Jag har pratat med många som jobbar med RL på sistone, och jag har märkt något intressant — när samtalet väl rör RL Infra dras det nästan alltid till ett ämne: tåg-inferens-alignment. Hur man håller utbildnings- och inferenspolicyn konsekventa. Hur man kontrollerar en off-policy-examen. Hur man hanterar log prob diff efter att ha infört asynkron. Det här är alla viktiga frågor, utan tvekan. Men jag är alltmer övertygad om att RL Infra lider av en betydande felfördelning av uppmärksamhet. Med en inramning från en nyligen diskuterad diskussion med en kollega kallar jag detta för Barrel Effect of RL Infra. Ett fat rymmer bara så mycket vatten som dess kortaste stav. Genomströmningen och korrektheten i ett RL-träningssystem fungerar på samma sätt – de bestäms inte av den modul du optimerat mest, utan av den du har försummat mest. Tåginferensjustering kan vara den stav du slipat och polerat till perfektion. Men om din sandlådestabilitet är en katastrof, din belöningspipeline stannar av hela tiden och din end-to-end-observabilitet är praktiskt taget obefintlig – vad är då perfekt alignment värd? Systemets kapacitet är redan begränsad av alla andra svaga punkter. Detta skiljer sig fundamentalt från hur optimering av inferenssystem fungerar. Som en inferensmotor har SGLang ett enormt strategiutrymme för optimering, men dess pipeline är relativt linjär — processförfrågan, prefill, avkodning. Du kan isolera flaskhalsar modul för modul, och kopplingen mellan komponenterna är hanterbar. RL-träning är en helt annan sak — en mardrömslikt komplex multisystem-loop: utrullningsgenerering beror på inferensmotorn, belöningsberäkningar kan bero på externa miljöer, policyuppdateringar beror på träningsramverket och nästa omgång av utrullningar beror på den uppdaterade policyn. Om någon enskild länk bryts kollapsar hela loopen. Tyvärr, utifrån vad jag sett under det senaste året, finns det fortfarande många allvarligt underskattade svaga punkter: Agent Sandbox-tillförlitlighet. Detta är förmodligen det smutsigaste, mest krävande och minst akademiskt glamorösa arbetet inom RL Infra idag. Agentbaserad RL behöver en pålitlig exekveringssandlåda för utrullningar – låter enkelt, men visar sig vara en mardröm. Containerstabilitet, kallstartslatens, resursisoleringstillförlitlighet, sandbox-tillståndshantering – dessa saker verkar frikopplade på papper, men sandlådeprodukterna på marknaden presterar konsekvent under förväntningarna. Agentsandboxing är inte ett algoritmiskt problem, men det bestämmer direkt din datagenereringseffektivitet, vilket i sin tur bestämmer din träningshastighet. Observerbarhet. Felsökning av förträning är relativt enkelt – titta på förlustkurvan, kontrollera gradientnormen, och du kan oftast lokalisera problemet. Men felsökning av RL kräver end-to-end-spårningsmöjligheter: utrullningskvalitetsdistributioner, belöningsstatistik, off-policy-grad, policyuppdateringsstorlekar och till och med attribuering av logprob-diff (kommer diffen från inferenssidan, eller från asynkron tränings versionsfördröjning?). Tyvärr flyger de flesta lag jag stött på i princip blinda på dessa dimensioner. Detta leder till en besvärlig situation – när träningsresultaten är dåliga vet du inte ens vilken modul du ska skylla på. Skaldilemmat. Många RL-infrastrukturoptimeringar visar endast mätbar påverkan i tillräcklig skala. Småskaliga experiment visar ofta ingen meningsfull skillnad – inte för att optimeringen är värdelös, utan för att bruset är för högt och stegantalet för lågt för att signalen ska kunna komma fram. Ändå är storskaliga experiment orimligt dyra. Detta skapar en ond cirkel: du kan inte bevisa att din optimering fungerar i liten skala, så du kan inte säkra resurser för storskaliga experiment; Och utan storskalig validering fastnar din optimering för alltid vid "teoretiskt borde det hjälpa." Branschens investering i RL Infra är allvarligt oförenlig med dess faktiska komplexitet. De flesta team behandlar det som en patch på ovanpå förträningsinfrastruktur – ta ett färdigt träningsramverk, koppla till en inferensmotor, limma ihop dem med skript och kalla det RL Infra. Men systemets komplexitet i RL-träning och förträning är inte ens i samma liga. Förträningspipelines är linjära, homogena och har praktiskt taget inga externa beroenden. RL-träningspipelines är cykliska, heterogena och starkt beroende av externa miljöer. Att tillämpa det arkitektoniska tankesättet från det förra på det senare är garanterat att stöta på en vägg i stor skala. Den verkliga svårigheten inom systemteknik handlar inte om att pressa en enskild modul till dess ytterlighet – utan om att förstå kopplingen mellan moduler och det globala kompromissutrymmet. Detta gäller för inferenssystem, och ännu mer för RL Infra, där kopplingsdimensionerna är större, återkopplingsslingorna längre och informationstätheten för felsökning är mycket lägre. Jag vill avsluta med två frågor som jag har funderat på, och jag skulle gärna vilja höra från andra som arbetar inom detta område: Var exakt börjar marginalavkastningen av tåg-inferensjustering att minska? När asynkron nivå införs är off-policy-examen redan betydande. Utifrån den baslinjen, är den inkrementella vinsten från ytterligare justering faktiskt högre ROI än att investera samma ingenjörsarbete i sandlådestabilitet, belöningsoptimering av pipelines eller observerbarhetsinfrastruktur? Jag har mitt eget preliminära svar, men jag tycker att den här frågan förtjänar seriös eftertanke från fler – istället för att man automatiskt ser alignment som högsta prioritet bara för att det är det mest synliga ämnet. Och det finns en anledning till att det är det mest synliga: tåg-inferensjustering har ren matematisk formalisering och ger eleganta ablationer — det passar naturligt för artiklar. Men hur skriver man en uppsats om sandlådestabilitet? Hur ramar man in container-orkestreringstillförlitlighet som en akademisk berättelse? Det kan du inte, verkligen. Så dessa problem ignoreras kollektivt. Även om ett RL Infra-system uppnår bitnivå-tåginferensjustering kan den totala effektiviteten ändå vara usel – eftersom flaskhalsen flyttade någon annanstans för länge sedan. I vilken utsträckning kan RL Infra standardiseras? Inferenssystem har relativt väl definierade benchmarkmått — TTFT, TBT, Throughput. Dessa objektiva indikatorer låter oss tydligt utvärdera optimeringarnas påverkan. Men vilka är utvärderingsstandarderna för RL Infra? Träningsgenomströmning? Proveffektivitet? Väggklockstid från början till ände? Den optimala arkitekturen kan variera dramatiskt mellan scenarier (kodgenerering vs. agent vs. resonemang). Om vi inte ens har en konsensus om hur "bra RL Infra" ser ut, kommer ingenjörskunskap inom detta område att vara extremt svår att samla på sig och återanvända. Om RL är den kritiska vägen för att förbättra modellens kapacitet – det omdömet är fortfarande under utveckling. Men om svaret är ja, då är infra den mest underskattade flaskhalsen på den vägen. Inte för att ingen arbetar med det, utan för att kollektiv uppmärksamhet är felfördelad. Grymheten i Barrel Effect är denna: oavsett hur hög din högsta stav är, kan den inte rädda systemet. RL Infra är inte en sekundär fråga. Det är ett oberoende, högkomplext systemingenjörsområde. Endast genom att behandla den som en förstklassig medborgare kommer vi ha någon chans att få RL att skala.