Distributed Training

分布式训练

并行策略 · ZeRO/FSDP · 梯度同步 · NCCL 通信优化 · 排障面试题

trainingparallelismzerofsdpncclinterview

Module Switcher

分布式训练学习模块

并行策略3

显存与通信2

面试与排障2

内容模块

并行策略总览

基础★☆☆⏱ 12 min

一句话结论

分布式训练并行策略的总公式是总 GPU 数由 DP、TP、PP 等维度相乘决定。

复习定位

维度	内容
所属模块	分布式训练
章节类型	机制类
解决问题	围绕数据并行、张量并行、流水线并行、ZeRO/FSDP、NCCL 和训练排障建立大模型训练系统答案。
面试抓手	先画并行维度，再讲通信和显存代价。

先把分布式训练看成四个问题

分布式训练不是“卡越多越快”，而是在多张 GPU 之间拆分数据、模型、训练状态和通信。读这一页时先建立地图：模型放不下看显存拆分，单层太大看张量并行，层数太多看流水线并行，吞吐不够再扩大数据并行。

数据怎么拆DP/DDP 让每张卡处理不同 batch，通过 AllReduce 同步梯度。

模型怎么拆TP 切层内矩阵，PP 切层间 stage，EP 切 MoE 专家。

状态怎么拆ZeRO/FSDP 把参数、梯度、优化器状态从“每卡完整保存”变成“分片保存”。

通信怎么放TP 优先节点内 NVLink，PP/DP 更适合跨节点，NCCL 决定通信效率。

一张表先看清每种并行

策略	解决什么问题	核心通信	放置直觉	细节位置
DP / DDP	扩大吞吐，吃更多数据	每步 AllReduce 梯度	拓扑要求相对低，可跨节点	数据并行与梯度同步
TP	单层矩阵太大或单层计算太重	每层 AllGather / ReduceScatter	尽量放在同节点 NVLink/NVSwitch 内	张量并行与流水线并行
PP	模型层数太多，整模型放不进单卡	相邻 stage 传激活和梯度	可以跨节点，但要减少 stage 间跳数	张量并行与流水线并行
EP	MoE 专家分布在不同 GPU	All-to-All	需要高 bisection bandwidth	NCCL 与通信优化
ZeRO / FSDP	参数、梯度、优化器状态占显存太多	AllGather / ReduceScatter	通常作为 DP 的显存优化层	ZeRO / FSDP

选型路径

分布式训练选型可以按“先能放下，再跑得快，再排得好”的顺序判断，不要一开始就堆所有并行策略。

单卡能放下模型状态吗不能就上 ZeRO/FSDP单层仍太大就上 TP层数太多就上 PP吞吐不足再扩大 DP

判断问题	优先方案	原因
模型状态放不下	ZeRO-2 / ZeRO-3 / FSDP	先减少每卡必须常驻的训练状态
单层参数或 attention 太大	TP	把层内矩阵切到多张卡上计算
层数太多、激活峰值高	PP + activation checkpointing	把不同层放到不同 stage，降低单卡常驻压力
模型能放下但吞吐不够	DP / DDP	复制模型副本，吃更多数据
MoE 专家很多	EP	专家分布式放置，按 token routing 通信

3D 并行的拓扑放置

大模型训练常见组合是 TP × PP × DP。总 GPU 数满足：

$$\text{Total GPUs} = TP \times PP \times DP$$

放置原则比公式更重要：TP 的通信最频繁，优先限制在单节点高速互联内；PP 只在相邻 stage 传激活，通常可以跨节点；DP 每步同步梯度，频率低于 TP，可以放在最外层扩吞吐。

并行维度	推荐位置	为什么
TP	节点内 4/8 卡	每层多次通信，跨节点延迟和带宽都容易成为瓶颈
PP	跨节点 stage	通信量主要是激活和梯度，低于 TP
DP	多条 pipeline 副本之间	每步同步一次梯度，适合做吞吐扩展

读这个模块的顺序

先读本页总览，理解每种并行策略解决的问题；再读数据并行，掌握 AllReduce 和梯度同步；然后读 TP/PP，理解层内和层间切分；最后读 ZeRO/FSDP 与 NCCL，把显存和通信问题串起来。

只想建立框架：读本页总览和选型路径。
要算通信量：读数据并行与 NCCL 两个 Tab。
要讲大模型训练配置：读 TP/PP 和 ZeRO/FSDP。
要准备面试排障：读排障与面试计算题。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

数据并行与梯度同步

进阶★☆☆⏱ 15 min

一句话结论

数据并行每卡保存完整模型、处理不同数据，并通过 AllReduce 同步梯度。

复习定位

维度	内容
所属模块	分布式训练
章节类型	机制类（含公式）
解决问题	围绕数据并行、张量并行、流水线并行、ZeRO/FSDP、NCCL 和训练排障建立大模型训练系统答案。
面试抓手	公式重点是梯度大小和 Ring AllReduce 每卡流量。

数据并行：最常见、也最容易被低估的并行方式

数据并行（Data Parallelism, DP）的核心是：每张 GPU 持有一份完整模型，处理不同数据分片，每个 step 后同步梯度，保证所有副本参数一致。它的优点是实现简单、扩展直观；缺点是模型和优化器状态仍然需要每卡完整保存，通信瓶颈集中在梯度同步。

DP / DDP 基础链路

阶段	每张卡做什么	通信行为	面试重点
Forward	用本地 mini-batch 计算 loss	通常无跨卡通信	每卡模型副本完整
Backward	计算本地梯度	梯度 bucket ready 后启动 AllReduce	DDP 会按 bucket 重叠通信和反向计算
Optimizer Step	用同步后的梯度更新参数	无额外通信或少量状态同步	所有副本参数保持一致
Next Step	读取下一批数据	重复上述过程	DataLoader/I/O 也可能成为瓶颈

梯度同步通信量

如果模型参数量为 P，每个梯度用 FP32 表示，即 4 bytes/parameter，则一次梯度张量大小约为：

$$\text{Gradient Size} = P \times 4 \text{bytes}$$

Ring AllReduce 中，每张卡的网络收发总量近似为：

$$\text{Traffic per GPU} = 2 \times (N - 1) / N \times \text{Gradient Size}$$

当 N 很大时，近似为：

$$\text{Traffic per GPU} \approx 2 \times P \times 4 \text{bytes}$$

通信-计算重叠：DDP 性能的关键

DDP 不会等所有梯度都算完才统一通信，而是把参数分成多个 bucket。某个 bucket 的梯度 ready 后就立刻 AllReduce，同时后面的层继续反向计算。

机制	作用	风险
bucket	把小梯度合并成较大通信块	bucket 太小启动开销高，太大重叠差
overlap	通信隐藏在 backward 计算后面	如果网络慢或模型小，仍然暴露通信尾巴
gradient accumulation	多次 backward 后再同步	有效 batch 变大，可能影响收敛
no_sync	累积期间禁用 DDP 同步	忘记恢复同步会导致参数不一致

Q: 数据并行为什么需要 AllReduce？AllReduce 同步的到底是什么？

回答思路：先说明每卡看到的数据不同，再说明梯度平均的数学意义，最后解释 AllReduce 的工程价值。

1. 每张卡的梯度不同

DP 中每张卡处理不同 mini-batch，算出的本地梯度只代表本地数据。如果直接各自更新，模型副本会逐渐发散。

2. AllReduce 做全局平均

AllReduce 会把所有 GPU 的梯度求和并广播回每张卡，通常再除以 world size，得到等价于更大 batch 上的平均梯度。

$$g = (g_1 + g_2 + ... + g_n) / N$$

3. 为什么不是 Parameter Server

AllReduce 是去中心化集合通信，没有单点参数服务器瓶颈，适合 GPU 间高带宽同步。

面试口径：DP 同步的是梯度，AllReduce 让每张卡拿到全局平均梯度，从而保持模型副本一致。

Q: 梯度累积和增大 batch size 是一回事吗？

回答思路：先讲等价条件，再讲差异和副作用。

1. 计算上接近等价

如果累积 k 个 micro-batch 后再做 optimizer step，在不考虑 BatchNorm、dropout 随机性和数值误差时，接近于把 batch size 扩大 k 倍。

$$\text{Global Batch} = \text{micro\_batch} \times \text{gradient\_accumulation\_steps} \times \text{data\_parallel\_size}$$

2. 通信频率下降

累积期间可以不做 AllReduce，等 k 次 backward 后再同步一次，通信频率降低为原来的 1/k。

3. 收敛可能变化

有效 batch 变大后，学习率、warmup、梯度裁剪、loss scale 都可能需要重新调参。

面试口径：梯度累积是用时间换显存和通信频率，数学上接近增大 batch，但优化动态可能变化。

Q: 一个 7B 模型做 DP 训练，8 卡，每步梯度 AllReduce 的通信量大约是多少？

回答思路：明确参数量、梯度 dtype、Ring AllReduce 公式，再代入计算。

1. 梯度大小

7B 参数，如果梯度用 FP32 保存，则梯度张量约为：

$$7 \times 10^9 \times 4 \text{bytes} = 28 \text{GB}$$

2. Ring AllReduce 每卡流量

8 卡 Ring AllReduce 每张卡收发总量约为：

$$2 \times (8 - 1) / 8 \times 28 \text{GB} = 49 \text{GB}$$

3. 解释结果

这不是总集群流量，而是每张 GPU 网卡/互联上的近似收发量；如果网络带宽不足，这部分会成为 step time 的尾部。

面试口径：7B FP32 梯度约 28GB，8 卡 Ring AllReduce 每卡约 49GB 收发量。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

张量并行与流水线并行

精通★☆☆⏱ 18 min

一句话结论

张量并行切层内矩阵，流水线并行切层间 stage，两者解决的瓶颈不同。

复习定位

维度	内容
所属模块	分布式训练
章节类型	机制类
解决问题	围绕数据并行、张量并行、流水线并行、ZeRO/FSDP、NCCL 和训练排障建立大模型训练系统答案。
面试抓手	TP 看 NVLink，PP 看 bubble。

张量并行与流水线并行：一个切层内，一个切层间

张量并行（TP）解决“单层矩阵太大或单层计算太重”的问题；流水线并行（PP）解决“层数太多、整模型放不进单卡”的问题。二者经常组合：TP 放在节点内 NVLink 域，PP 可以跨节点。

TP vs PP 对比

维度	张量并行 TP	流水线并行 PP
切分对象	每层矩阵、attention head、MLP 中间维度	模型层序列
通信模式	AllGather、ReduceScatter、AllReduce	相邻 stage Send/Recv
通信频率	每层多次，频率极高	每个 micro-batch 跨 stage 传激活/梯度
拓扑要求	强，优先 NVLink/NVSwitch	中等，可以跨节点但要减少跳数
主要风险	跨节点 TP 会极慢	pipeline bubble 降低利用率

TP 的矩阵切分直觉

以线性层 Y = XW 为例，列并行把 W 按输出维度切成多份：

$$W = [W_1, W_2, ..., W_t]$$

$$Y_i = XW_i, Y = \operatorname{concat}(Y_1, Y_2, ..., Y_t)$$

行并行则把输入维度切分，局部结果需要 ReduceScatter 或 AllReduce 合并。

PP 的 Bubble 公式

流水线并行把 batch 切成 m 个 micro-batch，在 p 个 stage 上流动。1F1B 调度下，理想 bubble 比例可近似为：

$$\text{Bubble Rate} = (p - 1) / (m + p - 1)$$

所以 stage 越多 bubble 越大，micro-batch 越多 bubble 越小。但 micro-batch 数受 global batch size、显存和收敛约束限制。

Q: 为什么 TP 一般要求放在同一台机器内？

回答思路：先说明 TP 通信频率高，再比较 NVLink 和跨节点 IB 的带宽/延迟差异。

1. TP 每层都通信

TP 不是每 step 通信一次，而是每一层 forward/backward 都可能 AllGather 或 ReduceScatter。96 层模型一轮训练可能触发数百次集合通信。

2. 频率比通信量更致命

跨节点网络不仅带宽低于 NVLink，还会增加延迟。频繁的小/中等消息会被延迟放大。

3. 放置原则

通常 TP 度不超过单节点 GPU 数，例如 8×A100 节点上 TP=8，跨节点部分交给 PP 或 DP。

面试口径：TP 是高频层内通信，必须尽量放在 NVLink/NVSwitch 域内；跨节点 TP 通常是性能灾难。

Q: Pipeline Bubble 怎么计算？如何降低？

回答思路：先给公式，再解释 p 和 m 的影响，最后给工程优化手段。

1. Bubble 公式

1F1B 调度下近似：

$$\text{Bubble Rate} = (p - 1) / (m + p - 1)$$

p 是 stage 数，m 是 micro-batch 数。

2. 例子

如果 p=4、m=12：

$$\text{Bubble Rate} = 3 / (12 + 4 - 1) = 20%$$

3. 优化方式

增加 micro-batch、减少 PP stage、使用 interleaved 1F1B、平衡每个 stage 的层数和计算量。

面试口径：PP 的核心开销是 bubble，stage 越多越差，micro-batch 越多越好，但受 batch size 和显存限制。

Q: 32 张 GPU，TP=8、PP=2，那么 DP 是多少？应该如何放置？

回答思路：先用公式算 DP，再给拓扑放置原则。

1. 计算 DP

总 GPU 数等于三种并行度乘积：

$$\text{Total GPUs} = DP \times TP \times PP$$

$$DP = 32 / (8 \times 2) = 2$$

2. 放置方式

如果每节点 8 卡，则每个 TP group 正好占一台机器；两个 PP stage 占两台机器；DP=2 表示有两条完全相同的 pipeline 副本，总共 4 台机器。

3. 面试补充

TP group 内通信走 NVLink，PP stage 间走 IB，DP 同步梯度频率较低，可以跨 pipeline 副本做 AllReduce。

面试口径：DP=总卡数/(TP×PP)，这个例子是 DP=2；TP 放节点内，PP/DP 才跨节点。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

ZeRO / FSDP

精通★☆☆⏱ 18 min

一句话结论

ZeRO/FSDP 的本质是把参数、梯度和优化器状态从每卡完整保存变成分片保存。

复习定位

维度	内容
所属模块	分布式训练
章节类型	机制类（含公式）
解决问题	围绕数据并行、张量并行、流水线并行、ZeRO/FSDP、NCCL 和训练排障建立大模型训练系统答案。
面试抓手	显存公式要按 ZeRO 阶段拆。

ZeRO / FSDP：把训练状态从“每卡完整保存”变成“分片保存”

大模型训练的显存不仅被参数占用，还被梯度、优化器状态和激活值占用。ZeRO 和 FSDP 的核心都是将训练状态分片，降低每张 GPU 的显存压力；代价是前向/反向时需要更多通信来取回参数或同步分片。

训练显存组成

组成	常见 dtype	每参数字节数	说明
模型参数	FP16/BF16	2	forward/backward 使用
梯度	FP16/FP32	2 或 4	优化器更新需要
Adam 一阶矩	FP32	4	momentum
Adam 二阶矩	FP32	4	variance
Master weights	FP32	4	混合精度训练常见

常见估算会把 Adam 训练状态近似为：

$$\text{Training State} \approx \text{Parameters}(2B) + \text{Gradients}(4B) + \text{Adam States}(12B) = 18 \text{bytes} / parameter$$

ZeRO 阶段对比

阶段	分片对象	显存节省	通信变化	典型选择
ZeRO-1	优化器状态	中等	接近 DP	低风险节省显存
ZeRO-2	优化器状态 + 梯度	较大	接近 DP	常用甜点
ZeRO-3	参数 + 梯度 + 优化器状态	最大	额外参数 AllGather	模型极大时使用
FSDP	参数 shard + 按需 all-gather	接近 ZeRO-3	与 wrapping 策略强相关	PyTorch 原生生态

Q: 7B 模型，4 卡，用 ZeRO-1/2/3 每卡训练状态显存怎么估算？

回答思路：先说明每参数字节数，再按分片对象分别计算。

1. 无 ZeRO

按每参数 18 bytes 估算：

$$7B \times 18 \text{bytes} = 126 \text{GB} / \text{GPU}$$

每卡都保存完整训练状态，A100 80GB 放不下。

2. ZeRO-1

只切 Adam 优化器状态，参数和梯度仍完整保存：

$$7B \times (12 / 4 + 4 + 2) = 63 \text{GB} / \text{GPU}$$

3. ZeRO-2

切优化器状态和梯度：

$$7B \times (12 / 4 + 4 / 4 + 2) = 42 \text{GB} / \text{GPU}$$

4. ZeRO-3

参数、梯度、优化器状态都切：

$$7B \times (12 / 4 + 4 / 4 + 2 / 4) = 31.5 \text{GB} / \text{GPU}$$

面试口径：ZeRO 的本质是分片训练状态，ZeRO-2 常是性价比甜点，ZeRO-3 显存最省但通信更重。

Q: FSDP 和 ZeRO-3 是什么关系？

回答思路：先讲共同点，再讲 PyTorch FSDP 的实现特点。

1. 共同点

FSDP 和 ZeRO-3 都会把参数、梯度、优化器状态按 data parallel group 分片，前向/反向前按需 all-gather 完整参数，用完后释放。

2. FSDP 的关键是 wrapping

FSDP 按 module 包裹粒度决定 all-gather 和释放范围。包得太粗会峰值显存高，包得太细会通信次数多。

3. 工程差异

FSDP 是 PyTorch 原生能力，和 autograd/module 生态结合更紧；DeepSpeed ZeRO 提供更完整的 offload、optimizer、配置生态。

面试口径：FSDP 可以理解为 PyTorch 原生的 ZeRO-3 类方案，差异主要在 wrapping 粒度和生态实现。

Q: ZeRO-3 为什么通信更多？什么时候仍然值得用？

回答思路：解释参数被分片后必须按需 gather，再说明适用边界。

1. 参数不再完整常驻

ZeRO-3 下每张卡只保存部分参数。某一层 forward/backward 需要完整参数时，需要先 AllGather。

2. 通信换显存

相比 ZeRO-2，ZeRO-3 增加参数 AllGather，但显存进一步下降。它是典型的用通信换显存。

3. 适用场景

当 ZeRO-2 仍然放不下模型，或者想扩大 batch/seq_len 时，ZeRO-3/FSDP 值得使用；如果 ZeRO-2 已足够，ZeRO-3 不一定更快。

面试口径：ZeRO-3 不是免费午餐，它通过额外参数 AllGather 换取最大显存节省。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

NCCL 与通信优化

精通★☆☆⏱ 18 min

一句话结论

NCCL 是 GPU 集合通信事实标准，训练慢或 hang 时必须看拓扑、算法、带宽和慢 rank。

复习定位

维度	内容
所属模块	分布式训练
章节类型	机制类
解决问题	围绕数据并行、张量并行、流水线并行、ZeRO/FSDP、NCCL 和训练排障建立大模型训练系统答案。
面试抓手	通信时间粗估是流量除以有效带宽。

NCCL：GPU 集合通信的事实标准

NCCL 负责 GPU 间高效集合通信，常见于 DDP 梯度同步、TP 层内通信、MoE expert routing 等场景。分布式训练排障里，NCCL 往往是最关键也最难定位的一层。

常见集合通信语义

操作	语义	训练场景
AllReduce	所有 rank 的数据归约后广播给所有 rank	DDP 梯度同步
ReduceScatter	归约后按 rank 分片	ZeRO/FSDP 梯度分片
AllGather	收集所有 rank 的分片到每个 rank	ZeRO-3/FSDP 参数按需 gather
Broadcast	一个 rank 发送给所有 rank	初始化参数、同步状态
All-to-All	每个 rank 给每个 rank 发送不同分片	MoE expert parallel

Ring vs Tree

算法	优势	劣势	适合场景
Ring	带宽利用高，链路均匀	延迟随 rank 数增加	大 tensor AllReduce
Tree	延迟更低	带宽利用可能不如 ring	小 tensor、rank 数多
Hierarchical	节点内/节点间分层优化	实现复杂，依赖拓扑识别	多节点多 GPU 训练

通信时间粗估

通信瓶颈可以用“数据量 / 有效带宽”粗估：

$$\text{Communication Time} \approx \frac{\text{Traffic}}{\text{Effective Bandwidth}}$$

例如每卡 AllReduce 流量 49GB，有效带宽 100GB/s，则裸通信时间约：

$$49 \text{GB} / 100 \text{GB}/s = 0.49 s$$

实际还要加上启动延迟、拓扑、协议栈、拥塞、NCCL 算法选择和通信计算重叠效果。

Q: NCCL 训练 hang 了，应该怎么排查？

回答思路：先区分是某个 rank 先失败还是所有 rank 卡在通信，再从日志、网络、拓扑、环境变量逐层排查。

1. 看 rank 是否一致进入 collective

集合通信要求所有 rank 按相同顺序调用。如果某个 rank OOM、数据读取失败或提前退出，其他 rank 会卡在 NCCL 调用里。

2. 打开 NCCL 日志

常用环境变量：

export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=INIT,NET,COLL
export TORCH_DISTRIBUTED_DEBUG=DETAIL

3. 检查网络与设备

确认 IB/RDMA 设备可见、网卡选择正确、端口互通、容器权限和 device plugin 注入正常。

面试口径：NCCL hang 常常不是 NCCL 本身错，而是 rank 顺序不一致、某 rank 先失败、网络或设备不可用。

Q: 为什么 MoE 的 All-to-All 比 DDP AllReduce 更难优化？

回答思路：对比通信模式、流量分布和负载均衡。

1. AllReduce 数据模式规则

AllReduce 通常每个 rank 发送相同大小梯度，通信模式规则，容易用 ring/tree 做优化。

2. All-to-All 更依赖路由分布

MoE 中 token 被路由到不同专家，某些专家可能热门，导致不同 rank 发送/接收数据不均衡。

3. 对全网带宽要求高

All-to-All 需要更高 bisection bandwidth；拓扑不均衡、交换机拥塞、跨机房部署都会放大性能问题。

面试口径：All-to-All 难在不规则、全互联、负载不均衡；它比规则 AllReduce 更吃拓扑和路由质量。

Q: NCCL 常见环境变量有哪些？面试中怎么说？

回答思路：不要背一堆变量名，要按用途分类。

1. 日志诊断

NCCL_DEBUG=INFO、NCCL_DEBUG_SUBSYS=INIT,NET,COLL 用于看初始化、网络选择和 collective 信息。

2. 网卡选择

NCCL_SOCKET_IFNAME、NCCL_IB_HCA 用于限制 NCCL 选择哪些网卡，避免走错 docker0、lo 或低速网卡。

3. 功能开关

NCCL_IB_DISABLE、NCCL_P2P_DISABLE 可用于隔离 RDMA/P2P 问题，但生产不应长期关闭高性能路径。

面试口径：NCCL 环境变量按日志、网卡选择、功能开关三类记，核心是帮助判断走了哪条通信路径。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

排障与面试计算题

精通★☆☆⏱ 22 min

一句话结论

分布式训练排障先分层：数据、单卡算子、通信、并行策略、存储、调度和故障恢复。

复习定位

维度	内容
所属模块	分布式训练
章节类型	排障诊断类
解决问题	围绕数据并行、张量并行、流水线并行、ZeRO/FSDP、NCCL 和训练排障建立大模型训练系统答案。
面试抓手	把 GPU-Util、MFU、NCCL、OOM、hang 分开定位。

分布式训练排障：先定位瓶颈属于哪一层

分布式训练慢或失败，不能只盯 GPU 利用率。应按链路拆分：数据加载 → CPU 预处理 → GPU 计算 → 显存/激活 → NCCL 通信 → checkpoint/存储 → 调度和拓扑。

高频故障速查

现象	优先排查	常见原因
GPU 利用率低	DataLoader、CPU、I/O、通信等待	数据供给慢、batch 太小、NCCL 等待
GPU 利用率高但训练慢	MFU、kernel timeline、NCCL timeline	低效 kernel、通信占比高、显存带宽瓶颈
NCCL hang	rank 日志、首个失败 rank、网络设备	rank 调用顺序不一致、某 rank OOM、IB 不通
CUDA OOM	模型状态、activation、fragmentation	batch/seq 太大、ZeRO 配置不当、checkpoint 缺失
checkpoint 很慢	存储带宽、元数据、并发写	多 rank 同时写、共享文件系统拥塞

面试计算题套路

题型	核心公式	容易错的点
DP 通信量	$$2 \times (N - 1) / N \times P \times \text{bytes}$$	区分梯度大小和每卡收发量
ZeRO 显存	$$P \times (optimizer/N + grad/N + param/N)$$	不同 ZeRO 阶段分片对象不同
PP bubble	$$(p - 1) / (m + p - 1)$$	m 是 micro-batch 数，不是 batch size
3D 并行度	$$\text{Total GPUs} = DP \times TP \times PP$$	TP 通常不能跨节点随便放

Q: GPU 利用率低，如何判断是数据加载慢还是通信慢？

回答思路：先观察时间线，再做隔离实验。

1. 看 timeline

用 profiler 看 GPU kernel 之间是否有大空洞。如果空洞出现在 forward 前，多半是数据加载；如果出现在 backward 中或 optimizer 前，多半是通信同步。

2. 做隔离实验

用 synthetic data 替代真实 DataLoader。如果吞吐显著提升，说明数据链路慢；如果仍慢，再看 NCCL/计算。

3. 看系统指标

数据慢常伴随 CPU 高、磁盘/网络读高、DataLoader worker 忙；通信慢常伴随 NCCL kernel 时间长、网卡带宽高或 rank 等待。

面试口径：先看 timeline 空洞位置，再用 synthetic data 隔离数据链路，最后结合 CPU/I/O/NCCL 指标判断。

Q: 为什么 nvidia-smi 显示 GPU-Util 100%，训练仍然可能不高效？

回答思路：区分 GPU-Util、SM Active、MFU 和端到端吞吐。

1. GPU-Util 不是算力利用率

nvidia-smi 的 GPU-Util 更接近采样窗口内是否有 kernel 在跑，不代表 Tensor Core 被充分利用。

2. 更应看 MFU

MFU 衡量模型实际吞吐对应的 FLOPs 占硬件峰值的比例：

$$\mathrm{MFU} = \text{Actual Model FLOPs} / \text{Hardware Peak FLOPs}$$

3. 高 util 低效率原因

可能是小 kernel 碎片、访存瓶颈、通信等待、精度未用 Tensor Core、batch 太小或算子 fallback。

面试口径：GPU-Util 100% 只能说明 GPU 忙，不说明忙得有效；训练效率要看 MFU、吞吐和 timeline。

Q: 64 卡训练，TP=8、PP=4，DP 是多少？如果每节点 8 卡，需要几台机器？

回答思路：用 3D 并行乘积公式，再结合每节点 GPU 数计算机器数。

1. 计算 DP

$$DP = 64 / (8 \times 4) = 2$$

2. 计算节点数

每节点 8 卡，总共 64 卡：

$$\text{Nodes} = 64 / 8 = 8$$

3. 放置解释

每个 TP group 占一台机器，4 个 PP stage 占 4 台机器，一条 pipeline 用 4 台机器；DP=2 表示两条 pipeline 副本，共 8 台机器。

面试口径：DP=2，总共 8 台 8 卡机器；TP 节点内，PP 跨节点，DP 是 pipeline 副本数。

Q: 训练任务 OOM，应该先调 batch size、ZeRO，还是 activation checkpointing？

回答思路：按 OOM 来源分类，不要机械回答。

1. 参数/优化器状态 OOM

如果模型状态占主导，优先 ZeRO/FSDP、optimizer offload、参数分片。

2. Activation OOM

如果 seq_len/batch 增大后 OOM，通常是 activation 占主导，优先 activation checkpointing、减小 micro-batch 或 sequence parallel。

3. 碎片和峰值

如果偶发 OOM，要看 allocator fragmentation、临时 workspace、checkpoint 保存/加载时的峰值。

面试口径：状态 OOM 用 ZeRO/FSDP，activation OOM 用 checkpointing/减 batch，偶发 OOM 要看碎片和临时峰值。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

系统设计：分布式训练平台

精通★☆☆⏱ 22 min

一句话结论

分布式训练平台的设计主线是「把一次多机多卡训练从提交到完成的全流程做成可靠的自动化」：任务抽象屏蔽并行细节、Gang + 拓扑感知调度保证一起起且通信近、生命周期管理训练循环和 checkpoint、容错处理 worker 故障弹性恢复、可观测性贯穿全程。

复习定位

维度	内容
所属模块	分布式训练
章节类型	系统设计类
解决问题	围绕分布式训练平台、任务抽象、Gang 调度、容错和可观测性形成可复述设计题框架。
面试抓手	回答时先定范围，再讲核心链路，最后落到工程风险和面试追问。

题目

设计一个端到端的分布式训练平台，支持从提交任务到训练完成的全流程。

设计要点

任务抽象
- 用户提交训练配置：模型代码、数据路径、并行策略、资源需求
- 平台生成 PodGroup + 配置 ConfigMap + Headless Service
资源调度
- Gang scheduling 保证所有 worker 同时启动
- 拓扑感知：优先同节点（NVLink）→ 同机柜（高速交换）→ 跨机柜
训练生命周期
- 初始化：参数同步 + NCCL 通信组建立
- 训练循环：数据加载 → 前向 → 反向 → AllReduce → 更新
- Checkpoint：周期性异步保存到分布式存储
容错机制
- Worker 故障检测（心跳超时）
- 弹性恢复：从最近 checkpoint 重启，支持 worker 数量变化
- GPU 健康检查：ECC 错误检测 + 自动标记不可用
可观测性
- 训练指标：loss、throughput、GPU 利用率
- 系统指标：网络吞吐、存储 IOPS、调度延迟
- 日志和事件：统一收集到日志平台

追问：如何优化大模型训练的启动时间？

(1) 镜像预热：在目标节点预拉取训练镜像（几十 GB），避免冷启动拉镜像。(2) 模型缓存：预训练 checkpoint 缓存在节点本地 NVMe，不用每次从分布式存储下载。(3) NCCL 初始化优化：减少初始化时的全互联探测时间。(4) 数据预加载：提前将训练数据加载到内存或本地 SSD。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。