千问公开 Agent 训练框架 QwenGyre：同等 GPU 预算下 48 步 RL 训练从 135 小时压缩到 75 小时

文婷 发自 凹非寺 量子位 | 公众号 QbitAI GPU不够烧，但AI要啃的任务却越来越长，模型迭代稍慢一步就可能被同行彻底甩下牌桌。 怎么破？ 千问交出了一份新答卷—— QwenGyre 。 在同等GPU预算下，它将原本需要跑135小时的48步强化学习训练时间直接压缩到了 75小时 ，一口气为团队省下了 近三天（60个小时） 的训练时间。 这意味着，训练团队不用再多加一张卡，靠QwenGyre重新安排算力、处理训练数据，就能把训练效率提升 78% 。 那么QwenGyre是怎样把原本浪费掉的算力重新抠出来的？

研发过程中又刷新了千问团队对于Agent训练什么认知？ 看完你就明白了。 AI接上大工程，训练系统先“堵车”了 从前咱们聊代码Agent，顶多是在SWE-bench这类基准上修一个现成的bug，AI跟终端交互几十轮就收工了。 但现在趋势完全变了。 大家开始让AI独立搞全自动软件开发。 无论是从零搭一个完整代码库、做系统级重写、还是给整个超大工程做代码重构。 这背后，都透露出了用户对 长程自主规划 与 复杂工程落地能力 越来越高的要求。 Qwen团队将这类任务称为 xLong-horizon ，即超长程任务。

跑一次rollout（环境交互），AI要调用各种工具、跑终端命令、反复看报错，连续交互几百次，上下文动辄累积100万token。 这就像公司派了一批AI实习生去独立承包整个重大软件项目，很难吃得消。 而问题，也就恰好出在这场 工程实习 里。 我们可以总结为两个麻烦。 第一个麻烦：Agent交卷时间参差不齐，算力只能跟着干等 同一批分发下去的任务，有的AI运气好或者任务简单，半小时就交卷了； 但有的AI一旦遇到了棘手bug，就能在沙盒里疯狂死磕4个多小时。

在这时候，如果用传统的 Colocate（共享池交替） 模式，整个GPU集群就像一个同进同退的大班级。 哪怕90%的卡早就跑完了，也必须死等最后一个拖后腿的AI交卷，才能全集群统一切换去做训练反向传播。 导致提前交卷的算力全都在干等， 算力利用率暴跌。 如果换成 Async（异步分离） 模式呢？ 把GPU切成两块，一块专职跑推理，一块专职跑训练？ 结果，更尴尬了。 因为超长任务生成太慢，负责训练的GPU经常断粮饿肚子； 而负责推理的GPU卡到冒烟，又没办法把训练卡拉过来帮忙跑推理…

△ 三种算力调度方式对比 第二个麻烦：工作记录不断分叉，复盘算账彻底乱套。 在几个小时的工程执行里，像Claude Code 2.1.220这种成熟的黑盒Agent框架，可不会像小学生记流水账一样单线往下走。 上下文快爆了，它就会 自动做历史压缩（compaction） ； 任务太重了，它就会 派生出子Agent去干活 ； 命令跑挂了，它就会 掉头重试 。 于是，跑完一个项目后，AI留下的根本不是一条直线的执行记录，而是一棵枝繁叶茂、疯狂分叉的轨迹树。

△ Agent的轨迹树 要是我们这时候选择做策略优化，系统就会当场就懵圈： 所有分叉路径全展开训练？ 不行，显存和计算量会瞬间原地爆炸，里面充斥太多重复前缀； 中途超时的任务怎么算分？ 直接判0分太冤枉了吧，毕竟人家已经写完了80%的代码； 但不判0分，又没有最终的成功信号。 面对这团乱麻， QwenGyre干脆把整套系统重构了一遍。 给GPU动态调班，理清AI的“实习日志” 千问团队给出的解法很清晰： 弹性调度器（Elastic Scheduler） ：负责管算力；

轨迹处理器（Trajectory Processor） ：负责管数据。 △ QwenGyre整体架构 整体运作可以分成两步走。 第一步， 给GPU无缝调班 。 QwenGyre把整个GPU集群切成了多个可以独立切换角色的计算单元（Cell，比如4台机或8台机一组）。 排在第一位的叫Core Cell，掌握着优化器状态和权威模型权重； 后面的叫Satellite Cells。 在任务刚启动时，大家都在全力以赴跑推理。

系统里设置了一个 水位线监控机制（Waterlevel Control） ，时刻盯着还剩多少没跑完的任务。 随着一部分AI陆续交卷，未完成的任务越来越少，水位线跌破阈值。 这时候，空闲下来的Cell不需要等所有Agent，立刻就可以就地转职，切去训练模式。 △ 水位线监控机制图 这套机制的灵感，来源于千问团队内部的一张 GPU利用率监控看板 。

他们发现，在传统训练框架中，GPU利用率总会呈现出一种 锯齿状波动 ： 第一轮任务刚开始时，大量Agent同时调用模型，导致负责推理的GPU忙得热火朝天、 推理需求瞬间拉满 ； 但随着越来越多Agent完成任务，或者转去调用工具、运行测试，推理需求便会一路下滑， 大量GPU也跟着闲下来待命 。 而另一边，等待训练的数据却在不断堆积。 于是团队灵机一动： 既然推理和训练的波峰波谷正好错开，那为什么不能让同一批GPU灵活换班，用训练的高峰填平推理的低谷呢？ 好一个逆向思维。 既然算力潮汐无法抹平，那就让任务去适应潮汐！

咱们可以把它理解为 去银行办理业务 。 早晨刚开门时客户扎堆，5名工作人员需要全部留在窗口接待； 但随着一些业务办完，有些客户开始转去填表、复印，窗口逐渐空了下来，只是后台等待处理的材料越堆越多。 这时，银行只需要根据尚未办完的业务量，留下足够的人守住窗口，再让其余员工转去后台处理材料，便能提高整体工作效率。 QwenGyre也是如此。 当推理需求下降时，就把空闲GPU切去训练； 一旦Agent重新需要调用模型，再把算力调回来。 这样，GPU既不用陪着少数慢任务干等，也不会错过随时可能回来的Agent。

看到这里，大家可能会忍不住好奇： AI还在沙盒里跑着呢，GPU突然切去搞训练，推理不就直接掉线崩溃了吗？ 对此，QwenGyre设计了一套透明的 无损迁移机制 ： 1、请求透明重路由： 当某个Cell准备转职训练时，它先停止接收新请求，代理层把后续的模型调用秒级分流到还在负责推理的节点上。 2、RDMA极速搬运KV-Cache： 原节点把显存里的Cache块锁住，目标节点直接通过RDMA把缓存拉过去无缝接力，尽量避免重新算一大段历史上下文。

3、切换耗时极短： 从推理切到训练平均只要 8.52秒 ，从训练切回推理只要 3.46秒 。 相比于动辄几个小时的工程任务，这几秒钟的切换时间几乎可以忽略不计。 △ 无损迁移机制，依据论文制图 而且在训练侧，千问团队还搞了 流式训练（Streaming Training） 。 Core Cell不需要等一个大Batch的所有数据全部集齐，只要手头有做完的数据，直接拉开架势开训。

随后转职过来的Satellite Cell通过Mooncake Transfer Engine可直接拉取权威权重，像拼积木一样动态插队加入训练。 于是，谁算力空闲，谁就从微步队列里认领任务； 大家各干各的，最后在同一个时间点齐刷刷完成参数更新。 这样一来，算力调班便理顺了。 第二步，是 理清AI复杂的“实习日志” 。

面对AI在几个小时里留下的那棵巨大、错综复杂的分叉轨迹树，QwenGyre做了几道干净的处理： 1、TITO（Token-in Token-out）与前缀树共享： 黑盒代理层精确记录每一次模型调用的原始token与行为概率。 所有分叉路径合并成一棵前缀树，公共前缀只存一份，训练时也只算一次目标损失，绝不重复算账。

△ TITO处理，依据论文制图 2、科学给出“过程分”： 如果AI因为超时没彻底跑通整个项目，评估器（比如独立的Qwen 3.7-Max打分模型或项目单测）会对当前已经生成的代码产物做局部评估，并给出真实的过程分，而不是直接一棍子打死判为0分。 这样一来， 中途探索的经验，也能转化有效的训练信号。

△ 过程分评估流程，依据论文制图 3、按角色优先级精准采样： 面对庞大的分支，系统也设立了严格的优先级： 主Agent主线>主Agent总结 > 子Agent任务 > 子Agent总结 系统给每个任务设立了一个严格的预算上限 （默认最多挑5条轨迹） ，并优先保证主任务的学习信号，防止边角料子任务反客为主。 △ 优先级排序，依据论文制图 4、严格打mask与样本级归一化： 只有模型自己吐出来的token才算loss ，系统提示词、工具返回的终端输出全部打上mask。

同时把损失在任务内部做平均，杜绝了“谁分叉多谁权重就大”的偏置问题。 △ 整套流程，图源论文 这两套组合拳打下来，模型的排班便更加灵活了，复盘也更利索了。 但架构搭得再漂亮，最终还是要看实战演练。 接下来，就让咱们一起来扒扒看，它的实际战果如何。 少花近60小时，AI学得怎么样？ 除了在Qwen 3.6 122B上做了详尽的消融对比外，千问团队还把这套方案直接推到了旗舰模型Qwen 3.8 2.4T上。

整体评测任务选的也是业内公认最难啃的代码生成与工程基准： NL2RepoBench （根据自然语言需求从零搭建整个代码库）、 DeepSWE 以及 TerminalBench 。 而底层的Agent外壳，则统一使用的是 Claude Code 2.1.220 。 在Qwen 3.8 2.4T上跑NL2RepoBench时，超长任务的残酷性展现得淋漓尽致： 有超过61.1%的查询任务耗时在4小时以上，最长任务超时率高达38.2%。 但就算是在这样的极限压力下，QwenGyre也交出了一份不错的成绩单。

先来看训练耗时对比： 完成48步强化学习训练，传统的Async异步方案整整跑了 134.55小时 ； 传统的Colocate方案跑了 91.47小时 ； 而QwenGyre只用了 75.42小时 。 相比于Async，提速了 1.78倍 ； 相比于Colocate提速了 1.21倍 ，一口气省了整整 59.13小时 的训练时间。 而在多项跨任务的评测中，QwenGyre也相比Colocate最高实现了 1.85倍 的端到端加速，相比Async最高实现了 1.78倍 的加速。

△ 不同模型与任务上的端到端加速结果 那么速度拉得这么猛，模型智商有没有打折扣？ 答案是， 没有 。 在NL2RepoBench上，Qwen 3.8 2.4T在经过QwenGyre仅仅48步的RL训练后，代码通过率从 52.48% 狂飙到 58.54% ，提升约 6% 。 在训练得分曲线上，QwenGyre的表现与基线完全贴合甚至更优，说明提速完全没有牺牲策略优化的稳定性。

△ 左为训练得分，右为NL2RepoBench评测通过率 此外，千问团队还做了一组非常有意思的 消融实验 ，验证了轨迹采样的威力： 如果每个任务只挑 1条 主轨迹 拿去训练，模型的训练得分明显变差，梯度范数也开始剧烈震荡，说明AI丢掉了重要的上下文分支信息； 但如果把所有分叉轨迹一股脑全塞进去，显存和前反向计算开销又过于沉重。 当把预算设为 5 时，不仅训练效果紧贴全量轨迹基准，平均每步的前向与反向计算时间也直接缩短了 25.2% 。

△ 122B模型的轨迹预算消融 而调度颗粒度的实验同样证明，把32个节点划分为8个4节点Cell，由于能够更早地把算力分批送去训练，大部分训练耗时都被完美“隐蔽”在了推理等待的间隙里。 从算力调度的动态变形，到轨迹树的精准剪枝，每一步都卡在了最关键的节骨眼上。 说到这里，大家或许会以为，Qwen这项亮眼的研究早已筹谋多时。 但事实恰恰相反。 千问的研发团队向我们透露，QwenGyre的诞生，仅仅只是源于一条朴素的日常需求： 让超长程任务训练跟上千问主模型的迭代节奏，别让一轮实验动辄跑上半个月，甚至一个月。

而这段研发经历，也 刷新了他们对Agent训练的固有认知。 把GPU跑满，把Agent送得更远 最先让他们感到意外的，其实是QwenGyre最终跑出来的速度。 起初，他们只是想盘活闲置GPU，不让超长程任务拖慢主模型的交付节奏。 但随着实验的逐步推进，他们才猛然地意识到， 现有Agent强化学习框架里被浪费掉的算力，远比他们想象的还要多得多得多。 而另一个打破他们固有认知的发现，则来自 训练轨迹 。 过去大家很容易认为Agent在执行任务时产生的分支越多，送进模型学习的轨迹越完整，训练效果就越好。

但Qwen团队在消融实验中发现事实并非如此： 并不是每一条轨迹都值得模型从头学一遍。 正如前文所说的，他们在论文中抛出了最直接的证据： 当他们选择只保留主Agent轨迹，再从大量分支中挑选一部分真正有学习价值的内容时，平均训练时间缩短了约 25% ，但最终效果却几乎没有变化。 而这也让团队意识到，Agent的训练或许早已告别了“堆轨迹、拼算力”的粗放阶段，迈入了 “精准筛选、高效提纯” 的精细化时代。 他们认为，在Agent RL时代， 训练基础设施绝不能只是模型外面负责搬数据、管GPU的后勤部门。

训练的基础设施能不能承载长程任务、能不能处理爆炸式增长的分支、能不能快速把经验转化为下一轮训练数据，将会直接决定模型可以学习多复杂的能力。 而目前，用户需求的明显转向也推动着千问愿意花力气去改造这套底层框架： 现在，大家越来越在意模型能不能在超长上下文中保持逻辑一致、严格遵守复杂规范、以及独立交付一个真正可运行、可验证的完整成果了。 比如说，能不能从0开始搭建《我的世界》游戏。

但千问团队也直言， GPU资源有限是整个行业绕不开的痛点 ： 阿里的算力储备在国内公司中已经相对能打，但目前模型规模、数据量和实验需求涨得太快，GPU性能与资源供给还是很难完全跟上。 所以， 比起去追问“有没有卡”，能不能把手里有限的卡真正跑满或许才是更值得关注的事情。 而QwenGyre要做的，就是帮千问训练团队从现有的GPU里持续“抠”出生产力，让相同的算力支撑起更多的实验、更长的任务和更快的模型迭代。 千问团队表示，为了完成这套框架，千问AI Infra与算法团队共同投入了 约两到三个月 ；

其中， 千问曾于去年提出的 GSPO算法框架 ，MegaFlow智能体调度框架，SWE-Universe数据构建框架，以及开源社区中的 Megatron 、 SGLang 、 Mooncake 等开源项目，共同为QwenGyre的诞生提供了宝贵的支持和灵感。 而QwenGyre，也将于优化后开源。 对于未来可能出现的借鉴甚至是“抄作业”，团队也看得相当坦然： 有人愿意借鉴，本身就是对我们这套思路的认可。 计算机技术的进步，本来就建立在开源社区不断分享、验证和迭代的基础上。

QwenGyre真正想贡献给行业的，是一次关于Agent强化学习中GPU放置、数据分发和训练轨迹处理方式的重新思考。 同时，千问也坦言，这些藏在底层的基础设施和资源调度确实很难被用户直接看见； 但 它带来的好处将在未来一点点浮出水面 ： 例如，当训练时间砍掉44%后，千问就能更快地验证新的训练方法、更频繁地迭代模型； 代码Agent也能从只修一个Bug，逐渐进化到连续稳定工作数小时，并学会独立搭项目、做重构、跑测试，最后为用户交出一个真正能够运行的完整结果。 而这，或许才是QwenGyre最重要的价值。

当AI开始接手越来越漫长、越来越复杂的工程任务时； 决定其能力上限的，早已不只是模型本身有多聪明，还有训练它的那套底层系统，究竟能把它送到多远。 参考链接： [1]https://arxiv.org/abs/2609.33848 一键三连 「点赞」「转发」「小心心」 欢迎在评论区留下你的想法！ — 完 — 🌟 点亮星标 🌟 科技前沿进展每日见