🤖 machine learning

Where Should RL Post-Training Compute Go? Model Size, Search, Learning, and Feedback

Cet article introduit un cadre de comptabilisation des FLOP et le protocole de diagnostic RACE pour démontrer que les stratégies optimales de post-entraînement par apprentissage par renforcement sous un budget fixe ne sont pas universelles mais dépendent d'une interaction complexe entre la taille du modèle, la profondeur de recherche, les mises à jour d'apprentissage et les mécanismes de rétroaction, incitant les chercheurs à rapporter les allocations de calcul détaillées plutôt que seulement le total des FLOP.

Auteurs originaux : Patrick Wilhelm, Odej Kao

Publié 2026-07-16

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Patrick Wilhelm, Odej Kao

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous soyez un chef tentant de créer la soupe la plus délicieuse du monde, mais que vous soyez limité par une consommation stricte d'électricité pour votre cuisinière. Vous pourriez dépenser cette électricité pour une marmite géante et coûteuse qui contient beaucoup de soupe à la fois, ou bien vous pourriez utiliser une plus petite marmite mais la remuer pendant des heures. Vous pourriez aussi dépenser de l'énergie pour goûter la soupe constamment afin de voir si elle a besoin de sel, ou pour hacher les légumes plus rapidement. Dans le monde de l'intelligence artificielle, et plus précisément lorsqu'on enseigne à des programmes informatiques comment réfléchir et résoudre des problèmes, les scientifiques sont confrontés à un casse-tête similaire. Ils disposent d'un « budget » fixe de puissance informatique (mesuré en une unité appelée FLOPs, qui est simplement un décompte du nombre de calculs mathématiques que l'ordinateur peut effectuer). La grande question est : si vous avez une quantité déterminée de puissance, où devez-vous la dépenser ? Devez-vous utiliser un cerveau plus gros et plus intelligent pour l'IA ? Devez-vous laisser l'IA faire plus de tentatives avant d'apprendre ? Ou devriez-vous consacrer plus de puissance à un « enseignant » qui évalue le travail de l'IA ? Se tromper dans ce dosage signifie que l'IA apprendra lentement ou pas du tout, même si vous disposez de beaucoup de puissance.

Cet article, intitulé « Where Should RL Post-Training Compute Go? », explore précisément cette question. Les auteurs, Patrick Wilhelm et Odej Kao, traitent l'énergie de l'ordinateur comme un budget limité qui doit être réparti entre trois éléments principaux : la recherche (laisser l'IA essayer de nombreuses réponses différentes), l'apprentissage (réellement mettre à jour le cerveau de l'IA sur la base de ces réponses) et le feedback (utiliser un programme distinct pour noter la qualité de ces réponses). Ils ont découvert qu'il n'existe pas de « meilleure » façon unique de dépenser l'argent. Au lieu de cela, la recette parfaite change selon la taille du cerveau de l'IA, le type d'enseignant qui la note, et le type de test que vous voulez que l'IA réussisse plus tard.

Les chercheurs ont découvert que dire simplement « nous avons utilisé 100 unités de puissance » ne suffit pas pour comprendre comment une IA a été entraînée. C'est comme dire qu'un chef a utilisé 100 watts d'électricité sans préciser s'il les a dépensés pour la cuisinière, le mixeur ou les lumières. Si vous avez un petit cerveau d'IA, vous pourriez obtenir les meilleurs résultats en dépensant la majeure partie de votre puissance pour la laisser essayer de nombreuses réponses (recherche). Mais si vous avez un cerveau géant et puissant, cette même quantité de puissance ne pourrait vous acheter que quelques essais, donc vous devrez peut-être consacrer davantage d'énergie aux étapes d'apprentissage effectives. Ils ont également découvert que l'« enseignant » compte énormément. Si l'enseignant est un vérificateur simple basé sur des règles (comme une clé de correction mathématique), presque toute la puissance est consacrée à l'essai de l'IA. Mais si l'enseignant est un autre programme d'IA complexe, une énorme partie du budget de puissance est absorbée par le travail de l'enseignant lui-même, laissant moins de place pour que l'IA étudiante apprenne.

L'article suggère que la « meilleure » façon d'entraîner une IA dépend entièrement de ce que vous cherchez à accomplir. Si vous voulez qu'elle obtienne un score élevé à un test d'entraînement spécifique, un certain mélange de recherche et d'apprentissage pourrait être optimal. Mais si vous voulez qu'elle résolve un problème totalement nouveau plus tard, un mélange différent pourrait être préférable. Pour aider les scientifiques à déterminer cela sans gaspiller des millions de dollars en essais, les auteurs ont introduit un outil appelé RACE. Considérez RACE comme un test de goût rapide et peu coûteux. Il exécute une expérience minuscule et à faible puissance pour deviner où se trouve le « point idéal » pour dépenser le budget, afin que les chercheurs sachent quels tests à grande échelle valent la peine d'être réalisés. Les auteurs précisent bien que ce n'est pas une garantie magique que l'IA deviendra plus intelligente ; c'est juste un outil de diagnostic pour les aider à choisir la bonne direction avant de s'engager pleinement dans leurs ressources.

En fin de compte, la principale conclusion est que « plus de puissance » n'est pas la seule réponse. Le mouvement le plus intelligent est d'être un comptable prudent. Que vous entraîniez un robot à marcher ou un ordinateur à résoudre des problèmes mathématiques, vous devez rapporter exactement comment vous avez réparti votre énergie entre la taille du cerveau, les tentatives d'entraînement et le système de notation. Car, comme le montrent les auteurs, la même quantité d'énergie peut acheter un type d'intelligence complètement différent selon la manière dont vous la dépensez.

Résumé Technique : Où l'apprentissage par renforcement (RL) doit-il allouer son calcul post-entraînement ?

Énoncé du Problème
L'apprentissage par renforcement (RL) post-entraînement est de plus en plus utilisé pour adapter les modèles de fondation au raisonnement, à la planification et aux pipelines d'apprentissage robotique pilotés par le feedback. Cependant, les analyses de mise à l'échelle actuelles résument généralement le coût de ces processus à l'aide d'une métrique agrégée unique : le nombre total de FLOPs. Ce document soutient qu'un tel rapport est sous-spécifié. Sous un budget de post-entraînement fixe, l'allocation de la puissance de calcul est un problème d'allocation de ressources contraintes impliquant quatre dimensions couplées :

Taille du Modèle : La capacité de la politique en cours d'entraînement.
Recherche/Rollout (Search/Rollout) : La génération de trajectoires candidates.
Apprentissage/Mises à jour (Learning/Updates) : L'optimisation par gradient de la politique.
Évaluation du Feedback/Récompense (Feedback/Reward Evaluation) : Le coût d'inférence des modèles de récompense ou des vérificateurs.

La question centrale abordée est la suivante : Sous un budget de FLOPs fixe, comment la puissance de calcul doit-elle être distribuée entre ces composants pour maximiser la performance ? Les auteurs postulent que les politiques plus grandes consomment plus de calcul par jeton (token), achetant ainsi moins de rollouts et d'étapes de mise à jour pour un même budget. De plus, l'introduction de mécanismes de feedback appris (par exemple, les modèles de récompense de processus ou PRM) introduit un nouveau coût de calcul qui entre en compétition avec les budgets de rollout et de mise à jour, un arbitrage occulté par le rapport des FLOPs totaux.

Méthodologie
L'étude introduit un cadre de comptabilité des FLOPs spécifiquement conçu pour le GRPO (Group Relative Policy Optimization) en post-entraînement. Le calcul total ( $C_{total}$ ) est décomposé en trois termes distincts :
$C_{total} = C_{search} + C_{learning} + C_{reward}$
Où :

$C_{search}$ : Génération autoregressive de rollouts.
$C_{learning}$ : Optimisation de la politique (tenant compte des paramètres de l'adaptateur LoRA et des coûts du backbone gelé).
$C_{reward}$ : Inférence de la récompense ou du vérificateur.

La variable d'allocation principale est la fraction de mise à jour ( $\rho$ ), définie comme le ratio du calcul d'apprentissage sur le calcul total. Les auteurs mènent des expériences utilisant des politiques Qwen2.5 adaptées par LoRA sur le jeu de données de raisonnement mathématique Polaris-53K. Le design expérimental comprend :

Étape A : Variation des tailles de modèles (1.5B, 3B, 7B) pour étudier l'allocation recherche-apprentissage.
Étape B & D : Comparaison de différents systèmes de récompense (parsemée, structurée, dense, proxy-PRM et PRM réelle) pour évaluer comment le coût du feedback déplace les frontières d'allocation.
Évaluation : Les métriques incluent la récompense native d'entraînement, la précision pass@1 en aval sur GSM8K et MATH-500, ainsi qu'un score de qualité de processus via un "juge commun".

Pour répondre au coût élevé d'une recherche exhaustive, les auteurs introduisent RACE (Reward-Aware Compute Allocation), un protocole de pilotage par grille de diagnostic. RACE exécute de petites grilles pilotes IsoFLOP pour estimer les réponses locales de l'allocation de la récompense et identifier si un paramétrage appartient à un régime "orienté recherche" (search-heavy), "orienté mise à jour" (update-heavy) ou "orienté récompense" (reward-heavy). Les auteurs précisent explicitement que RACE est un outil de diagnostic pour l'identification de régimes, et non une garantie d'amélioration sur des données non vues.

Contributions Clés

Cadre de comptabilité des FLOPs : Une décomposition formelle du calcul de post-entraînement par RL en composants de rollout, de mise à jour et d'évaluation de la récompense, permettant la comparaison de sessions qui sont mécanistiquement différentes malgré des FLOPs totaux identiques.
Couplage Taille du Modèle et Allocation : Preuve empirique montrant que le choix du modèle et l'allocation de l'entraînement sont inséparables. Sous un budget fixe, les politiques plus grandes achètent intrinsèquement moins de mises à jour et de rollouts, modifiant ainsi la frontière d'allocation optimale.
Dépendance à la Récompense et à la Cible : Démonstration que la "meilleure" allocation dépend du système de récompense (basé sur des règles vs PRM) et de la cible d'évaluation (récompense native vs précision en aval vs qualité de processus). Par exemple, le feedback basé sur un PRM déplace la fraction de mise à jour optimale ( $\rho$ ) vers le bas, car une partie du budget est consommée par l'inférence du modèle de récompense.
Protocole RACE : Une méthode de diagnostic pour identifier les régimes d'allocation via de petites grilles pilotes, destinée à guider les sessions de validation plutôt qu'à les remplacer.

Résultats

Frontières d'Allocation Conditionnelles : L'allocation optimale n'est pas un point fixe mais une frontière conditionnelle. Les configurations orientées recherche sous-utilisent la capacité d'apprentissage, tandis que les configurations orientées mise à jour deviennent limitées par l'exploration.
Impact du Système de Récompense : Les récompenses basées sur des règles (parsemées, structurées, denses) tendent à favoriser les régimes de mise à jour élevée ( $\rho \approx 0,72$ ). En revanche, le feedback de type PRM (proxy et réel) déplace la frontière de la récompense native vers des fractions de mise à jour plus faibles ( $\rho \approx 0,44–0,45$ ) car le budget fixe doit désormais couvrir l'inférence du modèle de récompense.
Désaccord des Cibles : Différentes cibles d'évaluation sélectionnent différentes allocations optimales.
- Récompense Native : Favorise l'allocation qui maximise le signal de feedback spécifique utilisé pendant l'entraînement.
- Pass@1 en Aval : Favorise souvent les régimes de mise à jour élevée (ex: le réglage $a180$ ) à travers les systèmes de récompense.
- Juge Commun : Présente souvent un pic dans les régimes de mise à jour intermédiaire (ex: $a100$ ) pour les récompenses denses et les PRM.
- Ce désaccord indique qu'une recette maximisant une métrique peut ne pas maximiser une autre.
Performance de RACE : RACE identifie avec succès le bon régime (mise à jour élevée vs faible) dans les contextes de validation avec une grande précision (taux de même régime de 1,0) mais ne garantit pas une amélioration globale de la récompense sur les données non vues par rapport aux bases de référence.

Signification et Revendications
Le papier affirme modestement que le post-entraînement par RL est un problème d'allocation de ressources contraintes plutôt qu'une simple loi d'échelle. Les auteurs soutiennent que le rapport des seuls FLOPs totaux masque les arbitrages mécanistes entre la capacité du modèle, la génération d'expérience et l'évaluation du feedback.

La signification réside dans la recommandation faite à la communauté de rapporter un calcul conscient de l'allocation : les FLOPs totaux accompagnés de la décomposition spécifique des FLOPs de rollout, de mise à jour et d'évaluation de la récompense, ainsi que la fraction de mise à jour $\rho$ résultante. Cette transparence est cruciale pour les systèmes d'apprentissage robotique, où l'amélioration d'un module de raisonnement ou de feedback via le post-entraînement par RL implique de décider s'il faut investir des ressources limitées dans des modèles plus grands, une recherche plus étendue ou des mécanismes de feedback plus puissants. Le papier conclut qu'il n'existe pas de "meilleure" recette universelle ; l'allocation optimale dépend conjointement de la taille du modèle, de la conception de la récompense et de la cible d'évaluation spécifique qui est optimisée.

Résumé Technique : Où l'apprentissage par renforcement (RL) doit-il allouer son calcul post-entraînement ?

Articles similaires