AI热榜 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 闲置的情况；但如果简单地把所有资源混在一起，又会带来任务抢占、调度冲突和服务稳定性问题。
招商银行的做法，是共享底层资源池，但为训练和推理保留不同的运行与调度机制。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接