The Qwen team published QwenGyre as arXiv 2609.33848, and its headline result is a wall-clock number rather than an accuracy score. Training an agent policy on the flagship Qwen 3.8 2.4T model for 48 steps took 75.42 hours under QwenGyre, against 134.55 hours for an asynchronous baseline and 91.47 hours for the colocated one, while the evaluation pass rate moved from 52.48% to 58.54%.
QwenGyre is a training framework, not a model and not a set of weights. It exists because the kind of agent work the Qwen team now trains on does not fit the scheduling assumptions of standard reinforcement learning.
The release
What shipped is a paper: arXiv 2609.33848, announced on 12 October 2026, listed under machine learning and distributed computing, with no accompanying code link. A search of GitHub's repository index for the name returns zero repositories, and the QwenLM organisation's public repository list does not include it, so the measurements below are the authors' own for now, produced with an RL adaptation of Group Sequence Policy Optimization.
The framing in the abstract claims up to 1.85x and 1.78x end-to-end speedups over the Colocate and Async baselines. The body of the paper is more specific, and the numbers there are what this article uses.
The xLong workload
The paper defines xLong as a single execution that spans hours, hundreds of dependent model-environment interactions, and roughly one million input and output tokens across its model calls. That token count includes repeated context at every request, so it can exceed the context limit of any individual call.
Measured on NL2RepoBench with Qwen 3.6 122B, mean duration was 1.93 hours per rollout execution and 2.96 hours per query, and 9.51% of queries took at least four hours. Overall timeouts ran at 0.87%. On the 2.4T model the tail is longer and the team extended the limit to accommodate it: 61.1% of queries with complete duration records took at least four hours, and in 38.2% of those the longest rollout ended in an overall timeout.
Those distributions are the reason the scheduling problem exists. A colocated setup alternates one GPU pool between rollout and training, and at these durations the pool cannot switch until the slowest execution finishes, so cards sit idle on a handful of stragglers. An asynchronous setup partitions the pool into fixed rollout and training halves, which prevents idling but also prevents either half from borrowing the other's spare capacity when its own stage has nothing to do. I would size a cluster for this workload from the tail rather than the mean, because the mean is two hours and the tail is what holds the whole training pool hostage.
The harness itself is part of the constraint. All three workloads ran inside Claude Code 2.1.220 manipulating files in containers, and the paper notes that the harness is a black box reached through a proxy: it offers no general way to checkpoint and resume a live execution, so a model call that cannot be served may stall or time out and change the task outcome for reasons unrelated to the policy's decisions. Preserving inference access for the whole execution is treated as a hard requirement rather than an optimization.
Elastic cells and the waterlevel
The resource unit is a cell, and cells share a training parallel layout. One cell is the core: it holds the authoritative weights and is the only owner of optimizer state. The rest are satellites, and any satellite can serve rollouts or pull the core's parameter snapshot and join the batch. Training runs on Megatron and rollout on SGLang, which the paper names because the role change has to re-shard parameters between them.
Scheduling is driven by a waterlevel, defined as the number of dispatched executions minus the number finished. A cell may leave rollout for training when the remaining rollout capacity still covers the outstanding executions and a supply check passes: at least a fixed fraction of the batch's ready, unassigned groups must be available for a set period before the transition starts. Cells change role serially, core first, then satellites in order, and they stay in training for the rest of the burst, so the training pool grows as a prefix of the cell list rather than jumping all at once — which is what lets training start on part of the cluster while rollouts continue on the rest.
The comparison against the baselines depends on a quantity the paper defines rather than assumes. Scheduling staleness is the difference between the policy version being trained and the version that was current when a group was dispatched, and all three methods were tuned to hit the same target mean. At a target of 1.5, Async runs one training step per burst with an extra-dispatch factor of 1.5, Colocate runs four steps per burst with no extra dispatch, and QwenGyre runs three steps with 0.5. That is what makes the run times comparable: a method can look faster by training on older data, and matched staleness removes that trade. I would check that constraint before accepting any speedup of this shape, because the framework is choosing where the wall-clock goes and the data budget is the thing it can quietly spend.
Two pieces of engineering make the change cheap enough to be worth doing. In-flight model calls are rerouted by the proxy while the harness, workspace, and tool state stay where they are, and the source cell pins its KV-cache blocks so the destination can read them over RDMA before the source releases them. Measured switching time was 8.52 seconds rollout-to-training and 3.46 seconds training-to-rollout, against executions that last hours. Training is streamed rather than batched: a trajectory buffer holds execution records by rollout group and a packing buffer turns selected paths into micro-steps that cells claim atomically as capacity appears, with a continuous one-forward-one-backward pipeline that runs one startup and one final drain per batch. Satellites joining an in-progress batch pull the core's weights through Mooncake's transfer engine over RDMA while gradients accumulate on a frozen snapshot, and the framework prebuilds one set of communication groups per cell prefix so a collective uses the set matching the cells that actually joined.
At the end of a burst, satellites return to rollout, restore their inference engines, and the core publishes updated weights. The core stays in training only if enough ready groups are available for the next batch and the remaining capacity covers the outstanding work plus the next dispatch.
Trajectory trees and partial credit
Recording what happened during a multi-hour execution is the second half of the problem. The proxy implements token-in token-out recording: for each model call it stores the exact input and output token IDs and the behavior log-probabilities, and it caches original tool-call payloads by call ID so that harness-side reformatting does not produce spurious history mismatches.
The records are organized into a trajectory tree per execution. Each node is one request record holding its incremental input, output, and metadata; an incoming request is matched against existing paths by its serialized context, only new content is encoded, and diverging contexts create branches. Compaction removes history from the harness's view, but each output keeps its original conditioning context in the tree, and sub-agent calls land as their own branches instead of being flattened into one sequence.
Not every token in that tree is a training target. Only tokens the policy generated during rollout are eligible; system prompts, user prompts, tool results, and assistant content the harness injects are masked and kept as context. Candidate trajectories are the leaves, and a single execution can produce many of them, sometimes far more than another execution in the same group. QwenGyre therefore caps the draw at five trajectories per execution by default and fills the budget in order of role priority: the main agent's task-driving trajectory first, then its summary trajectory, then a sub-agent's task trajectory, then a sub-agent's summary. Each draw masks the whole root-to-leaf path, so a shared prefix is never trained twice and its tokens are not double-weighted.
The cap is not cosmetic. Sampling only the main trajectory per execution produced lower training scores and larger gradient norms over the first 42 steps; a cap of five matched the scores obtained by sampling every available trajectory. Mean forward-backward time per step with caps of one and five came in at 41.4% and 74.8% of the uncapped baseline, so the cap of five buys back 25.2% of that time at comparable scores.
Rewards come from scoring the workspace an execution leaves behind, not from how it ended. An unfinished execution can receive a valid score if its completed work is assessable, and the data plane is explicit that rewards are not derived from elapsed time, trajectory length, or termination status. Each assessment stays attached to the execution, artifact version, and branch it evaluated. An evaluator failure leaves the assessment unresolved and can be retried within the execution's overall budget; an unresolved assessment is excluded from training and is treated as distinct from a valid zero. For complete failures with no assessable work, such as a container image that never pulled, the framework inserts a zero-reward placeholder trajectory.
Measured speedups
The end-to-end numbers come from three workloads, all with Qwen 3.6 122B except the flagship run, and all compared at matched mean scheduling staleness so that the baselines are not handicapped by a different data-dispatch policy. The RL recipe is the same across methods, which matters for reading the table: an adaptation of Group Sequence Policy Optimization with token importance weights capped at 5 and sequence-level clipping between 0.995 and 1.005, 16 rollout executions per group, 32 groups consumed per update on NL2RepoBench and 48 on the other two, a trajectory cap of 5, and Adam at a constant learning rate of 1e-6.
| Run | vs Async | vs Colocate |
|---|---|---|
| Qwen 3.8 2.4T, NL2RepoBench, 48 steps | 1.78x | 1.21x |
| Qwen 3.6 122B, NL2RepoBench, 48 steps | 1.42-1.53x | 1.36-1.47x |
| Qwen 3.6 122B, DeepSWE, 24 steps | 1.569x / 1.572x | 1.610x / 1.824x |
| Qwen 3.6 122B, TerminalBench, 24 steps | 1.383x / 1.430x | 1.809x / 1.849x |
The DeepSWE and TerminalBench rows show two values because they were run at two staleness targets, one and one and a half training steps; the 122B NL2RepoBench row is a range across the same two targets. The 122B runs used 32 nodes arranged in eight cells of four (24 nodes in six cells for DeepSWE and TerminalBench, with a per-cell inference concurrency of 192), and the 2.4T run used four cells of 48 nodes with a total inference concurrency of 384.
The smaller margin over Colocate on the flagship run has a stated cause. Its query durations cluster near the timeout limit, which leaves fewer opportunities for QwenGyre to reclaim cells early and expand training gradually, and it puts QwenGyre in the same position as Colocate, which also shares one pool between the two stages. Against Async the gap is wider for the opposite reason: Async's fixed partition keeps resources reserved for training even when training is idle, and reallocating those to rollout during long executions buys inference capacity that the baseline cannot use.
Every number here is a single lab measuring its own framework against baselines it implemented, and the paper does not report an independent reproduction. The evaluation follows each benchmark's prescribed protocol, with NL2RepoBench scored by a separate Qwen 3.7-Max evaluator against independently written tests and training data constructed internally for all three workloads.
Ablation paths
The ablation table separates the two mechanisms and shows that neither is sufficient alone. It runs 12 training steps on 32 nodes.
Adding streaming to Async cut time by 11.6%, but streaming on its own reaches only part of the available gain, because Async's fixed partition still cannot move idle GPUs. Moving nodes from training to rollout inside Async made things 7.7% slower, and lengthening training bursts made them 29.9% slower, since the fixed rollout pool could not feed them efficiently.
From the Colocate side, adding standalone rollout nodes bought just 2.9% over the original, and adding an independent switching capability while shrinking the pool that must switch together made the run 7.6% slower than the streaming version, because the longer training phase delayed the next dispatch. Replacing the fixed split with eight independently switching 4-node cells on top of streaming is where the gains land: 16.12 hours for the 12 steps, a 1.19x improvement over that intermediate configuration and the fastest configuration tested. Doubling cell size to eight nodes cost 2.2%, and dropping to one training step per burst cost 10.9% while still beating the equivalent Async configuration by 1.24x.
The paper also reports that in the fastest configuration, rollout fully hides training, with 20.85% of slack left over. That is a statement about this workload at this scale: once rollouts stop being the bottleneck, the same design has less room to recover time, and the team does not claim the ratios transfer to other harnesses, other models, or to trajectories short enough that a few minutes of GPU idling never mattered.
Harness timeouts are billed as normal work. On the 122B NL2RepoBench runs they hit 6.25% of executions, and those executions are still scored and used for training, which turns an hour of agent work that ran out of clock into a training signal instead of waste. Only an execution that exhausts its overall budget without producing an assessable artifact is dropped.
Loading comments…