走进一万张卡的训练机房，第一眼看过去是密集的机柜、嗡嗡呼啸的风扇、以及上百台交换机之间跳动的光纤。但对大模型训练来说，真正决定效率的核心并不是那堆闪闪发光的 GPU 卡，而是落在调度配置里的一行行规则：谁先跑、谁排队、谁占多少卡、挂了谁来顶。这背后的执行者，就是训练场的隐形老板——调度器。
打一个大家都能听懂的比方：调度器就像食堂里那个打饭阿姨，GPU 是热菜，模型训练任务是饥肠辘辘的干饭人。菜做得再好，如果阿姨不懂排号、叫号、判断谁该多盛一勺，食堂照样乱成一锅粥。到了万卡规模，这位“阿姨”不仅得会排班，还得处理食材断供、锅灶起火、有人插队等一切突发状况。
这篇文章就围绕“一万张 GPU 怎么排班”这个话题展开，聊聊调度器在大规模训练场里的核心职责、调度算法怎么选型、多团队共享集群时怎么端平一碗水、我这些年在一线踩过的坑，以及一份看完就能上手的排查清单。不管你是正在搭 GPU 集群的基础设施工程师，还是被“任务老是卡在 Pending”折磨的训练同学，这篇内容应该都能帮你少走不少弯路。
1. 调度器到底管了什么：它凭什么当“隐形老板”
1.1 模型训练里，调度器被严重低估了
很多刚接触大模型训练的人有个误区：觉得训练跑得慢，要么是模型代码写得不行，要么是 GPU 卡不够好。直到某天模型训练任务一个接一个卡在排队阶段，GPU 空闲一大片，才发现真正卡脖子的往往是调度系统。
调度器做的事情，本质上是“资源分配决策”。它知道集群里有多少张 GPU、每张卡的健康状态、每个节点上有多少剩余显存；它也清楚每个训练任务需要几卡、多大显存、需要跑多久、属于哪个团队。然后它要根据这些信息，决定下一秒让哪个任务上卡、哪些任务继续等着。
在万卡规模下，人工盯是绝对不可能的。一台一台去查 GPU 剩余量、再去估该给哪个任务分配卡，光这个动作就得花几个小时，更别提训练任务经常会失败重启、节点偶尔会掉线。调度器的价值就是把这些所有“该让谁上”的决策规则化、自动化，用代码把资源裁决做掉。
我经常给团队新人打一个比方：调度器不直接产生算力，但它决定了算力能不能被用起来。它不是训练场里的发动机，而是变速箱——没有它，发动机再猛也跑不出速度。
1.2 调度器的四项核心职责：注册、排队、拉起、自愈
调度器表面上只是个“排队系统”，实际运作起来要干的活儿比想象中多得多。我从实际运维的角度拆解一下，它至少承担四个方面职责：
资源注册与目录管理。每张 GPU 都像员工一样要有“档案”。调度器需要维护一张集群资源表，记录每个节点的 GPU 型号、显存大小、驱动版本、当前剩余卡数、健康状态。卡坏了要能自动标红下线，新扩容的节点要能自动发现并纳入调度池。这套机制相当于 HR 手里那张花名册，如果不准，后续所有决策都是瞎蒙。
任务排队与匹配分配。训练任务提交之后，调度器要根据任务的资源需求（几张卡、多少显存）、约束条件（必须落在有某类 GPU 的节点上）、优先级（哪些任务可以插队）来做匹配。所谓“排班”，这里是最核心的动作。
生命周期管理。任务分配只是开始，调度器还要负责把任务真正拉起来、运行中监控它的健康状态、结束后回收资源。万卡训练中，容器被 kill、节点重启、驱动崩掉都是日常事件，调度器要保证任务失败后能重新排队、重新调度，而不是直接变成没人管的僵尸进程。
故障自愈与故障域隔离。某个节点上的 GPU 温度一高，训练就会显著变慢甚至报错。调度器发现节点异常后，要能自动把所有任务迁移走，把故障节点隔离出调度池，防止一颗“老鼠屎”拖垮整锅汤。在故障域上也要有讲究：比如一个训练任务最好别全放在同一个机架或者同一个交换机下，否则一次断电、一次机房网络抖动，整个任务全军覆没。
2. 调度策略的核心机制：排队、分配与抢占背后的门道
2.1 两种最常见的分配策略：binpack 和 spread
调度器最常见的两种分配策略，业内叫 binpack 和 spread。听名字可能有点懵，我用搬家装货来展开。
binpack 是“能塞就塞”，优先把任务调度到已经部分占用的节点上，尽量把整机塞满。这样做的好处是容易省出完整空闲的机器。比如一个集群有 20 个节点、每节点 8 卡，100 个任务各要 1 卡。如果全部用 binpack 策略，调度器会把任务往现有节点上不停堆，最后可能只需要 13 个节点左右就装完，剩下 7 个节点完全空闲。这些空闲节点可以关机省电，或者留给需要整机 8 卡的大任务。
spread 则是“均匀铺开”，把任务打散到尽可能多的节点上。好处是单节点故障时影响面比较小，不会因为一个节点挂了导致很多任务同时失败；坏处是碎片化比较明显，大任务来了可能找不到连续的空闲卡位。
| 策略 | 优点 | 缺点 | 典型适用场景 |
|---|---|---|---|
| binpack | 资源利用率高，能腾出整机空闲 | 单点故障影响面大 | 成本敏感、卡特别贵的集群 |
| spread | 故障影响面小，负载均衡 | 碎片多，凑不齐大任务 | 稳定性优先、多租户共享集群 |
实践里怎么选？我的经验是：如果集群里有大量需要 1 卡、2 卡的小任务，同时也有 8 卡整机的大任务，那最好做成混合策略——小任务用 binpack 优先填满某些节点，大任务专门预约空闲整机。调度器的策略配得好不好，直接体现在月底的电费和任务平均等待时间上。
2.2 多团队共享集群：队列、优先级和抢占怎么端水
万卡集群很少有人是独占使用的，通常好几个算法团队共用。这时候调度器要面对一个极其现实的问题：A 团队在跑一个 512 卡的预训练，B 团队急着上线一个 64 卡的微调任务，C 团队只想调试代码要用 2 卡。该先给谁？
这就是调度器里的队列和优先级机制发挥作用的地方。
可以把排队理解成食堂的窗口制度。FIFO（先来先服务）就是只有一个窗口，排在前面的先打饭；Fair Scheduler（公平调度）就是多开几个窗口，保证每个团队都有机会打饭；Capacity Scheduler（容量调度）则是给每个团队固定分配一个窗口的份额，比如 A 团队最多用 50% 的资源，B 团队最多用 30%，剩下的归 C。
而抢占机制，就是“VIP 来了，普通窗口要给 VIP 挪位置”。比如高优任务提交后，调度器发现预留配额不够，可以强制把低优先级任务的资源回收，等低优任务重新排队。这个过程听起来很爽，但实际操作中要非常小心。如果抢占过于激进，可能导致低优任务一直训练不完，反复被掐断、反复重新排队，整个集群有效吞吐反而下降。
我推荐一个土办法：给每个任务设置最长等待时间和最小运行时间。低优任务一旦运行超过某个时间阈值，就不再被抢占；高优任务如果等太久，调度器可以选择弹性扩容或者提醒管理员人工介入。规则一定要先跟业务团队对齐，否则“调度器乱杀任务”的投诉会淹没你。
另外提醒一句：任务编排调度和资源调度是两码事。像海豚调度器（DolphinScheduler）这类工具，解决的是“某个工作流里 A 任务跑完再跑 B 任务”的依赖编排；而 GPU 调度器解决的是“这么多任务谁先上卡、上几张卡”。前者管流程，后者管资源，二者很容易混为一谈，实际部署时是两套系统配合使用。
2.3 显存怎么分配：训练和推理需求完全不一样
调度器分配 GPU 时，不能只看“几张卡”，还要看“每张卡上的显存够不够”。这也是大家常讨论的一个点：GPU 显存容量到底是测算训练还是推理用的？
答案是训练和推理都要测，但侧重点不一样。
训练时，显存不仅要装模型参数，还要装梯度、优化器状态、激活值。Adam 优化器一开，额外显存开销可能比模型本身还大。这也是为什么 7B 模型用 FP16 推理可能一张 24G 卡就够，但训一次全参数微调，怎么也得 4 卡甚至 8 卡 A100（每卡 80G）才能塞下。
推理时显存需求相对小，主要装权重和前向激活值，但有个新问题：推理请求是动态的，并发请求一多，显存占用会像商场客流一样突然暴涨。如果调度器给推理服务分配的显存太满，一个峰值请求就能把卡压爆。
分配显存的另一个隐藏坑是“显存碎片”。比如一张 80G 的卡，已经跑了几个小任务占掉了 10G、20G、30G 的零散空间，剩余可用显存是 20G，但它们在显存空间上并不连续。有些训练框架申请显存时要一大块连续空间，此时调度器明明显示“还剩 20G”，任务却报显存不足。集群里的显存碎片一多，浪费会比想象中严重很多，需要靠定期整理碎片，或者干脆采用更激进的 binpack 策略把小任务聚到特定节点上。
2.4 为什么 GPU 满载了，任务还在排队：聊聊背压
我经常被训练团队问一个问题：“集群 GPU 明明已经满载了，为什么我的任务还在排队？是不是调度器坏了？”
绝大多数情况下，调度器没坏，问题出在“资源配额已满”和“背压机制”上。
调度器本质上是一个多生产者多消费者的系统。为了让集群不因为任务太多而崩溃，调度器必须做限流——这和我每天早高峰开车的道理一样，高速路口如果让所有车同时冲进去，结果不是跑得快，而是全线堵死。调度器的背压机制，就是控制单位时间内能进入集群运行的任务数量，宁可让一部分任务在外面排队，也不能让太多任务同时在集群里互相抢资源，最后谁都跑不动。
所以一个任务处于 Pending（排队）状态时，可能是三种情况：
- 集群真的没有足够的空闲资源；
- 有足够资源，但团队配额已经用尽；
- 系统在做背压限流，防止恶意突发任务拖垮集群。
遇到任务排队，第一步先去看调度器的队列深度和等待原因，而不是盲目重启任务或者找运维“加卡”。很多线上事故，都是因为有人反复手动把卡从别的任务里抠出来，打乱了调度器的全局安排。
3. 万卡集群怎么选调度器：从开源方案到落地实战
3.1 主流调度器横向对比：Kubernetes、Volcano、SLURM
调度器的选型是万卡集群最核心也最纠结的决策之一。我把主流的几套方案放在一起聊聊，不吹不黑，就当是给还没有踩坑的同学一份参考。
Kubernetes 原生调度器：如果你已经是云原生架构，用容器跑训练，那 K8s 原生调度器是最容易上手的方案。它简单、稳定、社区生态大，但默认调度逻辑比较基础，对 GPU 这种特殊资源支持不够精细。比如它默认把 GPU 当作“整数资源”来分配，一张卡不能拆成两半用，也不擅长处理大批量训练任务的批量调度。
Volcano：这是 K8s 生态里专门做高性能批量调度的扩展组件，底层还是 K8s，但补充了 K8s 原生调度器缺乏的很多能力，比如 Gang Scheduling（任务组排队和统一调度）、队列管理、优先级抢占、资源配额、拓扑约束等。对跑大模型训练的场景来说，Volcano 基本是必选项。
SLURM：这是高性能计算领域的老牌调度器，很多老牌超算中心和传统 HPC 团队都在用。它非常稳定、调度效率高，但和云原生、容器生态的整合不够好，灵活性稍弱。如果你团队主战场是传统 HPC 脚本而不是 Docker 容器，SLURM 依然是可靠选择。
| 调度器 | 优势 | 劣势 | 推荐场景 |
|---|---|---|---|
| Kubernetes 原生调度 | 云原生生态、简单易用 | GPU 资源调度能力弱 | 小规模 GPU 集群、推理服务 |
| Volcano | 支持批量任务、Gang、队列、抢占 | 需要额外搭建和调优 | 大规模训练集群、大模型训练 |
| SLURM | 稳定、HPC 生态成熟 | 容器支持弱、弹性较差 | 传统超算、脚本式科学计算 |
以开源社区的活跃度和大模型训练的实际情况来看，当前比较主流的选择是“K8s + Volcano”组合，再根据自己的情况做一些插件开发，比如实现自定义的拓扑感知调度策略。
3.2 弹性配额与分时复用：一张卡一天可以干好几份活
万卡集群买回来是巨大成本，如果利用率拉不上去，老板看账单的脸色会很难看。提高利用率的一个常见做法，就是弹性配额和分时复用。
弹性配额的意思，是团队的资源配额并不是一条死线。比如 A 团队白天在线推理业务繁忙，需要 60% 的卡；到了晚上推理流量下降，就可以把配额临时让给跑离线训练的 B 团队。调度器可以根据时间窗口或者实时的资源水位自动调整配额，让同一批 GPU 在一天之内被不同用途的任务复用。
分时复用则是把一张卡按时间片或者按显存颗粒切分。比如一张 80G 的卡，白天跑四个 20G 的在线推理实例，晚上流量降下来，就把其中三个实例缩掉，让出 60G 给夜间批量训练。这里的关键是调度器要支持“任务收缩”和“资源调整”的能力，能在运行中动态修改任务占用的显存和卡数。
弹性配额最大的价值，是把 GPU 平均利用率从 40% 拉到 70% 以上。我见过不少团队，一开始调度配置只会写死“谁多少张卡”，后来改成弹性配额之后，同样的卡数能多跑接近一倍的训练量。调度器配得好不好，月底看账单就知道区别了。
3.3 拓扑敏感调度：卡放哪里，直接决定训练快慢
多机多卡训练里，通信开销常常被低估。以 AllReduce 为例，N 张卡同步梯度，通信量随卡数增加基本是平方级增长。如果任务里的卡被调度器乱丢到不同机架、不同交换机下面，跨机通信要走好几次网络转发，训练速度可能直接掉一半甚至更多。
拓扑敏感调度，就是为了解决这个问题。调度器在分配任务时，不仅看“有没有卡”，还看“这些卡之间的物理距离有多近”。最理想的部署，是同一个训练作业的卡尽量落在同一个节点上，其次是同一机架、同一 NVLink 域内。不同节点之间能走高速互联通道，就尽量别走普通网络。
这就像请客吃饭，大家坐在同一张桌子上聊天肯定比隔着一栋楼喊话效率高。如果你的训练任务用了模型并行，通信频率更高、延时更敏感，那调度器对拓扑的要求就更高。
有意思的是，MoE（混合专家）这类模型结构反倒可以故意把专家分散到不同节点上，因为专家并行天然就是跨节点通信，调度策略又是另一套逻辑。所以我给基建团队的建议是：不要只做一套拓扑策略，要能根据训练框架的类型灵活切换。
3.4 没有监控就没有调度：可观察性是调度的生命线
调度器再智能，如果看不到集群实时状态，本质上也是“盲人开车”。可观察性是调度系统能不能真正落地的生命线。
我一般要求监控体系至少覆盖四个层面：
- 物理层监控：每张卡的 GPU 温度、显存温度、风扇转速、功耗、时钟频率。用 nvidia-smi 和 DCGM 一类的工具持续采集，异常指标能直接触发告警。
- 调度器层监控：任务 Pending 数量、队列深度、调度成功/失败次数、任务等待时间分布。这里能看到调度器本身是否健康，有没有任务积压。
- 业务层监控：单任务的训练吞吐量（比如每秒多少样本）、梯度同步耗时、数据加载耗时。调度问题会间接体现在这些指标上，值得算法团队也关注。
- 资源利用率监控：集群总体 GPU 利用率、显存利用率、特定节点的空闲率。这是调优调度策略最原始的依据，没有数据寸步难行。
只有把监控搭起来，你才有底气做调度策略调优。否则你改一个参数，到底变好还是变坏，全靠猜。
4. 实操避坑：我在一线遇到过的调度器翻车现场
4.1 翻车现场一：任务在排队，GPU 却空闲一半
这是我维护 GPU 集群时遇到最多的一种诡异情况：打开监控面板，明明集群还有几百张空闲卡，新提交的任务却一直卡在 Pending，怎么也调度不上去。
排查这种问题，我会按下面这个顺序来：
第一步，看团队配额。挂载在任务上的配额是不是已经用满了？配额用尽的情况下，哪怕集群真的有很多空闲卡，任务也进不去。这是最常见也最容易被忽略的原因。
第二步，看节点标签和污点。K8s 里如果节点上有 taints（污点）或者没有匹配的 nodeSelector，任务会被调度器直接过滤掉，导致看起来“有卡却上不去”。很多运维加了污点忘记删，或者标签写错，就会造成这种假性空闲。
第三步，看显存碎片。用 GPU 监控看看空闲卡是不是都被小任务占了一部分显存，如果都是“剩 10G、剩 15G”这种零散容量，而你的任务要求 32G 显存，那调度器在显存匹配上就会失败，任务永远排不上。
这个案例给我的教训是：调度问题不一定是调度器本身的问题，很可能是底下资源状态、标签配置、配额策略等外围因素的综合结果。排查的时候要有耐心，从外到内一层层剥开。
4.2 翻车现场二：一次“GPU 卡死”引发的连锁反应
大模型训练长时间跑，GPU 偶尔会“挂掉”，表现为某个算子在卡上执行不动，训练进程 hung 住，既不报错也不退出。这个时候如果调度器没有超时驱逐机制，任务会一直占着卡，其他任务只能干等。
有一次我们在跑一个 256 卡的任务，中途有一张卡触发了 GPU Crash Dump，驱动直接把上下文丢了。没有容错机制的调度器完全没有反应，训练作业挂在那边整整十二个小时，浪费的算力换算成钱，足够吃好几顿大餐了。后来我们加了两道保险：
一道是容器层面的健康检查（livenessProbe）。每 30 秒检测一次训练进程的日志心跳，超过 3 分钟没有新输出就判定为死锁，自动杀掉容器，让任务重新排队。
另一道是调度器层面的故障驱逐。调度器定期检查节点上的 GPU 状态，如果发现温度异常、ECO 报错或者驱动丢失，就直接把该节点标记为不可调度，并将上面的任务驱逐到其他健康节点。
这套机制上线之后，再遇到 GPU 卡死，集群基本能在 5 分钟内自动恢复，不再需要半夜被电话叫起来手动处理。调度器的价值，这一刻体现得特别实在。
4.3 我常用的五条排障命令和日常巡检清单
最后分享几个我在排障时最高频使用的命令和巡检动作，对正在搭集群的同学应该能直接派上用场：
kubectl get nodes -L gpu-type：一目了然看到集群所有节点的 GPU 类型和状态，检查是否有节点被误标为不可调度。kubectl describe pod <pod-name>：查看任务调度事件，里面会明确写出“0/8 nodes available”或是“insufficient memory”这类原因，这是定位 Pending 的第一入口。nvidia-smi -pm 1：打开 GPU 持久化模式，减少运行过程中驱动初始化带来的性能抖动，排查卡顿问题时也会用到。nvidia-smi dmon：持续监控每张卡的利用率、显存、温度、功耗变化，适合定位“某张卡是不是偷懒了”这类问题。journalctl -u kubelet | tail -200：看节点上 kubelet 的日志，调度器下发任务后启动失败，大多数报错都能在这里看到。
日常巡检我维持在每周一次的频率，重点看四张图：集群 GPU 平均利用率、Pending 任务数曲线、节点故障率、显存碎片率。只要这四条线不出大问题，调度系统基本是稳的。等哪天真出问题，再顺着监控一层层往深处查。
5. 高频问题速查表与新手入门建议
5.1 高频问题速查表
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| 任务一直 Pending，集群却有大量空闲卡 | 团队配额用尽、节点标签/污点不匹配、显存碎片 | 检查配额、节点标签、显存空闲分布 |
| 显存明明够，任务却报显存不足 | 显存碎片化，连续大块显存不足 | 整理碎片，考虑 binpack 聚拢小任务 |
| 节点 GPU 卡死，任务长时间无输出 | 驱动故障、温度过高、算子死锁 | 配置健康检查和调度器自动驱逐 |
| 多任务同时训练，整机利用率很低 | 拓扑不匹配，跨节点通信开销太大 | 启用拓扑感知调度，尽量整机放置 |
| 低优先任务总被抢占，训练无法收敛 | 抢占策略太激进 | 设置最长等待时间、最小运行时间阈值 |
| GPU Crash Dump 触发，训练中断 | 驱动崩溃或硬件异常 | 检查驱动日志、重启设备，必要时换卡 |
5.2 新手入门从哪开始：单机到万卡的进化路径
很多人一上来就想搭万卡集群，我其实不大建议。调度的复杂度是随规模非线性上升的，你在 4 张卡上遇到的调度问题，和 10000 张卡上遇到的调度问题，完全是两个物种。
我给新同学的路径建议是：
第一步，先在单机多卡上理解显存分配和并行模式，搞清楚 DDP（分布式数据并行）、FSDP（全分片数据并行）在显存占用上的区别。不理解模型本身怎么吃显存，你就没法理解调度器为什么要对显存做精细管理。
第二步，搭一个几台机器的小型 K8s 集群，部署 Volcano，把队列、优先级、配额这几个核心概念在小规模上摸透。踩过几次坑之后再去碰大规模，就不会手足无措。
第三步，在完成前两步的基础上，再去调研万卡集群的拓扑感知调度、故障自愈、弹性配额这些高级话题。这就像练武功，先扎马步再学招式，调度器的基本功是 Linux、容器、网络和分布式系统，这四样缺一不可。
写在最后的几点体会
做 AI Infra 这几年，我越来越觉得调度器是个不太起眼但极其重要的角色。它不像模型结构那样动辄刷榜，也不像 GPU 集群那样肉眼可见地闪闪发光，但真正把集群利用率从 40% 拉到 70% 以上，靠的恰恰是这层看不见的规则。
我个人的一个建议是：很多团队的调度配置停在“能用”的层面，从没认真优化过。我建议每周花半小时看一眼集群利用率曲线，哪里常年空闲、哪里总是排队，调优方向就在那张图里。调度器排的不是代码，是钱——一万张 GPU 每天的成本非常可观，调度做得好不好，月底账单会告诉你答案。最后再分享一个小技巧：每次调整调度策略时，不要一次性改多个参数，改一个、观察一天、记录数据，再改下一个。调度器的问题很多是参数之间互相影响，你要能分清是哪个变量导致的收益，这样才算真的在调优，而不是在碰运气。
