阿里 Qwen 推出 QwenGyre：面向超长程 Agent 训练的弹性强化学习框架，最高提速 1.85 倍
来源MarkTechPost查看原文
速览
- QwenGyre 在不停掉在线 Agent 的前提下，把 GPU 在 rollout 与训练之间来回调度
- 轨迹树把每个 execution 的样本上限压到 5 条，共享前缀只训练一次
- 超时未完成的执行仍按其保留的工作区打分，评估器失败不计为零奖励
- 最高比 Colocate 快 1.85x，比 Async 快 1.78x
- Qwen 3.8 2.4T 在 NL2RepoBench 上 48 步从 52.5% 提升到 58.5%
- 训练采用改造版 GSPO，每组 16 次 rollout
- 对比 veRL、AReaL、Agent Lightning，QwenGyre 是唯一未披露公开代码的框架
阿里 Qwen 团队发布 QwenGyre，一个面向「超长程（XLong-horizon）」Agent 训练的弹性强化学习框架。该框架通过未修改的黑盒 harness 训练编码 Agent，单次 rollout 可持续数小时、处理接近 100 万 token。QwenGyre 已在 Qwen 3.6 122B 与旗舰 Qwen 3.8 2.4T 模型上验证，核心思路有两条：一是在 rollout 与训练之间动态调度空闲 GPU，二是把分支化的 Agent 历史压缩成有界的训练样本。在相同分数下，QwenGyre 相比 Async 方案快 1.38x 至 1.78x，相比 Colocate 方案快 1.21x 至 1.85x；在 TerminalBench 上对 Colocate 取得最高 1.85x 的端到端加速。Qwen 3.8 2.4T 在 NL2RepoBench 上 48 步内通过率从 52.48% 提升到 58.54%，48 步总耗时 75.42 小时，而 Async 为 134.55 小时、Colocate 为 91.47 小时。论文未披露公开代码发布计划。
关键事实
- QwenGyre 是训练框架而非模型，已在 Qwen 3.6 122B 和 Qwen 3.8 2.4T 上测试，单次 rollout 约 700K token
- 122B 实验使用 24 至 32 个节点，2.4T 实验使用 192 个节点（4 个 cell，每 cell 48 节点），GPU 型号未披露
- 训练侧使用 Megatron，rollout 侧使用 SGLang，harness 为 Claude Code 2.1.220
- 在相同分数下，相比 Async 快 1.38x 至 1.78x，相比 Colocate 快 1.21x 至 1.85x
- TerminalBench 上对 Colocate 取得最高 1.85x 端到端加速；2.4T 模型上仅 1.21x，原因是大量查询接近超时
- Qwen 3.8 2.4T 在 NL2RepoBench 上 48 步内通过率从 52.48% 升至 58.54%，耗时 75.42 小时（Async 134.55 小时、Colocate 91.47 小时）
本站视角
对国内做 Agent 的团队来说，这件事的实质价值在于它把「长程 Agent 训练跑不动」这个工程瓶颈拆成了两个可复用的解法：弹性 cell 调度和轨迹树压缩。前者解决的是 GPU 利用率——Colocate 要等最慢的 rollout、Async 的池子之间不能互借，QwenGyre 让 cell 在 rollout 与训练之间来回切换，切换开销只有 8.52 秒和 3.46 秒，这个量级在小时级 rollout 面前几乎可以忽略。后者解决的是样本成本——Claude Code 这类 harness 天然产生分支树，逐条展开会重复训练共享前缀，QwenGyre 用 5 条上限加去重把前向-反向时间砍掉 25.2% 而分数不掉，说明大部分分支对梯度贡献是冗余的。我们认为这是实质进步而非营销包装：它没有提出新算法，而是把系统层的浪费挤出来，这类工作往往比新 loss 函数更容易被复现和迁移。最该跟进的是自建 RL 训练栈、且已经在跑小时级编码 Agent rollout 的团队，尤其是用 Megatron + SGLang 这套组合的；如果只是调用 API 做应用层，短期影响有限。需要指出几处可疑或不足：其一，2.4T 模型上对 Colocate 只有 1.21x，原文归因于大量查询接近超时，这说明收益高度依赖任务时长分布，短任务上弹性调度的空间会被压缩；其二，横向对比表里 AReaL 报出 2.77x vs synchronous，而 QwenGyre 报的是 1.85x vs Colocate，原文自己标注「各项目自建环境、不可直接比较」，读者不应把这两组数字放在一起排名；其三，论文未披露 GPU 型号、未披露代码开源计划，许可证状态也是「未披露」，这意味着外部团队目前无法复现，只能等后续动作。我们判断，QwenGyre 更像是一次面向自家旗舰模型训练的基础设施建设，公开论文的传播价值大于短期可复现价值，真正值得观察的是它是否会开源、以及这套弹性调度能否在非 Qwen 模型上复用。
背景与影响
「超长程」任务指 Agent 运行持续数小时、经历数百次模型与工具交互，例如按规格生成完整代码仓库（NL2Repo-Bench）。这类任务在训练时暴露两个工程问题：一是 rollout 存在长尾，Colocate 方案下训练要等最慢的执行、GPU 空转，Async 方案下固定 GPU 池之间又无法互相借调算力；二是 Claude Code 这类 harness 会压缩上下文、派生 sub-agent、重试，一次执行会变成一棵分支树而非单条轨迹，逐条展开会重复共享前缀、推高训练成本。QwenGyre 的应对是把 GPU 切成共享同一训练布局的 cell，每个 cell 既可服务 rollout 也可承载完整训练副本，由核心 cell 持有权威权重与优化器状态，卫星 cell 稍后加入训练；调度器跟踪 rollout waterlevel（排队中与运行中的执行数），当剩余 cell 仍能服务全部在线工作时就切换部分 cell 进入训练，模型调用通过代理转发，harness 无需中断。KV-cache 块在重路由时经 RDMA 迁移以减少前缀重算，卫星 cell 通过 Mooncake 的 Transfer Engine 拉取核心权重并加入正在进行的 batch，流式训练让 cell 在数据就绪时认领 micro-step。轨迹侧则用 TITO（token-in, token-out）记录精确 token ID 与行为 log-probability，把调用存成前缀共享的轨迹树，按 main > main-summary > sub-agent > sub-agent-summary 排序，每个 execution 最多保留 5 条，共享目标只计一次，只有策略生成的 token 参与训练，损失在每个 execution 内取平均以免分支多的执行权重被放大。这意味着长程 Agent 训练的瓶颈正从「模型能力」部分转向「训练系统吞吐」，对做编码 Agent、需要跑数小时级 rollout 的团队来说，调度与样本构造的工程价值在上升。需要观察的是，论文未披露 GPU 型号与代码开源计划，横向对比表中的加速数字来自各项目自建环境，原文也明确提示不可直接比较。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
