一种面向运行时可变环境下流水线并行训练的就绪驱动运行系统

arXiv: 2605.18750v1

论文信息

标题: A Readiness-Driven Runtime for Pipeline-Parallel Training under Runtime Variability

作者: Ruitao Liu, Xinyang Tian, Shuo Chen, et al.

发布日期: 2026-05-18

arXiv ID: 2605.18750v1

PDF 链接: 下载 PDF

论文背景与研究动机

随着大语言模型和多模态模型规模急剧扩张，流水线并行（Pipeline Parallelism）已成为扩展训练的关键技术。它将模型按层划分到多个 GPU 上，并通过在不同阶段上并行处理多个微批次（microbatch）以隐藏通信延迟。经典的 1F1B（一前向一后向）及其变种被广泛采用，但其进展依赖于一个核心假设：所有计算和通信的耗时在运行时是稳定且可预测的。

然而，现实世界中的训练工作载荷在运行时表现出显著的变异性。即便在完全相同的输入和配置下，GPU 内核抖动、资源争用和通信波动都会导致同一操作的实际延迟产生剧烈变化（实验显示通信延迟的归一化 P95-P5 散布高达 58.74）。当运行时状态偏离了原先预设的固定调度顺序时，各流水线阶段必须按照既定次序等待尚未就绪的任务，即便此时还有其他可执行的工作处于就绪状态。这种僵化的“预提交顺序”带来了大量空闲气泡和阶段不对齐，严重限制了硬件利用率。

现有系统虽然通过离线剖析或在线自适应来优化调度计划，但它们最终仍将优化后的顺序固化为一个必须严格遵守的执行序列，运行时本身无法摆脱这一束缚。本文一针见血地指出：问题的根源不在于调度策略的优劣，而在于将预先制定的顺序强加为运行时的强制约束。为此，作者提出了一种全新的运行时哲学——就绪驱动，并基于此设计了 RRFP（Runtime-Readiness-First Pipeline）。

从固定序列到提示排序：RRFP 的核心理念

RRFP 的核心转变在于对调度计划的消费方式。它不再将调度视为一个必须等待遵循的执行序列，而是将其视为一个非绑定的提示顺序，仅用于在处于就绪状态的任务中进行优先级排序。在每个流水线阶段，运行时首先根据当前激活和梯度的到达情况构建“就绪集”，然后按照提示顺序扫描该集合，拣选出第一个就绪的任务立即执行，而跳过所有尚未就绪的更高优先级任务。

这种设计将调度决策与运行时进度解耦。优点显著：当提示顺序与实际就绪情况吻合时，其行为等价于高效的固定顺序调度；而当出现扰动导致某些任务延迟时，运行时能无缝回退到其他就绪任务，避免因死等而造成流水线停滞。由此，任何现有的调度方案（包括 1F1B、ZeroBubble 等）都可被当作提示顺序复用，但不会因它们的“过时”选择而阻塞执行。

关键技术机制详解

为了实现上述就绪驱动的乱序执行，同时保持训练正确性并避免额外开销，RRFP 引入了三个紧密协作的运行时机制。

消息驱动的异步通信

传统的流水线通信要求相邻阶段以相同的微批次顺序收发数据，乱序执行会打破这一约定，导致失配甚至死锁。RRFP 将数据传输彻底从计算主循环中解耦：每个阶段使用专门的发送和接收线程，计算线程将完成的前向或后向张量（带微批次标识和方向元数据）提交到完成缓冲区并唤醒发送线程；接收线程异步收取从对端到达的消息，根据元数据路由到对应微批次的就绪缓冲区，并直接更新任务就绪状态。这使得前向和后向任务就绪的标志完全由“消息到达”这一真实事件驱动，不再依赖固定的序列同步。

轻量级张量并行协调

当流水线阶段内部采用张量并行（TP）时，同一 TP 组内的各排名必须按照相同的微批次顺序调用集合通信（如 All-Reduce），否则会产生错误或死锁。在就绪驱动模式下，不同排名观察到的就绪集可能不同。RRFP 采用了一种低开销的组内协调协议：每个排名在执行可能涉及 TP 集合操作的前向/后向任务前，先将其选中的就绪微批次标识通过标量 All-Gather 同步给所有组员；仅当所有排名一致时，该任务才会被真正执行，否则将其推迟并重新仲裁。实测表明，该协调步骤的开销仅占迭代时间的不到 1%，而收益是巨大的。

就绪集仲裁与反向-前向提示

仲裁层是调度提示的实际应用者。它将一个固定的优先级排列 Π\Pi 作为参数，在每次计算线程可用时快速扫描就绪缓冲区，按 Π\Pi 的顺序选择第一个就绪的任务。默认配置采用反向-前向（BF）提示：每轮仲裁先检查是否有后向任务就绪，有则执行一个；然后检查前向任务，有则执行一个。同方向内，前向任务优先取模型块索引较小的，后向优先取较大的，以尽早释放模型块用于后续通信与集合操作。BF 提示本质上模拟了 1F1B 的方向偏好，但又完全服从于运行时就绪状态的裁剪。

理论保证：为什么 BF 提示已足够好

为了在理论上验证就绪仲裁的效果，作者在简化的非交错流水线模型下证明了 BF 提示的迭代完工时间上界：

C≤F+B+∑j=1M−1(Fmax⁡j−Flastj)+∑j=0M−2(Bmax⁡j−Blastj)\mathcal{C} \le \mathcal{F} + \mathcal{B} + \sum_{j=1}^{M-1}(F_{\max}^{j} - F_{\text{last}}^{j}) + \sum_{j=0}^{M-2}(B_{\max}^{j} - B_{\text{last}}^{j})

该上界将完工时间分解为理想化纯前向和纯后向流水线时间之和，加上因阶段不平衡引入的惩罚项。进一步的分析表明，当最后一个流水线阶段是瓶颈的概率较高时（在测量中，LLM 场景达到 96.8%，多模态场景达 85.9%），BF 提示的期望完工时间与最优调度之比趋近于 1+2p(ρ−1)+O(N/M)1 + 2p(\rho-1) + O(N/M)，即只要瓶颈假设稍微偏离，性能下降也在可控范围内。这也解释了为何简单的 BF 提示能在多数负载下表现良好。

实验评估与应用效果

RRFP 基于 Megatron-LM 实现，在高达 128 个 GPU 的规模上进行了全面评测。实验覆盖 GPT3-Large、Qwen3+ViT 等多个语言和多模态模型，以及多种并行配置。

  • 端到端加速：与固定顺序 1F1B 相比，使用 BF 提示的 RRFP 在语言模型上最高加速 1.77 倍，在多模态模型上最高加速 2.77 倍；若加入 ZeroBubble 风格的后向-权重更新分解作为提示（RRFP+BFW），增益进一步提升。在大规模设置（32～128 GPU）中，加速比始终保持在 1.25×～2.77×之间。
  • 运行时瓶颈分析：将每次迭代时间拆分为计算、阻塞等待和 TP 协调开销，发现 1F1B 的阻塞等待占比高达 65%～67%，而 RRFP 大幅消减了这一部分，将大部分时间归还给有效计算。
  • 与外部系统对比：RRFP 默认配置在可比较的设置下优于 DeepSpeed 和专门的多模态训练系统 Cornstarch，最高取得 1.84 倍加速，且保持训练损失曲线一致，验证了正确性。
  • 鲁棒性：在注入计算抖动的压力测试下，RRFP 的性能衰减明显慢于 1F1B，标准差也更小，展现出对运行时变异的强大免疫力。
  • 扩展性：增益随着流水线深度、批次大小和模态不平衡度的增加而增大，说明当固定顺序更容易“过时”且备选就绪任务更多时，就绪驱动策略的优势更显著。

实践应用建议与未来方向

对于计划将 RRFP 引入自身训练框架的工程师，有几点值得注意。首先，RRFP 作为运行时层可以无缝叠加在现有代码之上，无需修改模型定义。建议遵循以下步骤：将通信后端改造为消息驱动模型，添加就绪缓冲区和仲裁循环；对于 TP 场景，引入标量 All-Gather 协调。缓冲区大小限制的敏感度实验表明，一个适中的值（如 32）即可释放大部分就绪驱动的增益，无需过度扩张内存。提示顺序可采用默认的 BF，其性能接近最优，且对方向偏好的轻度变化不敏感；但应当避免“前向优先”这类会延迟后向执行造成新的气泡的顺序。

未来工作可沿着几个方向展开。一是将 RRFP 的就绪集仲裁打造为一个通用的微调度框架，允许动态生成或被强化学习驱动的智能体实时调整提示顺序。二是将消息驱动通信和缓冲区管理扩展到更复杂的 3D 混合并行（流水线+张量并行+数据并行），并与梯度累积、优化器步骤的异步化深度结合。三是研究在模型架构或输入序列长度严重异构时，如何利用就绪驱动原生支持异构硬件或细粒度的负载均衡。

总结

RRFP 通过将流水线并行执行的约束从“固定顺序”转变为“就绪优先”，成功化解了运行时变异性对大型训练任务的负面影响。其核心洞察在于将调度计划降级为灵活的提示，使得数十年积累的调度优化技术依然可用，但不再成为运行时的紧箍咒。三个协调机制在保证训练正确性的前提下实现了极低开销的乱序执行。该系统不仅在多种工作负载和规模上显著提升了训练吞吐，更开辟了一个将调度策略与运行时解耦的新设计范式，对构建下一代的弹性大规模训练系统具有深远的参考价值。