以色列理工学院与本古里安大学联手，让AI训练"流水线"彻底告别空转浪费

这项由以色列理工学院（Technion - Israel Institute of Technology）计算机科学系与本古里安大学（Ben-Gurion University of the Negev）电气与计算机工程学院联合完成的研究，于2026年6月5日以预印本形式发布在arXiv平台，论文编号为arXiv:2606.07881。感兴趣的读者可以通过该编号在arXiv上查阅完整论文。

**一、为什么训练大型AI模型会出现"空转浪费"的问题**

当你打开一个导航软件，在路口等绿灯时，整条车道的所有汽车都得停下来，哪怕后面的路段完全畅通无阻。这种等待本质上是一种资源浪费——明明还有很多车可以往前跑，却因为路口信号的限制，全都闲置在那里。

训练大型AI模型时，有一种技术叫做"流水线并行"（Pipeline Parallelism），其工作原理和汽车生产流水线非常相似。把一个庞大的神经网络模型切分成好几段，每段分配给一块不同的GPU（显卡），就像把汽车组装分成"装底盘"、"安车身"、"装轮胎"、"涂装"这样的工序，分别在不同的工位上同时进行，以此来提高整体效率。

然而问题就出在这里：每处理完一批训练数据，整条流水线都必须"清空"——也就是等所有工位都完成手头的工作之后，才能做一次参数更新（类似于让整个工厂暂停，统一讨论改进方案），然后才能开始下一批。在这段等待时间里，有些GPU处于完全空转状态，什么计算都不做，这就是业内所说的"气泡"（Bubble）问题。气泡越大，意味着越多的计算资源被白白浪费。

研究团队将这个浪费量化了：如果流水线有N个阶段，每次只处理m批数据，那么每次清空周期里有N-1个时间单元是在空等，整体效率只有m/(m+N-1)。当流水线很长但每次处理的数据批次不多时，这个效率会低得惊人。

**二、现有解法各有缺陷，像在"拆东墙补西墙"**

既然气泡这么浪费，工程师们当然想办法解决。目前主要有两条路可以走，但都有代价。

第一条路是"同步流水线"方案。这类方法的核心是保证每次计算的参数版本一致——就是说，不管哪个工位在处理哪批数据，大家用的都是同一版本的模型参数。好处是训练过程稳定、结果可预期。GPipe是这类方案的代表，它等所有前向计算完成后才做反向传播，然后清空流水线、更新参数。后续改进版本如Megatron-LM的交错1F1B调度、零气泡流水线并行（Zero-Bubble Pipeline Parallelism，简称ZB）等，都在想方设法缩短等待时间，但代价往往是需要更多的显存，或者对计算时间分配有苛刻的平衡要求。这类方法的根本局限在于：只要想保持参数一致性，就必然需要某种形式的等待和协调，气泡虽然可以减少，但无法完全消除。

第二条路是"异步流水线"方案。既然等待是问题所在，那就别等了——让每个工位处理完就立刻更新自己的参数，不等其他工位。这样气泡确实消失了，流水线可以一直满负荷运转。但随之而来的是一个棘手的新问题：当一批数据完成前向计算、等到后向计算时，模型参数可能已经被更新过好几次了。也就是说，"前向用的是旧参数算出来的中间结果，后向却在用新参数去算梯度"——这两者对不上，就好像你根据昨天的地图计算出了一条路线，走到一半却发现地图已经更新了，路已经改了，但你还在按老路线开。这种"前后版本不一致"的现象，就是所谓的"前向/反向权重版本不一致性"（F/B Inconsistency）。

为了解决这个不一致性问题，现有异步方案要么采用"权重存储"（Weight Stashing）——把每批数据前向计算时用的参数版本保存下来，等到后向计算时拿出来用，代价是显存占用成倍增加；要么采用"参数预测"（Weight Prediction）——预估后向计算时参数会变成什么样，提前在前向计算时就用预测版本，代价是计算复杂度上升，且预测未必准确；还有一些方案通过复杂的调度策略来限制版本漂移，但需要运行多条并行流水线，协调成本很高。

归纳来说，现有的同步方案"有气泡、没有不一致性"，现有的异步方案"没气泡、有不一致性或者要额外付出代价"。这个矛盾是整个领域长期面临的核心挑战。

**三、PACI的核心思路：用"慢更新"来控制版本漂移**

以色列理工学院和本古里安大学的研究团队提出了一个不同寻常的问题：我们真的需要把不一致性降低到零吗？还是说，只要把它控制在一个足够小的范围内，训练就依然可以稳定进行？

这个问题背后隐含着一个重要的洞察：前向和反向之间的参数版本差距，根本上取决于在这段时间里，参数被更新了多少次。流水线的长度决定了前向和反向之间"隔了多少工位"，而每次更新参数的频率则决定了"这段时间里参数跑了多远"。

PACI（Pipeline Asynchronous training with Controlled Inconsistency，受控不一致性的异步流水线训练）的核心策略简单而精妙：保留异步流水线的基本结构（不引入清空等待），但让参数更新的节奏慢下来。具体做法是引入一个"梯度累积"（Gradient Accumulation）机制——每个工位不再处理完一批数据就立刻更新参数，而是积累a批数据的梯度之后才做一次更新。这个a就是"累积因子"，是PACI的核心控制旋钮。

这就好比，原本一条流水线上每个工位处理完一辆车就开一次质量总结会，讨论是否改进工艺。PACI改成了：每处理完a辆车才开一次总结会，讨论改进方案。这样，在一批零件从"进厂"到"出厂"的整个周期里，工艺标准被修改的次数就从最多N-1次降低到了最多(N-1)/a次。

研究团队给出了严格的数学证明：在一个有N个阶段的流水线里，对于某个工位i，它在前向和反向计算之间最多会发生(N-i)/a次参数更新（取上整）。最极端的情况出现在第一个工位，此时版本漂移最多为(N-1)/a次（取上整）。当累积因子a等于N-1时，理论上版本漂移可以降为1，即前后向最多只差一个版本。

**四、防止流水线"跑飞"的本地流量控制机制**

光有梯度累积还不够，还需要防止上游工位跑得太快、大量积压未完成的前向计算。PACI为每个工位设计了一个本地计数器q_i，记录"已经做了前向计算但还没收到对应反向梯度"的批次数量。当这个计数器达到N+1-i时（i是当前工位的编号，从1开始），该工位就暂停接收新的前向计算任务，直到有对应的反向计算完成、计数器下降。

这个机制不是全局同步屏障，不需要所有工位统一行动，也不会引入等待气泡。它只是一个本地的"限流阀"，确保每个工位不会积压太多未完成的任务。就像路口的临时信号灯，只管控自己这个路口的车流，不需要和远处的路口同步。正是这个机制配合梯度累积，共同保证了版本漂移的上界在任何时刻都成立，无论各工位的计算速度是否完全一样快。

**五、PACI与现有方案的正面交锋：实验数据说话**

研究团队在GPT-2 Medium（一种中等规模的语言模型，有约3.5亿参数）上进行了全面测试，在OpenWebText数据集上从头训练，累计处理了498亿个词语，使用8块NVIDIA RTX PRO 6000 Blackwell Max-Q GPU（每张96GB显存）分成8个流水线阶段运行。

关于训练稳定性的测试是最关键的实验。研究团队分别测试了全局批大小128和256两种情况，并使用三个不同的随机种子重复实验，以排除偶然因素的干扰。结果显示，当累积因子a=4时（此时最大版本漂移不超过2次更新），PACI的训练损失曲线几乎和同步1F1B-flush的曲线完全重合，看不出明显的震荡、跳变或发散迹象。偶尔出现的训练不稳定情况经过仔细分析，发现同步版本也同样会发生，说明这是训练本身的随机波动，和不一致性无关。

更有意思的是，PACI不仅训练损失曲线类似，而且实验结果的稳定性更好。以批大小128为例，同步1F1B-flush的训练损失在不同随机种子之间的波动（用均方根标准差衡量）为1.10×10??，而PACI (a=4)只有2.12×10??，PACI (a=8)更是低至1.81×10??。同样在批大小256的情况下，1F1B-flush的波动是5.30×10??，PACI (a=8)降到3.01×10??，PACI (a=16)仅为1.75×10??。也就是说，PACI反而比同步方案更"稳"，不同运行之间的结果更一致。

在最终验证困惑度（Perplexity，衡量语言模型质量的指标，越低越好）方面，批大小256下PACI (a=16)达到15.291，略优于1F1B-flush的15.350；批大小128下PACI (a=8)达到15.483，与1F1B-flush的15.480几乎相同。用完全相同数量的训练数据，PACI能达到至少相当、有时略优的最终模型质量。

**六、更重要的是：同样的模型质量，PACI用时短得多**

模型质量相近只是基础，更关键的问题是：达到同样的质量，PACI需要多长时间？

研究团队设计了"训练时间对准确性"（Time-to-Accuracy）对比实验：记录每种方法在实际挂钟时间下，训练损失曲线到达特定验证困惑度阈值所需的时间。这个指标最能反映实际使用中的效率，因为你不仅关心最终能训练出多好的模型，更关心要花多少时间才能达到那个质量。

结果非常清晰。在批大小128、使用8个微批次的配置下，PACI达到与1F1B-flush（同样8个微批次配置）相同困惑度所需的时间缩短到了后者的54%，也就是快了1.84倍。即便和最快的同步配置（16个微批次的flush）相比，PACI仍然快了1.69倍。在批大小256下，PACI对比最快同步配置的加速比是1.41倍。

如果细看训练过程中不同阶段的加速情况，规律是加速比随着训练进展而增大。到达困惑度≤18时（训练早期），批大小128下对比最快同步配置的加速约为1.55倍；到达困惑度≤16时（训练后期），加速提升到1.64倍。这个趋势背后的原因是：训练初期，两种方法的损失曲线有一点小的垂直偏差（PACI的初始损失稍高一点点），随着训练进行，这个偏差逐渐消失，纯粹的吞吐量优势就越来越主导了时间差距。

用具体数字来说，批大小128、累积因子a=8的PACI配置，完成全部498亿词语的训练只需87.99小时，而最快的同步基准需要148.64小时。少了整整60多个小时，可以少排好几天队等GPU资源。

**七、吞吐量的提升完全符合理论预测**

为了验证这些加速不是来自其他因素，而确实是消除了气泡导致的，研究团队进行了系统的吞吐量分析。

他们以不同数量的微批次运行1F1B-flush，记录每种配置下的实际吞吐量（每秒处理多少词语），然后将每个配置的同步吞吐量除以对应PACI配置的吞吐量，得到一个相对比值。如果加速确实来自气泡消除，这个比值应该和理论气泡效率公式m/(m+N-1)非常吻合。

实验结果和理论曲线几乎完美重合。当微批次数量m=4、流水线长度N=8时，理论气泡效率为4/(4+7)≈36%，意味着1F1B-flush有64%的时间在等待——实测比值确实在36%-40%左右。随着微批次数量增加，两条曲线（实测和理论）都同步上升并趋近于1。这个结果有力地说明了：PACI的吞吐量优势来源明确，就是消除了气泡，没有其他魔法。

研究团队还揭示了一个同步流水线的内在矛盾：增加微批次数量确实能减少气泡（效率从36%提升到更高），但同时每个微批次的数据量会减少，GPU矩阵运算的效率（"核效率"）也会随之下降，因为GPU最擅长处理大块数据。这两种效应相互对冲，导致增加微批次数量的收益在某个点之后就停滞甚至下降了。而PACI不受这个限制，因为它的微批次数量主要由版本漂移控制需求决定，不需要堆很多微批次来减少气泡。

**八、显存代价：几乎为零**

一个常见的担忧是：PACI需要累积梯度，会不会占用更多显存？答案是几乎不会。

梯度累积在标准训练中本就存在——每个工位本来就有梯度缓冲区，梯度累积只是延迟了清零的时机，并不需要额外开辟新的存储空间。参数只保存一份，不需要像PipeDream那样多备份几个历史版本。在稳态运行时（微批次数量足够多、流水线充分填充时），PACI和1F1B-flush的峰值显存几乎完全相同，实验中两者的峰值显存曲线高度重合。只在极端情况下（微批次数量m=4时，流水线尚未进入稳态），两者才有些微差异。

**九、大规模推算：PACI在百亿参数模型上能带来多大提升**

当然，研究团队在8块GPU上测试GPT-2 Medium只是验证原理。真正的大型语言模型训练往往需要数十上百块GPU，模型参数量达到几十亿甚至上百亿。为了评估PACI在更大规模下的潜力，研究团队利用另一篇论文（Zero Bubble Pipeline Parallelism）报告的实测数据进行推算。

零气泡论文使用了多达32块NVIDIA A100 SXM 80GB GPU，测试了1.5B、6.2B、14.6B和28.3B参数的模型。研究团队将这些实测的1F1B-flush吞吐量除以对应的气泡效率因子，得到PACI的预期吞吐量，同时使用1F1B-flush的实测显存作为PACI的显存估计（因为两者设计上显存相同）。

推算结果非常突出。以28.3B参数模型、32块GPU、96个微批次为例：PACI预计能达到每GPU每秒1.01个样本的吞吐量，而同步1F1B-flush只有0.76，差距约33%；零气泡ZB-2p方案能达到0.99，但需要接近两倍的显存（74GB vs 43GB）。换言之，PACI能以1F1B-flush的显存代价，达到接近ZB-2p的速度，同时避免了ZB-2p方案在调度和实现上的种种复杂性。在所有测试的配置中，这些大规模场景的最大版本漂移也都不超过1次参数更新，完全处于研究已验证的稳定范围内。

**十、和其他方案的横向比较**

研究团队在论文中给出了一张详细的对比表，梳理了主要流水线并行方案在四个维度上的表现：是否同步、额外显存占用、气泡多少、前后向不一致性高低。

同步方案里，GPipe额外显存多（需要保存大量中间激活值）、气泡多，不一致性为零；1F1B-flush显存不多、气泡多；ZB-2p气泡接近零但需要约两倍显存。异步方案里，PipeDream完全消除不一致性但需要多份参数副本（显存大幅增加）；PipeMare保留了不一致性并需要额外的速度状态；PipeOptim和SpecTrain等预测类方法不一致性只是近似消除，且需要额外计算。AMDP通过限制读写距离来控制不一致性，但需要多条并行流水线和跨副本梯度同步。

PACI在这张表上独树一帜：无额外显存、零气泡、不一致性低且有上界保证。这是目前已知方案中唯一同时实现这三点的设计。

**十一、一些尚待解决的问题**

研究团队对自己工作的局限性保持了坦诚的态度。目前的实验局限于GPT-2 Medium这一种模型结构，以及OpenWebText这一个数据集，以及最多8个流水线阶段的配置。更大的模型（如数百亿参数）、更深的流水线（如几十甚至上百个阶段）、其他类型的模型结构（如视觉模型、多模态模型）或其他优化器，都还需要进一步验证。

激活检查点（一种通过重新计算中间值来节省显存的技术）与PACI的结合也是一个开放问题。理论上两者可以结合，不会增加参数显存，但重新计算会改变不一致性的表现形式：原本是"旧激活值配新参数"的不一致，变成了"用新参数重新计算的激活值"与"来自下游、基于老计算的梯度"之间的不一致，具体影响尚未完整分析。

另一个技术性限制是梯度裁剪（Gradient Clipping）问题。标准的全局梯度裁剪需要先在所有设备上汇总完整的梯度范数，这在异步执行环境下会强制引入同步点。研究团队提到了使用无需同步的优化器级别替代方案（如SPAM）的可能性，但尚未实现和验证。此外，当某个工位遇到非法梯度（如出现NaN）时，如果下游工位已经更新了参数，上游工位可能无法完整地回滚整个操作，这个边缘情况的处理策略也留待未来研究。

说到底，PACI的核心贡献在于改变了一种思维定式。过去，研究者们普遍认为异步流水线训练中的版本不一致性是必须被消除或精确补偿的"错误"，否则训练就会不稳定。PACI的实验结果说明，这种不一致性只要被控制在合理范围内，训练完全可以正常进行，甚至比同步方案还更稳定。这意味着在大型AI模型训练中，我们不必为了"完美一致"而付出昂贵的时间或显存代价——接受受控的"不完美"，反而能让整个系统跑得更快。对于实际训练大型语言模型的工程团队而言，这意味着在不增加任何额外硬件的前提下，同样的训练时间可以让模型训练得更久、或者同样的训练目标可以更快完成。对于关心AI发展速度和成本的普通人而言，这类效率提升最终会体现在AI产品的迭代速度和算力成本上。如果你对技术细节感兴趣，可以通过arXiv编号2606.07881查阅完整论文。

Q&A

Q1：PACI方法和普通流水线并行训练相比，为什么能节省训练时间？

A：普通的同步流水线训练在每次更新参数前，需要等待所有GPU都完成当前批次的计算，这段等待时间被称为"气泡"，可能占据整体计算时间的30%到60%。PACI采用异步方式，各GPU不需要等待彼此，流水线始终满负荷运转，从而消除了这些气泡。在8个GPU、批大小128的实验配置下，PACI比最快的同步方案快了1.69倍。

Q2：PACI的梯度累积机制怎样控制参数版本不一致的程度？

A：在PACI中，每个流水线工位不是处理完一批数据就立刻更新参数，而是积累a批数据的梯度后才更新一次。这样参数版本演进的速度慢了a倍，而前向和反向计算之间最多只会经历(N-1)/a次参数更新，其中N是流水线总阶段数。通过调大累积因子a，可以把这个版本漂移控制得很小，实验证明漂移不超过2次时训练完全稳定。

Q3：PACI需要额外的显存来存储不同版本的模型参数吗？

A：不需要。PACI的核心设计之一就是每个流水线阶段只保存一份参数，不存储历史版本。梯度累积复用了优化器原本就有的梯度缓冲区，无需额外开辟空间。实验测量表明，在稳态运行时PACI和标准同步1F1B-flush的峰值显存几乎完全相同，这是它相比PipeDream等异步方案的重要优势。