CNCF 终端用户案例怎样提升 GPU 利用率

我整理 CNCF 终端用户案例时，最容易被“GPU 利用率提升”这句话带偏：它并不等于把某个参数调大，也不等于单独换一个调度器。CNCF 公开的中国招商银行案例给出的答案更像一套云架构组合：把训练、推理和多租户微调放进同一套 Kubernetes 控制面，同时保留各自的运行策略。

官方资料入口：https://www.cncf.io/case-studies/china-merchants-bank-2/

GPU 利用率上升的关键，不是让所有任务使用同一种策略，而是把准入、弹性、细粒度分配、数据访问和运行时复用分别做好，再用同一组指标衡量结果。

先看案例到底解决了什么问题

这份 CNCF 案例描述的是近 1 万张异构加速卡上的企业 AI 平台。训练任务通常持续时间长、需要成组资源同时就绪；在线推理则跟着流量变化，更看重延迟；LoRA 微调还要处理多个租户共享同一个基础模型的问题。三种负载都使用加速卡，却不能用同一套调度和扩缩容规则。

案例公布的结果是：平均加速器计算利用率从 35% 提升到 60% 以上，比较条件相近时每百万 token 的推理成本下降 60% 以上；默认五个 LoRA 租户共享一个基础模型实例，训练密度提升到原来的五倍，基础模型副本从五份降为一份。这里的“60% 以上”和“五倍”都是官方案例的内部口径，不应直接当作其他集群的保证值。

业务负载：训练、推理和微调先分开看

我觉得这类案例最值得借鉴的地方，是先把负载差异写清楚，再谈组件。训练需要稳定、可预测的容量；如果一部分 Pod 先启动却等不到剩余 worker，已经分配的卡就会处于低效等待。推理面对的是突发请求，长期为峰值保留整卡又会产生空闲。多租户 LoRA 微调只改变少量适配参数，却很容易按租户重复加载完整基础模型。

约束条件：统一控制面，不统一所有策略

案例的架构可以拆成三层。第一层是 Kubernetes 统一控制面，负责 Pod、节点和基础资源编排。第二层是按负载拆开的运行时：训练侧使用 Twinkle 与 Ray，推理侧使用 vLLM 或 SGLang 与 Ray。第三层是共享能力，包括加速器节点池、对象或数据存储、模型仓库、缓存和 Prometheus 指标。

这个边界很重要：统一的是资源入口、数据路径和观测方式，不是把训练和推理强行塞进同一个伸缩策略。训练侧由 Kueue 做队列、配额和准入；推理侧由 Prometheus 提供实时信号，再由 KEDA 调整副本数。HAMi 负责把共享加速器容量切得更细，Fluid 缩短数据集、模型权重和 checkpoint 到计算侧的等待。

方案对比：为什么不能只加卡或只换调度器

只加卡只能扩大总容量，不能解决作业互相等待、推理低峰空置和模型重复加载。只换调度器也不够，因为调度完成后，数据还可能没有到位，推理副本还可能需要重新加载大模型。

更稳妥的方案是把浪费来源逐项对应：

• 提前占用：Kueue 让训练任务先经过队列和配额准入，减少 Pod 只拿到一部分资源却长时间等待。
• 整卡独占：HAMi 以更细粒度分配异构加速器，避免小型或波动型服务长期霸占完整卡。
• 低峰空闲：KEDA 根据 Prometheus 暴露的请求和延迟信号扩缩推理副本。
• 数据等待：Fluid 将数据集、权重和 checkpoint 的访问加速到靠近计算侧的位置。
• 基础模型重复：Twinkle 让多个 LoRA 租户复用一个基础模型实例，只隔离适配器、配置和状态。

推荐架构：共享资源层，解耦运行时

如果要把这个案例抽象成自己的评估图，可以先保留一个共享加速器池，再为训练和推理分别建立入口。训练入口进入 Kueue 的队列和配额，随后由 Kubernetes Scheduler 与 HAMi 选择节点和分配容量，Fluid 负责数据与 checkpoint 访问，最后交给 Twinkle 和 Ray。推理入口则从网关进入 vLLM 或 SGLang，Prometheus 采集 QPS、队列深度和延迟，KEDA 根据这些信号扩缩，HAMi 和 Fluid 继续复用底层资源与缓存。

这不是把所有组件都照单全收。真正的决策顺序应是：先确认两类负载是否确实共享硬件，再确认是否有队列碎片、整卡浪费、模型加载慢或基础模型重复的问题，最后才决定引入哪个能力。否则组件越多，运维边界反而越难解释。

风险点：指标提升不能简单归因给某一个组件

官方案例明确把结果放在“整条资源路径”的交互上理解：准入减少了碎片化占用，细粒度分配提高了共享程度，缓存减少了数据和模型等待，运行时复用又减少了基础模型副本。写复盘时，如果只把 35% 到 60% 以上归功于某一个项目，很容易得到错误的迁移结论。

还要区分三种指标。平均加速器计算利用率回答“硬件有多少时间在做有效计算”；每百万 token 成本回答“业务处理单位是否变便宜”；训练密度回答“同一个基础模型实例能支撑多少租户”。它们互相有关，但不是同一个指标。CNCF 案例也特别强调要保持改造前后的测量方法一致，并限定可比较的模型与服务条件。

落地清单：先做可比测量，再决定是否复用方案

1. 记录训练和推理的资源池范围、加速器型号、平均利用率、队列等待和副本启动时间。
2. 把训练、推理、微调的资源申请与扩缩容策略分开写，明确哪些能力必须共享，哪些策略必须隔离。
3. 验证队列准入是否能避免“先启动一部分 Pod、再等待剩余资源”的碎片。
4. 验证模型权重、数据集和 checkpoint 的访问延迟，单独记录缓存命中与未命中的差异。
5. 对 LoRA 场景记录基础模型副本数、适配器数量、并发租户数和显存压力，不能只看 GPU 百分比。
6. 用同一时间窗口复算利用率、每百万 token 成本和训练密度，避免把流量变化误判为架构收益。

我最后的判断是：CNCF 终端用户案例真正提供的不是一张可以照抄的产品清单，而是一种拆问题的方法。共享硬件、分开策略、缩短等待、减少重复，再把结果放回同一套测量口径里，才是 GPU 利用率提升能够持续的原因。

官方公告：https://www.cncf.io/announcements/2026/09/07/china-merchants-bank-wins-cncf-end-user-case-study-contest-for-unifying-ai-training-and-inference-on-kubernetes/

相关问题

GPU 利用率高就代表推理成本一定低吗？

不一定。还要结合每百万 token 成本、模型加载等待、延迟和服务质量；高利用率如果换来排队或延迟上升，不能算完整收益。

训练和推理必须使用同一套运行时吗？

不需要。案例的做法是共享 Kubernetes、加速器、数据和观测能力，但让训练与推理分别选择适合自己的运行时和控制策略。

中小团队能直接复刻近万张卡的架构吗？

不建议直接照搬规模。更合理的做法是先在一组异构节点上验证队列准入、细粒度分配、缓存和指标闭环，再按实际瓶颈逐项扩展。