阿里巴巴推出了QwenGyre，这是一个强化学习框架，专为该公司研究团队所称的“XLong-horizon”（超长时程）智能体训练而设计：在这类任务中，单次rollout可能运行数小时，涉及模型与环境之间的数百次交互，并消耗接近一百万token。

该框架回应了LLM智能体部署方式的转变。当它们从解决单个代码仓库问题升级到构建完整代码库时，传统的在线RL流水线会遭遇两大障碍。Rollout时长差异极大，导致GPU在少数滞后的执行完成前处于闲置状态；而分支化的执行路径会产生海量冗余训练数据。在以小时和数十万token衡量的时程下，这两个障碍都直接转化为算力浪费：rollout尾部的硬件闲置和重复token推高了每次训练的成本。

弹性调度器解决GPU利用率不足

第一个组件是弹性调度器（Elastic Scheduler），用于解决GPU利用率不足的问题。现有框架通常采取两种做法之一：在rollout和训练之间交替使用整个GPU池（colocate，共置模式），导致硬件在冗长的rollout尾部闲置；或在两个阶段之间静态划分GPU（async，异步模式），使任何一方都无法借用另一方的闲置算力。每种设计都是以一种闲置形式换取另一种——共置模式在rollout尾部闲置整个GPU池，而异步模式则把闲置算力锁在无法利用它的一方。

QwenGyre转而将硬件组织为可独立切换的“单元（cell）”，随着未完成rollout工作量的变化在推理与训练之间重新分配。运行中的任务执行不会被中断：模型请求在执行途中被重新路由到剩余的rollout引擎，KV缓存通过RDMA（远程直接内存访问）迁移，从而避免重复计算。释放出来的单元随后作为额外的数据并行副本加入正在进行的训练步骤，从核心单元拉取权威权重，同时流式训练根据各组的进度分发微批次，使所有单元同步完成。

角色切换非常迅速。平均而言，从rollout切换到训练需要8.5秒，切换回来需要3.5秒——相对于持续数小时的rollout执行而言可以忽略不计。

驯服分支化轨迹

第二个组件是轨迹处理器（Trajectory Processor），负责处理训练数据本身。在XLong时程下，智能体会压缩饱和的上下文、将子任务委派给子智能体，并重试失败的路径，因此单次执行会产生一棵由不同上下文路径构成的分支树，而非线性轨迹。简单地展开每条路径会重复共享前缀并推高训练成本——这一负担会随着这些运行产生的近百万token上下文而不断增长。

QwenGyre转而将执行重构为前缀共享轨迹树，保留每个模型输出精确的原始条件上下文。只有策略实际生成的token才会参与训练，共享目标通过树上的掩码机制只计算一次。

部分进展同样会被评分：达到超时限制的执行仍会根据其保留的工作区状态进行评估，因此未完成尝试也能获得有意义的奖励，而不是被直接丢弃。鉴于单次执行可能占用硬件数小时，这种恢复机制保留了原本会被丢弃的信号。在训练准入阶段，每次执行会选择数量有限的轨迹——按角色优先级设置上限，主智能体优先，其次是子智能体，最后是汇总路径——并且token损失会在每次执行内部取平均，从而避免路径数量扭曲权重。

基准测试结果

应用于阿里巴巴旗舰模型Qwen 3.8-2.4T（每次rollout约700K token）时，QwenGyre在48个训练步骤内将NL2RepoBench通过率从52.5%提升至58.5%，耗时75.4小时，而异步基线为134.6小时，共置基线为91.5小时——分别实现最高1.78倍和1.85倍的加速，同时达到与基线相同的训练得分。在同等GPU预算下，这一优势在所有三项评估工作负载——NL2RepoBench、DeepSWE和TerminalBench——中均保持稳定。

相比异步基线节省的近60个小时凸显了调度在这一规模上的重要性：在得分持平的情况下缩短实际耗时，降低了每个训练周期的时间成本。对于评估类似基础设施声明的读者而言，需要注意这些数字附带的两个条件——训练得分持平与同等GPU预算——以及所有数据均来自约700K token的rollout这一事实，这正是该框架所面向的XLong场景。

来源：Alibaba's QwenGyre Tackles The Million-Token Problem With Elastic GPU Scheduling For XLong RL，via Metaverse Post。