通信与并行正文
页面目标
这页把“多卡为什么慢”“并行策略怎么选”“通信热点怎么查”这三件事展开成正文。
适用人群
- 想把单卡训练扩到多卡的人。
- 正在判断该用 ZeRO、Pipeline 还是 Tensor Parallelism 的人。
- 想把通信等待、气泡和吞吐放在一起看的人。
不适用人群
- 只关心单卡算子优化的人。
- 还没建立 batch、同步、AllReduce 基本概念的人。
- 不打算看 benchmark 或通信热点的人。
你应该如何开始读
- 先读
05 -> 20，把通信原语和拓扑关系看懂。 - 再读
06 -> 27 -> 28 -> 29，确定该用哪种并行切分。 - 如果你关心实际扩展效果，再看
42 -> 34 -> 31。 - 最后回到
2.8，把策略选择和训练目标对齐。
故事线
一个最常见的并行故事，是“GPU 明明加了，训练还是没快”。最开始大家通常会怀疑模型太大，或者单卡算子太慢；但真正把链路拆开以后，问题往往是同步等待、micro-batch 气泡和通信 overlap 没做好。
第一步先看 05 -> 20，把通信原语和拓扑关系讲清楚。 第二步再看 06 -> 27 -> 28 -> 29，决定到底该切状态、切层还是切算子。 第三步再看 42 -> 34 -> 31，确认通信热点和基准结果是否证明并行策略真的值。 最后回到 2.8，把策略判断和训练目标重新对齐。
这个故事的重点不是“多卡就快”，而是不同切分层级解决的是不同问题，必须先分清代价从哪来。
具体案例
案例 1：8 卡训练，速度没有线性提升
现象是：从 1 卡扩到 8 卡，显存确实降了，但训练时间没有按预期下降。
判断链路是：先看 05 -> 20，确认同步原语和拓扑关系；再看 42 -> 34，确认通信等待和 overlap 是否已经吞掉收益。
常见结果是：
- 如果
sync占比高，说明 AllReduce 或同步开销在拖慢。 - 如果
bubble高，说明流水线没有排满。 - 如果
overlap低，说明通信和计算没真正重叠起来。
这个案例的重点是：加卡只是把显存问题拆开，不代表训练一定更快。
案例 2：ZeRO 后显存降了，但 step time 变长
现象是：启用 ZeRO 后，显存明显下降，但每步耗时却增加。
判断链路是：先看 06 -> 27，确认状态切分是否有效；再看 42 -> 34 -> 31，确认收益是不是被更多的通信和管理开销吃掉。
常见结论是：
- 如果状态切分有效但访问更频繁，时间代价会上升。
- 如果 benchmark 没对齐 workload，结论会被误判。
这个案例的重点是：显存收益和时间收益不是同一个方向，必须一起看。
案例 3：Tensor Parallelism 在小 batch 下不划算
现象是：算子内部切分后，通信频率变高，小 batch 场景下收益不明显。
判断链路是：先看 29 -> 42，确认切分后的通信压力；再看 42 -> 34 -> 31，确认真实吞吐是否被通信成本抵消。
这个案例的重点是：并行策略要和切分层级、batch 规模、通信拓扑一起看，不能只看理论扩展性。
专题主线
这页不是按单个并行方法罗列，而是按“通信原语 -> 并行切分 -> 调度与代价 -> 基准验证”的链路来读。
| 主线 | 关注的问题 | 适合先看 |
|---|---|---|
| 通信原语主线 | NCCL 和 AllReduce 到底在做什么 | 05 -> 20 |
| 显存分摊主线 | ZeRO 怎么把参数、梯度和优化器状态拆开 | 06 -> 27 |
| 流水线主线 | Pipeline Parallelism 的 micro-batch 和气泡怎么理解 | 28 -> 34 |
| 张量切分主线 | Tensor Parallelism 的切分和同步代价怎么判断 | 29 -> 42 |
| 选型验证主线 | 怎么把并行策略的收益和通信代价算清楚 | 42 -> 34 -> 31 |
一页速记
| 层级 | 你主要关心什么 | 在本专题里怎么看 |
|---|---|---|
| 计算层 | 单卡算子和单步前向/反向是否合理 | 先看基础模块，再判断是不是本身就算得慢 |
| 切分层 | 参数、梯度、激活该怎么分到多卡上 | 重点看 ZeRO / Pipeline / Tensor Parallelism |
| 通信层 | 同步、AllReduce、Overlap 和等待时间 | 重点看 42 -> 34 -> 31 这条验证链 |
| 验证层 | 多卡扩展到底有没有收益 | 最后回到 benchmark，确认吞吐和气泡是否改善 |
建议阅读顺序
- 先看
05 -> 20，把通信原语和拓扑关系立住。 - 再看
06 -> 27 -> 28 -> 29，判断该用 ZeRO、Pipeline 还是 Tensor Parallelism。 - 最后看
42 -> 34 -> 31，把通信热点和收益验证闭环起来。
典型案例
加卡不加速
如果 GPU 数量增加了但速度没涨，先别假设“模型太大”，而是先查是不是同步等待过高。05 -> 20 能先把原语和拓扑关系说明白，42 -> 34 能把通信热点和等待时间坐实。
并行策略选择
如果要选并行策略，先看切分层级：状态切分用 ZeRO，层切分用 Pipeline，算子内部切分用 Tensor Parallelism。对应阅读是 06 -> 27、28 -> 34、29 -> 42。
通信是否重叠成功
很多优化看起来通信少了，但其实只是被挪到了别处。要用 42 -> 34 看 overlap 和 idle time，确认通信是不是被真正藏进计算间隙。
典型阅读链
- 如果你想先理解多卡通信原理，先读
05 -> 20，把通信拓扑和 AllReduce 先讲通。 - 如果你想先理解显存是怎么被并行策略切开的，先读
06 -> 27，把 ZeRO 的收益和代价讲清楚。 - 如果你想先理解流水线为什么会有气泡，先读
28 -> 34，把 micro-batch、排布和基准结果串起来。 - 如果你想先理解张量切分的通信压力，先读
29 -> 42，把切分方式和通信热点串起来。 - 如果你想先看并行策略值不值，先读
42 -> 34 -> 31，把通信 profile、分布式 benchmark 和最终收益连起来。
对照表
| 场景 | 先看什么 | 重点差异 |
|---|---|---|
| 只想看同步 | 05 -> 20 | 先确认通信原语和拓扑 |
| 要选并行法 | 06 -> 27 / 28 / 29 | 区分状态切分、层切分和算子切分 |
| 多卡不加速 | 42 -> 34 -> 31 | 看等待、气泡和 overlap |
| 想做扩展 | 2.8 | 看策略如何和训练目标对齐 |
进一步展开
1. 先看通信层级
- 如果是参数/梯度同步，先看
AllReduce。 - 如果是状态切分，先看
ZeRO。 - 如果是层切分，先看
Pipeline。 - 如果是算子内部切分，先看
Tensor Parallelism。
2. 再看资源代价
- 通信是否把计算间隙吃掉了。
- micro-batch 是否造成了气泡。
- 显存分摊是否真的换来了规模提升。
3. 最后看验证口径
- 只看显存不够，要看时间。
- 只看单卡不够，要看多卡。
- 只看一次实验不够，要看 benchmark。
FAQ
ZeRO和Tensor Parallelism能一起用吗？可以，但它们解决的是不同层面的切分问题，组合后要额外关注通信复杂度和调度边界。Pipeline Parallelism为什么常常会有气泡？因为 micro-batch 在流水线上需要填充和排空，阶段不平衡时就会留下空转。- 这个专题是不是只讲训练？不是，通信原理和并行边界也会直接影响推理和服务化场景。
通信 profiling的结果为什么不能直接当结论？因为它需要结合 workload、batch 和请求分布一起解释，单看热图容易误判。
观测清单
- 先看
allreduce / sync占比，判断是不是通信把训练或推理拖慢了。 - 再看
bubble / idle time，判断是不是流水线没有排满。 - 再看
memory split / state shard，判断是不是显存分摊真的起作用。 - 再看
overlap / wait time，判断是不是通信和计算没重叠起来。 - 最后回到
34 / 31，把并行策略的收益和代价放到 benchmark 里验证。
简单规则
- 先判定问题是不是同步/等待。
- 再选并行策略，不要反过来。
- 最后用 benchmark 验证吞吐和显存收益。
常见错误
- 盲目加卡。
- 把不同切分层级的并行方法混为一谈。
- 只看显存，不看气泡和通信等待。
深入阅读
- 想看完整并行选型故事，去 通信与并行深入阅读。
- 想快速回顾摘要、案例和清单，继续留在本页即可。
相关专题
- Profiling 专题：当你先要确认瓶颈是不是通信时看这里。
- 显存优化与性能调优专题：当通信策略和显存分摊、cache 压力一起出现时看这里。
- 编译与图优化专题：当并行策略要和执行模型、backend 约束一起看时看这里。
小结
通信与并行的关键不是“有没有多卡”，而是“切分层级和通信代价是不是匹配当前问题”。