Pipeline Parallel：把模型切成段，让 micro-batch 排进流水线

先把 p、m、F、B 四个量定清楚；后面所有时间线都只用它们。

数据并行（DP）把 batch 切开，每张卡仍要放一份完整模型，显存不降。张量并行（TP）把每层的 GEMM 切开， 每层都要 all-reduce，跨节点带宽吃不消。流水线并行（PP）换一个维度：按层把模型切成 p 段， 每段放一张卡（或一组卡），段间只传边界 activation。

为了让 p 段同时忙起来，PP 把 mini-batch 再切成 m 个 micro-batch。每个 stage 对每个 micro-batch 做一次 forward（F）和一次 backward（B）。stage s 的 F 要等 stage s−1 的输出，B 要等 stage s+1 的梯度——这就是流水线的依赖链。

依赖链的代价是气泡（bubble）：开始时要等 p−1 个 stage 依次拿到第一个 activation， 结束时要等 p−1 个 stage 依次把梯度传回去。m 越大，这段固定开销越容易被摊薄；p 越大，首尾空转越长。

第二个代价是激活显存。做 B 的时候要用 F 时留下的 activation。GPipe 把 m 个 micro-batch 的 F 全做完才做 B，所以这 m 份激活都得留着；1F1B 在 steady state 里一 forward 一 backward，最多只留 p 份。

两条路线的分歧不在数学，而在「什么时候做 backward」。

三种 schedule 的差别可以压成一张表（据 GPipe §2.3、PipeDream §3.3、SC21 §2.2 与 Megatron 源码整理；不是原文表格）：

这里要区分 PipeDream 原版和 Megatron 的 1F1B：PipeDream 用 weight stashing 让异步流水线的权重版本一致 （PipeDream §3.4，按 arXiv 1806.03377v1 的编号；SOSP 版章节号可能不同），而 Megatron 的 1F1B 在每个 batch 末尾做 flush，保持同步语义（SC21 §2.2.1 称之为 PipeDream-Flush）。本页的时间线按后者画。

调 p 和 m，直接看气泡怎么被摊薄；再切换 GPipe/1F1B，看同样的气泡被放在哪里。

p 是 stage 数，m 是 micro-batch 数。总时间线长度是 2(m+p−1) 个时间单位：m 个 F + m 个 B + 首尾各 p−1 个空转。理想时间是 2m；差值 2(p−1) 就是气泡。m 相对 p 越大，气泡占比越低。

论文的实验观察是 M ≥ 4×K 时气泡开销可忽略（§2.3）。这是吞吐实验的结论；上面的 1:1 公式给的是 时间线占比，两者不是同一把尺子推断（§2.3 同时给出公式与实验观察，未说明二者如何换算）。 公式用来比较 p、m 的相对影响，不用来复现论文的实测吞吐。

自己动手：拖 p 和 m，切换 GPipe / 1F1B

下面是最小时间线模拟：每个 stage 一行，横轴是时间；绿色是 forward，紫色是 backward，斜线格是 bubble。 切换 schedule 只改变 F/B 的顺序，不改变总计算量。

Interleaved 1F1B：把气泡再除以 v，但通信乘上 v

每张卡不再只持有一段连续层，而是持有 v 个 model chunk（例如 4 层变成 2 个 chunk，每块 2 层）。 调度时按 chunk 交错，设备在等某个 chunk 的梯度时可以先算另一个 chunk 的 forward。SC21 §2.2.2 给的近似是： 气泡时间变为原来的 1/v，通信量增加 v 倍。

代价是 m 必须按 p 分组：SC21 要求 m 是 p 的整数倍；Megatron 的实现允许最后一组有余数，但余数必须为 0 或 ≥ p，否则会报 “dependency bubbles” 错误（schedules.py:1164-1174）。

看代码怎么选 schedule、怎么算 warmup、怎么发 p2p。

入口是 get_forward_backward_func（schedules.py:53）。非 MultiModule 路径下，它只看两个配置：pipeline parallel size 和 virtual pipeline size。pp_size > 1 时，有 virtual pipeline 就走 interleaved，否则走 non-interleaved 1F1B；pp_size = 1 走 no_pipelining（schedules.py:161-167）。

warmup 怎么算。non-interleaved 的 warmup 数是 total_stages - current_stage - 1（schedules.py:2301），也就是 p−rank−1； steady loop 跑 m - warmup 次「一 forward 一 backward」（schedules.py:2409）， 最后 cooldown 把 warmup 阶段留下的 backward 做完（schedules.py:2488）。

interleaved 的 warmup 数更复杂： (pp_size - rank - 1) * 2 + (num_model_chunks - 1) * microbatch_group_size_per_vp_stage （schedules.py:958-959）。代码里前一项固定乘 2；后一项按 (num_model_chunks - 1) * microbatch_group_size_per_vp_stage 填充。schedule 的 (microbatch, chunk) 顺序由 get_schedule_table 生成（schedules.py:983），warmup/steady/cooldown 的主循环分别起于 schedules.py:1567、:1727、:1965（对应的段起始注释在 1536、1725、1948）。

p2p 怎么发。P2PCommunicator（p2p_communication.py:148）封装 pp group； _batched_p2p_ops（:22）用 torch.distributed.batch_isend_irecv 批量提交 isend/irecv；steady state 用 send_forward_recv_backward（:521）和 send_backward_recv_forward（:554）把两个方向的重叠起来。通信只发生在 stage 边界， 传的是 activation / gradient 的张量，不传整层参数。

激活怎么省。non-interleaved 循环里维护 input_tensors 和 output_tensors 两个列表：warmup append 见 schedules.py:2393-2394；steady append + pop(0) 见 schedules.py:2453-2461，cooldown 继续 drain。列表长度由在飞 micro-batch 数决定， 不会增长到 m。这就是 1F1B 在代码层面的省显存机制。

Megatron 用 parallel_state 里的 group 函数把三维并行拼起来： get_tensor_model_parallel_world_size（parallel_state.py:2151）、 get_pipeline_model_parallel_world_size（:2159）、 get_pipeline_model_parallel_rank（:2187）、 get_virtual_pipeline_model_parallel_world_size（:2257）、 get_data_parallel_world_size（:2321）。PP 只是其中一个轴。

论文 §3 把 TP 描述为 “orthogonal and complementary to pipeline model parallelism”；Appendix B 讲的是 model+data parallel 的 group 划分。论文的 8.3B / 512 GPU 实验是 8-way TP + 64-way DP，不含 PP； 论文 §6 明确说更大的模型需要把 intra-layer 和 inter-layer model parallelism 叠加起来。

空格就是 bubble；GPipe 把气泡堆在首尾，1F1B 把它切碎摊开。

GPipe 的时间线是两块三角形：前 8 个 F 依次填满 4 个 stage，最后 8 个 B 再依次退出。每个 stage 的空转都集中在首尾， 共 6 个时间单位。1F1B 的时间线是锯齿：stage 0 先做 3 个 warmup F，再做 1 个 steady F，然后等梯度做 B……空转被切碎， 但每个 stage 仍然是 6 个时间单位。两者的总时长都是 22。

真正的差别不在时间线长度，而在激活：GPipe 要同时保留 m=8 个 micro-batch 的激活，1F1B 最多 p=4 个。Interleaved 没有画进来：它会把每个 stage 的工作再切成 v 份，气泡缩小，但 p2p 消息变多； 时间线更碎，不改变总计算量。

GPipe 的两张吞吐表，和 Megatron 的 3D 组合数据。

Table 2 是 GPipe 在 TPU 上的归一化训练吞吐：每个分区一张 accelerator，batch size 按显存调整。行是 micro-batch 数 M，列是分区数 K。M=1 表示没有 pipeline parallelism。

Table 2：归一化训练吞吐（TPU；batch size 按显存调整）

M=1 时，K 从 2 到 8，AmoebaNet 只从 1 到 1.38，Transformer 从 1 到 1.3：只有一张卡在算，pipeline 没有并行度。 M=32 时，Transformer 在 K=8 达到 6.3，是 K=2 时 1.8 的 3.5 倍（6.3/1.8；论文 §3 也写 3.5× speedup）； AmoebaNet 从 K=2 的 1.21 到 K=8 的 3.48，只有 3.48/1.21≈2.9×，低于 4× 线性，论文归因于各层参数量/计算量不均衡。

Table 3 在没有 NVLink 的 GPU 上，M=32、K 从 2 到 8：AmoebaNet 2.7×，Transformer 3.3×。GPipe 只在分区边界传 activation，所以 PCIe 也能跑出接近线性的趋势；论文 §3 说 communication bandwidth 不再是 model parallelism 的瓶颈。

Table 3：无 NVLink 的 GPU 归一化吞吐（M=32）

Table 1 未完整转录，只取关键行；其余分区/显存行未转录。AmoebaNet-D 从 82M（Naive-1）到 318M（Pipeline-1，重算后）， 峰值激活 6.26 GB → 3.46 GB，减少 2.80 GB（相对减少 44.7%）；同一张表里，AmoebaNet 用 8 个分区到 1.8B， Transformer 用 128 个分区到 83.9B。表头条件：AmoebaNet 行是 8GB NVIDIA GPU，Transformer 行是 16GB TPUv3。 这里的 82M / 318M / 1.8B / 83.9B 都是 Table 1 的直接读数，不需要二次换算。

Megatron 1909.08053 的 8.3B / 512 GPU 结果是 8-way TP + 64-way DP，15.1 PFLOPS、76% scaling efficiency； 论文没有把这个实验说成 PP 的结果，而是明确说 TP 与 PP 正交，>16B 需要把两者叠加（§6）。

PP 解决的是「放不下」，不是「算得快」。

把上面的条件压成一张决策表（据 GPipe §2.3、SC21 §2.2 与 Megatron 源码整理；不是原文表格）：

一句话：p 决定能放多大，m 决定气泡被摊多薄，schedule 决定激活留多少。先看哪个成本在卡你， 再调对应的旋钮；不要默认「上了 PP 就一定更快」。