企业官网建设流程全解析

一万张 GPU 的集群说大不大，说小不小。说不大，是因为真正头部厂商的智算集群早已经是数万卡起步，一万卡在这个圈子里只能算“中等规模”；说不小，是因为真要把这一万张卡稳定跑满、让每个训练任务都按计划推进，背后需要解决的技术问题一点也不比万卡互联简单。上一章聊了分布式训练框架怎么做并行切分、怎么做集合通信，这一章我们得换个视角——从训练框架往上走一层，看看站在所有任务之上的“大管家”。

在大规模训练场景里，我越来越觉得调度器就是那个“隐形老板”。它不直接参与梯度计算，不碰模型参数，但它决定了一万个 GPU 什么时候给谁用、用多久、用完能不能要回来、任务挂了要不要重新排。你可以把训练框架想象成一支施工队，调度器则是排工程的甲方。施工队技术再好，甲方排期一塌糊涂，工地照样窝工。

所以这篇的核心话题就一个：大规模 GPU 集群的排班是怎么做的。我会结合实际运维经验，把调度器选型、队列设计、抢占机制、拓扑亲和、资源超卖这些核心问题一五一十拆开讲，附带一些日常排查案例，希望能给正在搭集群、做 AI Infra 的同学一些参考。

1. 调度器解决的核心问题：资源碎片与排队博弈

1.1 没有调度器的集群，是什么状态

先描述一个没上调度器的混乱场景。假设你手头有 100 张 A100，分给了 10 个算法工程师，每人填了个共享表格说自己要用卡，结果某个大模型训练任务一口气申请了 32 卡，但这 32 卡散落在四个物理节点上，节点间的网络带宽只有跨机的一半，结果 AllReduce 通信直接成了整个训练的性能瓶颈。

更麻烦的是，有一位同事训练到一半下班跑了，进程没结束，卡就那样被白占一个晚上。第二天早上模型训练卡在 NCCL 初始化超时，因为显存和 NVLink 拓扑全乱套了，新任务又在同一批卡上反复尝试。

这时候你就明白，调度器不是来“管理 GPU”的，它是在解决两个底层问题：

• 分配冲突：多任务争抢同一批算力资源时要有先后顺序和准入机制，不能靠人肉协调。
• 资源碎裂：任务需要的资源形态不一样，如果不管拓扑结构随便分卡，再大的池子也会很快碎成没法用的小块。

在万卡规模下，这两件事靠人工表或者简单的“谁先到谁用”已经无法搞定。算力资源是有空间属性的——一张卡在哪个节点、和哪张卡相邻、走什么样的网络拓扑，直接决定训练任务能不能跑起来、跑得快不快。

1.2 调度器到底在调度什么

很多人以为调度器调度的就是“显卡”。实际上，一次成功的调度涉及的资源起码有四层：

• GPU 算力与显存：最基础的资源，按卡、按显存粒度分配。
• 网络带宽与拓扑：特别是跨节点 AllReduce，是否被限定在 Leaf-Spine 结构的同一组叶子交换机下，关系到通信延迟。
• 内存与 CPU 资源：训练进程宿主机的 CPU 和内存往往容易被忽略，DALI 数据加载、PyTorch DataLoader 多进程都要吃 CPU，如果 CPU 挤爆，GPU 照样跑不满。
• 存储 IO：大量 checkpoint 写入、数据集读取对存储带宽有要求。如果多个任务同时高频写 checkpoint，存储会成为隐形的瓶颈。

因此调度器排班时，本质上是在多维资源约束下，找到一组满足某种策略的最优组合。卡数只是最显式的一维，可调度器真正要考虑的，是一整套“任务运行所需的最小资源闭包”。

1.3 三个硬指标：利用率、排队时间、恢复效率

我评估一套调度系统好不好用，从来不只看某个时刻的卡利用率，而是综合看三个指标：

• GPU 利用率：这个数字高不代表好，太低一定有问题。理想状态应该是长期在 60% 以上，大任务密集时期反倒是 70%-80% 比较健康。
• 排队等待时间：任务提交到真正开始运行之间的等待时长。实验性小任务等待时间要分钟级，大训练任务可以放宽到小时级，但不能毫无上限。
• 故障恢复效率：训练挂在某个节点上，探测到故障、重新调度、拉起新副本的时间。万卡规模下节点故障是常态，恢复效率直接决定有效训练时间。

调度器设计者的日常，本质上就是在权衡和优化这三个指标。比如为了利用率，你愿意让任务排队；但为了排队时间可控，你又得引入抢占，把低优先级任务赶走下去跑更重要的任务。

2. 调度器选型与整体设计思路

2.1 主流调度器横向对比：Kube-Scheduler、Volcano、Kueue、Slurm

在圈子里聊起调度器，大家默认先从开源主流的几个候选里选。我根据自己的实际使用经验和社区反馈，整理了一个对比：

我个人的判断是：如果你的集群是纯学术超算环境、用户习惯用srun/sbatch提交作业，Slurm 依然很合适。如果你想做的是内部 AI 平台，希望把镜像、服务发现、日志、监控全统一到 Kubernetes 体系内，那么走 Volcano 或 Kueue 会更顺手。

2.2 为什么我倾向于 Kueue 搭配其他组件

先说结论：目前的万卡集群我主要用 Kueue，搭配自定义的网络拓扑过滤插件。

理由主要有三个。

第一，Kueue 的项目定位很聚焦：只管队列和配额，不做具体 Pod 调度。真正把 Pod 落到某台机器上的还是 Kube-Scheduler。这种分层设计的好处是简单、职责单一。调度器的 bug 很难隔离，如果 Volcano 这种大而全的组件出了状况，整个集群的调度行为都受影响，排查范围太大。而 Kueue 的问题通常集中在队列不释放、配额计算错误这些边界，定位快。

第二，Kueue 对多租户场景的模型非常清晰。它用 ClusterQueue 管全局限额、LocalQueue 管团队请求，再把两者和 Workload 关联起来。理解成本比较低，新同学也能快速上手。

第三，Kueue 与 Kube-Scheduler 的配合更灵活。Kueue 只管“这个任务现在能不能调度”，至于调度在哪个节点、满足什么标签约束，它把决定权交给下一层。我们可以在 Kube-Scheduler 上做插件开发，比如加网络拓扑过滤、加节点 binpack 打分，这样功能扩展不用修改队列模型的代码。

当然，Kueue 也不是没有缺点。它默认不带抢占和排队策略，需要一个叫Preemption的 CRD 或搭配第三方组件才能实现更复杂的优先级驱逐。这也是权衡的结果——想轻量，就要牺牲一些开箱即用的完整度。

2.3 队列、配额与优先级：关系到“政治智慧”

调度器的技术选型只是一半，另一半更考验“政治智慧”。集群的使用者不会只有一组人，他们之间的利益和优先级经常互相冲突。

举一个典型场景：

• 算法团队 A 在生产环境训大模型，200 张卡跑三周。
• 算法团队 B 在跑短期实验，50 张卡跑几小时。
• 推理服务团队 C 希望 30 张卡稳定给在线服务兜底。

如果你把所有人放在同一条大队列里，后果必然是小实验任务插队、生产大任务被卡、在线服务高峰期算力被训练任务抢走。所以队列和配额必须做拆分。

我在实际设计队列时的原则是：

• 生产训练队列：独占配额，优先级高，不允许被抢占。这个队列的任务往往是跨迭代的长跑，杀掉重来损失太大。
• 实验开发队列：共享配额，优先级低，允许被抢占。这类任务通常能断点续跑，或者干脆不值得续跑。
• 推理在线队列：需要保证最小资源预留，不可被训练作业借走，避免在线延迟飙高。

这类设计在 Kueue 里直接对应 ClusterQueue 的admissionChecks和resourceGroups配置，你会看到为不同队列配置不同的namespaceSelector和resourceQuota，有效确保团队之间的算力隔离。关键就是不要让“需求不一致”的任务混在同一个队列里，否则调度器的策略再完善也发挥不出来。

3. 核心细节解析与实操要点

3.1 Gang Scheduling：全有或全无的刚需

做分布式训练的人大概率遇到过一个问题：一个需要 64 张卡的任务，集群当前只有 60 张可用。如果调度器先把这 60 张分给任务，任务开始跑，接着因为资源不足而卡死，其他任务也无法使用那 4 张卡，整个集群的资源调度进入死锁状态。

Gang Scheduling 就是为了解决这类问题。它的核心原则是：一个作业的所有资源必须全部到位，才会真正启动。要么全部分配成功，要么一个都不要。这样不会出现“任务占用了一半资源却跑不起来”的尴尬场景。

Kueue 对 Gang Scheduling 的支持是通过 Workload 的整体准入控制实现的。当一个 Workload 不能满足时，它不会部分接纳一个任务，而是整个任务继续排队。实践证明这样能显著减少资源悬置，代价是任务在大资源碎片下可能等待更久，但如果配合优先级抢占，整体调度效率依然是提升的。

实现 Gang Scheduling 的隐藏成本在于：调度器需要一次性计算的任务约束变多了，排队任务之间的比较逻辑也更复杂，如果不做优化，调度周期可能从毫秒级膨胀到秒级。这在大规模集群上是一个需要关注的问题。

3.2 拓扑感知：真正决定训练速度的存在

万卡集群里，调度器最容易被低估的能力是拓扑感知。如果只是按“某个节点有 8 个空闲卡”这种粗粒度来分配，训练作业的跨节点通信很可能成为性能灾难。

NVIDIA 的 DGX 机器单节点内部 8 卡通过 NVLink 互联，带宽极高，而跨节点走的是 IB 或 RoCE 网络。不同代际卡互联带宽差异巨大，A100 可能只有 400Gbps 到 800Gbps，H100/ A800 这些更高一些，但无论如何都比不上片间 NVLink 的 TB 级带宽。

因此调度器分配时应该考虑：

• 优先使用同一节点内的卡：一个 8 卡训练任务尽量全部落在同一个节点上，避免跨节点通信。
• 如果任务超过单节点规模，尽量落在同一列交换机或同一 Pod 内部：这样跨机通信经过的网络跳数更少，延迟更低。
• 避免异构混跑：如果一张 A100 和一个 A800 混在同一个多机任务里，通信速度会被拖到最低水平。

落实到操作上，我们会给每个节点打上标签，比如nvidia.com/gpu.product=A100、nvidia.com/node.network=leaf-01，然后在 Kube-Scheduler 的调度配置里加 NodeAffinity 和 topologySpreadConstraints，让调度器优先选择 tag 相同的节点。配置好的拓扑约束，对训练性能的影响往往比调整几个框架参数更大。

3.3 显存资源与超卖管理

GPU 的资源除了算力，显存是更稀缺的资源。ER 任务申请的是“一张卡”，但不同的模型对显存的需求差异巨大——几个 GB 的 batch size 实验，可能一个 7B 的模型 70GB 显存都不够。

调度器层面通常无法感知任务实时的显存使用，只能通过显式声明nvidia.com/gpu资源数量来分配。所以调度的粒度一般是“卡上”，而不是“显存 byte”。这就要求做容量规划的时候，按照任务的显存峰值来估算。

实际运维中，最头疼的是显存超卖问题。如果你允许每个节点上多个任务共享一张卡，比如用 CUDA MPS 或 MIG 隔离，调度器需要感知真正的显存可用量，否则会出现调度器认为节点有 8 张空闲卡，实际显存已经被某个常驻进程占了 60GB，任务一启动就 OOM。

最好的做法是在每个节点跑一个 GPU 监控 Agent，定时把每张卡的实际显存使用量上报给调度器的资源模型。当调度器做节点过滤时，除了看卡数，还要看显存余量。这个方案需要额外的开发成本，但长期来看是必须做的。

3.4 训练与推理混部：两种完全不同的排队逻辑

训练任务和推理任务对调度器的要求截然不同。训练任务是 long-running batch，有明确的开始和结束，可以容忍排队和重启；在线推理任务是实时服务，要么立刻有资源，要么拒绝用户请求，几乎不能等待。

我现在看到的互联网大厂普遍做法是分开集群：训练集群和推理集群物理隔离。如果你资源有限必须混部，调度器必须具备强大的优先级控制和抢占机制。

我建议在混部场景下给在线推理服务极高的优先级，同时为它设置不可抢占的配额，再用节点级污点把所有训练任务赶出推理服务所在的节点。切勿让训练任务和推理任务真正共处一张卡，即便技术上可行，实际效果也不好——推理延迟波动会大得让人无法接受。

4. 实操过程与核心环节实现

4.1 最小可用的 Kueue 队列配置

为了让大家直接落地，我分享一下目前我常用的 Kueue 配置思路。假设集群中有一个分给算法团队 A 的队列，配额为 128 卡，且不允许被抢占。

第一步，创建 ClusterQueue：

apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata: name: production-team-a spec: namespaceSelector: matchLabels: team: algorithm-a resourceGroups: - coveredResources: ["nvidia.com/gpu"] flavors: - name: a100 resources: - name: "nvidia.com/gpu" nominalQuota: 128 preemption: withinClusterQueue: Never reclaimWithinCohort: Never

第二步，创建 LocalQueue，并将其绑定到生产命名空间：

apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata: name: algorithm-a-queue namespace: algorithm-a spec: clusterQueue: production-team-a

在这之后，用户只需要在提交训练 Pod 时声明一个 Job 并关联这个 LocalQueue。调度器的行为大致是：Job 提交后生成 Workload，Kueue 检查 ClusterQueue 中是否还有配额，如果有则放行，由 Kube-Scheduler 完成节点绑定。配额满了就排队，排队的过程中如果相等优先级新任务进来，旧任务不会被挤掉。

这个配置最大的优势是简单直观。新团队接入时不用理解调度器内部的复杂机制，只需要记住“我的任务提交到什么队列，配额满了就等”。

4.2 抢占与优先级设计

生产集群上，低优先级任务和高优先级任务一般会混在同一个队列或 cohort 里。如果不做抢占，高优先级任务可能会在排队队列里等很久，因为低优先级任务永远在跑，空闲资源不足。

我在集群里启用了 Kueue 的Preemption特性，当高优先级任务进入队列时，如果配额不足，调度器会从队列中挑出优先级更低的任务驱逐，释放资源给新任务。

关键参数设计：

• PriorityClasses：定义high、medium、low三级，在生产队列中给大模型训练定义high，给周末要出的分析型任务定义low。
• PrioritySorting：Kueue 默认按创建时间和优先级排序，需要调整为Priority优先。
• Preemption Policy：只允许高优先级抢占low级别的任务，不允许high之间互相驱逐。

抢占机制不是没有代价的。任务被杀掉后，训练状态全在内存里，没有及时 checkpoint 的话，几小时乃至几天的训练进度就丢了。所以调度器层面做抢占，应用层面一定要做好频繁 checkpoint 的习惯，不然“隐藏老板”频繁裁员，员工会崩溃。

这里给一个优先级示例类定义：

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-training value: 1000 globalDefault: false description: "生产大任务优先级"

配合 ClusterQueue 的preemptionPolicy: Any使用，可以让高优先级任务插队。注意，value 越高优先级越高，但不能超过 1 亿（Kubernetes 限制），实际大家也不用设那么极端。

4.3 任务生命周期管理与自动恢复

大规模集群的常态是节点故障、网络抖动、显卡异常。调度器除了分配资源，还要负责“处置异常”。

Kubernetes 原生的机制是 Pod 失败后由 Controller 重建，但训练任务需要更精细的生命周期管理。比如：

• 一个任务运行 5 小时后遇到节点断电，调度器应该换一台机器重新拉起 Pod。
• 如果 Pod 连续重启 10 次，说明问题不是偶发性的，需要标记失败通知用户排查。
• 大任务 checkpoint 完成后，调度器可以感知到“上一个副本已经安全落盘”，这样可以减少重新拉起的风险。

大多数场景下，我会在训练框架侧配合使用RestartPolicy=OnFailure，同时把当前目录下的 checkpoint 和日志挂载到持久卷上。这样一来，即便任务被调度器打死，重新拉起时也能从最近的 checkpoint 续训，不会一切从零开始。

4.4 监控可视化：让调度器状态透明化

“隐形老板”再厉害，也得让员工知道自己的工位安排。监控可视化这件事不能只靠望着 Grafana 的空洞面板猜测。

我们在集群上搭建了三个层次的监控：

• 调度器层：Kueue 暴露了 Workload 的状态，包括 Pending、Admitted、Finished，通过指标拉取，能实时看到每个队列的等待时长。
• 节点层：除了 CPU/内存，重点监控每张 GPU 的利用率、显存占用、温度、NVLink 带宽。这几个值一起看，才能判断任务是否陷入通信瓶颈或显存不足。
• 作业层：跟踪每个训练任务的进度，比如迭代数、loss 曲线、checkpoint 时间。

调度器层的监控有一个特别关键的指标：排队时间中位数 vs P99。如果 P99 非常高，说明队列设计或配额分配存在问题——可能有少数任务被饿死了。把这个指标单独拉出来做告警，比看平均利用率更能反映调度健康度。

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

5.1 场景一：GPU 明明空闲，任务却一直 Pending

这个是最常见的报障。用户说“我的任务要 16 卡，集群明明有 20 卡空闲，为什么一直在排队”。

排查路径通常分三步：

1. 查调度器的资源视图：Kueue 的 ClusterQueue 显示当前已用配额是否达到上限。如果上限是 128 卡，现在用了 120 卡，你的 16 卡任务进来确实会 Pending——即使物理机上有足够空闲卡，因为“队列额度”已经满了。这是资源模型里最容易被误解的地方，配额和物理资源不是一回事。
2. 查节点污点与容忍：有些节点专门给推理服务打上了污点，训练任务不能打上去。检查节点上的Taints与任务的Tolerations是否匹配。
3. 查资源请求是否合理：有些用户申请了 16 卡但还额外申请了 500GB 内存，节点物理内存不足，导致卡空闲也无法分配。

经验之谈，大部分 Pending 问题出在第一步，也就是配额设计没有和物理资源对齐。

5.2 场景二：任务被抢占后频繁重建，进度反而更慢

高优先级抢占低优先级任务，这个机制听起来很美好。但实际操作中，我遇到过一种情况：低优先级任务被杀了，重新调度后又碰上另一个高优先级任务，又被杀了，反复几次，结果低优先级任务一直跑不完，高优先级任务也被拖累，整体吞吐反而下降。

解决思路：

• 引入“cooldown”机制，任务被抢占后至少等待 X 分钟才能再次调度。
• 给低优先级任务设置“最多被抢占次数”，超过后自动将这个任务放到更空闲的队列中避免频繁中断。
• 考虑用 checkpoint 周期与抢占时间做联动。如果任务 5 分钟前刚存过 checkpoint，失去一个卡并没有想象中那么痛；如果是 2 小时前，重新拉起代价就很高。

这个优化提示在调度器层面没有默认解决方案，需要平台团队根据自身业务对任务时延和恢复成本的容忍度自行配置。

5.3 场景三：上了调度器以后，集群利用率反而下降了

部分团队迁移到 Kubernetes + Kueue 后，发现 GPU 利用率反而比原来直接裸机使用低了不少。这通常是因为调度粒度变细了，但作业的请求策略没有跟着变。

举个例子：以前裸机场景下，用户可能整个节点一口气申请 32 卡，反正不用考虑配额和排队，捕获到的空间较大。上了调度器后，为了防止个人独占，平台把卡粒度切成一张一张。原本一个任务需要 32 卡，调度器拆成 8 个节点的碎片卡，每个节点通信拓扑不一致，利用率自然会下降。

这类问题解决路径有两条：

• 一个是尽量将分散的小卡请求合并到少数字段节点上，通过 binpack 策略提高节点内部卡密度。
• 另一个是教育用户正确申请资源。团队的资源配额应该按“任务峰值需求”申请，而不是按“自己希望长期占有的份额”申请。大任务不要贪多，小任务要及时释放，平台可以设置空闲资源自动回收策略。

5.4 场景四：调度器说资源够了，任务一跑就 OOM

这是非常典型的问题。训练任务申请了 4 张卡，模型加载时发现每张卡 80GB 显存不够用，直接就 OOM。Kueue 在调度时只看到“节点上有空闲卡”，但无法感知模型实际需要多少显存。

目前最实用的兜底方案是：

• 用户在申请资源的时候，显式声明nvidia.com/gpu.memory这类扩展资源（需要 gpu-device-plugin 配合）。
• 平台侧提供一个简单工具，根据用户提供的模型配置自动估算所需显存。比如 7B 模型 FP16 权重约 14GB，加上梯度和优化器状态约 4 倍到 5 倍，单卡推理大概 28GB，训练可能需要 56GB 甚至更多。

但必须说清楚，调度器不是算命先生，它只能依赖用户提供的资源声明。如果用户对自己的显存需求一无所知，平台再怎么样也救不了。比较实际的建议是设计一个“资源预算模板”，让用户通过几个下拉选项选择“模型规模”“并行策略”“batch size”，自动换算成推荐的卡数和显存要求，从源头减少误申请。

5.5 场景五：跨团队共享集群，调度器不公平怎么办

在多团队集群里，一定会有人抱怨调度不公平。最简单的公平性保障就是按团队设置硬配额，谁也不许超过。但有些时候，团队 A 的配额用不满，团队 B 需要临时借用，配额又不够。

一种相对公平的做法是引入“弹性配额”。ClusterQueue 支持borrowingLimit概念，超过硬配额的部分可以去其他队列借用，被借用方需要排队等待时，借用任务立即终止并归还资源。这类动态借用机制在 Kueue 的 cohort 设计中已经支持，但需要平台团队提前规划好哪些资源可以借、哪些不能借。

我见过不少团队天天吵计算资源，本质上不是调度器不行，而是“临时借用”的规则没有定义清楚。写清楚每一种资源的硬性上限、弹性上限、抢占优先级，争执就能减少 80%。

6. 写在最后：调度器不是万能的，但没有调度器万万不能

从我自己的经验来看，调度器这个角色在很多团队里被严重低估。大家一提分布式训练，首先想到的是那套看起来很有技术含量的并行框架，模型并行、流水线并行、混合精度训练，这些当然重要，但真正决定一个万卡集群能“跑出多少有效算力”的，往往是更上层、更不性感的调度层。

好的调度器能让你在用满算力的同时，还不让任何团队觉得被饥渴、被饿死、被抢走资源。它像足球场上的裁判，平时你可能感觉不到它的存在，可一旦它吹错一个哨、漏判一次犯规，整场团队的士气都会受影响。

如果你还在用人工表格管理 GPU 资源，我强烈建议尽快启动调度层的改造。不用一开始就追求万卡集群的复杂策略，先把“队列、配额、优先级、Gang Scheduling、抢占恢复”这几件事做扎实，就能解决 80% 的混乱问题。

至于更深层的“弹性算力”、“自动混合调度”、“碳感知调度”，那是未来的事。先把隐形老板立起来，后续的排班改革才有基础。

我自己在推进调度器改造的过程中，最大的收获倒不是技术上的，而是意识到了一个问题：日程排布上的公平，比技术上的绝对最优更重要。算力集群上跑的每一行代码背后都是一个个等待实验结果的工程师，调度策略不能只是一堆冷冰冰的分数公式，它还要照顾到人的预期和等待情绪。这也是为什么我一直强调队列语义和优先级设计要跟团队的真实需求对齐，而不是简单地把一堆任务丢进一个大池子里比谁跑得快。

这个是 AI Infra 系列第五篇的下半部分，主要聚焦“调度”。按照这个系列的规划，接下来会接着聊容量规划与成本控制，讲清楚怎么根据任务画像估算训练和推理分别需要多少 GPU、如何做算力成本的分摊预算，还有那些租用 GPU 去跑业务的同学最关心的“显存容量到底按训练还是推理来测算”的问题。下一章见。