7 月 AI 基础设施复盘：我们到底在平台上加了哪些能力
一、从"能跑"到"能扛"：AI 平台能力建设的核心矛盾
一个月时间，AI 基础设施团队到底做了什么？如果只看工时统计，无非是几十个 PR、上百次部署、一堆配置变更。但这些数字回答不了真正的问题：平台能力的边界到底扩展了多少？
七月，团队面临的核心矛盾是三个并发增长——模型数量增长了 40%、日均推理请求量增长了 3 倍、训练任务提交频率增长了 60%。但基础设施不会因为需求增长而自动变强。资源和需求之间的裂缝，只能靠新能力去填。以下是七月实际落地到平台上的能力增量，按生产影响排序而非功能炫酷程度排序。
二、能力全貌：七项平台增量的一体化视角
七月的平台能力增量覆盖了调度、服务质量、成本管控三个核心维度，彼此之间存在强依赖关系。以下是整体架构：
七项能力中，GPU 分时复用和自适应批处理对生产可用性的影响最大，下面重点拆解这两项。
2.1 GPU 分时复用调度器：让一张卡被多个推理服务共享
在七月之前，GPU 节点的分配策略是粗粒度的独占模式——一个推理服务即使只用 30% 显存，也会占满整张卡。随着模型数量增长，GPU 利用率长期徘徊在 25%-35% 之间。
七月初上线的分时复用调度器基于 MIG（Multi-Instance GPU）和非 MIG 兼容两种模式实现。对于 H100 和 A100，启用 MIG 将单卡拆分为最多 7 个独立实例；对于旧款 V100，通过显存隔离和 CUDA 流绑定实现软件层面的分时复用。调度器通过扩展 Kubernetes scheduler extender，在 Pod 调度阶段感知 GPU 分片可用性，避免了"请求已调度但 GPU 不足"的问题。
核心改动在于 Device Plugin 的自定义资源上报逻辑。不再简单上报nvidia.com/gpu: 1，而是上报分片级别的资源：
nvidia.com/gpu-mig-1g.5gb: 7 nvidia.com/gpu-mig-2g.10gb: 3 nvidia.com/gpu-mig-3g.20gb: 2 nvidia.com/gpu-mig-7g.40gb: 1这个改动看起来小，但在调度层面带来的影响极大——需要配合扩展调度器支持分片维度的 Bin Packing 和碎片整理策略。上线后 GPU 平均利用率从 28% 提升到 62%，等效节省了约 35% 的 GPU 节点成本。
2.2 自适应批处理引擎：让推理吞吐不再随请求量线性衰减
多模型推理网关 v2 的核心能力是自适应批处理。传统方案的问题是：批处理窗口的大小是固定的，当请求量波动时，要么产生额外排队延迟，要么 GPU 算力浪费在 batch padding 上。
自适应引擎根据四个实时指标动态调整 batch_size：传入队列长度、P99 延迟、GPU SM 占用率、显存带宽使用率。调整算法基于指数加权移动平均，上限 64，下限 1。当 GPU 利用率低于 40% 时，batch_size 每 500ms +8；当 P99 延迟超过 SLA 阈值的 80% 时，batch_size -4 并将等待超时缩至原来的 50%。
以 Llama-3-8B 推理为例，在并发请求 200 QPS 的情况下，固定 batch_size=32 的方案 P99 延迟达 320ms，自适应方案 P99 稳定在 180ms 以内，且吞吐量提升 22%。
三、关键工程实现：优先级抢占与自动缩放到零
3.1 训练任务优先级抢占
训练任务和推理服务共享 GPU 池是成本优化的必然选择，但训练任务通常是批处理性质，对延迟不敏感。优先级抢占机制允许高优推理服务驱逐低优先级的训练 Pod，类似 Kubernetes 原生 PriorityClass 的逻辑，但加入了 GPU 状态保存。
抢占触发前，调度器会向被抢占的训练 Pod 发送 SIGTERM 前的 checkpoint 信号，训练框架（PyTorch FSDP）在收到信号后将 optimizer state 和 data loader position 序列化到共享存储。被抢占后的恢复时间从重新开始训练缩短到 2-3 分钟。
实现上需要注意死锁场景：如果所有 GPU 节点都被训练任务占满且同时被抢占，可能造成推理服务也调度不上。解决方案是将每个 GPU 节点至少保留 20% 的显存给推理服务预留池。
3.2 推理服务自动缩放到零
成本管控的最后一个环节是"缩放到零"。对于低频调用的模型（如内部测试模型、冷门垂直模型），长时间保持常驻 Pod 是巨大的浪费。
七月实现的 Scale-to-Zero 方案基于 KEDA + Prometheus 自定义指标触发，当模型连续 5 分钟内请求数为零时，驱动 KEDA 将 Deployment replicas 设为 0。请求恢复时通过 Istio sidecar 的"冷启动代理"临时缓存首请求，待 Pod 就绪后转发，首次请求延迟控制在 cold start SLA 的 3 秒以内。
这个方案在七月为 12 个低频模型节省了约 60% 的常驻计算成本。
四、边界条件与尚未解决的问题
七项能力落地不代表可以高枕无忧，每个方案都有明确的边界：
- GPU 分时复用：MIG 的分割粒度固定且不可动态调整。当一个 2g.10gb 实例空闲时，不能拆成两个 1g.5gb 给更小的服务使用。另外 MIG 模式下不支持 GPU Direct RDMA，对多节点训练有一定影响。
- 自适应批处理：依赖 GPU 指标采集的实时性，在 Prometheus scrape interval 为 15s 的默认配置下，调整存在 15s 滞后。对于流量突变（如秒级 spike），批处理窗口可能来不及响应。
- 优先级抢占：checkpoint 恢复的前提是训练框架支持，目前仅覆盖 PyTorch FSDP 场景。TensorFlow 和 JAX 训练任务暂不支持优雅抢占。
- 缩放到零：冷启动代理处的首请求缓存存在内存泄漏风险——如果缓存未及时清理，低频率模型的请求日志会持续膨胀。
此外尚未解决的一个问题是跨集群 GPU 调度。目前所有能力限定在单集群内，当单个集群 GPU 资源耗尽时，无法自动将推理负载迁移到其他集群。
五、总结
七月交付的七项能力覆盖了 GPU 利用率提升、推理服务吞吐优化、训练/推理混合调度、低频模型成本优化四个关键方向。量化来讲：GPU 利用率从 28% 提到 62%，推理吞吐提升 22%，低频模型成本降低 60%。
八月的优先级建议集中在两个方面：一是跨集群 GPU 池化，打破单集群资源天花板；二是提升 MIG 的灵活性，探索 vGPU 或 MPS 方案作为 MIG 的补充，让 GPU 分片粒度更细。
基础设施不需要漂亮话，但需要持续的能力交付。七月的数据证明了这一点：每一个百分点的利用率提升背后，都对应着实实在在的硬件成本省出来的钱。
