通信与计算重叠：梯度桶、Prefetch 与关键路径

分布式训练的通信本身不产生有用功，但它不一定要花时间——只要通信 kernel 和计算 kernel 在不同 stream 上并行推进，通信就能藏进计算里。藏不住的部分叫暴露通信（exposed communication），直接拉长 step。这页讲三种重叠机制和在 trace 里的验证方法。

1. DDP 梯度桶：反向一边算，梯度一边发

朴素做法是整个 backward 算完再对全部梯度做一次 all-reduce——通信完全串行。DDP 把梯度按固定大小（默认约 25 MB）分桶，某桶内所有梯度就绪就立即异步发出 all-reduce，同时 backward 继续算后面的层：

由于反向是逆序的，最后层的梯度最先就绪，桶按 L4→L1 的顺序发车；理想情况下只有最后一桶（没有后续反向可覆盖）露出在关键路径上。工程要点：

• 桶大小：太小 → 每桶达不到带宽峰值且 launch 开销占比高；太大 → 就绪等待变长、重叠窗口变小。PyTorch 用 bucket_cap_mb 调；
• 分桶顺序：DDP 按反向就绪顺序（大致是参数的逆序）装桶，而不是按定义顺序；
• grad accumulation 边界：多 microbatch 累积时，只有最后一个 microbatch 的反向才需要发车，前面的只累加。

2. FSDP / ZeRO-3：权重的 all-gather prefetch

ZeRO-3/FSDP 里权重是分片的，每层用之前要先 all-gather。重叠方式是 prefetch：算第 k 层时就并发发起第 k+1 层的 all-gather，前向如此、反向如此；梯度侧则把 all-reduce 拆成 reduce-scatter 逐桶发出。FSDP 暴露这些旋钮：forward_prefetch、backward_prefetch、limit_all_gathers（限制在飞的 gather 数量以控制显存峰值）。

与 DDP 桶的本质差异：DDP 重叠的是「反向内部」的梯度通信，FSDP 还要多藏一份「层边界」的权重通信；跨节点带宽弱时，all-gather 很容易暴露，这时该考虑缩小分片域（节点内 FSDP + 节点间 DDP 的混合分片）。

3. TP 与 PP：不好重叠的两种通信

• TP 的 all-reduce 在层内关键路径上：Y = X·W 的两个 GEMM 之间夹着的 all-reduce，后继计算必须等它完成。能做的只有融合（all-reduce 拆进 GEMM 的 epilogue、sequence parallel 把 LayerNorm 段拉直）或减小 TP 域，而不是「藏到别处」。
• PP 的 p2p send/recv：发生在 流水调度 的边界，粒度是单个 microbatch 的激活（B·S·H，很小），延迟主导；它与气泡交织，优化手段是调度（1F1B 让边界更密）而非重叠。

4. 在 Trace 里验证，不靠感觉

重叠是否成立是可观测的，用 GPU Trace 分析 的方法：

1. 看 stream 时间线：compute stream 上的 GEMM kernel 与 NCCL stream 上的 all-reduce kernel 是否有时间重叠区；
2. 量暴露通信：NCCL kernel 中没有被任何 compute kernel 覆盖的区间总和，就是该 step 的暴露通信；它和 Critical Path 的交点就是优化对象；
3. 对照带宽基线：单桶耗时 ÷ 桶大小得到的有效带宽，与 nccl-test 实测的同规模 all-reduce 带宽对比，差太多说明桶太小或链路/拓扑有问题；
4. 常见反模式：NCCL kernel 被 launch 在 compute stream 上（串行化）、limit_all_gathers 过紧导致 prefetch 失效、小模型大集群（通信 > 计算，天然暴露）。

相关页面

• 训练基础：一个 Step 的执行图反向产生梯度的位置
• ZeRO 与 FSDPall-gather / reduce-scatter 的来源
• 流水线并行p2p 与气泡的关系
• Megatron 并行TP 层内 all-reduce 的位置
• GPU CommunicationNVLink/PCIe/NVSwitch 与集合通信原语
• GPU Trace 分析stream 重叠的观测方法
• nccl-test 运行通信带宽基线实测