Alibaba heeft QwenGyre geïntroduceerd, een reinforcement-learningframework dat is ontworpen voor wat het onderzoeksteam van het bedrijf 'XLong-horizon'-agenttraining noemt: taken waarbij een enkele rollout uren kan duren, honderden interacties tussen het model en zijn omgeving omvat en bijna een miljoen tokens verbruikt.

Het framework reageert op een verschuiving in de manier waarop LLM-agenten worden ingezet. Nu ze van het oplossen van individuele repository-issues doorgroeien naar het bouwen van complete codebases, lopen conventionele online RL-pipelines tegen twee obstakels aan. De duur van rollouts varieert zo sterk dat GPU's inactief blijven terwijl een handvol trage uitvoeringen afloopt, en vertakkende uitvoeringspaden genereren enorme hoeveelheden redundante trainingsdata. Bij horizonten van uren en honderdduizenden tokens vertalen beide obstakels zich direct in verspilde rekenkracht: inactieve hardware tijdens rollout-staarten en gedupliceerde tokens verhogen de kosten van elke trainingsrun.

Elastic Scheduler richt zich op onbenutte GPU-capaciteit

De eerste component, de Elastic Scheduler, pakt de onderbenutting van GPU's aan. Bestaande frameworks doen doorgaans een van twee dingen: ze laten een hele GPU-pool afwisselen tussen rollout en training (colocate), waardoor hardware inactief blijft tijdens lange rollout-staarten, of ze verdelen de GPU's statisch tussen de twee fasen (async), waardoor geen van beide kanten de vrije capaciteit van de andere kan benutten. Elk ontwerp ruilt één vorm van inactieve tijd in voor een andere — de colocate-aanpak laat de hele pool inactief tijdens rollout-starten, terwijl de async-aanpak vrije capaciteit vastzet bij de kant die deze niet kan gebruiken.

QwenGyre groepeert hardware in plaats daarvan in onafhankelijk schakelbare 'cellen' die tussen inferentie en training worden herverdeeld naarmate het volume aan onafgerond rollout-werk verandert. Lopende harness-uitvoeringen worden nooit onderbroken: modelverzoeken worden tijdens de uitvoering omgeleid naar de overgebleven rollout-engines, waarbij KV-caches via RDMA (remote direct memory access) worden gemigreerd zodat geen enkele berekening herhaald hoeft te worden. Vrijgekomen cellen voegen zich vervolgens bij de lopende trainingsstap als extra data-parallelle replica's, halen de autoritatieve gewichten op uit een kerncel, terwijl streaming-training micro-batches verdeelt op basis van de voortgang van elke groep, zodat alle cellen gelijktijdig klaar zijn.

Rolwisselingen verlopen snel. Gemiddeld duurt de overstap van rollout naar training 8,5 seconden, en de terugweg 3,5 seconden — verwaarloosbaar vergeleken met rollout-uitvoeringen die uren duren.

Het temmen van vertakkende trajecten

De tweede component, de Trajectory Processor, verzorgt de trainingsdata zelf. Bij XLong-horizonten comprimeren agent-harnesses verzadigde contexten, delegeren ze subtaken aan sub-agenten en proberen ze mislukte paden opnieuw, zodat één uitvoering een vertakkende boom van uiteenlopende contextpaden oplevert in plaats van een lineair traject. Elk pad naïef uitbreiden dupliceert gedeelde prefixen en verhoogt de trainingskosten — een last die toeneemt met de bijna een miljoen tokens grote contexten die deze runs produceren.

QwenGyre reconstrueert de uitvoering in plaats daarvan als een prefix-gedeelde trajectboom, waarbij de exacte oorspronkelijke conditionele context van elke modeluitvoer behouden blijft. Alleen tokens die daadwerkelijk door het beleid zijn gegenereerd, worden gebruikt voor training, en gedeelde doelen worden slechts eenmaal geteld via masking op de boom.

Ook gedeeltelijke voortgang wordt beoordeeld: uitvoeringen die hun time-out bereiken, worden nog steeds geëvalue op basis van hun bewaarde werkruimtestatus, waardoor gedeeltelijke pogingen zinvolle beloningen opleveren in plaats van te worden weggegooid. Aangezien een enkele uitvoering urenlang hardware kan bezighouden, behoudt dat herstel signaalwaarde die anders verloren zou gaan. Bij de toelating tot training wordt per uitvoering een begrensd aantal trajecten geselecteerd — begrensd door rolprioriteit, met de hoofdagent eerst, daarna sub-agenten en vervolgens samenvattingspaden — en worden tokenverliezen binnen elke uitvoering gemiddeld, zodat het aantal paden de weging niet kan vertekenen.

Benchmarkresultaten

Toegepast op Alibaba's vlaggenschipmodel Qwen 3.8-2.4T met circa 700K tokens per rollout, verhoogde QwenGyre het slaagpercentage van NL2RepoBench van 52,5% naar 58,5% in 48 trainingsstappen, die werden afgerond in 75,4 uur tegenover 134,6 uur voor de async-baseline en 91,5 uur voor de colocate-baseline — versnellingen van respectievelijk tot 1,78× en 1,85×, behaald terwijl de baselinetrainingsscores werden geëvenaard. De winsten bleven consistent over alle drie de geëvalueerde workloads — NL2RepoBench, DeepSWE en TerminalBench — bij gelijke GPU-budgetten.

De bijna 60 uur die worden teruggewonnen ten opzichte van de async-baseline onderstreept waarom planning op deze schaal ertoe doet: kortere doorlooptijd bij gelijke scores verlaagt de tijdkosten van elke trainingscyclus. Voor lezers die vergelijkbare infrastructuurclaims afwegen, zijn de details om op te letten de twee voorwaarden die aan deze cijfers zijn verbonden — gelijke trainingsscores en gelijke GPU-budgetten — en het feit dat alle cijfers afkomstig zijn van rollouts van circa 700K tokens, het XLong-regime waarvoor het framework is gebouwd.

Bron: Alibaba's QwenGyre Tackles The Million-Token Problem With Elastic GPU Scheduling For XLong RL via Metaverse Post.