1. 课程导入
大规模GPU集群的调度策略，是决定AI训练与推理成本、效率与稳定性的关键枢纽。在单机单卡时代，任务调度几乎不构成独立问题；但当集群规模扩展到数千甚至数万张GPU时，调度策略的优劣将直接导致数倍的算力利用率差异。本课程旨在系统性地拆解这一复杂命题，从底层硬件约束到顶层业务策略，建立一套完整的调度知识体系。
一、学习目标：从“能跑”到“跑得最优”
完成本课程后，学习者应具备以下四项核心能力：
- 诊断能力：能够通过监控指标与调度日志，快速定位集群利用率低下的根因（如碎片化、饥饿、死锁、拓扑感知缺失）。
- 设计能力：能够根据业务负载特征（训练/推理、在线/离线、周期性/突发性），选择合适的调度架构（集中式、两层式、共享状态式）与排队模型。
- 调优能力：掌握关键参数（如队列权重、抢占超时、binpack/spread策略）的调整方法，并理解其对端到端训练吞吐的影响。
- 扩展能力：理解调度器在万卡规模下的性能瓶颈，掌握分片、缓存、异步协商等扩展技术。
二、核心概念：调度问题的形式化拆解
在深入细节之前，我们需要建立一套统一的词汇表。GPU调度问题可以抽象为：在满足一系列约束条件的前提下，将一组任务（Jobs）映射到一组资源（GPU/Nodes）上，并优化某个目标函数。其核心概念包括以下五个维度：
| 概念维度 | 关键术语 | 说明 |
|---|---|---|
| 资源模型 | GPU型号、显存、显存带宽、NVLink拓扑、NUMA亲和性 | 资源不再是“一张卡”，而是具有多维属性的节点。调度必须感知物理拓扑。 |
| 任务模型 | 单卡任务、多卡分布式任务、任务间通信模式（PS/AllReduce）、优先级、抢占性 | 任务对资源的请求是多维向量（如8卡×40GB显存），且任务内部有依赖关系。 |
| 调度策略 | FIFO、容量、优先级抢占、公平共享（DRF）、Gang调度、Binpack/Spread | 决定“谁先跑”以及“如何放置”。 |
| 排队模型 | 单一队列、多级队列、加权公平队列、虚拟队列 | 决定任务等待的秩序与资源配额。 |
| 调度时机 | 事件驱动（任务到达/结束）、周期扫描、增量调度 | 影响调度延迟与系统开销的平衡。 |
其中，Gang调度（全有或全无）是大规模分布式训练中最关键也最具争议的概念。一个需要64张GPU的AllReduce训练任务，若只分配到63张，则任务无法启动，且这63张卡被无效占用。Gang调度要求所有资源同时就绪才下发任务，这虽然避免了“部分资源死等”，但也可能引发集群碎片化与饥饿问题。
三、整体框架：从物理拓扑到业务策略的四层视图
为了便于理解，我们将GPU集群调度系统拆解为四个逻辑层次。每一层解决不同粒度的问题，层与层之间通过标准接口交互。
+----------------------------------------------------------+
| L4: 业务策略层 (配额、优先级、公平性、抢占策略) |
| 输入: 业务SLA、部门配额、任务优先级 |
+----------------------------------------------------------+
| L3: 调度决策层 (匹配、放置、绑定) |
| 输入: 任务资源请求 + 集群实时状态快照 |
| 核心算法: 过滤(Filter) + 打分(Score) + 绑定(Bind) |
+----------------------------------------------------------+
| L2: 资源管理层 (节点状态、GPU分配/回收、拓扑感知) |
| 输入: 物理节点心跳、GPU健康状态、NVLink链路状态 |
+----------------------------------------------------------+
| L1: 物理资源层 (GPU、CPU、内存、网络、存储) |
+----------------------------------------------------------+本课程将按照自下而上的顺序展开：
- 第1-3章（本导入章节及后续）：建立问题定义与衡量指标（利用率、排队延迟、完成时间、碎片率）。
- 第4-8章：深入L1与L2层，讲解GPU拓扑结构（NVLink、NVSwitch、PCIe Switch）对调度决策的硬约束，以及资源管理中的“显存碎片”与“拓扑碎片”问题。
- 第9-15章：聚焦L3层，剖析主流调度算法（DRF、Gang、Binpack、Topology-Aware Placement）的数学原理与工程实现。
- 第16-22章：上升到L4层，讨论多租户场景下的配额管理、抢占式调度、弹性调度与任务排队优先级反转问题。
- 第23-27章：专项探讨故障恢复、GPU虚拟化/共享（MIG、时间片）、以及异构GPU混部场景下的调度挑战。
- 第28-30章：实战案例复盘与性能调优工具链（如DCGM、NVIDIA SMI、调度器Benchmark方法论）。
四、典型场景与案例：为什么调度策略如此重要？
让我们通过一个具体案例来感受调度策略的“威力”。假设某集群拥有128台8卡A100节点（共1024张GPU），同时提交了以下三类任务：
- 任务A：大模型预训练，需512张GPU，AllReduce通信模式，预计运行7天。
- 任务B：超参数调优，共100个小任务，每个需8张GPU，运行时间约1小时。
- 任务C：在线推理服务，需16张GPU，要求低延迟，长期运行。
若采用最简单的FIFO策略，任务A首先获得512张GPU，剩余512张GPU被任务B的64个小任务瓜分。此时任务C到达，发现剩余GPU虽多，但无法凑齐连续的16张卡（因为B任务已随机散布在集群中），导致C被迫排队。更严重的是，任务A的512张卡在7天内固定不变，而B任务不断结束释放资源，但这些碎片化的资源无法被任何新的大任务利用，集群利用率逐渐下降。
若采用Binpack策略（优先将任务填满尽可能少的节点），任务B的100个小任务会被集中调度到64个节点上，剩余64个节点完全空闲。当任务C到达时，可以轻松找到16张连续GPU。同时，空闲节点可以关闭或供其他离线任务使用。这一策略将集群的整体利用率从约60%提升至85%以上。
五、常见误区与复盘
在讲授调度优化时，我们经常遇到以下三类典型误区，这些也是本课程希望帮助学习者规避的“坑”：
利用率指标需要区分“时间利用率”与“空间利用率”。将GPU显存塞满但计算空闲，或计算繁忙但显存冗余，都是不健康的。调度优化应关注有效计算吞吐（MFU，Model FLOPs Utilization），而非单纯的GPU占用百分比。
当集群规模超过2000节点时，调度器的决策延迟可能成为瓶颈。一次全局最优匹配计算可能需要数秒，而任务排队等待调度的时间可能超过任务实际运行时间。此时需要引入分层调度或增量调度，而非一味追求全局最优。
抢占式调度可以解决高优先级任务被阻塞的问题，但频繁抢占会导致被抢占任务反复执行checkpoint与恢复，反而降低整体效率。合理的做法是结合预测性配额与优雅抢占（允许任务保存状态后再释放资源）。
六、本课程的实践环境与工具约定
为了便于后续章节的实操演练，我们统一约定以下实验环境与工具链。学习者无需完全复现，但理解这些工具的输出含义是必要的。
# 推荐实验环境
- 操作系统: Ubuntu 22.04 LTS
- GPU驱动: NVIDIA Driver 535.xx 及以上
- 容器运行时: NVIDIA Container Toolkit
- 调度器参考实现: Volcano (v1.9+), Kueue (v0.6+)
- 监控工具: DCGM-Exporter + Prometheus + Grafana
# 常用命令速查
nvidia-smi --query-gpu=index,memory.used,utilization.gpu --format=csv
dcgm dmon -i 0,1,2,3 -c 10 # 采集GPU指标
kubectl describe pod <pod-name> | grep -A 5 "Events" # 查看调度事件在后续章节中，我们将频繁使用“调度决策路径”这一概念。它指的是一个任务从提交到运行所经历的全部逻辑步骤：入队 → 过滤（Feasibility） → 打分（Optimality） → 绑定（Binding） → 启动。理解每一步的输入输出，是分析一切调度问题的基本功。
最后需要强调的是，GPU调度策略并非孤立的技术栈。它与上层业务负载特征（例如模型并行度、梯度同步频率）、下层物理网络拓扑（例如Fat-Tree vs. Dragonfly）紧密耦合。本课程将始终以“端到端训练性能”作为最终衡量标准，避免陷入纯理论优化的陷阱。