招商银行基于 HAMi 在 Kubernetes 上优化 AI 算力调度
摘要
随着 AI 工作负载在模型训练、推理服务、研发和内部 AI 应用中全面铺开，招商银行需要一种更高效的方式来大规模管理多样化的加速器资源。借助 Kubernetes 和 HAMi，该行搭建了一个统一的 AI 算力调度平台，实现了异构资源池化、拓扑感知调度和细粒度加速卡共享。最终结果是：硬件利用率提升，分布式训练的通信开销下降，企业级 AI 工作负载有了更具扩展性的底座。
关于招商银行
招商银行是中国领先的商业银行之一，在云原生、AI 和数字基础设施上投入巨大。随着 AI 在越来越多金融场景中成为核心能力，该行需要运行种类繁多的训练、推理和内部 AI 工作负载，这对底层算力平台构成了实实在在的压力。
挑战
大模型训练、推理服务和各类 AI 应用正在快速扩张。对大多数大型机构而言，真正的瓶颈并不在于算力不足，而在于如何让既有资源高效协同。
招商银行恰好遇到了这个问题。该行此前搭建了一个异构算力平台，使用多种 AI 加速卡来支撑模型训练、在线推理、研发和内部 AI 工具。随着用量增长，原有的资源管理方式已经跟不上，于是该行在 Kubernetes 上基于 HAMi 重新搭建了统一调度平台，把异构资源管理、拓扑感知调度和细粒度共享整合到一处。
在企业级规模上搭建 AI 平台，归根结底是三个问题：
资源管理碎片化
不同 AI 加速器厂商各自交付自己的软件栈和管理工具。结果是：资源池相互割裂，调度策略彼此不一致，运维开销持续攀升。
训练硬件未充分利用
部分训练节点采用多芯片高速互联，任务放置对芯片的物理拓扑极为敏感。如果调度器不理解这套拓扑，任务就会被放到错误的芯片上，轻则性能受损，重则直接失败。
小任务的容量浪费
大量推理、微调和测试任务并不需要整张加速卡。但传统做法按整卡分配，留下了大量闲置容量。
为什么选择 HAMi
该行选择 HAMi 出于几个原因：
- Kubernetes 原生。 无需重构既有的云原生技术栈。
- 统一异构资源。 多种加速器类型共用一套调度框架。
- 支持细粒度共享。 显存和算力可以带配额地切分，把每张卡的效用压榨到极致。
- 开源且可扩展。 架构开放，能按真实业务需求进行调整。
解决方案
招商银行在 Kubernetes 和 HAMi 上搭建了统一 AI 算力平台，随后在资源纳管、共享调度和训练效率上持续迭代。
平台架构
平台分为三层：
- 业务服务层： 大规模模型训练、AI 推理服务、模型微调和内部 AI 应用。
- HAMi 调度层： 异构资源池化、拓扑感知调度、GPU/NPU 共享、多厂商设备抽象。
- 基础设施层： 多厂商 AI 加速卡、多节点集群、高速互联网络。
统一异构资源管理
HAMi 让该行能够把多种不同类型的加速卡汇入一个统一的 Kubernetes 资源池。在招商银行的环境里这一点尤为关键，因为平台包含种类繁多的异构算力资源，包括昆仑芯、多款昇腾型号、NVIDIA GPU、PPU、摩尔线程、MetaX 以及其他加速设备。如果没有 HAMi，每交付一批硬件通常都会伴随一个独立的 Kubernetes 集群，这可能让该行维护八个以上彼此独立的集群，每个集群都要各自维护一套 device plugin、调度策略、监控体系、运维流程和排障模型。
借助 HAMi，这些异构设备可以通过单一调度框架和一致的平台策略来管理。应用团队继续通过标准 Kubernetes 工作流申请资源，平台团队则把设备类型、厂商栈和资源分配模型之间的差异抽象掉。HAMi 的价值不止于设备切片和监控。该项目还提供厂商专属的最佳实践和示例工作负载，让该行能通过 HAMi 示例快速验证新纳管的设备，再投入生产使用。
拓扑感知调度：适配超算节点架构
部分训练节点采用超算节点（双芯片模组）架构，多颗芯片通过高速互联组成一个逻辑单元。Kubernetes 默认调度器不理解这种布局，于是带来了真问题：
- 奇数卡分配会出问题。 奇数张卡的分配可能跨越两个模组，触发驱动报错。
- 跨模组通信慢。 模组之间的通信延迟明显高于模组内部。
- 集群部分算力闲置。 错误的放置决策让一些硬件实际上无法使用。
该行增强了 HAMi 的 Device Plugin 和调度器，使其识别物理模组并强制成对分配。调度器现在理解模组拓扑，把卡保持在同一模组内，避免了奇数卡跨模组放置导致的驱动崩溃。硬件资源池利用率达到了 100%。
在 ResNet50 推理基准测试（batch size = 32）中，HAMi 的细粒度算力分区把单卡总吞吐量从 64.6 images/s 提升到 94.8 images/s。随着分区粒度加大，整体吞吐量最高提升 46.7%，说明工作负载密度更高、加速器利用更充分。
该行还改进了系统对多芯片高速互联节点的处理方式。系统现在理解芯片间的连接关系，并优先把训练任务放在通信路径最短的位置，让训练更稳定也更快。
细粒度共享：vNPU-Core 软件分区
推理、小模型微调和研发测试任务通常不需要整张卡。给这些工作负载分配整张卡会浪费大量容量。
该行使用 HAMi 的 VMPO Core 组件来做用户态算力分区。两个主要机制是：
- 令牌桶。 每个任务获得一个算力配额。超过配额的任务排队等待。
- 用户态显存管理。 GPU 显存分配在用户态完成，使细粒度分区成为可能。
分区粒度最细可达 1 GB 显存 / 1% 算力，并可按任务自由组合。这一点在银行业意义非凡。风控模型和客服模型往往体量很小，并不需要整张卡，细粒度分区让该行能在同一批硬件上跑多得多的这类模型。
对于推理、小模型训练和研发测试，该行还开启了卡共享，让多个任务可以共用单张加速卡。这使多个工作负载得以共享单张加速卡，降低了较小推理和测试工作负载的闲置容量。
网络拓扑：三层抽象与反打散
针对分布式训练，该行设计了一套多级拓扑感知调度算法，把物理网络视为三层：
- 第一层：同节点。 延迟最低，调度优先级最高。
- 第二层：同一 LEAF 交换机。 延迟中等，优先级中等。
- 第三层：跨 LEAF 交换机。 延迟最高，优先级最低。
调度器现在在打分阶段加入拓扑分数，优先把高通信任务放在同一节点或同一交换机域内。跨机调度下降了 30%，消除了分布式训练中的一大通信瓶颈。
该行还注意到，调度器有时会把同一作业的 Pod 打散到不同节点。为此，它引入了基于控制器 UID 的确定性哈希机制，把同一批次的 Pod 保持在同一节点上。
关键成果
这些改动为该行带来了如下收益：
| 指标 | 成果 |
|---|---|
| 硬件资源池利用率 | 100% |
| 跨机调度概率 | 下降 30% |
| 最细分区粒度 | 1 GB 显存 / 1% 算力 |
| 平台架构 | 统一的异构 AI 算力调度 |
这些改动让该行能够应对不断增长的 AI 工作负载，而不必持续采购更多硬件。
通过 HAMi，我们在 Kubernetes 上搭建了统一的异构 AI 算力调度平台，在资源利用率、训练效率和平台稳定性上取得了显著提升。
意义何在
招商银行的故事说明，AI 基础设施真正的竞争优势并不在于买更多硬件，而在于用软件把既有硬件的价值榨取出来。
对云原生世界而言，这对 Kubernetes 是一次有意义的进展。它不再仅仅是编排容器，而是正在成为企业 AI 基础设施的控制面。
像 HAMi 这样的开源项目，让企业在 Kubernetes 之上获得异构调度、共享和编排能力，从而更快地搭建 AI 平台，无需重复造轮子。
后续规划
该行计划持续演进其 AI 算力平台。重点方向包括：进一步优化昇腾 hami-vnpu-core 软件分区机制，降低多工作负载环境下的性能波动；构建针对虚拟化 NPU 的完整监控能力，提供显存和算力利用率的实时可见性。招商银行还计划继续作为 HAMi 开源社区的活跃贡献者，分享运维经验，推动异构 AI 基础设施技术向前发展。
总结
招商银行的实践表明，Kubernetes 和 HAMi 能够为企业级规模的异构 AI 基础设施管理提供统一底座。通过提升资源利用率、优化工作负载放置并启用细粒度资源共享，该行搭建了一个更高效、更具扩展性的平台，用以支撑组织内不断增长的 AI 项目。
本文改编自云原生计算基金会（CNCF）发布的招商银行 CNCF 案例研究。