COSCon 的议程终于公布了。作为一个从第一届开始就蹲直播、后来自己也上台讲过两回的老开源人每年秋季等这份议程已经成了我的固定仪式。今年让我最上头的不是主会场那些宏大叙事而是一场专门把 AI 基础设施单独拎出来的论坛——在这个模型满天飞的年份真正决定 AI 能不能落地的其实是那些最容易被人忽略的算力调度、数据管线、推理优化和平台工程。底座稳不稳直接决定上层应用能走多远。这篇就把我读完议程后的第一手解读整理出来聊聊 AI 基础设施为什么值得开源圈拿出整整一个论坛来讨论以及普通开发者和开源爱好者能从里面挖到哪些真正有用的东西。1. 为什么AI基础设施成了开源社区绕不开的议题1.1 AI基础设施到底覆盖了哪些层很多人一听 AI 基础设施 就以为说的是 GPU 集群这个理解太窄了。我把 AI 基建拆成五层来看最下面是算力层包括 GPU、NPU 这些加速卡异构计算框架还有资源调度系统往上是数据层数据集整理、数据标注、特征工程、数据版本管理都在这一层再往上是模型层预训练、微调、量化、推理服务、模型注册和评测基准接着是平台层负责把上面的能力封装成 API、工作流和可观测体系最上面才是应用层AI Agent、RAG 知识库、AI 编程助手这些东西。用盖房子来类比可能更好懂模型是装修风格产品是家具陈设而 AI 基础设施是水电骨架和承重墙。平时看不见一旦出了问题整个屋子都没法住。过去两年大家把注意力都放在哪个模型又刷榜了上面直到真正把模型搬进生产环境才发现网络带宽、GPU 利用率、数据清洗链路、推理延迟、成本账单每一个环节都能让人崩溃。这也是为什么 AI 基础设施从一个后端话题变成了连产品经理都在讨论的前台话题。对开发者来说理解这五层还有一个实际用处你可以快速定位自己的技术栈到底卡在哪一层。比如你用开源模型做应用发现效果不好问题可能不在模型本身而在数据层没做好发现响应很慢问题可能在推理服务和调度策略上。方向判断对了才能选对工具避免拿锤子到处找钉子。1.2 为什么这件事必须开源AI 基础设施如果走封闭路线会有一个很现实的问题信任没法建立。模型是黑盒、算力调度是黑盒、数据管线也是黑盒企业把核心业务放上去之前总要问一句你的底层到底干了什么。开源天然解决这个问题——代码看得见、日志查得到、问题可复现出了问题社区会一起修。更重要的是基础设施从来都是规模效应的游戏。一个调度框架用的人越多暴露的场景越多迭代越快最终形成事实标准。今天我们熟悉的 Linux、Kubernetes、Prometheus都是这么走过来的。现在的 AI 技术栈正在重复服务器时代走过的路一开始百花齐放然后通过开源社区的协作统一底层接口最后形成大家默认的公共层。谁在这个阶段参与得越深谁在未来的标准制定里话语权就越大。对中小团队来说开源基建还意味着不被锁定。商业云厂商的托管服务确实方便但等你把数据、工作流、监控全绑上去之后迁移成本会高到让你怀疑人生。开源项目至少给了你一条退路也可以用社区版先把架构跑通再按需购买商业支持。这种安全感和可选择性在基础设施选型里比什么都重要。2. 论坛议程的整体编排逻辑把AI基建拆成三层从已经公开的议程信息来看能明显看出组委会想做的一件事把AI 基础设施这个大词拆成三个互相咬合的层面来讲。这个编排思路挺务实的没有停留在AI 很厉害的口号上而是把技术人真正关心的算力、数据、工具链问题摆到了台面上。对听众来说按这条主线去听会比自己随机串场要高效得多。2.1 算力层异构计算、调度与成本优化第一个层面是算力。这方面的议题基本都围绕一个核心矛盾GPU 又贵又缺但利用率普遍不高。很多团队买了卡跑起来才发现一台机器上 GPU 空转的时间比计算时间还长多团队共享集群时资源分配全靠吵架训练任务和推理服务混部的时候互相抢资源导致谁也跑不快。开源社区这几年在算力调度上交出的答卷正是这一层重点讨论的内容。Kubernetes 生态里的 Kueue、Volcano 这类项目专门解决批量任务排队和资源配额的问题Ray 在分布式计算和弹性伸缩上做得比较成熟已经有不少公司在生产环境跑了大规模训练和推理任务更细的还有 GPU 共享、MIG 切分、内核态调度等优化手段每一招都能把硬件的利用效率再往上顶一截。算力层还有一个绕不开的话题是成本。跑一次训练、部署一组推理服务账单数字往往让老板皱眉这种算力水账单问题在社区里被反复讨论。开源方案的价值在于它能让你把成本拆到每个任务、每个模型、甚至每次请求上——用开源监控和计量工具做好账单分析再结合调度策略做弹性伸缩省下来的钱往往比换更便宜的云厂商还要可观。我特别建议做平台工程的同学重点关注这一层。你们平时最头疼的资源碎片化、任务排队时间长、不同框架的镜像管理混乱在这类议题里几乎都能找到对应的开源解法。听完之后哪怕只回去落地一个调度策略都值回票价了。2.2 数据与模型层从开源模型到数据治理第二层是数据和模型。现在开源模型的选择已经多到让人挑花眼从通用大模型到垂直行业小模型从英文主导到中文友好的中文社区模型几乎每一个细分需求都能找到对应产物。但模型只是起点真正决定业务效果的是数据怎么组织、怎么清洗、怎么喂给模型。这一层会聊到数据集的构建与治理原始数据里噪声太多、版权不明、缺乏标签怎么办数据版本怎么管理才能让每一次模型训练都可回溯评测集怎么设计才能防止模型刷题式地过拟合。这些都是生产环境下每天都会遇到的硬骨头。开源数据集、开源数据工具链在这里的价值是让团队不必从零开始直接站在前人的肩膀上做增量。模型层的另一个关键词是推理服务化。训练出一个好模型只是第一步把模型高效地部署成可调用的服务才是真正的考验。vLLM 这类推理引擎通过 PagedAttention 等机制大幅降低显存占用、提升吞吐已经成了很多团队部署开源模型的首选配合 Triton、ONNX Runtime 等跨框架推理服务一套底座可以同时跑多种框架的模型运维复杂度下降得不是一点半点。还有模型评估和可观测性。用开源评测框架给模型打分用 Langfuse 这类开源工具追踪每次推理的输入输出、Token 消耗和延迟出了问题能在链路里直接定位。在许多实际案例里线上模型效果突然变差最后查出来是上游数据字段格式变了这种问题没有可观测链路的话排查起来简直是灾难。2.3 工具链与Agent层应用开发的最后一公里第三层是离应用最近的工具链和 Agent 生态也是今年最热闹的方向。AI Agent 已经从能聊天进化到能干活:自动规划任务、调用工具、读写代码、操作浏览器背后需要一整套工程化支撑。MCP 这类开放协议正在把模型和外部工具之间的交互标准化让 Agent 不再局限于某个厂商的封闭生态。AI 编程是另一个绕不开的话题。开源社区里出现了不少 AI 编程助手和代码补全工具可以直接接入本地的编辑器在保护代码隐私的前提下提供智能补全和重构建议。与之配套的还有 AI 代码审计和软件供应链安全工具——AI 动辄生成几千行代码质量门禁和漏洞扫描就变成了刚需开源审计工具可以帮助团队在合入代码之前把明显的问题拦下来。为了让 Agent 稳定可用这一层还离不开可观测性和测试评估。Agent 每一步决策、每次工具调用都需要被记录和追踪否则出了问题根本没法复现。开源方案在这里的优势是数据和链路完全自主可控可以按自己的业务需求做深度定制。社区里甚至已经开始出现专门给 Agent 写测试的测试框架把传统软件工程里的单测、集成测、回归测理念搬到了 Agent 开发里。从整个论坛的编排来看这三层是一条完整的价值链算力省下来数据和模型才能跑得动模型和服务稳定了上层的 Agent 和应用才有发挥空间而工具链又反过来提升开发和运维效率形成正向循环。这样拆开讲即使是刚入行的开发者也能找到自己最应该深入的那个切入点。3. 议题之外几个值得重点跟踪的开源方向论坛议程里能看到的内容已经很多了但作为一个经常泡开源社区的老人我还想额外提醒几个容易被忽略、但实际落地价值很高的方向。这些方向不一定每个都有独立议题但会在多个演讲里反复出现值得重点跟踪。3.1 开源大模型与私有化部署开源大模型已经成了很多企业做 AI 应用的首选底座原因很直接数据安全、定制空间、长期成本。私有化部署虽然没有公有云那么省心但数据不出内网这个特性对金融、医疗、政企这些行业几乎是刚需。现在团队可选的路子很多需求轻量就上 Ollama体验一把本地起服务的感觉追求并发和性能就上 vLLM把吞吐打满想要完整的模型服务化体系可以走 KubeFlow 或 Ray Serve 这条更重的路线。选型建议我给一条先明确你的场景是学习验证还是生产服务。学习验证随便折腾Ollama 就够了显卡差点也能跑量化版生产服务必须考虑高可用、压测、监控、回滚一上来就要按平台工程的标准去设计。很多团队栽跟头就栽在先用着以后再说结果模型一上线就裸奔。量化也值得关注。同样的模型从 FP16 量化到 INT8 甚至 INT4显存占用可能砍掉一大半推理速度还能提升。代价是精度有一定损失,需要在成本和效果之间做权衡。论坛上如果有讲量化和推理优化的议题建议认真听一下这部分经验基本都是踩坑踩出来的。3.2 开源知识库与RAG落地RAG 是当前把大模型落地到企业场景最稳妥的方式之一核心思路是先检索相关内容再让模型基于检索结果生成回答减少一本正经地胡说八道。一个典型的开源 RAG 链路包括文档解析、文本分块、向量化、向量检索、重排序、提示词组装、生成与引用溯源。这个链路看起来简单细节全是坑。文档解析阶段PDF 里的表格、扫描件、页眉页脚处理不好后面全白搭文本分块阶段切得太碎会丢失上下文切得太大会稀释语义分块大小和重叠率要根据文档类型反复调检索阶段向量模型的选型和 embedding 维度会直接影响召回效果单路召回不够的时候还得加关键词召回做混合检索。开源方案在这条链路上的优势非常明显。Dify、RAGFlow 这类项目把整个流程封装成了可视化编排工具配置相对友好向量数据库可以选 Qdrant、Milvus 或者轻量的 Chroma重排序模型也有开源版本能把检索结果里最相关的内容排到前面。强烈建议你先用开源组件把一个最小可用的链路跑通再逐步替换瓶颈环节而不是一上来就追求大而全的平台。3.3 边缘计算与嵌入式AI论坛讨论的热点大多在云端但边缘和终端场景同样重要尤其是面向硬件和嵌入式开发的工程师。工业质检、智能摄像头、可穿戴设备、车机交互这些场景往往对延迟和隐私极其敏感必须在本地完成推理端侧 AI 和嵌入式开源项目因此成了基础设施里不可忽视的一环。端侧推理的核心是把模型压到设备能跑的尺寸。除了量化还有模型蒸馏、剪枝、算子融合等优化手段。开源推理引擎在端侧的支持差异很大移动端有 TFLite、MNN、NCNN 这些老牌选手更轻量的嵌入式场景则需要 BSP、交叉编译环境和底层算子库的紧密配合。很多工程师平时用的开源软件镜像站、包管理器本质上也是这套基础设施的一部分只是平时不太会被当作主角来讨论。开源硬件和嵌入式操作系统的组合正在把 AI 的能力从云端下沉到各种物理设备上。这一块的参与者不一定都是大厂背景反而是中小企业、创客和高校实验室贡献了大量有价值的项目。如果你做硬件相关的工作这类议题和展台是绝对不能错过的很多分享者本人就是项目的核心维护者现场交流的价值比看十篇博客都大。4. 参加COSCon25的实操建议与避坑指南议程再好不会听会也白搭。我参加过好几届 COSCon也在其他技术大会上踩过不少坑总结下来高效的参会绝对不是准时进场、从头坐到尾而是有策略、有目标、有后续动作。4.1 行前准备先读议程再定路线收到议程之后第一件事不是收藏而是通读一遍把感兴趣的议题标记出来。我个人的习惯是每个时间段先按最想听排序然后每个时段准备一个备选因为现场可能会遇到某些热门会场站不下、某些演讲临时调时间的情况。重点标记那些有实操演示、有开源项目代码仓库地址、演讲者本身就是核心维护者的场次这种内容的干货密度通常最高。行前还有一个容易被忽略的环节提前列出自己最近遇到的技术问题清单。比如GPU 共享怎么实现RAG 召回率一直上不去怎么办带着具体问题去听会你会发现普通的技术分享瞬间变成了私人咨询。很多讲者在会后都愿意多聊几句前提是你能提出一个让他觉得这个人真的在做这件事的问题。另外如果想在现场动手实操记得带上笔记本并提前装好常用的开发环境但如果是纯听讲和社交轻装出行反而更舒服。会场通常会比较吵带个降噪耳机和充电宝是明智的选择。4.2 现场怎么听会才有收获到了现场别急着从头记到尾。技术分享的 PPT 一般都会公开比起逐页抄笔记更需要记录的是这个方案为什么这么做和他踩过的坑是什么。我记笔记只记三件事可复现的结论、项目的仓库地址、以及当场冒出来的疑问。疑问可以在 QA 环节直接提问也可以在会后找讲者交流。QA 是全场价值密度最高的十分钟。很多人在大场合不敢提问其实完全没必要有压力。提问的目标不是显得自己多厉害而是解决自己的困惑。一个有效的问题通常包含三部分我的场景是什么、我做了什么尝试、卡在了哪里。比如我在 K8s 上用 Kueue 做配额管理发现抢占策略不符合预期有没有推荐的配置方式?这种问题讲者一听就知道你是真用户回答也会特别具体。如果现场有 Open Space 或闪电演讲环节强烈建议参与。Open Space 是一种非正式的小型讨论主题由参与者现场提出主持人只负责引导秩序每个人都能开口说话。我第一次参加时还有点拘谨后来发现这种场合才是认识同行、碰撞思路的最佳场所。哪怕只是抛出一个自己正在纠结的问题都可能收获好几个人从不同角度给出的建议。4.3 会后跟进把灵感变成Issue会后最大的坑是热情散场就结束了。我见过太多人在会上加了微信、拍了 PPT、说要回去试试然后就没有然后了。我自己后来定了一条规矩参会后一周内必须把自己感兴趣的项目至少打开一次给它提一个 Issue 或 Star 一下。具体做法是把会上记下的仓库地址整理成一个清单逐个扫一遍 README、看最近的 Release 和 Issue 列表、跑一个最小示例。遇到文档不清楚或者跑不通的地方直接提 Issue附上自己的环境信息、复现步骤和日志。一个高质量的 Issue 本身就是对开源项目的重要贡献同时也是你和维护者建立联系的开始。如果时间和精力允许还可以顺手写一篇参会总结发到技术社区或者把某个项目的使用体验整理成教程。这个动作看起来是利他的实际上是检验自己有没有真正理解的最佳方式——写不出来就说明没听懂写出来了就会有人来和你讨论你的圈子就自然扩大了。5. 从围观到共建普通开发者参与开源基建的路径最后聊一个话题也是很多刚接触开源的朋友最关心的我知道了这些项目很重要也想去参与但代码量不够到底能做什么其实参与开源的门槛远比你想象的低尤其是 AI 基础设施这类大型项目需求是多元的贡献方式也是多元的。5.1 文档贡献是最友好的起点很多人的第一个开源贡献来自文档我就是这么走过来的。大型基础设施项目的文档量非常大API 更新后文档没跟上、翻译不完整、示例代码跑不通、架构图过时这些问题几乎每个项目都有。修一个文档错别字、补一段新手指引、把某个晦涩的概念用更通俗的例子讲清楚都是实实在在的贡献。文档贡献的最大好处是它会逼着你把项目完整读一遍。为了写清楚一个模块的用法你不得不去理解它的参数、返回值、边界条件这个过程比单纯翻代码高效得多。而且文档 PR 通常 review 起来比较快对新手友好能让你在比较短的时间里走通提交 PR、参与讨论、被合并的完整流程建立正向反馈。一年下来积累十来个文档类的 PR你就已经对这个项目的设计和结构有了比较深入的了解这时候再转向代码贡献会顺理成章很多。不少开源项目的核心贡献者最初就是从帮项目写文档这个不起眼的动作开始的。5.2 用真实业务问题驱动贡献而不是只写Hello World很多新手想做代码贡献一上来就搜good first issue结果找到的题要么太小没有成就感要么和自己的实际场景完全无关。我的建议是反过来先在自己的项目里认真用这个开源软件用到深处一定会遇到问题这才是最好的贡献入口。比如你在生产环境里用某个开源向量数据库发现内存占用异常这就是一个绝佳的研究方向。你可以尝试定位是配置问题还是 bug可以在社区里提问可以先给项目提交一个详细的 Issue说明现象、环境、复现路径和已经做的排查。维护者最缺的往往不是修 bug 的人而是能把 bug 讲清楚的人。一个高质量 Issue 能帮助他们快速定位问题省去大量来回沟通的时间。在你能够稳定地提出高质量 Issue 之后就有机会参与真正的代码修复了。从补一个测试用例开始到修一个边界条件再到实现一个小功能路径会越来越清晰。核心心得是真实需求带来的动力和耐心远不是为了凑贡献数量能比的。5.3 贡献开源不只有写代码注意许可证与社区礼仪最后必须强调开源项目的贡献方式远不止代码。设计、测试、文档、翻译、社区运营、布道推广、用户支持每一个环节都是贡献。尤其是 AI 基础设施项目需要大量测试人员在真实环境里跑数据、反馈性能需要有人帮忙整理用户案例需要有人做中文社区的问题解答——这些工作同样重要而且缺口很大。如果你决定开源自己的项目许可证的选择值得花点时间琢磨。MIT 和 Apache-2.0 都算宽松商用友好后者还多了一条明确的专利授权条款GPL/AGPL 则强调代码共享AGPL 对网络服务也有约束。很多项目因为许可证选得草率后续商业化或合作时才发现处处受制。具体怎么选要结合你的目标是广泛采用还是保护代码不被闭源商用这也是每个开源参与者迟早要面对的选择题。在社区沟通层面尊重和维护者的时间很重要。提问前先搜文档和已有 Issue提问时给出完整的上下文收到回答后及时反馈结果这些基本的社区礼仪会让你的贡献之路顺畅很多。开源社区本质上是个陌生人协作的网络信任是靠一个个负责任的举动积累起来的。最后说点个人体感。每年开完 COSCon我都会重新整理一遍自己关注的开源清单今年尤其如此。AI 基建这个赛道表面上看是巨头之间的军备竞赛实际上恰恰是开源社区最能发挥价值的地方——因为基础设施比拼的不是谁的发布会更响亮而是谁能把信任、透明和生态做扎实。就像十年前没人能预料 Kubernetes 会成为整个行业的事实标准一样今天你在论坛上听到的某个调度器、某个评测框架也可能就是未来 AI 世界的底座。你不需要一开始就懂底层原理先来听、来问、来提一个 Issue就已经是参与筑底了。