正在加载，请稍候
近万张异构卡统一调度，平均利用率从 35% 提到 60%，每百万 Token 成本降超六成。拆解准入队列、推理弹性、卡级切分、数据加速四层机制与迁移门槛。
近 10000 张异构加速卡，平均利用率从 35% 拉到 60% 以上，同条件下每百万 Token 的推理成本下降超过 60%。这是招商银行在 KubeCon + CloudNativeCon China 2026（上海，9 月 8 日）分享的一组数字，也是一份典型的"存量算力回血"样本。
值得抄的不是某个组件，而是它承认了一个事实：训练、推理、微调三件事对资源的要求互相冲突，靠把池子切开是躲不掉的。
分池是最省事的选择，也是最贵的选择。
训练任务动辄跑几天到几周，最怕被抢占；在线推理的请求量随业务节奏上下浮动，最怕实例不够；LoRA 这类微调天然多租户——每个业务组都要一张卡跑自己的小任务，单任务吃不满整卡，但数量极多。三条负载放在三个池子里，任意时刻总有两个池子闲着。
混池是另一个极端。训练作业先占卡、后等 worker 就绪，几张卡被"预占"半小时不出活；推理实例被离线任务挤掉，P99 延迟直接上天。
大会现场的共识也指向同一件事：异构性回来了。InfoQ 对这场大会的现场报道提到，CNCF、OpenInfra 与 PyTorch 三个社区第一次同台，OpenInfra 基金会总经理 Thierry Carrez 的表述是"无基础设施，不 AI"。同一篇报道里还引了一个 Wikipedia 的观察：Agent 带来的页面访问约占 35%，却消耗了超过 60% 的资源密集型用量——负载形态变了，按人类访问路径设计的容量规划公式随之失效。
招行的做法可以拆成四层，每层只解决一个问题。
原生的容器编排缺少作业队列，不少团队的做法是让训练任务直接申请 Pod，于是卡被预占了、worker 还没就绪。这个组件扮演调度器之前的准入控制器，只管队列和配额，不替换核心组件。
它对外宣称的五个核心能力对多租户场景很关键：集群级配额跨团队共享、队列之间可动态借用闲置容量、按网络拓扑决定分布式大任务的落点、区分不同硬件资源池并支持优先级抢占、以及跨集群派发。其中"动态容量共享"是平均利用率从 35% 往上走的直接来源——A 业务的闲置配额被 B 业务借走，而不是躺在账上。机制细节可查 官方文档。
推理池最大的浪费是"按峰值常驻"。用监控系统抓业务侧指标（QPS、排队深度、显存水位），交给事件驱动的伸缩器决定副本数，低谷期释放出来的卡就能回流共享池。这一层不需要改模型，只需要把伸缩信号从 CPU/内存换成真正反映推理压力的业务指标。
LoRA 微调是典型的小任务多租户场景：每个任务吃不满整张卡，但也不允许被别的任务抢走。该项目提供加速器虚拟化与异构调度能力，把整卡按显存和算力切片分配，让多个任务共享一块物理卡。项目代码仓库的定位是面向 AI 基础设施的 GPU 虚拟化与异构加速器调度，Apache-2.0 协议，目前约 4.6k star、815 次 fork——生态成熟度已经不算低。
前三条都在解决"卡分给谁"，这一条解决"卡拿到之后有没有活干"。把数据集缓存到离计算更近的位置并做分布式加速，可以压缩训练与推理启动阶段的等待时间。这段时间里加速卡按秒计费但不产出，落在报表上就是利用率被拉低。
| 层次 | 解决的问题 | 关键机制 | 该看的指标 |
|---|---|---|---|
| 训练准入 | 作业预占卡、配额静态 | 准入队列、配额借用、优先级抢占 | 队列等待时长、配额借用率 |
| 推理弹性 | 实例按峰值常驻 | 业务指标驱动副本伸缩 | 副本数波动、单副本吞吐 |
| 卡级切分 | 小任务吃不满整卡 | 显存与算力细粒度分配 | 卡内切片数、碎片率 |
| 数据加速 | 算力等数据 | 数据集缓存与就近访问 | 数据加载耗时占比 |
把四个组件装上不等于省钱。这套方案成立的前提是覆盖面：招行把 99% 的加速资源纳入了统一框架，只在极少数高隔离要求的场景保留独立池。
三个数字值得记住：
第三个数字最容易被误读。它不是"换成更便宜的模型"省出来的，而是同一批卡跑出更多 Token 的结果——利用率提升不到一倍，成本却降了六成，差额来自峰值常驻被削掉、碎片被拼起来、数据等待被压缩这几块叠加。
一个横向参照：同一场大会上，PyTorch 基金会提到 vLLM 的贡献者数量过去一年增长超过 180%，AMD 结合该推理引擎在新硬件架构上不到 19 天把性能提升了 11 倍。软件栈本身的优化空间，往往比换一代芯片更早见效。
这套组合拳的门槛不在组件，在配套。
起步顺序建议这样排：先把推理池的伸缩信号从资源指标换成业务指标（收益最快、风险最低），再把训练作业改成准入制，然后引入卡级切分，最后才动数据加速层。
如果你们的推理负载是低频突发且延迟极度敏感，队列化会把排队时间直接变成 P99 抖动。这类业务留在独立池里反而更划算——多付的那点闲置成本，比一次超时事故便宜。共享池解决的是"平均利用率低"，不是"任何负载都该混着跑"。
加速卡租用或折旧、闲置浪费、数据加载等待，以及为峰值预留的冗余容量。前两项通常占比最大，所以提升利用率往往比换模型更早见效。
先做一件事：把推理服务的伸缩依据从 CPU/内存换成 QPS 或排队深度，并统计卡级利用率基线。基线不清楚，任何优化都无法验证，也无从判断是配置问题还是负载不足。
可以共享物理资源，但要保留不同调度机制。共享的是卡，不是策略——强行用一套队列同时管训练和在线推理，两边都会受损。
没有通用阈值。更实用的判断是同时看排队时长与碎片率：如果队列长期为空而卡长期占用，说明问题在准入或切分，而不在负载不足。
如果你的团队正在评估大模型推理成本治理的落地路径，蓝曜炬辉（www.lanyaoai.com）做过的基础设施类交付复盘可以作为一个参照，见案例库；也可以带着当前的卡级利用率数据直接来聊，见联系方式。更多云原生与 AI 工程内容在技术博客。