一万张 GPU 排班到底有多难很多没真正碰过训练集群的人会觉得这问题不就是“哪个任务要用卡分它不就完了嘛”。但真正在一个大规模训练环境里待过的人都会明白GPU 调度是训练平台里最脏最累、也最容易被低估的一环。标题里那句话说得挺准——调度器才是训练场的隐形老板。这个系列前面几章聊到过训练环境、算力规划这些基础问题这一篇把“下篇”补上核心就是围绕调度器展开讲清楚一万张 GPU 是怎么被分出去的为什么调度策略不对会让几千卡闲着以及你在做 AI Infra 时最容易被问住的那些“调度八股”背后到底是什么。先说明一点这篇文章不是照着哪家云厂商的文档抄出来的更多是我在管理大规模训练集群过程中的实际经验再加上业内普遍认可的一些做法。你拿去参考可以具体参数和策略一定得结合你自己的业务形态来调。1. 一万张 GPU 排班到底难在哪调度器凭什么当“隐形老板”1.1 先算一笔账一万张卡是个什么规模假设我们手里有一万张 H100单卡显存 80GB。这批卡全部加起来显存总量是 800TB。什么概念你现在手里最强的游戏本算它 24GB 显存那这一万张卡相当于三万三千多台游戏本同时开足马力跑训练。再看功耗。H100 标称功耗通常在 700W 左右一万张卡那就是 7MW 的功耗。按一个训练周期 30 天算不算制冷和网络设备光是 GPU 本身电费按工业电价 0.6 元一度粗算大概是 300 万人民币。你要是调度不当让这批卡平均利用率只有 40%那就等于每 10 天烧掉 180 万的电费产出却只有一半。这么一算你就能理解为什么所有做 AI Infra 的人都在拼命压榨 GPU 利用率。GPU 太贵了贵到任何一个合理的调度策略都值得你花上几周时间去打磨。1.2 人肉排班为什么不可行调度器补上了哪三类能力一万张卡的集群如果靠人肉排班每天要处理的不是“今天谁用几台机器”这种静态问题而是突发故障、高优任务插队、低优任务让位、节点维护、网络拥塞一大堆动态事件。随便一个凌晨三点的卡故障靠值班人肉去一台台找卡重新拉起任务第二天整个训练进度都会难看。调度器补上的恰恰是这三类人类不擅长的事情一是快速决策。任务提交后毫秒级或秒级做出资源分配判断不用等人开会评审。二是全局视图。它知道哪个节点还有空卡、哪条网络路径是通的、哪个队列的配额已经用满。三是长期策略。可以提前把任务按优先级与公平性排布甚至考虑到未来一个小时的排队预期。这一节把“隐形老板”的角色定性了后面我就展开讲讲调度器到底在看哪些资源靠什么策略做排班。2. 调度器到底在调度什么GPU、显存、网络与任务状态2.1 GPU 不是一个简单整数它身上挂着四五个维度的属性很多刚接触 AI Infra 的人一提资源分配就说“给我 4 张卡”好像 GPU 就是一堆整数。真到万卡集群里调度器面对的 GPU 属性至少包括单卡显存大小比如 40GB、80GB后面还有更大的算力单元数量也就是 SM 数或 CUDA core 数不同型号的卡对 PyTorch 训练吞吐影响很大卡间互联能力比如 NVLink 域、NVSwitch 域跨域通信走 IB 或 RoCE 网络带宽完全不是一个量级是否支持 MIG 切片也就是一张物理卡切成多份逻辑卡在推理或者小模型训练场景里很有用当前健康状态有没有报过 Xid 错误有没有被调度器标记为“亚健康”。调度器如果只按“一张卡”来匹配那就太粗了。比如大模型训练需要 8 张卡必须在同一个 NVLink 域内调度器随手从三个节点各拿几张卡拼一个任务出来通信就会走跨节点网络性能直掉一半都有可能。这就是为什么在真实的调度系统里资源并不是一张扁平的表而是一棵拓扑树。调度器要先找到满足拓扑条件的节点组再在组内挑具体卡优先级最高的约束总是“卡间互联拓扑必须匹配”。2.2 任务状态机与调度器介入的时机训练任务一般会经历几个状态提交Pending、排队Queued、运行Running、完成Succeeded或失败Failed。调度器的核心工作集中在“排队”到“运行”这一段但它还要一直盯着运行中的任务因为运行任务可能出各种幺蛾子。常见的调度器介入场景有这么几类任务提交时校验资源量、检查配额、打上优先级标签然后扔进队列。队列轮转时按策略从多个队列里选出“下一个该跑的任务”再去找匹配的节点。运行中故障时如果节点宕机或者 GPU 报错调度器要把未完成任务重新入队或者通知训练框架去恢复 checkpoint。运行中变更时高优任务抢占低优任务、节点需要维护排空、任务需要扩缩容这些都属于运行的动态调整。一句话总结调度器不只是“分配一次”它是整个训练任务生命周期的隐形管理者。2.3 集群调度器和框架级调度两层调度各管一段很多人问过我一个问题我都用 Kubernetes 或者 Slurm 做调度了为什么训练框架里还有调度概念实际情况是训练场景下往往存在两层调度。底层是集群调度器管的是一台台物理节点、一块块 GPU。它的视角是整个数据中心大到租户配额小到某块 GPU 的拓扑位置都是它的职责。框架级调度则内嵌在训练框架里比如 Megatron-LM、DeepSpeed 或者 Ray它管理着一个训练任务内部的 pipeline 并行、tensor 并行、数据并行这些子角色应该放在哪张卡上以及它们之间的通信模式。集群调度器负责“把资源给任务”框架级调度负责“任务内部怎么用资源”。两层配合得好训练效率才能拉满配合不好就会出现资源够但任务起不来或者任务起来了但通信拓扑一塌糊涂。3. 排队、抢占与配额排班表的底层逻辑这一节是“隐形老板”的核心决策逻辑。拿我们熟悉的排班表来类比调度器有点像大型医院的门诊排班系统一边是有限数量的诊室和医生一边是源源不断的患者和不同的病情紧急程度。你得先设规则再谈效率。3.1 队列与配额怎么划分才不容易吵架大规模集群基本都会按团队、项目、或者业务线划分队列每个队列有独立的资源配额。你千万不要做那种“全网一个大池子随便用”的事否则一旦出现资源争抢靠事后协调一定会扯皮。每个队列通常会设置这几个参数最大可用 GPU 数比如 team-a 最多 512 张队列优先级数值高的在争抢时有优势是否可以借用其他队列的空闲资源以及被追回时的行为是否允许抢占允许抢占的队列在资源不足时可以召回低优先级的资源。我见过很多团队把节点打上不同的标签再把队列绑定到具体节点组上比如训练队列绑定到 A100 节点组推理队列绑定到 A10 节点组。这样做的好处是物理隔离减少了相互干扰坏处是会产生“资源孤岛”。某边排队排队排死另一边可能空闲一片。更好的做法是在共享节点组上用标签约束比如大模型训练任务的 Pod 强制要求节点必须带 nvidia.com/gpu.productA100同时允许推理任务在这个池子里跑但要设置可被抢占的标记。3.2 优先级与抢占高优任务插队低优任务让位但别饿死调度器的排队如果只按 FIFO那就没法处理“搜推广大模型训练”和“某个实验性小任务”同时抢卡的局面。必须引入优先级。不过优先级不能只体现在“排队顺序”上还得体现在“抢占能力”上。一个训练任务跑了两天高优任务来了低优任务就得被暂停保存 checkpoint释放资源。这里有一个关键点训练任务的抢占不像微服务拉起一个容器就完事它涉及大模型 checkpoint 的保存和恢复。如果每个小时存一次 checkpoint抢占时最多丢失一小时的训练进度。如果你 8 小时才存一次抢占一次就相当于白白烧掉几万块钱的算力。所以在我自己负责的集群里我们强制要求大模型训练任务至少每 30 分钟写一次 checkpoint并且把 checkpoint 存储放在高可用分布式文件系统或者对象存储里。抢占发生时调度器会先通知任务进入保存流程优雅一点而不是直接拔电源。这点实操经验非常关键。同时也要防止低优任务被饿死。我们会有类似“保证低优任务最终能获得少量资源”的机制比如每个队列哪怕优先级再低也保底有 8 张卡的资源量在空闲时可以调度。不然低优任务的用户会觉得这个平台完全不可用最后只会逼大家偷偷绕过调度器在裸机上跑任务场面会彻底失控。3.3 Binpack 还是 Spread装箱策略选择背后的取舍调度器分资源时有两种比较极端的策略一种是 Binpack把任务尽量集中调度到少数节点上剩余节点可以处于空闲关机或者低功耗状态这样省电也省管理开销。另一种是 Spread把任务尽量分散到不同节点上降低单点故障的影响面也降低节点间通信的竞争但会导致碎片化。训练场景和在线服务场景的策略选择完全不同。在线服务尤其是推理任务通常倾向于 Spread把负载摊开避免一个节点挂了服务雪崩。训练任务则要分阶段看大模型训练优先看节点内拓扑同一节点的 8 卡组最佳所以 Binpack 在节点维度上是必须的但跨任务之间我们又会尽量避免把多个大型训练任务放在同一台交换机下面因为网络会互相干扰。所以实际环境里很少用“全局 Binpack”或“全局 Spread”更多是按拓扑层级混合用节点内 Binpack机架间 Spread。这个细节在面试 AI Infra 相关岗位时经常被问到你如果能把“两层策略”讲清楚会比单纯背概念强很多。4. 万卡调度最麻烦的三件事拓扑、故障、显存维度这一章写的都是实操中最容易翻车的地方。网上讲调度的文章很多但真正把这三个问题讲透的不多。4.1 组调度Gang Scheduling为什么少一张卡任务反而不能跑单机多卡训练或者多机多卡训练通常会用到集合通信库比如 NCCL。任务内部往往有多个进程每个进程占一张卡并且它们要彼此同步。如果调度器分资源时只给了 7 张卡而不是任务要求的 8 张悲剧来了7 个进程开始初始化第 8 个进程因为拿不到卡卡在初始化阶段整个任务 hang 住别人看到的就是“这个任务把 7 张卡占着卡死了”。这就是组调度存在的意义。调度器必须保证要么一次性把任务需要的全部 GPU 都分配好要么完全不分配。这个“手拉手一起走”的机制在 Slurm 里对应一些批量分配参数在 Kubernetes 生态里则常通过 Volcano 或其它支持 Gang 的插件实现。但组调度也有代价。如果任务需要 512 张卡而集群某时刻只有 500 张空闲那这 500 张会一直空等到任务超时利用率上不去。所以我们在实际使用中会做两件事一是通过优先级和队列配额尽量保证大任务申请的卡数不超过一个集群水位线 二是对大任务做弹性训练支持也就是任务本身支持“先申请 256 张卡跑起来等资源充足后再扩展到 512 张”。这个能力训练框架要配合比如支持动态调整并行度调度器只需要提供扩缩容接口。4.2 故障驱逐与自愈半夜 GPU 坏了调度器比人起得快一万张卡每天出几个故障太正常了。GPU 可能报 Xid error节点可能网络失联SSD 可能被训练日志写满甚至机房空调故障导致局部节点温度过高而自动关机。调度器如果只负责分配资源那集群就是“开瓶后没人管”的状态。必须有一套故障处理机制第一步是健康检查监控 Agent 不断上报节点和 GPU 状态。第二步是故障标记当一个节点上的 GPU 多次报错Agent 会把节点标记为“Schedulablefalse”不再分配新任务现有任务则迁移。第三步是任务驱逐与重排队调度器把受影响的任务重新放回队列并在等待后重新调度到健康节点上。听起来挺标准的流程但实际情况往往有坑。比如有些 GPU 故障是间歇性的第一次报错后过一小时又恢复正常。如果只凭一次错误就驱逐任务会把好好的训练打断。我们的做法是对“可恢复错误”设置观察窗口比如 30 分钟内连续 3 次以上才标记为不可用。对于关键训练任务还要配合训练框架的 checkpoint 机制驱逐前先让任务进入保存状态。4.3 从卡数到显存粒度的调度训练任务申请资源时除了写“我要多少张卡”还要写“每张卡需要多少显存”。很多人只写了卡数也没说模型权重、梯度、优化器状态大概需要多少显存。结果就是两个 40GB 显存的任务被调度到同一张 80GB 的卡上从“卡数”角度看是 1 张卡给 1 个任务没问题从“显存”角度看调度器可能完全没有利用好显存的维度。我们在调度器里通常会扩展资源模型把 GPU 显存作为一种独立可量化的资源维度。比如任务 A 需要 20GB 显存、任务 B 需要 30GB 显存那么一张 80GB 的卡可以通过 MIG 或者显存隔离手段同时分给两个任务。不过要提醒一句显存隔离和算力隔离不完全等价。如果你的训练任务是很吃算力的大模型 trainer强行切分显存可能会导致同一物理卡上的两个任务互相争抢计算单元最终两个任务都变慢。所以显存级维度的调度更适合推理任务或者小 batch 的微调训练不太适合那种要把整张卡计算单元全部打满的大规模预训练。5. 多租户与成本治理调度器不只会排班还会管账5.1 公平性调度别让一个大任务饿死全平台多队列场景下如果队列之间的调度只是简单比优先级很容易出现高优队列长期霸占资源低优队列啥也跑不起来的情况。业内的经典方案是“主导资源公平”思路简单说就是看每个队列在所有资源维度上的占用比例谁的最小份额最少谁就更应该被优先分配。比如团队 A 占用了大量 GPU但 CPU 份额用得不多团队 B 占用的 GPU 不多但 CPU 已经用满。在 GPU 资源紧张时按 GPU 维度公平在 CPU 资源紧张时又需要考虑另一套权重。实际调度器不会做得那么理想但至少要保证每个队列有一个不被打穿的“水位线”这也是租户治理的最低底线。5.2 利用率观测与碎片整理怎么发现“资源其实够但调度不出来”调度器最怕的情况是每个节点上都有空闲卡但都是零散的单卡组不出一个多卡任务。这就是资源碎片化。要发现这个问题靠感觉没用你得有一套指标和看板。我常用几个核心指标GPU 使用率看算力是否打满显存使用率看显存是否够用节点聚合带宽看跨节点通信是否成为瓶颈每队列排队任务数看队列配置是否合理资源碎片率比如某节点组的上可组 8 卡任务的候选集数量。当你发现某节点组明明 GPU 总量还剩不少却连续几天有大量任务在排队大概率就是碎片化太严重。这时候可以选择做一次“压缩”也就是把分散的任务重新迁移到一批节点上释放出连续节点组。但训练任务的迁移是有成本的除非任务支持热迁移很少否则必须是“先停、存 checkpoint、再调度、再恢复”。所以压缩操作一般安排在训练低谷期并且要对所有任务标记“可迁移”与“不可迁移”。5.3 成本归属与排班审计隐形老板还要算明白账万卡集群一定涉及成本核算。每张 GPU 采购价、折旧、电费、网络和存储成本最终都要分摊到每个团队、每个实验任务上去。调度器应该为每个任务记录它的精确资源使用量包括用了多少卡、多少小时、多少带宽。我们在调度器上层会有一个“计费与预算”模块每天根据任务资源账单给团队推送成本报告。哪个团队在跑的实验最多、哪个模型训练烧钱最狠一目了然。这时候调度器的作用就不只是“技术底座的隐形老板”而是“成本控制的管理抓手”。6. 常见问题与排查技巧实录写这一节之前我翻了下之前带团队时踩过的坑挑几个典型问题写出来附上排查思路对实际做调度系统维护的人比较友好。6.1 任务一直排队进不去原因可能不是“没资源”最常见的现象是用户在那边喊“我明明看到集群有空卡为什么任务一直 Pending”如果你自己也这么怀疑先别急着改调度策略按下面顺序排查查任务申请的资源是否匹配节点标签比如模型指定了 A100但当前空闲的是 A10查队列配额是不是已经用完配额满的情况下即便有物理空闲也不一定能调度查任务是否声明了特殊限制比如“必须 8 卡同节点”“必须带 IB 网卡”“必须在指定机房”查任务优先级如果队列里排在前面的高优任务吃得特别多低优任务实际上要等很久。我之前遇到过最隐蔽的一个坑任务在 YAML 里设置了非常严格的 CPU 请求量比如一个 GPU 任务要求 64 核 CPU而集群里每台机器只有 96 核调度器必须同时满足 CPU 和 GPU 才能调度结果 GPU 有富余CPU 不够任务就一直 Pending。看监控时只盯着 GPU 指标很容易漏掉 CPU 维度。6.2 运行中的任务慢得离谱调度器该不该背锅如果任务是正常调度起来的但训练速度远低于预期优先考虑是不是通信拓扑出了问题。比如一个 8 卡任务被调度到了 2 台机器上每台 4 卡跨节点通信只有一根网线带宽而正常情况下 8 卡应该在同一台机器上走 NVLink。这种问题从外部看GPU 利用率也可能不低但训练吞吐就是上不去。排查时可以看几个点任务被分配到的节点名单这些节点是否属于同一个故障域或者接入同一台物理交换机训练日志里集合通信的耗时占比如果框架支持开启 NCCL 调试日志看通信路径是否出现问题。遇到这种情况光靠“重跑”解决不了根本问题还得回到调度策略上强化“必须按拓扑模型分配”的约束。6.3 资源明明够但任务一启动就被驱逐注意健康检查误报还有一种让人很头大的问题任务调度成功跑了几分钟就被调度器驱逐了。查日志一看是某张 GPU 上报了一次瞬时错误被健康巡检判定为故障。这种瞬时错误有的是真实故障有的只是驱动抖动或者监控误报。建议把健康检查策略设计得保守一些单次错误只记录不驱逐连续多次错误且出现在不同任务的多次分配中才标记为故障。同时保留一张“故障观察名单”被标记的 GPU 可以先摘掉一段时间如果后续任务连续稳定运行再放回来。处理这种问题调度器本身的策略只是一部分监控数据的合理性和准确性同样重要。你永远不希望因为一个误报让一个千卡任务突然中断。6.4 节点维护时如何优雅“排空”别把训练任务直接杀掉数据中心总有节点要换配件、升级固件。这时候如果你直接标记节点不可调度然后硬杀上面的任务训练就白跑了。更规范的做法是先把节点标记为“不可调度新任务”等待节点上正在运行的任务自然完成或者通知训练框架自行保存 checkpoint 后退出如果在限定时间内任务没退出再执行强制驱逐维护完成后节点重新标记为可调度但要有“冷却时间”机制先跑一些小任务验证健康再分配大任务。这套流程本质上就是调度器状态管理与运维动作的配合能少很多训练事故。7. 最后补充一点个人体会调度器这个方向入门难在概念多深入难在场景差异大。同一个调度策略在推理集群里合适在训练集群里可能翻车在单租户离线训练场景合适在多租户混合负载场景又不够用。所以不要迷信任何一篇“最佳实践”你要把这套东西当成一个不断调参和验证的过程。我个人做训练集群调度这几年的体会是先把监控做扎实再谈策略优化。没有准确的资源利用率和任务状态数据调度器就像在黑夜里开车你再牛的算法也白搭。接着要舍得在工程细节上抠比如优先级抢占的优雅返还、故障节点的观察窗口、组调度和弹性调度的配合每一处都能榨出不少性价比。另外给刚开始接触 AI Infra 的读者一个建议不要一上来就啃分布式调度算法的论文不如先把自己手头的几张卡、一个小集群的调度流程搞清楚亲手复现一次“任务排队—调度—运行—故障恢复”的完整链路收获会更大。毕竟调度器再强大最终也是为人服务让训练任务稳定、高效、可预期地跑起来这才是“隐形老板”真正的价值。
