L'équipe Qwen d'Alibaba a présenté QwenGyre, un framework d'apprentissage par renforcement (RL) élastique pour l'entraînement d'agents à horizon extrêmement long. QwenGyre est un système d'apprentissage par renforcement en ligne d'Alibaba qui entraîne des agents de codage via des harnaises boîtes noires non modifiées. Il cible des rollouts qui s'exécutent pendant des heures et traitent près de 1M de tokens. Le framework RL élastique QwenGyre a été utilisé sur le modèle phare de Qwen, Qwen 3.8 2.4T. Il repose sur 2 idées centrales. Il déplace les GPU inactifs entre le rollout et l'entraînement. Il transforme également les historiques d'agents ramifiés en échantillons d'entraînement bornés.
TL;DR
- Taille : Un framework d'entraînement, pas un modèle. Testé sur Qwen 3.6 122B et Qwen 3.8 2.4T (A95B selon Qwen), avec environ 700K tokens par rollout.
- Fonctionne sur : Clusters de GPU multi-nœuds. Les exécutions du 122B ont utilisé 24 à 32 nœuds ; l'exécution du 2.4T a utilisé 192 nœuds (4 cellules de 48). Modèle de GPU non divulgué. Megatron entraîne, SGLang sert les rollouts.
- Performance : 1,38x à 1,78x plus rapide qu'Async, 1,21x à 1,85x plus rapide que Colocate, à scores équivalents.
- Meilleur : Accélération de bout en bout de 1,85x par rapport à Colocate sur TerminalBench.
- Pire : Seulement 1,21x par rapport à Colocate sur le modèle 2.4T, où de nombreuses requêtes ont approché le délai d'expiration.
- En résumé :
- Meilleur : NL2RepoBench passe de 52.5% à 58.5% en 48 étapes.
- Pire : l'article ne renvoie vers aucune version publique du code.
Quel problème QwenGyre résout-il ?
L'équipe de recherche définit les tâches « XLong-horizon » comme des exécutions d'agents s'étendant sur des heures et des centaines d'interactions avec des modèles et des outils. Des exemples incluent la génération de dépôts complets à partir de spécifications, comme dans NL2Repo-Bench.
Deux problèmes apparaissent à cette échelle :
- Premièrement, les rollouts ont de longues traînées. Dans une configuration Colocate, l'entraînement attend l'exécution la plus lente pendant que les GPU restent inactifs. Dans une configuration Async, des pools de GPU fixes ne peuvent pas se prêter mutuellement leur capacité excédentaire.
- Deuxièmement, des harnaises comme Claude Code compaktent le contexte, créent des sous-agents et réessayent. Une seule exécution devient un arbre ramifié, et non une simple trajectoire. Développer chaque chemin duplique les préfixes partagés et gonfle le coût d'entraînement.
Comment fonctionne l'ordonnanceur Elastic ?
QwenGyre divise les GPUs en cellules qui partagent une disposition d'entraînement. Chaque cellule peut servir des rollouts ou héberger un réplica d'entraînement complet. Une cellule cœur (core) possède les poids faisant autorité et l'état de l'optimiseur. Les cellules satellites rejoignent l'entraînement plus tard.
L'ordonnanceur suit un niveau d'eau de rollout : les exécutions en file d'attente et en cours. À mesure que les exécutions se terminent, les cellules basculent vers l'entraînement une fois que les cellules restantes peuvent encore servir tout le travail en cours. Les appels de modèle sont redirigés via un proxy, de sorte que le harnais continue de fonctionner.
Mécanismes clés :
- Les blocs de KV-cache migrent via RDMA lors de la redirection, réduisant le recalcul des préfixes.
- Les satellites récupèrent les poids du cœur via le Transfer Engine de Mooncake et rejoignent un lot en cours.
- L'entraînement en streaming permet aux cellules de réclamer des micro-pas à mesure que les données deviennent prêtes.
- Les changements de rôle ont pris en moyenne 8.52 s (rollout vers entraînement) et 3.46 s (entraînement vers rollout).
Comment le processeur de trajectoires construit-il les échantillons d'entraînement ?
Un proxy enregistre les identifiants de tokens exacts et les log-probabilités comportementales en utilisant token-in, token-out (TITO). Les appels sont stockés sous forme d'arbres de trajectoires à préfixe partagé.
- Notation partielle : Les exécutions arrivées à échéance sont tout de même notées sur leur espace de travail préservé. Les échecs des évaluateurs sont exclus, jamais traités comme une récompense nulle.
- Échantillonnage borné : Au maximum 5 trajectoires par exécution sont conservées, classées main > main-summary > sub-agent > sub-agent-summary.
- Déduplication : Les cibles partagées comptent pour une seule, et seuls les tokens générés par la politique sont entraînés.
- Pondération équitable : Les pertes sont moyennées au sein de chaque exécution, de sorte que les branches supplémentaires ne gonflent pas son poids.
Un plafond de 5 égalait les scores d'entraînement non plafonnés tout en réduisant le temps forward-backward de 25.2%. L'entraînement utilise un GSPO avec 16 rollouts par groupe.
Quelle est la vitesse de QwenGyre ? Résultats des benchmarks
Toutes les exécutions ont utilisé Claude Code 2.1.220 comme harnais, avec des budgets GPU égaux et une obsolescence (staleness) équivalente.
| Charge de travail (modèle) | vs Async | vs Colocate |
|---|---|---|
| NL2RepoBench (Qwen 3.6 122B, 48 étapes) | 1.42x à 1.53x | 1.36x à 1.47x |
| DeepSWE (Qwen 3.6 122B, 24 étapes) | 1.569x à 1.572x | 1.610x à 1.824x |
| TerminalBench (Qwen 3.6 122B, 24 étapes) | 1.383x à 1.430x | 1.809x à 1.849x |
| NL2RepoBench (Qwen 3.8 2.4T, 48 étapes) | 1.78x | 1.21x |
Sur le modèle 2.4T, QwenGyre a terminé 48 étapes en 75.42 heures. Async a pris 134.55 heures et Colocate 91.47 heures. Le taux de réussite à l'évaluation est passé de 52.48% à 58.54%.
Comment QwenGyre se compare-t-il aux autres frameworks RL agentiques ?
| Fonctionnalité | QwenGyre | veRL | AReaL | Agent Lightning |
|---|---|---|---|---|
| Développeur | Alibaba Qwen | ByteDance Seed + communauté | Tsinghua IIIS + Ant Group | Microsoft |
| Licence | Non divulgué | Apache-2.0 | Apache-2.0 | MIT |
| Placement des GPU | Cellules élastiques, bascule en cours de déploiement | Mappage flexible des périphériques, resharding par HybridEngine | Entièrement asynchrone | Non divulgué |
| Cadre d'évaluation en boîte noire | Oui, via un proxy | Non divulgué | Oui, via un échange de base_url | Oui, quasi aucun changement de code |
| Entraînement / déploiement | Megatron / SGLang | FSDP, Megatron / vLLM, SGLang | Megatron, FSDP, Archon / vLLM, SGLang | Non divulgué |
| Plus grande échelle annoncée | Qwen 3.8 2.4T | Modèles 671B | Non divulgué | Non divulgué |
| Accélération phare | Jusqu'à 1,85x par rapport à Colocate | Non divulgué | 2,77x par rapport au synchrone (v0.3) | Non divulgué |
| Code public | Non divulgué | Oui | Oui | Oui |
Les accélérations proviennent de la configuration propre à chaque projet et ne sont pas directement comparables.
Points clés à retenir
- QwenGyre déplace les GPU entre le rollout et l’entraînement sans interrompre les agents en cours d’exécution.
- Les arbres de trajectoires plafonnent les échantillons à 5 par exécution et entraînent une seule fois les préfixes partagés.
- Les exécutions expirées sont tout de même évaluées sur leur travail partiel.
- Jusqu’à 1.85x plus rapide que Colocate et 1.78x plus rapide que Async.
- Qwen 3.8 2.4T NL2RepoBench est passé de 52.5% à 58.5% en 48 étapes.
Découvrez l’article complet de QwenGyre sur arXiv ainsi que la publication d’annonce de Qwen. Tout le crédit revient au chercheur de ce projet. N’hésitez également pas à nous suivre sur Twitter et n’oubliez pas de rejoindre notre 150k+ML SubReddit et de vous abonner à notre Newsletter. Attendez ! êtes-vous sur telegram ? vous pouvez désormais nous rejoindre également sur telegram.
L’article Alibaba Qwen présente QwenGyre : apprentissage par renforcement (RL) élastique pour les agents XLong-Horizon est applu pour la première fois sur MarkTechPost.