ThunderSyncRL: Lossless Acceleration of Agentic Reinforcement Learning

发表时间: 2026-10 · arXiv:2610.05935 (Stanford / Yonsei / Korea University / Bespoke Labs)

原文: https://arxiv.org/abs/2610.05935

作者/机构:Seil Kang, Hangoo Kang, Tarun Suresh, Youngeun Kim, Shreyas Pimpalgaonkar, Seong Jae Hwang, Azalia Mirhoseini(斯坦福大学、延世大学、高丽大学、Bespoke Labs)

速读

一句话结论 ThunderSyncRL 提出了一种梯度流调度框架,在保证零策略延迟且数学更新完全等价的前提下,将智能体强化学习(如 GRPO 和 OPD)的训练速度提升了最高 1.9 倍,并在同等算力预算下实现了更优的任务成功率。

要解决什么问题 现在的语言模型在做智能体强化学习时,生成的交互轨迹非常长且耗时参差不齐,具有极端的长尾效应,最慢的 10% 轨迹可能会占掉一半的生成时间。传统的同步训练(Sync)存在严重的流水线气泡,必须等整个批次的所有轨迹和奖励都生成完,学习器才能开始计算梯度,导致 GPU 有将近一半的时间在空转等待,而生成阶段本身就占了总训练时间的 70% 到 90%。为了消除这种空转,现有的异步训练(Async)让生成和学习跨步重叠,但代价是引入了策略延迟,即使用旧策略采样的数据来更新当前模型。这种延迟不仅会损害最终的训练效果,通常还需要引入重要性采样权重、数据过滤或裁剪等复杂的算法修正机制。这就产生了一个核心卡点:如何在不牺牲策略新鲜度、不改变原有优化目标的情况下,把学习器等待长尾轨迹的空转时间充分利用起来。

怎么做的 核心思路是打破“必须等整个批次齐了才能算梯度”的粗粒度执行屏障,只要某段数据的客观数学依赖满足了,就立刻启动后向传播,这被称为梯度流。关键设计由针对不同算法的流式拆解和统一的同步优化器屏障构成。对于组相对策略优化(GRPO),原本计算优势值需要等同组 $m$ 条轨迹的奖励全部返回,才能求出均值 $\mu_{\mathcal{G}}$ 和标准差 $\sigma_{\mathcal{G}}$。ThunderSyncRL 绕开了这个等待,只要单条轨迹 $i$ 的奖励 $r_i$ 到了,就立刻计算其得分梯度 $H_i = \nabla_{\boldsymbol{\theta}} S_i(\boldsymbol{\theta})|_{\boldsymbol{\theta}=\boldsymbol{\theta}_k}$,并在内存中维护两个累加和:$G_{\mathcal{G}}^{(1)} = \sum_{i \in \mathcal{G}} r_i H_i$ 与 $G_{\mathcal{G}}^{(2)} = \sum_{i \in \mathcal{G}} H_i$。等全组跑完,直接按公式合并得出精确的组梯度:

$$ g_{\mathcal{G}} = \frac{1}{m} \frac{G_{\mathcal{G}}^{(1)} - \mu_{\mathcal{G}} G_{\mathcal{G}}^{(2)}}{\sigma_{\mathcal{G}} + \epsilon} $$

这样就把原本只能在最后串行算的梯度,拆解并重叠到了漫长的生成等待期中。对于同策略蒸馏(OPD),只要冻结的教师模型对当前轮次的动作给出了评分,系统就立刻释放该轮次学生模型的局部后向传播,使其与后续的工具调用和环境执行完全并行。所有就绪的计算任务会进入一个工作队列按序执行。当整个批次的所有轨迹都结束、所有局部梯度都累加完毕后,系统才会统一执行一次分布式规约,进行全局裁剪,并让优化器走且仅走一步,最后将新权重广播给所有生成端。这种“异步执行、同步更新”的机制,既榨干了硬件的空转时间,又保证了所有轨迹都在同一个策略快照下优化,实现了数学上的无损加速。

效果如何 实验在 SWE-bench Verified(软件工程任务)和 Terminal Bench 4.0(终端任务)上进行,使用了 Qwen-3.8-27B 和 GLM-4.7-Flash-31B 模型,硬件环境为 8 张 NVIDIA B200 或 H200 GPU,训练设置包含每步 256 条轨迹(GRPO)或 128 条轨迹(OPD),单轨迹最高 300 个交互轮次。对比基线包括三个:代表零延迟但有大量空转的 Sync(同步)、代表允许落后一步更新的 Async(异步),以及代表允许轨迹在飞行中途被更新的 Fully Async(完全异步)。量化结果显示,在达到相同的 pass@3 目标分数时,ThunderSyncRL 的耗时比 Sync 快了 1.6 到 1.9 倍,当生成和学习耗时接近平衡时,其加速比逼近理论上限的 2 倍。在固定的 128 个 GPU 小时预算下,由于每步耗时更短且没有策略延迟的负面影响,ThunderSyncRL 的 pass@3 成绩全面超越了 Async,最高领先 2.47 个百分点,同时在 H200 上实现了高达 51.0% 的训练器活跃 MFU。作者也坦承了该方法的局限与代价:为了让梯度提前计算并挂起等待合并,学习器需要保留部分梯度状态和累加器,这导致其峰值显存占用略高于同步基线,例如在 Qwen 的 GRPO 设置下,单卡显存峰值从 117.0 GB 增加到了 122.8 GB,本质上是用少量的显存空间换取了大幅的墙上时间加速。

主要贡献

当前语言模型正从单纯生成答案向在交互式环境中追求长视野(long-horizon)目标迈进。对这些智能体进行后训练需要冗长且异构的交互轨迹。传统的同步系统(Synchronous systems)在等待 rollout(轨迹生成)和验证完成期间,会导致学习器(learner)引擎处于闲置状态,产生严重的流水线气泡(pipeline bubbles)。为了消除这些气泡,现有的异步训练(asynchronous training)通过在不同更新之间重叠 rollout 和学习过程来提高效率,但这不可避免地带来了策略滞后(policy staleness)问题。

针对这一困境,本文提出了 ThunderSyncRL 框架。其核心目标是在实现零策略滞后的前提下,通过依赖感知调度来消除流水线气泡。本文的主要创新点和贡献如下:

  • 提出 ThunderSyncRL 与梯度流式处理框架:该框架能够在保持同步优化器步骤和零策略滞后的同时,将 rollout 与学习器计算过程进行重叠。学习器计算在所有必需的输入固定后立即开始。
  • 推导了 GRPO 和回合级 OPD 的精确梯度归约:

    • 对于组相对策略优化(GRPO),ThunderSyncRL 在每条轨迹的奖励到达时立即计算该轨迹的分数梯度,而无需等待整个组完成。
    • 对于同策略蒸馏(OPD),当工具调用在沙盒中运行时,它会为每个已完成的智能体回合(turn)中由教师模型打分的动作计算梯度。
    • 作者在数学上证明了,这种梯度流式处理产生的 GRPO 和 OPD 更新与批次同步训练完全相同,且未改变任何优化目标。
  • 显著的训练加速与性能提升:在 SWE-bench Verified 和 Terminal Bench 4.0 基准测试中,ThunderSyncRL 在 GRPO 和 OPD 下训练模型达到相同性能指标的速度比同步训练快高达 1.9 倍。此外,在 128 GPU 小时的固定计算预算下,凭借其零滞后调度,ThunderSyncRL 的 pass@3 表现超越了允许陈旧 rollout 的异步训练方法最高达 2.47 个百分点。

图 1:在 GRPO(左侧两图)和 OPD(右侧两图)下,ThunderSyncRL 在降低高达 1.9 倍训练成本的同时,达到了与 Sync 相同的 SWE-bench Verified pass@3。在 128 GPU 小时的预算下,其零滞后调度相比于允许陈旧 rollout 的 Async 和 Fully Async,将 pass@3 提升了最高 2.47 个百分点。
图 1:在 GRPO(左侧两图)和 OPD(右侧两图)下,ThunderSyncRL 在降低高达 1.9 倍训练成本的同时,达到了与 Sync 相同的 SWE-bench Verified pass@3。在 128 GPU 小时的预算下,其零滞后调度相比于允许陈旧 rollout 的 Async 和 Fully Async,将 pass@3 提升了最高 2.47 个百分点。

背景知识与问题定义

智能体强化学习中的流水线气泡问题 语言模型越来越多地被训练为智能体,在交互式环境中进行长视野决策,通过推理和使用工具来响应反馈。从环境或验证器反馈中进行强化学习(RL)已成为改善这种行为的有效途径。然而,训练这些智能体需要生成成本高昂且持续时间异构的交互轨迹,这些轨迹的完成时间具有长尾分布特性。在批次同步(batch-synchronous)的强化学习中,学习器引擎必须保持空闲,直到 rollout 引擎完成整个批次的生成并且所有奖励都到达。作者发现,在同步的 GRPO 和 OPD 训练中,学习器 GPU 在等待 rollout 和验证的过程中,有 49.5% 的步骤时间处于闲置状态。最慢的 10% 的 rollout 请求可能占据一半的 rollout 时间,而 rollout 本身占据了 70% 到 90% 以上的训练时间。
图 3:同步智能体强化学习中的流水线气泡。SWE-smith 上的 GRPO 训练期间的 GPU 利用率,坐标轴上方为 4 个 rollout GPU,下方为 4 个学习器 GPU。随着长尾轨迹的完成,rollout 利用率(生成槽的繁忙份额)下降。阴影条带标记了空闲时间。Sync 学习器在每个步骤中有 49.5% 的时间等待最后一个奖励,而 rollout GPU 在学习器训练时等待。ThunderSyncRL 在每条轨迹的奖励到达时开始其反向传播,并在 Sync 需要 8 个步骤的 GPU 小时内完成了 15 个优化器步骤。

现有系统的权衡与局限 现有系统通过在不同更新之间重叠计算和协调资源分配来减少这些流水线气泡。异步执行(Asynchronous execution)将 rollout 和学习跨更新进行重叠,但这会导致部分轨迹来自于旧策略。这种策略滞后(policy staleness)通常需要额外的算法机制来弥补,例如重要性加权的离策略校正、过滤、裁剪或显式的滞后控制【ESM+18,IMPALA: Scalable Distributed Deep-RL with Importance Weighted Actor-Learner Architectures + 2018 + ICML】、【FGS+25,Areal: A large-scale asynchronous reinforcement learning system for language reasoning + 2025 + NeurIPS】。同策略(On-policy)流水线在固定的 rollout 内重叠执行,但基于完整组的调度仍然会延迟轨迹局部的反向传播,直到所有组奖励到达。作者认为,流水线重叠与零滞后之间表面上的权衡是人为造成的,它源于粗粒度的执行屏障。

组相对策略优化(GRPO)基础 给定一个提示(prompt),GRPO 采样一组轨迹,并在该组内对其奖励进行归一化,以获得相对优势(relative advantages)。策略更新通过其分离的(detached)优势来对每条轨迹的打分动作 token 的对数概率进行加权。

同策略蒸馏(OPD)基础 OPD 使用学生策略生成轨迹,并在冻结的教师模型下评估学生的动作 token。由此产生的 token 级监督信号为每个智能体回合(turn)的动作 token 定义了蒸馏损失。

目标源与释放语义的定义 考虑在策略 $\pi_{\theta_k}$ 下的第 $k$ 次更新以及逻辑 rollout 批次 $B_k$。每条轨迹是一系列智能体回合,其中一个回合包含策略生成的动作以及由此产生的环境或工具观察结果。我们将学习器计算中可独立释放的单元称为目标源(objective source)。当源 $j$ 的所有输入都固定后,它在时间 $\tau_j$ 变为就绪(ready)状态。就绪单元取决于训练目标。对于包含 $m$ 条轨迹的 GRPO 组 $\mathcal{G}$,源 $i$ 与轨迹 $i$ 相关联,并在其 token 序列、打分 token 掩码和奖励 $r_i$ 固定时变为就绪状态。在所有 $m$ 个奖励到达之前,组统计信息仍然不可用。在 OPD 中,每个回合的打分动作 token 构成一个源。一旦这些 token 及其掩码固定,冻结的教师模型就可以使用它们已实现的因果上下文对其进行打分。教师分数会释放相应的学生反向传播,这允许与工具执行和后续回合重叠。

调度目标 系统面临的问题是如何在其客观依赖关系满足的最早时间释放每个源,同时保留相应的批次同步更新语义。第 $k$ 次更新中的所有轨迹都是从 $\pi_{\theta_k}$ 中采样的,并且所有梯度都在固定参数 $\theta_k$ 处进行评估。在逻辑批次关闭并且所有梯度工作完成后,优化器采取一个步骤来产生 $\theta_{k+1}$。逻辑批次和目标保持不变;只有符合条件的学习器工作的时间安排有所不同。

图 2:GRPO (a) 和 OPD (b) 的调度示意图。Sync 等待完整的批次;Async 重叠相邻的批次,具有一步滞后;Fully Async 在轨迹仍在飞行中时更新 rollout 权重。ThunderSyncRL 流式处理就绪的梯度,具有一个批次同步优化器步骤和零滞后。
图 2:GRPO (a) 和 OPD (b) 的调度示意图。Sync 等待完整的批次;Async 重叠相邻的批次,具有一步滞后;Fully Async 在轨迹仍在飞行中时更新 rollout 权重。ThunderSyncRL 流式处理就绪的梯度,具有一个批次同步优化器步骤和零滞后。

方法细节

释放规则与基于就绪状态的调度 ThunderSyncRL 在每个源的就绪时间 $\tau_j$ 释放其学习器计算任务,这个时间可以早于其所在组或批次的完成时间;梯度在参数 $\theta_k$ 处累积。就绪的源按照就绪顺序进入一个工作守恒队列;准入机制绝不会为了等待较小的轨迹索引而阻塞,也不会为了低于每个 rank 上限的无关组而阻塞。独立的组可以并发归约,而每个组保留确定性的归约顺序。作者将轨迹或组关闭时的延迟梯度传播作为具有自身释放时间的学习器工作。按照服务顺序对 $n$ 个学习器工作项进行索引;设 $\tau_j$ 和 $p_j$ 分别表示工作项 $j$ 的释放时间和服务时间。在一个初始完成时间 $c_0 = 0$ 的单一学习器通道上,完成时间满足公式 $c_j = \max\{\tau_j, c_{j-1}\} + p_j$。设 $R_k$ 为完整的 rollout 批次关闭的时间,$P_k$ 为共同的最终归约、优化器和发布后缀的时间。更新的终点时间为 $T_k = \max\{R_k, c_n\} + P_k$。批次同步方法将所有学习器工作推迟到 $R_k$。对于 GRPO,组就绪流水线在其最终奖励到达时释放组内的所有源。ThunderSyncRL 根据任一目标的每个源的就绪时间,将符合条件的学习器工作移入 rollout 间隔中,从而减少了最后一条轨迹之后的学习器尾部时间。

零滞后优化器屏障 ThunderSyncRL 会严格等待每一个注册的轨迹和组关闭,并等待所有延迟的梯度传播完成。随后,分布式归约和特定目标的归一化将产生批次更新方向 $g_k$。ThunderSyncRL 对该方向进行裁剪,并精确地应用一次优化器步骤,公式为 $\theta_{k+1} = \mathrm{Opt}\left(\theta_k, \mathrm{clip}(g_k)\right)$。随后,ThunderSyncRL 将生成的适配器或策略参数发布给 rollout 副本。每个副本加载新版本,清除依赖于策略的状态,并在下一次更新开始之前确认其正在服务 $\theta_{k+1}$。因此,第 $k$ 次更新内的每个 rollout 和学习器源都绑定到 $\theta_k$,没有任何轨迹会针对其在飞行过程中发生改变的策略进行优化。

流式处理 GRPO 梯度 流式处理 GRPO 梯度的主要障碍在于,一条轨迹的优势(advantage)取决于其整个组的奖励。设 $\mathcal{G}$ 为包含 $m$ 条轨迹的组。对于轨迹 $i \in \mathcal{G}$,定义其掩码策略分数和相应的源梯度为 $S_i(\theta) = \sum_{t \in \mathcal{M}_i} w_{i,t} \log \pi_{\theta}(a_{i,t} \mid h_{i,t})$ 以及 $H_i = \nabla_{\theta} S_i(\theta) |_{\theta = \theta_k}$,其中 $\mathcal{M}_i$ 是打分的动作 token 集合,$w_{i,t}$ 是 token 权重,$r_i$ 是轨迹奖励。组奖励均值和标准差定义为 $\mu_{\mathcal{G}} = \frac{1}{m} \sum_{i \in \mathcal{G}} r_i$ 以及 $\sigma_{\mathcal{G}} = \sqrt{\frac{1}{m} \sum_{i \in \mathcal{G}} \left(r_i - \mu_{\mathcal{G}}\right)^2}$。在微分期间保持组归一化优势恒定的情况下,组更新方向为 $g_{\mathcal{G}} = \frac{1}{m} \sum_{i \in \mathcal{G}} \frac{r_i - \mu_{\mathcal{G}}}{\sigma_{\mathcal{G}} + \epsilon} H_i$。尽管计算 $\mu_{\mathcal{G}}$ 和 $\sigma_{\mathcal{G}}$ 需要等待组完成,但该梯度可以精确分解为 $g_{\mathcal{G}} = \frac{1}{m} \frac{G_{\mathcal{G}}^{(1)} - \mu_{\mathcal{G}} G_{\mathcal{G}}^{(2)}}{\sigma_{\mathcal{G}} + \epsilon}$,其中 $G_{\mathcal{G}}^{(1)} = \sum_{i \in \mathcal{G}} r_i H_i$ 且 $G_{\mathcal{G}}^{(2)} = \sum_{i \in \mathcal{G}} H_i$。ThunderSyncRL 在轨迹 $i$ 变为就绪状态时立即计算 $H_i$,并增量累加 $G_{\mathcal{G}}^{(1)}$ 和 $G_{\mathcal{G}}^{(2)}$。当组内所有奖励和源梯度都可用时,即可计算出组方向 $g_{\mathcal{G}}$。将所有组方向相加得到优化器屏障的批次方向 $g_k = \sum_{\mathcal{G} \subset B_k} g_{\mathcal{G}}$。这种设计保留了批次屏障更新的数学等价性,同时允许轨迹反向传播在组完成之前开始。

流式处理 OPD 梯度 在 OPD 中,一旦冻结的教师模型对每个回合(turn)的动作 token 进行了打分,该回合就会提供一个梯度源。设 $\mathcal{U}_k$ 为批次 $B_k$ 中的回合集合,设 $\mathcal{M}_j$ 包含回合 $j$ 的打分动作 token。OPD 更新通过批次中打分 token 的总数进行归一化。定义分离的 token 优势和该回合未归一化的更新方向为 $A_{j,t} = \mathrm{sg}\left[\log \pi_{\mathrm{T}}(a_{j,t} \mid h_{j,t}) - \log \pi_{\theta_k}(a_{j,t} \mid h_{j,t})\right]$ 以及 $g_j = \sum_{t \in \mathcal{M}_j} A_{j,t} \ \nabla_{\theta} \log \pi_{\theta}(a_{j,t} \mid h_{j,t}) \big|_{\theta = \theta_k}$,其中 $\pi_{\mathrm{T}}$ 是冻结的教师模型,sg 表示停止梯度(stop-gradient)。每个优势仅取决于采样的 token、其实现的因果上下文以及固定的学生和教师策略。ThunderSyncRL 在教师分数可用时立即释放回合局部的反向传播,允许学习器计算与工具执行和后续回合重叠。它累积未归一化的梯度贡献,并在最终归约之前通过早期上下文完成任何延迟的梯度传播。批次更新方向为 $g_k = \frac{1}{N_k} \sum_{j \in \mathcal{U}_k} g_j$,其中总 token 数 $N_k = \sum_{j \in \mathcal{U}_k} |\mathcal{M}_j|$。总打分 token 计数 $N_k$ 仅在逻辑批次关闭时固定,因此 ThunderSyncRL 在回合级反向传播进行时推迟这种标量归一化。在裁剪和单一优化器步骤之前,将累积的梯度除以 $N_k$,可提供与批次同步 OPD 相同的数学更新,并且每个 rollout 和学习器计算都绑定到 $\theta_k$。

实验环境

  • 数据集:

    • SWE-smith:用于软件工程任务后训练,包含 50,908 个 Python 仓库修复任务。
    • SETA-Env:用于终端任务后训练,包含 4,567 个综合终端任务。
    • 评估基准:SWE-bench Verified(500 个任务)和 Terminal Bench 4.0(66 个任务)。评估任务严格从训练集中排除。
  • 模型架构与参数:

    • Qwen-3.8-27B:用于全参数微调和 LoRA 配置。OPD 教师模型使用 Qwen/Qwen3.8-Flash-Next-FP8。
    • GLM-4.7-Flash-31B:用于对比评估,激活约 3B 参数。OPD 教师模型使用 zai-org/GLM-5.3-Flash。
  • 硬件配置:

    • 参考配置:单节点 8 张 NVIDIA B200 GPUs。
    • 对比配置:单节点 8 张 NVIDIA H200 GPUs。
    • 角色分配:对于 GRPO,4 张 GPU 用于学习器,4 张用于 rollout;对于 OPD,4 张用于学习器,2 张用于 rollout,2 张用于教师模型打分。
  • 软件与代码配置:

    • 代码实现基于 vLLM(用于 rollout)、verl(用于 GRPO 同步/异步基线)和 SkyRL(用于 OPD 同步/异步基线)。
    • 启用 vLLM 的 chunked prefill 和 prefix caching,禁用投机解码。
    • 优化器使用 AdamW,学习率 $10^{-6}$,全局梯度裁剪阈值 1.0。

实验结果

学习效率与智能体性能

  • 实验内容:在 SWE-bench Verified 和 Terminal Bench 4.0 上,对比 ThunderSyncRL 与 Sync 到达相同 pass@3 目标所需的 GPU 小时数。
  • 实验结果:ThunderSyncRL 在 SWE-bench Verified 上达到目标 pass@3(GRPO 74.01%,OPD 74.54%)的速度比 Sync 快 1.9 倍。在 Terminal Bench 4.0 上,GRPO 下快 1.8 倍,OPD 下快 1.9 倍(见图 5 左侧和图 6)。
  • 分析结论:通过将学习器工作与 rollout 重叠,ThunderSyncRL 大幅缩短了步骤挂钟时间(图 4 显示步骤时间缩短了 1.91 倍至 1.94 倍),从而在相同的 GPU 小时内处理了更多的轨迹批次,显著降低了训练成本。
    图 4:GRPO 和 OPD 的步骤挂钟时间(左)和训练器活动 MFU(右)。
    图 5:左图:达到匹配的 pass@3 的时间。右图:在 128 GPU 小时下,Async 和 Fully Async 相对于 ThunderSyncRL 的表现。
    图 6:Terminal Bench 4.0 的 pass@3 随训练成本的变化,以及平均训练奖励随 GPU 小时的变化。箭头标记了 ThunderSyncRL 达到 Sync 检查点分数的点;标签给出了成本比率。

固定训练预算下的性能对比

  • 实验内容:在 128 GPU 小时(8-GPU 节点上 16 小时)的固定预算下,对比 ThunderSyncRL 与 Async/Fully Async 的 pass@3 性能。
  • 实验结果:在 SWE-bench Verified 上,ThunderSyncRL 领先 Async 2.47(GRPO)和 1.27(OPD)个百分点。在 Terminal Bench 4.0 上,领先 1.52(GRPO)和 2.02(OPD)个百分点(见图 5 右侧)。
  • 分析结论:由于 Async 引入了一步的策略滞后,而 Fully Async 引入了可变的策略滞后,ThunderSyncRL 凭借其零滞后特性在相同的计算预算下取得了更高的最终性能。

跨模型与硬件的效率(Trainer Active MFU)

  • 实验内容:在 B200 和 H200 GPU 上,分别测试 Qwen-3.8-27B 和 GLM-4.7-Flash-31B 模型的 Trainer active MFU(训练器活动模型触发率)和显存峰值。
  • 实验结果:在 B200 上,Qwen 模型下 ThunderSyncRL 相比 Sync 加速 1.91x (GRPO) 和 1.94x (OPD);GLM 模型由于激活参数少,rollout 成为瓶颈,加速比为 1.64x 和 1.63x。在 H200 上,Qwen 负载变为学习器受限,加速比为 1.63x 和 1.67x。ThunderSyncRL 的 MFU 在所有配置中均最高(B200 Qwen GRPO 达到 45.9%)。显存峰值略高于 Sync(Qwen GRPO 为 122.8 GB vs 117.0 GB)。
  • 分析结论:加速比高度依赖于硬件上 rollout 和学习器阶段的平衡状态。ThunderSyncRL 有效回收了空闲时间,提高了 MFU,代价是由于需要暂存梯度状态而略微增加了主机和 GPU 内存的峰值使用量。

工作负载扩展与重叠效率

  • 实验内容:通过改变 rollout 与学习时间的比率、轨迹异构性、批次大小和轨迹长度,分析 ThunderSyncRL 的加速极限。
  • 实验结果:当阶段时间相等(平衡)且后缀开销可忽略时,理论加速比逼近 2 倍。随着轨迹持续时间离散度(异构性)的增加,GRPO 的加速比从 1.58x 提升到 1.95x。随着批次大小增加,学习器尾部时间占比减小,加速比进一步逼近 2x(见图 7、图 8)。
  • 分析结论:ThunderSyncRL 的就绪驱动调度机制能够完美适应异构的长尾轨迹,在不同负载规模下均能提供高度精确和稳定的加速效果。
    图 7:(a) 测量步骤的加速比和训练器活动 MFU 与轨迹持续时间离散度的关系,附带最小二乘拟合。(b) 在 $T_{\mathrm{rollout}} / T_{\mathrm{train}} = 1$ 时的预测加速比。
    图 8:相对于 Sync 的加速比。等高线显示了跨批次大小(上)和视野(下)的分析预测。散点图汇总了两次扫描,并将此预测与来自测量释放迹线的预测(空心圆)以及测量的挂钟加速比(实心圆)进行对比。

结论

本文提出了 ThunderSyncRL 框架,它能够在零离策略滞后(zero off-policy staleness)的条件下实现 rollout 与学习过程的重叠。该框架在固定的策略快照下流式处理就绪的梯度,并在批次关闭后执行一次优化器步骤,从而完美保留了同步 GRPO 和 OPD 的更新语义。通过利用梯度充分统计量,GRPO 的反向传播能够在所有组奖励到达之前开始;而通过利用教师打分的回合,OPD 的学习过程可以在工具执行期间进行。当 rollout 和学习器工作达到平衡,且学习器尾部及更新开销可忽略时,步骤挂钟时间的加速比可逼近 2 倍。在不改变优化目标的前提下,ThunderSyncRL 成功回收了学习器的闲置时间,缩短了前沿规模智能体训练的研究循环,使得相同的计算资源能够回答更多的研究问题。未来工作可自然扩展至多节点训练以及更广泛的智能体工作负载。

附录

附录 A:局限性与进一步讨论

设计的适用性与局限性 ThunderSyncRL 建立在一个核心前提之上:学习器工作应当在目标依赖关系允许的尽早时间开始。因此,它能节省多少时间,既取决于调度器,也同样取决于工作负载本身。相比于等待组级别信号的目标,那些梯度输入较早解析的目标(例如回合级 OPD)能够留下更多的学习器工作与 rollout 进行重叠,并且当 rollout 和学习器工作耗时相近时,这种收益最大。同时,尽早开始工作意味着在每个组或批次关闭之前需要保留部分梯度状态,这本质上是用训练器内存来换取挂钟时间。作者将这些依赖关系视为一个设计空间。采用更细粒度的就绪单元、以及在准入时权衡内存与剩余服务时间的策略,可以将更多的学习器工作转移到 rollout 窗口中;而为其他目标识别就绪单元,则可以将精确的梯度流式处理扩展到 GRPO 和 OPD 之外。

附录 B:效率测量标准

训练器活动 MFU(Trainer active MFU) 本文中,训练器活动 MFU 定义为学习器的模型 FLOPs 除以完整的更新挂钟时间以及训练器 GPU 的峰值容量。对于第 $k$ 次更新,设 $F_k^{\mathrm{train}}$ 为学习器所需的模型 FLOPs,$T_k^{\mathrm{step}}$ 为其完整的更新挂钟时间,$P_d$ 为训练器 GPU $d$ 使用的密集 BF16 峰值速率。其计算公式为 $\mathsf{MFU}_k^{\mathrm{active}} = \frac{F_k^{\mathrm{train}}}{T_k^{\mathrm{step}} \sum_{d \in \mathcal{D}_{\mathrm{train}}} P_d}$。分母的时间窗口包括 rollout 等待、环境执行、教师打分、学习器工作、最终归约、优化器执行和策略发布。由于重叠的学习器工作减少了训练器空闲时间,因此该指标会上升。

平均训练器活动 MFU(Average trainer active MFU) 对于预热后 $N$ 个已完成更新的报告窗口,平均训练器活动 MFU 为 $\overline{\mathrm{MFU}}^{\mathrm{active}} = \frac{1}{N} \sum_{k=1}^N \mathrm{MFU}_k^{\mathrm{active}}$。实验中,作者记录了种子 42、43 和 44 的 40 次更新,丢弃了 1-4 次作为启动阶段,并对 5-40 次($N=36$)进行了性能分析。CUDA 事件记录了设备服务时间,而共享的主机时钟记录了完整的更新周期。

步骤挂钟时间加速比(Step wall time speedup) 步骤挂钟时间是每个已完成训练更新的流逝挂钟时间。对于 $N$ 个已完成的更新,设 $\bar{T}_{\mathrm{method}}^{\mathrm{step}}$ 为流逝时间除以 $N$。每个目标和配置的加速比为 $\mathrm{Speedup}_{\mathrm{method}} = \frac{\bar{T}_{\mathrm{Sync}}^{\mathrm{step}}}{\bar{T}_{\mathrm{method}}^{\mathrm{step}}}$,其中两个时间使用相同的工作负载、硬件分配和预热后完成的更新次数。

硬件分配与内存测量 8-GPU 配置将 4 张 GPU 分配给学习器。ThunderSyncRL 报告的 GPU 峰值内存是学习器 GPU 在更新期间的最大值,包括梯度累积、分布式归约和优化器执行。它涵盖了常驻模型和优化器状态、激活值、梯度缓冲区和临时存储。FP32 批次累加器和 GRPO 组统计信息驻留在固定的主机内存(host RAM)中,不计入 GPU 峰值。

附录 C:训练数据与基准隔离

数据源与版本控制 软件工程工作负载使用 SWE-smith(Python 版本,包含 50,908 个实例),终端工作负载使用 SETA-Env(包含 4,567 个任务)。评估使用 SWE-bench Verified(500 个任务)和 Terminal Bench 4.0(66 个任务)。所有数据源的版本和哈希值在比较期间保持固定。

过滤规则与开发集划分 SWE-smith 的静态过滤移除了 11,437 个问题描述为空的记录。SETA 任务全部通过了包含指令、环境 Dockerfile 等静态检查。开发集包含了 5% 的组(按仓库或源家族划分,向上取整),这些组是通过规范化组标识符的 SHA-256 摘要排序后选出的前几个组。最终训练集包含 37,084 个 SWE-smith 任务和 4,333 个 SETA 任务。

可执行验证与语义去污(Decontamination) 对于 SWE-smith,作者在原始仓库上运行了验证工具,应用了引入 bug 的补丁并重新测试。对于 SETA,验证了参考解决方案能够通过且 no-op 解决方案未能解决任务。此外,作者进行了极其严格的语义重叠审查,排除了与基准测试(Benchmark)在指令、解决方案或测试哈希值上重叠的源家族,确保基准测试任务绝对不参与训练。

附录 D:优化与生成设置

逻辑批次与优化器设置 GRPO 每次更新使用 32 个 prompt,每个 prompt 采样 8 条轨迹(共 256 条)。OPD 每次更新使用 32 个 prompt,每个 prompt 采样 4 条独立轨迹(共 128 条)。优化器为 AdamW,全微调学习率为 $10^{-6}$,无权重衰减,全局梯度范数裁剪为 1.0。GRPO 组内奖励通过总体标准差进行标准化。学生前向精度为 BF16,梯度累积和 Adam 状态使用主机端的 FP32。对于 Qwen LoRA 配置,秩设为 32,缩放参数 $\alpha=64$,目标模块包括注意力投影和 MLP 层。

智能体交互与生成限制 滚动生成使用 vLLM。每个轨迹最大允许 300 个智能体回合,每回合最多生成 1,024 个 token。最大总上下文 token 数限制为 131,072。采样温度为 1.0,top-p 为 1.0。启用了 vLLM 的 chunked prefill 和自动 prefix caching,禁用了投机解码。

教师模型与硬件分配详情 Qwen-3.8-27B 的 OPD 教师模型是 Qwen3.8-Flash-Next-FP8。GLM 的 OPD 教师模型是 GLM-5.3-Flash FP8。教师模型保持冻结状态。ThunderSyncRL 在 4 个学习器 GPU 上复制 BF16 学生模型,在它们之间分片 AdamW 状态,并在主机内存中以 FP32 累积梯度。GRPO 的准入上限 $k$ 设为 1,这意味着当某个 rank 上有 $k$ 个组持有统计信息时,新组的轨迹反向传播会被推迟,从而严格限制了主机内存的使用量(跨 4 个 rank 最大约 1.5 TB)。

对比控制变量 所有比较(Sync、Async、Fully Async 和 ThunderSyncRL)均固定了目标函数、模型、适配方法、初始检查点、训练列表、奖励、优化器、精度、服务设置、环境资源和硬件。Async 使用落后学习器一个优化器更新的策略进行采样(1-step stale),而 Fully Async 允许在轨迹飞行中途更新权重(可变滞后)。

附录 E:评估设置

基准测试与成功标准 SWE-bench Verified 使用官方评估工具,要求所有指定的 FAIL_TO_PASS 和 PASS_TO_PASS 测试通过。Terminal Bench 4.0 使用其官方的 Harbor 工具,并保留了 8 小时的外部超时限制。训练奖励与评估成功标准分离,例如 SETA 训练使用部分进度奖励,而评估使用官方的任务成功判定。

尝试次数与 pass@3 聚合 协议规定在每个评估检查点对每个任务进行 3 次独立尝试。公式 $\mathrm{pass}@3 = \frac{100}{M} \sum_{i=1}^M \mathbf{1}\left[\sum_{j=1}^3 y_{ij} > 0\right]$ 计算了在三次尝试中至少成功一次的任务比例。尝试会重启环境和智能体历史,后续尝试不会收到之前尝试的反馈。

检查点与 GPU 小时数的比较方法 固定预算比较使用的是在 128 GPU 小时内发布的最晚完成的检查点。到达目标的时间是首次达到该目标的评估检查点。所有结果均基于三个独立训练种子(42、43、44)的平均值。GPU 小时数的计算包含了 rollout、环境交互、验证、教师打分、学习器计算和策略发布的总时间。

附录 F:可扩展性理论

步骤时间与学习器尾部 作者构建了严格的数学模型。设 $R$ 为 rollout 时间,$p_j$ 为学习器作业 $j$ 的服务时间,总学习器服务为 $L = \sum_{j=1}^n p_j$。完成时间满足 $c_n = \max_{1 \leq j \leq n} \left(\tau_j + \sum_{i=j}^n p_i\right)$。定义学习器尾部(learner tail)为 $\lambda_K = [c_n - R]_+ / R$,相对学习器服务为 $\rho = L / R$,最终后缀为 $\kappa = P / R$。Sync 的时间为 $T_{\mathrm{Sync}} = R + L + P$,而 ThunderSyncRL 的时间为 $T_{\mathrm{ThunderSyncRL}} = R(1 + \lambda_K) + P$。由此推导出加速比上限公式:$S_{\mathrm{Sync}} \leq \frac{R+L+P}{\max(R, L) + P} \leq 2$。

工作释放如何决定尾部 设 $F^-(u)$ 为在归一化时间 $uR$ 之前释放的学习器服务分数。尾部时间满足 $1 + \lambda_K = \max\left\{1, \ \sup_{0 \leq u \leq 1} \left[u + \rho \big(1 - F^-(u)\big)\right]\right\}$。最大滞后定义为 $D = \sup_{0 \leq u \leq 1} [u - F^-(u)]$,尾部满足 $[\rho - 1]_+ \leq \lambda_K \leq [\rho - 1]_+ + \rho D$。

  • GRPO 释放模型:假设轨迹完成时间均匀分布且服务与 $U^\gamma$ 成正比。释放分数公式为 $F_{\mathrm{GRPO}}(u) = (1 - \beta) u^{\gamma+1} + \beta u^{\gamma+m}$,其中 $\beta$ 是等待组完成的服务比例。
  • OPD 释放模型:引入回合数 $a$ 和延迟分数 $\delta$,释放分数公式为 $F_{\mathrm{OPD}}(u) = \frac{1 - \delta}{a} \sum_{j=1}^a \min\left(1, \frac{au}{j}\right)^{\gamma+1} + \delta u^{\gamma+1}$。

批次大小与连续 rollout 波次 设一个完整的 rollout 波次耗时 $W$,对于 $w$ 个连续启动的波次,加速比公式推导为 $S_{\mathrm{Sync}}(w) = \frac{w(1 + \rho_{\mathrm{w}}) + \kappa_{\mathrm{w}}}{w \max(1, \rho_{\mathrm{w}}) + \kappa_{\mathrm{w}} - [\rho_{\mathrm{w}} - 1]_+ + \lambda_{\mathrm{w}}}$。在平衡状态下,当波次 $w$ 增加时,比率逼近 2。

有限批次与模型局限性 如果两个释放分布在所有时间上的差异最多为 $\epsilon$,则它们的归一化端点差异界限为 $|\lambda(F, \rho) - \lambda(G, \rho)| \leq \rho \sup_u |F(u) - G(u)|$。这证明了连续理论模型对离散实际情况的有效近似。

图表参数与测量对比 作者评估了 588 组配对配置。定义误差 $e_i = 100 \frac{|o_i - s_i|}{s_i}$ 和 $d_i = 100 \frac{o_i - f_i}{o_i}$。结果显示,释放模型与迹线预测的平均偏差 $e_i$ 仅为 1.6%(最大 10.6%),而迹线预测与实际挂钟加速比的差距 $d_i$ 平均为 6.5%,证明了理论模型的高度准确性。

图 9:相对于 Sync 的加速比,作为 rollout 与训练时间比率以及每轨迹智能体回合数的函数,在固定的每次优化器步骤轨迹数(256 至 2048)下,对于 GRPO(上)和 OPD(下)。
图 10:相对于 Sync 的加速比,作为 rollout 与训练时间比率以及每次优化器步骤轨迹数的函数,在固定的每轨迹智能体回合数(10 至 300)下,对于 GRPO(上)和 OPD(下)。

附录 G:经验更新等效性

验证协议与结果 作者记录了 Sync 运行的连续 10 个逻辑批次,并在 Sync 和 ThunderSyncRL 下重放。定义参数差距公式为 $\Delta_k = \frac{\|\theta_k^{\mathrm{ours}} - \theta_k^{\mathrm{sync}}\|}{\|\theta_k^{\mathrm{sync}} - \theta_0\|}$。在 FP32 精度下,两种调度的梯度逐坐标完全一致(GRPO 相对误差 $5.1 \times 10^{-7}$,OPD 为 $1.1 \times 10^{-6}$)。在 BF16 下,FP32 参数差距保持在 $6 \times 10^{-5}$ 以下,比 BF16 和 FP32 Sync 之间的差距低近三个数量级。这在数值精度层面证实了 ThunderSyncRL 完美复现了批次同步更新。
图 11:在 B200 上 GRPO(顶行)和 OPD(底行)的更新等效性。
图 12:在 H200 上的更新等效性。

附录 H:进一步的实验结果

Pass@1 和 Pass@5 结果 公式 $\mathsf{pass}@k = \frac{100}{M} \sum_{i=1}^M \left(1 - \binom{n - c_i}{k} \Big/ \binom{n}{k}\right)$ 用于无偏估计 $k$ 次尝试中至少成功一次的概率。图 13 和图 14 证实,无论是评估单次尝试的 pass@1 还是多次尝试的 pass@5,ThunderSyncRL 在达到相同性能时的成本均显著低于 Sync。
图 13:SWE-bench Verified 上的 pass@1 和 pass@5 随训练成本的变化。
图 14:Terminal Bench 4.0 上的 pass@1 和 pass@5 随训练成本的变化。

LoRA 效率结果 在 8 张 B200 GPU 上配置 LoRA 后,ThunderSyncRL 依然保持了效率优势(MFU 达到 16.7% 至 33.0%),且挂钟加速比为 1.62x 至 1.71x。由于冻结了基础权重减少了学习器工作量,加速比略低于全微调,但依然在零策略滞后下超越了 Sync。

附录 I:ThunderSyncRL 算法与实现

整体算法逻辑与共享前缀反向传播 算法 1 展示了 rollout 线程(生产者)和学习器线程(消费者)的并发执行。就绪源被推入队列,学习器不断弹出并处理。所有调度(Sync、Async 和 ThunderSyncRL)均在学习器上复用了共享前缀计算优化:在固定的学习器快照下,计算一次共享前缀,处理每个带有因果上下文的延续分支,并累积其相对于前缀边界状态的梯度。分支贡献准备就绪后,一次通过共享前缀的反向传播即可传递其总和。

GRPO 实现细节 以下代码展示了奖励就绪准入以及公式 7 中的分解逻辑。源梯度可以在内容完成时准备好,随后再绑定其奖励。finish_group_backward 负责将组合的贡献通过延迟上下文进行传播。
GRPO 实现细节

OPD 实现细节 以下代码展示了回合级 OPD 路径。教师打分使用采样的动作实现的因果上下文。分离的学生对数概率来自相同的策略快照,因此重要性比率等于 1 但保留了其导数。回合反向传播在切割状态边界处捕获伴随变量(adjoints),轨迹和组关闭时传播剩余的伴随变量,最后通过全局打分 token 数进行归一化。
OPD 实现细节