Alibaba a présenté QwenGyre, un cadre d'apprentissage par renforcement conçu pour ce que l'équipe de recherche appelle l'entraînement d'agents « XLong-horizon » : des tâches dans lesquelles un seul rollout peut s'exécuter pendant des heures, impliquer des centaines d'interactions entre le modèle et son environnement, et consommer près d'un million de tokens.

Le cadre répond à une évolution dans le déploiement des agents LLM. Alors qu'ils passent de la résolution de problèmes individuels de dépôt à la construction de bases de code entières, les pipelines RL en ligne conventionnels se heurtent à deux obstacles. Les durées de rollout varient tellement que les GPU restent inactifs tandis qu'une poignée d'exécutions retardataires se terminent, et les chemins d'exécution ramifiés génèrent d'énormes volumes de données d'entraînement redondantes. À des horizons mesurés en heures et en centaines de milliers de tokens, ces deux obstacles se traduisent directement en calcul gaspillé : le matériel inactif pendant les fins de rollout et les tokens dupliqués augmentent le coût de chaque entraînement.

Un ordonnanceur élastique contre la sous-utilisation des GPU

Le premier composant, l'Elastic Scheduler, s'attaque à la sous-utilisation des GPU. Les cadres existants font généralement l'une de deux choses : alterner tout un pool de GPU entre rollout et entraînement (colocate), laissant le matériel inactif pendant les longues fins de rollout, ou partitionner statiquement les GPU entre les deux étapes (async), ce qui empêche chaque côté d'emprunter la capacité libre de l'autre. Chaque conception échange une forme de temps d'inactivité contre une autre — l'approche colocate laisse tout le pool inactif pendant les fins de rollout, tandis que l'approche async verrouille la capacité libre du côté qui ne peut l'utiliser.

QwenGyre regroupe plutôt le en « cellules » commutables indépendamment, qui sont réaffectées entre l'inférence et l'entraînement à mesure que le volume de travail de rollout inachevé évolue. Les exécutions en cours ne sont jamais interrompues : les requêtes du modèle sont redirigées en plein vol vers les moteurs de rollout restants, avec des caches KV migrés via RDMA (accès direct à la mémoire à distance) afin qu'aucun calcul ne doive être répété. Les cellules libérées rejoignent ensuite l'étape d'entraînement en cours comme réplicas data-parallel supplémentaires, récupérant les poids faisant autorité depuis une cellule centrale, tandis que l'entraînement en flux distribue les micro-batches selon la progression de chaque groupe afin que toutes les cellules terminent en phase.

Les transitions de rôle sont rapides. En moyenne, le passage du rollout à l'entraînement prend 8,5 secondes, et le retour prend 3,5 secondes — négligeable face à des exécutions de rollout durant des heures.

Dompter les trajectoires ramifiées

Le second composant, le Trajectory Processor, traite les données d'entraînement elles-mêmes. Aux horizons XLong, les harnais d'agents compactent les contextes saturés, délèguent des sous-tâches à des sous-agents et réessayent les chemins échoués, de sorte qu'une seule exécution produit un arbre ramifié de chemins de contexte divergents plutôt qu'une trajectoire linéaire. Développer naïvement chaque chemin duplique les préfixes partagés et gonfle le coût d'entraînement — un fardeau qui croît avec les contextes de près d'un million de tokens que ces exécutions produisent.

QwenGyre reconstruit plutôt l'exécution sous forme d'arbre de trajectoires à préfixes partagés, en préservant le contexte de conditionnement original exact de chaque sortie du modèle. Seuls les tokens réellement générés par la politique sont entraînés, et les cibles partagées ne sont comptées qu'une seule fois grâce au masquage sur l'arbre.

Les progrès partiels sont également notés : les exécutions arrivées à leur délai d'expiration sont toujours évaluées sur leur état d'espace de travail préservé, de sorte que les tentatives partielles portent des récompenses significatives plutôt que d'être jetées. Étant donné qu'une seule exécution peut occuper le matériel pendant des heures, cette récupération préserve un signal qui serait sinon perdu. À l'admission à l'entraînement, un nombre limité de trajectoires est sélectionné par exécution — plafonné par priorité de rôle, avec l'agent principal d'abord, puis les sous-agents, puis les chemins de résumé — et les pertes de tokens sont moyennées au sein de chaque exécution afin que le nombre de chemins ne puisse fausser la pondération.

Résultats des benchmarks

Appliqué au modèle phare Qwen 3.8-2.4T d'Alibaba avec environ 700K tokens par rollout, QwenGyre a fait passer le taux de réussite de NL2RepoBench de 52,5 % à 58,5 % en 48 étapes d'entraînement, achevées en 75,4 heures contre 134,6 heures pour la base de référence async et 91,5 heures pour la base colocate — desélérations allant jusqu'à 1,78× et 1,85× respectivement, obtenues tout en égales les scores d'entraînement des bases de référence. Les gains se sont maintenus de manière constante sur les trois charges de travail évaluées — NL2RepoBench, DeepSWE et TerminalBench — à budgets GPU égaux.

Les près de 60 heures récupérées par rapport à la base async soulignent pourquoi l'ordonnancement compte à cette échelle : un temps horloge plus court à scores équivalents réduit le coût temporel de chaque cycle d'entraînement. Pour les lecteurs qui évaluent des affirmations d'infrastructure similaires, les détails à noter sont les deux conditions attachées à ces chiffres — scores d'entraînement égaux et budgets GPU égaux — et le fait que toutes les données proviennent de rollouts d'environ 700K tokens, le régime XLong pour lequel le cadre est conçu.

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