华为云CCE VolcanoNext调度引擎深度解析：从Gang调度到DRA队列配额的通智一体化实践

2026年，AI基础设施的调度范式正在经历一次根本性重构。传统Kubernetes调度器kube-scheduler的设计假设是微服务和长期运行的批处理作业——任务生命周期长、资源需求稳定、调度延迟容忍度高。但Agentic AI和万亿级Token推理的到来，让集群中同时运行着三类特征迥异的工作负载：训练作业需要独占数百张NPU卡并保持数小时的稳定运行；推理服务需要毫秒级的弹性伸缩和KV Cache感知的路由；Agent任务则可能在一秒内发起数十次工具调用，每次调用的执行环境生命周期只有几百毫秒。

让这三类负载共用一套调度逻辑，结果要么是调度器成为瓶颈，要么是训练作业被频繁打断。华为云CCE VolcanoNext给出的解法，是在开源Volcano的基础上构建一个通智一体化调度引擎，通过“训推共池+碎片整合”实现异构算力的统一调度。本文将从多调度器架构、Gang粒度抢占、DRA队列配额和碎片整理四个层面，解析VolcanoNext的技术原理。

一、多调度器架构与动态节点分片
Volcano v1.14引入了动态节点分片机制，这是VolcanoNext实现通智一体化调度的架构基础。

传统方案中，集群通常只运行一个调度器实例，所有Pod的调度请求都经过同一个调度队列。当Agent任务以每秒数百次的频率创建和销毁Pod时，这些短生命周期请求会挤占训练作业的调度资源，导致训练Pod的调度延迟从毫秒级恶化到秒级。

VolcanoNext的解法是引入Sharding Controller，基于实时集群状态为每个调度器动态计算候选节点池。集群中的节点被划分为不同的“分片”，分别服务于Batch Scheduler（处理训练作业）和Agent Scheduler（处理推理和Agent任务）。当某类任务的负载下降时，分片比例可以动态调整，实现资源的弹性复用。

Agent Scheduler采用多Worker并行调度架构，多个调度Worker同时处理调度请求，配合乐观并发控制减少锁竞争。训练作业的规模化运行和Agent任务的快速响应因此可以在同一集群中共存。

二、Gang粒度抢占：从Pod级到作业级的原子调度
Gang调度是分布式训练场景的核心机制——它要求一组Pod要么全部调度成功，要么全部不调度。如果分布式训练的8个Worker Pod中有3个因为资源不足无法调度，剩余5个即使调度成功也无法开始训练，反而白白占用资源。

Volcano v1.15.0在Gang调度上做了一个关键增强：Gang粒度抢占。此前的抢占机制以Pod为单位——当高优先级作业需要资源时，调度器逐个驱逐低优先级Pod，直到释放出足够资源。这种Pod级抢占在Gang场景下存在一个问题：如果低优先级作业是Gang调度的，驱逐其中几个Pod会导致整个作业失败，即使被驱逐的Pod数量远少于该作业的总Pod数。

Gang粒度抢占将抢占决策的原子性从Pod提升到PodGroup。调度器评估资源缺口时，以整个PodGroup为单位判断——只有当某个低优先级PodGroup的全部Pod都被驱逐后释放的资源足以满足高优先级作业的需求时，才执行抢占。否则，调度器会寻找另一个更低优先级的PodGroup作为抢占目标。

这一机制避免了Pod级抢占的“半驱逐”问题——低优先级作业要么完整保留，要么完整被抢占，不会出现被驱逐一半导致训练中断的情况。

三、DRA队列配额：异构资源的精细化管理
Kubernetes 1.34将DRA（Dynamic Resource Allocation） 推向了稳定阶段，这为GPU/NPU的精细化调度打开了新的可能性。DRA允许将加速器资源（如GPU、NPU、FPGA）以更细的粒度暴露给调度器——不再只是“一张卡”或“一个设备”，而是可以声明具体的设备属性，例如显存容量、互联拓扑、甚至特定的芯片型号。

Volcano v1.15.0在capacity插件中引入了DRA队列配额，将DRA资源纳入多租户队列管理框架。这意味着：

一个团队在Volcano队列中申请的不再只是“N张NPU卡”，而是可以声明“M张具备NVLink互联的昇腾卡，每张卡至少64GB显存”。队列配额管理器根据这些声明在DRA资源池中进行匹配和分配，确保跨队列的资源竞争不会导致某个队列的DRA声明无法满足。

对于Agentic Infra场景，DRA队列配额的意义在于训推共池的资源隔离。训练队列可能声明“独占的、互联拓扑最优的NPU设备”，而推理队列声明“显存带宽优先的NPU设备”。DRA让这些差异化需求可以被精确表达和调度，而不是在同一个粗粒度的“GPU资源池”中竞争。

四、碎片整理：从“资源够但放不下”到“精准装箱”
大规模NPU集群运行一段时间后，一个常见的问题是资源碎片化。假设集群有100个节点，每个节点有8张NPU卡。经过数轮训练作业的创建和销毁后，可能出现每个节点都剩余3到4张空闲卡的情况——总空闲卡数不少（例如300张），但没有一个节点能容纳一个需要8张卡的完整训练作业。

VolcanoNext的碎片整理能力通过Binpack策略与负载感知调度的协同来解决这个问题。Binpack调度算法为满足调度条件的节点打分，节点的资源利用率越高得分越高。这意味着调度器优先将Pod调度到已经比较“满”的节点上，而不是均匀分散。配合负载感知重调度（Descheduler），系统会定期评估集群的资源碎片状态，将分散在多个节点上的Pod迁移到少数节点，释放出完整的节点资源。

碎片整理策略与Gang调度配合使用时有一个关键约束：重调度器不能随意驱逐Gang作业中的Pod，因为驱逐任何一个Pod都会导致整个作业重启。因此，碎片整理只针对那些已经完成或处于稳定运行状态的作业执行，且迁移决策需要评估作业的检查点成本和重启代价。

五、CloudMatrix384：调度引擎的硬件底座
VolcanoNext的调度能力最终运行在CloudMatrix384超节点之上。该超节点将384颗昇腾NPU和192颗鲲鹏通用计算芯片通过MatrixLink网络对等全互联，基于灵衢总线实现全局共享内存，不同节点上的NPU可以像访问本地内存一样访问远端内存，延迟达到微秒级别。

这一硬件特性对调度器有直接的影响。传统集群中，调度器需要感知网络拓扑（如NUMA节点、交换机层级），尽量将通信密集的Pod调度到拓扑邻近的节点上。而在CloudMatrix384中，由于所有NPU之间都是对等全互联，拓扑感知的复杂度大幅降低——调度器不需要在“邻近”和“远端”之间做复杂的权衡，所有节点之间的通信延迟差异被压缩到了一个很窄的范围内。

这带来的工程收益是调度决策的简化。VolcanoNext可以将更多调度权重分配给资源利用率和Gang原子性，而不是网络拓扑感知。CloudMatrix384的“一切皆对等”架构，某种程度上让调度器从拓扑约束中解放出来。

六、性能数据与总结
Volcano v1.14的性能数据验证了这套架构的效果：调度吞吐达到950 Pod/s，P99延迟45ms，GPU利用率从35%提升至72%，任务调度成功率从42%提升至98%。CCE VolcanoNext通过“训推共池+碎片整合”，将资源利用率进一步提升30%以上。

从kube-scheduler的单调度器架构，到VolcanoNext的多调度器动态分片、Gang粒度抢占、DRA队列配额和碎片整理，Kubernetes的调度能力正在从“能用”走向“通智一体”。对于正在规划AI基础设施的团队而言，理解这些调度机制的设计逻辑，比单纯关注NPU卡的数量更重要——在万卡集群中，调度效率的1%提升，可能意味着数百万的算力成本节约。