流水线并行实战：从气泡原理到GPU利用率调优

手里一个 7B 模型单卡放不下数据并行加上重计算也压不住显存于是我上了 Pipeline Parallel把模型塞进了 4 张卡里。显存确实降下来了但训练速度很尴尬——GPU 使用率忽高忽低曲线全程跳机械舞盯着 nvidia-smi 能看出每个卡都在轮流“摸鱼”。如果你也遇到过这种“模型装下了GPU 却还在等”的情况这篇就是写给你的。我会把这套东西的底层逻辑、气泡来源、调度方式、排查思路和实际调参过程一次讲清楚既有原理也有可直接抄作业的配置。1. 为什么需要 Pipeline Parallel从“单卡放不下”说起1.1 一个 7B 模型到底吃掉了多少显存先把“模型太大”这件事量化了你才知道为什么要折腾流水线并行。以常见的 7B 参数模型为例混合精度训练bf16/fp16 参数 Adam 优化器时的显存开销大致是这样模型参数14GBbf16 下每个参数 2 字节梯度14GB框架里通常也是 bf16/fp16 保存Adam 优化器状态84GBfp32 主权重 28GB 一阶动量 28GB 二阶动量 28GB光这三项加起来就是 112GB 以上一张 80GB 的 A100 装不下。这还没算激活值activation也就是前向传播时为了反向传播而保存的中间张量。激活值跟 micro-batch size、序列长度、隐藏层维度强相关一个稍微长一点的序列就能再吃掉十几 GB 甚至几十 GB。所以对于 7B 以上模型单卡训练基本是站不住的。有人会问数据并行不是也能分摊吗传统数据并行确实可以但它的前提是每张卡上都能放下一份完整的模型副本显存瓶颈依然存在。ZeRO 是把参数、梯度、优化器状态分片到不同卡上但它每次更新都要触发大量的跨卡通信。而 Pipeline Parallel 的选择完全不同直接按层切开每个设备只负责其中一小段网络层的计算显存开销天然就是“总大小的 1/P”。1.2 为什么选择切层而不是切数据通信成本和带宽的取舍流水线并行的核心思想并不复杂把一个大模型按层切成若干段stage第 0 段算完一部分层把中间结果传给第 1 段第 1 段继续算下一部分层依次接力。前向传的是中间激活值反向传的是梯度整个过程很像工厂里的流水线。这和数据并行最大的区别是通信量。数据并行每个训练步骤都要 AllReduce 同步完整的梯度跨机通信量动辄几个 GB流水线并行只需要在相邻 stage 之间传输 activation 和梯度数据量通常只有几 MB 到几十 MB通信量小了一个数量级以上。对于跨节点跨服务器训练这种低通信特性非常有价值因为机间网络带宽远低于机内 NVLink。但天下没有免费的午餐。切层带来的新问题是设备之间产生了先后依赖前一个 stage 不把结果送过来后一个 stage 就只能干等。这种等待在流水线并行里有一个专用名词叫气泡bubble也是本文标题里“GPU 还在等”的最根本来源。1.3 拆解三个关键概念stage、micro-batch、pipeline depth要聊清楚流水线并行三个基础概念得先立住。第一是 stage流水线阶段。整个模型被切成 P 段P 就是流水线深度pipeline depth。比如 4 张卡就是把 48 层 Transformer 切成 4 份每张卡负责 12 层。第二是 micro-batch微批次。如果以整个 global batch 为单位塞进流水线那么某一时刻只有一张卡在干活其他卡全在等效率极差。于是人们把一个大的 batch 拆成 M 个小的 micro-batch让它们一个接一个地流进流水线好让不同 stage 能同时处理不同 micro-batch。第三是 micro-batch 数量 M。它直接决定了流水线能有多“满”。M 越大每个 stage 越不容易闲着气泡占比越小。但 M 也不能无脑加后面会详细讲。想理解这三个概念的关系可以联想到高速公路隧道一辆车模型层的计算要经过多个隧道stage如果你只有一辆车那每过一个隧道就只看到一辆车在跑其他隧道全空着如果你排了很多辆车micro-batch所有隧道才能同时有车在跑。2. 核心原理拆解气泡Bubble是怎么把 GPU 拖垮的2.1 一个时间线推演从 P4、M4 看 GPU 的空闲为了直观我拿 P4、M4 来推演一遍。假设每张卡算一个 micro-batch 的前向F需要 1 个时间单位反向B也需要 1 个时间单位那么朴素 GPipe 调度的时间表大致如下时间Stage 0Stage 1Stage 2Stage 3t0F0空闲空闲空闲t1F1F0空闲空闲t2F2F1F0空闲t3F3F2F1F0t4B0F3F2F1t5B1B0F3F2t6B2B1B0F3t7B3B2B1B0t8空闲B3B2B1t9空闲空闲B3B2t10空闲空闲空闲B3注意看Stage 0 在 t8 到 t10 等了 3 个时间单位Stage 3 在 t0 到 t2 也等了 3 个时间单位。整个流水线跑完这 4 个 micro-batch 用了 11 个时间单位而理想状态下 4 张卡全部满负荷只需 8 个时间单位。效率损失接近 27%。这就是气泡流水线启动和排空阶段总有一部分 GPU 是闲置的。气泡率计算公式在 GPipe 论文里给得很明确气泡率 ≈ (P - 1) / (M P - 1)这里的 P 是 stage 数M 是 micro-batch 数。公式的前提是各 stage 负载均衡、F 和 B 时间大致相等。2.2 为什么 M 越大气泡越小一个量化对比把公式代几个典型值进去感受会更直接Pstage 数Mmicro-batch 数理论气泡率4427.3%4827.3%4328.6%8830.4%81630.4%8649.8%看出规律了吗同样的流水线深度micro-batch 数量越大气泡占比越低。粗算一下M 大于 4 倍 P 之后气泡就能压到 10% 以下M 越大越接近“流水线一直处于满负荷状态”。这也是为什么实际框架里要求配一个足够大的 num-microbatches而不是随便填个数字。当然 M 也不是越大越好M 变大意味着 global batch size 变大直接影响收敛和学习率M 变大还会让激活值显存占用变大在部分调度策略下。所以 M 是一个要反复权衡的超参数一般经验是从 M ≥ 3P 开始调然后结合显存余量往上加。2.3 1F1B 调度为什么能省显存上面那张时间表其实是“最朴素”的 GPipe 调度先完整跑完所有 forward再统一跑 backward。问题很明显——所有 micro-batch 的 activation 都得先存着等 backward 来了才能释放显存峰值和 M 直接成正比。M 一多显存一样会炸。业界主流解决方式是 1F1BOne-Forward-One-Backward调度也叫 memory-efficient pipeline schedule。核心思路是只要当前 device 上某个 micro-batch 的 backward 已经完成就立刻开始下一个 micro-batch 的 forward让 forward 和 backward 交错执行。这样稳态阶段每一张卡上“同时存活”的 micro-batch 数量很少activation 占用的显存大幅下降。对比一下GPipe 最多需要保存 M 个 micro-batch 的 activation1F1B 在 P 个 stage 的流水线里单卡同时只需要保存 O(P) 个左右的 activation。P 通常是个小数字4 到 16而 M 可以到几十甚至上百。所以 1F1B 在显存友好度上有本质优势这也是它成为 Megatron-LM、DeepSpeed 等框架默认调度的原因。但需要注意1F1B 并没有消除气泡它只是显著降低了显存占用并改善了一点流水线行为。气泡的数学本质没有变M 不够大的话该等还是等。2.4 Interleaved 调度用更多通信换更低气泡为了进一步压气泡Megatron-LM 提出了 Interleaved Pipeline也可以叫 Virtual Pipeline。它的做法是把每个 stage 负责的层数再细分比如每个 stage 本来负责 12 层现在把 12 层拆成 3 份每份 4 层多个“虚拟 stage”交替执行。插一句人话解释原来一个设备只做一个大任务做完 A 再做 A 的下一段现在设备要同时维护两三个小任务轮流做一下 A1、再做一下 B1、再做 A2、再做 B2。这样气泡被拆细了整体空闲时间缩短。Interleaved 的直观效果气泡率可以在原有基础上再缩减约 V 倍V 是虚拟 stage 数。代价是相邻设备间的通信次数增加了 V 倍因为每个虚拟 segment 都需要一次 p2p 传输。如果你的机器带宽很差这一招要慎用如果机内带宽不错收益通常远大于通信开销。3. 实战配置micro-batch、调度策略和通信优化3.1 主流框架里怎么开流水线并行最常用的两个开源方案是 Megatron-LM 和 DeepSpeed。它们都支持 Pipeline Parallel参数风格略有差异。Megatron-LM 里跟流水线相关的主要参数是这样python -m torch.distributed.launch \ --nproc_per_node8 \ pretrain_gpt.py \ --tensor-model-parallel-size 2 \ --pipeline-model-parallel-size 4 \ --num-microbatches 16 \ --global-batch-size 128--pipeline-model-parallel-size 4把模型切成 4 个 stage需要 4 张卡来负责不同层。--tensor-model-parallel-size 2在每个 stage 内再按张量切分2 张卡做张量并行。--num-microbatches 16一次 global batch 被切成 16 个 micro-batch。如果想让 Interleaved 生效需要再加一个参数类似--num-layers-per-virtual-pipeline-stage把虚拟 stage 的层数指定出来。DeepSpeed 的配置主要在 JSON 里做法是通过 ZeRO 流水线并行组合实现不再展开命令行参数核心仍然是设置 pipeline 并行度、micro-batch 数和调度参数。3.2 PP 传的到底是什么数据为什么传一点点也会卡很多人第一次看 PP 的通信量会觉得不可思议一个 activation 张量才几十 MB怎么会让卡等这么久这里要分清两个概念数据量小 ≠ 延迟低。PP 里的 p2p 通信是串行依赖的Stage i 算完 F 之后必须把 activation 发给 Stage i1Stage i1 才能开始它的 F。这期间如果通信没有和计算重叠接收方就是纯等待。虽然传的数据不多但它的位置处于关键路径上一次延迟就被放大成一个 bubble。以 GPT-3 这类模型为例单次 p2p 传输的 activation 大小大致是 micro-batch size × 序列长度 × hidden size × 字节数常在几 MB 到几十 MB 之间。相比数据并行里每步几个 GB 的 AllReduce量级确实不大。但 PP 的 M 一多传输次数就多M 次 forward p2p M 次 backward p2p如果网络延迟高总等待时间依然可观。实际项目中以下几点会比较管用尽量让 p2p 通信和本地的 compute 重叠。Megatron 和 DeepSpeed 在底层会用独立 CUDA stream 来做这个事版本较老或通信库不匹配时重叠效果会很差需要检查实际 timeline。节点内通信走 NVLink 时延迟很低问题不大跨节点通信走 InfiniBand 或 RoCE延迟敏感尤其是 P 很大时。如果卡的是跨节点传输优先把 PP 的边界对齐到节点边界让同一个节点内的 stage 之间尽量少跨机传输。注意很多框架对 p2p 消息有顺序要求不允许乱序接收。这意味着你没法简单地把所有通信都丢给一个独立线程去做必须严格按依赖顺序收发。这个特性在自定义调度时特别容易踩坑。3.3 和 TP、DP 组合时怎么分配经验法则真正的大规模训练很少只用 PP通常是 PP、TPTensor Parallel、DPData Parallel三者混合。我的分配经验是节点内优先考虑 TP。NVLink 带宽高、延迟低TP 通信密集的问题在节点内不明显TP 没有气泡利用率更稳。跨节点优先考虑 PP。PP 每步只传少量张量通信量适合低速链路DP 的 AllReduce 通信量大跨节点用多了会拖慢整体速度。单机 8 卡训练 7B 或 13B 模型通常 TP4 或 TP8 DP 就够了PP 在这种场景下收益有限反而会因为 bubble 拉低性能。只有在单机多卡依然放不下或者要跑更大模型时才引入 PP。多机场景比如 32 卡以上常见做法是节点内 TP2~8节点间 PP4~8剩余维度做 DP。当然具体要看模型大小和网络拓扑没有绝对公式。一句话总结能用 TP 和 DP 解决就不要上 PP不得不上 PP 时把 PP 的维度架在通信相对慢的那一侧并用 M 把气泡压下去。4. 排查实录模型装下了 GPU 却在等待的常见原因4.1 原因一micro-batch 数量太少bubble 占了大头这是我在实际项目里遇到最多的情况。很多刚接触 PP 的人把--num-microbatches设成 4 甚至 1然后就开跑。模型是装下了但 GPU 利用率长期在 50% 到 70% 徘徊profile 一看全是周期性的空闲。用公式简单算一下就知道P4、M4 时理论气泡就超过 27%实际加上通信延迟和负载不均利用率能上 70% 就算不错。排查方式也很直接把 M 调大几倍比如从 8 调到 32观察有效吞吐有没有明显上涨。如果涨了基本就是气泡问题。4.2 原因二各 stage 负载不均衡有人在加班有人在摸鱼气泡公式有个前提每个 stage 的计算时间基本相等。但真实模型并不是均匀切分就真的均匀。embedding 层、输出层、loss 计算往往分布在头尾设备上某些 attention 层里还可能混着额外分支。结果就是有的 stage 是瓶颈其他 stage 干完自己的活只能等。症状是 nvidia-smi 里各卡利用率差异明显同一时间有人 95% 有人 30%。这种问题光靠调 M 没用得从层分配上调整。我曾经把一个 48 层模型切成 4 段后发现 stage 0 因为多了 embedding 和 loss 计算每轮要多出将近 10% 的时间。解决办法是把 stage 0 的层数减少几层或者把 embedding 这一类重活拆一部分到 TP 维度上让整体更均衡。4.3 原因三p2p 通信没和计算重叠GPU 在空等数据如果 M 已经不小了stage 也没有明显不均衡但利用率还是低那大概率是通信和计算没有做好重叠。此时 profile 里会看到大量时间花在recv相关的等待上或者 NCCL 的 p2p 核函数占了一大块。检查方法用 PyTorch Profiler 或nsys抓 timeline看 communication kernel 有没有和 compute kernel 重叠。看节点内 NVLink 和跨节点网卡的传输速率确认瓶颈在链路还是库。尝试换用较新的 PyTorch/NCCL 版本老版本的 p2p 调度重叠能力差很多。检查你的训练脚本是否强制设置了单 GPU 模式或关闭了异步执行。注意在自定义 Pipeline 实现里不要天真地手动把 p2p 放到新 stream 就认为万事大吉。p2p 的发送和接收有严格的顺序约束而且接收方通常需要预分配缓冲区一旦 stream 同步不当轻则性能回退重则挂死。这类 bug 排查起来非常痛苦。4.4 原因四pipeline flush 造成的周期性空转每个 global batch 训练结束时流水线必须“排空”flush——把最后一个 micro-batch 的 backward 彻底跑完才能做参数更新。这个过程天然会制造尾部气泡。M 越小flush 出现的频率越高尾部气泡占比就越大。如果训练曲线呈周期性波动每隔一个固定步数利用率就掉一下很可能就是 flush 在起作用。加大 M 可以减少 flush 在总时间里的占比但不是彻底消除。Interleaved 调度能把这个尾部空转进一步打散效果更明显。4.5 常见问题速查表现象可能原因排查方向解决建议利用率周期性低micro-batch 太少检查--num-microbatches增大 M或开启 Interleaved各卡利用率差异大stage 负载不均衡profile 各 stage 耗时重新分配层数结合 TP 分担重层大量时间花在 recvp2p 未重叠profiler / nsys timeline升级通信库、检查 stream 调度每个 global step 尾部掉速pipeline flush观察训练曲线周期增大 M减少 flush 频率显存占用远低于预期但性能差调度或 M 过小看实际有效吞吐在显存余量内增大 M 或启用 1F1B5. 实例测算7B 模型在 8 卡上的 PP 调优全过程5.1 从一套不合理的初始配置开始假设场景8×A100 80GB跑 7B 模型训练。我先用了一套比较“偷懒”的配置TP 2PP 4DP 1--num-microbatches 8序列长度 2048hidden size 4096global batch 32micro-batch size 约 4先算气泡P4M8理论气泡约 27.3%。这意味着哪怕通信、显存、负载全部理想利用率上限也只有 72.7%。实际测下来有效吞吐只有理论峰值的 60% 出头曲线里能明显看到 stage 0 和 stage 3 各自有大段空闲GPU 平均利用率 65% 左右。为什么 M8 不好因为 8 倍于 micro-batch 的流水线深度才刚够填满 4 个 stage流水线启动和排空的开销占比太高。这种情况就是典型的“模型装下了但 GPU 在等”。5.2 逐项调整后的配置和效果第一刀把 M 从 8 提到 32。global batch 不变的话需要把 micro-batch size 调小比如 micro-batch size 从 4 降到 1global batch 1 × 32 32。此时理论气泡降到 3/(323)8.6% 左右。显存方面micro-batch 变小后激活值变低反而留出更多空间安全性更高。第二刀开启 Interleaved虚拟 stage 数 V2。气泡进一步下降但 p2p 通信次数翻倍。好在是单机场景NVLink 压得住实测影响不大。第三刀检查 timeline发现 stage 0 因为额外承担了 embedding 计算延迟明显高于其他 stage。我把一部分层从 stage 0 挪到 stage 1并给 embedding 所在 stage 增加了 TP 维度分摊整体负载更均匀。调整后这套配置变成--tensor-model-parallel-size 2 \ --pipeline-model-parallel-size 4 \ --num-microbatches 32 \ --num-layers-per-virtual-pipeline-stage 2 \ --global-batch-size 32实际有效吞吐比初始配置提升了约 30%GPU 平均利用率从 65% 左右升到 82% 以上。剩余的空闲主要来自 flush 尾部气泡和少量通信延迟在单机场景下已经比较接近这套组合的上限了。5.3 经验总结先算率再调数最后看 timeline这套调优过程里最关键的是先把理论气泡算出来。只要理论气泡超过 15%就别指望框架能帮你妙手回春先想办法把 M 提上去或减小 P。然后才是看负载均衡最后才谈 stream 重叠和通信优化。顺序错了会走很多弯路。我见过有人一上来就盯着 NCCL 版本和各种环境变量调翻了大半天结果 profile 一看瓶颈就是 M 太小导致的大段空闲。把 M 调大以后其他问题都显得无关紧要了。最后再分享一个容易被忽略的小技巧检查 PP 相关配置时不要只看--num-microbatches还要确认--global-batch-size和 micro-batch size 的换算关系。很多框架里 global batch micro-batch size × num-microbatches × DP一旦某处配置冲突实际生效的 M 可能跟你以为的不是一回事。动手调参前先把这个等式的每一项都核清楚能省下大把摸黑排查的时间。