7 月 AI 基础设施复盘我们到底在平台上加了哪些能力一、从能跑到能扛AI 平台能力建设的核心矛盾一个月时间AI 基础设施团队到底做了什么如果只看工时统计无非是几十个 PR、上百次部署、一堆配置变更。但这些数字回答不了真正的问题平台能力的边界到底扩展了多少七月团队面临的核心矛盾是三个并发增长——模型数量增长了 40%、日均推理请求量增长了 3 倍、训练任务提交频率增长了 60%。但基础设施不会因为需求增长而自动变强。资源和需求之间的裂缝只能靠新能力去填。以下是七月实际落地到平台上的能力增量按生产影响排序而非功能炫酷程度排序。二、能力全貌七项平台增量的一体化视角七月的平台能力增量覆盖了调度、服务质量、成本管控三个核心维度彼此之间存在强依赖关系。以下是整体架构七项能力中GPU 分时复用和自适应批处理对生产可用性的影响最大下面重点拆解这两项。2.1 GPU 分时复用调度器让一张卡被多个推理服务共享在七月之前GPU 节点的分配策略是粗粒度的独占模式——一个推理服务即使只用 30% 显存也会占满整张卡。随着模型数量增长GPU 利用率长期徘徊在 25%-35% 之间。七月初上线的分时复用调度器基于 MIGMulti-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_size32 的方案 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 分片粒度更细。基础设施不需要漂亮话但需要持续的能力交付。七月的数据证明了这一点每一个百分点的利用率提升背后都对应着实实在在的硬件成本省出来的钱。
)
