V poslední době mluvím s mnoha lidmi, kteří pracují na RL, a všiml jsem si něčeho zajímavého — kdykoli se rozhovor stočí k RL Infra, téměř vždy se to stočí k jednomu tématu: zarovnání vlakové inference. Jak udržet konzistentní školení a politiky inferencí. Jak kontrolovat titul mimo politiku. Jak řešit logaritmický pravděpodobnostní rozdíl po zavedení async. To jsou všechno důležité otázky, o tom nepochybuji. Ale jsem stále více přesvědčen, že RL Infra trpí výrazným špatným rozdělením pozornosti. Vypůjčujíc si rámec z nedávné diskuse s kolegou, nazývám to Barrel Effect of RL Infra. Sud pojme jen tolik vody, kolik má jeho nejkratší tyč. Propustnost a správnost RL tréninkového systému fungují stejně — nejsou určeny modulem, který jste nejvíce optimalizovali, ale tím, který jste nejvíce zanedbali. Vlakové zarovnání může být ta, kterou jste broušili a leštili k dokonalosti. Ale pokud je stabilita vašeho sandboxu katastrofa, odměňovací pipeline se neustále zastavuje a vaše end-to-end pozorovatelnost je prakticky nulová — k čemu je dokonalé zarovnání? Kapacita systému je už omezena všemi ostatními slabými články. To je zásadně odlišné od toho, jak funguje optimalizace inferenčních systémů. Jako inferenční engine má SGLang obrovský strategický prostor pro optimalizaci, ale jeho pipeline je relativně lineární — požadavky na proces, předvyplňování, dekódování. Můžete izolovat úzká místa modul po modulu a propojení mezi komponenty je zvládnutelné. Trénink RL je úplně jiná záležitost — noční můra složitá vícesystémová smyčka: generování rolloutů závisí na inferenčním enginu, výpočet odměn může záviset na externím prostředí, aktualizace politik závisí na tréninkovém frameworku a další kolo zavádění závisí na aktualizované politice. Pokud se přeruší jediné spojení, celá smyčka se zhroutí. Bohužel, z toho, co jsem za poslední rok viděl, stále existuje mnoho silně podceňovaných slabých míst: Agentní sandbox spolehlivost. Toto je pravděpodobně nejšpinavější, nejnáročnější a nejméně akademicky okázalá práce v RL Infra dnes. RL založené na agentech potřebuje spolehlivý sandbox pro spuštění — zní to jednoduše, ale nakonec je to noční můra. Stabilita kontejneru, latence studeného startu, spolehlivost izolace zdrojů, správa stavů sandboxu — tyto věci se na papíře zdají být oddělené, ale sandboxové produkty dostupné na trhu neustále zaostávají za očekáváními. Sandboxování agentů není problém algoritmu, ale přímo určuje efektivitu generování dat, což následně určuje rychlost tréninku. Pozorovatelnost. Ladění předtrénování je relativně jednoduché — sledujte křivku ztrát, zkontrolujte gradientní normu a obvykle dokážete problém přesně určit. Ale ladění RL vyžaduje end-to-end trasovací schopnosti: rollout kvalitní rozdělení, statistiky odměn, stupeň mimo politiku, velikost aktualizací politiky a dokonce i přiřazení logprob diff (pochází rozdíl ze strany inference, nebo z verzního zpoždění asynchronního tréninku?). Bohužel, většina týmů, které jsem potkal, v těchto dimenzích v podstatě létá naslepo. To vede k nepříjemné situaci — když jsou výsledky školení špatné, ani nevíte, který modul za to můžete. Dilema s váhou. Mnoho optimalizací RL Infra vykazuje měřitelný dopad pouze ve dostatečném měřítku. Malé experimenty často neodhalí žádný významný rozdíl — ne proto, že by optimalizace byla zbytečná, ale protože šum je příliš vysoký a počet kroků příliš nízký na to, aby se signál mohl objevit. Přesto jsou rozsáhlé experimenty neúnosně drahé. To vytváří začarovaný kruh: nemůžete dokázat, že vaše optimalizace funguje v malém měřítku, takže nemůžete zajistit zdroje pro rozsáhlé experimenty; A bez rozsáhlé validace je vaše optimalizace navždy uvězněna na "teoreticky by to mělo pomoci". Investice průmyslu do RL Infra je výrazně nevyrovnaná její skutečné složitosti. Většina týmů to bere jako záplatu navíc k předškolící infraze — vezměte si hotový tréninkový framework, přidáte inferenční engine, spojte je skripty a nazveme to RL Infra. Ale složitost systémů RL tréninku a předškolení není ani na stejné úrovni. Předtrénovací pipeline jsou lineární, homogenní a prakticky nemají žádné vnější závislosti. Tréninkové pipeline RL jsou cyklické, heterogenní a silně závislé na vnějším prostředí. Aplikace architektonického myšlení prvního na druhou zaručeně narazí na zeď ve velkém měřítku. Skutečná obtíž systémového inženýrství nespočívá v tlačení jednoho modulu do extrému — jde o pochopení propojení modulů a globálního prostoru kompromisů. To platí pro inferenční systémy, a ještě více pro RL Infra, kde jsou rozměry vazeb větší, zpětnovazební smyčky delší a informační hustota pro ladění je mnohem nižší. Chci zakončit dvěma otázkami, nad kterými jsem přemýšlel, a rád bych slyšel názory ostatních, kteří v této oblasti pracují: Kde přesně začínají klesat marginální výnosy z zarovnání vlakové inference? Jakmile je asynchronní systém zaveden, titul mimo politiku je již značný. Na tomto základním základě je přírůstek z dalšího sladění skutečně vyšší návratnost investice než investice stejného inženýrského úsilí do stability sandboxu, optimalizace pipeline nebo infrastruktury pozorovatelnosti? Mám svou vlastní předběžnou odpověď, ale myslím, že si tato otázka zaslouží vážnější zamyšlení od více lidí — místo toho, aby se sladění stavilo na nejvyšší prioritu jen proto, že je to nejviditelnější téma. A je důvod, proč je to nejviditelnější: zarovnání vlakové inference má čistou matematickou formalizaci a vytváří elegantní ablace — je to přirozené přizpůsobení pro články. Ale jak napsat článek o stabilitě sandboxu? Jak prezentovat spolehlivost orchestrace kontejnerů jako akademický příběh? Opravdu nemůžeš. Takže tyto problémy jsou kolektivně ignorovány. I když RL Infra systém dosáhne zarovnání train-inference na bitové úrovni, celková efektivita může být stále mizerná — protože úzké hrdlo se už dávno přesunulo jinam. Do jaké míry lze RL infrastrukturu standardizovat? Inferenční systémy mají poměrně dobře definované benchmarkové metriky — TTFT, TBT, Throughput. Tyto objektivní ukazatele nám umožňují jasně vyhodnotit dopad optimalizací. Ale jaké jsou hodnotící standardy pro RL Infra? Propustnost školení? Účinnost vzorků? Čas na stěnách od začátku do konce? Optimální architektura se může dramaticky lišit v různých scénářích (generování kódu vs. agent vs. uvažování). Pokud ani nemáme shodu na tom, jak vypadá "dobrá RL infrastruktura", pak bude inženýrské znalosti v této oblasti extrémně těžké získat a znovu využít. Zda je RL klíčovou cestou pro zlepšení schopností modelu — toto hodnocení se stále vyvíjí. Ale pokud je odpověď ano, pak je infrastruktura nejvíce podceňovaným úzkým hrdlem na této cestě. Ne proto, že by na tom nikdo nepracoval, ale protože kolektivní pozornost je špatně rozdělována. Krutost efektu sudu spočívá v tomhle: bez ohledu na to, jak vysoká je vaše nejvyšší hůl, systém nezachrání. RL infrastruktura není sekundární problém. Jedná se o nezávislou, vysoce složitou oblast systémového inženýrství. Pouze tím, že ho budeme považovat za občana první třídy, budeme mít šanci dosáhnout škálování reálného života.