134 Hours Down to 75: Qwen's Agent Training Trick

Author: Prompt Engineer 48 · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: 134 Hours Down to 75: Qwen’s Agent Training Trick · Channel: Prompt Engineer 48 · 03:35 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, AI models

Summary

The video explains how Qwen Jireh’s elastic scheduler reduces GPU idle time when training on long-running agent tasks, where a single rollout can take hours and involve hundreds of interactions. Instead of waiting for all tasks or keeping fixed rollout and training pools, the scheduler lets small groups of GPUs switch roles as work finishes, without interrupting active runs. A trajectory processor also removes duplicate shared prefixes and retains partial work from timed-out runs. The reported 2.4-trillion-parameter training run took 75.42 hours, compared with 134.55 hours for async training, while the video notes that the larger speed-up figure comes from a different benchmark and model size. The approach requires many independent GPU cells, and the flagship model and training data are not released.

Key points

Long agent rollouts can take hours and reach hundreds of thousands of tokens.
With collocated training, the cluster waits for the slowest rollout to finish.
With asynchronous training, fixed rollout and training pools can leave GPUs waiting for data.
The elastic scheduler divides the cluster into cells that switch between rollout and training independently.
Live agent runs are not interrupted, and cells can join a training batch already in progress.
Agent runs branch into multiple trajectories; training repeatedly on shared prefixes creates duplicate tokens.
The trajectory processor builds a prefix tree, trains only on tokens generated by the model, and masks shared prefixes after they are trained.
The system keeps at most five trajectories per run and preserves scored work when a run times out.
On the 2.4-trillion-parameter model, 48 steps took 75.42 hours with the proposed method, versus 134.55 hours async and 91.47 hours collocated.
The method needs many independent cells; smaller GPU budgets were not evaluated, and the flagship model is not released.

Chapters

Start	Chapter	Summary
00:00	Long agent runs and the GPU utilization problem	The video introduces X-Long rollouts and explains how collocated and asynchronous training can leave GPUs idle.
01:01	Elastic scheduling	The cluster is split into independently switching cells, while agent runs continue uninterrupted and training streams in as cells finish.
02:03	Removing duplicate trajectory tokens	A trajectory processor builds prefix trees, limits trajectories, masks already-trained shared prefixes, and retains partial work from timed-out runs.
03:04	Results and limitations	The video compares training times, clarifies which benchmark produced the 1.85× figure, and outlines the approach’s hardware and release limitations.

Quotes

the training run dropped from 134 hours to 75. — 00:00

the live agent runs, are never interrupted. — 01:32

one run becomes a tree. — 02:03

Partial progress is not thrown away. — 02:34

this is about getting the same learning faster, not smarter per step. — 03:04

Concepts and entities

Qwen, Alibaba, X-Long, elastic scheduler, prefix tree, NL2 Repo Bench, Terminal-Bench, RunPod

Full transcript (original language)

00:00 All right, Quan trained its 2.4 trillion parameter model on a task where one attempt takes hours and the training run dropped from 134 hours to 75. That is the paper you can see here, Quan Jiar from Alibaba. Now, mind you, you cannot run this on your own system. It needs a lot of GPU nodes, but it explains why agents get better faster. And one number in their headline is not what it looks like. Let’s go ahead. So, first, what is X-Long? In the abstract, they say one agent run can span hours, hundreds of

00:30 model and environment interactions, and nearly 1 million tokens. For their 2.4 trillion model, it is around 700,000 tokens per rollout. And on the 122 billion model, the average run on NL2 Repo Bench, building a whole repo from a text back, takes about 1.93 hours. So, you are training a model by letting it code for 2 hours and then scoring it. Problem number one, GPUs sit idle. If you use collocate, all the GPUs switch between rollout and training together. So, training waits until the slowest run

01:01 finishes. You can see here a few trailing tasks and the whole cluster is just waiting. If you use async, you split the GPUs into a fixed rollout pool and a fixed training pool. And now, the training GPUs wait for data because a batch takes way longer than a training step. And the rollout pool cannot borrow them. On the 2.4 trillion model, 61% of queries take 4 hours or more. So, that waiting is huge. Their fix is the elastic scheduler. They cut the cluster into cells, for example, eight cells of four nodes. Each cell switches on its

01:32 own. When rollouts finish, a cell flips to training and the other cells keep serving the runs that are still going. The key part, the live agent runs, are never interrupted. New cells even join a training batch that already started and training streams in as groups finish in their ablation. Streaming alone gave async about 11.6% and the fine-grained cells gave 1.19 times over streaming collocate. Problem number two, these runs are not a straight line. The agent compacts its contacts into a summary. It spawns sub agents. It retries. So, one

02:03 run becomes a tree. If you train on every path, you train on the same shared prefix again and again. In one of their real runs, 636 requests turned into 10 candidate trajectories. That is a lot of duplicate tokens and that is what cripples training. So, the trajectory processor records the exact tokens for every model call and builds a prefix tree. Only tokens the model actually generated are trainable. System prompts and tool results are just context. Then it keeps at most five trajectories per run, ranked main agent first, then its

02:34 summary, then sub agents. And once a shared prefix is trained, it is masked, so it counts one time. And one more thing, if a run times out, the work already done still gets scored. Partial progress is not thrown away. Now, the numbers on the 2.4 trillion model, 48 steps took 75.42 hours with Qwen Jireh, 134.55 for async, and 91.47 for Collocate. That is 1.78 times faster than async. So, about 44% less time. But against Collocate, it is 1.21 times, not 1.85.

03:04 The 1.85 is real, but it is from Terminal Bench on the smaller 122 billion model, and the score on NL2 Repo Bench went from 52.5 to 58.5% in those 48 steps, six points. Mind you, the paper says the training scores are comparable across methods. So, this is about getting the same learning faster, not smarter per step. Limits, and they say them themselves. It needs many independent cells and smaller GPU budgets were not evaluated. With multi-step bursts, they cannot shuffle

03:35 data across the whole batch. All the training data is internal, and the 2.4 trillion flagship is not released. So, we have the idea, not the weights. Quick one, if you’re looking for a cheap and reliable GPUs, I use RunPod, and the link is in the description. So, in this video, we have seen how Qwen Jireh cuts GPU idle time and duplicate training data. Check out the paper, link is in the description, and tell me in the comments, would you trust a speed-up number without a baseline? I’ll see you in the next one.