最近朋友圈里被一条消息刷屏了COSCon‘25 AI 基础设施开源论坛的议程正式发布。无论是搞模型的、做平台的还是写业务代码的都在转这个链接。说实话这两年我参加过的技术大会不少但像这样把“AI基础设施”单独拎出来作为一场核心论坛还是能看出行业风向的变化——大家终于不再只盯着模型效果刷榜单而是开始认真思考那些支撑AI跑起来的底层系统到底该怎么建。这个论坛的核心主题很清晰开源赋能筑牢AI基建底座。一句话拆开看有三个关键词开源、AI、基础设施。而这三个词放在一起恰好构成了未来几年技术圈最重要的命题。围绕这份议程结合我自己在开源社区和AI工程化项目里踩过的坑、趟过的路把这事儿的门道从头到尾捋一遍。想了解AI基础设施到底包含什么、开源方案怎么选怎么用、以及普通人怎么参与进来的朋友这篇文章应该能给你一个比较完整的视角。1. 为什么“AI基础设施”是开源未来十年的题眼1.1 从AI应用狂欢到基建底座之争过去两年AI圈子的热闹程度有目共睹。大模型能力越来越强ChatGPT、开源模型、各种AI Agent框架层出不穷似乎什么应用都能被AI重做一遍。但如果你真的在一线跑过生产环境就会有完全不同的体感Demo和产品之间隔着一整个基础设施的鸿沟。很多团队拿着开源模型做了漂亮的原型一上生产就崩。为什么因为推理服务扛不住并发、GPU利用率低得可怜、数据管道一塌糊涂、模型版本管理混乱连回滚都不知道怎么回。这些都跟模型本身的参数多少没关系问题全出在底座上。这也解释了为什么“AI基础设施”这个词开始被反复提及。算力怎么调度、数据怎么流转、模型怎么部署、服务怎么观测这四件事构成了AI落地的基本盘。而基本盘不稳上面盖多少层楼都白搭。所以COSCon把AI基础设施论坛作为独立板块不是赶时髦是真有那么多问题需要聊。1.2 开源在AI基建中的三个不可替代价值为什么AI基础设施这件事天然适合开源来做我的理解有三个层面。第一是透明可控。AI系统越来越复杂如果底层全用闭源黑盒出了问题你连排查方向都没有。开源让训练流程、数据管线、推理服务都裸奔在阳光下出了问题能顺着代码往下查这在合规和审计场景里尤为重要。第二是生态共建。AI技术迭代太快今天刚出的方案三个月后可能就过时了。闭源商业产品有滞后性而开源项目背后是全世界开发者在共同推进踩坑的速度和修复的速度都是单打独斗没法比的。你用的组件不是一家公司在维护而是整个社区在维护。第三是成本。AI基础设施的建设成本极其高昂从GPU集群到存储到网络哪一样都不便宜。开源让团队能站在社区的肩膀上把别人沉淀好的工程能力直接拿过来用省下的时间就是省钱。这也是我常跟朋友说的开源省的不是软件授权费而是研发人员的生命。2. AI基础设施的技术栈到底有哪些层AI基础设施这个概念听起来抽象拆开看其实是一条很具体的链路。我把日常工作中会接触到的技术栈分成六个层次每一层都有对应的开源方案也都有绕不开的坑。2.1 算力层GPU资源池化与集群管理算力层是AI基础设施的物理底座。你要训练一个大模型或者部署一个高并发的推理服务背后都需要成百上千块GPU在协同工作。但GPU是非常贵的资源一块A100级别的卡跑着千把块钱一小时的成本如果利用率只有30%老板的脸色可想而知。所以算力层要解决的核心问题就是资源池化与高效调度。Kubernetes是绕不开的底座它负责把GPU抽象成可调度的资源。但原生K8s对GPU调度支持并不算好于是就有了Volcano、Kueue这类批量调度组件。Volcano擅长处理AI训练中常见的“排队-调度-运行”模式能根据优先级和公平性把任务安排得明明白白Kueue则更侧重于配额管理让多个团队在共享集群里互不干扰。另外Ray在处理分布式计算和并行任务编排上也很受欢迎它把Python生态和分布式执行结合得很好适合做数据并行和规模化的模型服务。除了调度算力层还要操心故障。GPU集群里单卡故障是常态一块卡中途挂了整个训练任务可能就要从头再来。所以持续检查点、自动弹性伸缩、节点腾挪这些能力都必须配套。这套东西做扎实了集群才敢扛生产任务。2.2 数据层数据版本化、标注与加速AI圈有句老话数据决定了模型的上限。但没有好的基础设施数据就是一团乱麻。很多团队的数据散落在各个FTP目录、NAS、甚至个人电脑里版本混乱到无法追溯那训练出来的模型出了问题根本不知道该怪谁。数据层的开源工具其实已经很成熟了。数据版本管理用DVC它像Git一样管理数据集和模型的版本记录下每次变更改了什么这样你可以随时回到某一个数据快照复现实验。数据标注可以用Label Studio支持图像、文本、音频等多种类型的标注还能做多人协作和质量管理。特征存储方面Feast很出名它的作用是把线上线和离线用的特征统一管理避免训练时用的特征和推理时取的特征不一致——这个不一致的问题在工业界经常引发线上事故。另外值得单独说的是数据加速。模型训练时如果数据喂不够速度再强的GPU也是在空转。Alluxio和JuiceFS这类工具可以把数据写到分布式缓存或对象存储里用内存缓存的方式大幅提升数据读取效率。我见过一个项目仅仅接入了数据缓存层训练吞吐就直接提升了数倍显卡利用率也肉眼可见地涨了起来。2.3 模型层训练、微调、推理与量化模型层是大家关注度最高的地方因为这里的技术迭代最快。训练框架里DeepSpeed和Megatron-LM都是重量级开源选手它们解决了大模型分布式训练时显存不够、通信开销大等问题。不过对于绝大多数团队来说全量预训练不是常规动作更多时候是在开源基座模型上做微调。微调现在的主流方案是PEFT家族的LoRA和QLoRA。原理很好理解冻结住已经训练好的权重只训练一小部分低秩适配器参数这样既能适配特定任务又不需要动辄几百GB的显存。比如你要在7B模型上做领域适配用QLoRA方式甚至可以在消费级显卡上跑起来不用再望GPU兴叹。推理环节是生产环境最敏感的。vLLM和Text Generation InferenceTGI是目前两个使用最广的开源推理引擎。vLLM的PagedAttention技术特别值得一提它把KV Cache按页管理像操作系统管内存一样大幅减少了显存浪费让推理吞吐扶摇直上。Triton Inference Server则是NVIDIA出品的重量级方案它不是一个模型专属的引擎而是一个统一的推理服务平台可以同时托管多种框架的模型。还有量化工具AWQ和GPTQ把大模型压缩到4bit或者8bit让部署成本直线下降。2.4 调度与编排层从工作流到模型服务模型训练好了怎么把它变成能对外提供服务的API这中间其实隔着很大一段工程。工作流层面Airflow、Dagster、Prefect这些开源调度工具让整个训练流程可编排、监控、重跑。它们解决的是“从一个Notebook脚本到一个流水化生产任务”的问题让你面对复杂依赖时不需要手工逐个触发。模型服务的标准化也很关键。KServe是Kubernetes上跑模型推理的标准方案它支持模型导入、自动扩缩容、灰度发布相当于模型服务领域的“标准CI/CD”。BentoML则更偏向开发者体验可以把Python模型快速打包成标准服务同时管理依赖和运行时环境。如果团队规模不大BentoML上手会更快一些。2.5 开发范式层Agent与工程化协作到了这个层讨论的重点已经从“跑通”变成了“怎么开发效率更高”。最近AI Agent非常火LangChain、LlamaIndex这些框架让开发者能用几行代码就组合出复杂的Agent行为。但工程化远不止代码提示词怎么管理Agent的响应怎么评测怎么确保它在这一轮和下一轮之间不会漂移所以现在越来越多团队会做提示词版本化和评测集建设。提示词也像代码一样入库、评审、上线变更后自动跑评测集检查对核心场景的影响。这一步虽然听起来有点笨重但在生产环境里非常重要。基础设施能支撑起这套协作范式AI产品的质量才真正可控。2.6 可观测与治理层运维AI系统的眼睛AI系统运维和传统系统运维不一样。传统系统你监控CPU、内存、QPS就够了但AI系统还要监控模型质量。离线指标合适不代表线上效果好数据分布一变模型效果可能悄悄下滑。所以可观测与治理层需要关注的内容更广。MLflow是老牌开源模型生命周期管理工具支持实验跟踪、模型注册、项目管理。Langfuse和Phoenix则是专门为LLM应用设计的可观测工具能追踪到大模型每一步的输入输出、成本消耗、甚至推理链路里的推理过程。Prometheus加Grafana依旧是底层监控标配用来看基础设施的负载时延。这些工具拼在一起才能给AI系统装上“仪表盘”出了问题知道去哪看。3. 开源项目在真实业务场景里的完整链路技术栈说了这么多估计有人会觉得抽象。我挑了三个典型业务场景把“开源基础设施如何落地”完整串一遍这样就知道这些组件是怎么配合工作的。3.1 自动驾驶场景数据闭环是怎么转起来的自动驾驶的核心痛点是数据。路采车每天回传海量视频如果靠人工去分类、标注、整理再训练效率低到难以想象。一个典型的开源数据闭环是这样的原始数据回传到存储池用代码自动做时间戳对齐和场景标签化。用Label Studio组织标注团队在统一平台里标目标框、车道线标注结果自动落库。DVC把每一轮的标注数据集打上版本快照关联到对应的模型训练实验。训练集群通过Ray做任务调度把训练、仿真验证、评测串联成一个流程。模型评测达到标准后通过KServe灰度上线同时用监控工具观测线上表现。线上发现的新问题场景再回流到数据池开启下一轮迭代。这个链条看起来很大但每一环都有成熟开源组件能顶上。整个闭环跑起来后从“采集数据”到“模型更新”的时间可以从数周压缩到数天。3.2 工业质检场景实时推理链路怎么搭工业质检对实时性要求很高。比如一条产线上每分钟流过数百张产品图片要在毫秒级判断是否有缺陷。链路大致是这样高速相机拍摄的图片先落到本地缓存由采集程序做初步压缩和筛选。再通过消息队列送入GPU集群调用训练好的缺陷检测模型做推理。推理结果返回产线控制系统同时把“可疑样本”自动写入待复核队列。模型管理用MLflow做版本跟踪每次模型更新前先在历史数据上跑回归。实时监控用Prometheus采集每个阶段的处理时延和成功率和误报率。产线端到端的延迟、误检率和漏检率都会被记录每个环节都看得见。当漏检率上升时系统自动触发告警干预后若有必要则回滚到上一版模型。这套系统里基础设施的价值不在于某一个模型有多强而在于整个链路能稳定跑、出了问题能找到原因。这也是工业场景最看重的东西可靠性排在一切指标前面。3.3 大模型微调与私有化部署场景现在很多企业内部在做“私有知识库”或者“行业大模型”链路也非常典型。先用开源基座模型加LoRA微调适配领域数据再把模型量化后部署到推理服务里。这里的关键参数其实很容易算清楚。比如一个70B参数模型如果权重用FP16保存模型体积大概是140GB光靠单张80GB的A100或者H100显存是肯定装不下的。如果做量化到4bit大概只需要35GB到40GB单卡就能推理。这就是为什么量化工具在私有化部署场景里如此重要。部署的时候再用vLLM的PagedAttention优化KV Cache管理实际吞吐还能再往上翻不少。我见过不少团队在这个环节翻车原因是把“模型部署”理解成了简单的“拉起一个服务”。结果遇到并发上来、显存溢出、模型版本不对这些问题时没有配套的监控和回滚手段线上直接翻车。基础设施的意义就在于它是为“出问题的时候”准备的。4. COSCon’25 AI基础设施论坛专题前瞻回到COSCon这份议程本身虽然我没办法剧透每一个具体的演讲嘉宾但从“AI基础设施”这个方向来看论坛的专题设置基本会覆盖几个重要维度。这边帮大家梳理一下值得关注的看点。4.1 算力与集群建设是绕不开的主旋律在大模型训练和推理需求集中爆发的当下算力集群的调度、容错、利用率优化是最现实的难题。这个专题大概率会涉及Kubernetes上的GPU共享与资源池化、多租户配额、慢节点识别、集群自动恢复等话题。对于正在自建GPU集群的团队这些内容的价值不亚于一场解决方案培训。尤其值得关注的是如何提升GPU利用率。很多平台的利用率长期在20%到40%徘徊这和任务调度不到位、网络通信瓶颈、数据加载速度慢都有关。如果能从论坛演讲里收获一套成熟的提升思路回去对集群做一次优化省下的钱可能是百万级。4.2 推理性能、量化与部署方案对比是焦点推理侧的技术演进非常快。vLLM从诞生到成为事实标准只用了很短时间量化和推理加速的新方案也层出不穷。这类议题会很直接地回答一个问题同样一个模型怎么部署性价比最高。关注量化算法和推理引擎对比的听众建议针对性消化这个板块。大模型推理的显存与算力开销如何边界、PagedAttention这种技术到底优化在哪、常见推理引擎在不同场景下怎么选型把这些问题搞透之后你回到自己的项目里就能直接套用。4.3 数据工程与知识基建走向台前在模型能力走向“够用”之后数据的工程化含量会越来越高。高质量数据的采集、清洗、标注、版本管理以及大模型时代的RAG知识库建设都会成为讨论热点。这个方向很多人重视不够但它决定AI应用的上限。我自己参加过不少数据工程建设相关的社区交流深感数据的“脏乱差”才是AI项目最常见的失败原因。这个论坛的思想碰撞大概率会给这些苦于数据质量的人提供一些新思路包括数据管道如何自动化、数据处理链路如何展开、治理如何落地。4.4 MLOps与LLMOps成为不可或缺的环节没有运维就没有真正可靠的生产系统。MLOps曾经是少数大厂在讨论的话题现在已经是中小团队也必须面对的日常。实验管理、模型注册、持续评估、灰度发布、在线监控这些组件共同构成了AI系统的“运维编排层”。LLM应用可观测的议题应该也会在论坛上被重点关注。一个Agent从接收用户输入到最后完成工具调用中间会经历多次模型推理和数据检索这一整条链路的追踪与成本核算比传统服务的监控复杂得多。这块内容对正在做AI应用生产落地的团队尤其实用。5. LLM时代基础设施的新挑战LLM给基础设施带来的变化不只是“模型变大了”这么简单它让整个基础设施的设计逻辑都发生了变化。5.1 显存策略决定推理成本的生死线模型推理由计算密集转向显存密集这是LLM时代最显著的变化。Transformer模型在推理过程中需要维护KV Cache随着并发请求增加KV Cache会占用大量显存。传统推理框架里这些显存处于一种“预分配但无法预知用量”的状态浪费非常严重。vLLM的PagedAttention之所以能火起来本质就是把这个浪费打了回去。这也是为什么量化、推理引擎选型、显存容量规划这些“底层细节”现在连业务团队都要开始关心了。因为每差一档效率体感上都是在烧钱。很多团队在给客户报价时才发现推理成本占了总成本的相当大比例而这些成本的高低很大程度上取决于基础设施层是否做了优化。5.2 从批处理思维切换到交互式推理思维传统互联网服务的核心逻辑是“请求-响应”资源分配比较稳定可预期。而LLM推理是动态生成的用户问一句话模型可能要生成几百上千个token每一个token都在消耗GPU算力。这导致负载模型极度非线形A用户一个简单请求可以很快返回B用户一个复杂请求可能拖住整卡几十秒。这种差异让传统的自动扩缩容策略失效了。按QPS扩缩容你会发现机器被拖垮按并发token数扩缩容又需要新的度量标准。基础设施层现在要做的是更细粒度的资源切分、请求排队、超时控制以及多模型间的“路由”。调度策略合理与否直接影响用户体验和成本。5.3 多租户与安全隔离成为硬需求当AI能力对外开放多租户隔离就不可避免地成为焦点。这里不仅是“租户之间不能干扰”的性能隔离还包括模型推理过程中输入输出的数据隐私合规。开源基础设施在解决这些问题上已经积累了不少方案比如模型沙箱隔离、自定义安全策略、审计日志系统等但离“开箱即用”还有距离。这也是很多企业选择接入开源组件并二次开发的原因灵活性和可控性都更好。6. 选择开源方案的五条避坑指南既然开源是AI基础设施的主旋律那怎么选开源方案就成了最现实的问题。这些年我在选型上踩过不少坑总结几条避坑经验尤其值得刚接触这块的人看一看。6.1 选型前先问四个问题网上各种开源项目的Star数和宣扬文案很容易让人眼花缭乱。我的习惯是选型前先问自己四个问题团队有没有能力二次开发和排错如果纯靠社区支持选一条比较大众案例多的路径更稳妥。社区是活跃还是死水一潭看GitHub的commit频率、issue反馈速度、最近release时间这些都是“活水”的指标。许可证是否允许商用这点容易被忽略后续可能在法律上出问题。组件的运维边界是否清晰有些开源项目安装容易日常运维成本很高这个账也要算清楚。6.2 许可证的“隐藏雷区”开源不等于免费商用许可证问题在工程实践中经常被忽略。Apache 2.0是比较宽松友好的MIT也很自由但GPL系列有较强的传染性——意思是你的代码如果基于它做了衍生可能需要用同样许可证开源。还有一些项目用的是“开源代码、商用收费”的带源码可用协议Business Source License简称BSL它本质上不是严格意义上的开源但很多不了解的人会误用落地到商业项目之后才发现有使用限制。建议每个团队维护一张许可证合规清单选型时同步评估别等法务找上门再回头排查代码。6.3 成本与运维的平衡之道开源软件本身免费但“免费”的含义仅限授权费。你在社区上得到的支持有限取决于社区的活跃度。自建基础设施涉及的人力、运维、带宽和存储成本往往是隐性的。拿GPU集群来说硬件采购是一次性成本但机房、电费、运维人员工资才是持续的大头。很多团队前期没算清这笔账后期搞到一半发现难以为继。一个替代思路如果团队没有专门的运维队伍优先选择管理型的开源发行版或SaaS服务很多发行版在开源之上提供了企业支持和纯自建相比谈不上哪个绝对好核心要看团队场景。6.4 稳定性优于先进性开源社区永远在迭代新版本功能很诱人但稳定性永远应该优先于先进性。我见过有人为了尝鲜直接上主分支版本结果遇到各种莫名其妙的问题。建议生产环境永远锁定一个经历过考验的稳定版本尽量让新组件先在测试环境灰度跑一段时间充分验证之后再逐步替换。6.5 安全底线依赖与供应链审查开源组件用多了供应链安全是个绕不开的问题。你拉的每个镜像、每个依赖包都可能有潜在漏洞。所以一定要建一套扫描机制用Trivy、Grype这类工具扫描镜像和依赖库定期清理高危漏洞同时维护软件的物料清单SBOM做到“这台机器上跑了什么、为什么在这里”可追溯。AI系统涉及的依赖更多安全问题更容易被忽视但这恰恰是最不能省的一环。7. 从“用开源”到“反哺开源”这条路怎样才能一直走远最后聊聊参与开源这件事。很多读者可能想说你说的这些开源项目我都在用但深度参与总觉得离我很远。其实不然。7.1 贡献的起点远比你想象得低参与开源不一定要一上来就写复杂的功能代码。第一个PR从修文档里的错别字、补注释、优化示例代码开始完全没毛病。这些看似微小的贡献恰恰是你熟悉项目流程、代码规范、贡献指南的最好方式。我记得自己也干过这种“修文档”的活虽然小事但因为走了一遍完整的PR流程对项目的参与感一下子就上来了。除了代码和文档给项目提一个详细的issue也是很好的贡献。能清楚描述问题、提供最小复现路径、说明预期行为的issue维护者是发自内心感谢的那种问题本身就是在帮社区省时间。7.2 从小步提交到主线PR当你对某个项目越来越熟悉就可以尝试写一点有实际价值的代码。值得特别注意的是动手之前先看维护者的方向。开源项目最怕的就是有人闷头写了一堆代码结果跟项目维护者的规划完全不在一个方向上。正确做法是先去Issue区找有没有讨论中的需求或者在Discussions里直接说“我想做这个事情方向对吗”获得认可后再动手。这样你提交的PR被合入的成功率会高非常多。另外遵守项目的代码规范、提交规范和PR描述模板甚至比代码本身更能赢得维护者的好感。这些“显性礼仪”都是社区协作的一部分。7.3 反哺开源长期主义的复利效应持续参与开源给我带来的最大回报从来不是简历上多了一行字而是形成了“遇到问题 → 调查根因 → 修复并共享”的工作习惯。这种习惯让一个人对系统的理解变深也让个人在社区里慢慢积累声誉。很多同行都是因为长期在某几个项目里贡献后来收到大厂Offer或者社区邀请的。这条路没有任何捷径但“复利效应”非常惊人。在论坛上看到那些开源项目的核心维护者时你不必觉得自己跟他们有距离。他们也是一行一行PR写出来的只是比你更早开始、坚持得更久而已。对自己诚实一点只要在持续用这些基础设施你其实已经是社区的一部分了。这句话不是场面话开源之所以能有生命力恰恰是因为“使用”本身也是在为项目提供反馈和生态基础。我个人在实际操作中的一个体会是参与开源不要急着证明自己先想着怎么把自己的问题解决得更漂亮。当你真正把一个项目吃透改起来得心应手的时候很多所谓的机会和收益都会自然而然地出现。最后再分享一个小技巧参与议题讨论时尽量要求自己带一个可复现的案例或数据去发言而不是只发表感受。这样才能真正吸收属于你的那份经验对下一次工程选型产生实质帮助。