真实面经题目 · 原创解析

分布式 LLM 训练中 AllReduce、AllGather、ReduceScatter 和 AllToAll 分别解决什么通信问题,哪些并行场景会用到它们?

这道题考察分布式训练中 collective communication 的语义和并行策略映射。回答要先把 AllReduce、AllGather、ReduceScatter、AllToAll 的输入输出关系讲清,再说明它们分别解决梯度汇总、参数或激活拼接、归约后分片、个性化交换等问题。进一步要能联系数据并行、张量并行、ZeRO/FSDP、序列并行、专家并行和 MoE token dispatch,指出通信量、同步开销、拓扑和 overlap 对训练效率的影响。

出现于:快手 · 算法

60 秒回答模板

分布式 LLM 训练里的通信原语可以按数据流理解。AllReduce 是每张卡都有一份张量,先跨卡求和或平均,再把相同结果发回所有卡,典型用于数据并行的梯度同步,也会出现在某些张量并行输出归约中。AllGather 是每张卡只有一片张量,通信后每张卡都拿到完整拼接结果,常用于 FSDP/ZeRO 在计算前聚合参数、张量并行拼接激活或 logits。ReduceScatter 是先对多卡张量做归约,再把结果按 shard 分给各卡,常用于 ZeRO/FSDP 的梯度归约分片,也能减少 AllReduce 后每卡保留全量结果的内存。AllToAll 是每张卡给每张其他卡发送不同切片,结果不是简单广播或求和,常用于 MoE 专家并行的 token dispatch/combine、序列并行重排和一些 context parallel 的维度变换。选择原语时要看并行维度、张量形状、是否需要所有卡持有全量、是否需要归约,以及能否和反向计算、参数预取或 optimizer step 重叠。

考点 AllReduce 规约同步
难度 真实面经题
回答目标 让读者能用输入输出语义解释四类 collective,并能把它们准确映射到 LLM 训练中的数据并行、参数分片、张量切分、序列切分和专家路由场景。

深入解析

01

AllReduce

AllReduce 的语义是所有 rank 输入同形状张量,跨 rank 做 sum、mean、max 等规约,然后每个 rank 都得到同一份规约结果。最典型场景是数据并行中每张卡计算不同 micro-batch 的梯度,需要平均后保持模型副本一致。

02

AllGather

AllGather 的语义是每个 rank 持有不同 shard,通信后所有 rank 都得到完整拼接张量。它解决的是从分片状态临时恢复全量视图的问题,例如 FSDP 前向前 all-gather 当前层参数,或张量并行中把被切分的 hidden/logits 拼回完整维度。

03

ReduceScatter

ReduceScatter 可以看成 AllReduce 的一半:先跨 rank 对对应块求和,再只把结果的一片留在每个 rank。它适合结果本来就要分片保存的场景,例如 ZeRO/FSDP 对梯度做规约后直接按参数 shard 分散,避免每张卡都持有完整梯度。

04

AllToAll

AllToAll 的语义是每个 rank 都把不同切片发给不同目标 rank,同时也从所有 rank 接收属于自己的切片。它解决的是个性化重分布,不是简单复制或求和。MoE 中 token 根据 router 分配到专家所在 rank,就是 AllToAll 的典型用法。

05

并行映射

数据并行主要依赖梯度 AllReduce,ZeRO/FSDP 把 AllReduce 拆成 ReduceScatter 和 AllGather 来节省显存;张量并行根据列切或行切使用 AllGather、AllReduce 或 ReduceScatter;序列并行会在 hidden 维和 sequence 维之间交换;专家并行则大量使用 AllToAll 迁移 token。

06

通信成本

AllReduce 和 ReduceScatter 通常可用 ring 或 tree 算法,成本受张量大小、rank 数、网络带宽和延迟影响。AllGather 会放大全量副本内存,AllToAll 对网络拓扑和负载均衡更敏感,MoE 如果 router 不均衡,会出现某些专家 rank 拥塞和 padding 浪费。

07

重叠优化

LLM 训练不会只看单个 collective 的理论复杂度,还要看能否 overlap。常见优化包括反向传播时按 bucket 提前 reduce-scatter 梯度,FSDP 在计算下一层前预取参数,tensor parallel 将通信与 GEMM 调度穿插,以及将小张量合并减少 launch 和网络延迟。

08

排障指标

通信异常常表现为 step time 抖动、某些 rank 等待时间长、NCCL 超时、GPU SM 利用率低但网络链路高、MoE expert load imbalance 或显存峰值异常。排查时要按并行组拆分数据并行组、张量并行组、pipeline stage 和 expert group,而不是只看全局 GPU 利用率。

易错点

  • 把 AllGather 和 AllReduce 混为一谈,忽略前者不做规约、后者会规约。
  • 认为 ReduceScatter 只是减少通信量,不说明它也改变结果的存储分片。
  • 把 AllToAll 说成广播,忽略每个目标收到的是不同数据切片。
  • 只背定义,不联系数据并行、张量并行、FSDP、MoE 等具体场景。
  • 认为通信开销只和 GPU 数有关,忽略张量大小、拓扑、带宽、延迟和算法。
  • 忽略 rank group,错误地假设所有 collective 都在全局所有 GPU 上发生。
  • 只看平均 GPU 利用率,不排查 straggler、负载不均和 NCCL 等待时间。
  • 没有说明通信与计算重叠,导致优化建议停留在换更快网络。

面试官追问

为什么 ZeRO/FSDP 能用 ReduceScatter 和 AllGather 替代传统数据并行 AllReduce?

传统数据并行让每张卡都保留完整参数、梯度和优化器状态,因此梯度 AllReduce 后每卡都有全量结果。ZeRO/FSDP 把状态分片保存,反向时用 ReduceScatter 直接得到各自负责的梯度 shard,前向或反向需要参数时再 AllGather 临时恢复。

Megatron 张量并行中的列并行和行并行 linear 分别会用哪些通信?

列并行 linear 通常把输出维切开,各卡计算不同输出分片,后续若能继续分片使用就不必立刻通信,若需要完整 hidden 则 AllGather。行并行 linear 把输入维切开,各卡得到部分和,通常需要 AllReduce 或 ReduceScatter 合并结果。

MoE 中 AllToAll 为什么容易成为瓶颈,如何缓解 expert imbalance?

MoE router 会把 token 发送到专家所在 rank,AllToAll 的消息大小随路由分布变化,热门专家会造成某些 rank 拥塞和 padding 浪费。缓解方式包括 load balancing loss、capacity factor 调整、专家复制、top-k 限制和更合理的 expert placement。

Pipeline parallelism 主要通信什么,和这些 collective 有什么区别?

Pipeline parallelism 主要在相邻 stage 之间点对点发送前向激活和反向梯度,通信对象是流水线边界张量,不一定涉及组内所有 rank。collective 则是一个通信组内多卡共同参与的规约、拼接或重分布,语义和同步范围不同。

如何用 profiler 判断训练慢是 compute-bound 还是 communication-bound?

如果 GEMM 时间占比高、SM 和 HBM 利用充分,通常更偏计算瓶颈;如果 NCCL kernel、rank wait、网络吞吐或 dataloader wait 占比高,GPU 计算单元空转明显,就偏通信或输入瓶颈。还要分 rank 看 straggler,而不只看平均值。

bucket size 过大或过小会怎样影响梯度同步和 overlap?

bucket 太大时,需要等更多梯度就绪后才启动通信,overlap 机会减少,尾部等待变长;bucket 太小时,通信启动次数和调度开销增加,小消息效率差。合适大小应让通信尽早开始,同时保持足够大的带宽利用率。