先设想一个场景：你让旗舰模型从零写出一个完整的代码仓库。它要跟终端、测试、文件系统反复交互几百轮，一次 rollout 吃掉约 70 万 token，一跑就是几个小时。这时候你想用在线强化学习继续把通过率往上抬，却发现集群里相当一部分 GPU 在干等——等最慢的那几条轨迹跑完。等也不是，不等也不是，训练预算就这样被长尾烧掉。
阿里千问团队新发布的 QwenGyre，就是把这个问题当靶子的。它给出的答案分两半：一半管算力调度，让空闲 GPU 在采样和训练之间随时换岗；另一半管轨迹处理，把分叉产生的海量冗余轨迹修剪成训练能高效消化的形状。
论文说了什么，本文不说什么
先交代信源。QwenGyre 的论文《QwenGyre: An Elastic Reinforcement Learning Framework for Training xLong-Horizon Agents》于 2026 年 9 月 27 日提交 arXiv（编号 2609.33848，页面见 https://arxiv.org/abs/2609.33848 ），署名 12 位作者，包括 Weiqi Wang、Yuxin Zhou、Mouxiang Chen 等。中文科技媒体 ai-bot.cn 在 10 月 13 日以「阿里千问推出在线强化学习框架 QwenGyre」为题收录了这条消息。训练对象是千问的 Qwen3.8-2.4T 模型。
再把分工说清楚。本站此前已经写过小米 MiMo-V2.6 的 Agentic RL 路线与 verl 训练基建（开源篇），也做过开源 RL 训练框架的横评（横评篇）。所以本文不聊框架选型，也不做 verl、SLime 之类的横向对比，角度只有一个：当旗舰模型在跑 70 万 token 级的超长程 agent 任务时，在线 RL 的工程调度与轨迹处理到底要怎么做。就这个具体问题而言，QwenGyre 是目前公开材料里讲得最系统的一份。
超长程在线 RL 的两堵墙
论文摘要口径，QwenGyre 针对的是两大痛点。
第一堵墙：执行方差大，rollout 延迟长，GPU 大量空转。超长程任务有个讨厌的性质：同一个策略采样出来的轨迹，完成时间可以差出数倍。有的 rollout 半小时收敛，有的跑几个小时还卡在环境报错里循环。同步式训练要等最慢的那条轨迹齐活，快 GPU 全程陪跑；异步式训练虽然不等了，但参数一更新，正在跑的旧轨迹价值就打了折扣，调度不好反而更浪费。任务越长，方差被放大得越厉害，空转问题就越无解。
第二堵墙：非线性分叉产生海量轨迹冗余，训练效率低下。agent 任务不是一条直线。一次工具调用的不同返回结果，会引出完全不同的后续路径；一个仓库写到一半，测试通过和测试失败通向两个世界。几百次交互之后，轨迹数量指数膨胀，而其中大量内容是重复的共享前缀。如果每条轨迹都完整计价、完整回传梯度，等于同一份前缀被反复计算、反复计权重，训练信号被冗余稀释。
这两个痛点在普通长度的 RLHF 里并不致命，但任务一旦拉长到论文对 xlong 任务的定义——单次执行可达近 100 万 token、数百次模型-环境交互、持续数小时——就会被指数级放大。QwenGyre 的两个核心机制，分别对着这两堵墙。
弹性调度器：让 GPU 在采样与训练之间换岗
第一根支柱是 Elastic Scheduler（弹性调度器）。它解决的问题是：rollout 的算力需求和训练的算力需求在时间上错配，而传统做法把 GPU 静态绑死在某个角色上。
同构 cell：不预设角色
QwenGyre 把 GPU 划分为一个个同构的 cell，每个 cell 既能用 SGLang 承担采样（跑 rollout），也能用 Megatron 承载训练副本。这个设计的前提是同构：如果 cell 之间硬件不一致，换岗就没法自由进行。角色不再由部署拓扑决定，而是由调度器按需分配——采样端积压就多派几个 cell 去采样，训练端有富余就拉回来算梯度。
数秒级切换：三件事必须同时做到
关键卖点是「任务不中断的情况下动态切换」。切换时做三件事：请求重路由、KV cache 经 RDMA 迁移、工作区与工具状态保留。论文口径，整个切换耗时仅数秒。
拆开看这三件事。请求重路由保证在途请求不丢；KV cache 走 RDMA 迁移，意味着采样上下文不用重新 prefill——对一条已经滚了几十万 token 的轨迹来说，重新算一遍 prefill 的代价是不可接受的；工作区与工具状态保留则最容易被忽视但最关键：agent RL 的环境状态不只是模型上下文，文件系统、终端会话、测试环境都是状态。如果切换采样节点要重置环境，超长程任务等于白跑。把这层状态纳入迁移范围，是「不中断」能成立的前提。
核心与卫星：算力热插拔
另一个值得展开的机制是核心 cell 与卫星 cell 的分层。核心 cell 持有权威参数；卫星 cell 拉取参数快照后，可以中途加入当前批次的梯度累计。这意味着算力可以热插拔——一块刚被释放的 GPU 不用等下一个完整训练轮次，直接并入正在进行的批次干活。对超长程负载来说，这种「来活就接」的弹性，正是把空转时间吃掉的关键。
一句话总结这根支柱：Elastic Scheduler 把「算力供给」和「任务节奏」解耦了，让 70 万 token 的长尾 rollout 不再绑架整张集群。
轨迹处理器：TITO、轨迹树与 Partial Scoring
第二根支柱是 Trajectory Processor（轨迹处理器），对着「轨迹爆炸」那堵墙。三个机制环环相扣。
TITO：输出必须对上生成时的原始上下文
TITO（Token-in Token-out）记录每次调用的精确输入输出。听起来平平无奇，实际上戳中了 agent RL 的一个隐蔽坑：多轮交互之后，模型看到的上下文已经被系统注入、工具结果、环境反馈改写过很多轮。如果直接拿最终状态的组织方式当训练信号，某段输出对应的可能根本不是它生成时的原始上下文——训练信号就成了「虚假上下文」，梯度在纠正一个当时根本不存在的决策。TITO 的原则是每段输出都必须对上它生成时刻的原始上下文。举个直观的例子：agent 在第 50 步调用了测试命令，得到一份失败报告，然后基于这份报告做了修复决策。到第 300 步再回看，上下文里那份报告可能已经被摘要压缩、被后续工具输出推挤变形。如果训练时把第 300 步看到的「变形版报告」当成第 51 步决策的输入，模型学到的因果关系就是错的。TITO 在记录阶段就锁死每一步的精确输入输出，不管后面上下文怎么演化，训练信号永远锚定生成时刻。对几百次交互的超长任务来说，这一点直接决定梯度修的是「当时那个错」，还是「想象中的错」。
轨迹树：共享前缀只算一次
轨迹按共享前缀组织成树。分叉的轨迹天然共享前缀，树结构让系统可以识别「这些轨迹其实是同一段历史的不同延续」。这是后面计损失的基础：既然前缀是同一份，它的损失就不该按分叉数重复计算。
Partial Scoring 与 Jmax：给超时任务一个交代，给分叉一个上限
超长任务经常跑不完——数小时的执行里，超时是常态而非意外。一分不得显然不合理：写了半个仓库，至少已完成的模块是可以检验的。Partial Scoring 的做法是给超时任务的可检验部分成果评分，让「做了一半」也有训练信号。
另一半是配额机制：每条执行最多保留 Jmax 条轨迹，共享前缀的损失只计一次，使每条执行的权重与分叉数解耦。直白地说，一个 agent 状态分叉出 10 条后续路径，它对梯度的贡献不会膨胀 10 倍。没有这一层，策略会学到「爱分叉的行为权重更高」，训练被探索行为本身带偏——这是轨迹冗余问题最隐蔽的代价。
三个机制合起来：TITO 保证信号正确，轨迹树保证结构清晰，Partial Scoring 加 Jmax 保证权重公平。轨迹从「一堆等长的对话记录」变成了「一棵按需计价的树」。
数字怎么读
以下数字均为论文口径：模型是 Qwen3.8-2.4T；单次 rollout 约 70 万 token；48 步训练把 NL2RepoBench 通过率从 52.5% 提到 58.5%，绝对提升 6.0%；48 步训练耗时从 134.55 小时降到 75.42 小时；相同 GPU 预算下，较 Colocate 方案加速 1.85 倍，较 Async 方案加速 1.78 倍。
NL2RepoBench 测的是「自然语言生成完整代码仓库」。52.5% 到 58.5%，乍看不是数量级跃迁，但它证明的事情很重要：在这类超长任务上，在线 RL 依然能把一个已经很强的旗舰模型再抬 6 个绝对百分点。基线已经站上 52.5%，越往上每一分都越贵，这个增益并不廉价。
更有工程含金量的是时间数字：134.55 小时降到 75.42 小时，省下近 60 小时。这 60 小时里模型没换、数据没换、奖励函数没换，省的全是调度与轨迹处理的收益。也就是说，在超长程负载下，系统工程层面的优化空间大到能与算法改进同台竞技。
两个被对比的基线方案也值得认识一下，因为它们代表了当前主流的两种资源组织方式。Colocate 是把采样和训练放进同一批 GPU，同一块卡在不同阶段切换角色——省机器，但角色切换粒度粗，长尾任务一来全卡陪绑；Async 则是采样与训练彻底分离、异步推进——不等慢轨迹，但参数更新与在途轨迹脱节，轨迹价值随时间衰减。QwenGyre 的 1.85 倍和 1.78 倍说明，弹性调度这条路确实同时跑赢了「一把梭的同步」和「放任自流的异步」两种传统方案，而且赢的幅度不小。
对手里没有 2.4T 参数模型的大多数团队，这组数字的意义在于方向：当你的 agent 任务开始以十万 token 计、以小时计时，调度和轨迹处理的优先级就该提前了，它们不是锦上添花的工程细节，而是决定训练能不能跑下去的地基。
场景、边界与值得盯的事
论文口径的应用场景有五类：自然语言生成完整代码仓库、已有仓库的长程软件工程、多轮终端自动化、大规模重构迁移、多智能体协作。共同特征很清晰：执行时间长、交互次数多、存在可检验的终点。凡是满足这三条的任务形态，都是这套框架的目标射程。
必须写明一条边界：QwenGyre 目前以论文形式发布，代码与安装包尚未公开（ai-bot.cn 报道口径）。想在 verl 等开源框架上复刻这套机制，要么等官方放出代码，要么照论文自行实现。而且弹性调度里几件硬骨头——RDMA 迁移 KV cache、cell 换岗时保留工具状态、卫星 cell 中途并批——工程门槛都不低，自己实现的成本要有心理准备。
后续值得盯三件事：一是代码是否会开源，这决定这套方案能否被社区验证和复用；二是换更小规模的模型，1.85 倍的加速比是否依然成立，弹性调度的收益和任务长度到底呈什么关系；三是 Partial Scoring 的可检验成果定义能否推广到代码之外的领域——评测器怎么写，决定了这套方法能吃下多大的任务面。
超长程 agent 的 RL 军备竞赛刚刚开场。QwenGyre 的价值不只是一个基准数字，而是把「训练基建怎么配得上模型能力」这个此前散落在各家内部实践里的问题，第一次摆成了完整的公开答卷。