算子与编译器：通信算子与计算重叠

当模型开始使用数据并行、张量并行、流水线并行、专家并行和上下文并行时，通信就不再是“附属开销”，而是训练与推理系统的主路径之一。很多大模型系统之所以吞吐上不去，不是因为 GPU 算得慢，而是因为 all-reduce 太频繁、all-gather 太重、reduce-scatter 时机不对、通信和计算没有重叠、拓扑映射不合理，或者某些 collective 让快 GPU 在等慢链路。

因此理解通信算子，并不是通信工程师才需要的事，而是大模型系统工程的基础。

初学者先抓住

多卡训练里，算得快只是上半场，同步得快才是下半场。通信重叠的目标不是让通信消失，而是把必须发生的数据交换藏到计算正在进行的时间里。

难点解释：为什么 overlap 经常没有真的发生

代码里写了异步通信，不代表时间线上已经重叠。若依赖关系、stream、bucket 大小、拓扑或 collective 时机不对，GPU 仍可能在等待通信结束。判断 overlap 要看 timeline，而不是只看 API 名字。

有趣例子：边炒菜边等外卖

Overlap 像厨师一边炒菜，一边让人去取下一批食材。只有当取食材真的发生在炒菜期间，才算重叠；如果厨师炒完才发现食材还没到，时间线里仍然是等待。

1. 通信问题为什么会在大模型时代爆发

单卡时代，性能大多由 kernel 决定；
多卡时代，性能开始由“算得快不快”和“同步得快不快”共同决定。

可以粗略把一次分布式 step 写成：

$T_{\text{step}} \approx T_{\text{compute}} + T_{\text{comm}} - T_{\text{overlap}}.$

这里真正关键的是 $T_{\text{comm}}$ 有多大，以及能不能通过 $T_{\text{overlap}}$ 把一部分藏起来。

如果不能重叠，通信就会直接变成裸露的 wall-clock 时间。

2. 最常见的几类 collective

2.1 All-Reduce

每个 rank 提供一份张量，最终每个 rank 都拿到聚合结果。它常见于数据并行梯度同步、某些张量并行中间结果归约和统计量同步。

2.2 Reduce-Scatter

先做归约，再把结果分散到不同 rank。它常见于 ZeRO / FSDP 路径、优化器状态分片，以及把 all-reduce 拆解成更可重叠的形式。

2.3 All-Gather

每个 rank 提供自己的一片，最终每个 rank 都拿到完整拼接结果。它常见于 ZeRO-3 / FSDP 参数按需 gather、张量并行输出拼接，以及 MoE / CP 某些分布式路径。

2.4 Broadcast / Gather / Scatter

在某些控制流、元数据同步或较简单分发逻辑里仍会使用。

3. Ring、Tree 与拓扑意识

同一种 collective，在不同实现里可能采用 ring、tree、hierarchical 或混合拓扑路径。

3.1 Ring 的直觉

ring 通常在大消息带宽利用上有优势，适合很多训练场景。但其延迟路径和节点数强相关。

3.2 Tree 的直觉

tree 更适合某些低延迟聚合场景，但未必总能最大化持续带宽。

3.3 为什么系统工程师必须关心拓扑

因为 TP 高度依赖节点内高速链路，DP 更适合跨更大范围扩展；若把频繁通信放到最慢链路上，理论并行设计再漂亮也没用。

这也是为什么现实系统里，TP / PP / DP 的分组常和物理拓扑强绑定。

4. 数据并行里的通信主线

在普通 DP 中，最典型的通信是梯度 all-reduce。
若每个 rank 梯度张量为 $g_i$，则最终每个 rank 都需要：

$g = \frac{1}{N}\sum_{i=1}^{N} g_i.$

4.1 为什么梯度同步会变成主瓶颈

因为当参数量很大时，梯度张量体积大、每步都要同步、训练步数极多；如果 bucket 划分不合理，就很难和反向传播重叠。

4.2 Bucket 化为什么重要

bucket 化的目的，是让梯度一边反传、一边开始通信，而不是等所有梯度都算完再一次性同步。
这样才能把一部分通信时间藏进计算时间里。

5. 张量并行里的通信主线

TP 的核心代价是层内通信，常发生在列并行 / 行并行线性层之间、attention 中间结果归并和输出拼接处。

5.1 为什么 TP 更依赖低延迟高速互联

因为它的通信频率高、粒度细，而且位于前向 / 反向主路径上。
跨节点 TP 往往比节点内 TP 更痛苦，除非拓扑和实现都特别强。

6. 流水线并行里的通信主线

PP 主要依赖 stage 间点对点传输。
每个 micro-batch 在相邻 stage 之间传递激活和梯度。

6.1 PP 的通信为什么不像 DP 那样“全局”

它更像局部相邻传输，而不是全局 collective。
但这并不代表它简单，因为：

1. 它和 micro-batch 调度强相关；
2. 会受到 pipeline bubble 影响；
3. 激活大小和 stage 划分都会改变带宽需求。

7. ZeRO / FSDP 为什么把通信问题彻底抬上台面

当参数、梯度、优化器状态被分片后，显存省下来了，但新的问题是：

1. 参数什么时候 all-gather；
2. 梯度什么时候 reduce-scatter；
3. 优化器状态什么时候同步；
4. 通信能否和前向 / 反向重叠。

7.1 ZeRO-3 / FSDP 的真实代价

很多人只看到了“参数不再完整复制”，没看到：

1. 前向前需要 gather；
2. 反向后需要 scatter；
3. wrap 粒度决定通信频率；
4. checkpoint 也更复杂。

所以 ZeRO/FSDP 不是免费午餐，而是“用更多通信与系统复杂度换更低显存”。

8. Reduce-Scatter 与 All-Gather 组合的意义

很多现代训练系统喜欢把原本的 all-reduce 拆成：

1. reduce-scatter；
2. 局部计算或状态更新；
3. 必要时再 all-gather。

这样做的好处是更适合分片状态，更容易和某些计算阶段重叠，也与 ZeRO/FSDP 的参数组织更一致。

8.1 为什么拆开后更容易重叠

因为你不一定要等“所有人都拿到完整结果”才能继续下一步。
在某些设计里，只要先得到本 rank 负责的那片结果，就能继续局部工作。

9. 通信重叠为什么是核心能力

如果把通信和计算完全串起来，系统就会变成“算一阵、等一阵、再算一阵、再等一阵”。更理想的是反向一边产出梯度、一边 reduce，前向一边需要参数、一边提前 gather，pipeline 传输与计算交错，把通信尽量隐藏在计算后面。

10. Megatron 之所以强调 overlap，不只是小优化

Megatron 路线里对 grad reduce overlap、param gather overlap、tp communication overlap 等能力的强调，并不是“锦上添花”，而是因为在超大规模训练中，通信裸露时间足以吞掉大量理论吞吐。

10.1 overlap 真正难在哪里

难点在于 bucket 和 layer 边界要匹配，过早启动通信会增加内存压力，过晚启动又会错失重叠窗口；不同并行维度还会互相干扰，profile 里也很容易只看到“通信很多”，却看不出哪部分真的被隐藏了。

11. MoE 与通信

MoE 的通信问题往往比稠密模型更复杂，因为 token 要 dispatch 到不同 expert，expert 输出还要 gather 回来；router 会导致负载分布不均，热门 expert 又会形成热点通信与计算。

11.1 为什么 MoE 常让“算力足够”却仍然很慢

因为问题可能根本不在 GEMM，而在 token permutation、all-to-all、expert 负载失衡，或者动态路由破坏了静态优化。

因此 MoE 系统很依赖通信与调度共同优化。

12. 上下文并行与长序列通信

当上下文并行或序列并行进入训练与推理后，通信还会进一步嵌入 attention 分块、序列切分、长上下文 KV / activation 管理，以及跨 rank 的局部结果组合。

这说明长上下文系统不只是“更多显存”，也往往意味着更复杂的通信图。

13. 推理里的通信问题

人们常把通信问题视为训练专属，其实大模型推理同样会遇到张量并行推理的每步同步、多节点 KV cache 访问或跨卡路由、MoE 推理中的 expert dispatch，以及多模型服务中的设备间调度与共享。

13.1 为什么 decode 阶段通信更刺眼

因为 decode 本来单步计算就不大，一旦跨卡同步存在，通信占比会非常高。
这也是为什么很多在线系统会极其谨慎地使用跨节点 TP。

14. 通信 profiling 该怎么看

一个较有用的通信 profile 至少要回答：哪些 collective 最耗时，发生在哪些阶段，是否被计算覆盖，是 bandwidth-bound 还是 latency-bound，是否存在某一组 rank 明显更慢，以及是否与物理拓扑不匹配。

14.1 常见误判

只看“总通信时间”往往不够，因为很多通信已被 overlap 掩盖，真正影响 step time 的是裸露通信；少量关键路径通信，可能比大量被隐藏通信更值得优化。

15. 一个更实用的诊断顺序

如果一个大模型训练吞吐低，较稳妥的通信排查顺序通常是：

1. 先确认 compute 是否真的吃满；
2. 再看 step 中通信占比；
3. 再拆 collective 类型；
4. 再看是否已有 overlap；
5. 再对照拓扑看分组是否合理；
6. 最后才决定是改 bucket、改 wrap、改并行度，还是改拓扑映射。

16. 为什么通信优化常比写新 kernel 更难

因为它涉及多进程、多节点、多维并行、异步时序、拓扑映射，而且 profile 与复现难度都更高。

一个 kernel 慢，你通常能在单卡上反复微基准；
一个通信问题慢，往往要在特定 world size、特定拓扑和特定 workload 下才显现。

17. 一个形象比喻

如果把多卡训练想成多条装配线协同生产同一种产品，那么计算 kernel 像每个工位的加工速度，通信算子则像工位之间传递半成品和同步进度的物流系统。某个工位再快，如果半成品总卡在传送带上，整条产线吞吐仍然上不去。通信重叠的本质，就是让传送带在工位加工时同步运转，而不是每加工完一次就全线停下来等物流。

18. 小结

通信算子与计算重叠，是大模型系统性能的另一半。只优化 kernel、不优化 collective 与拓扑，很多训练和推理系统最终都会撞到通信天花板。真正成熟的分布式设计，不只是“用了 DP/TP/PP/ZeRO”，而是知道这些并行策略各自带来了哪些通信路径，又怎样通过 bucket、分组、拓扑映射与 overlap 把通信尽量藏起来。

一旦建立这套视角，你看待 Megatron、DeepSpeed、FSDP、MoE、长上下文和多节点推理时，就不会只看到名词，而会看到一张清晰的通信图和关键路径图。