1. 从“排队十分钟”到“排队一百小时”调度器到底在排什么先说个真实场景。某次我盯一个千卡集群的扩容项目业务方跑一个70B模型的预训练任务需要的资源是512张A100。等我把节点加进Kubernetes集群、GPU驱动装好、RDMA网络调通之后以为万事大吉结果任务提交上去硬生生在队列里蹲了三个小时没动。排查了一圈不是显卡不够不是网络故障是调度器把任务卡住了。原因是这个任务申请的是整机资源而集群里当时剩余的“零散卡”数量足够却凑不出“整整齐齐”的512张调度器就这么干等着既不拆机也不抢占也不回填。那一刻我才真正意识到一个事在万卡集群里GPU是弹药调度器才是决定弹药能不能打出去的那个指挥官。训练框架决定模型怎么算调度器决定任务什么时候、在哪批卡上算算到一半挂了怎么恢复恢复之后抢谁的资源。整个训练场看着是GPU在发光发热暗地里全是调度器在排班。本篇文章就围绕这个“隐形老板”展开。我会把调度器面临的场景、核心机制、主流通用方案、集群层面的实操要点和坑一次性讲透。内容偏向基础设施侧适合做GPU集群运维、AI平台研发、算法团队里负责跑训练的同学也适合想把训练任务交付效率弄明白的人。先说结论调度器解决的不是“把GPU分出去”这种小学生问题而是在超大规模、多租户、异构资源、动态优先级、故障频发的环境下做全局最优的资源分配决策。复杂度全在这个“最优”二字上。2. 万卡集群的调度到底比单机复杂在哪2.1 单机只是“分配”集群才是“排班”单机场景下你用torch.cuda.set_device或者CUDA_VISIBLE_DEVICES指定一下跑哪张卡事情就结束了。多机场景就不一样了你面对的是几千台物理机、几万张卡、几十个业务团队、上百个同时在跑的训练任务。这里任何一个维度单拎出来都够喝一壶的时间维度任务是陆续提交的有长有短短的跑几分钟的debug任务长的跑几个月的预训练任务。资源怎么在时间轴上错峰复用空间维度任务对资源的需求不一样有要1张卡调bug的有要512张卡做模型并行的。卡与卡之间的网络拓扑NVLink、InfiniBand、RoCE直接影响任务性能分配的时候必须把“拓扑亲和”算进去。租户维度多个团队共享一个集群怎么保证A团队的大任务不会被B团队的小任务饿死怎么保证高峰期大家都有资源用怎么防止某个团队无限堆任务拖垮全局故障维度GPU卡也会坏训练任务跑几天挂掉是常态。挂了之后是重新排队还是预留资源重跑调度器上手慢了几百张卡空转一小时浪费的钱够买好几张卡。所以很多人把调度的复杂度等同于“排队算法好一点”这是天大的误解。它本质上是在做一个多约束、多目标的全局优化问题约束条件包括但不限于资源量、显存、拓扑、亲和性、隔离性、优先级、配额、时间窗口目标可能是“吞吐量最大化”“平均等待时间最小化”“保障SLA”等。2.2 调度不是“分卡”而是“帮任务找家”我更喜欢用一个比喻来理解调度器它就像餐厅的排号系统。食客就是训练任务桌子就是GPU节点桌子的尺寸对应资源量餐桌之间的远近对应网络拓扑距离排号规则就是调度策略。但比餐厅复杂的是这些“食客”还有性格差异——有的能拼桌弹性容错有的必须独占一张大圆桌AllReduce同步训练有的自带厨师团队依赖特定的镜像和库有的甚至要求必须坐在靠窗位置对某类GPU型号有硬性要求。一个能扛住万卡集群的调度器要同时做到三件事看得全实时掌握整个集群的资源状态、拓扑结构、任务运行状态、历史运行数据。算得对基于上述信息能快速算出“新任务放哪里最合适”。管得住任务运行后还能动态调整、抢占、驱逐、恢复。这三件事看起来简单但每一件在万卡规模下都会遇到性能瓶颈。举个例子“看得全”这件事如果调度器每次调度都要实时扫一遍所有节点的资源状态当节点数超过几千台时这个扫描动作本身就变成了瓶颈。业界通用的做法是分层、缓存、异步上报但实现起来细节很多后面会展开讲。3. 主流的调度器方案怎么选Volcano、Kueue、Slurm、Ray3.1 训练场景的调度器不是只有一种很多人聊调度器天然默认是Kubernetes那一套。但在AI训练这个领域情况复杂得多。我粗略把当前主流的方案分成四类先拉个表格对比一下调度器定位最适合的场景核心特点Kubernetes原生 自定义调度器云原生基础设施微服务、AI训练混合部署需要统一平台生态成熟扩展性好但深度学习任务适配需要二次开发VolcanoKubernetes上的批量调度扩展大模型训练、Spark、Flink等批量任务支持Gang调度、队列、优先级、抢占更贴合训练场景KueueKubernetes上的配额管理框架多团队共享集群需要精细的队列与配额管理基于队列做资源借贷与抢占管理逻辑清晰Slurm传统高性能计算HPC传统科学计算、老的AI训练平台稳定、稳健但在云原生与容器化方面较弱Ray分布式计算框架自带调度强化学习、超参搜索、数据并行训练动态任务图调度灵活但大规模训练管理与Kubernetes集成成本高你可能会问直接用Kubernetes原生调度器不行吗答案是可以但需要做很多额外工作。原生调度器本身是为在线服务设计的它假设任务启动后“长稳运行”不需要考虑复杂的资源抢占策略和多级队列。而训练任务是典型的批量任务生命周期可能是几小时到几天运行过程中GPU利用率波动大。所以聪明人都不会直接裸用原生调度器而是基于它的扩展机制Scheduler Framework做二次开发或者直接上Volcano、Kueue这类更贴合训练场景的方案。3.2 关键选择标准看你的集群规模和组织形式方案选型没有绝对最优关键看你自己的情况。我做集群方案设计的经验是先回答三个问题第一你的集群是单租户还是多租户如果集群只服务一个团队比如大模型预训练团队独占那调度器只需要管优先级和资源复用比较简单。如果是多租户场景多个算法团队共用一个集群那排队机制、配额管理、抢占比资源复用更重要Kueue或Volcano的队列机制会很顺手。第二任务是单一的“大块头”还是“长短混合”如果你的集群主要跑大规模预训练一个任务动辄用几百张卡那Gang调度是刚需——任务需要所有卡同时就绪一张卡不到位整个任务就起不来。Volcano的Gang调度策略就是干这个的。如果任务以微调、推理为主单卡和多卡任务混合那反倒不用把Gang调度看得太重原生Kubernetes加合理的节点亲和性就够了。第三团队有没有专门的人维护调度和基础设施这是最现实的问题。Slurm这种老牌方案文档齐全、社区人多遇到问题Stack Overflow一搜就有答案。Kueue和Volcano相对年轻但胜在云原生生态能跟Prometheus监控、日志系统无缝接。如果你的团队全是算法背景没人愿意天天折腾Kubernetes那老老实实用Slurm别赶时髦。3.3 Volcano与Kueue怎么协同使用很多人以为Volcano和Kueue是二选一其实在生产环境里它们经常一起合作。我见过的最佳实践是Kueue管“宏观配额”Volcano管“微观调度”。假如集群有1024张A100A团队配额是512张B团队配额是256张。这个“谁有资格用多少卡”的事情交给Kueue它维护好根队列和子队列的关系。真正到具体的GPU卡分配、节点绑定、Gang调度、抢占、分片恢复这些底层操作交给Volcano。Kueue能识别任务依赖的调度器类型把Pod调度动作卸载给Volcano两者通过CRD和Webhook协作互不干扰。这套组合拳的好处是配额管理在平台层很透明业务方申请资源的时候看到的是“队列剩余额度”而不是底层节点的琐碎信息。你甚至可以在Kueue之上再抽象一层做一个训练平台界面让算法同学自助提交任务、自助查日志、自助看监控调度细节全部屏蔽。4. 核心机制拆解Gang调度、抢占、回填、拓扑感知4.1 Gang调度没有条件创造条件也要整机一起上Gang调度的原理其实不复杂一个分布式训练任务由多个worker组成PS架构下有ps和workerAllReduce架构下全是worker只有当所有角色的资源都齐了任务才能真正跑起来。如果有任何一个worker的资源没到位任务就卡在那里占着已分配到的资源空转既不出结果还浪费GPU。Gang调度器的核心工作就是检测任务需要的资源是否齐全——即“任务的资源需求是否满足作业规模的约束”。如果满足一次性下发到所有节点如果不满足任务在队列里等待已经预留的资源会被暂时Hold住不实际占用。这个机制听着简单实现起来有两个难点如何Hold资源不浪费Volcano的做法是采用PodGroup概念将一组Pod打包成一个调度单元。调度器一次性判断所有Pod是否可调度如果全部可调度则一次性完成绑定如果不能全部满足则一个都不绑定避免部分绑定导致的死锁。如何避免死锁假设A任务要512张卡已经抢到了500张B任务要512张卡也抢到了500张。此时集群里只剩下24张卡两个任务都启动不了互相干瞪眼。这种情况Volcano提供了抢占机制来解决后面会细说。我做集群配置时习惯把Gang调度的超时时间设成一个合理的阈值比如10到15分钟超过时间就强制触发抢占或重新调度。有次踩过坑把超时设成了无限长结果一个小任务抢占了一半的资源后一直等另一半集群整体利用率被拉低到不足五成那叫一个蛋疼。4.2 抢占与优先级排队付了钱也得插队万卡集群里一定有低优先级任务占着资源跑得很欢也一定有高优先级任务进队列半天蹲不出结果。这时候就必须有“抢占”这个手段。抢占不是“我比你级别高把你拖出来机器给我用”这么简单粗暴。它涉及好几个问题抢占谁的资源要选可牺牲最小代价的任务。作为被抢对象最好是那些“刚启动不久的”或“已经跑了很久接近尾声的”任务因为前者重跑成本低后者已经产出不少checkpoint。调度器需要记录任务的启动时间和当前状态才能做出最优决策。被抢占的任务怎么办不是直接杀掉而是优雅退出保存checkpoint、退出训练、释放GPU。这个动作需要训练框架配合训练时定期存checkpoint的关键作用在这里就体现出来了。如何避免频繁抢占的“颠簸”现象如果高优先级任务不断到来、不断抢占那低优先级任务永远跑不完整个集群都在互相抢占、checkpoint、重启效率极低。解决方案是引入“最小抢占间隔”和“抢占代价模型”即两次抢占之间至少要隔多长时间、被抢占任务如果只运行了几分钟那就宁可让高优先级任务等一等。我这里给一个实用经验为不同任务定义合理的优先级层级不要搞太多层三层足够——生产任务比如线上模型的训练、实验任务比如调参的跑批、开发任务比如调试代码。生产任务可以直接抢占实验和开发任务但实验任务不能抢占生产任务。这样既能保证核心业务不被打断又能让集群资源不至于空闲浪费。4.3 回填与碎片资源利用给乞丐也安排一张床万卡集群“表面饱和实际上有一堆碎片资源”是日常。比如一个任务要32张卡集群当前只剩15张任务只能排队。但剩下这15张卡如果闲着就是浪费因为还有一堆只要2张卡、4张卡的小任务等着跑。回填Backfill机制就是解决这个问题在保证大任务资源不会流失的前提下允许调度器把暂时空闲出来的资源分配给一些小任务使用等大任务的资源真的到位了再终止这些小任务。这个机制的底层逻辑有点像“候补机票”你买了一张候补航班但起飞前其他乘客没退票候补的只能干等。这时候如果有个乘客只想飞一小段刚好可以利用你多出来的里程那他先上飞机也不影响你候补成功。回填机制对运维的挑战在于调度器要能准确预估大任务“大概还要等多久”如果预估不准可能导致小任务频繁被终止。业界常用的做法是设置大任务的最长等待时间超过这个时间无论资源有没有到齐都强制调度一次让大任务挤掉小任务保证大任务也有截止时间。4.4 拓扑感知调度卡和卡之间的距离决定了训练跑得快不快当你分配GPU时卡的“地理位置”决定了训练的效率。假设你要分配8张卡给一个小型训练任务这8张卡如果分布在4台不同的机器上每台2张那么训练过程中的梯度通信就需要走网络可能是InfiniBand也可能只是RoCE。而如果这8张卡在2台机器上每台4张通信走NVLink速度可能差了10倍。这是训练调度和Web服务调度最大的不同Web服务多搞几个副本分散到不同机器上是提高可用性训练任务把GPU分散到不同机器上是自找苦吃。所以调度器必须具备拓扑感知能力在做调度决策时考虑一系列层次Single Node Multi-GPU多张卡在同一个节点内走NVLink/NVSwitch通信带宽最高。Single Rack Multi-Node多台机器在同一个机柜内走TOR交换机延迟可控。Cross Rack跨机柜通信如果网络没有做好分层延迟和带宽损耗会很大。实现上Kubernetes的节点标签可以标记这些信息比如给节点打上topology.kubernetes.io/zone、nvidia.com/gpu.schedule等标签。Volcano在分配时也会读取这些标签尽量把同一个任务的Pod调度到拓扑上相邻的节点上。有一回我们遇到过这样的坑一个数据并行任务需要64张卡调度器全给散到各个机柜去了训练速度比预期慢了将近两倍。最后排查发现是节点标签打错了把同机柜的机器标成了跨机柜调度器做拓扑感知的时候直接抓瞎。从那以后我就明白一个道理拓扑标签的这种“后勤信息”比调度算法本身还容易出问题一旦出错谁都救不了你。把标签维护当成基础设施的一部分来对待。5. 实操基于Volcano Kueue搭建一个能用的调度环境5.1 环境准备与版本选型纸上谈兵再多不如直接落地一个环境。下面这套方案我已经在多个生产集群中使用过组件选择都是当前比较稳的组合组件版本建议说明Kubernetes1.28新版本对CRD和调度框架支持更好Volcano1.9稳定版Gang调度和抢占都比较完善Kueue0.5多队列管理机制较成熟NVIDIA Device Plugin0.14GPU资源上报适配新驱动GPU Operator23.6一键管理驱动、DCGM、监控等建议先把Kubernetes集群本身搭建好节点标签打全让调度器对环境有完整认知。如果用云服务商托管版Kubernetes那可以直接跳过集群搭建环节。但如果你自己维护裸金属我建议在集群里先部署好NVIDIA GPU Operator它会自动把驱动、容器运行时、DCGM导出器等组件部署好省去大量手动配置的活儿。5.2 部署Volcano并配置队列Volcano的部署非常方便一条Helm命令即可helm repo add volcano https://volcano.sh/charts helm install volcano volcano/volcano -n volcano-system --create-namespace部署完成之后我们需要创建队列。Volcano使用queue这个CRD来管理队列资源一个典型的队列定义如下apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: gpu-a5000 spec: weight: 1 capability: nvidia.com/gpu: 512 reclaimable: true deserved: nvidia.com/gpu: 512这句话的意思是该队列最多可以使用512张GPU卡并且队列内的资源可以回收即允许抢占。当多个队列同时存在时weight字段决定了资源分配的比例权重。在Volcano中Pod只有绑定了Queue才能被该队列调度。做法是给Pod添加volcano.sh/queue标签或者在PodGroup上设置Queue名称。我一般都是用PodGroup来管理因为PodGroup更容易表达Gang调度语义。apiVersion: scheduling.volcano.sh/v1beta1 kind: PodGroup metadata: name: test-job-pg namespace: default spec: minMember: 32 queue: gpu-a5000 priorityClassName: high-priority minResources: nvidia.com/gpu: 32minMember: 32表示这组Pod需要32个成员才能开始调度。minResources声明资源总量。当32个Pod都能找到合适的节点时Volcano会一次性调度全部Pod如果不行任务继续等待。5.3 配置Kueue做租户级别的配额管理Kueue做的分层逻辑我觉得特别适合多团队集群。它的核心概念包括ResourceFlavor定义一组资源比如gpu-a100-40g、gpu-a100-80g。ClusterQueue相当于一个资源池对应某一个ResourceFlavor的容量。LocalQueue挂在ClusterQueue下面用于给业务方提供资源申请入口。Workload表示一个训练任务一个或多个Pod组成。最简配置可以参考apiVersion: kueue.x-k8s.io/v1beta1 kind: ResourceFlavor metadata: name: gpu-a100-80g --- apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata: name: cq-a100 spec: namespaceSelector: {} resources: - name: nvidia.com/gpu flavors: - name: gpu-a100-80g resources: - name: nvidia.com/gpu nominalQuota: 256 borrowingLimit: 64 --- apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata: name: lq-alg-team-a namespace: alg-team-a spec: clusterQueue: cq-a100这里定义了A团队可以在A100上获得最多256张卡的配额同时还能临时借用64张卡。borrowingLimit的“临时借用”机制非常适合处理突发性的实验需求——团队在配额之外借了资源用完归还给集群整体利用率提升了不少空间。业务方在提交训练任务时只需要把Pod所在的命名空间设为alg-team-a并加一个kueue.x-k8s.io/queue-name: lq-alg-team-a标签Kueue就会自动接管kubectl label ns alg-team-a kueue.x-k8s.io/queue-namelq-alg-team-a --overwrite5.4 结合Prometheus做调度监控调度器装上只是第一步监控调度行为和集群利用率是第二步。这里我建议必须监控以下指标队列长度每个队列里等待调度的任务数量。正常情况下队列不应堆积太多否则说明资源不够或调度策略有问题。调度延迟从任务提交到Pod真正启动的时间间隔。延迟越高排队越严重。GPU利用率区分任务运行中GPU利用率和集群整体利用率。前者反映训练框架的效率后者反映调度的效率。抢占事件数如果抢占频繁发生说明队列配额设置不合理或者优先级层级太粗。节点碎片化程度如果集群总是出现有节点只有1~2张卡空闲但整体无法满足新任务需求说明碎片化严重需要调整分配策略。Volcano和Kueue都暴露了Prometheus指标端点例如Kueue的/metrics端口提供了队列使用量、Workload状态、调度时长等指标。直接接入即可不需要额外开发。有过一次生产经验我们在一个集群里部署好Kueue之后发现GPU利用率从62%提升到了82%原因很简单——队列配额管理让资源的借用和归还变得清晰团队之间不再互相卡着不放资源。6. 常见问题排查实录我在调度上踩过的坑6.1 明明有空卡任务就是不调度这是我们最初部署Volcano时遇到的第一个怪事。集群里空闲资源明明有80多张卡一个需要32张卡的任务就是不去跑一直Pending。排查路径先看Pod的事件终于看到了这么一句0/128 nodes available: 32 Insufficient nvidia.com/gpu, 96 insufficient topology key。问题出在拓扑标签。我们给节点打标签的时候把topology.kubernetes.io/zone打成了两个不同的值看起来是实际物理机柜号但实际上Volcano在做拓扑调度的时候要求同组Pod的拓扑标签必须一致。当时32张卡需求要全部落在同一个拓扑域里但每个机柜正好只有16张卡两倍都凑不齐调度器就认为所有节点都“不满足拓扑约束”。解决方式无非两种要么把任务拆成两个16卡的子任务分属不同的PodGroup要么更新节点标签把所有能互通的机柜打成一个拓扑域。从性能角度考虑我选择了后者因为同一训练任务拆到不同机柜通信损耗太大。从这个坑里真要总结一个铁律节点标签就是调度器的“眼睛”眼睛瞎了算法再好也白搭。上线前至少花半天核对标签尤其是GPU型号、拓扑域、资源预留这些关键信息。6.2 高优任务抢占后低优任务反复重启出不了结果这个问题出在一次配置改动之后。当时我们把一个团队的实验任务优先级调低了图的是让生产任务能有更快的调度。结果实验团队的同学跑过来抱怨说任务跑两分钟就被抢占重新排队又跑两分钟一整天啥结果没出。本质上是抢占太频繁。高优任务占满资源后低优任务只要一开始跑马上被抢占陷入“启动-被抢-重启-再被抢”的死循环。我的处理方案分两步设置volcano.sh/preemptable标记和更细的优先级层。实验任务可被抢占但加了一个“稳定运行窗口”后抢占动作只在低优任务运行超过一定时间后才触发。用Kueue对实验任务的提交频率做限流防止同一时间堆积太多低优任务。如果某个命名空间同时只有3个小任务在跑就算被抢占重跑代价也很低。核心思想是抢占策略的设计必须考虑“重跑成本”。一个已经跑了3个小时的任务和一个刚启动3分钟的任务被抢占后代价完全不同。调度器的策略应该倾向于抢占“年轻的”任务而不是“年长的”。6.3 碎片化严重资源利用率只有四成有时候集群总资源看着很充裕但任务就是排不进去。统计一看128张卡一个节点每个节点都有余卡但往往是几十张卡零散地分布在各节点上怎么拼都拼不出一个大任务需要的整机资源。这种碎片化问题在调度上非常经典。解决办法有三板斧节点池分类把支持大任务比如需要8卡整机的节点和支持小任务比如1~2卡的节点分开管理。大任务只能调度到特定节点池小任务则只能在另一个节点池跑物理隔离互不污染。开启Binpack策略Volcano支持binpack调度策略即把任务尽量集中在少数节点上不散开。这样能让空闲节点变成完整空闲的节点为未来的大任务腾出整机。定期整理碎片如果发现某几台机器长期只有少量卡被占用可以手动驱逐这些任务迁移到其他有剩余容量的节点上把空节点释放出来。我这里特别想提一下Binpack策略和散列分布策略的选择。在线服务通常希望把Pod打散到不同节点因为这样单节点故障影响面小。但训练任务恰恰相反希望尽量集中因为带宽和延迟是硬指标。这就意味着如果集群里同时跑在线服务和训练任务需要分成两个节点池来分别管理不能混在一起。6.4 任务长时间挂起排查发现是镜像拉取太慢最后一个问题虽然严格上说不是调度器的问题但调度器背锅了。当时集群里大量任务进入Pending状态调度器日志显示已经完成了调度决策Pod也已经绑定到节点上了但容器状态一直是ContainerCreating。查来查去发现是因为镜像仓库带宽打满导致镜像拉不下来。每个训练任务启动时都要拉一个超过10GB的大镜像几十个任务同时启动直接把镜像仓库带宽拉垮了。后来做了几件事镜像预热节点在空闲时提前把常用镜像拉取到本地。镜像分层优化把基础镜像和训练代码分开基础镜像只在变化时更新。配置imagePullPolicy: IfNotPresent避免每次启动都强制拉最新版本。这里也给做调度平台的同学提个醒调度器的职责范围之广远超“把Pod放到节点上”。从镜像拉取到存储挂载从网络分配到健康检查任何一个环节出问题任务都会卡在队列里。做排障的时候不要只看调度器日志要把整条链路都过一遍。7. 调度器的下一步分时调度与自适应调度的实践方向谈到未来目前我比较看好的几个趋势里最贴近生产落地的是分时调度和自适应调度。分时调度解决的是“白天实验任务多、晚上训练任务多”的问题。我们曾经尝试过用CronJob在每天固定时间调整调度器的配额权重晚上10点后把训练任务的配额调高白天再调回来。这个方案简单直接对资源利用率提升效果明显适合那种团队的训练任务有明确时段规律的情况。自适应调度则更智能一些它结合历史运行数据和当前集群状态自动判断一个任务应该给多少资源、放在哪个节点上。比如一个训练任务早期需要大内存做数据处理后期进入训练阶段后GPU利用率逐步上升调度器可以在任务运行过程中动态调整CPU和内存配比把多余的CPU资源让给其他任务。这些方向在开源社区已经开始有落地尝试但距离生产成熟还有距离。我个人的建议是先把基础的调度能力做扎实再考虑高阶玩法。所谓的自适应调度无论算法多花哨底层还是需要有可靠的任务画像数据、精准的预测模型和快速的调度反馈通道作为支撑。如果基础调度都经常出问题上高级功能只会放大问题。对多数人来说现阶段最有价值的实操动作是把你的调度器日志、队列使用量、任务等待时间这些指标全面监控起来跑上一两周拿到一批真实数据看看瓶颈到底在哪里。多数情况下你会发现问题不是出在调度算法不够聪明而是出在配额设计不合理、标签配置混乱、监控缺失这些“笨功夫”上。把笨功夫做扎实比追新概念有用得多。