Ik heb de laatste tijd met veel mensen gesproken die aan RL werken, en ik heb iets interessants opgemerkt — wanneer het gesprek over RL Infra gaat, draait het bijna altijd om één onderwerp: de afstemming tussen training en inferentie. Hoe houd je de trainings- en inferentiebeleid consistent. Hoe controleer je de off-policy graad. Hoe ga je om met log prob diff na het introduceren van async. Dit zijn allemaal belangrijke vragen, dat staat vast. Maar ik ben er steeds meer van overtuigd dat RL Infra lijdt onder een significante verkeerde toewijzing van aandacht. Door een kader te lenen van een recente discussie met een collega, noem ik dit het Barrel Effect van RL Infra. Een vat houdt slechts zoveel water als zijn kortste plank. De doorvoer en correctheid van een RL-trainingssysteem werken op dezelfde manier — ze worden niet bepaald door de module die je het meest hebt geoptimaliseerd, maar door degene die je het meest hebt verwaarloosd. De afstemming tussen training en inferentie kan de plank zijn die je tot in de perfectie hebt geschuurd en gepolijst. Maar als de stabiliteit van je sandbox een ramp is, je beloningspipeline constant vastloopt, en je end-to-end observability vrijwel niet bestaat — wat heb je dan aan perfecte afstemming? De capaciteit van het systeem is al beperkt door elke andere zwakke schakel. Dit is fundamenteel anders dan hoe optimalisatie van inferentiesystemen werkt. Als een inferentie-engine heeft SGLang een enorme strategie ruimte voor optimalisatie, maar zijn pipeline is relatief lineair — verwerk verzoek, prefill, decode. Je kunt knelpunten module voor module isoleren, en de koppeling tussen componenten is beheersbaar. RL-training is een totaal ander beest — een nachtmerrieachtig complexe multi-systeemlus: rollout generatie hangt af van de inferentie-engine, beloningsberekening kan afhankelijk zijn van externe omgevingen, beleidsupdates hangen af van het trainingsframework, en de volgende ronde van rollouts hangt af van het bijgewerkte beleid. Als een enkele schakel breekt, stort de hele lus in. Helaas, op basis van wat ik het afgelopen jaar heb gezien, zijn er nog steeds veel ernstig onderschatte zwakke punten: Agent Sandbox Betrouwbaarheid. Dit is waarschijnlijk het vuilste, meest slopende en minst academisch glamoureuze werk in RL Infra vandaag. Agent-gebaseerde RL heeft een betrouwbare uitvoeringssandbox nodig voor rollouts — klinkt eenvoudig, blijkt een nachtmerrie te zijn. Containerstabiliteit, cold start latentie, betrouwbaarheid van resource-isolatie, sandbox state management — deze dingen lijken op papier ontkoppeld, maar de sandbox-producten die op de markt beschikbaar zijn, presteren consequent onder de verwachtingen. Agent-sandboxing is geen algoritmeprobleem, maar het bepaalt rechtstreeks je efficiëntie van gegevensgeneratie, wat op zijn beurt je trainingssnelheid bepaalt. Observability. Debuggen van pretraining is relatief eenvoudig — kijk naar de verliescurve, controleer de gradientnorm, en je kunt meestal het probleem pinpointen. Maar debuggen van RL vereist end-to-end traceercapaciteiten: rollout kwaliteitsdistributies, beloningsstatistieken, off-policy graad, beleidsupdate-magnitudes, en zelfs toeschrijving van logprob diff (komt de diff van de inferentiekant, of van de versievertraging van async training?). Helaas zijn de meeste teams die ik ben tegengekomen in wezen blind aan het vliegen op deze dimensies. Dit leidt tot een ongemakkelijke situatie — wanneer de trainingsresultaten slecht zijn, weet je niet eens welke module je de schuld moet geven. De Schaal Dilemma. Veel RL Infra-optimalisaties tonen alleen meetbare impact bij voldoende schaal. Kleine experimenten onthullen vaak geen significante verschillen — niet omdat de optimalisatie nutteloos is, maar omdat de ruis te hoog is en het aantal stappen te laag voor het signaal om naar voren te komen. Toch zijn grootschalige experimenten prohibitief duur. Dit creëert een vicieuze cirkel: je kunt niet bewijzen dat je optimalisatie werkt op kleine schaal, dus kun je de middelen voor grootschalige experimenten niet veiligstellen; en zonder grootschalige validatie blijft je optimalisatie voor altijd vastzitten op "theoretisch zou het moeten helpen." De investering van de industrie in RL Infra is ernstig niet in overeenstemming met de werkelijke complexiteit. De meeste teams beschouwen het als een patchwerk bovenop pretraining infra — pak een kant-en-klaar trainingsframework, voeg een inferentie-engine toe, lijm ze samen met scripts, en noem het RL Infra. Maar de systeemcomplexiteit van RL-training en pretraining is niet eens in dezelfde league. Pretraining pipelines zijn lineair, homogeen, en hebben vrijwel geen externe afhankelijkheden. RL-training pipelines zijn cyclisch, heterogeen, en sterk afhankelijk van externe omgevingen. Het toepassen van de architecturale mindset van de eerste op de laatste is gegarandeerd om tegen een muur te lopen op schaal. De echte moeilijkheid in systeemengineering gaat niet over het duwen van een enkele module tot het uiterste — het gaat over het begrijpen van de koppeling tussen modules en de globale afwegingsruimte. Dit is waar voor inferentiesystemen, en nog meer voor RL Infra, waar de koppeling dimensies groter zijn, de feedbacklussen langer zijn, en de informatie dichtheid voor debugging veel lager is. Ik wil afsluiten met twee vragen waar ik over heb nagedacht, en ik zou graag van anderen in deze ruimte horen: Waar precies beginnen de marginale rendementen van de afstemming tussen training en inferentie te verminderen? Zodra async is geïntroduceerd, is de off-policy graad al aanzienlijk. Op die basis, is de incrementele winst van verdere afstemming daadwerkelijk hoger-ROI dan het investeren van dezelfde engineeringinspanningen in sandbox stabiliteit, beloningspipeline optimalisatie, of observability infrastructuur? Ik heb mijn eigen voorlopige antwoord, maar ik denk dat deze vraag serieuze overweging verdient van meer mensen — in plaats van standaard afstemming als de hoogste prioriteit te beschouwen, simpelweg omdat het het meest zichtbare onderwerp is. En er is een reden waarom het het meest zichtbaar is: de afstemming tussen training en inferentie heeft een schone wiskundige formalisatie en produceert elegante ablatie — het is een natuurlijke fit voor papers. Maar hoe schrijf je een paper over sandbox stabiliteit? Hoe kader je de betrouwbaarheid van containerorkestratie als een academisch verhaal? Dat kan je niet, echt. Dus worden deze problemen collectief genegeerd. Zelfs als een RL Infra-systeem bit-niveau afstemming tussen training en inferentie bereikt, kan de algehele efficiëntie nog steeds miserabel zijn — omdat de bottleneck ergens anders al lang geleden is verschoven. In hoeverre kan RL Infra worden gestandaardiseerd? Inferentiesystemen hebben relatief goed gedefinieerde benchmarkmetrics — TTFT, TBT, Doorvoer. Deze objectieve indicatoren stellen ons in staat om de impact van optimalisaties duidelijk te evalueren. Maar wat zijn de evaluatiestandaarden voor RL Infra? Trainingsdoorvoer? Monster efficiëntie? End-to-end wandklok tijd? De optimale architectuur kan dramatisch variëren tussen scenario's (code generatie vs. agent vs. redenering). Als we zelfs geen consensus hebben over hoe "goede RL Infra" eruit ziet, dan zal engineeringkennis in dit veld extreem moeilijk te accumuleren en hergebruiken zijn. Of RL de kritieke weg is voor het verbeteren van modelcapaciteiten — dat oordeel is nog steeds in ontwikkeling. Maar als het antwoord ja is, dan is Infra de meest onderschatte bottleneck op die weg. Niet omdat niemand eraan werkt, maar omdat de collectieve aandacht verkeerd is toegewezen. De wreedheid van het Barrel Effect is dit: ongeacht hoe hoog je hoogste plank is, het kan het systeem niet redden. RL Infra is geen secundaire zorg. Het is een onafhankelijke, hoog-complexe systeemengineeringdomein. Alleen door het als een eerste klas burger te beschouwen, hebben we enige kans om RL op te schalen.