The Pulse
QwenGyre riduce a 75 ore un addestramento di agenti in 48 passaggi
I ricercatori di Alibaba presentano QwenGyre, un framework di apprendimento per rinforzo che sposta capacità di calcolo tra i rollout degli agenti e l’addestramento. Su NL2RepoBench, il team riferisce di un’esecuzione durata 75,42 ore e di

AI.info Team · Scritto con l’IA ·
Ai guadagni di efficienza di QwenGyre si accompagna un’avvertenza, contenuta nello stesso studio: nel test più grande del team, la maggior parte delle query di cui è stata registrata la durata ha richiesto almeno quattro ore e più di un terzo di queste si è concluso con un timeout complessivo. Il framework, descritto in uno studio pubblicato su arXiv il 27 settembre, sposta capacità di calcolo tra le risposte degli agenti e l’addestramento del modello al variare dei carichi di lavoro. Gli autori riferiscono tempi di addestramento inferiori rispetto a due comuni metodi di pianificazione, ma i risultati provengono da esperimenti che richiedono molte risorse e riguardano un compito in cui i lunghi ritardi restano un problema caratterizzante.
Spostare capacità man mano che i rollout si concludono
L’apprendimento per rinforzo online alterna la generazione dei tentativi degli agenti, detti rollout, all’uso dei risultati ottenuti per aggiornare un modello. Nei compiti di programmazione lunghi, questi tentativi possono richiedere ore e avere durate molto diverse. Un pool condiviso che aspetta la conclusione di ogni tentativo può lasciare inattive risorse di calcolo; una ripartizione fissa tra rollout e addestramento può lasciare capacità inutilizzata da una parte mentre l’altra è in attesa.
Lo scheduler di QwenGyre sposta i nodi di calcolo tra i due ruoli senza interrompere le esecuzioni attive degli agenti. Quando la domanda di risorse per i rollout diminuisce, i nodi disponibili possono unirsi all’addestramento già in corso. Lo studio descrive anche un sistema di elaborazione delle traiettorie che ricostruisce cronologie ramificate, valuta il lavoro parziale dopo alcuni timeout e limita il numero di percorsi di ciascuna esecuzione che diventano esempi di addestramento.
«QwenGyre rialloca in modo elastico le GPU tra rollout e addestramento senza interrompere le esecuzioni in corso», scrivono gli autori di «QwenGyre: An Elastic Reinforcement Learning Framework for Training xLong-Horizon Agents».
Il risultato di 75 ore e il confronto su cui si basa
Per Qwen 3.8 2.4T su NL2RepoBench, i ricercatori riferiscono che QwenGyre ha completato 48 passaggi di addestramento in 75,42 ore. Async, che usa pool fissi separati per rollout e addestramento, ha impiegato 134,55 ore; Colocate, che alterna l’impiego di un pool condiviso tra i due compiti, ne ha impiegate 91,47. In quell’esperimento, QwenGyre è stato quindi 1,78 volte più veloce di Async e 1,21 volte più veloce di Colocate.
Negli stessi 48 passaggi, il tasso di superamento del modello nella valutazione NL2RepoBench è salito, secondo i dati riportati, dal 52,48% al 58,54%. Il confronto ha impiegato quattro celle da 48 nodi ciascuna per il modello 2.4T, per un totale di 192 nodi. Questo risultato è distinto dagli incrementi massimi di velocità rilevati nelle valutazioni più ampie dello studio: fino a 1,78 volte rispetto ad Async e a 1,85 volte rispetto a Colocate.
I percorsi ramificati aggiungono un altro costo all’addestramento
Le esecuzioni lunghe degli agenti non producono sempre una singola sequenza di azioni. Le infrastrutture di test usate negli esperimenti possono compattare le cronologie delle conversazioni, delegare il lavoro a sottoagenti e riprovare i percorsi falliti, generando prefissi condivisi e ramificazioni che sarebbero ridondanti se ogni percorso fosse trattato come un campione di addestramento separato.
QwenGyre registra le chiamate al modello in un albero, conserva il contesto originale di ogni output e conteggia una sola volta i target condivisi. Il limite predefinito è di cinque traiettorie di addestramento per esecuzione di rollout. I ricercatori hanno valutato il framework su NL2RepoBench, DeepSWE e TerminalBench; gli esperimenti con Qwen 3.6 da 122 miliardi di parametri hanno usato 32 nodi per NL2RepoBench e 24 per ciascuno degli altri due carichi di lavoro.
Restano i timeout e i vincoli di implementazione
Il maggiore incremento di velocità sul modello 2.4T è stato ottenuto rispetto ad Async, non a Colocate. Gli autori collegano il minore guadagno rispetto a Colocate alla lunga coda nella distribuzione delle durate delle query: quando molte esecuzioni si avvicinano al limite di timeout, lo scheduler ha meno occasioni per recuperare nodi in anticipo ed espandere il pool destinato all’addestramento. Tra le query con registrazioni complete della durata, il 61,1% ha richiesto almeno quattro ore; nel 38,2% di queste, il rollout più lungo si è concluso con un timeout complessivo.
Lo studio individua anche vincoli pratici. La pianificazione elastica richiede più gruppi di nodi commutabili in modo indipendente, ciascuno abbastanza grande da supportare il modello e la configurazione dell’addestramento: un requisito che, secondo gli autori, può rendere l’approccio impraticabile con budget ridotti. L’addestramento in streaming su più passaggi in una sequenza ravvicinata impedisce inoltre di mescolare globalmente tutti i minibatch prima del primo aggiornamento; lo studio afferma che l’effetto di questo ordine sulla qualità dell’apprendimento non è stato isolato.
Per ora, la prova più chiara a sostegno di QwenGyre è un’esecuzione di 48 passaggi su NL2RepoBench, durata 75,42 ore su 192 nodi, accompagnata da un aumento del tasso di superamento al 58,54%. Nell’esperimento dello studio sul modello più grande, le query che richiedono più di quattro ore restano la norma e una quota considerevole di esse termina con un timeout complessivo.