COSCon‘25 的 AI 基础设施开源论坛议程正式发布了。如果你这些年一直在一线做 AI 应用、大模型训练推理或者负责公司内部算法平台的架构应该能感受到这个消息的分量开源已经从“方案选项”变成了“基础设施的默认答案”而这次论坛就是围绕这个答案展开的。不管是刚入行的算法工程师、搞了多年后端的技术负责人还是想参与开源但不知道从哪下手的贡献者这份议程都值得你花半小时认真拆一遍。我自己参加过几届 COSCon明显感觉今年的 AI 基础设施方向不再是过去那种“分布式存储”、“任务调度”的泛泛而谈而是直接对准了大模型时代最疼的几个问题GPU 不够用怎么办、数据杂乱怎么整、推理成本压不下去怎么解、模型上线之后怎么观测。看完这份议程我的直觉是它不是在讲未来的技术愿景而是在解决今天公司里每天都在发生的真实问题。下面我把这届论坛的核心内容、背后的技术逻辑、适合哪些人看以及我这些年在开源 AI 基建方面踩过的坑一次性说清楚。1. AI基础设施到底在“基建”什么1.1 从“算模型”到“建底座”的认知转变很多人一听到“AI 基础设施”第一反应是买显卡、搭机房。这个理解放到五年前是没错的但现在早就不是这样了。大模型时代基础设施的覆盖面已经扩展到了你从“拿到一个开源模型”到“把它变成线上稳定服务”之间的一切环节。我把 AI 基础设施拆成四层来理解这样比较直观层级核心问题典型开源项目算力层显卡怎么调度、资源怎么切分、任务怎么排队Kubernetes、Ray、Slurm、vLLM、Sglang数据层数据怎么采集、清洗、标注、版本管理、合成Airflow、DVC、Label Studio、Apache Arrow模型层模型怎么下载、微调、评估、压缩、部署Hugging Face Transformers、LoRA、ONNX Runtime、TensorRT-LLM应用层Agent 怎么编排、工具怎么调用、效果怎么观测LangGraph、Langfuse、MLflow、Prometheus可以这么想以前我们做 AI 是“自己买菜、自己生火、自己做菜”现在是大模型时代菜市场、燃气灶、抽油烟机、甚至菜单都变成了基础设施。你真正要投入精力的是怎么把菜做得比别人好吃而不是再纠结火候怎么控制。所以这次 COSCon 把 AI 基础设施单独拎出来做论坛本质上是在替行业喊一句话模型能力会持续迭代但底座不牢什么新模型都跑不利索。1.2 为什么 AI 基础设施天然适合开源这个问题如果放在五年前可能还需要辩论一下。现在答案已经很清晰了AI 基础设施是典型的“需要所有人共建、又被所有人共用”的公共资源。先说共建。没有哪家公司能独自搞定从底层芯片适配到上层 Agent 编排的全部环节。拿推理引擎来说vLLM 能这么快普及就是因为它吸收了全球几百家公司的贡献每个厂商把自家遇到的推理瓶颈、显存优化技巧都回馈到社区然后其他人直接受益。这种迭代速度闭源产品完全追不上。再说共用。如果你是一家中小型公司不太可能自己从零写一套 GPU 调度器或者向量数据库。用了开源方案相当于站在整个行业的肩膀上。这个优势在成本上尤其明显商业软件的授权费是按 CPU 核数或者节点数收的但开源项目可以随便铺。更重要的是开源意味着“可审计、可改造”。企业在 AI 落地中最怕的不是技术难而是被某个供应商锁死。你用一个闭源平台跑核心业务一旦平台调整策略、涨价、或者不再维护你连自救的机会都没有。开源项目至少把源码摆在那哪怕社区维护节奏慢了你也能拉分支自己续命。这些道理说起来简单但真正经历过“平台突然改收费策略”的人才会明白“底座必须掌握在自己手里”这句话有多重。2. 论坛核心议题拆解从算力到模型再到落地2.1 算力层GPU 紧缺背景下的弹性与效率算力是这届论坛绕不开的话题。现在的现状是大模型不是跑一次就完事而是长期做训练、微调、推理每一步都在吃显存。很多团队的 GPU 资源利用率低得可怜平均也就 30% 上下不是不够买而是调度能力跟不上。围绕这个痛点论坛里应该有大量分享会集中在几个方向异构资源统一调度把 A100、H800、4090 甚至消费级显卡都纳入同一个资源池按需分配。开源社区里现在比较主流的方案是 Ray Kubernetes 的组合Ray 负责分布式计算任务Kubernetes 负责资源生命周期管理。推理引擎的极致优化持续做大模型的 KV Cache 管理、连续批处理、投机采样这类技术。vLLM、SGLang、TensorRT-LLM 这些项目每发一个新版本吞吐量都能涨一截。弹性扩缩容在线推理服务有明显的波峰波谷。白天用户多晚上没人用如果服务始终全量跑着显卡全在空转。通过 KEDA 这类开源组件做基于队列长度、GPU 利用率的自动伸缩能省下很大一笔成本。这些方向有一个共性逻辑算力紧缺不是靠“买更多卡”解决的而是靠“把每一张卡压榨到极致”解决的。这也是开源 infra 团队最能体现价值的地方。2.2 模型层从下载到部署的完整链路过去模型部署是算法工程师的“最后一公里”现在这个环节已经变成了独立的专业领域。论坛里关于模型层的讨论我推测会围绕这几个话题展开模型选型。开源模型越来越多从几 B 参数的小模型到几百 B 的旗舰模型都有。怎么根据业务场景选择合适规模的模型没有绝对的答案需要一套评估机制。Hugging Face 上已经有大量 benchmark 数据但真实业务场景的效果还是得自己跑评测集。微调的工程化。LoRA、QLoRA 这类参数高效微调方法已经成为主流但微调之后怎么和原模型做切换、怎么保证不“灾难性遗忘”很多团队在实操中会踩坑。开源社区里比较好的实践是用 DVC 记录数据集和模型版本配合 MLflow 管理实验做到每次微调都可追溯、可回滚。部署形态的分化。同一个开源模型可以跑成在线 API 服务、可以打进边缘设备、可以做成离线批处理任务。不同的部署形态对量化、裁剪、编译优化有完全不同的要求。ONNX Runtime、TFLite、OpenVINO 这些项目在边缘场景中仍然是主角。说白了模型层已经不是“搞个模型回来就行了”的时代而是需要一套从选型到上线、从侧重点各异的部署形态到统一运维的流水线。这场论坛如果能把这些链路讲透参会者回去至少能少走半年弯路。2.3 数据层高质量数据是更深的护城河算法圈有一句老话数据和特征决定了机器学习的上限模型只是逼近这个上限。到大模型时代这句话依然成立而且被放大了。现在开源模型本身已经严重同质化同等参数规模下大家的能力差距并不大。真正拉开产品差距的反而是数据谁的数据更干净、更贴近业务场景、标注质量更高谁微调出来的模型就更好用。这次论坛在数据层面的议题我特别关注这几个点数据环节核心痛点开源工具链采集网站爬取、日志收集、多源异构整合Apache Airflow、Flink、Scrapy清洗重复、噪声、敏感信息、格式不统一pandas、Apache Spark、Dedupe标注人工标注贵、自动标注质量不稳定Label Studio、Argilla、GPT-4 辅助标注版本管理数据变更难以追踪、复现困难DVC、LakeFS、Git LFS合成数据真实数据不足、隐私合规限制Faker、Synthetic Data Vault其中合成数据是比较新的方向。现在很多团队发现靠人工标注根本跟不上模型迭代速度于是开始尝试用大模型生成结构化数据、用规则引擎构造对抗样本、用迁移学习补足长尾场景。这些方法在开源社区里有不少现成工具但真正把它们组合成一套可靠流水线的实践分享还是很稀缺的。如果你所在团队正在被“喂数据”这件事折磨这部分议程值得重点关注。2.4 工程化可观测性与成本治理往往决定生死AI 基建还有一个特别容易被低估的环节模型上线之后怎么观测、怎么排障、怎么控制成本。很多团队上线第一个模型的时候只关注效果指标比如准确率、召回率但真正上线跑起来之后发现问题根本不在模型本身而在系统层面。推理延迟为什么会抖动显存泄漏怎么定位用户输入变了模型效果开始退化怎么办某个调用方疯狂刷接口导致 GPU 成本飙升怎么办多版本模型同时在线流量怎么切分这些问题需要通过完善的观测体系来回答。开源生态里有 Langfuse、LangSmith部分开源、MLflow、Prometheus Grafana、OpenTelemetry 等一系列组件可以覆盖从调用链追踪到指标监控的完整链路。我特别想强调的是成本治理。大模型服务的成本结构跟传统 Web 服务完全不同Token 消耗就是真金白银。如果没有一套预算控制和配额管理机制一个失控的线上服务完全可能一个月烧掉几十万。开源界已经有项目在做模型网关专门负责限流、负载均衡、成本核算、多模型路由相当于把 API 网关的思路搬到了大模型服务上。这类项目性价比极高值得所有做 AI 应用的公司关注。3. 这份议程对谁最有价值3.1 一线开发者抓住技术风向标如果你天天在写 Prompt、调模型、搞 RAG 流程这份议程相当于一份“行业技术风向标”。你不用亲自跟踪每一个 GitHub 项目的 Release 记录只需要看论坛上哪些项目被反复提及、哪些议题被拿出来讨论就能判断出哪些技术正在从“玩具”走向“生产可用”。比如如果论坛上有多个分享都涉及“多 Agent 协作的可靠性”这个话题那就说明它在行业里已经有足够多的真实落地案例和踩坑经验你这时候入门正好能吃到早期红利。给一线开发者的建议不要只盯 PPT重点看分享者的开源项目地址和架构图。通常做完一场分享讲者都会把核心设计思路沉淀到项目文档里顺着这条线去挖收获会比会议本身大得多。3.2 架构师与技术决策者开源选型的重要参考对于负责技术选型的人来说这类论坛最大的价值不是“学习”而是“验证”。你可能已经在某几个开源方案之间犹豫了几个月想找人问问真实的使用体验。论坛现场的圆桌讨论、问答环节、会后交流都是绝佳的调研机会。我自己也做过技术决策踩过最大的坑就是只看项目 Star 数没有关注项目的许可证类型。Apache 2.0、MIT、GPL 的商用友好程度完全不同。别等到产品要商业化的时候才发现用了 GPL 组件导致整个项目都得开源那场面真的很尴尬。建议技术决策者带着明确的问题清单去逛论坛比如这套方案在千卡集群上验证过吗社区最近的 commit 活跃度怎么样背后有商业公司在维护吗和现有技术栈的兼容性如何出了问题社区响应速度如何这些问题的答案往往比官网白皮书真实得多。3.3 学生和开源新手找到低成本入圈路径如果你想进入 AI 基础设施这个方向但没有任何大厂实战经验开源社区可能是你最友好的入口。你不用简历上写着“五年分布式系统经验”只要在 GitHub 上有几个高质量的 commit、能在社区讨论里提出有价值的问题就已经比大多数求职者突出了。这次论坛对学生和开源新手的价值在于你能看到那些平时只出现在 README 里的项目维护者听他们亲口讲设计决策背后的权衡。这些内容学校里不会教但在实际工程中极其重要。更务实的建议是从文档和 issue 入手。别一上来就想提大 PR先帮项目修文档、补充测试、复现 bug这些都是社区非常需要但又没人愿意做的事情。积累几轮信任之后再逐步接触核心代码成长速度会非常快。4. 参与论坛的正确姿势与避坑指南4.1 会前预习先把背景补上我见过太多人参加技术会议现场听着热闹回去啥也没记住。核心原因就是背景知识没跟上听到的都是碎片信息。看这份议程之前建议先花一个周末的时间把议程里提到的核心开源项目在本地跑一遍。不需要做多复杂的二次开发只要能把项目启动起来、跑通一个最简单的 Demo 就行。比如用 vLLM 在本地起一个模型推理服务用 DVC 给一份示例数据集做版本管理用 Langfuse 追踪一次 LangChain 调用用 Ray 在本地启动一个简单的并行任务有了这些基础体验论坛上再听到相关的概念、架构、性能数据时你的理解深度完全是两个层次。因为你会自动把听到的内容映射到自己实际跑过的场景上“原来当时遇到的这个问题是这么解的”这种感觉比被动听讲爽多了。4.2 会中记录不是记 PPT而是记问题听分享的时候最忌讳逐字记录 PPT。PPT 上的内容基本都会公开真正有价值的是分享者讲到某个细节时顺口提的一句“这里我踩过一个大坑”或者回答听众问题时突然抖出来的实践细节。我的习惯是准备一个纯文本笔记只记录三类内容分享者提到了什么开源项目拼写是什么立刻记下来。某个架构图里出现了哪些我认不出来的组件在现场拍下来会后再查。分享者说“我们一开始是这样做的后来改成那样”的地方。这个前后差异往往比最终方案更有价值。另外一定要利用好问答环节。很多人不好意思提问担心问题太基础被鄙视。但我的经验是技术会议上大多数听众其实跟你水平差不多你问出的问题往往也是大家想问的。如果不确定问什么可以问一些开放性的工程决策问题比如“这个方案在单机跑和分布式跑有什么差异”“如果数据量再涨十倍当前的架构瓶颈会出现在哪里”这类问题通常能引出很有价值的回答。4.3 会后跟进把会议收获变成技术资产参会最大的误区是逛完就算完了。我给自己定过一个规矩参加完技术会议后72 小时内必须产出一份“技术简报”哪怕只是给团队发一篇内部笔记也行。具体做法是这样的把会议上收集到的项目地址整理成一份列表标注清楚它们解决的问题挑一个跟当前业务最相关的项目在本地部署跑一遍写一篇简短的使用体验包括安装过程、踩坑点、性能表现如果合适把体验分享到团队的技术 wiki 或者社区这个过程能帮你把被动输入转化为主动输出知识留存率会高很多。5. 从会议到日常把开源 AI 基建真正用起来5.1 一套最简 AI 基建栈跑通你的第一个 Demo听完论坛自己动手是最好的沉淀方式。如果你想快速体验现代 AI 基础设施完整链路这里有一套我非常推荐的最小组合全部开源一台带 NVIDIA 显卡的机器就能跑起来。组件职责为什么选它Ollama本地模型运行时一条命令下载并运行主流开源模型Open WebUI聊天前端提供类 ChatGPT 的交互界面vLLM高性能推理引擎测试吞吐量时对比 Ollama 的差异Langfuse调用追踪与可观测性记录 Prompt、Token、耗时DVC数据版本管理用 Git 思想管理数据变化第一步用 Ollama 拉一个 7B 到 14B 的模型比如 Qwen 系列。ollama run qwen2.5:7b几秒就能跑起来。先感受一下纯对话体验。第二步通过vllm serve以 OpenAI 兼容接口的方式启动同一个模型。你会立刻发现它在并发请求、吞吐量上的优势。这背后就是连续批处理和 PagedAttention 等优化带来的差异。第三步在代码里调用 vLLM 的服务把请求接入 Langfuse 做追踪。这样你就能看到每一次请求的耗时、Token 消耗、Prompt 内容。它是你之后优化效果和成本的基础。第四步用 DVC 给数据集做个版本管理建立一条简单的数据更新流程。你就能理解为什么说“数据管线”也是基础设施的一部分了。这套组合拳跑下来你对 AI 基建的认知会从“听过很多名词”变成“我亲手搭过一条链路”。有了这个基础再去看论坛的深水区内容吸收效率完全不同。5.2 参与开源贡献怎么选项目、怎么上手关于怎么选项目我有一个非常朴素的标准选你自己正在用的项目。不要为了刷贡献而去研究一个你根本不会用到的轮子。你日常使用中踩到的坑、觉得哪里不顺手、想要但没找到的功能就是最好的贡献起点。比如你正在用 Langfuse 做链路追踪发现它的告警通知只支持少数几个渠道而你用的是钉钉。这时候你就可以动手看看项目的 API 设计在 GitHub 上发一个 feature request如果维护者回复了相关计划可以问一句“需要帮忙实现吗”从最简单的 provider 扩展开始写一个通知渠道适配器这类贡献不需要你理解整个系统的全貌只需要你熟悉自己用到的那个模块学习成本很低但对项目的价值却很实在。另一个建议是多留意“good first issue”和“help wanted”标签。但不要盲目认领先看 issue 对应的代码区域你是否熟悉有没有可能在一到两周内完成。认领后如果进展不顺及时在 issue 下说明维护者通常能理解。我发现很多新手最缺的不是技术能力而是“敢动手”的勇气。总觉得自己水平不够担心提的代码被维护者吐槽。其实开源社区的常态是只要你的 PR 是认真做的哪怕没有直接被合并维护者也会在 review 时给出详细的改进意见。这个过程本身就是极好的学习。5.3 关注这个领域日常信息源怎么搭如果你打算长期跟踪 AI 基础设施和开源生态建议把日常信息源结构化一下别每天被动刷热搜。GitHub Trending每天快速看一下 Star 增长异常的项目不一定是排名最靠前的而是那些在你关注的领域里突然冲出来的新项目。配合 GitHub 的 Watch 功能关注几个核心仓库的 Release 和 Discussion。Hacker News 的 Show HN很多有创意的开源项目会在这里首发亮相尤其是开发者工具类。技术会议的视频回放COSCon 这类会议结束后演讲视频一般都会传到 B 站或者官网。不需要实时看参加完会后用一周时间分章节回放效果甚至比现场更好因为可以暂停和倍速。项目维护者的个人博客直接订阅你喜欢的开源项目核心维护者的博客或 RSS 源能提前看到他们的设计思路和行业判断。把这些信息源组合起来每天花大概 30 分钟长期坚持你对领域的敏感度会明显高于其他人。6. 写在最后我的几点体会从最初自己用开源组件搭模型服务到后来参与维护一些开源项目再到这次看到 COSCon 的 AI 基础设施论坛议程我的感受其实挺一致的开源在这里已经不是一个“可有可无”的选择而是很多团队真正跑通 AI 业务的基石。我自己在实践中有两个一直坚持的习惯分享给大家。第一不管项目再忙每隔一段时间一定要做一次“技术下沉”。所谓下沉就是暂时离开业务代码去深入了解底层基础设施到底是怎么运转的。比如花一个下午去看 vLLM 的调度逻辑、看 Kubernetes 怎么调度 GPU 资源。这种投入不会直接带来业务收益但能让你在排障时多很多直觉而且往往能发现一些可以反向优化应用层的机会。第二永远保持“够用就好”的心态。开源基建领域有个陷阱就是技术名词太多、方案太丰富容易陷入“什么都想用”的误区。如果你只需要一个简单的推理服务先别急着上分布式推理框架。等流量真实涨上来了再逐步演进架构比一开始就搭一个庞大的集群要务实得多。这次论坛虽然议程刚发布但从主题设置和嘉宾方向来看基本覆盖了 AI 基础设施从资源调度、数据工程、模型服务到可观测性的完整链路。对很多人来说它可能会成为接下来一整年项目选型和技术规划的重要参考。建议你提前把议程里感兴趣的部分标记出来准备好问题清单带着自己的实际业务场景去参会、去提问、去交流。等会议结束之后如果有什么值得聊的技术细节我再回来补一篇实战复盘。