Alibaba ha presentato QwenGyre, un framework di reinforcement learning progettato per ciò che il team di ricerca dell'azienda definisce addestramento di agenti "XLong-horizon": task in cui un singolo rollout può durare ore, implicare centinaia di interazioni tra il modello e il suo ambiente e consumare quasi un milione di token.

Il framework risponde a un cambiamento nel modo in cui vengono impiegati gli agenti LLM. Man mano che passano dalla risoluzione di singole issue di repository alla costruzione di intere codebase, le pipeline online RL convenzionali incontrano due ostacoli. Le durate dei rollout variano così ampiamente che le GPU restano inattive mentre un pugno di esecuzioni disperse termina, e i percorsi di esecuzione ramificati generano enormi volumi di dati di addestramento ridondanti. Con orizzonti misurati in ore e centinaia di migliaia di token, entrambi gli ostacoli si traducono direttamente in potenza di calcolo sprecata: hardware inattivo durante le code dei rollout e token duplicati aumentano il costo di ogni esecuzione di addestramento.

L'Elastic Scheduler punta all'underutilizzazione delle GPU

Il primo componente, l'Elastic Scheduler, affronta l'underutilizzazione delle GPU. I framework esistenti in genere fanno una di due cose: alternano un intero pool di GPU tra rollout e addestramento (colocate), lasciando l'hardware inattivo durante le lunghe code dei rollout, oppure partizionano staticamente le GPU tra le due fasi (async), impedendo a ciascun lato di sfruttare la capacità inutilizzata dell'altro. Ogni design scambia una forma di tempo di inattività con un'altra: l'approccio colocate lascia inattivo l'intero pool durante le code dei rollout, mentre l'approccio async blocca la capacità inutilizzata sul lato che non riesce a impiegarla.

QwenGyre, invece, organizza l'hardware in "celle" commutabili in modo indipendente che si riallocano tra infer e addestramento al variare del volume di lavoro di rollout non ancora completato. Le esecuzioni attive degli harness non vengono mai interrotte: le richieste al modello vengono reindirizzate a metà esecuzione verso i motori di rollout rimanenti, con le KV cache migrate via RDMA (remote direct memory access) per evitare di ripetere calcoli. Le celle liberate si aggiungono poi al passo di addestramento in corso come repliche data-parallel aggiuntive, recuperando i pesi autorevoli da una cella centrale, mentre l'addestramento in streaming distribuisce i micro-batch in base ai progressi di ciascun gruppo, in modo che tutte le celle terminino in sincronia.

Le transizioni di ruolo sono rapide. In media, il passaggio dal rollout all'addestramento richiede 8,5 secondi, e il ritorno 3,5 secondi — trascurabile rispetto a esecuzioni di rollout che durano ore.

Addomesticare le traiettorie ramificate

Il secondo componente, il Trajectory Processor, gestisce i dati di addestramento stessi. A orizzonti XLong, gli harness degli agenti compattano i contesti saturi, delegano i sotto-task a sotto-agenti e ritentano i percorsi falliti, così una singola esecuzione produce un albero ramificato di percorsi di contesto divergenti anziché una traiettoria lineare. Espandere ingenuamente ogni percorso duplica i prefissi condivisi e gonfia il costo di addestramento — un onere che cresce con i contesti di quasi un milione di token prodotti da queste esecuzioni.

QwenGyre, invece, ricostruisce l'esecuzione come un albero di traiettorie con prefissi condivisi, preservando il contesto di condizionamento originale esatto di ogni output del modello. Vengono addestrati solo i token effettivamente generati dalla policy, e i target condivisi vengono conteggiati una sola volta tramite masking sull'albero.

Anche i progressi parziali vengono valutati: le esecuzioni che raggiungono il timeout sono comunque valutate sul loro stato di workspace preservato, così i tentativi parziali portano reward significativi anziché essere scartati. Dato che una singola esecuzione può trattenere l'hardware per ore, questo recupero preserva un segnale che altrimenti andrebbe perso. All'ammissione all'addestramento, un numero limitato di traiettorie viene selezionato per esecuzione — con un tetto stabilito dalla priorità di ruolo: prima l'agente principale, poi i sotto-agenti, infine i percorsi di sintesi — e le loss sui token vengono mediate all'interno di ciascuna esecuzione, così che il numero di percorsi non possa distorcere la ponderazione.

Risultati dei benchmark

Applicato al modello di punta Qwen 3.8-2.4T di Alibaba, con circa 700K token per rollout, QwenGyre ha innalzato il tasso di superamento di NL2RepoBench dal 52,5% al 58,5% in 48 passi di addestramento, completandoli in 75,4 ore contro 134,6 ore della baseline async e 91,5 ore della baseline colocate — accelerazioni rispettivamente fino a 1,78× e 1,85×, ottenute mantenendo punteggi di addestramento pari alle baseline. I guadi si sono mantenuti costantemente su tutti e tre i workload valutati — NL2RepoBench, DeepSWE e TerminalBench — a parità di budget GPU.

Le quasi 60 ore recuperate rispetto alla baseline async sottolineano perché lo scheduling conta a questa scala: un tempo a muro più breve a parità di punteggio riduce il costo temporale di ogni ciclo di addestramento. Per chi valuta affermazioni simili su infrastrutture, i dettagli da notare sono le due condizioni allegata a questi numeri — punteggi di addestramento equivalenti e pari budget GPU — e il fatto che tutti i dati provengono da rollout di circa 700K token, il regime XLong per cui il framework è stato costruito.

Fonte: QwenGyre di Alibaba affronta il problema del milione di token con lo scheduling GPU elastico per l'RL XLong via Metaverse Post.