7 月收尾云原生 AI 平台的半年里程碑与下半年路线一、半年数据从零到日均 480 万推理请求一月的时候这个平台还只是三个模型跑在几台 GPU 节点上的原型系统。到七月底平台承载的在线模型 26 个日均推理请求 480 万次GPU 节点 32 台日均成本 $1,240。对应的团队规模是 6 个人。数字本身不说明问题。核心问题是这半年的建设到底解决了哪些能力瓶颈还有哪些关键能力缺失。七月作为上半年的收尾月适合做一次整体复盘把半年的交付串成一条线。二、半年能力建设全景第一阶段1-2 月让模型能跑起来第一阶段的目标简单选型推理引擎、搭建 K8s GPU 调度、把 3 个模型部署上线。关键技术决策是选择 vLLM 而非 TGI 作为主力推理引擎六月完成了全量迁移原因在前面的月报里已详细说明。这个阶段的遗留问题是模型能跑起来但不保证跑得好。可用率 98.2%、GPU 利用率 25%、没有批处理——属于能用但远不到好用。第二阶段3-4 月让服务质量可度量、可优化多模型推理网关是第二阶段最关键的交付。它解决的问题是不同模型有不同的延迟特征、上下文窗口和成本结构但应用层不应该关心这些差异。网关负责请求路由、负载均衡和自适应批处理。这个阶段同时建立了服务质量监控体系。TTFT、TPS、显存利用率三个指标构成了模型服务的核心 SLA 看板。监控体系的建设带来一个预期之外的收益排障时间明显缩短——以前要翻 5 个不同系统的日志现在一张 Grafana 面板能看到全链路状态。第三阶段5-6 月成本优化不是省钱是把钱花对地方GPU 是 AI 平台最贵的资源。第三阶段的 GPU 分时复用和训练/推理混合调度不是在省 GPU而是让 GPU 从一卡一用变成一卡多用。GPU 利用率从 25% 提到 62%等效释放了约 10 台节点的算力。Scale-to-Zero 是另一个成本管控的关键能力。低频模型长期常驻消耗资源但没有产出自动缩放到零后用多少付多少。这个阶段也上线了 Spot 实例的自动切换策略在有 fallback 保证的前提下进一步降低推理服务的基础成本。第四阶段7 月稳定性治理和技术债务清理七月做的事情和前面三个阶段不同——不是在加新能力而是在修旧地基。三次存储故障的修复、CI/CD 流水线从 12 分钟到 5 分钟、工具链的瘦身评估、性能调优清单——这些都是基础设施层面的精细化运维。三、下半年的路线三个必须填上的坑半年交付了 20 个能力但差距仍然明显。下半年必须解决三个关键问题3.1 跨集群 GPU 池化当前所有 GPU 节点在一个集群内当这个集群资源耗尽时无法将推理负载自动迁移到其他集群。这意味着单集群的 GPU 容量上限就是整个平台的能力天花板。下半年的目标是为推理服务建立跨集群的统一调度层基于 Karmada 或自研调度器实现跨集群的 GPU 资源池化和负载迁移消除单集群资源瓶颈。3.2 推理服务质量从返回结果到返回正确结果当前的服务质量指标衡量的是技术性能——延迟、可用率、吞吐。但这些指标回答不了模型给出的回答是否准确。下半年计划建立内容质量自动评估管线至少覆盖三个维度幻觉率事实性错误、格式遵从率结构化输出的一致性和风格一致性。3.3 多租户资源隔离当前所有推理服务共享 GPU 池没有租户级的资源隔离。当一个模型的流量暴涨时可能挤占其他模型的计算资源。下半年计划基于 K8s ResourceQuota 和优先级抢占机制建立租户级的资源保障体系让每个业务线都有明确的算力 SLA。四、团队能力的增长与缺失半年做了不少事情但团队的短板也清楚了强项基础设施搭建和运维、GPU 调度调优、Go 后端服务开发。弱项模型评估和 Prompt Engineering 的方法论积累不足、训练侧的 GPU 调优NCCL 参数、FSDP 分片策略还处于摸索阶段。缺失没有专门做 AI 安全和对齐的人模型的安全评测越狱攻击、有害内容过滤目前是空白。下半年的团队扩充计划优先考虑两个方向一个是训练侧的性能优化工程师补齐 NCCL/FSDP 的短板另一个是 AI Safety 方向的工程师建立安全评估体系。五、结语半年时间团队把一个原型系统跑成支撑 26 个模型、日均 480 万推理请求的平台。GPU 利用率从 25% 提到 62%推理吞吐提升 22%CI/CD 从 12 分钟压到 5 分钟可用率从 98.2% 提到 99.7%。这些数字背后是无数个深夜的排障、一次又一次的配置调整和不断迭代的架构决策。但也要清醒地看到跨集群调度还没做、内容质量评估还是空白、多租户隔离只存在于文档中。下半年的重点是填上这三个坑把平台的成熟度从能用推到可规模化运营。基础设施不需要漂亮话。上半年的成绩是数据说话下半年的目标也要用数据来验证。七月是上半年的终点但不是建设的终点——八月已经开始新的能力必须在新的数据中得到证明。