Ultimamente ho parlato con molte persone che lavorano su RL e ho notato qualcosa di interessante: ogni volta che la conversazione si sposta su RL Infra, si concentra quasi sempre su un argomento: l'allineamento tra addestramento e inferenza. Come mantenere coerenti le politiche di addestramento e inferenza. Come controllare il grado off-policy. Come gestire la differenza di log prob dopo aver introdotto l'asincronia. Queste sono tutte domande importanti, senza dubbio. Ma sono sempre più convinto che RL Infra stia soffrendo di una significativa cattiva allocazione di attenzione. Prendendo in prestito un inquadramento da una recente discussione con un collega, chiamo questo l'Effetto Barile di RL Infra. Un barile contiene solo tanta acqua quanto il suo staves più corto. La capacità e la correttezza di un sistema di addestramento RL funzionano allo stesso modo: non sono determinate dal modulo che hai ottimizzato di più, ma da quello che hai trascurato di più. L'allineamento tra addestramento e inferenza potrebbe essere lo stave che hai levigato e lucidato alla perfezione. Ma se la stabilità della tua sandbox è un disastro, il tuo pipeline di ricompensa si blocca costantemente e la tua osservabilità end-to-end è praticamente inesistente — a che serve un allineamento perfetto? La capacità del sistema è già limitata da ogni altro anello debole. Questo è fondamentalmente diverso da come funziona l'ottimizzazione dei sistemi di inferenza. Come motore di inferenza, SGLang ha un enorme spazio strategico per l'ottimizzazione, ma il suo pipeline è relativamente lineare: elaborazione della richiesta, prefill, decodifica. Puoi isolare i colli di bottiglia modulo per modulo, e il collegamento tra i componenti è gestibile. L'addestramento RL è una bestia completamente diversa: un loop multi-sistema complesso e da incubo: la generazione di rollout dipende dal motore di inferenza, il calcolo della ricompensa può dipendere da ambienti esterni, gli aggiornamenti delle politiche dipendono dal framework di addestramento, e il prossimo round di rollout dipende dalla politica aggiornata. Se un singolo collegamento si rompe, l'intero ciclo collassa. Sfortunatamente, da quello che ho visto nell'ultimo anno, ci sono ancora molti punti deboli gravemente sottovalutati: Affidabilità della Sandbox dell'Agente. Questo è probabilmente il lavoro più sporco, più faticoso e meno accademicamente glamour in RL Infra oggi. L'RL basato su agenti ha bisogno di una sandbox di esecuzione affidabile per i rollout — sembra semplice, ma si rivela un incubo. Stabilità del contenitore, latenza di avvio a freddo, affidabilità dell'isolamento delle risorse, gestione dello stato della sandbox — queste cose sembrano decouple sulla carta, ma i prodotti sandbox disponibili sul mercato sottoperformano costantemente le aspettative. Il sandboxing degli agenti non è un problema algoritmico, ma determina direttamente l'efficienza della generazione dei dati, che a sua volta determina la velocità di addestramento. Osservabilità. Il debug del pre-addestramento è relativamente semplice: osserva la curva di perdita, controlla la norma del gradiente, e di solito puoi individuare il problema. Ma il debug dell'RL richiede capacità di tracciamento end-to-end: distribuzioni di qualità dei rollout, statistiche delle ricompense, grado off-policy, magnitudini degli aggiornamenti delle politiche, e persino attribuzione della differenza di logprob (la differenza proviene dal lato dell'inferenza o dal ritardo della versione dell'addestramento asincrono?). Sfortunatamente, la maggior parte dei team che ho incontrato stanno essenzialmente volando alla cieca su queste dimensioni. Questo porta a una situazione imbarazzante: quando i risultati dell'addestramento sono scarsi, non sai nemmeno quale modulo incolpare. Il Dilemma della Scala. Molte ottimizzazioni di RL Infra mostrano un impatto misurabile solo a scala sufficiente. Esperimenti su piccola scala spesso non rivelano differenze significative — non perché l'ottimizzazione sia inutile, ma perché il rumore è troppo alto e il conteggio dei passaggi troppo basso perché il segnale emerga. Eppure, gli esperimenti su larga scala sono proibitivamente costosi. Questo crea un ciclo vizioso: non puoi dimostrare che la tua ottimizzazione funziona su piccola scala, quindi non puoi assicurarti le risorse per esperimenti su larga scala; e senza validazione su larga scala, la tua ottimizzazione rimane bloccata per sempre a "teoricamente dovrebbe aiutare." L'investimento dell'industria in RL Infra è gravemente disallineato con la sua reale complessità. La maggior parte dei team lo tratta come un lavoro di riparazione sopra l'infrastruttura di pre-addestramento — prendi un framework di addestramento pronto all'uso, aggiungi un motore di inferenza, incollali insieme con script e chiamalo RL Infra. Ma la complessità del sistema di addestramento RL e del pre-addestramento non sono nemmeno nella stessa lega. I pipeline di pre-addestramento sono lineari, omogenei e hanno praticamente zero dipendenze esterne. I pipeline di addestramento RL sono ciclici, eterogenei e fortemente dipendenti da ambienti esterni. Applicare la mentalità architettonica del primo al secondo è garantito che colpirà un muro su scala. La vera difficoltà nell'ingegneria dei sistemi non riguarda il portare un singolo modulo al suo estremo — riguarda la comprensione del collegamento tra i moduli e dello spazio di compromesso globale. Questo è vero per i sistemi di inferenza, e ancor di più per RL Infra, dove le dimensioni di accoppiamento sono maggiori, i loop di feedback sono più lunghi e la densità di informazioni per il debug è molto più bassa. Voglio chiudere con due domande su cui ho riflettuto, e mi piacerebbe sentire altri che lavorano in questo campo: Dove esattamente iniziano a diminuire i ritorni marginali dell'allineamento tra addestramento e inferenza? Una volta introdotta l'asincronia, il grado off-policy è già sostanziale. Su quella base, il guadagno incrementale da un ulteriore allineamento è realmente più ROI rispetto a investire lo stesso sforzo ingegneristico nella stabilità della sandbox, nell'ottimizzazione del pipeline di ricompensa o nell'infrastruttura di osservabilità? Ho la mia risposta provvisoria, ma penso che questa domanda meriti una seria riflessione da parte di più persone — piuttosto che ricorrere all'allineamento come priorità principale semplicemente perché è l'argomento più visibile. E c'è una ragione per cui è il più visibile: l'allineamento tra addestramento e inferenza ha una formalizzazione matematica pulita e produce ablazioni eleganti — è un abbinamento naturale per i documenti. Ma come scrivi un documento sulla stabilità della sandbox? Come inquadri l'affidabilità dell'orchestrazione dei contenitori come una storia accademica? Non puoi, davvero. Quindi questi problemi vengono collettivamente ignorati. Anche se un sistema RL Infra raggiunge un allineamento tra addestramento e inferenza a livello di bit, l'efficienza complessiva può ancora essere disastrosa — perché il collo di bottiglia si è spostato da qualche altra parte molto tempo fa. Fino a che punto può essere standardizzato RL Infra? I sistemi di inferenza hanno metriche di benchmark relativamente ben definite — TTFT, TBT, Throughput. Questi indicatori oggettivi ci permettono di valutare chiaramente l'impatto delle ottimizzazioni. Ma quali sono gli standard di valutazione per RL Infra? Throughput di addestramento? Efficienza dei campioni? Tempo totale end-to-end? L'architettura ottimale potrebbe variare drammaticamente tra scenari (generazione di codice vs. agente vs. ragionamento). Se non abbiamo nemmeno consenso su come appare "buona RL Infra", allora la conoscenza ingegneristica in questo campo sarà estremamente difficile da accumulare e riutilizzare. Se RL è il percorso critico per migliorare le capacità del modello — quel giudizio è ancora in evoluzione. Ma se la risposta è sì, allora Infra è il collo di bottiglia più sottovalutato su quel percorso. Non perché nessuno ci stia lavorando, ma perché l'attenzione collettiva è mal allocata. La crudeltà dell'Effetto Barile è questa: non importa quanto sia alto il tuo stave più alto, non può salvare il sistema. RL Infra non è una preoccupazione secondaria. È un dominio di ingegneria dei sistemi indipendente e ad alta complessità. Solo trattandolo come un cittadino di prima classe avremo qualche possibilità di far scalare RL.