运行时可变性条件下流水线并行训练的就绪驱动运行时

论文信息

标题: 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

3 分钟速览

• 研究问题：现代分布式训练中，计算和通信延迟存在不可预测的运行时波动，导致预先制定好的流水线并行调度计划在实际执行时变得过时，流水线各阶段被迫等待尚未就绪的任务，产生大量空闲气泡和利用率下降。
• 核心方法：提出就绪驱动运行时 RRFP，将预定义的流水线调度计划从强制执行顺序降级为非绑定的提示排序，每个阶段根据任务实际就绪状态动态选择可执行工作，通过消息驱动的异步通信、轻量张量并行协调和就绪集仲裁三个机制保证正确性和低开销。
• 关键结果：在语言和多模态工作负载下，RRFP 相比固定顺序的 1F1B 基线最高获得 1.77 倍（语言）和 2.77 倍（多模态）加速（见论文表 1、表 2）。
• 主要局限：张量并行场景下需引入轻量协调开销（<1%），且性能增益依赖实际就绪状态的多样性，当所有任务几乎同时就绪时，就绪驱动策略的优势会减弱（论文第 7.4 节）。
• 适合读者：从事大模型分布式训练系统开发、流水线并行调度优化、或关注训练效率提升的工程师和研究人员。

论文背景和研究动机

流水线并行是扩展大模型训练的核心技术之一，通过将模型划分到多个设备上，不同微批次在不同阶段上并发执行，提高硬件利用率。现有工作从离线评估和在线自适应两个方向优化调度，但最终系统均将这些调度方案当作运行时必须遵守的执行序列：即使实际就绪状态已经变化，各阶段仍需等待计划中的下一个任务到来。

现代分布式训练呈现显著的运行时变异特性，即使模型、输入数据和硬件配置完全固定，单次运行的微批次计算和通信延迟依然存在不可预测的波动。论文通过重复 300 次相同训练过程并追踪固定样本的延迟分布（见论文图 2），发现计算延迟的归一化 p95–p5 波动幅度达 0.73，通信延迟的对应值高达 58.74。这意味着预定义的执行顺序随时可能与实际就绪状态背离：计划中优先级更高的任务尚未就绪，而其他可执行的工作却被空置。

这一问题的本质不在于某个特定的调度策略不够好，而在于流水线系统将调度计划固化为进度的先决条件。一旦计划与实际就绪集出现短暂不匹配，局部等待就会通过流水线依赖关系逐级放大，形成阶段失准和空闲气泡。

核心方法和技术细节

RRFP 的核心设计原则是就绪优先：每个流水线阶段持续评估当前可执行的就绪任务集合，仅使用调度计划对这些就绪候选进行排序，如果计划中排在最前面的任务未就绪，则跳过它直接调度另一个就绪任务，而非阻塞等待。这一设计面临三个关键技术挑战。

消息驱动的异步通信。 传统流水线通信假设发送方和接收方按相同微批次顺序进行数据交换。就绪驱动执行允许相邻阶段以不同顺序处理微批次，可能导致通信失配甚至死锁。RRFP 将数据传输与计算循环完全解耦：独立的发送和接收线程异步搬运张量，每个张量携带微批次标识符和方向信息，接收端根据标识符将乱序到达的数据路由到对应微批次的就绪缓冲区。前向任务在收到上一阶段的激活后标记为就绪，反向任务需同时满足本地前向完成和下一阶段梯度到达两个条件。这种消息驱动模型使得通信进度不受计算顺序分歧的影响（见论文第 4.1 节）。

张量并行协调。 在张量并行场景下，同一张量并行组内的各个 rank 必须按相同微批次顺序调用集合通信原语，否则会导致错误结果或死锁。RRFP 采用轻量协调协议：在执行可能触发集合通信的计算前，各 rank 先提出自己选择的就绪微批次，组内通过标量 all-gather 交换这些标识符。若所有 rank 选择一致，则直接执行；否则推迟该任务等待就绪状态变化。这一机制的协调开销极低，在 TP=4 时仅占单次迭代时间的 0.77%（见论文表 3）。

就绪集仲裁。 当计算线程空闲时，RRFP 扫描提示顺序并调度第一个在当前就绪缓冲区中存在的微批次任务。提示顺序可以来自静态调度、离线评估或在线自适应算法，RRFP 不作限制。论文实例化了一种轻量的 Backward-Forward（BF）提示：每轮仲裁优先考虑反向就绪任务，其次考虑前向就绪任务；同方向内根据流水线依赖关系排序。通过控制缓冲区大小上限并施加反压策略（前向计算领先反向计算超过阈值时暂停前向分发），RRFP 在调度灵活性与内存增长之间取得平衡（见论文第 5 节和附录 C）。

创新点和贡献

本工作做出了三个层面上的贡献。

在概念层面，论文识别并形式化了流水线并行中一个被忽视的根本问题：不是某个调度策略不够好，而是系统将调度计划固化为强制执行顺序的方式本身就脆弱。RRFP 将调度的角色从 “必须遵守的顺序” 降级为 “对就绪候选的排序提示”，这一定位转变使得调度质量和运行进度被解耦，任何现有调度算法都可以作为非绑定提示融入就绪驱动的执行框架。

在机制层面，三项运行时技术协同工作以支持安全的乱序执行。消息驱动通信消除了通信阶段的顺序假设；张量并行协调以亚百分比的代价保证了集合通信一致性；就绪集仲裁在执行效率和调度质量之间建立了简洁的权衡接口。

在系统层面，RRFP 扩展 Megatron-LM 作为可配置的运行时层，无需修改模型定义或训练流程，兼容现有调度算法和混合并行配置（张量并行 + 流水线并行 + 数据并行）。这使得就绪驱动执行可以渐进式部署到现有训练框架中。

实验结果分析

论文在最多 128 块 GPU 上，对语言和多模态工作负载进行了全面评估。

端到端性能（RQ1）。 在 12 个代表性配置中，RRFP 相比 1F1B 实现 1.21–2.24 倍加速，相比 ZeroBubble 也普遍更优。多模态工作负载的增益大于纯语言负载，因为视觉编码器和语言骨干之间的异构计算加剧了运行时波动，固定顺序更容易失效。在 32–128 GPU 的大规模部署中，加速比依然维持在 1.37–2.77 倍（见论文表 1、表 2）。

运行时分解（RQ2）。 对 Qwen3-4B + ViT-Big 的迭代时间分解显示，1F1B 的阻塞等待占迭代时间的 64–66%，远超过实际计算时间。RRFP 通过就绪驱动消除了大量阻塞，使其降至 43–45%，同时计算时间基本持平，张量并行协调开销仅占 0.55–0.77%（见论文表 3）。这表明加速完全来源于利用就绪驱动回收了原本浪费的空间时间。

跨框架对比（RQ3）。 在相同配置下，RRFP 的默认 BF 配置在 12 个代表性设置和 8 个大规模设置上均优于 DeepSpeed 和 Cornstarch，较较快的外部基线最高加速 1.84 倍（见论文表 4、表 5）。

鲁棒性与敏感性（RQ4、RQ5）。 在注入计算路径抖动（随机 CUDA 延迟）的实验下，RRFP 的迭代时间标准差为 0.19–0.23s，远低于 1F1B 的 0.33–0.41s，且随抖动增强退化更慢（见论文表 6）。在提示顺序敏感性测试中，BF、FB 和 B-priority 的差距不到 1%，说明性能增益主要来自就绪驱动而非特定的启发式规则（见论文表 7）。

缩放行为（RQ6）。 随流水线深度增加、视觉编码器增大或全局批尺寸增长，RRFP 相对 1F1B 的加速比均呈上升趋势（见论文表 8），印证了就绪驱动在更大搜索空间和更多样化就绪状态下具有更强的适应性。

实践建议

RRFP 的就绪驱动设计对现有大模型训练系统的改进具有直接的工程落地路径。

第一，团队可在现有 Megatron-LM 风格的训练框架上以运行时层的方式集成 RRFP，无需修改模型定义或训练流程。缓冲区大小限制建议设为 32，该值在论文的灵敏度分析和所有实验中被证实足够暴露就绪驱动的收益，同时控制内存增长。

第二，在部署时无需对现有调度算法进行大幅改造。RRFP 的仲裁接口接受任意提示顺序，团队可继续使用已有的 1F1B、ZeroBubble 或自适应调度方案作为提示，由 RRFP 负责就绪过滤和乱序执行。如果需要最大化性能，可引入 ZeroBubble 的反向/权重更新分解，形成 BFW 提示，在语言和多模态负载上均已验证较 BF 提示有额外增益（见论文表 1、表 2）。

第三，RRFP 在以下场景中收益最显著：多模态训练（语言 + 视觉编码器计算异构）、较深的流水线（PP≥16）、大全局批尺寸（≥128），以及存在明显计算/通信抖动的集群环境。部署优先级可按这些条件排序。

第四，张量并行配置下需计入协调开销（TP=4 时 <1%），但总体性价比仍远优于固定顺序方案。建议 TP 较大时先在小规模上验证协调开销的可接受性。