当一个编程 Agent 的单次执行要跑上几个小时、和环境交互数百轮、每条 rollout 接近 100 万 token 才拿到一次奖励时,在线强化学习的瓶颈就不再是算法,而是系统。GPU 大量时间在等最慢的那条长尾 rollout,分叉的轨迹里塞满重复内容。阿里 Qwen 团队 2026 年 9 月 27 日提交到 arXiv 的 QwenGyre 论文,正是针对这两个问题的训练框架。

需要先说清来源边界:本文只依据 arXiv 摘要页(arXiv:2609.33848v1)撰写,摘要之外的细节以论文正文为准。

超长时 Agent 训练的两个系统瓶颈

论文把这类任务称为 xlong-horizon(超长时)任务,摘要里的量级是:单次执行可以持续数小时、包含数百次模型与环境的交互、每条 rollout 接近 100 万 token。在这种规模下做在线 RL,摘要指出两个根本挑战。

  1. 执行方差大、rollout 延迟长。有的任务几分钟结束,有的要跑几个小时。同步等待最慢的那条,会让大量 GPU 空转。
  2. 非线性分叉带来大量轨迹冗余。Agent 会回退、重试、分支探索,同一段上下文在多条轨迹里重复出现,拖垮训练效率。

这两个问题在短任务 RL(例如单轮数学题)里并不明显,但在仓库级编程任务里会被放大。

弹性 GPU 重分配

摘要指出的两个瓶颈,对应两种常见部署方式的短板。Colocate 让 rollout 和训练共用同一批 GPU、交替执行,容易被长尾 rollout 拖住;Async 把 rollout 与训练分离、异步执行,则需要固定划分资源,难以适应负载波动。

QwenGyre 的做法是在 rollout 和训练之间弹性地重新分配 GPU,并且不中断正在运行的执行。对跑了几个小时的 rollout,这一点很关键,中途打断意味着前面的计算全部浪费。

下面的伪代码只用于说明调度思路,不是论文或 Qwen 的实际实现。

# 概念示意:根据负载在 rollout 池和训练池之间迁移空闲 GPU
while training:
    idle = rollout_pool.idle_gpus()          # 已完成 rollout、空出来的 GPU
    if trainer.has_ready_batch() and idle:
        trainer.borrow(idle)                 # 借给训练,不打断仍在运行的 rollout
    if rollout_queue.backlog() > threshold:
        rollout_pool.reclaim(trainer.release_after_step())

轨迹处理器:重建、部分进度评分与去重

摘要描述的轨迹处理器承担三件事。

  • 重建分叉历史,把 Agent 回退、重试产生的非线性交互还原成结构化的历史。
  • 为部分进度打分,不只看最终是否成功,也对中间进展给出评分。对奖励极其稀疏的长任务,这直接影响学习信号的密度。
  • 删除冗余路径,对重复路径去重,从而限制训练成本的上界。

有第三方报道补充说,QwenGyre 通过未经修改的黑盒 harness 训练编程 Agent,也就是不要求为训练专门改造执行框架。这一点来自二手报道,摘要中未出现,具体机制需以论文正文为准。

论文公开的结果

以下数字全部来自论文摘要。

项目 摘要中的数据
模型 Qwen 3.8 2.4T(论文称其旗舰模型)
每条 rollout 长度 700K token
NL2RepoBench 52.5% → 58.5%,绝对提升 6.0 个百分点,48 个训练步
相对 Colocate 的加速 最高 1.85×
相对 Async 的加速 最高 1.78×

需要注意,加速比是作者在「多个领域训练数据集上的评估」中观察到的最高值,不代表每种负载都能拿到同样收益。

边界与尚未核实的信息

  • 是否开源。部分媒体称 Qwen 团队开源了 QwenGyre,但 arXiv 摘要页没有提供代码仓库链接。在找到官方仓库之前,不建议把它当作可直接使用的工具。
  • 二手报道中的其他数字。有报道引用了运行时长从约 134 小时降到约 75 小时之类的数据,这些数字没有出现在摘要中,本文不采用。
  • 同行评审。截至本文撰写,论文为 arXiv v1 预印本。
  • 可复现性。实验规模是 2.4T 参数模型,绝大多数团队无法在同等条件下复现,结论对中小模型的适用程度仍需验证。

对应用开发者的启示

大部分团队不会自己训练 2.4T 模型,但这篇论文对构建长时 Agent 的人仍有参考价值。

  • 长任务要可中断、可恢复。训练侧不愿意打断运行中的 rollout,应用侧同样应该让 Agent 的状态可以持久化、可以续跑。
  • 记录中间进度。部分进度评分的前提是轨迹里有可度量的里程碑。为 Agent 设计显式的阶段性检查点,也有利于线上评估和故障定位。
  • 警惕上下文冗余。重试和回退会让上下文膨胀。对轨迹做摘要或去重,既是训练问题,也是推理成本问题。

如果你在做仓库级编程 Agent 或长时任务 Agent,建议直接阅读论文正文中的系统设计与消融实验部分,并关注 Qwen 团队是否发布官方代码。

参考来源

EOF · 全文完 未分类 · · 共 1.4k 字

感谢耐心读到这里。若这篇文字曾带来片刻启发或共鸣,不妨点亮喜欢或分享给同路人。

喜欢 0
DISCUSSION / 读者评论 0 条评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注