招商银行统一近万张AI加速卡：利用率从35%提至60%+、每百万Token推理成本降低60%

9 月 8 日，在上海举行的 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 大会期间，招商银行凭借其 AI 基础设施实践，获得 CNCF 最终用户案例研究大赛冠军。

相比“获奖”本身，这个案例更值得关注的是招商银行对 AI 算力基础设施的一次系统性改造：通过 Kubernetes 以及 Kueue、KEDA、Prometheus、HAMi、Fluid 等组件，招商银行建立了一套统一控制平面，让模型训练、微调和在线推理共享近 10000 张异构加速卡。

目前，招商银行已经将 99% 的加速计算资源纳入这套统一框架。按照其公布的数据，近 10000 张加速卡的平均利用率从 35% 提升至 60% 以上；在模型和服务条件相同的情况下，每处理 100 万 Token（包含输入和输出）的推理成本下降超过 60%。

训练和推理开始抢同一批卡

随着 AI 进入更多金融业务场景，招商银行遇到的问题并不只是“缺算力”，而是不同类型的 AI 工作负载开始争抢同一套资源。

其中，分布式训练通常要求稳定、连续且可预测的计算资源。如果部分 Worker 或加速卡还没有准备就绪，已经被提前分配的资源就可能处于空闲状态。

在线推理则完全不同。它面对的是不断变化的业务请求，负载可能在短时间内迅速增加，也可能长时间保持低位，因此更依赖快速弹性扩缩容。

除此之外，LoRA 等多租户微调任务也开始大量占用基础模型和加速卡资源。

如果这些工作负载分别建设独立资源池，很容易出现一边资源紧张、一边 GPU 闲置的情况；但如果简单地把所有资源混在一起，又会带来任务抢占、调度冲突和服务稳定性问题。

招商银行的做法，是共享底层资源池，但为训练和推理保留不同的运行与调度机制。

Kueue、KEDA 和 HAMi 如何组合起来

在这套架构中，Kubernetes 充当统一资源底座，不同项目分别负责不同环节。

• Kueue 负责训练任务的准入、队列和配额管理。对于需要多张加速卡共同执行的训练任务，Kueue 可以避免资源尚未全部就绪时就提前启动任务，从而减少部分 GPU 已分配但实际无法开始计算的情况。

• 在线推理则采用 KEDA 与 Prometheus 的组合。Prometheus 持续采集服务负载等运行指标，KEDA 根据实时业务信号动态调整推理实例规模，使计算资源能够随请求量变化进行扩缩容。

• HAMi 被用于训练和推理工作负载之间更细粒度地分配异构加速计算资源，解决单张 GPU 或其他加速器难以被充分利用的问题。

• Fluid 则主要处理数据侧瓶颈，加速训练数据集、模型权重以及 Checkpoint 的访问，尽量减少加速卡等待数据加载的时间。

这几部分组合起来之后，招商银行希望解决的核心问题是：尽可能减少加速卡因为等待任务、等待数据或资源碎片而产生的空闲时间。

招商银行 AI 基础设施架构师 PeiXiang Tan 表示，基于统一云原生底座，平台已经将异构计算资源池化、训练任务调度、推理弹性伸缩、数据与模型加速访问以及端到端可观测能力整合在一起，使训练和推理能够采用不同的运行路径，同时共享底层资源。

5 个 LoRA 租户共享一个基础模型

在多租户微调场景中，招商银行还通过自主研发的 Twinkle 训练框架进一步压缩资源开销。

通常情况下，如果 5 个租户分别进行 LoRA 微调，每个任务可能都需要加载一份完整的基础模型。尽管真正需要训练的 LoRA 参数规模并不大，但基础模型副本本身仍然会占用大量显存。

Twinkle 默认允许 5 个 LoRA 租户共享同一个基础模型实例。按照招商银行公布的数据，这相当于把基础模型副本从 5 份减少到 1 份，在对应场景下可以将加速器资源消耗降低 80%，同时把训练密度提高 5 倍。

这也是当前 AI Infra 中一个越来越常见的问题：当企业内部开始出现大量微调任务之后，真正消耗 GPU 的往往不只是模型计算本身，还包括大量重复加载的模型权重和被切碎的显存资源。

从 GPU 利用率走向单位 Token 成本

招商银行此前已经多次公开其云原生 AI 基础设施实践。在此前的一项 CNCF 案例中，其基于 Kubernetes 和 HAMi 构建调度平台，并通过拓扑感知调度提升硬件资源利用效率，使分布式训练工作负载的跨机器调度减少 30%。

此次公布的新架构则进一步把优化目标从单纯提高 GPU 利用率，扩展到了训练、推理和多租户任务之间的统一资源管理。

按照后续规划，招商银行还准备继续推进动态调整多租户训练并发度，并将资源利用率、任务队列状态和延迟指标结合起来，建立面向“单位成本”的容量管理机制。

在推理侧，其计划继续扩展 KEDA，使部分推理服务能够采用更接近 Serverless 的运行模式，在没有请求时缩容至零；同时继续扩展 HAMi 对更多异构加速器以及训练、推理后端的支持。

这些都反映出企业 AI 基础设施正在发生的一个变化：在大模型部署初期，很多企业首先关心的是“有没有 GPU”；但当 GPU 规模进入数千甚至上万张之后，问题开始变成这些卡究竟有没有被持续有效地利用，以及每一次训练、每 100 万 Token 推理究竟要花多少钱。

从这个角度看，招商银行此次案例的价值并不只在于把 Kubernetes 用到了 AI 场景，而在于把训练队列、在线推理、异构资源切分、数据加载和多租户微调放进了同一个资源效率问题里。对于已经开始大规模部署 AI 的企业来说，下一阶段 AI Infra 的竞争，越来越可能从“拥有多少算力”，转向“同样一批算力能产出多少有效计算”。