## 一、先算一笔账：GPU 排队一小时，等于烧掉多少钱

如果你管过一个训练集群，下面这个场景一定不陌生：周三下午，三个团队同时提交作业——A 要 512 卡训大模型，B 要 64 卡微调，C 只要 8 卡跑实验。调度器该怎么排？先到先得？大作业优先？还是按配额公平分？

排不好就是纯烧钱。一张 H100 按市价算，一小时租金几十块，一个 512 卡的作业排队一小时，白烧的钱够吃一顿好的。更麻烦的是 GPU 之间的"排班"还有硬约束：多卡作业必须同时拿到所有卡才能开工（要么一起上，要么都不上）；卡与卡之间的物理位置决定了通信快慢，放错位置性能打骨折。

所以集群调度说白了就三件事：**哪张卡、什么时候、给谁**。三件事互相打架，调度器就是那个"拉架"的。

![fig11-scheduler-evolution.png](https://developer.qcloudimg.com/http-save/yehe-11479707/0eddaa8158f890c2b6689327b1f3584a.png)

## 二、K8s 调度 GPU 的十年：从"数设备"到"说需求"

2017 年之前，K8s 根本不知道 GPU 是什么。后来 NVIDIA 出了设备插件（Device Plugin），把 GPU 变成一种可计数的资源：`nvidia.com/gpu: 8`，调度器按"张"分配。这是第一代，够用，但很糙——只能按整卡分，不知道卡之间怎么连的，也不管 NUMA。

第二代是**拓扑感知**。K8s 拓扑管理器 + GPU Operator 用 GPU Feature Discovery 给每个 GPU 打标签（NUMA 节点、NVLink 域、PCIe 总线），调度多卡作业时尽量把卡安排在共享 NVLink 的同一服务器上。

第三代是 **DRA（Dynamic Resource Allocation，动态资源分配）**。打个**比**——DRA 像外卖平台：Pod 不再"数卡"，而是提需求（"我要 8 张卡、要 NVLink 互连、最好同 NUMA 节点"），由设备驱动（NVIDIA 的 DRA driver）响应"派单"。DRA 在 Kubernetes 1.34（2025 年 8 月）正式 GA，为 MIG 切片、DPU、可编程网络设备等异构资源打开了大门（来源：Kubernetes 官方博客）。2026 年 KubeCon EU 上，NVIDIA 把 DRA 驱动（含 GPU 调度相关组件）捐给了 CNCF，社区接管；同期 KAI Scheduler 进入 CNCF Sandbox（来源：KubeCon EU 2026 公告）。

但 DRA 解决的是"资源怎么给"，没解决"作业怎么排队"。排队是**配额与队列系统**的活：CNCF 生态里的 **Kueue**（K8s 原生工作负载队列）和 **Volcano**（华为 2019 年开源，2024 年底晋升 CNCF 毕业项目，Gang Scheduling 一等公民）。2025 年底 K8s 1.35 引入原生 Workload/PodGroup API（KEP-4671，alpha、默认关闭），实现了 Gang Scheduling 的核心逻辑，但生产环境目前还得靠 Volcano/Kueue 这类成熟方案（来源：Kubernetes 1.35 发布说明、Volcano 社区）。

**我的判断**：如果你是 2026 年从零搭集群，别再用裸 K8s 手搓调度了。DRA + Kueue（或 Volcano）是标准答案，前者管资源、后者管排队。

## 三、Gang 调度：要么一起上，要么都不上

大模型训练作业是"一损俱损"的：512 张卡里 511 张到了、1 张没到，作业也跑不起来，跑起来的卡还空占资源。这就是 **Gang Scheduling（组调度）** 要解决的问题——整个 Pod 组要么同时被调度，要么一起等。

为什么需要它？想象没有 Gang 调度会怎样：A 作业的 512 个 Pod 一个个被调度，前 400 个先占着卡等后面 112 个，而这些卡被 B 作业的小 Pod 见缝插针占走，最后 A 的 400 个 Pod 永远等不齐——**死锁**，卡白占，作业白等。Gang 调度就是把"整组"当成一个调度单元，凑不齐就不放行。

Gang 调度带来的收益在生产里往往是数量级的。Volcano + KubeRay 的多个生产案例分享都报告过类似的跃升：裸 K8s 时大量卡被"永远凑不齐的作业"占着，切换后利用率、排队时间、失败重跑率全面好转（具体数字因集群而异，见 Volcano 社区 2024-2025 年的若干案例讨论）。

![fig11-gpu-share.png](https://developer.qcloudimg.com/http-save/yehe-11479707/a617c31bad9518e11cdbf08de44e64a0.png)

## 四、拓扑感知：GPU 放错位置，性能差数倍

调度不只看"有没有卡"，还要看"卡在哪"。GPU 之间的通信带宽差异是数量级的：

| 通信路径              | 典型延迟       | 带宽量级                    |
| ----------------- | ---------- | ----------------------- |
| 同机同卡 NVLink（域内）   | ~100ns     | NVLink5 域内最高约 1.8TB/s/卡 |
| 机柜内 InfiniBand 子网 | ~200ns     | 800G（XDR）级              |
| 跨机柜/跨组网           | ~300-500ns | 视拓扑，明显衰减                |

（来源：NVIDIA NVLink 规格、2026 年调度相关技术分析）

**白话解释**：GPU 集群里的"距离"不是按米算的，是按纳秒算的。NVLink 域内的卡互相通信像邻桌说话，跨机柜就像隔了两条街喊话。一个 8 卡作业，如果 8 张卡在同一个 NVLink 域，通信开销极小；如果被调度器撒到 8 台机器上，每次梯度同步都要跨网络走一圈。

原书给了一个重要参考：在 NVLink5 NVL72 系统上，单机架 NVLink 域提供最高约 130TB/s 聚合双向带宽（每 GPU 约 1.8TB/s）。调度集合通信密集的训练作业时，要优先让流量留在快速 NVLink 域内，再考虑跨越较慢的网络（来源：*AI Systems Performance Engineering* 第 3 章）。

实操手段：

- K8s：拓扑管理器策略配 `single-numa-node`（最严格，全部资源来自同一 NUMA 节点）或 `restricted`，配 GPU Operator 的拓扑感知标签。
- SLURM：用 GPU 通用资源（Generic Resource）声明 GPU 挂载的 NUMA/NVLink 域，作业请求时指定"要同一 NUMA 的卡"（来源：*AI Systems Performance Engineering* 第 3 章 3.6.2 节）。
- 排错位置性能差距通常在**数倍**以上，具体取决于集合通信模式与拓扑跨度（NCCL 相关分析，2025-2026）。

**我的判断**：拓扑感知是最容易被忽略的"隐形税"。很多团队调度器一升级、节点一扩容，多卡作业莫名变慢，查半天发现是新节点拓扑标签没打对，GPU 被撒到不同 NUMA 域。建议把"拓扑标签正确性"写进集群验收 checklist。

## 五、SLURM vs K8s：训练和推理从来不是一套班子

传统分工很明确：**训练用 SLURM，推理用 K8s**。SLURM 是 HPC 世界的调度器，按"作业"排队、支持 Gang、支持 MIG 分区调度，多节点训练启停干净利落；K8s 是云原生世界的编排器，弹性扩缩容、服务发现、健康检查一应俱全，天然适合推理服务。

但混合趋势明显：

- **Volcano / KubeRay**：在 K8s 上补齐训练调度（Gang、队列、公平），让 K8s 也能跑好分布式训练。
- **CoreWeave SUNK**：实现 "Slurm-in-Kubernetes" 混合，把 SLURM 的作业管理嵌进 K8s 集群，兼顾两边的生态。
- 原书提到开源项目 Slinky 也做了类似的事：简化跨训练和推理工作负载的集群管理（来源：*AI Systems Performance Engineering* 第 3 章 3.6.2 节）。

**我的判断**：1000 卡以内，Volcano/Kueue + K8s 一套班子完全够用，别两套系统了；万卡级纯训练基地，SLURM 的成熟度和 HPC 生态（作业会计、记账、依赖管理）仍是优势，用 SUNK 这类方案做混合桥接是主流路径。

## 六、万卡架构：单集群的墙，和跨集群的桥

卡多了也有烦恼。单集群超过一定规模（原书和业界共识大约 5000 节点量级）会撞上三堵墙：

1. **调度墙**：调度器要处理的 Pod/作业状态爆炸，调度延迟失控；
2. **网络墙**：单集群全网状拓扑成本指数上升，集合通信的全局同步越来越难；
3. **故障墙**：规模越大，单位时间内必有节点出故障，作业中断成了常态而非例外。

于是 2025-2026 年的主流路线是**多集群联邦**：把万卡拆成若干个"千卡级"集群，每个集群内用 NVLink/IB 高速互连，集群之间用高带宽广域/数据中心间链路连接，配合统一的作业队列层（如 Kueue 的多集群模式）和全局存储（第三章的 3FS 这类）。

![fig11-federation.png](https://developer.qcloudimg.com/http-save/yehe-11479707/4c5d3ecb9b54743ad483fb1b4ffceeb4.png)

有个标杆数据：据多家媒体转述，OpenAI 在 2025 年披露的运营实践中提到其 2.5 万卡集群做到了约 **97% 的有效利用率**——注意这是"有效"利用率，不是 GPU 通电利用率，意味着把调度、故障、checkpoint、重启的损耗压到了 3% 以内。能做到这一点的前提，就是把下面第七节说的容错做到了极致。

**白话解释**：万卡集群像一支几万人的军队，光有兵力没用，得靠"连-营-团"的建制把指挥成本降下来。多集群联邦就是建制，97% 利用率就是纪律严明的结果。

## 七、容错：万卡训练不可能不挂，问题是挂了怎么办

先给个让人清醒的数字：一份 32K-GPU 规模的预训练部署报告（被 PHOENIX 论文 [arXiv:2607.01646](https://arxiv.org/abs/2607.01646) 引用为现场数据）统计，一次完整训练跑下来经历了 **678 次意外中断**，其中 **HBM 内存故障、PCIe 故障、NCCL watchdog 超时**三类合计占 **49.9%**——也就是说，一半的故障来自最"底层"的硬件和通信。万卡规模下，"不挂"是幻想，"挂了快速恢复"才是工程。

容错三板斧：

**① Checkpoint：异步 + 分布式是标配。** 同步 checkpoint（所有 rank 停下来等写盘）在千卡规模还能忍，万卡规模就是灾难。2026 年主流是异步 checkpoint（训练继续跑，后台写盘）+ 分布式分片 checkpoint（FSDP/DeepSpeed 把状态分片到各节点，各写各的，不再有"单点全量快照"）。DeepSeek 3FS 这类高性能存储进一步把 checkpoint 写盘时间压缩到分钟级（见第三章）。

**② 热替换 + 快速恢复。** 学术界和工业界都在做"零中断换卡"：比如 PHOENIX 提出的内存 checkpoint + hot-swapping 方案，把恢复时间压到 **约 40 秒**（512 卡 A100 集群验证，来源：arXiv:2607.01646，2026）。据 NVIDIA 官方口径，Resiliency Extension + Mission Control 自治恢复引擎可让恢复提速 10 倍（来源：NVIDIA 2026 发布）。

**③ 故障检测要快。** 据天翼云公开宣传，其「息壤」平台的万卡集群做到秒级故障检测、分钟级恢复。检测慢 10 分钟，一个 512 卡作业就多烧 10 分钟的钱，所以"故障发现速度"本身就是性能指标。

![fig11-failover.png](https://developer.qcloudimg.com/http-save/yehe-11479707/4baf02f9fd3aa8ecb42ad1739182f7bb.png)

## 八、监控与 AI 辅助运营：让集群自己"看门"

万卡集群人工盯不过来，监控 + AI 辅助是 2026 年的标配：

- **硬件监控**：DCGM（NVIDIA 数据中心 GPU 管理器）采集温度、功耗、显存 ECC 错误、SM 利用率等指标，喂给 Prometheus 体系。GPU 显存突然下降 = 内存泄漏或数据停顿，这类异常用阈值规则 + AI 辅助定位根因。
- **AI 排障副驾驶**：作业跑了一半失败，人工翻日志要几小时；AI 副驾驶消化日志 + 指标 + 警报，直接给结论——"节点 42 崩溃前有 5 个 ECC 错误，疑似 HBM 通道问题"，或"loss 在第 10000 步变 NaN，检查梯度裁剪"。Splunk/Cisco、PagerDuty 已经在用 AI 预测数据中心故障，扩展到 AI 工作负载专属遥测是自然延伸。
- **AI 调度代理**：观察整个集群状态，学习哪些作业可以共存（计算密集 + 内存带宽密集互补），动态调整资源分配，目标从"GPU 不闲着"升级为"GPU 忙在有用的神经计算上"——传统利用率指标会骗人，100% 忙在冗余数据传输上的 GPU 并不高效。

**我的判断**：别等万卡才上这套。几百卡的集群，DCGM + Prometheus + 一个 LLM 排障助手，能把故障定位从小时级压到分钟级，投入产出比极高。最贴合本书主题的地方——AI 帮助创造更好的 AI，性能工程师的角色从"手动拧每个旋钮"变成"设定目标和护栏、处理 AI 没见过的新情况"。

## 九、串起来：从单机到万卡的完整视角

第五章上下两篇其实是一条线：

- **单机**：NUMA 绑定、内存固定、GPU 持久化、MPS/MIG——把每张卡的性能榨干；
- **集群**：DRA 管资源、Kueue/Volcano 管排队、Gang 管整组、拓扑感知管位置、联邦管规模、checkpoint + AI 运营管容错。

这套方法论落到数字上就两行：调度浪费 30%，拓扑错位数倍——先拧这两个，胜过所有花哨优化。


## 参考资料

- Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media（第 3 章 K8s/SLURM 调度、第 20 章 AI 辅助集群运营）
- Kubernetes 官方发布记录（1.34 DRA GA、1.35 原生 PodGroup alpha）
- NVIDIA 2026 公告（GPU 调度组件捐赠 CNCF、Resiliency Extension、Mission Control）
- Volcano / Kueue 社区文档与 2025 年 1024 卡 H100 集群案例分享
- CoreWeave SUNK 项目文档
- OpenAI 2025 年工程分享（2.5 万卡集群运营，97% 有效利用率，媒体报道）
- arXiv:2607.01646（PHOENIX，内存 checkpoint + hot-swapping，2026）
- 2025-2026 年公开的 32K-GPU 预训练部署报告（678 次中断统计）
- 天翼云「息壤」公开技术分享（万卡集群故障检测与恢复）


如果你管过一个训练集群，下面这个场景一定不陌生：周三下午，三个团队同时提交作业——A 要 512 卡训大模型，B 要 64 卡微调，C 只要 8 卡跑实验。调度器该怎么排？先到先得？大作业优先？还是按配额公平分？

AI Infra 系列 · 第五章 训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板

单机调优解决"一台机器怎么跑得快"，集群调度解决"一万台机器怎么不浪费"。训练集群的调度器每天面对的问题：有的作业要 512 张卡，有的只要 4 张；有的必须整组一起上，有的晚 5 分钟也无所谓；GPU 放错机柜，性能能差 3-8 倍。这篇讲清楚从设备插件到 DRA 的调度演进、Gang 调度、拓扑感知、SLURM 与 K8s 的分工，以及万卡集群怎么容错、怎么用 AI 来运营。

运维开发工程师

人工智能

架构设计

开发工具

GPU集群调度优化指南：从裸K8s到DRA+Kueue/Volcano架构演进，Gang调度解决资源死锁，拓扑感知避免性能损失数倍。万卡集群需多集群联邦、容错checkpoint与AI辅助运维，将有效利用率提升至97%，监控故障定位从小时级压缩到分钟级。

数据中心

Kubernetes

服务器

云原生

2026上云采购 | AI焕新·智启新局

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Infra 系列 · 第五章 训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第五章训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板

AI Infra 系列 · 第五章训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第五章 训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板

AI Infra 系列 · 第五章 训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第五章训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板

AI Infra 系列 · 第五章训练与调度（下）：一万张 GPU 怎么排班，调度器才是训练场的隐形老板