开源社主办的 COSCon‘25 中国开源年会AI 基础设施开源论坛的议程终于官宣了。这两年做 ML 平台、容器编排、数据引擎的朋友应该都有同一种感觉大家嘴里聊的还是大模型有多聪明手里干的却全是基建的脏活累活——GPU 资源利用率上不去、推理服务延迟抖动、训练作业一挂就是一整天。AI 要从 demo 变成生产力真正卡脖子的恰恰是这些“没那么多聚光灯”的基础设施层。这篇文章我以从业者的视角把本次论坛主题拆开揉碎结合过去几年我在开源社区踩坑和交付项目的经验聊聊为什么这场论坛值得关注以及你该带着什么技术视角去听。1. 为什么是“AI 基础设施”论坛选题背后的产业逻辑1.1 从模型竞赛到工程竞赛过去三年AI 圈的兴奋点一直在模型本身参数规模、评测分数、多模态能力。但到了 2025 年行业里越来越多人意识到模型能力再强如果训练时算力利用率不到 30%推理时单次调用成本降不下来业务就根本无法规模化落地。我所在的小组去年接手过一个内部大模型服务平台前半年折腾的一直不是模型而是资源调度。这种变化的核心原因在于AI 已经从一个“算法问题”变成了“系统问题”。训练一个千亿参数模型需要成千上万张 GPU 协同工作网络拓扑、通信库、容错机制、数据吞吐每一项都会直接影响训练效率上线一个对话产品需要面对峰值流量、连续多轮回复、上下文长度增长带来的显存压力和传统 Web 服务的容量模型完全不同。模型竞赛的红利正在被工程能力摊薄谁的基建底座更稳谁才能真正把模型成本打下来。1.2 开源在 AI 基础设施中的不可替代性为什么这场论坛要谈“开源赋能”因为回看整个 AI 基础设施生态几乎所有关键层级的“事实标准”都是开源项目。在资源调度层Kubernetes 已经是无可争议的底座在模型推理层vLLM、Triton、Ollama 这些项目几乎主导了生产级部署方案在数据链路层对象存储、数据湖、向量数据库里跑在前面的也是开源项目。商业闭源方案当然存在但它们往往滞后于社区创新的速度而且容易形成锁定。基础设施一旦被锁定后续想换引擎、换调度策略、加新硬件支持都会被供应商牵着鼻子走。这就像修房子。你可以花钱请人盖但地基的图纸如果不掌握在自己手里每次想要加一层楼都得看别人脸色。开源的价值不在于“免费”而在于可审视、可修改、可演进。本次 COSCon‘25 的 AI 基础设施开源论坛把话题集中在开源生态本质上也是希望把这类“地基能力”放到公开场域里讨论让不同背景的工程师站在同一个坐标系里对齐思路。2. 议程核心拆解这场论坛到底在聊什么2.1 算力与调度吃透 GPU 的极致方案GPU 是整个 AI 基础设施中最贵、最稀缺的资源因此算力调度天然是论坛的重头议题。过去单机单卡的时代调度问题很简单一张卡跑一个模型。现在不一样了训练任务动不动要几十台机器组成一个集群推理任务则希望在同一批机器上塞进更多模型副本。资源不能碎片化也不能因为某个任务占着卡却没用满导致其他任务排队。这个方向上的典型开源技术栈包括 Volcano、Kueue 这类批处理调度器以及 Kubernetes 生态里的 GPU 设备插件和拓扑感知调度。论坛议程里如果出现“混部”“超卖”“潮汐调度”这些关键词不要觉得它们互相矛盾。混部指的是训练任务和在线推理任务共享集群白天推理负载高夜里训练负载高通过优先级和弹性配额把同一个集群的利用率拉满超卖则是指不按物理卡数量分配资源而是按显存和算力动态切分。听这类议题的时候我建议大家把关注点放在三个问题上任务排队模型是否公平、抢占策略是否会导致长训练任务做无用功、故障恢复的 Checkpoint 机制是否成熟。因为调度器在演示环境里都很好看真正拉开差距的是集群规模大了之后的稳定性。2.2 模型服务与推理优化让模型真正“用起来”模型训练完成只是开始真正决定业务体验的是推理环节。推理优化这几年发展非常快核心思路已经从“加速单次计算”扩展到“提高吞吐与降低延迟的权衡”。以 vLLM 为代表的推理引擎之所以能成为主流关键在于 PagedAttention 这类显存管理技术它把 KV Cache 像操作系统管理内存一样进行分页大幅提升批处理吞吐。配合 Continuous Batching连续批处理模型可以在一个推理循环里动态加入新请求而不是等整批结束。论坛议程里只要涉及“推理延迟”“吞吐优化”“量化”都离不开这些底层机制。另外模型服务不仅是引擎本身。生产环境里还需要网关来做多模型路由、Prompt 鉴权、限流需要灰度发布能力来切换新版本模型需要流式输出时的连接管理。整个链路里任何一个环节不扎实都可能让模型响应变慢或直接断连。我的经验是自建推理平台时前两周通常都在和网络代理、超时重试、连接池这老三样斗争真正调模型参数的时间反而少。2.3 数据链路与存储AI 的“另一半”工程AI 基础设施如果只聊算力和引擎很容易被带偏方向。数据才是模型效果的“原材料”而数据工程的复杂度经常被低估。论坛议程里大概率会覆盖数据构建、特征工程、评估数据集、RAG 知识库等话题。开源方案里数据湖和对象存储的选型已经相对成熟MinIO、CubeFS 这样的项目在 AI 场景下出镜率很高。相比之下更值得关注的是数据版本化和数据血缘。训练数据不是一成不变的每次清洗规则调整都可能改变模型分布如果数据版本无法追踪出了线上效果回退的问题很难定位是代码改错还是数据改错。RAG 相关的知识库也是近两年论坛上的常客。向量数据库、文档解析、切片策略、召回重排这些组件组合起来才是完整的知识库底座。我不建议上来就搭建一条包含十几个中间件的复杂 RAG 链路更务实的做法是先用一个开源向量库加一个成熟的嵌入模型把闭环跑通再逐步加入重排和评估环节。3. 落到现场从议程倒推你需要提前掌握的技术栈3.1 一眼看懂底层骨架云原生与 AI 的合流听这类论坛时如果你对 Kubernetes 不太熟很多演讲会听得云里雾里。因为当前 AI 基础设施的默认坐标系就是“云原生 AI 工作负载”。最底层的骨架是 Kubernetes 集群上面跑着两类工作负载训练 Job 和推理 Deployment。为了让 GPU 能被容器正常使用需要安装 NVIDIA GPU Operator 这类组件把驱动、容器运行时、设备插件统一管理起来。往上走是调度层负责决定哪个 Pod 分配到哪块 GPU 上再往上是推理引擎层负责加载模型、处理请求最上层则是 AI 平台或网关对外暴露统一接口。这套骨架可以用一张心智图来记忆集群是底盘调度是方向盘推理引擎是发动机网关是仪表盘。论坛上的每个议题几乎都能在这套骨架里找到对应位置。听演讲时先在心里判断一下台上讲的是哪一层再把他提出的问题映射到自己的架构里效果会好很多。3.2 上手示例在 Kubernetes 上部署一个轻量推理服务纸上谈兵没有意思我拿一个非常典型的部署示例来说明。假设要在 Kubernetes 集群里部署一个 7B 参数的对话模型并且通过 OpenAI 兼容接口对外提供服务。最常用的开源组合是 vLLM 对象存储 K8s。模型文件放在对象存储或共享存储中Deployment 的 YAML 大致长这样apiVersion: apps/v1 kind: Deployment metadata: name: qwen2-5-7b-infer namespace: ai-infra spec: replicas: 2 selector: matchLabels: app: qwen2-5-7b template: metadata: labels: app: qwen2-5-7b spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model - Qwen/Qwen2.5-7B-Instruct - --tensor-parallel-size - 1 - --max-model-len - 8192 resources: limits: nvidia.com/gpu: 1 ports: - containerPort: 8000这份配置里有几个参数值得展开说。tensor-parallel-size表示模型切分到几张 GPU 上。7B 模型单张 24G 显存基本够用但如果你跑 70B 模型单卡放不下就需要把这个参数调大同时配合多卡通信。max-model-len控制最大上下文长度这个参数直接影响显存占用开得太大容易 OOM开得太小又会截断用户输入需要根据线上实际 prompt 长度谨慎调整。把这个 Deployment 提交到集群后还需要配套 Service 和 HPA 才能对外可用、自动扩缩容。HPA 的指标不建议直接用 CPU而应根据 GPU 利用率和请求队列长度配置自定义指标。这是很多团队容易踩的坑模型服务是 IO 密集和显存密集型的CPU 使用率几乎参考意义不大。3.3 参会前必会的 5 个工具与概念如果你想在论坛现场听懂 70% 的内容而不是全程懵圈建议提前熟悉以下开源工具和概念。工具/概念对应环节一句话理解Kubernetes底座容器编排系统AI 工作负载的统一“宿舍楼”Volcano / Kueue调度批处理任务排队与优先级管理解决“谁先上 GPU”的问题vLLM推理高性能模型推理引擎显存管理非常激进GPU Operator资源让 K8s 能识别 GPU装载驱动与监控组件Prometheus OpenTelemetry可观测采集 GPU 利用率、推理延迟等指标没有它基本等于盲跑这五个工具里可观测性往往是最容易被忽略的。很多团队把服务部署上去之后才发现不知道怎么看 GPU 显存碎片、不知道哪个模型实例在处理超长请求、不知道请求排队时间飙升的原因。没有指标就没有调优依据。4. 老兵的避坑手册AI 基础设施常见问题与排查实录4.1 绕不开的 6 个经典问题这么多年实操下来我总结了一些非常典型的故障模式。这六个问题几乎每个做 AI 基础设施的团队都会遇到论坛现场问答环节也大概率绕不开。第一是 GPU 显存 OOM。推理引擎配了过大的max-model-len或者在批处理中把并发请求数调得太高直接导致 CUDA Out Of Memory。排查时先看推理引擎日志里的显存申请记录再把并发数和上下文长度同时降一半通常能快速恢复。第二是 GPU 利用率低但任务还是慢。这种情况多半不是算力不够而是数据加载成为瓶颈。训练作业不断等待数据从远端存储拉取GPU 空转。解决方案是把数据缓存本地、使用共享内存做数据集缓存或检查网络带宽是不是被打满。第三是分布式训练中 NCCL 通信超时。多机训练时节点之间的网络抖动或拥塞会导致 AllReduce 操作卡住整个训练任务停摆。这个问题的排查特别烦日志里通常只会看到Timeout字样。建议先检查网卡速率和 MTU 配置再验证节点间带宽最后确认是否有人在同一网络上跑了大流量任务。第四是镜像拉取慢导致副本扩容失败。集群里新增推理实例时节点需要拉取几个 GB 大小的镜像如果直接走公网镜像仓库扩容可能要花十几分钟。企业内部应该搭建镜像仓库或者提前在节点上预加载镜像否则流量突增时扩不上来和没有扩容一样。第五是推理引擎的请求排队时间不可控。连续批处理模式下引擎会尽量填满当前批次导致某些请求等待过久。解决思路是设置合理的超时和最大队列长度以及在网关层做排队分流而不是把所有流量压到同一个推理实例上。第六是 CUDA 版本和驱动不匹配。容器里跑 PyTorch 或 vLLM需要特定版本的 CUDA 运行时但宿主机的 NVIDIA 驱动只支持到某一版本。遇到CUDA driver version is insufficient错误时别急着换镜像先看宿主机驱动版本再选择对应 CUDA 基础镜像。4.2 我给新人的三条实操建议如果你刚开始接触 AI 基础设施有几条经验能帮你少走弯路。第一条先从单机单卡跑通一个端到端推理服务再考虑集群化。很多人一上来就搭三个节点的 K8s 集群中间每一个环节都可能出问题GPU Operator 装不上、设备插件没识别到卡、PV 挂载失败。先在单机上把 vLLM 或 Ollama 跑起来用真实请求压一压延迟再一步步迁移到集群。第二条可观测性建设一定要在第一天就做而不是上线之后补。至少要把 GPU 利用率、显存占用、推理延迟和 Token 吞吐量四个指标采到监控系统里并配置基本告警。没有这些数据你排查任何一个问题都会像在没有仪表盘的飞机上盲飞。第三条对开源项目的版本保持敬畏。AI 基础设施生态迭代极快vLLM 几天就发一个新版本K8s 一年三个大版本很多 API 会弃用。部署时锁定版本升级前先行测试不要永远追着 latest 跑。5. 论坛之外如何把这次议程变成你的行动清单5.1 听懂一场技术论坛需要带什么问题入场很多人参加技术会议是“听讲模式”听完就觉得“好像都懂了“回去之后什么也没留下。我自己的做法是在进场前先写下三个当前项目里最让我头疼的问题然后有意识地从演讲里寻找答案或线索。比如如果你的产品总是被反馈首 token 延迟太高那你关注的重点就应该是推理引擎的预填充优化、KV Cache 复用这类议题如果你发现训练集群的 GPU 利用率不到 40%那你的关注点就应该落在混部调度和资源超卖上。带着问题入场听论坛才不会变成被动接收信息。另外不要只盯着讲得精彩的演讲者。会场里布展区的开源社区 Maintainer、相关项目的 Contributor他们能给你的信息往往比 PPT 更真实。多问一句“这个方案在生产环境最大跑到过什么规模”通常能得到比演讲更诚实的答案。5.2 社区参与路径从用户到贡献者的最短距离COSCon 本质上是一场开源大会所以论坛之外的社区气息非常浓厚。如果你在会场里被某个开源项目打动想参与进去我的建议是不要一上来就提大功能或大重构。最稳妥的路径是先把项目用起来遇到问题后有质量地提交 Issue然后尝试修复文档错误、补充测试用例、优化 CI 脚本等到你对代码结构足够熟悉再尝试认领 Small Good First Issue。这条路看起来慢实际却是最快建立信任的方式。维护者最怕的不是你菜而是你提了一个影响全局的设计提案却对项目历史一无所知。我在这方面的经验是每次参加完这类会议我都会挑一个正在用的开源项目在未来两周内提交至少一个文档或测试相关的 PR。量不大但能让我保持对社区的参与感。最后说点个人体会。这几年我参加过不少类似的技术论坛发现一个规律大家在台上聊的方法论大同小异真正的差异都藏在“这个方案在线上跑了多大规模”以及“遇到故障时你花了多久恢复”这些细节里。COSCon’25 的 AI 基础设施开源论坛把议题聚焦在底座上方向上是对的。作为工程师我们最该带走的不是某家公司的新品发布而是一份对自己技术栈的复盘——哪里还是黑盒哪里靠手工救火哪里可以借助开源生态彻底重做。这种带着问题来的参会姿态远比多记几个项目名更有价值。