De 134 horas para 75: o truque de Qwen para treinar agentes

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: 134 Hours Down to 75: Qwen’s Agent Training Trick · Canal: Prompt Engineer 48 · 03:35 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA

Resumo

O vídeo apresenta um método de treinamento de agentes associado a Qwen, que reduziu de 134,55 para 75,42 horas o tempo de 48 etapas em um modelo de 2,4 trilhões de parâmetros. O método usa um escalonador elástico para diminuir o tempo ocioso das GPUs e processa trajetórias em árvore para evitar treinar repetidamente os mesmos tokens de prefixo. O ganho de velocidade depende da comparação: foi de 1,78 vez em relação ao modo assíncrono, enquanto o número de 1,85 vez veio de um benchmark com um modelo menor. O vídeo ressalta que o método exige muitos recursos de GPU, que os dados de treinamento são internos e que o modelo principal não foi lançado.

Pontos-chave

O treinamento envolve execuções de agentes que podem durar horas e gerar centenas de milhares de tokens.
No modo de execução conjunta, as GPUs aguardam a execução mais lenta antes de retomar o treinamento.
No modo assíncrono, as GPUs de treinamento podem ficar sem dados enquanto aguardam execuções longas.
O escalonador elástico divide o cluster em células que alternam entre execução e treinamento de forma independente.
As execuções ativas dos agentes não são interrompidas quando as células mudam de função.
O processador de trajetórias organiza chamadas do modelo em uma árvore de prefixos e evita contar prefixos compartilhados mais de uma vez.
Apenas tokens gerados pelo modelo são treináveis; system prompts e resultados de ferramentas servem como contexto.
No modelo de 2,4 trilhões de parâmetros, 48 etapas levaram 75,42 horas com o método, contra 134,55 horas no modo assíncrono e 91,47 horas no modo de execução conjunta.
O ganho de 1,85 vez foi medido no Terminal Bench com o modelo menor de 122 bilhões de parâmetros.
O método requer muitas células independentes; o modelo principal não foi lançado e os dados de treinamento são internos.

Capítulos

Início	Capítulo	Resumo
00:00	O problema das execuções longas de agentes	O vídeo apresenta o trabalho, os modelos e o custo de executar tarefas de agente que podem durar horas.
00:30	Ociosidade de GPUs e escalonamento elástico	Compara os modos de execução conjunta e assíncrono e explica como células independentes reduzem o tempo de espera.
01:32	Trajetórias em árvore e prefixos duplicados	Explica como o processador organiza as chamadas do agente e impede que tokens de prefixos compartilhados sejam treinados repetidamente.
02:34	Resultados e comparação dos ganhos	Apresenta os tempos das 48 etapas e esclarece que o ganho de 1,85 vez veio de outro benchmark e de um modelo menor.
03:04	Limitações e disponibilidade	O vídeo destaca as exigências de recursos, os dados internos e a indisponibilidade do modelo principal.

Citações

O treinamento caiu de 134 horas para 75. — 00:00

As execuções ativas dos agentes nunca são interrompidas. — 01:32

Isso é 1,78 vez mais rápido do que o modo assíncrono. — 02:34

A ideia é obter o mesmo aprendizado mais rápido, não aprender mais a cada etapa. — 03:04

Temos a ideia, não os pesos. — 03:35

Conceitos e entidades

Qwen (modelo): Família de modelos da Alibaba mencionada no vídeo no contexto do treinamento de agentes.
Alibaba (empresa): Empresa associada ao trabalho sobre treinamento de agentes apresentado no vídeo.
X-Long (conceito): Configuração de tarefas longas em que uma execução de agente pode envolver horas de interação e quase um milhão de tokens.
elastic scheduler (conceito): Escalonador que divide o cluster em células capazes de alternar independentemente entre execução de agentes e treinamento.
prefix tree (conceito): Estrutura usada para identificar prefixos compartilhados entre trajetórias e evitar treiná-los repetidamente.
NL2 Repo Bench (conceito): Benchmark citado para avaliar tarefas de construção de repositórios a partir de texto.
Terminal-Bench (conceito): Benchmark em que foi medido o ganho de 1,85 vez usando o modelo menor.
RunPod (empresa): Serviço de GPUs recomendado pelo apresentador em um anúncio no encerramento.

Tradução completa (pt-BR)

00:00 Certo, a Qwen treinou seu modelo de 2,4 trilhões de parâmetros em uma tarefa em que cada tentativa leva horas, e o tempo da execução de treinamento caiu de 134 horas para 75. Esse é o artigo que vocês podem ver aqui, da Qwen, da Alibaba. Mas atenção: não dá para executar isso no seu próprio sistema. São necessários muitos nós com GPU, mas o artigo explica por que os agents ficam melhores mais rápido. E um número do título não é o que parece. Vamos lá. Primeiro, o que é X-Long? No resumo, eles dizem que uma execução de agent pode durar horas, com centenas de

00:30 interações entre o modelo e o ambiente, e quase 1 milhão de tokens. Para o modelo de 2,4 trilhões, são cerca de 700 mil tokens por rollout. E, no modelo de 122 bilhões, a execução média no NL2 Repo Bench — criar um repo inteiro a partir de uma especificação em texto — leva cerca de 1,93 hora. Então, você treina um modelo deixando-o programar por 2 horas e depois avaliando-o. Problema número um: as GPUs ficam ociosas. Se você usa o modo co-localizado, todas as GPUs alternam juntas entre rollout e treinamento. Assim, o treinamento espera até que a execução mais lenta

01:01 termine. Aqui dá para ver algumas tarefas que ainda estão em andamento, enquanto o cluster inteiro fica esperando. Se você usa o modo assíncrono, divide as GPUs em um grupo fixo para rollout e outro fixo para treinamento. Aí, as GPUs de treinamento esperam pelos dados, porque um lote demora muito mais do que uma etapa de treinamento. E o grupo de rollout não pode pegar GPUs emprestadas. No modelo de 2,4 trilhões, 61% das consultas levam 4 horas ou mais. Então, esse tempo de espera é enorme. A solução deles é o escalonador elástico. Eles dividem o cluster em células, por exemplo, oito células com quatro nós cada. Cada célula alterna por conta própria.

01:32 Quando os rollouts terminam, uma célula passa para o treinamento, enquanto as outras continuam atendendo às execuções que ainda estão em andamento. O ponto principal é que as execuções de agent em andamento nunca são interrompidas. Até mesmo células novas entram em um lote de treinamento que já começou, e o treinamento transmite os dados à medida que os grupos terminam. No estudo de ablação deles, só o processamento em fluxo deu ao modo assíncrono cerca de 11,6%, e as células de granularidade fina deram 1,19 vez o resultado do modo co-localizado com processamento em fluxo. Problema número dois: essas execuções não seguem uma linha reta. O agent compacta seu contexto em um resumo. Ele inicia subagents. Tenta de novo. Então, uma

02:03 execução vira uma árvore. Se você treina com todos os caminhos, treina o mesmo prefixo compartilhado várias vezes. Em uma execução real deles, 636 solicitações se transformaram em 10 trajetórias candidatas. Isso gera muitos tokens duplicados e prejudica o treinamento. Então, o processador de trajetórias registra os tokens exatos de cada chamada do modelo e cria uma árvore de prefixos. Só os tokens que o modelo realmente gerou podem ser usados no treinamento. system prompts e resultados de ferramentas são apenas contexto. Depois, ele mantém no máximo cinco trajetórias por execução, priorizando primeiro o agent principal, depois o resumo e, por fim, os

02:34 subagents. E, depois que um prefixo compartilhado é usado no treinamento, ele é mascarado para contar apenas uma vez. Mais uma coisa: se uma execução atinge o limite de tempo, o trabalho já feito ainda é avaliado. O progresso parcial não é descartado. Agora, os números do modelo de 2,4 trilhões: 48 etapas levaram 75,42 horas com a Qwen, 134,55 horas no modo assíncrono e 91,47 horas no modo co-localizado. Isso é 1,78 vez mais rápido do que no modo assíncrono. Ou seja, cerca de 44% menos tempo. Mas, em comparação com o modo co-localizado, o ganho é de 1,21 vez, não 1,85.

03:04 O ganho de 1,85 é real, mas vem do Terminal Bench, no modelo menor, de 122 bilhões, e a pontuação no NL2 Repo Bench passou de 52,5% para 58,5% nessas 48 etapas: seis pontos. Mas atenção: o artigo diz que as pontuações de treinamento são comparáveis entre os métodos. Portanto, trata-se de obter o mesmo aprendizado mais rápido, não de aprender mais a cada etapa. Há limitações, e eles mesmos as apontam. São necessárias muitas células independentes, e configurações com menos GPUs não foram avaliadas. Com rajadas de várias etapas, eles não conseguem embaralhar

03:35 os dados por todo o lote. Todos os dados de treinamento são internos, e o modelo principal de 2,4 trilhões não foi lançado. Então, temos a ideia, não os pesos. Uma informação rápida: se você está procurando GPUs baratas e confiáveis, eu uso o RunPod, e o link está na descrição. Neste vídeo, vimos como a Qwen reduz o tempo de ociosidade das GPUs e os dados de treinamento duplicados. Confira o artigo; o link está na descrição. E me diga nos comentários: você confiaria em um número de aceleração sem uma referência de comparação? Até o próximo vídeo.

Transcrição original

[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.