Am vorbit cu mulți oameni care lucrează la RL în ultima vreme și am observat ceva interesant — ori de câte ori conversația se îndreaptă spre RL Infrastructură, aproape întotdeauna se îndreaptă spre un singur subiect: alinierea train-inference. Cum să menții politicile de instruire și inferență consistente. Cum să controlezi gradul în afara politicii. Cum să gestionezi probabilitatea log după introducerea asincronului. Toate acestea sunt întrebări importante, fără îndoială. Dar sunt tot mai convins că RL Infra suferă de o alocare semnificativă greșită a atenției. Împrumutând o formulă dintr-o discuție recentă cu un coleg, numesc acest lucru Efectul Barrel al infrastructurii RL. Un butoi reține doar atâta apă cât cel mai scurt baston al său. Debitul și corectitudinea unui sistem de antrenament RL funcționează la fel — nu sunt determinate de modulul pe care l-ai optimizat cel mai mult, ci de cel pe care l-ai neglijat cel mai mult. Alinierea prin inferență a trenului ar putea fi bastonul pe care l-ai șlefuit și lustruit la perfecțiune. Dar dacă stabilitatea sandbox-ului este un dezastru, pipeline-ul de recompense se blochează constant, iar observabilitatea de la un capăt la altul este practic inexistentă — la ce bun alinierea perfectă? Capacitatea sistemului este deja limitată de toate celelalte verigi slabe. Acest lucru este fundamental diferit de modul în care funcționează optimizarea prin sistemul de inferență. Ca motor de inferență, SGLang dispune de un spațiu strategic enorm pentru optimizare, dar pipeline-ul său este relativ liniar — cerere de proces, preumplere, decodare. Poți izola blocajele modul cu modul, iar cuplajul dintre componente este gestionabil. Antrenamentul RL este cu totul altă poveste — un ciclu multi-sistem extrem de complex: generarea de implementări depinde de motorul de inferență, calculul de recompensă poate depinde de medii externe, actualizările de politici depind de cadrul de antrenament, iar următoarea rundă de implementări depinde de politica actualizată. Dacă orice legătură se rupe, întregul circuit se prăbușește. Din păcate, din ce am văzut în ultimul an, există încă multe puncte slabe grav subestimate: Fiabilitatea Agent Sandbox. Probabil aceasta este cea mai murdară, mai epuizantă și cea mai puțin spectaculoasă lucrare academică din infrastructura reală de astăzi. RL-ul bazat pe agenți are nevoie de un sandbox de execuție fiabil pentru implementări — sună simplu, dar se dovedește a fi un coșmar. Stabilitatea containerelor, latența la pornirea la rece, fiabilitatea izolării resurselor, managementul stării sandbox — aceste aspecte par decuplate pe hârtie, dar produsele sandbox disponibile pe piață performanță constant sub așteptări. Sandboxing-ul agenților nu este o problemă de algoritm, dar determină direct eficiența generării datelor, ceea ce la rândul său determină viteza de antrenament. Observabilitate. Depanarea pre-antrenamentului este relativ simplă — urmărește curba de pierdere, verifică norma gradientului și, de obicei, poți identifica problema. Dar depanarea RL necesită capabilități de urmărire end-to-end: distribuții de calitate a lansării, statistici de recompensă, grad off-policy, mărimi de actualizare a politicii și chiar atribuire a diferențialului logprob (diferența vine din partea inferenței sau din lag-ul de versiune al antrenamentului asincron?). Din păcate, majoritatea echipelor pe care le-am întâlnit zboară practic pe orb pe aceste dimensiuni. Acest lucru duce la o situație stânjenitoare — când rezultatele antrenamentului sunt slabe, nici măcar nu știi pe ce modul să dai vina. Dilema cu solzii. Multe optimizări RL Infra arată un impact măsurabil doar la scară suficientă. Experimentele la scară mică adesea nu arată nicio diferență semnificativă — nu pentru că optimizarea este inutilă, ci pentru că zgomotul este prea mare și numărul de pași prea mic pentru ca semnalul să iasă la suprafață. Totuși, experimentele la scară largă sunt prohibitiv de costisitoare. Acest lucru creează un cerc vicios: nu poți dovedi că optimizarea ta funcționează la scară mică, așa că nu poți asigura resursele pentru experimente la scară largă; Și fără o validare la scară largă, optimizarea ta rămâne mereu blocată la "teoretic ar trebui să ajute". Investiția industriei în infrastructura RL nu se potrivește grav cu complexitatea sa reală. Majoritatea echipelor tratează acest lucru ca pe un patchwork peste infrastructura de pre-training — ia un cadru de antrenament gata de utilizare, adaugă un motor de inferență, îl lipește împreună cu scripturi și îl numește RL Infra. Dar complexitatea sistemică a antrenamentului RL și pre-training nici măcar nu este la același nivel. Pipeline-urile de preantrenare sunt liniare, omogene și au practic zero dependențe externe. Canalele de antrenament RL sunt ciclice, eterogene și depind puternic de mediile externe. Aplicarea mentalității arhitecturale a primului la cea de-a doua este garantată să lovească un zid la scară largă. Adevărata dificultate în ingineria sistemelor nu este să împingi un singur modul la extrem — ci să înțelegi cuplajul dintre module și spațiul global al compromisurilor. Acest lucru este valabil pentru sistemele de inferență și cu atât mai mult pentru RL Infra, unde dimensiunile de cuplare sunt mai mari, buclele de feedback sunt mai lungi, iar densitatea informației pentru depanare este mult mai mică. Vreau să închei cu două întrebări la care m-am gândit și mi-ar plăcea să aud de la alții care lucrează în acest domeniu: Unde anume încep să scadă randamentele marginale ale alinierii cu inferența trenului? Odată ce async este introdus, gradul off-policy este deja substanțial. Pe această linie de bază, câștigul incremental din alinierea ulterioară este de fapt un ROI mai mare decât investiția aceluiași efort ingineresc în stabilitatea sandbox, optimizarea pipeline-ului de recompense sau infrastructura de observabilitate? Am propriul meu răspuns provizoriu, dar cred că această întrebare merită să fie gândită serios de mai mulți oameni — în loc să se întâmple ca prioritate principală alinierea doar pentru că este cel mai vizibil subiect. Și există un motiv pentru care este cel mai vizibil: alinierea prin inferență a trenului are o formalizare matematică clară și produce ablații elegante — este o potrivire naturală pentru lucrări. Dar cum scrii o lucrare despre stabilitatea sandbox-ului? Cum încadrați fiabilitatea orchestrării containerelor ca o poveste academică? Nu poți, de fapt. Așadar, aceste probleme sunt ignorate colectiv. Chiar dacă un sistem RL Infra obține alinierea inferenței trenului la nivel de bit, eficiența generală poate fi totuși slabă — deoarece blocajul s-a mutat în altă parte de mult timp. În ce măsură poate fi standardizat RL Infra? Sistemele de inferență au metrici de referință relativ bine definite — TTFT, TBT, Throughput. Acești indicatori obiectivi ne permit să evaluăm clar impactul optimizărilor. Dar care sunt standardele de evaluare pentru RL Infrastructure? Capacitatea de antrenament? Eficiența eșantionului? Timp de la ceas de perete de la un capăt la altul? Arhitectura optimă poate varia dramatic între scenarii (generare de cod vs. agent vs. raționament). Dacă nici măcar nu avem un consens despre cum arată "infrastructura RL bună", atunci cunoștințele inginerești în acest domeniu vor fi extrem de greu de acumulat și reutilizat. Dacă RL este calea critică pentru îmbunătățirea capabilităților modelului — această judecată este încă în evoluție. Dar dacă răspunsul este da, atunci Infrastructura este cel mai subestimat blocaj pe această cale. Nu pentru că nimeni nu lucrează la asta, ci pentru că atenția colectivă este alocată greșit. Cruzimea Efectului Butoi este aceasta: oricât de înalt ar fi toiagul tău cel mai înalt, nu poate salva sistemul. Infrastructura RL nu este o preocupare secundară. Este un domeniu independent, de mare complexitate, al ingineriei sistemelor. Doar tratându-l ca pe un cetățean de primă clasă vom avea vreo șansă să ajungem la scară reală.