Gardez les jetons en circulation : leçons tirées de 16 bibliothèques RL open source

TL;DR -- Pour ceux d'entre vous qui n'ont pas le temps de lire 5 000 mots sur la plomberie asynchrone RL (nous comprenons, vous avez des modèles à former) :

• Le problème : dans la formation synchrone RL (apprentissage par renforcement), la génération de données (inférence de modèle pour créer des échantillons de données) domine le temps d'horloge : un seul lot de déploiements de 32 000 jetons sur un modèle 32 B (32 milliards de paramètres) peut prendre des heures, tandis que les GPU utilisés pour la formation restent inactifs.
• La solution sur laquelle tout le monde a convergé : désagréger (séparer) l'inférence et la formation sur différents pools de GPU, les connecter avec un tampon de déploiement (stockage temporaire pour les sorties du modèle) et transférer les poids de manière asynchrone (sans attendre), afin qu'aucune des parties n'attende l'autre.
• Nous avons étudié 16 bibliothèques open source qui implémentent ce modèle et les avons comparées sur 7 axes : primitives d'orchestration, conception de tampon, protocoles de synchronisation de poids, gestion de l'obsolescence, gestion du déploiement partiel, prise en charge de LoRA et backends de formation distribués.
• Principales conclusions : Ray domine l'orchestration (8 bibliothèques informatiques distribuées interrogées sur 16). La diffusion NCCL (NVIDIA Collective Communications Library) est la méthode par défaut pour transférer les poids des modèles. La gestion de l'obsolescence fait référence à la façon dont les échantillons de données obsolètes sont traités, allant de la simple suppression des anciens échantillons à l'utilisation d'une correction avancée de l'échantillonnage par importance. La formation LoRA (Low-Rank Adaptation) est peu prise en charge. Le support distribué du MoE (Mixture of Experts) est le différenciateur émergent.

Si vous préférez passer directement à la bonne partie, voici le tableau comparatif complet (aucune lecture requise, nous ne jugerons pas).

Mais sérieusement, si vous restez dans les parages, vous apprendrez peut-être une chose ou deux sur les raisons pour lesquelles vos GPU sont inactifs 60 % du temps.

• 1. Motivation : De la formation RL synchrone aux architectures asynchrones
  • 1.1 Comment TRL organise la formation RL aujourd'hui
  • 1.2 Formation colocalisée ou désagrégée
  • 1.3 Le goulot d'étranglement de la génération
  • 1.4 L'information fondamentale
• 2. Bibliothèques interrogées
• 3. Le cadre de comparaison : sept axes
  • Axe 1 : Primitive d'orchestration et de concurrence
  • Axe 2 : Conception du tampon de déploiement
  • Axe 3 : Protocole de synchronisation des poids
  • Axe 4 : Gestion de l'obsolescence
  • Axe 5 : Gestion du déploiement partiel
  • Axe 6 : Support à la formation LoRA
  • Axe 7 : Backend de formation distribué et parallélisme
• 4. Aperçu global : seize bibliothèques en un coup d'œil
• 5. La prochaine vague : implications en matière de conception
  • 5.1 Algorithmes sans critiques : mémoire libérée, mais la pression de synchronisation du poids augmente
  • 5.2 Récompenses de processus : une nouvelle barrière de synchronisation
  • 5.3 Coévolution multi-agents : le problème des retardataires s'aggrave
  • 5.4 Inadéquation formation-inférence : étude de cas Deepseek v3.2 MoE
  • 5.5 Distillation : le même problème asynchrone sous un nom différent
• 6. Choix de conception pour l'entraîneur asynchrone de TRL
  • Principe de conception : garder l'orchestration légère
  • 1. File d'attente délimitée avec par jetonmodèle_version(Pas de double tampon)
  • 2. Synchronisation du poids NCCL avec transferts emballés
  • 3. Prise en charge du déploiement partiel pour les charges de travail agentiques

1. Motivation : De la formation RL synchrone aux architectures asynchrones

La formation Async RL est devenue le paradigme dominant pour la post-formation à grande échelle. Plusieurs tendances de la post-formation moderne ont rendu les boucles de formation synchrones presque impossibles à mettre à l'échelle :

• Déploiements longs à partir de modèles de raisonnement. La formation en chaîne de pensée produit des déploiements très longs, et un seul lot de génération synchrone peut prendre des heures sur un seul GPU. Pendant tout ce temps, les GPU d’entraînement restent complètement inactifs.
• Les formateurs sans valeur et fonction comme GRPO utilisent les avantages relatifs au groupe. Cela signifie générer jusqu'à G fois plus de déploiements par invite, et l'ensemble du lot est contrôlé par l'achèvement le plus lent du groupe.
• L’essor de la formation RL agent. Lorsque les modèles interagissent avec des outils, des bacs à sable et des environnements externes sur des trajectoires multitours, les durées de déploiement et les latences deviennent très variables. Un simple appel d'API peut être renvoyé en quelques secondes, tandis qu'une chaîne de raisonnement complexe avec utilisation d'un outil peut durer des minutes ou des heures. Le framework Forge de MiniMax, utilisé pour entraîner MiniMax-M2.5, illustre l'ampleur que cela atteint dans la pratique : des longueurs de contexte allant jusqu'à 200 000 jetons, plus de cent mille échafaudages et environnements d'agents distincts et un débit quotidien de l'ordre de millions d'échantillons. À cette échelle, toute barrière synchrone entre la génération et la formation devient un sérieux goulot d’étranglement. Le seul problème des retardateurs (où une poignée de déploiements lents bloquent un lot entier) peut faire tourner des centaines de GPU au ralenti.

L'écosystème open source a convergé vers une réponse architecturale commune : désagréger l'inférence de la formation sur des pools GPU distincts, les connecter avec un tampon de déploiement et laisser les deux côtés s'exécuter simultanément.

Nous développons un nouvel entraîneur asynchrone pour TRL, l'une des bibliothèques les plus utilisées pour la post-formation de modèles. Pour guider notre conception, nous avons étudié seize bibliothèques open source construites à partir de zéro autour de la formation asynchrone et les avons comparées sur sept axes : primitives d'orchestration, conception de tampon, protocoles de synchronisation de poids, gestion de l'obsolescence, gestion du déploiement partiel, prise en charge de LoRA et backends de formation distribués. Cet article distille les principes de conception que nous avons extraits de cette enquête.

Au-delà de RL, le besoin d’une infrastructure asynchrone est de plus en plus évident. Par exemple, la distillation sur politique, où un élève génère des séquences et un enseignant les note, reflète le GRPO mais échange la fonction de récompense contre une passe avant de l'enseignant. Compte tenu de cette similitude structurelle, tout dans cette étude s'applique également à la distillation asynchrone. Nous reviendrons sur ce point plus large dans la section 5.

1.1 Comment TRL organise la formation RL aujourd'hui

TRL actuelFormateur GRPOimplémente la boucle GRPO complète (échantillonnage rapide, génération, notation des récompenses, calcul des avantages, mise à jour du gradient et synchronisation des poids) en un seul processus synchrone.étape_entraînement()appel. Cette conception est simple et correcte, mais elle ne peut pas chevaucher la génération et la formation, ce qui laisse de côté une utilisation importante du GPU.

En regardant leFormateur GRPO, nous avons les phases suivantes séquentiellement au sein de chaque étape de formation :

1. Échantillonnage d'invites : extrayez un lot d'invites à partir de l'ensemble de données. Rien de fou ici, continuons.
2. Génération, appelsmodèle.generate()(ou transmettre les requêtes à un serveur vLLM) pour produire des complétions G par invite. Ceci est autorégressif et domine le temps de l’horloge murale.
3. Notation des récompenses : évaluez chaque achèvement par rapport à une ou plusieurs fonctions de récompense.
4. Calcul des avantages
5. Passages avant et arrière : calculez la perte de gradient de politique écrêtée et rétropropagez.
6. Étape d'optimisation, mise à jour des poids du modèle.
7. Synchronisation des poids, transfert des poids mis à jour vers le moteur d'inférence (vLLM) afin que la prochaine génération utilise la nouvelle politique.

Chaque phase se bloque jusqu'à la fin avant que la suivante ne commence. La chronologie ressemble à ceci :

TRL propose leétapes_par_générationoption de configuration pour réutiliser un seul ensemble de déploiements sur plusieurs étapes de dégradé (réutilisation temporelle), amortissant ainsi le coût de génération. Mais l’appel de génération lui-même reste totalement synchrone et bloquant ; le formateur ne peut pas commencer le calcul du gradient tant que chaque achèvement du lot n'est pas terminé.

La bibliothèque prend également en charge l'exécution de vLLM dansserveurmode en tant que processus distinct. Cela libère le GPU d'entraînement pendant la génération, mais deux barrières de synchronisation strictes subsistent : les appels HTTP jusqu'au retour de toutes les achèvements, et la synchronisation du poids bloque à la fois l'entraîneur et le vLLM pendant le transfert.

1.2 Formation colocalisée ou désagrégée

Avant d'aborder la formation asynchrone, il est essentiel de comprendre les deux topologies de déploiement pour la formation RL avec un moteur d'inférence distinct :

• Le mode colocalisé place l'inférence et la formation sur le même ensemble de GPU. Un seul GPU (ou groupe TP) contient à la fois le modèle de formation (sous FSDP ou ZeRO) et le moteur d'inférence (vLLM ou SGLang). Un seul rôle est actif à la fois : pendant la génération, les paramètres du modèle de formation peuvent être déchargés ou repartagés dans une disposition conviviale pour l'inférence (par exemple, des fragments FSDP à la disposition tenseur parallèle de vLLM) ; pendant l'entraînement, le moteur d'inférence est mis en pause ou mis en veille. La « synchronisation » du poids est essentiellement gratuite ; il s'agit tout au plus d'un reharding sur place sur le même GPU, pas d'un transfert réseau. L’avantage du mode colocalisé est la simplicité et le coût ; vous avez besoin de moins de GPU au total. La limite fondamentale est que l’inférence et la formation ne peuvent pas se chevaucher. Par exemple, voici le Trl avec vllm danscolocaliser_mode:

• Le mode désagrégé place l'inférence et la formation sur des pools GPU distincts. Le pool d'inférence exécute vLLM ou SGLang en continu ; le pool de formation exécute l'optimiseur en continu. Les deux pools communiquent via un protocole de synchronisation de poids (diffusion NCCL, point de contrôle du système de fichiers, HTTP, etc.) et un mécanisme de transfert de données (magasin d'objets Ray, flux Redis, mémoire partagée, etc.)

Le plus grand avantage du mode désagrégé est que l’inférence et la formation peuvent s’exécuter simultanément. Pendant que le formateur calcule les gradients sur le lot N, le pool d'inférence génère déjà des déploiements pour le lot N+K, permettant un entraînement asynchrone. Cependant, cet avantage a un coût : des GPU supplémentaires sont nécessaires.

La concurrence, l'asynchronicité et le parallélisme sont des concepts distincts qui sont souvent confondus. Dans cet article, lorsque nous parlons de « formation asynchrone », nous entendons quelque chose de spécifique : la génération et la formation s'exécutant en parallèle, avec un chevauchement effectif ; le pool d'inférence produit le prochain lot de déploiements tandis que le pool de formation calcule les gradients sur le lot actuel. Il s’agit fondamentalement d’une capacité en mode désagrégé. Le mode colocalisé peut bénéficier d'optimisations telles que la gestion de la mémoire veille/réveil ou un repartitionnement rapide sur place pour accélérer l'inférence, mais il ne peut pas obtenir un véritable chevauchement simultané ; l'inférence et la formation se relaient toujours sur les mêmes GPU. Chaque bibliothèque de cette enquête qui implémente un chevauchement asynchrone significatif utilise le mode désagrégé comme base.

1.3 Le goulot d'étranglement de la génération

Dans la formation RL pour les modèles de raisonnement, la génération autorégressive domine le temps de l'horloge murale. Un seul déploiement pour une tâche mathématique ou de codage peut produire 8 000 à 64 000 jetons de raisonnement en chaîne de pensée (voir Longueurs des déploiements QED-Nano).

Pour concrétiser cela, considérez les benchmarks vLLM sur un seul GPU H100 de 80 Go (bf16, pas de quantification, mode de débit hors ligne). Un modèle 7B (DeepSeek-R1-Distill-Qwen-7B) atteint un débit global d'environ 6 300 jetons de sortie/s ; un modèle 32B (DeepSeek-R1-Distill-Qwen-32B) tombe à environ 1 200 jetons de sortie/s. Il s'agit du débit total pour toutes les requêtes simultanées, le nombre que le moteur d'inférence peut transmettre par seconde, quel que soit le nombre de séquences partageant le GPU.

Considérons maintenant une étape de formation GRPO typique : G = 8 achèvements par invite × 64 invites/lot = 512 déploiements. Combien de temps dure la génération ?

Même à court terme (2K tokens générés avec un modèle 7B), la génération à elle seule consomme plusieurs minutes par étape de formation. À long terme, où les modèles de raisonnement frontalier fonctionnent de plus en plus, une seule phase de génération peut prendre des heures sur un GPU. La mise à l'échelle vers 8 GPU d'inférence divise ces temps par environ ...
[Courte citation de 8% de l'article original]