1. 为什么说调度器是训练场的隐形老板先把结论摆在这里当我们讨论“一万张 GPU 怎么排班”这个话题时真正的核心往往不是 GPU 本身也不是只管把模型跑起来的训练框架而是那个藏在中间层、几乎没人会主动提起的调度器。做了这么多年 AI Infra我越来越觉得调度器才是训练场的隐形老板它决定了哪个任务能上机、哪个任务得排队、哪个任务会被劝退甚至连训练失败的“善后工作”也都是它在兜底。从使用者的视角看你在命令行敲一条提交命令然后任务就神奇地“跑起来了”。但从平台方的视角看事情远没有这么轻松。一万张 GPU 的系统里每天有几十个甚至上百个训练任务在竞争资源有的要 64 卡做大规模并行训练有的只要 2 卡做推理预热有的是半夜定时跑的增量训练有的是一提交就要立刻出结果的紧急实验。如果没有一个统一的大脑做决策资源必然是一团乱麻。调度器干的事情本质上就是一门“排班管理学”——每个人都要干活每块 GPU 都不能闲着任务之间还不能互相干扰。调度器到底“管”了什么我把它拆成三件事排班、盘点、兜底。排班指的是决定谁在什么时间点用多少资源跑多久这背后涉及队列、优先级、抢占、配额等一系列策略。盘点指的是实时感知集群里每一张 GPU 的状态是空闲、被占、故障还是被预留并且要快速响应节点上下线、驱动升级等变更。兜底则是指当任务失败、节点宕机、抢占误伤等情况发生时调度器要能快速重调度保证训练能继续推进而不是卡死在那里等人工介入。很多人有个误区觉得调度器不就是“谁先来谁先得”吗真要这么简单我就不用花一整篇来聊了。大规模训练场景下的调度难点在于“约束太多”一张 GPU 不够大模型跑任务往往需要跨节点组合单卡坏掉会影响整组不同任务的优先级随时在变管理员还想在白天优先保障在线推理、晚上让位给离线训练。这些需求堆在一起调度策略的选择就变得极其敏感。调度器选得好集群利用率能稳定在 70% 以上选得不好即使你有再多的卡实际跑出的有效算力可能连一半都不到。2. 从排队到占据两种调度策略的博弈2.1 先来先服务看起来很公平实际很脆弱先来先服务也就是 FCFSFirst Come First Serve这是最直观的一种调度策略。队列建好任务按提交时间排队前面的跑完后面的顶上。它像极了银行柜台叫号你来得早就早点办业务。好处是逻辑简单、实现容易、用户也好理解“为什么我的任务还在等待”——前面有人排在前面呗。但在大规模 GPU 集群里FCFS 暴露出一个致命问题队头阻塞。举个例子你在队列前端排了一个需要 512 卡的预训练任务可它要的卡一直凑不齐。后面几十个小任务明明只要 4 卡、8 卡却全部被这个“巨型任务”堵住。极端情况下大任务在等资源小任务也在等资源集群利用率反而下来了。这种“看似公平、实则双输”的局面在真实生产环境中我见过太多次。FCFS 还有一个隐性缺点它没有任何“全局观”。调度器只按提交时间做决策用户提交一个长时间占用的预训练任务可能就把整个 GPU 池“包圆”了。其他团队想插进来做快速验证完全没有机会。所以纯 FCFS 在大集群中几乎不会单独出现它一般会被包装成某种“基础排队逻辑”上面再加优先级、配额、抢占等机制来对冲缺陷。2.2 Gang 调度要么一起上要么都别上大模型训练给调度器出的第一道难题就是这玩意儿对资源的请求是“整块”的。你要做一个 64 卡的 LoRA 微调在训练框架层面是 64 个进程同时在跑每个进程需要一张卡而且这 64 个进程在每一轮迭代里都要做集合通信。如果调度器只给了你 60 张卡剩下 4 张“待分配”那这 64 个进程会全部卡在等待通信的 Barrier 上一步都走不动。更糟的是部分卡在空等资源白白浪费任务反而还处于“未完成分配”的状态。这就是 Gang 调度也叫 All-or-Nothing 调度存在的意义。调度器在启动任务时必须一次性把满足数量要求的 GPU 全部凑齐再统一发放给任务。要么 64 张卡全部到手要么一张都不给你继续凑资源。这像一个团队要包一辆大巴车大巴不满员不开车宁可在站台等也绝不让人先上车干坐着。Gang 调度的价值之大在大模型时代尤其被凸显。早些年 BERT、GPT-2 那个体量几张卡就够训练了调度不调度的没那么敏感。现在动不动就是千卡、万卡集群如果调度器不具备 Gang 能力靠人工去凑资源那几乎不可能。实际落地中Kubernetes 生态里有 Volcano 这类调度器专门实现 Gang scheduling在 Pytorch Elastic、MPI 这类框架上也能看到这类调度需求的影子。2.3 配额调度与公平调度资源有限时的“分蛋糕规则”除了 FCFS 和 Gang调度器还必须处理“资源归谁”的问题。一个万卡集群通常由多个部门、多个团队共用部门 A 拿了 60% 的卡部门 B 只有 20%剩下 20% 作为公共缓冲池。这种分配逻辑在调度器里叫配额Quota或容量Capacity管理。调度器不能只看单任务的优先级还要看任务所属团队的配额是否还有余额。配额决定了团队的“上限”而优先级是在配额之内决定任务谁先上。公平调度Fair Scheduling则是另一个角度。它追求的是让所有任务“相对公平”地获取资源而不是让某个大任务长期独占。常见的实现思路是基于 Dominant Resource FairnessDRF算法系统先看每个任务的“主导资源”是什么再以主导资源占用率为依据做均衡。打个比方任务 A 消耗大量 CPU、少量 GPU任务 B 消耗大量 GPU、少量 CPU两者的主导资源不同调度器会在两条维度上分别做均衡避免某个维度的资源被压垮。实际生产环境很少只用一种策略更多是组合拳用配额做团队级隔离用优先级做任务级排序再用 Gang 保证分布式训练任务的完整性最后用抢占来解决“资源不够又要保紧急任务”的冲突。这四种策略配合起来才勉强撑得住万卡集群的日常调度需求。3. 调度器的核心机制队列、优先级与抢占如果说调度策略是“价值观”那调度机制就是“执行手段”。策略定好了机制能不能落地很关键。下面是几个绕不开的调度器核心机制我逐个聊一遍。3.1 多级队列把集群当成一座“停机场”大型集群最常见的资源组织方式是“队列”而且通常是多级队列。看名字你可能想到工作队列、消息队列但这里的队列更像“停车场分区”有大货车区、轿车区、VIP 区。管理员会为不同类型的任务划分专门的队列比如“预训练队列”“微调队列”“推理队列”“开发测试队列”。每个队列有独立的资源配置有的队列配 70% 的 GPU、80% 的 CPU另外一些队列则给更少的资源。这样设计的好处是任务与任务之间的“脾气”差异太大了。预训练任务一跑就是一周推理任务要求毫秒级延迟开发测试任务可能每半小时就要杀一批。把它们混在同一个资源池里互相干扰非常严重。多级队列把不同“脾气”的任务物理隔离到不同资源分区稳定性会好很多。但多级队列不是越细越好。队列分得太多每个队列里的资源碎片就越严重调度器反而难以在全局做资源腾挪。我见过某些团队把队列细分到十几个结果运维同学每天被“资源不够但大规模空闲”的问题折磨。所以设计队列时要留出一定比例的“共享池”并让调度器支持队列间的资源借用。比如预训练队列暂时用不满微调队列可以先“借用”一部分资源一旦预训练队列有任务进来微调任务再让出去。这种弹性机制能让资源利用率上一个台阶。3.2 优先级与抢占谁能“插队”怎么“劝退”优先级机制解决的是“当下谁更急”的问题。集群里总会有一些任务需要立即执行例如线上模型出了严重精度问题需要紧急回滚并重新训练或者某团队在 deadline 前要出评测结果。这时候调度器如果还按队列顺序排下去业务就黄了。所以调度器要在队列逻辑之上增加“优先级”维度。高优先级任务可以跨队列插队甚至可以把低优先级任务已经占用的资源“抢”过来。“抢”这个动作正式名称叫抢占Preemption。抢占策略是调度器里最刺头的一块也是最能拉开平台差距的地方。我见过新手设优先级直接把预训练任务设为最高优先级结果一到夜里推理任务总是被抢占用户端延迟指标直接崩掉。抢占本身是必要的但要把握好“度”和“时机”。实现抢占通常有两种手段抢任务terminate与抢节点drain。抢任务意味着调度器直接终止低优先级任务的进程释放出来的 GPU 交给高优先级任务使用。这种方式简单粗暴但低优先级任务就“白跑了”尤其训练到一半的任务除非有很好的 checkpoint 机制否则损失巨大。抢节点则是把低优先级任务“挪走”比如先在同一节点上找到空闲资源把低优先级任务迁移过去再释放出整个节点给高优先级任务。这种方式的成本更高但伤害更小。实际场景中我更推荐“抢占分级”的做法先抢占尚未开始的排队任务再抢占已经跑了一部分但可以快速 checkpoint 重启的任务最后才硬杀那些无法断点续跑的任务。按“损失从小到大”的顺序来做抢占决策集群整体稳定性会好很多。3.3 亲和性、反亲和性与拓扑感知调度到了万卡规模调度还要考虑一个被很多人忽略的问题GPU 在物理上是分布在不同机器、不同机架、不同机房/可用区的。一个 64 卡的任务如果调度器把 64 张卡分布在距离很远的 8 个节点上训练过程中的跨节点通信时延就会显著拉高每一步迭代的时间都会变慢。相反如果 64 张卡尽量集中在一处甚至落在同一个 8 卡节点内组成 NVLink 域通信效率会大幅提升。所以现代调度器必须能感知硬件拓扑。这个话题一般叫 Topology-Aware Scheduling。调度器在给任务分配 GPU 时会优先把同一机架、同一交换机域内的 GPU 分配给同一个训练任务。更细的维度还包括16 卡尽量落在两台相邻的 8 卡服务器上而不是东西南北各一台需要 IB 网络通信的任务优先选择接入同一台 IB 交换机的节点。反亲和性则由另一个需求驱动某些任务之间希望尽量分散放置以减少故障半径。比如一个在线推理服务有多个副本调度器不希望这些副本落在同一台物理机上否则这台机器一挂整个服务都受影响。这类约束在 Kubernetes 生态里对应的是 PodAffinity / PodAntiAffinity / TopologySpreadConstraints但在高性能计算集群里这些逻辑通常会被嵌入调度器的资源 assignment 模块。拓扑感知这块在实际落地时常常被忽略因为它的效果不像队列、优先级那样“肉眼可见”。我在一个 512 卡集群里实测过同样一个分布式训练任务不感知拓扑随机调度 vs 感知拓扑就近调度训练吞吐差异可以达到 15%~25%。这个数字放在预训练动辄几天、成本几十万的项目里就是一大笔钱。4. 当训练任务出故障容错与重调度实战万卡集群里故障不是“会不会发生”的问题而是“多久发生一次”的问题。一张卡平均无故障时间MTBF再高乘以一万张之后每天都会有几个硬件故障在等着你。我在生产环境里遇到的故障类型大概是GPU 卡死或 ECC 报错、内存错误、节点网络抖动、IB 链路降速、存储目录被占满、训练框架自身 OOM、PyTorch NCCL 超时。任何一种都可能导致正在跑的训练任务中断或卡死。4.1 故障感知比任务失败更早地发现问题容错的第一步不是“恢复”而是“发现”。调度器需要实时监控每个节点的健康状态包括 GPU 的温度、显存错误计数、PCIe 链路状态、网卡速率、磁盘 inode 等。很多故障在真正导致训练失败之前其实已经有一些“征兆”。比如 GPU ECC 错误计数持续增长虽然训练还在跑但下一轮迭代失败的概率已经很高。调度器如果能在这种阶段就把节点标记为“不健康”并将新任务调度到别的节点就能避免大量训练任务在半路被中断。这里的关键是“预判式驱逐”predictive eviction与“事后恢复”reactive recovery结合。前者更高级但落地难度不小。我做过一版方案GPU ECC 错误达到阈值后调度器先把该节点置为“SchedulingDisabled”同时通知运行中的任务尽快做 checkpoint并准备迁移。这样从“预判故障”到“训练安全迁移”整体时间窗口可以控制得很短。后者的实现则相对直接检测到任务失败马上重置资源状态并重新扔进调度队列按原策略排队。4.2 与 Checkpoint 配合的弹性重调度训练任务中断后能不能快速续跑取决于 checkpoint 机制是否完善。调度器在这里的角色很微妙它不负责“怎么存 checkpoint”但决定了“任务什么时候能在别的地方重新跑起来”。一个常见的策略是 checkpoint 频率和调度状态绑定。调度器在决定“要不要杀掉这个任务”或“这个任务还能不能等”的时候会参考任务的 checkpoint 时间间隔。如果任务每 5 分钟存一次 checkpoint那杀掉它的代价就是最多损失 5 分钟的计算量如果一个巨型预训练任务每 2 小时才存一次那要抢它的资源就需要慎之又慎。我在平台里加过一个规则同一优先级下调度器优先抢占 checkpoint 频率更高的任务。这样既保证了紧急任务的资源需求又把被抢占任务的损失控制在最小范围。这个思路听上去很细但在万卡集群里每天多避免几次低效抢占整体训练吞吐就能提升不少。另一块容易忽略的是“重调度风暴”。当一个节点宕掉上面可能同时运行着 4 个训练任务每个任务里又有 8 个进程。如果调度器不加以控制同一瞬间会发起几十个 pod 的重建请求存储系统、网络插件、镜像仓库都会被打爆。我在生产里踩过一次大坑节点故障引发重启风暴直接把镜像仓库打挂了。后来专门在调度器里加了“重建限速”策略每次故障后按批次重建 pod比如每秒最多重启 30 个避免对依赖组件造成过载。这个细节虽然不起眼但紧急时刻能救命。4.3 重调度策略细节等待、重启、迁移重调度并不是简单的“重新分配”它包含三种截然不同的处置方式等待节点暂时有问题但不需要把任务迁走。调度器会把任务标记为 Pending等节点恢复后自动调度回去。这种方式适用于可预期的短暂网络抖动或节点重启。重启任务本身异常退出但代码和数据都是好的。调度器重新把任务拉起来跑在同一批节点上。这种情况最常见比如 NCCL 超时、OOM重启通常比迁移节点代价低。迁移节点硬件有问题或无法恢复调度器把任务调度到其他节点。迁移的代价最大因为要重新准备镜像、拉缓存、重建存储目录但在故障场景下又是最可靠的。在具体实现上我会用一个状态机来管理重调度的流转逻辑任务先进入“Recovering”状态然后根据故障类型判断是等待同一批节点恢复还是换 newNode 重新调度。状态机的关键在于避免“死循环”一个任务反复被调度、失败、再调度、再失败会形成调度风暴把集群的调度器 CPU 打满。解决办法是给每个任务设置重调度次数上限比如同一任务连续失败 3 次就停止重试并通知平台侧人工介入。宁可让人睡个好觉第二天起来手动处理也比半夜被调度风暴弄醒强。5. 从训练到推理、从单集群到多集群统一调度的大趋势5.1 训练调度和推理调度的差异在哪里训练任务和推理任务对调度器的要求完全不同这一点最容易被刚接触 AI Infra 的人忽略。训练任务的特征是生命周期长小时到天级、资源请求是“整块”的Gang、可以接受一定延迟等待、失败可以靠 checkpoint 恢复。推理任务的特征则是需要快速拉起、低延迟、高可用、多副本容灾而且资源是“微服务化”的一个推理服务可能拆成几十个小容器各自承载不同的请求量。所以训练调度强调“批量排队、资源聚合、抢占式调度”推理调度则更接近传统的 Kubernetes Deployment / HPA 那一套强调“副本数控制、负载均衡、QoS 保障”。万卡集群里如果只有一个统一调度器这两类任务混在一个池子里推理请求高峰期会把训练任务的资源抢走训练任务又会长期占用 GPU 导致推理弹不出来。实际生产里我见过两种主流方案。一种是把训练和推理分成两套调度平面底层仍然共享同一个资源池但通过“节点池”或“分区”做硬隔离。另一种是统一调度器中支持“双模调度”通过优先级/QoS 把推理任务设为不可抢占的高优先级训练任务则作为可压缩资源参与共享。坦白说训练侧对大算力 GPU 有强需求推理侧却越来越依赖低精度推理卡或专用 ASIC把两者完全混部调度工程复杂度会非常高。初期我更推荐“物理分池 逻辑统一调度”的折中方式把 GPU 按型号与时效性分成训练池和推理池但在调度入口用一个统一管理层这样后续做 GPU 池间的动态漂移也比较灵活。5.2 混部、潮汐调度与多集群 Federation当业务规模大到一定程度你会发现单个 K8s 集群哪怕是几千节点的超大集群也会到瓶颈。一方面是控制面像 API Server、Scheduler、Controller Manager 的压力越来越大另一方面是团队之间、地域之间天然存在隔离需求。这时候就不得不考虑多集群架构和跨集群调度。多集群调度的核心是 Federation也就是把一个逻辑上的大集群拆成多个物理子集群再由一个联邦控制器统一管理。用户的提交入口只有一个联邦层负责把任务分发到合适的子集群。这样各个子集群的故障不会互相传染同时资源利用率又能全局统一视图。潮汐调度是多集群调度里最实用的场景之一。比如白天在线业务繁忙推理任务吃紧离线训练任务可以让出一部分资源放到夜里再跑。联邦调度器需要支持“时间窗”策略白天把离线队列的可调度资源调低晚上把推理队列的资源配额调低同时让训练队列拿回大部分资源。这种“潮汐式”资源错峰能显著提升整体集群 TCO。但前提是任务本身要能容忍被延后或者有断点续跑能力否则强行错峰会引发频繁抢占反而不划算。5.3 大模型时代对调度器的新要求大模型训练对调度器提出了几个过去不太被关注的硬指标大规模 Gang 调度的毫秒级决策能力。任务数一多调度器每秒要处理的调度事件量极大决策太慢会导致大量 GPU 空转。面向“优先级反转”的容忍能力。大模型训练任务往往一占就是几十卡高优先级任务抢资源时被抢占的训练任务可能无法短时间内重新集齐资源这会造成“抢了也白抢”。此时调度器需要评估抢占行为是否真的能加速高优先级任务的执行时间而不是仅仅完成“抢占”这个动作。容错语义的丰富度。训练任务需要 checkpoint、需要感知故障自动进行“冷/热迁移”调度器要能感知训练框架的状态而不是只停留在“RestartPod”层面。从更长远看调度器会越来越像一个“算力操作系统”。它对上承接训练框架、推理引擎对下管理异构资源池GPU、NPU、HBM、RDMA 网络横向还要与存储、监控、告警平台做深度联动。跑通一万张 GPU 的训练真正考验的不是某一张卡有多快而是这套“操作系统”能不能让一万张卡长期稳定地协作跑任务。6. 选型参考、排障手册与我的实操体会6.1 常见调度器选型对比调度器选型是 AI Infra 团队必然要面对的问题。我把目前业界主流的方案整理成一张表方便大家对照自己的业务场景做选择。方案生态归属核心优势适用场景主要短板SlurmHPC 传统方案对 MPI、GPU、作业队列支持成熟学术科研、超算中心、HPC 类训练容器化/K8s 融合较弱API 偏传统Kubernetes KueueCNCF 原生云原生生态完善接入简单基于 K8s 的中大规模训练需要自己实现很多训练策略细节Kubernetes VolcanoCNCF 云原生批处理原生支持 Gang、队列、优先级大模型训练为主、HPC 混合负载社区活跃度与版本兼容性要留意自研调度器大厂私有完全贴合业务控制力最强万卡级超大规模、强定制化场景研发成本高、维护难度大Slurm 在传统超算里几乎是一统天下的存在。如果你接手的是一个 HPC 底子的平台团队也习惯用 sbatch、squeue、scancel 这一套命令那直接用 Slurm 往往最省心。但 Slurm 和 Kubernetes 结合起来使用时要处理“两套体系”的适配问题比如如何把 Slurm 的作业状态映射到 K8s Pod 上怎么做统一的日志与监控这些都需要额外投入。Kubernetes Volcano 是当下大模型训练场景中最常见的组合。Volcano 本身支持 Gang scheduling、队列、优先级还能和 PVC、RDMA 网络等资源无缝对接。社区活跃更新也快适合希望快速落地“训练平台”的团队。自研调度器一般是头部公司才做的事。它的价值不在于“造轮子”而在于万卡规模下对调度效率、故障恢复、成本控制有极致的定制需求。比如某业务专用的调度器可以结合训练框架的 checkpoint 信息自动决定要不要抢占、能不能延迟恢复。这种深度绑定是通用调度器很难做到的。6.2 调度器运维必查的几个指标调度器上线之后日常运维不能只盯着“有没有任务在跑”。我整理了几个关键指标建议在监控面板里长期展示调度延迟从任务提交到完成调度的平均耗时。过高说明调度器在大量排队或计算状态时开销大。队列深度每个队列里 Pending 任务的数量。队列长期堆积说明资源供给不足或优先级配置有问题。资源碎片率某个队列内“不可被大任务利用的小块资源”占总资源比例。碎片率高说明需要调整任务的资源请求粒度或开启资源聚合/合并策略。抢占频率单位时间内发生抢占的次数。频繁抢占会引发训练任务反复重启需要优化优先级策略。节点故障驱逐数被调度器隔离的节点数量。突然飙升说明硬件健康或网络链路出了问题。重调度成功率故障后成功完成重调度的任务比例。重调度反复失败需要及时追查调度循环或数据依赖问题。这些指标建议配合告警规则一起使用。比如调度延迟超过 5 分钟触发 Warning抢占频率超过每小时 3 次触发 Warning队列深度持续 30 分钟超过阈值则触达负责人。不要等到用户来投诉“为什么我的任务半天没启动”才去查运维主动发现问题比被动响应高效得多。6.3 我在实际集群中遇到的高频问题最后聊聊我在实际运维中遇到的高频问题这些问题在官方文档里往往写得很模糊但实战里几乎必踩。第一个是“任务长期 Pending 但资源明明没满”。这通常不是调度器 bug而是 Gang 调度的“严格性”导致的。64 卡的任务只凑了 62 张卡剩余 2 张卡因为分布太散无法满足任务的整体资源约束所以调度器只能一直等。排查时我会先查这个任务需要哪些资源标签比如 GPU 型号、SCM 节点标签、IB 网卡数量再看节点上是否有被占用的“小碎片”资源组合不满足整体需求。如果确认卡确实够但分布不合理可以考虑给任务开启“放宽资源约束”选项或者在调度器里做成“先松弛后严格”的两阶段调度。第二个高频问题是“CPU 和内存资源爆掉但 GPU 利用率很低”。很多训练任务的资源请求只写了 GPU 数量忘了申请 CPU 和内存或者申请得很小。调度器把任务分配到一个 CPU 很紧张的节点GPU 倒是够了但数据加载、Embedding 查表这些 CPU 密集操作全部卡住GPU 一直空转。排查这种问题要看任务实际资源使用曲线并把 CPU 请求量调到合理值。尤其大模型训练DataLoader 多进程占 CPU 非常夸张千万不能只盯着 GPU。第三个问题非常隐蔽“Kubernetes 集群中 kube-scheduler 与 Volcano/自研调度器并存同一种资源被两个调度器重复分配”。一旦出现这种冲突节点状态会变得极其混乱有时 Pod 挂在 Pending但 GPU 已经被某个调度器悄悄占掉了。解决办法是在资源分配链路中明确指定唯一的调度器入口并在 Pod 声明里显式指定 schedulerName。第四个容易踩的坑是“太多小任务把调度器打爆”。开发测试类的小任务常常是几十秒提交一个、几十秒跑完一个。这种雷鸣般的提交会让调度器状态频繁变更CPU 开销直接顶上去了。如果平台对这类任务不加限制很容易把调度器整体拖慢反而影响真正的训练任务。我后来在做平台都会加“提交频率限制”默认一个用户同时最多 5 个活跃的小任务超过的排队而不是直接发到调度器。这个小改动对调度器稳定性提升非常大。6.4 给新入场团队的三条建议如果是团队刚起步GPU 规模在几百张卡的阶段我的建议是不要一上来就自研调度器也不要照搬万卡级别的那套复杂策略。先用 Kubernetes Volcano启用 Gang scheduling、队列和优先级把最基本的“训练任务按队列跑、避免相互踩踏”这件事做好。等业务量真的大到 K8s 控制面撑不住或者有特别复杂的混部需求时再考虑引入自研或联邦调度。第二从一开始就把资源模型和业务模型对齐。GPU 型号、显存大小、节点分组、CPU 配额这些信息要提前规划并尽量标准化。我见过很多团队早期只用一种 GPU 型号觉得“调度器随便配配就行”后来引入多种 GPU 之后所有队列策略、标签体系、资源配额全都要重做非常痛苦。第三重视“调度策略变更”的可回滚性。调度器的配置改动影响面极大一次不当的优先级调整可能让所有训练任务都被抢占。建议所有调度策略变更都走 GitOps 流程配置文件版本化并且支持一键回退。在关键调度策略上加上“灰度开关”比如先在一小部分节点上启新策略观察几分钟指标再全量上线。调度器是训练场的中枢神经改动的风险等级必须按“生产变更”来对待而不是轻飘飘地改个配置就完事。我个人做了这么多年 AI Infra最大的体会是高性能的 GPU 决定了训练的下限而调度器决定了训练的上限。一万张卡堆出来的算力如果没有一个聪明的调度“老板”来排班那最终能跑出的有效算力一定远低于理论峰值。希望这篇关于训练与调度的分享能帮大家少走一点我走过的弯路。如果你们在落地过程中也遇到调度相关的坑欢迎带着具体场景来交流。