🤖 machine learning

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

Dit artikel introduceert een FLOP-boekhoudraamwerk en het RACE-diagnostisch protocol om aan te tonen dat optimale RL post-training strategieën onder een vast budget niet universeel zijn, maar afhangen van een complexe wisselwerking tussen modelgrootte, zoekdiepte, leerupdates en feedbackmechanismen, wat onderzoekers ertoe aanzet om gedetailleerde rekenallocaties te rapporteren in plaats van enkel het totale aantal FLOPs.

Oorspronkelijke auteurs: Patrick Wilhelm, Odej Kao

Gepubliceerd 2026-07-16

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Patrick Wilhelm, Odej Kao

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een chef bent die de wereld'n lekkerste soep probeert te maken, maar je hebt een strikte limiet op hoeveel elektriciteit je keukenfornuis kan gebruiken. Je zou die elektriciteit kunnen uitgeven aan een enorme, dure pan die in één keer heel veel soep bevat, of je kunt een kleinere pan gebruiken maar er urenlang in roeren. Je zou energie kunnen besteden aan het constant proeven van de soep om te zien of er zout bij moet, of aan het sneller snijden van groenten. In de wereld van kunstmatige intelligentie, specifiek bij het aanleren van computerprogramma's om na te denken en problemen op te lossen, staan wetenschappers voor een vergelijkbaar puzzelstukje. Ze hebben een vast "budget" aan computerkracht (gemeten in een eenheid genaamd FLOPs, wat simpelweg een telling is van hoeveel wiskundige berekeningen de computer kan uitvourden). De grote vraag is: als je een bepaalde hoeveelheid kracht hebt, waar moet je die dan aan uitgeven? Moet je een groter, slimmer brein gebruiken voor de AI? Moet je de AI meer gissingen laten doen voordat hij leert? Of moet je meer kracht besteden aan een "leraar" die het werk van de AI beoordeelt? Deze balans verkeerd krijgen betekent dat de AI traag leert of zelfs helemaal niet leert, zelfs als je over voldoende kracht beschikt.

Dit artikel, getiteld "Where Should RL Post-Training Compute Go?", duikt precies in die vraag. De auteurs, Patrick Wilhelm en Odej Kao, behandelen de computerenergie als een beperkt budget dat verdeeld moet worden over drie hoofdzaken: search (het laten uitproberen van veel verschillende antwoorden door de AI), learning (het daadwerkelijk bijsturen van de AI-hersenen op basis van die antwoorden) en feedback (het gebruiken van een apart programma om te beoordelen hoe goed die antwoorden zijn). Ze ontdekten dat er niet één "beste" manier is om de middelen te besteden. In plaats daarvan verandert het perfecte recept afhankelijk van de grootte van het AI-brein, het type leraar dat het beoordeelt, en wat voor soort test je later met de AI wilt laten maken.

De onderzoekers ontdekten dat simpelweg zeggen "we hebben 100 eenheden kracht gebruikt" niet genoeg is om te begrijpen hoe een AI is getraind. Het is also wordt gezegd dat een chef 100 watt aan elektriciteit heeft gebruikt zonder te vertellen of hij die aan het fornuis, de blender of de lampen heeft uitgegeven. Als je een klein AI-brein hebt, krijg je misschien het beste resultaat door het grootste deel van je kracht te besteden aan het laten uitproberen van veel verschillende antwoorden (search). Maar als je een gigantisch, krachtig brein hebt, koopt diezelfde hoeveelheid kracht je misschien slechts een paar pogingen, dus moet je wellicht meer besteden aan de daadwerkelijke leerstappen (learning). Ze ontdekten ook dat de "leraar" veel uitmaakt. Als de leraar een eenvoudige regelgebaseerde controle is (zoals een antwoordmodel voor wiskunde), gaat bijna alle kracht naar het uitproberen van zaken door de AI. Maar als de leraar een ander complex AI-programma is, wordt een enorm deel van het krachtbudget opgeslokt door de leraar die zijn werk doet, waardoor er minder overblijft voor de student-AI om te leren.

Het artikel suggereert dat de "beste" manier om een AI te trainen volledig afhangt van wat je wilt bereiken. Als je wilt dat de AI een hoge score haalt op een specifieke oefentoets, kan een andere mix van search en learning het beste werken. Maar als je wilt dat hij later een compleet nieuw probleem oplost, is een andere mix misschien beter. Om wetenschappers te helpen dit uit te zoeken zonder miljoenen dollars te verspillen aan proefruns, introduceerden de auteurs een hulpmiddel genaamd RACE. Zie RACE als een snelle, goedkope smaaktest. Het voert een klein, laag-energetisch experiment uit om te raden waar het "optimale punt" ligt voor het besteden van het budget, zodat onderzoekers weten welke grootschalige experimenten de moeite waard zijn. De auteurs benadrukken voorzichtig dat dit geen magische garantie is dat de AI slimmer wordt; het is slechts een diagnostisch hulpmiddel om hen de juiste richting te wijzen voordat ze hun volledige middelen inzetten.

Uiteindelijk is de belangrijkste les dat "meer kracht" niet het enige antwoord is. De slimste zet is om een zorgvuldige boekhouder te zijn. Of je nu een robot traint om te lopen of een computer om wiskunde op te lossen, je moet precies rapporteren hoe je je energie hebt verdeeld tussen de hersengrootte, de oefenpogingen en het beoordelingssysteem. Want zoals de auteurs laten zien, kan dezelfde hoeveelheid energie een compleet ander soort intelligentie kopen, afhankelijk van hoe je het uitgeeft.

Technische Samenvatting: Waar moet de RL Post-Training Compute Naartoe?

Probleemstelling
Reinforcement Learning (RL) post-training wordt steeds vaker ingezet om foundation models aan te passen voor redeneren, planning en feedbackgestuurde robot-learning pipelines. De huidige schalingsanalyses vatten de kosten van deze processen echter doorgaans samen met één geaggregeerde metriek: het totaal aantal FLOPs. Dit paper betoogt dat dergelijke rapportage ondergespecificeerd is. Onder een vastgesteld post-training budget is de allocatie van compute een probleem van beperkte middelenallocatie waarbij vier gekoppelde dimensies betrokken zijn:

Modelgrootte: De capaciteit van het beleid (policy) dat getraind wordt.
Search/Rollout: De generatie van kandidaat-trajecten.
Learning/Updates: De gradiënt-gebaseerde optimalisatie van het beleid.
Feedback/Reward Evaluatie: De inferentiekosten van reward-modellen of verifiers.

De centrale vraag die wordt behandeld is: Hoe moet compute worden verdeeld over deze componenten onder een vastgesteld FLOP-budget om de prestaties te maximalen? De auteurs stellen dat grotere policies meer compute per token verbruiken, waardoor er onder hetzelfde budget minder rollouts en update-stappen beschikbaar zijn. Bovendien introduceert de introductie van geleerde feedbackmechanismen (bijv. Process Reward Models) een nieuwe computekost die concurreert met de budgetten voor rollout en updates, een trade-off die verborgen blijft door de rapportage van totale FLOPs.

Methodologie
De studie introduceert een FLOP-accounting framework specifiek voor GRPO (Group Relative Policy Optimization) post-training. De totale compute ( $C_{total}$ ) wordt ontleed in drie afzonderlijke termen:
$C_{total} = C_{search} + C_{learning} + C_{reward}$
Waarbij:

$C_{search}$ : Autoregressieve rollout-generatie.
$C_{learning}$ : Policy-optimalisatie (rekening houdend met LoRA-adapterparameters en de kosten van de bevroren backbone).
$C_{reward}$ : Reward of verifier inferentie.

De primaire allocatievariabele is de update fractie ( $\rho$ ), gedefinieerd als de ratio van de learning compute ten opzichte van de totale compute. De auteurs voeren experimenten uit met LoRA-geadapteerde Qwen2.5 policies op de Polaris-53K wiskundige redeneerdataset. Het experimentele ontwerp omvat:

Fase A: Het variëren van modelgroottes (1.5B, 3B, 7B) om de search-learning allocatie te bestuderen.
Fase B & D: Het vergelijken van verschillende reward-systemen (sparse, gestructureerd, dens, proxy-PRM, en echte PRM) om te beoordelen hoe de feedbackkosten de allocatie-frontiers verschuiven.
Evaluatie: De gebruikte metrieken zijn de native training reward, downstream pass@1 accuratesse op GSM8K en MATH-500, en een "common judge" proceskwaliteitsscore.

Om de hoge kosten van exhaustieve zoektochten aan te pakken, introduceren de auteurs RACE (Reward-Aware Compute Allocation), een diagnostisch pilot-grid protocol. RACE draait kleine IsoFLOP pilot-grids om de lokale reward-allocatie responsen te schatten en te identificeren of een instelling behoort tot een "search-heavy", "update-heavy" of "reward-heavy" regime. De auteurs stellen expliciet dat RACE een diagnostisch hulpmiddel is voor regime-identificatie, en geen garantie biedt voor verbetering op onbekende data (held-out improvement).

Belangrijkste Bijdragen

FLOP Accounting Framework: Een formele decompositie van RL post-training compute in rollout, update en reward-evaluatie componenten, wat de vergelijking mogelijk maakt tussen runs die mechanistisch verschillend zijn ondanks identieke totale FLOPs.
Gekoppelde Modelgrootte en Allocatie: Empirisch bewijs dat modelkeuze en training-allocatie onscheidbaar zijn. Onder een vast budget kopen grotere policies inherent minder updates en rollouts, wat de optimale allocatie-frontier verandert.
Reward- en Target-afhankelijkheid: Demonstratie dat de "beste" allocatie afhankelijk is van het reward-systeem (regelgebaseerd vs. PRM) en het evaluatie-target (native reward vs. downstream accuratesse vs. proceskwaliteit). Zo verschuift bijvoorbeeld PRM-gebaseerde feedback de optimale update fractie ( $\rho$ ) naar beneden omdat een deel van het budget nu wordt geconsumeerd door de reward-model inferentie.
RACE Protocol: Een diagnostische methode voor het identificeren van allocatie-regimes via kleine pilot-grids, bedoeld om validatieruns te begeleiden in plaats van ze te vervangen.

Resultaten

Conditionele Allocatie Frontiers: De optimale allocatie is geen vast punt maar een conditionele frontier. Search-heavy settings maken gebruik van minder learning capaciteit, terwijl update-heavy settings beperkt worden door exploratie.
Impact van het Reward-systeem: Regelgebaseerde rewards (sparse, gestructureerd, dens) neigen naar high-update regimes ( $\rho \approx 0.72$ ). Daarentegen verschuift de optimale native-reward frontier bij PRM-stijl feedback (zowel proxy als echt) naar lagere update fracties ( $\rho \approx 0.44–0.45$ ), omdat het vaste budget nu ook de reward-model inferentie moet dekken.
Discrepantie in Targets: Verschillende evaluatie-targets selecteren verschillende optimale allocaties.
- Native Reward: Bevoordeelt de allocatie die de specifieke feedback gebruikt tijdens de training maximaliseert.
- Downstream Pass@1: Bevoordeelt vaak high-update regimes (bijv. de $a180$ setting) over verschillende reward-systemen heen.
- Common Judge: Piekt vaak bij mid-update regimes (bijv. de $a100$ setting) voor dense en PRM rewards.
- Deze discrepantie geeft aan dat een recept dat één metriek maximaliseert, niet noodzakelijkerwijs een andere metriek maximaliseert.
RACE Prestaties: RACE identificeert succesvol het juiste regime (high vs. low update) in validatie-settings met een hoge nauwkeurigheid (1.0 same-regime rate), maar garandeert geen globale verbetering van de held-out reward ten opzichte van baselines.

Betekenis en Claims
Het paper claimt bescheiden dat RL post-training een beperkt middelenallocatieprobleem is in plaats van een eenvoudige scaling law. De auteurs beargumenteren dat het rapporteren van enkel de totale FLOPs de mechanistische trade-offs tussen modelcapaciteit, ervaring-generatie en feedback-evaluatie maskeert.

De significantie ligt in de aanbeveling aan de community om allocatie-bewuste compute te rapporteren: totale FLOPs naast de specifieke uitsplitsing van de rollout, update en reward-evaluatie FLOPs, en de resulterende update fractie $\rho$ . Deze transparantie is cruciaal voor robot-learning systemen, waarbij het verbeteren van een redeneer- of feedbackmodule via RL post-training de beslissing vereist of men beperkte middelen investeert in grotere modellen, uitgebreidere zoektochten of sterkere feedbackmechanismen. Het paper concludeert dat er geen universeel "beste" recept is; de optimale allocatie hangt gezamenlijk af van de modelgrootte, het reward-ontwerp en het specifieke evaluatie-target dat wordt geoptimaliseerd.

Technische Samenvatting: Waar moet de RL Post-Training Compute Naartoe?

Meer zoals dit