万卡集群的隐形老板：GPU调度器如何决定训练效率

我做AI Infra也有几年了，先说一句可能让算法同学不爽的话：万卡集群里，真正说了算的不是模型训练代码，而是调度器。当一万张GPU堆在面前，物理卡只是算力，能把这些算力变成稳定、高效、可预期的训练服务，靠的是排队、分配、抢占、容错这一整套机制。这篇是AI Infra系列第五章的下半部分，专门聊训练与调度，重点就是那个“隐形老板”——GPU调度器。适合正在搭训练平台、管GPU集群、或者被“卡等人/人等卡”逼疯的同学参考。

很多刚接触这块的人会觉得，调度器不就是排队叫号吗，有什么好研究的。真到万卡规模你会发现，问题完全不是“谁先来谁先用”这么简单。一个训练任务可能要上百张卡，但集群里空闲的卡可能散落在几十台机器上；高优任务要随时能插队，又不能让低优任务饿死；任务跑到一半一张卡挂了，还得想办法不把整个训练拖垮。这些全是调度器的活。今天这篇我会按“资源困局-选型-核心原理-实操落地-问题排查-运维体会”来拆，尽量把一个万卡调度器该有的样子讲透。

1. 万卡训练场上的资源困局

1.1 一万张卡不等于一万倍算力

先纠正一个很常见的错觉：把集群从一百张扩到一万张，训练速度不会自动提高一百倍。算力规模上去了，但资源利用率如果没有调度器兜底，可能比单机还难看。我见过不少集群，业务方天天抱怨排队，可一看监控，大量GPU利用率不到10%。原因是训练任务经常只占一部分显存和算力，却把整张卡锁死了，别人想共享都没门。

更深层的问题是资源碎片化。假设集群有两千张空闲GPU，可它们分布在八百台机器上，每台机器只剩两到四张卡。如果有个任务需要八卡并行，调度器必须一次凑齐一个机头的八张卡，否则在物理网络上跨机通信会把训练效率拉低一大截。这里涉及的“八卡”不是单纯数量，而是拓扑上的一个整体。调度器如果不懂这些，只会机械按“剩余空闲卡”去分配，任务根本跑不起来。这也是为什么万卡集群的调度逻辑远比普通云主机调度复杂。

这背后还有一个关键指标叫“分配率”和“利用率”。分配率是任务拿到了多少卡，利用率是卡在任务里实际干了多少活。调度器主要管分配率，但很多团队把两者混着谈，最后算法怪运维，运维怪调度，调度怪需求方。真正合格的调度系统，需要在分配的时候就为利用率创造环境，比如把碎片卡先合并、把能共享的任务放在一起、把通信密集的任务安排到相近的拓扑。

1.2 谁在决定任务排队：从人工排班到调度器

早期训练集群规模小，几百张卡的时候，很多团队靠共享文档“排班”。每个算法同学在表格里填“我要用8卡，预计跑三天”，然后管理员手工分配机器，跑完再释放。看起来也能转，但规模一起来就崩了。人没法保证及时释放资源，没法判断优先级，更没法在半夜自动给任务找卡。更麻烦的是，人工分配往往只看“哪台机器有空闲卡”，根本不看机器上的拓扑，十次里有八次把多机任务分到跨交换机通信的路径上，训练速度肉眼可见地掉。

调度器的出现就是把“经验排班”变成“策略执行”。它持续接收资源上报，记录每张卡的状态，维护一个任务队列，每次有资源和任务变化，都按照预定策略重新决定谁先跑、在哪跑。整个过程不需要人参与，如果策略设计得好，资源分配率和任务吞吐都会比人工高很多。可以说，调度器就是训练场的隐形老板，它决定每个任务几点开工、上几号机组、能占多少资源、中途被打断怎么办。

调度器和“任务编排”要分清。海豚调度器（DolphinScheduler）这类工具更多是管DAG工作流，哪个任务依赖哪个任务、按时间触发，它不负责GPU资源分配。真正在万卡集群里管GPU的，是Slurm、Kubernetes加上Volcano这类资源调度器，或者商业化的训练平台底座。如果混用这两个概念，很容易把工作流调度和资源调度做成两套互不沟通的系统，最后又要靠人去搬运。

1.3 调度器的核心职责：排队、分配、抢占、容错

调度器听起来就是一个“找空闲资源”的过程，实际职责要宽得多。我习惯归纳成四件事：排队、分配、抢占、容错。排队解决“谁先用”的公平性和优先级；分配解决“具体用哪几张卡”的拓扑和配额；抢占解决“高优先任务来了如何腾地方”；容错解决“运行中出故障怎么恢复”。四个环节缺一不可。很多自研调度器只做了排队和分配，遇到任务卡死只能靠运维半夜起来kill。

排队机制不只是一个先进先出队列，还要能动态调整。比如预训练任务优先级高，但它是长时间任务；实验任务虽然短，可数量庞大。合理的调度器会设置多级队列，给每个队列设置权重和额度，避免一个长任务把队列全堵死。分配的核心是资源建模，把CPU、内存、GPU、显存、网络带宽甚至NVLink域都纳入请求模型。抢占则需要和训练框架配合，先保存checkpoint再释放资源，而不是直接把进程杀掉。容错则包括节点掉线、GPU报错、NCCL超时自动重试。

2. 调度器选型：从裸机到云原生

2.1 自研脚本为何撑不到一千张卡

很多团队一开始都是自研脚本。脚本逻辑不难：每隔几秒查询一次GPU状态，发现有任务请求就找空闲机器，然后SSH上去启动训练。问题是这种轮询式调度存在天然缺陷。第一，状态更新有延迟，两个调度节点同时看到空闲资源后会重复分配；第二，没有全局的拓扑视图，无法感知NVLink和交换机路径；第三，任务死掉后没有回收机制，残留在机器上的进程会继续占用GPU；第四，没有抢占和优先级概念，高优任务也只能干等。

到一千卡规模自研脚本就开始失控。因为GPU故障是常态，脚本很难区分“任务自己挂了”和“节点掉电”，更别说做自动故障转移。不少平台团队后来都掉进“补丁套补丁”的坑：先修重复分配，再修僵尸进程，再修优先级，最后代码几万行，各自为政。这时候引入成熟的调度器框架，反而更划算。除非你的场景是非常规的专用硬件、专用网络，否则不建议从零造调度器轮子。

2.2 开源调度器怎么选：Slurm、K8s+Volcano、Ray

当前主流方案基本可以分成三种流派。第一是传统HPC流派的Slurm。Slurm在超算领域摸爬滚打多年，对多机多卡调度、作业排队、抢占和计费支持很成熟。如果你的集群主要是裸机或物理机，用户习惯直接提交脚本，Slurm会非常顺手。PyTorch DDP任务最多用srun启动，再配合sbatch排队，体验很丝滑。第二是云原生流派的Kubernetes，搭配Volcano、Kueue等调度组件，适合已经容器化、对弹性伸缩和平台集成要求高的团队。K8s生态里的Device Plugin可以上报GPU数量、GPU型号、显存等；Volcano补充了Gang调度和异构资源调度能力。第三是Ray，更偏面向Python生态的分布式计算和任务调度，适合超参搜索、模型评估、强化学习模拟这类任务，但如果要稳定跑超大规模训练，一般还是和K8s或Slurm结合使用。

很多同学会问，到底选哪个？我的经验是看团队底子。如果团队已经有运维物理机的经验，算法同学习惯登录节点跑命令，Slurm是低门槛高收益，能解决90%的问题。如果团队本就在云原生体系里，希望训练、在线推理、数据工程项目统一到一个技术栈，就压K8s+Volcano。至于DolphinScheduler，更适合做数据集成和工作流编排，不是GPU资源调度器，不能把它当成训练调度核心。

2.3 从“物理机”到“容器化”：调度器的形态选择

调度器形态也会受上层使用方式影响。物理机时代，用户看到的就是一台Linux服务器，调度器把整机或部分GPU分配给一个任务。这种模式简单直接，但是环境隔离很差，不同算法的Python依赖可能打架，CUDA版本也可能相互污染。容器化之后，调度器分配的不再是赤裸裸的GPU，而是“容器+GPU+网络”的组合，环境可复制性大幅提升。这也是为什么K8s能成为今天AI平台的主流底座。

但容器化不等于万事大吉。GPU本身是物理设备，容器里看到的显卡数量和宿主机上被分配的设备要一一对应。调度器需要调用NVIDIA Device Plugin，为容器注入NVIDIA_VISIBLE_DEVICES环境变量，把宿主机的GPU设备映射给容器。如果这个环节没做好，容器里nvidia-smi可能显示全部显卡，多个任务就会抢占同一块卡，造成显存溢出。调度器选型时，不只是看调度算法，还要看和运行时、驱动、监控的集成度。

3. 调度器核心原理拆解

3.1 资源建模：GPU、显存、拓扑与亲和性

调度器第一件事，是把集群里的资源抽象成可描述、可分配的数据。物理上，一张GPU卡有算力、显存、带宽、显存带宽等属性。逻辑上，调度器还需要知道它在哪台机器、连在哪个PCIe Switch下、和哪些卡共享NVLink域、与哪张网卡在同一个NUMA节点。只有把这些信息都建模，才能做出让人满意的分配。用现实生活类比：你不能只告诉别人“我有8个座位”，还得说清楚这8个座位是不是在同一排，是连排还是散座，否则来一个需要团队坐一起的任务，散座再多也没用。

现代训练调度里，拓扑感知越来越重要。NVIDIA的NVLink域和NVSwitch让单机内通信接近内存带宽，而跨机通信走IB或RoCE网络，延迟和带宽差很多。调度器如果能感知到哪些GPU被分到了同一个NVLink域，就能让通信密集的并行训练任务优先使用相近GPU。这是一门很深的功夫，很多团队用NCCL拓扑探测工具生成“亲和性图”，再传给调度器作为节点打分的依据。

显存也是独立的资源。比如一张A100有80GB显存，一个小实验可能只要20GB，理论上可以三四个任务共享一张卡。但GPU共享不是简单切出显存就能用，还要考虑计算隔离和显存带宽争抢。所以资源建模必须支持“整卡分配”和“实例分配”两种粒度。NVIDIA MIG可以把A100/H100这类卡切分成多个GPU实例，每个实例有独立的显存和计算切片，调度器只要感知到这些实例并分配即可。对很多没有MIG的卡，常见的做法是给容器加显存配额限制，比如使用CUDA的cudaDeviceSetLimit或容器运行时限制，避免一个任务把整卡显存吃干抹净。

3.2 排队算法：从FIFO到公平调度与DRF

最先想到的排队算法一定是先来先服务(FIFO)。很简单，但问题也很典型：一个需要512卡的大任务排在前面，后面一堆8卡小实验只能干等。哪怕小实验三分钟就能跑完，也得等到大任务凑齐资源之后，整个队列吞吐都会变得很差。

所以实际系统都会引入多级队列和权重。管理员创建不同队列，比如“预训练队列”“实验队列”“自动评测队列”，每个队列分配一定的资源配额。调度器在队列之间做公平分配，在队列内部再按优先级和提交时间排序。这时候经常用到主导资源公平(DRF)思想，核心是看每个任务对集群中某种资源（GPU、CPU、内存）的主导占用比例，再做均衡，避免一个“吃显存狂魔”把所有GPU队列堵死。

分布式训练任务还有个特点：不确定什么时候能凑齐资源。调度器一般采用批量调度或回溯式调度，每收到一批新任务，就重新跑一遍匹配算法，尝试把所有等待任务调度到可用资源上。调度速度也很关键。一万卡集群每秒可能有大量请求，如果一次调度决策耗时超过几秒，任务排队体验会非常差。业界常用分层调度和增量调度来优化，先做粗粒度的分区筛选，再在分区内部细化分配。

3.3 Gang调度：All-or-Nothing的无奈与必须

传统HPC调度是“来一个任务，够资源就跑”。但分布式训练往往要求“所有worker同时就绪”，否则部分worker启动后只能空转等待，甚至NCCL初始化超时。比如PyTorch DDP任务需要128个进程同时拉起，调度器如果只放出来50个，其他78个还没分配到GPU，那50个进程就可能因等待通信对手而卡死。

因此必须支持Gang调度，也就是“要么全部给，要么一个也不给”。调度器在找到满足任务所需全部资源的方案之前，不会让任务任何一部分启动。这听起来很简单，但实现时会造成资源碎片，因为一个小任务可能挡住资源，让大任务无法凑齐。现在很多调度器采用“先到先得但整体回溯”或“把任务按优先级排列后统一实施”的办法，尽量减小gang调度带来的空隙。Volcano核心贡献之一就是提供Gang调度能力，它的设计就是为了解决这类AI训练场景。

3.4 抢占与重调度：不是简单kill进程

高优先级任务入场时，低优先级任务就得让路。但“让路”很有讲究。最粗暴的是发SIGKILL杀进程，这样做会丢失训练进度，甚至破坏checkpoint状态。合理做法是先把任务挂起，等它保存完最新checkpoint再释放资源，或者直接把整个容器“迁移”。迁移并不一定是物理迁移，很多系统采用“任务冻结+磁盘镜像”方式，冻结训练进程，换一台机器恢复。

抢占策略还要防止“活锁”和“饿死”。如果高优任务频繁到来，低优任务可能永远跑不完。调度器一般会对低优任务设置最小资源保障和最大等待时间，到了一定时间就禁止高优任务继续抢占。另一个难点是GPU是哑设备，进程被kill后，显存不会立刻释放，驱动会有一段时间等待。调度器需要配合监控在GPU空闲后更新资源状态，否则会出现“资源显示被占用，实际没人用”的假象。

3.5 显存视角：配额、隔离与显存管理

把显存当成独立资源来调度的必要性越来越强。大模型微调时，算法常在代码里设置显存上限，但很多人并不会。当多个任务共享一张GPU时，一个任务就可能把显存占满，把其他任务OOM掉。调度器要么直接做整卡分配，不允许共享；要么引入显存管理和隔离能力。如果选择共享，最好使用MIG等硬件隔离能力，或者容器运行时里设置设备级限制。

热词里经常有人问“虚拟显存到底减少的是什么”“释放GPU显存潜能”，这个要区分概念。NVIDIA没有传统意义上的虚拟显存，MIG是把物理显存切片，每个实例有自己的显存控制器，互不抢占。而Windows/Linux操作系统的共享内存虚拟显存，更多是把CPU内存当作备用显存，性能差很多，不适合训练调度。调度器要做的是合理使用MIG和GPU时间片，让大任务独占整卡，小任务共享实例，而不是指望“虚拟显存”解决超卖。

3.6 故障感知与自动重调度：万卡常态不是“如果挂”而是“肯定挂”

到了万卡规模，每天都有GPU出问题几乎是一种常态。PCIe链路松动、显存ECC错误、驱动hang、风扇转速异常、NCCL超时……调度器必须能感知这些故障并把任务转移到健康节点。一般流程是：监控组件定时上报节点健康状态，调度器发现异常后标记节点为排空状态，不再分配新任务；运行中的任务会根据设定做自动重启，重启前先尝试从checkpoint恢复。

故障恢复和抢占在表象上类似，但语义不同。抢占是人为优先级排序，故障重调度则是非预期事件。调度器需要保存任务的状态和资源偏好，好在新节点上恢复。更复杂的情况是NCCL集合通信超时，可能并不是节点故障，而是网络拥塞或拓扑不合理导致训练缓慢。调度器需要把这类任务的状态从“运行中”识别为“不健康”，再决定是否重启。

4. 实操：给训练场装上调度器

4.1 环境准备：从驱动到容器运行时

以Slurm这套典型的物理机调度方案为例，讲一下实操链路。前期要把每台训练服务器的GPU驱动装好，统一版本，保证nvidia-smi能看到卡，并且和CUDA版本兼容。很多团队遇到过“驱动版本过新导致旧CUDA无法使用”的问题，所以在装机时就要明确驱动、CUDA、GPU型号的兼容矩阵。还要安装nvidia-container-toolkit，让Docker或containerd创建的容器可以访问宿主机GPU。

配置好之后可以先用命令验证：

nvidia-smi nvidia-container-cli info

如果一切正常，nvidia-smi会列出所有GPU，nvidia-container-cli info会显示容器运行时识别NVIDIA驱动的能力。这一步看似基础，但我在很多故障排查现场发现，问题最终都出在驱动和容器运行时不匹配上。特别是有些机器同时安装了多个版本的显卡驱动，nvidia-smi显示正常，容器里却总是调用不了GPU。

4.2 快速搭起Slurm集群骨架

在物理机上搭建一个最小可用的Slurm集群，大致需要三个角色：一个是controler控制器节点，负责调度和记账；一个是compute计算节点，被controller管理；还有一个是数据库和Munge认证服务。Munge是用来做节点间认证的，安装后要保证所有节点使用相同的key，否则节点加入集群时会被拒绝。

配置文件slurm.conf是核心，需要定义集群名、节点列表、分区信息、资源类型。要给GPU做通用资源(GRES)配置，比如：

NodeName=gpu001 Gres=gpu:8 CPUs=128 RealMemory=500000 PartitionName=training Nodes=gpu001 Default=YES MaxTime=INFINITE State=UP

这里Gres=gpu:8表示gpu001这台机器上有8张GPU卡。配置完后用scontrol reconfigure加载，再用sinfo和squeue确认节点状态。如果节点处于DOWN状态，大概率是Munge认证失败或slurmd没起来，需要在计算节点上查slurmd日志。

4.3 写一个能被调度的分布式训练作业

准备好集群后，提交训练任务非常简单。写一个run.sbatch脚本：

#!/bin/bash #SBATCH --job-name=llm-train #SBATCH --partition=training #SBATCH --nodes=4 #SBATCH --ntasks-per-node=8 #SBATCH --gres=gpu:8 #SBATCH --time=48:00:00 #SBATCH --output=%x-%j.log srun torchrun --nproc_per_node=8 --nnodes=4 --master_addr=$(hostname) \ --node_rank=$SLURM_NODEID train.py --config=config.yaml

然后用sbatch run.sbatch提交，用squeue看排队情况，用sacct查看历史作业状态。Slurm会自动在分到的节点上启动srun任务，并通过环境变量SLURM_NODEID传节点编号。如果你的训练代码依赖固定的MASTER_ADDR和MASTER_PORT，建议由Slurm作业脚本统一注入，避免手动填IP出错。

这里有个很重要的实操心得：#SBATCH --gres=gpu:8必须写对。如果只写--ntasks-per-node=8而不声明GPU资源，Slurm只会分配CPU任务，任务起来后会发现容器里看不到GPU。反之如果声明了gres=gpu:8，Slurm就会通过环境变量把对应的显卡设备ID传给任务。

4.4 K8s+Volcano的替代路径

如果你选的是Kubernetes和Volcano路线，思路不太一样。需要先在集群里安装NVIDIA Device Plugin：

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/nvidia-device-plugin.yml

然后用模板提交Volcano Job：

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: ddp-job spec: tasks: - name: worker replicas: 32 template: spec: containers: - name: train image: training-image resources: requests: nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1

Volcano看到这个Job后，会根据请求的GPU数量和Pod间依赖关系做Gang调度，等32个worker全部满足条件后才一起启动。这个方式对容器化环境非常友好，但排错链路也更长，需要同时查Pod状态、调度器事件和Device Plugin日志。

4.5 监控GPU调度效果：别让数据骗了你

调度器运行起来后，必须持续监控效果。除了常见的GPU利用率和显存占用，我更建议关注这些指标：队列平均等待时间、任务分发时间、节点分配率、由于拓扑限制导致的调度失败次数、被抢占任务的数量和恢复成功率。可以配合nvidia-smi dmon看实时状态，也可以把DCGM Exporter接入Prometheus，采集功耗、温度、PCIe带宽、NVLink带宽等指标。热词里有人提“ubuntu stress测试需要看到CPU GPU各种状态”，其实生产环境也一样，不管多忙都要保留基础监控，否则出了故障只能抓瞎。

我自己通常会在调度器上设置一个“资源闲置告警”。比如某张GPU连续五分钟利用率低于10%，就推送到运维群。这个告警的意义不在于立刻处理，而在于发现调度器是否把任务分到了错误的拓扑位置，比如跨NUMA、跨交换机导致通信等待，表现为GPU利用率偏低但训练速度更慢。

5. 常见问题与排查技巧实录

5.1 任务在排队，GPU利用率却不高

这个矛盾现象很典型。表面上看，队列里有任务等待，说明“资源不够”，但实际每张卡都在摸鱼。最常见原因是资源碎片化和拓扑限制。比如等待的任务需要8卡，但空闲GPU分布在两个不在同一NVLink域的机头上，调度器认为无法分配。此时需要检查分区的Gres配置、节点是否处在排空状态、是否开启了拓扑感知过滤。另一个常见原因是任务分配到了大卡，但只用了一小部分显存，却占用了整个GPU实例，调度器不会把这个实例再分给别人。解决办法是开启显存共享或MIG。

5.2 NCCL超时和掉卡：调度器该背多少锅

NCCL超时是分布式训练最常见的“卡死”原因。有相当一部分不是GPU硬件故障，而是调度器把任务分配到了通信路径差的位置。比如一个训练任务被分到两个不同的机架，机架之间走几层交换机，延迟和拥塞控制都不行，NCCL的all-reduce就会慢到超时。排查时先看任务里nvidia-smi锁定的卡号，再看这些卡在宿主机的NUMA或PCIe拓扑上是否分散。可以通过NCCL的NCCL_DEBUG=INFO和NCCL_DEBUG_SUBSYS=ALL环境变量打开详细日志，如果日志里大量出现“connect timeout”，大概率是网络路径问题。

调度器的改进方向是给节点增加“网络分区”属性，把同一个ToR交换机下的机器归为一组，调度时尽量在组内满足任务需求。如果无法满足，宁可等待，也不要跨组硬凑。这也是很多平台从“能用”到“好用”的分水岭。

5.3 显存OOM：是任务问题还是隔离问题

在共享GPU的场景下，OOM不一定是任务本身需要太多显存，也可能是别的任务抢占了显存。排查时先用nvidia-smi看当前进程，再用dmesg查看是否有GPU相关报错。如果是调度器对分配出去的设备没有做严格隔离，一个任务可以动用整卡显存，那问题就在架构层。解决方案包括使用MIG实例，或通过容器的NVIDIA_VISIBLE_DEVICES限制，也可以升级使用NVIDIA vGPU方案，但vGPU一般要授权，开源调度时用MIG更常见。还有一点，有些图形界面应用比如ComfyUI，在Windows下没有走CUDA，导致任务全跑在CPU上，看起来显存没爆但速度特别慢，这种情况和调度器关系不大，更多是推理后端没正确安装。

5.4 抢占后被杀：训练怎么优雅断点续训

抢占本来是调度器保护高优任务的手段，但如果训练框架没有配合，抢占就会变成“事故”。我的经验是，在训练脚本里要周期性保存checkpoint，并且让调度器在抢占前发送SIGTERM而不是SIGKILL。Slurm支持PreemptMode=SIGTERM，给进程几秒时间处理。但训练框架自己也要能捕获SIGTERM，保存完状态再退出。如果训练框架没有这个机制，可以考虑用外部包装脚本，在收到信号时调用torch.save。

5.5 常见问题速查表

6. 运维体会：调度器之外，还有哪些“隐形老板”

6.1 GPU运维都做什么：从驱动到RMA

聊调度器绕不开一个基础问题：谁在维护这一万张卡？GPU运维远比想象中琐碎。从装驱动、升级CUDA、调BIOS参数，到监控温度、功耗、显存报错、机柜散热，还有定期和厂商对接RMA返修。调度器设计得再好，底下的物理设备老出问题也没用。我见过有团队把驱动装错，导致整机无法识别GPU，还要去机房排查，其实这些如果在装机时做好版本锁定是可以避免的。

在运维层面，还需要一个“硬件健康画像”。每张卡记录PCIe错误计数、ECC错误计数、降频次数，当计数异常时，调度器将该卡标记为“不健康”，不再分配新作业。很多硬件问题是有前兆的，做好预防性维护能减少训练中途掉线的概率。这是真正让万卡集群“稳定”的隐形底座，也是调度器能做出好资源决策的前提。

6.2 异构加速卡与调度器生态

不是只有NVIDIA GPU需要调度，昇腾等国产加速卡也越来越常见。昇腾有自己的CANN运行栈和Ascend Device Plugin，Kubernetes可以通过扩展资源上报昇腾卡数量。和NVIDIA类似，训练任务需要调度器感知芯片类型、显存、HCCS互联拓扑。如果公司同时有NVIDIA和昇腾，调度器模型必须抽象出“加速卡”这一类资源，并在设备层做异构管理。不要让上层任务直接绑定某一种卡，否则集群资源永远割裂。

6.3 调度器是训练场的隐形老板，但老板也需要“股东”

最后说一点个人体会。调度器再强，也只是体系中的一环。一套成熟的训练平台，还需要统一身份认证、配额管理、数据缓存管理、成本核算、模型仓库和可观测性。调度器负责“怎么分资源”，但“谁有资格拿”“拿了产生多少成本”“为什么任务又失败”这些问题，需要整个平台配合解决。

我在实际项目中踩过几次坑之后，越来越觉得调度器设计的核心不是调度算法本身，而是对整个训练流程的理解。比如一个算法工程师提交任务时，脑子里想的是“我要训练模型”，他不会关心Slurm有没有配置好GPU，也不会关心Volcano有没有为他的Pod完成Gang调度。但如果平台把这些底层逻辑都理清楚，他只需要提交一键任务，调度器在后台计算拓扑、配额、网络分区、检查点恢复路径，这才是真正的“隐形老板”。

所以，如果你正在搭训练平台，我建议别急着追赶最新调度框架，先把业务场景的优先级、任务类型、故障容忍度梳理清楚。调度器是选择出来的，更是配置和运营出来的。一张GPU是一分钱一分货，一万张GPU怎么排班，决定了你花出去的钱到底换回了多少模型迭代速度。这个隐形老板不好当，但一定要请好。