第8章：超大规模分布式训练

万卡训练不是”单机训练放大十倍”——它是一个完全不同的工程问题。从单机到 8 卡，加速比通常 7.x；从单机到万卡，能拿到 6000x 已经是顶尖水平。这中间损失的是什么？哪些是可工程优化的、哪些是物理极限？这一章把 3D 并行 + ZeRO/FSDP + MoE + Sequence Parallelism + 容错运维全部串起来——形成一份可执行的万卡训练运维指南，让 Goodput 从 25-30% 提到 75%+。

📑 目录

1. 万卡训练的真实工程画像
2. 3D 并行：TP / PP / DP 的工程切分
3. ZeRO Stage 1/2/3 与 FSDP
4. Sequence Parallelism 与 Ring Attention
5. MoE 训练：Expert Parallelism
6. 容错与可观测性
7. “训练突然变慢”排查 SOP
8. Goodput 25% → 75%+ 的工程化路径
自我检验清单
参考资料

1. 万卡训练的真实工程画像

1.1 为什么万卡比 8 卡难得多

8 卡训练大多数时候在一台 NVL72 节点内——通信走 NVLink，几乎零成本。

万卡训练涉及：

跨节点通信（InfiniBand / RoCE）—— 比 NVLink 慢 ~10x
跨机柜通信 —— 比柜内慢 ~3x
跨集群通信（多 AZ / 多 DC）—— 慢一两个数量级
故障率——10000 GPU 中每天故障 1-3 个是常态

这些因素的叠加，让万卡训练的真实”有效计算时间占比”（Goodput）通常只有 25-30%——剩下时间在通信、空闲、故障恢复。

1.2 Goodput 公式

$\text{Goodput} = \frac{\text{有效训练时间}}{\text{总 GPU 时间}}$

提高 Goodput 的三大支柱：

通信优化：3D 并行的切分 + ZeRO + Sequence Parallelism + Overlap
计算优化：CUDA / Tensor Core / FP8 / kernel fusion（Ch5-7 已讲）
可用性优化：故障恢复 / 抢占恢复 / 检查点

🌟 核心判断：万卡 Goodput 从 25% 到 75%+ 不是单一优化能做到——是上述三类合在一起的累积效应。

2. 3D 并行：TP / PP / DP 的工程切分

2.1 三种并行的角色

并行	切分维度	通信开销	适合切到哪
Tensor Parallel (TP)	矩阵切分	极高（每层）	柜内 NVLink
Pipeline Parallel (PP)	层切分	中（流水气泡）	柜间 InfiniBand
Data Parallel (DP)	数据切分	中（梯度 all-reduce）	柜间 / 跨柜

2.2 TP：矩阵层级切分

把一个 linear / matmul 切成多块：

列并行：A 切列，B 复制 → 输出切列
行并行：A 切行，B 切行 → 输出 all-reduce

每层 forward + backward 都需要 all-reduce / all-gather——高频通信。所以 TP 必须在 NVLink 内做。

2.3 PP：层级切分

把模型按层切成多段（stage）：

Stage 1: layer 1-8
Stage 2: layer 9-16
…

Stage 之间是流水线传递。问题：流水气泡（pipeline bubble）——前几个 step 后面 stage 没活干，最后几个 step 前面 stage 没活干。

气泡比例 ≈ (PP_size - 1) / (micro_batch_count + PP_size - 1)。 micro batch 越多气泡越小。

2.4 DP：数据切分

每张卡持有完整模型副本，处理不同 batch 数据，最后做梯度 all-reduce。优点：实现简单。缺点：模型必须装得下单卡。

2.5 3D 并行：组合切分

万卡训练通常组合三种：

TP=8（单机内 8 卡，NVLink）
PP=16（跨 16 个机柜）
DP=80（跨 80 个 PP group）
总卡数 = 8 × 16 × 80 = 10240

切分原则：

TP 切到柜内：高频通信走 NVLink
PP 切到柜外：通信稀疏，能容忍 IB 延迟
DP 切到最外层：异步通信能力最好

2.6 切分尺寸的工程经验

TP_size：通常 = 单机 GPU 数（A100/H100 8 卡）
PP_size：模型层数 / 期望气泡（通常 8-32）
DP_size：剩下的卡数

具体到 GPT-3 175B 的训练（典型 1024 GPU）：

TP=8, PP=8, DP=16 → 1024 总
每个 micro batch 会经过 8 个 PP stage
通常配 64-128 micro batches per macro batch 来让气泡可控

3. ZeRO Stage 1/2/3 与 FSDP

3.1 ZeRO 想解决什么

DP 的问题：每张卡都持有完整模型 + 优化器状态——模型 + Adam state 一起，实际显存 = 模型大小 × 4-12 倍。175B 模型 → 单卡需要 1+TB 显存。

ZeRO（Zero Redundancy Optimizer）的核心想法是：把这些副本切到不同的 DP rank 上——每个 rank 只持有一部分。

3.2 三个 Stage

Stage	切谁	显存节省	通信开销
ZeRO-1	优化器状态	4x	同 DP
ZeRO-2	+ 梯度	8x	同 DP
ZeRO-3	+ 参数	12-16x	DP × 1.5x

3.3 FSDP：PyTorch 原生 ZeRO-3

from torch.distributed.fsdp import FullyShardedDataParallel as FSDP

model = FSDP(
    model,
    sharding_strategy=ShardingStrategy.FULL_SHARD,  # ZeRO-3
    mixed_precision=MixedPrecision(...),
    cpu_offload=CPUOffload(offload_params=False),
    use_orig_params=True,
)

FSDP 的核心机制：

参数被切到所有 DP rank
forward 前 all-gather 当前 layer 的参数（其他 layer 的还在远端）
用完释放 → all-gather 下一 layer
反向时反向再做一次

这套机制把”参数副本”变成”按需加载”——单卡显存压力直接降到 ZeRO-1 的 1/4。

3.4 ZeRO 的代价

ZeRO-3 的通信开销比 DP 多 50%（多了 forward/backward 时的 all-gather）。在网络不够好的集群上，ZeRO-3 的 wall-clock 时间反而比 ZeRO-2 + 减小 batch 还差。

🌟 经验：H100 + 400G IB 集群上 ZeRO-3 通常能拿到 75-85% 的”理想可扩展性”；H100 + 200G IB 上要小心 ZeRO-3 的通信瓶颈。

4. Sequence Parallelism 与 Ring Attention

4.1 序列并行的动机

长上下文训练（>32K token）时，attention 的 $O(n^2)$ 让单卡装不下激活值。Sequence Parallelism 把序列维度切到多卡：

不切模型参数（DP/TP/PP 已经切了）
把 sequence dim 切到不同卡上
每张卡只管自己那段 sequence 的激活值

4.2 Ring Attention

Ring Attention 是 Sequence Parallel 的关键算法：

把 attention 计算改写成循环传 KV 段的形式
每个 GPU 同时算自己的 query 段 × 收到的 KV 段
一次循环就完成完整 attention，每张卡内存只装 1/N

类似分布式 GEMM 的 SUMMA 算法——流水线式地传 KV，让计算和通信完美重叠。

4.3 工程现实

Megatron-LM 提供 sequence parallel + tensor parallel 整合实现
DeepSpeed 提供 Ring Attention 实现
1M+ token 训练目前几乎都靠这条路径

5. MoE 训练：Expert Parallelism

5.1 MoE 的特殊挑战

Mixture of Experts 模型：

每层有 N 个 expert（FFN）
每个 token 只激活 K 个 expert（typically K=2 of N=8 或 64）
模型参数量大但单 token 计算量小

挑战：

如何把 expert 分到不同 GPU（Expert Parallelism）
如何把 token 路由到对应 expert 所在的 GPU（All-to-All 通信）

5.2 All-to-All 通信

每个 step 中 token → expert 的路由是 token-level 决定的——每个 GPU 都要把自己的 token 发到所有可能的 expert GPU。这需要 All-to-All 集合通信原语。

工程上的关键：Expert 分布要”伪均匀”——如果某个 expert 被 token 选中的频率高于其他，那张 GPU 会成为瓶颈。

5.3 EP × DP × PP 的混合

实际工程：

EP: 把 expert 切到多个 DP group
每个 DP group 持有部分 expert
All-to-All 在 EP group 内发生

5.4 计算 / 通信重叠

把 All-to-All 的 token 发送和 attention 计算重叠：

当前 layer 的 attention 计算时
异步发起下一 layer 的 token routing All-to-All

DeepSpeed-MoE / Megatron-MoE 都做了这个 overlap——典型能拿到 1.5x 加速。

6. 容错与可观测性

6.1 故障率的现实

10000 GPU 训练 30 天 = 7.2 百万 GPU-小时。即使单 GPU MTBF 是 100 万小时（极理想），也意味着整个训练过程会发生 7+ 次硬件故障。如果每次故障重启需要几小时，故障恢复就吃掉 10%+ 的训练时间。

6.2 检查点策略

频率	优点	缺点
每 100 step	快速恢复	IO 开销大
每 1000 step	平衡	故障损失最多 1000 step
每 10000 step	几乎无 IO 开销	故障损失大

工程经验：每 500-1000 step，且使用 async checkpoint（写盘和训练重叠）。

6.3 In-memory checkpoint

把检查点存在另一台机器的 DRAM 里——故障时从 DRAM 拉，而不是从慢磁盘拉。Megatron 的 in-memory checkpoint 实现把恢复时间从 30 分钟降到几分钟。

6.4 抢占恢复

云上训练经常碰到 spot instance 抢占——给的 preemption notice 可能只有 30 秒。需要：

快速序列化 checkpoint
把 state 写到外部存储（远端 DRAM 或 NVMe）
新机器启动时反序列化

6.5 大集群可观测性

万卡集群必备的监控：

DCGM（NVIDIA Data Center GPU Manager）：收集每张卡的 GPU/SM/HBM 利用率、温度、ECC error
Prometheus + Grafana：聚合到集群级 dashboard
NCCL log：通信失败排查
Job-level dashboard：每个训练任务的 Goodput、loss 曲线、checkpoint 状态

7. “训练突然变慢”排查 SOP

万卡训练里最常见的痛苦——某天 step time 突然从 5 秒变成 8 秒，没有人改代码。这一节给一份排查 SOP：

7.1 Step 1：确认是不是真的变慢了

是某个 step 突变还是渐进变慢？
看 wandb / tensorboard 里的 step time 时间序列
是不是同一个 wall clock 时刻（比如某个机柜的网络维护）？

7.2 Step 2：找到 stragglers

万卡训练里 step time = max(各 rank 的 step time)。一个 rank 慢就拖累全集群。

import torch.distributed as dist

# 在 step 末尾记录 per-rank 时间
local_time = step_end - step_start
all_times = [None] * dist.get_world_size()
dist.all_gather_object(all_times, local_time)

if dist.get_rank() == 0:
    if max(all_times) > 1.5 * min(all_times):
        slow_ranks = [i for i, t in enumerate(all_times) if t > 1.2 * min(all_times)]
        log(f"Slow ranks: {slow_ranks}")

7.3 Step 3：检查可能根因

根因	表现	排查方法
单卡硬件降频	个别 rank 持续慢	DCGM 看温度、降频事件
网络劣化	集群级慢，特定通信慢	NCCL `NCCL_DEBUG=INFO` log + 网络拓扑图
文件系统慢	DataLoader / checkpoint 慢	iostat、Lustre / Ceph 客户端日志
OS 调度	整体抖动大	top / pidstat / numactl 检查
内核 OOM	进程被 kill	dmesg、内核 log