GPU集群调度：Volcano与YuniKorn

可视化演示

展示Volcano gang调度全Pod原子启动、YuniKorn队列公平分配多租户GPU池、三种调度器利用率对比，步进切换探索。

调度背景

想象一家主打满汉全席的餐厅——豪庭餐厅。灶台不多，每桌宴席却要同时使用 3 到 8 个灶口才能开火；餐厅原本只有一个服务员，他一次只能端一道菜。于是常常出现这种局面：一道菜占用着灶台，另外几道菜却因为灶口不够迟迟无法下锅，整桌客人只能干等。这是分布式深度学习训练的真实写照：GPU 是金贵的灶台，一个训练任务往往要拆成几十个 Pod（菜），只有所有 Pod 都领到 GPU，任务才能真正开始算。

Kubernetes 原生调度器就像那个端菜的服务员，它只认识单个 Pod，不具备“整桌上菜”的全局视野。当任务需要 8 个 GPU，而集群只剩 6 个时，它先调度 6 个，剩下 2 个 Pod 无限 Pending；那 6 个 Pod 虽然占着 GPU，却因为没凑齐而不能执行——这就是著名的“死锁”与资源碎片化。深度学习任务的资源画像很特殊：多卡同步训练需要组内所有 Pod 同时启动；训练时长通常以小时计，一旦被“卡死”，GPU 空转成本极高。理想情况下，训练耗时 T 与总计算量 Q 和并行算力 N×S 的关系是：

回到餐厅：要解决半桌菜的尴尬，必须有一位懂宴席的调度总控。GPU 集群调度器的任务，就是把零散的 Pod 组合成“一桌菜”来统一安排，这正是我们接下来要认识的调度官。

Volcano调度器

Volcano 先生是豪庭餐厅的“包席经理”。他接手后，立刻引入了一套新规矩：顾客下单时，不再一盘一盘算，而是把整桌菜登记成一份“宴席单”（Job），每道菜安排一个编号（Task），这些菜要凑成一个“菜组”（PodGroup）。

Volcano 是 Kubernetes 生态中的开源批量调度器，运行时会监听 PodGroup、Queue、Job 等 CRD。它的核心本领是 Gang scheduling：一个 PodGroup 里的所有 Pod 必须全部满足资源条件，调度器才允许它们同时被绑定；有任何一道菜没着落，整桌菜都按兵不动。这与默认调度器的“逐个试错”形成鲜明对比。

Volcano 也提供队列（Queue）模型来承载资源配额。每个任务属于一个队列，队列可以配置 capacity 和 share，用于控制团队之间的资源边界；同时通过插件机制支持优先级抢占、拓扑感知等功能。这套设计让 AI 平台能够把训练任务作为整体管理，而不是只盯着单个容器。

举个例子，一个分布式训练作业有 4 个 worker 和 2 个 PS，如果集群只剩 3 张 GPU，Volcano 会让整个作业一致等待；一旦凑齐 6 张卡，6 个 Pod 像宴席上的菜一样同时上桌，杜绝了半桌菜占灶台的现象。豪庭餐厅也终于能招待那些讲究“同进同出”的大客户了。

YuniKorn调度器

与包席经理不同，YuniKorn 小姐更像餐厅的“公平叫号总台”。散客大厅里顾客身份复杂：有大客户、普通食客、临时访客，大家都想用灶台，但灶台有限。她的职责不是等一桌菜齐，而是让所有顾客都能按规则公平地排到位子。

Apache YuniKorn 起家于 YARN 调度器，专为 Kubernetes 多租户场景设计。它最著名的能力是层级队列管理——租户可以建根队列，下面再挂子队列，像餐厅的大厅、包厢、VIP 区层层划分。调度时采用 Weighted Max-Min Fairness（加权最大最小公平）：先给每个队列计算应得份额。

在此基础上，YuniKorn 还支持优先级抢占和弹性配额：队列空闲时，可以把 GPU 临时借给其他队列；当原租户任务回来时，再通过抢占回收，形成“高水位借用、低水位保障”的机制。这让多个团队共享一个 GPU 池时，既能互相救急，也不会被某一个大户永久占领。

包席经理管团队上桌，公平叫号台管客人排队——YuniKorn 的答卷，正是给多租户餐厅一份“大家都满意”的调度策略。

对比分析

包席经理和公平叫号员各怀绝技，但餐厅老板最关心的是：到底该用谁？先看队列模型：Volcano 的关注点是任务，队列只是资源容器，结构相对扁平；YuniKorn 的立身之本就是多层级队列，可以严格表达“部门—项目—子任务”的评级体系。

再看 Gang 调度：Volcano 原生支持 PodGroup，是分布式训练的事实标准；YuniKorn 最初面向 YARN 的 MapReduce 场景，虽然后续版本也通过插件支持 Gang，但社区心智更偏向队列公平与抢占。公平分配策略也有差别：Volcano 主要通过队列容量和任务优先级竞争，YuniKorn 则按权重做 Max-Min 公平，并设计了抢占与弹性回收。

因此现实项目中常有三种姿势：单团队重训练任务，用 Volcano 一马当先；跨部门多租户治理，选 YuniKorn 做总调度；大型 AI 平台则把两者组合——Volcano 负责 PodGroup 级别的 Gang 调度，YuniKorn 负责多队列间的公平分配，各管一段。

这就像餐厅并设“包席部”和“散客叫号台”：整桌宴席找包席经理，散客排队找叫号员。两者不打架，反而让整个餐厅的灶台运转得更顺畅。

多租户优化

多租户 GPU 资源池，就像大餐厅把灶台分给不同顾客群体：有些是长期包席，有些是散客，有些是临时访客。如果每个群体都独占部分灶台，高峰时有人排队、低峰时空转一片；如果没有边界，大客户一来就把灶台全占走。

YuniKorn 的弹性配额是化解矛盾的关键：给每个租户设一个“最低保障”，在此之上允许共享空闲 GPU。这样某团队跑大批量训练时，可以借用其他队列的空闲卡；当原租户提交任务后，调度器再通过抢占把卡还回去，既保证公平，又提高利用率。Volcano 则可以在任务层面用 binpacking（紧密打包）和节点亲和把 Pod 集中到同一批 GPU 节点，减少跨节点碎片；再配合队列 capacity 的限制，避免单个租户无限膨胀。

实践中，平台通常用两把尺子评估效果：GPU 平均利用率和任务排队等待时间。引入弹性共享后，原本某部门夜间闲置的 30% 资源可以被其他团队利用；同时通过 PodGroup 排队机制，高峰期的任务也不会把集群资源占满而饿死小任务。

豪庭餐厅的灶台因此从“包间私有”走向“闲时共享、忙时归还”，客人更多了，翻台率也上去了。

生产实战

餐厅运营数周后，老板决定复盘：调度官们如何上岗，出了问题又怎么排查？部署阶段，Volcano 通常以 Helm 或 DaemonSet 方式安装一到两个 scheduler 实例，配置默认调度器为 volcano；YuniKorn 则通过 admission controller 拦截 Pod 创建，并把队列配置写入 ConfigMap。二者都能以 CRD 方式暴露队列和任务状态。

故障排查时，最常见的信号是任务一直 Pending。首先看队列残余容量是否足够；其次，用 kubectl get podgroup 看 PodGroup 是否满员；如果部分 Pod 显示 Running 但主进程迟迟不启动，多半是 Gang 条件未满足或 PS/worker 角色互相等待。YuniKorn 场景下，还要查队列状态与抢占事件。

某互联网公司 AI 平台复盘：训练集群有 40 台 A100 节点，早期用 K8s 默认调度器，Ray 任务频繁因部分 Pod 阻塞而超时；切换到 Volcano 后分布式训练任务的排队时间下降约 40%，同一集群支持的任务并发数提升 50%。随后接入 YuniKorn 做部门级队列治理，GPU 平均利用率从 45% 提升到 70% 以上。

选型上，没有银弹：优先看业务形态是“整桌宴席”还是“散客排队”，再用两个调度器的组合拳完成最终方案。豪庭餐厅的复盘结论很直接：好的调度，是让每一口灶台都在最需要它的时刻烧起来。

AI 应用场景

Python 演示

#!/usr/bin/env python# -*- coding: utf-8 -*-"""GPU scheduler demo for gang scheduling and fair queue allocation."""from collections import deque  class GangScheduler:    def __init__(self, gpu_total):        self.gpu_total = gpu_total        self.pending = deque()        self.running = []     def submit(self, group_id, pod_count):        self.pending.append({"id": group_id, "pods": pod_count})     def tick(self):        allocated = 0        keep = deque()        for job in self.pending:            need = job["pods"]            if allocated + need <= self.gpu_total:                allocated += need                self.running.append(job)            else:                keep.append(job)        self.pending = keep     def show(self):        print("running:", [job["id"] for job in self.running])        print("pending:", [job["id"] for job in self.pending])  class FairShareScheduler:    def __init__(self, queues, total_gpus):        self.queues = queues        self.total_gpus = total_gpus     def allocate(self):        total_weight = sum(queue["weight"] for queue in self.queues)        result = {}        for queue in self.queues:            share = self.total_gpus * queue["weight"] / total_weight            result[queue["name"]] = min(share, queue["demand"])        return result  if __name__ == "__main__":    print("== Gang scheduling ==")    gang_scheduler = GangScheduler(8)    gang_scheduler.submit("job-a", 4)    gang_scheduler.submit("job-b", 3)    gang_scheduler.submit("job-c", 2)    gang_scheduler.tick()    gang_scheduler.show()     print("== Weighted fair queue ==")    queues = [        {"name": "cv", "weight": 2, "demand": 4},        {"name": "nlp", "weight": 1, "demand": 3},        {"name": "rec", "weight": 1, "demand": 2},    ]    fair_scheduler = FairShareScheduler(queues, 8)    result = fair_scheduler.allocate()    for name, share in result.items():        print(f"{name}: {share:.2f} GPU")

1. if allocated + need <= self.gpu_total:只有整个任务组的资源需求在当前轮次都被满足时才分配，体现 Gang 调度的精髓。
2. self.pending = keep没有被分配的任务不丢弃，继续留在队列中等待下一轮调度。
3. total_weight = sum(queue["weight"] for queue in self.queues)计算所有队列的权重总和，用来把权重归一化。
4. share = self.total_gpus * queue["weight"] / total_weight按权重占比切分 GPU 总量，计算每个队列的理论份额。
5. result[queue["name"]] = min(share, queue["demand"])实际分配不能超过队列需求，避免分配用不掉的资源。
6. gang_scheduler.tick()触发一轮 Gang 调度，观察任务是否整组启动或继续等待。
7. fair_scheduler.allocate()触发一轮加权公平分配，观察不同权重队列获得的 GPU 数量。

常见误区

面试题