Jeg har snakket med mange som jobber med RL i det siste, og jeg har lagt merke til noe interessant — hver gang samtalen dreier seg om RL Infra, dreier den seg nesten alltid mot ett tema: tog-inferensjustering. Hvordan holde opplærings- og inferenspolitikkene konsistente. Hvordan kontrollere en off-policy grad. Hvordan håndtere log prob diff etter å ha introdusert asynk. Dette er alle viktige spørsmål, uten tvil. Men jeg er stadig mer overbevist om at RL Infra lider av en betydelig feilallokering av oppmerksomhet. Med en innramming fra en nylig diskusjon med en kollega, kaller jeg dette Barrel Effect of RL Infra. En tønne rommer bare så mye vann som sin korteste stav. Gjennomstrømningen og korrektheten i et RL-treningssystem fungerer på samme måte — de bestemmes ikke av modulen du har optimalisert mest, men av den du har neglisjert mest. Tog-inferensjustering kan være staven du har slipt og polert til perfeksjon. Men hvis stabiliteten i sandkassen din er en katastrofe, belønningspipelinen din stopper opp hele tiden, og din ende-til-ende-observabilitet er praktisk talt ikke-eksisterende — hva er vel godt med perfekt justering? Systemets kapasitet er allerede begrenset av alle andre svake ledd. Dette er fundamentalt annerledes enn hvordan optimalisering av inferenssystemer fungerer. Som en inferensmotor har SGLang et enormt strategirom for optimalisering, men pipelinen er relativt lineær — prosessforespørsel, prefill, dekoding. Du kan isolere flaskehalser modul for modul, og koblingen mellom komponentene er håndterbar. RL-trening er en helt annen sak — en marerittaktig kompleks multi-system-løkke: utrullingsgenerering avhenger av inferensmotoren, belønningsberegning kan avhenge av eksterne miljøer, policyoppdateringer avhenger av treningsrammeverket, og neste runde med utrullinger avhenger av den oppdaterte policyen. Hvis en enkelt lenke brytes, kollapser hele løkken. Dessverre, ut fra det jeg har sett det siste året, er det fortsatt mange sterkt undervurderte svake punkter: Agent Sandbox pålitelighet. Dette er sannsynligvis det skitneste, mest krevende og minst akademisk glamorøse verket i RL Infra i dag. Agentbasert RL trenger en pålitelig utførelsessandkasse for utrulling — høres enkelt ut, men viser seg å være et mareritt. Containerstabilitet, kaldstartsforsinkelse, pålitelighet i ressursisolasjon, sandkassetilstandsstyring — disse tingene virker frakoblet på papiret, men sandkasseproduktene på markedet leverer konsekvent under forventningene. Agent-sandboxing er ikke et algoritme-problem, men det bestemmer direkte datagenereringseffektiviteten din, som igjen bestemmer treningshastigheten din. Observabilitet. Feilsøking av forhåndstrening er relativt enkelt — følg med på tapkurven, sjekk gradientnormen, og du kan som regel finne problemet nøyaktig. Men feilsøking av RL krever ende-til-ende-sporingsmuligheter: utrullingskvalitetsfordelinger, belønningsstatistikk, off-policy-grad, policyoppdateringsstørrelser, og til og med attribusjon av logprob-diff (kommer diffen fra inferenssiden, eller fra asynkron trenings versjonsforsinkelse?). Dessverre flyr de fleste lagene jeg har møtt i praksis blindt på disse dimensjonene. Dette fører til en vanskelig situasjon — når treningsresultatene er dårlige, vet du ikke engang hvilken modul du skal skylde på. Skjelldilemmaet. Mange RL Infra-optimaliseringer viser kun målbar effekt i tilstrekkelig skala. Småskala eksperimenter viser ofte ingen meningsfull forskjell — ikke fordi optimaliseringen er ubrukelig, men fordi støyen er for høy og stegtallet for lavt til at signalet kan komme til overflaten. Likevel er storskala eksperimenter altfor dyre. Dette skaper en ond sirkel: du kan ikke bevise at optimaliseringen din fungerer i liten skala, så du kan ikke sikre ressursene til storskala eksperimenter; Og uten storskala validering sitter optimaliseringen din for alltid fast på «teoretisk sett burde det hjelpe.» Bransjens investering i RL Infra er sterkt misforenlig med dens faktiske kompleksitet. De fleste team behandler det som en i tillegg til forhåndstrening av infrastruktur — ta et ferdiglaget treningsrammeverk, feste på en inferensmotor, lime dem sammen med skript, og kalle det RL Infra. Men systemkompleksiteten i RL-trening og fortrening er ikke engang i samme liga. Fortreningsrørledninger er lineære, homogene og har praktisk talt ingen eksterne avhengigheter. RL-treningspipelines er sykliske, heterogene og sterkt avhengige av eksterne miljøer. Å anvende den arkitektoniske tankegangen til førstnevnte på sistnevnte vil garantert møte en vegg i stor skala. Den virkelige utfordringen i systemteknikk handler ikke om å presse en enkelt modul til det ytterste – det handler om å forstå koblingen mellom moduler og det globale kompromissrommet. Dette gjelder for inferenssystemer, og enda mer for RL Infra, hvor koblingsdimensjonene er større, tilbakekoblingssløyfene er lengre, og informasjonstettheten for feilsøking er langt lavere. Jeg vil avslutte med to spørsmål jeg har grublet på, og jeg vil gjerne høre fra andre som jobber i dette feltet: Hvor begynner egentlig de marginale utbyttene av tog-inferensjustering å avta? Når asynkron innføres, er off-policy-graden allerede betydelig. På dette grunnlaget, er den inkrementelle gevinsten fra videre justering faktisk høyere ROI enn å investere samme ingeniørinnsats i sandkassestabilitet, belønningspipeline-optimalisering eller observabilitetsinfrastruktur? Jeg har mitt eget foreløpige svar, men jeg mener dette spørsmålet fortjener seriøs ettertanke fra flere — i stedet for å gå til justering som høyeste prioritet bare fordi det er det mest synlige temaet. Og det er en grunn til at det er det mest synlige: tog-inferensjustering har ren matematisk formalisering og gir elegante ablasjoner — det passer naturlig for artikler. Men hvordan skriver man en artikkel om sandkassestabilitet? Hvordan rammer du inn container-orkestreringspålitelighet som en akademisk historie? Det kan du egentlig ikke. Så disse problemene blir kollektivt ignorert. Selv om et RL Infra-system oppnår bit-nivå toginferensjustering, kan den totale effektiviteten fortsatt være elendig — fordi flaskehalsen flyttet seg et annet sted for lenge siden. I hvilken grad kan RL Infra standardiseres? Inferenssystemer har relativt veldefinerte referansemålinger — TTFT, TBT, gjennomstrømning. Disse objektive indikatorene lar oss tydelig vurdere effekten av optimaliseringer. Men hva er evalueringsstandardene for RL Infra? Opplæringsgjennomstrømning? Prøveeffektivitet? Ende-til-ende veggklokketid? Den optimale arkitekturen kan variere dramatisk mellom scenarioene (kodegenerering vs. agent vs. resonnement). Hvis vi ikke engang har enighet om hvordan «god RL Infra» ser ut, vil ingeniørkunnskap innen dette feltet være ekstremt vanskelig å samle og gjenbruke. Om RL er den kritiske veien for å forbedre modellens kapasiteter — den vurderingen er fortsatt under utvikling. Men hvis svaret er ja, er infra den mest undervurderte flaskehalsen på den veien. Ikke fordi ingen jobber med det, men fordi kollektiv oppmerksomhet er feilallokert. Grusomheten i Barrel Effect er denne: uansett hvor høy din høyeste stav er, kan den ikke redde systemet. RL Infra er ikke en sekundær bekymring. Det er et uavhengig, høykomplekst systemingeniørområde. Bare ved å behandle den som en førsteklasses borger vil vi ha noen sjanse til å få RL til å skala.