近万张异构卡统一调度，招行算力利用率从35%拉到60%

近万张异构算力卡，99%的加速算力资源纳入统一管理，平均算力利用率从35%提升到60%以上。这是招商银行训推一体云原生平台交出的成绩单。

2026年9月，这套平台获得CNCF参考架构奖，同时成为CNCF最终用户案例大赛获奖案例。两项认可分别对应它的生产结果与架构方法。

招商银行AI基础设施架构师谭培祥在采访中强调，平台在Kubernetes上统一资源治理、调度、数据通道和监控，训练与推理则分别采用符合负载特征的运行方式。

训练和推理，为什么不能各建各的

招商银行的大模型应用已经进入风险控制、智能客服和研发提效等生产场景。随着负载规模增长，平台的核心问题从算力供给转向利用效率：异构设备能否在不同负载之间得到持续、有效利用。

训练任务运行时间长且强调吞吐，分布式作业往往需要数十到数百张卡同时到位。在线推理对时延敏感，容量必须随业务流量快速变化。

如果为训练和推理分别按峰值建设资源池，一侧闲置时，另一侧也难以使用这部分容量。如果再按硬件厂商的软件栈拆分集群，还会带来更多资源碎片，并增加运维和适配成本。

招商银行因此选择建设统一底座：训练和推理共享资源治理、调度、数据通道和监控体系，同时采用符合各自负载特征的运行策略。

四项选型原则，划定了架构边界

第一，统一资源池。Kubernetes提供统一控制面和标准资源接口，将NVIDIA GPU与多种国产加速卡纳入同一治理体系。

第二，底座共享、策略分化。训练使用队列、配额和整批准入，在线推理依据实时流量与排队情况弹性伸缩。

第三，优先采用开放、可替换且经过生产验证的技术，降低对单一硬件和封闭软件栈的依赖。

第四，自研只补充开源生态尚未覆盖的业务和算法能力，不重复建设通用基础设施。

基于上述原则，Kubernetes、KEDA、Prometheus、HAMi和Fluid提供CNCF托管的基础能力。Kueue作为Kubernetes SIG Scheduling项目负责批作业准入，Ray提供分布式执行，RBG负责多角色推理编排，vLLM和SGLang提供推理引擎。

招商银行自研训练框架Twinkle，并发起开源项目verl-SpeCo，分别解决训练工程化、基础模型复用和强化学习Rollout加速问题。各组件在统一控制面下分工，并可按需要替换。

训练侧：配额、设备、数据三道关

训练作业首先经过Kueue的配额准入。Ray Head和全部Worker被视为一个Workload，只有整批PodSet的配额能够同时预留，作业才会进入调度；条件不足时继续排队，避免部分Worker已经占卡、其余Worker长期Pending。

ClusterQueue和Cohort还允许不同队列按规则借用空闲配额，使训练与推理能够错峰复用资源。

通过准入后，Kubernetes Scheduler与HAMi负责Pod放置、设备选择和资源分配。HAMi将异构加速卡纳入统一资源描述，可按显存和计算比例进行细粒度分配，并结合设备模组和网络拓扑改善分布式任务的放置。

其职责与Kueue不重叠：Kueue判断作业何时具备完整配额，Scheduler与HAMi负责配额获批后的物理放置和设备隔离。

完成设备分配后，任务还需要等待数据就绪。Fluid通过Dataset与Runtime抽象，把数据集、模型权重和checkpoint交付到计算侧缓存。训练Worker可就近读取热数据，在线推理也能在扩容前预热模型权重。

数百个实例并发启动时，分布式缓存优先承接高并发、小块读取，减轻底层对象存储的访问压力。因此，作业启动依次受配额、设备和数据就绪状态约束。

一个基础模型实例，五个租户共用

资源交付之外，训练侧还需要复用执行流程。Ray提供跨节点执行能力。Twinkle在其上组织训练，将Dataset、Template、Sampler、Reward、Loss、Kernel等环节拆分为25个以上可替换的原子组件。

全量训练、LoRA微调和强化学习可以复用作业提交、资源分配、数据访问和checkpoint管理机制，算法团队只需替换发生变化的环节。

在LoRA微调中，Twinkle让多个租户共享同一个基础模型实例，适配器、配置和训练状态则分别保存。CNCF公布的生产结果显示，默认五个LoRA租户共享一个基础模型实例后，该配置下的加速卡资源使用量下降80%，训练密度提升五倍。

把草稿模型训练塞进强化学习闭环

在强化学习训练中，Rollout往往占据大量时间。PPO、GRPO等算法持续更新目标模型，离线训练的静态草稿模型会逐渐偏离新的目标分布，投机解码的平均接受长度和加速收益随之下降。

招商银行研发团队因此发起开源项目verl-SpeCo，把草稿模型训练纳入强化学习闭环。vLLM或SGLang在Rollout中采集目标模型的隐藏特征与Top-K概率，训练侧持续更新草稿模型，再通过热更新把新权重送回推理引擎。

verl-SpeCo将特征采集、草稿模型训练、词表适配和权重发布与底层调度解耦，支持EAGLE3、DFlash等投机解码算法。

公开性能预览显示，Qwen3-8B使用EAGLE3和vLLM-Ascend/NPU运行100步时，Rollout比基线快约20%，端到端训练快约11%，未观察到精度回退。

推理扩容：角色组而不是等价副本

推理弹性由业务指标驱动。Prometheus采集等待请求数、队列深度、QPS和时延，KEDA根据vLLM或SGLang的实际负载计算期望副本数。扩容请求随后进入Kubernetes调度与HAMi设备分配，Fluid提供已经缓存的模型权重。只有角色、设备和模型数据全部就绪，新实例才接入业务流量。

在Prefill与Decode分离及大规模Expert Parallelism场景中，扩容对象不再是等价副本，而是Router、Prefill、Decode等相互依赖的角色组。这一侧的架构选型参考了阿里云ACK参与开源的AI Serving Stack参考架构与生产实践。

平台在扩容链中使用RBG，以RoleBasedGroup对象表达角色、实例和Pod的关系。角色依赖决定启动顺序，ScalingAdapter将角色状态接入外部弹性控制，CoordinatedPolicy协调多角色扩缩容和滚动升级，避免角色比例失衡或留下不完整实例组。

在hostNetwork和RDMA环境中，RBG还通过动态端口分配、拓扑配置注入和组件级服务发现处理端口冲突与跨角色寻址，使扩容后的角色实例具备调度、发现和流量接入条件。

每百万Token推理成本降了六成

统一控制面提高资源纳管覆盖，配额治理、错峰弹性和细粒度分配改善算力利用率，数据预热与按需扩缩容降低推理单位成本，Twinkle的基础模型复用提高训练密度。

这些结果对应一组技术机制，而非某个组件的单独贡献。平台在近万张异构加速卡的规模上完成验证，每百万输入与输出Token的推理成本下降60%以上。

CNCF最终用户案例大赛关注云原生技术在生产环境中的实际成效，参考架构评选则强调技术决策、组件边界和方法的可复用性。

同时运行训练和推理，并承担数据合规要求的企业，可以分阶段实施这一路径。先建立统一资源治理和训练准入，再改善设备分配与数据等待，随后建设由业务指标驱动的弹性推理；强化学习规模扩大后，再将投机解码协同训练纳入执行闭环。

各组件可按实际瓶颈逐步引入，但共享底座和职责边界需要在设计初期明确。

下一阶段，招商银行将基于该参考架构持续演进，进一步提升异构算力资源的利用率和整体运行效率。围绕训练、推理及多租户混部等场景，平台将完善更加精细、灵活和智能的调度策略。

通过加强算力、数据、模型与运行时之间的协同，持续提升平台对不同模型规模和业务负载的适配能力。在实践积累的基础上，进一步沉淀可复用的设计原则、组件组合和实施经验，形成具有行业通用性的训推一体架构模板。