1. 课程导入：AI算力集群的背景、挑战、学习目标与课程框架
1.1 为什么我们需要AI算力集群？
过去十年，人工智能模型的参数量以惊人的速度增长。2018年，BERT-Large的参数量约为3.4亿；2020年，GPT-3达到1750亿；而到了2023年，GPT-4等超大模型的参数规模已突破万亿级别。与此同时，单张GPU的显存容量和计算速度虽然也在提升，但远远跟不上模型规模的增长速度。以NVIDIA A100 80GB为例，即使使用最先进的张量并行技术，单卡也无法承载一个千亿参数模型的完整训练。
这种“模型规模增长”与“单卡算力上限”之间的剪刀差，催生了AI算力集群的必然性。我们不再依赖单台服务器，而是将数十、数百甚至数千张GPU通过高速网络（如InfiniBand、RoCE）连接起来，形成一个统一的、可弹性调度的算力资源池。这个资源池需要能够同时支撑多个训练任务、推理服务以及数据预处理作业，并且要保证每一块GPU都被高效利用。
核心矛盾：模型需要“大”，单卡做不到“大”，因此必须“连起来”。但“连起来”之后，如何分配、调度、均衡负载，就成了新的核心问题。
1.2 分布式调度与负载均衡面临的真实挑战
当我们把目光从单机转向集群时，一系列新的问题浮出水面。这些问题并非理论上的假设，而是在实际生产环境中反复出现的痛点。
- 资源碎片化：集群中不同任务申请GPU数量不同（如一个任务要8卡，另一个要2卡），如果调度策略不当，会导致集群中出现大量“零散”的空闲GPU，无法组合成新的任务所需的大块资源。例如，一个节点有8张卡，任务A占用了3张，任务B占用了2张，剩余3张卡既无法满足一个需要4卡的新任务，也无法满足一个需要8卡的任务，造成资源浪费。
- 网络拓扑感知缺失：并非所有GPU之间的通信速度都是相等的。在同一节点内，GPU通过NVLink通信，带宽可达600GB/s；跨节点通过InfiniBand，带宽通常为200-400Gb/s（约25-50GB/s）；而跨机架通信延迟更高。如果调度器不考虑拓扑，将需要频繁通信的GPU对分配到不同的机架，训练效率将急剧下降。
- 多租户争抢与公平性：在共享集群中，多个团队（如算法团队A、B、C）同时提交任务。如果没有合理的配额和优先级机制，一个大型任务可能会“饿死”其他小任务，或者多个任务之间互相争抢网络带宽，导致整体吞吐量下降。
- 故障感知与自愈：集群规模越大，硬件故障的概率越高。一块GPU的温控失效、一条光模块的松动、一次网络拥塞，都可能导致训练任务中断。调度系统需要能够快速感知故障，并将任务迁移到健康节点，同时保证迁移过程中不丢失训练进度（依赖checkpoint机制）。
- 异构算力兼容：集群中可能同时存在A100、H100、V100甚至国产加速卡（如昇腾、寒武纪）。不同型号的算力、显存、通信带宽各不相同，调度器需要根据任务对精度的要求（FP16/BF16/FP32）和显存需求，智能匹配最合适的硬件。
| 挑战维度 | 典型表现 | 后果 |
|---|---|---|
| 资源碎片化 | 空闲GPU分散，无法组合成大块资源 | 集群利用率低，任务排队时间长 |
| 拓扑感知缺失 | 跨机架通信频繁，网络成为瓶颈 | 训练速度下降30%-50% |
| 多租户争抢 | 大任务独占资源，小任务饥饿 | SLA无法保障，团队间冲突 |
| 故障自愈慢 | 单卡故障导致整个任务重启 | 有效训练时间（Goodput）降低 |
| 异构算力匹配 | 高精度任务被调度到低算力卡 | 算力浪费，成本上升 |
1.3 学习目标：学完这门课，你将掌握什么？
本课程不局限于理论讲解，而是围绕“生产环境中的真实调度系统”展开。学完本课程后，你将具备以下能力：
- 理解主流调度架构：能够清晰阐述集中式调度器（如Kubernetes + kube-scheduler）、两级调度器（如Mesos、YARN）以及共享状态调度器（如Omega）的架构差异与适用场景。
- 掌握核心调度算法：深入理解并能够实现或配置常见的调度策略，包括：深度优先调度（Depth-First）、广度优先调度（Breadth-First）、最佳适配（Best-Fit）、拓扑感知调度（Topology-Aware）以及基于作业完成时间预估的DRF（主导资源公平）算法。
- 具备负载均衡实操能力：能够使用NVIDIA DCGM、Prometheus + Grafana等工具监控集群GPU利用率、显存占用、NVLink带宽、PCIe流量等指标，并据此调整调度策略或进行手动干预。
- 掌握弹性伸缩与容错机制：理解如何在训练过程中动态调整Worker数量（弹性训练），以及如何配置自动故障恢复（如PyTorch的torchrun + etcd实现节点故障自动重启）。
- 能够进行性能调优与排障：当训练任务出现“GPU利用率低”或“通信瓶颈”时，能够快速定位是调度问题、网络问题还是代码问题，并给出解决方案。
课程定位：这是一门“工程实践导向”的课程。每一章都会结合开源工具（如Volcano、Kueue、Ray）和真实案例（如大模型训练、推荐系统推理）来讲解，确保你学到的知识可以直接落地到自己的集群环境中。
1.4 课程框架与学习路径
本课程共分为五个模块，共30章，内容层层递进。建议按照顺序学习，但对于有经验的工程师，也可以根据目录选择性跳转。
为了让你对整体脉络有直观认识，下图展示了本课程的核心知识模块与它们之间的依赖关系：
从上图可以看出，课程设计遵循“基础 → 算法 → 工程化 → 调优 → 实战”的递进路径。模块一和模块二构建你的理论基石，模块三和模块四赋予你工程实操能力，模块五则通过完整的案例（如千卡集群上的GPT类模型训练）将前四个模块的知识融会贯通。
1.5 学习建议与常见误区
在开始正式内容之前，有必要先澄清几个常见的认知误区，这些误区可能会影响你对后续章节的理解：
误区一：认为“调度 = 排队”。很多人以为资源调度就是FIFO（先来先服务），谁先提交谁先跑。实际上，现代调度器需要同时考虑优先级、配额、亲和性、拓扑、抢占等多种因素，是一个多目标优化问题。单纯排队会导致集群利用率极低。
误区二：忽略“通信”与“计算”的耦合关系。分布式训练中，通信时间与计算时间严重重叠。如果调度时只考虑GPU计算资源，不考虑网络拓扑，那么即使GPU利用率显示100%，实际有效计算时间（Goodput）可能只有60%。调度器必须理解“通信域”的概念。
误区三：把负载均衡等同于“平均分配”。真正的负载均衡不是让每张卡的使用率都恰好是50%，而是根据任务特性（如数据并行、模型并行、流水线并行）动态调整，避免出现“木桶效应”——即某一张卡成为瓶颈，拖慢整体速度。
学习建议：本课程涉及大量分布式系统概念。建议在学习过程中，每学完一种调度算法，就尝试在本地用模拟器（如Batsim）或小型集群（3-4台机器）进行验证。理论与实践结合，才能真正理解调度器的行为逻辑。