流水并行的气泡本质是“等”，等前一个stage算完，等后一个stage把梯度传回来，这期间GPU空转就是气泡，消减气泡的核心思路只有三条：把任务拆得更碎、把顺序排得更好、把空闲时间用来做别的。
流水并行气泡到底是怎么冒出来的
很多人在本地调通单卡训练后,第一次上多卡流水并行，发现GPU利用率惨不忍睹，打开nsys或NVIDIA的DCGM监控，能看到一排rank的算力曲线像波浪一样此起彼伏，这就是气泡。
要理解气泡,得先看流水并行怎么干活，假设你有4张卡，把一个大模型切成4段，每张卡负责其中一层或几层，一个batch的数据从第0张卡流到第3张卡，前向传播算完，再反向传播算梯度，梯度再一层层传回来，问题来了：第3张卡在等第2张卡往前传数据的时候，它没事干，第0张卡在等后面梯度传回来的时候，它也在干瞪眼。
业内专家指出,传统流水并行在stage数量较多的时候，气泡占比相当可观，用公式表达就是气泡率约等于(p-1)/(p+m-1)，p是流水级数，m是micro-batch数量，p越大，气泡越难压下去，你可以把这张卡想象成一个流水线上的工人，前一个工位没把零件递过来，你就只能站着等。流水并行优化史，本质上就是一部“让工人少站一会儿”的斗争史。
这里有个更隐蔽的问题反向传播的时间通常比前向传播长，在常见的1F1B调度（一个前向跟一个反向）下，调度不均会进一步加剧气泡。
拆小任务是最直接的消泡手段：interleaved调度的魔力
既然气泡源自“等待”，最朴素的想法就是把任务拆得足够碎，这就是interleaved pipeline schedule的核心思路，也有人管它叫V-shape调度。
普通流水并行中,每张卡只负责一个连续的大chunk，interleaved不一样，它把模型切成更多份，比如有4张卡，把模型切成8个chunk，第0张卡负责chunk 0和chunk 4，第1张卡负责chunk 1和chunk 5，以此类推，这样每个stage的颗粒度变小，前向和反向可以交替执行，气泡被明显压薄。
1F1B和Interleaved是现在最常被对比的两种方案，二者的核心区别如下：
| 对比维度 | 传统1F1B调度 | Interleaved调度 |
|---|---|---|
| 模型切分方式 | 每卡一段连续层 | 每卡多个不连续chunk |
| 气泡占比 | 较高，stage多时明显 | 较低，理论可减半甚至更多 |
| 显存开销 | 较低 | 需要缓存多个chunk的中间激活，显存开销上涨 |
| 通信次数 | 每个micro-batch通信一次 | 通信次数翻倍，但单次通信数据量不变 |
| 工程复杂度 | 成熟，Megatron原生支持 | 需要model parallel size与chunk数量配合，调参难度高 |
你需要知道的实操路径很明确,如果你用Megatron-LM，打开--pipeline-model-parallel-size设定流水级数，再设置--num-layers-per-virtual-pipeline-stage开启interleaved，这个参数的值就是virtual chunk的大小，实践中把num-layers-per-virtual-pipeline-stage设为1或2，效果通常最明显，代价是通信量上升，如果你的机器用的是PCIe互联而非NVLink，这部分开销可能会吞掉消泡的收益。
从源头消泡：zero-bubble技术挑战了什么
interleaved虽然把气泡削薄了,但没从根本上消除它，2026年前后，学界和工业界开始关注一种更激进的想法：把气泡从调度里彻底抠出去，这就是zero-bubble（ZB）技术路线。
核心出发点很反直觉：让每个stage在等待梯度的时候，去算别人家的活，传统流水并行中，每个stage只算自己那几层的梯度，没活干的时候就等着，zero-bubble思路下的调度，把反向传播拆解成两部分梯度的计算和权重的更新（或者对输入激活的梯度计算），其中某些部分是可以重新排列的，通过精细编排，让stage在原本的空窗期去执行不需要完整依赖链的梯度计算任务。
实操层面,如果你在DeepSpeed环境里做流水并行，可以关注它的管线调度定制能力，配合--zero-stage配置做显存优化，而在Megatron生态中，业界已尝试把interleaved和部分ZB思想结合，在较深的模型上获得了比单纯interleaved更低的空闲率，但ZB方案工程复杂度高，通信模式也更难捉摸，很多团队评估后觉得“收益还不够抵消工程成本”，目前大多停留在实验阶段。
还有一个“旁门左道”值得重视计算与通信重叠，气泡的本质是GPU在等数据，那能不能在等待的时候干点不依赖通信的活？常见做法包括：接收下一个micro-batch
的权重梯度时，同时做当前micro-batch的参数更新，或者把LayerNorm、Dropout这类计算量小但依赖上个stage结果的操作，与大型矩阵乘错峰执行，在NVIDIA的Transformer Engine中，部分算子已经被无缝编排了，你只要保证数据加载和预处理不拖后腿就行。
调优落地的几个关键细节
气泡率可以靠理论公式估算,但实际做过大模型训练的人都清楚，纸上算的优化比例和机器上能跑出来的数经常对不上，这里有三个工程上的坑和经验，直接照着做就能看到改善。
通信与拓扑适配怎么兼顾，很多团队用torch.distributed或Megatron时，默认走NCCL的ring allreduce，但在流水并行中，数据是一对一顺序传递的，这个场景更适合point-to-point通信，把NCCL_P2P_LEVEL设置为NVL或PIX，避免走共享内存中转，能显著降低延迟，如果你在云厂商买的实例是跨机流水并行，且机间带宽只有25Gbps甚至更低，那“多租户抢占带宽”甚至会被旁边租户的流量打到通信超时，这时宁可调大--overlap-p2p-communication去蹭通信和计算的重叠，也别硬着头皮加batch size。
显存和Batch Size的平衡，气泡小了不代表一切好了，interleaved的代价是显存涨得厉害，实践中，很多人在较大的模型上用“小chunk + 梯度检查点”的组合：把--recompute-method设成uniform，每层都做checkpoint，这样中间激活不存，反向时重算一遍，虽然多算了些FLOPs，但在显存和气泡之间找到了可接受的平衡点，有一种典型场景是：模型大到大模型训练显存不够怎么办成为团队核心痛点时，单纯压气泡没意义，得先确保跑得起来。
数据加载也可能是隐形气泡制造机，很多工程师把注意力全放在管线调度上，忽略了一个简单事实：如果数据加载跟不上，哪怕调度再完美，GPU照样在等数据，把DALI或tf.data这类预处理管线打开，用WebDataset格式把数据打成多个tar包，能大幅减少随机读小文件的IO压力，在多机场景下，优先把数据放进内存文件系统或NVMe SSD，别让网络文件系统（NFS）成为瓶颈，如果数据预处理包含解码、缩放、归一化等环节，可以考虑在数据加载进程里用CPU并行预处理，GPU只拿现成的张量。
核心问题速查：跟气泡缠斗的常见困惑
流水并行气泡怎么算？跟数据并行有什么区别？
气泡的定量评估可以用profiler跑出来,Megatron启动时加--profile-step-start和--profile-step-end，或者用NVIDIA Nsight Systems抓取三个iteration的GPU kernel时间线，统计一个iteration里GPU空闲的时间和总时间的比例就是气泡占比，数据并行每个GPU持有完整模型副本，同步梯度后各自更新参数，没有等待上下游数据的空窗期，所以数据并行天然没有流水气泡，但显存压力大得多，通信量也是全量梯度的allreduce，比流水并行的点对点通信重量级得多。
1F1B调度下的通信开销有办法压下去吗？
有,最常见的做法是开启P2P通信与计算重叠，Megatron中对应--overlap-p2p-communication参数，开启后，前一个stage在计算当前micro-batch时就会预取下一个micro-batch的tensor，而不是算完再等通信，此外把模型切分点选在算子边界而非层边界（比如切在LayerNorm之后），也能减少跨stage的tensor体积，实际项目里，通信重叠能掩盖掉相当一部分P2P延迟，但需要留意的是，overlap开启后显存峰值会略微上浮，因为要预存下一份数据，如果你的显存已经很紧，观察nvidia-smi的显存占用率再决定是否开启。
消减气泡后还能再顺手省点训练成本吗？
可以,气泡下降意味着固定算力开销下有效训练时长上升，GPU利用率提高了，训练总时长缩短，电费和云资源成本自然下降，以常见的云GPU实例价格估算，把气泡率从25%压到15%左右，大模型训练成本一般多少这个问题，答案会直接打八五折到九折，如果再结合混合精度训练（BF16）和梯度检查点，显存占用降下来后还能用更大的batch size换吞吐，但省钱的另一条腿是别过度设计模型不太深、stage只有两三个的时候，传统1F1B已经够用，折腾interleaved或者ZB方案大概率得不偿失，工程维护成本反而成了大头。
流水并行的气泡没法做到物理意义上的“零”，但通过interleaved拆碎任务、zero-bubble重排计算、通信与计算重叠这三板斧，把空闲率压到10%以下在当前主流框架里是可行的，一切优化的起点，都是先用profiler量出自己集群的气泡到底有多厚，再决定要不要上手段。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623883.html
