千问Agent训练框架公开！不多加一张卡，训练效率提升78%

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

文章来自于微信公众号 “量子位”，作者 “量子位”