Riepilogo Tecnico: ROLLART

Problematica

L'Apprendimento per Rinforzo Agente (Agentic Reinforcement Learning - RL) addestra i Large Language Models (LLM) attraverso interazioni multi-turno con ambienti esterni. Questo paradigma introduce un carico di lavoro complesso ed eterogeneo che mescola quattro fasi distinte: rollout (generazione LLM), esecuzione dell'ambiente, valutazione della ricompensa e addestramento.

I sistemi esistenti non riescono ad affrontare l'eterogeneità delle risorse fondamentale intrinseca in queste fasi:

1. Eterogeneità della Generazione: La generazione LLM alterna la fase di prefill (compute-bound, dominante nei compiti a lungo contesto e multi-turno) alla fase di decoding (bandwidth-bound, dominante nei compiti a breve turno e con catene di pensiero lunghe). I sistemi attuali spesso assegnano il rollout a un singolo tipo di GPU, ignorando che le GPU ottimizzate per il calcolo (es. H800) eccellono nel prefill, mentre quelle ottimizzate per la larghezza di banda (es. H20) eccellono nel decoding.
2. Stragglers degli Ambienti: Gli ambienti sono processi stateful, limitati dalla CPU, soggetti a latenze a coda lunga dovute all'inizializzazione dei container (Docker pull), contesa di rete e variabili turni di interazione. In un'esecuzione batch, gli ambienti lenti bloccano l'intera pipeline.
3. Sottoutilizzo della Ricompensa: Il calcolo della ricompensa è spesso stateless e intermittente (bursty). Collocare la ricompensa con il rollout su GPU dedicate porta a un sottoutilizzo severo (fino al 7,4%), mentre accoppiarla con la generazione crea contesa di risorse.
4. Overhead di Sincronizzazione: L'addestramento sincrono tradizionale costringe i worker di rollout a rimanere inattivi mentre attendono la sincronizzazione dei pesi attraverso i cluster, creando "bolle di dipendenza" che sprecano costose risorse GPU.

Metodologia: ROLLART

ROLLART è un sistema distribuito progettato per l'RL agente multi-task su infrastrutture disaggregate. Mappa ogni fase della pipeline all'hardware più adatto alle sue specifiche caratteristiche e disaccoppia le fasi per eliminare i colli di bottiglia della sincronizzazione.

Requisiti Core di Design

Il sistema è guidato da quattro requisiti derivati empiricamente:

• R1 (Hardware-Affinity Mapping): Vincolare compiti o sottofasi specifiche all'hardware più adatto. I compiti pesanti in prefill vengono instradati verso GPU ottimizzate per il calcolo; i compiti pesanti in decoding verso GPU ottimizzate per la larghezza di banda; gli ambienti girano su cluster CPU; e le ricompense stateless girano su infrastrutture serverless.
• R2 (Asincronia a Livello di Traiettoria): Disaccoppiare generazione, interazione con l'ambiente e punteggio della ricompensa alla granularità delle singole traiettorie. Ciò garantisce che ambienti lenti o falliti non blocchino il progresso delle altre traiettorie.
• R3 (Offloading Serverless): Delegare il calcolo stateless della ricompensa a piattaforme serverless (es. Function Compute) per eliminare le GPU dedicate in standby e consentire una scalabilità elastica.
• R4 (Addestramento a Staleness Limitata): Eseguire l'addestramento e il rollout concorrentemente su separati cluster di GPU. Un protocollo a staleness limitata permette all'addestramento di procedere su policy leggermente più vecchie mentre il rollout continua, sovrapponendo la sincronizzazione dei pesi alla generazione per nascondere la latenza.

Architettura del Sistema

ROLLART consiste in tre piani:

1. Piano delle Risorse (Resource Plane): Un gestore di risorse traccia pool di hardware eterogenei (H800, H20, CPU, Serverless) e vincola i worker alle risorse in base alle affinità hardware dichiarate dall'utente tramite decoratori Python.
2. Piano dei Dati (Data Plane): Implementa la pipeline utilizzando le astrazioni Worker e Cluster. Incapsula la logica di esecuzione (es. vLLM per la generazione, Megatron per l'addestramento) e gestisce l'offloading di task stateless verso endpoint serverless.
3. Piano di Controllo (Control Plane): Orchestra il workflow senza intervento dell'utente. I componenti chiave includono:
   • LLMProxy: Distribuisce le richieste di generazione per traiettoria, disaccoppiando i client dai worker di inferenza.
   • EnvManager: Gestisce i cicli di vita dei singoli ambienti in modo indipendente, permettendo un progresso parallelo.
   • SampleBuffer: Bufferizza le traiettorie punteggiate per l'addestramento.
   • Protocollo di Addestramento Asincrono: Un processo di sincronizzazione in sei fasi (Get Batch → Suspend → Update → Resume → Recompute KV → Train) che sovrappone l'addestramento al rollout. Include un limite di staleness ($\alpha$) per interrompere le traiettorie troppo vecchie, garantendo la stabilità dell'addestramento.

Ottimizzazioni

• Rollout Ridondanti dell'Ambiente: Avvia più ambienti di quelli strettamente necessari per mascherare fallimenti e stragglers; le traiettorie in corso vengono terminate una volta raccolto il target batch.
• Disaggregazione Prefill-Decoding (PD): Raffina ulteriormente R1 instradando le fasi di prefill e decoding della stessa richiesta verso tipi di hardware differenti (ottimizzati per calcolo vs larghezza di banda).
• Trasferimento Pesi Asincrono: Utilizza uno store basato su Mooncake per spingere i pesi in modo asincrono. I worker di inferenza prelevano i pesi su richiesta, nascondendo la latenza di trasferimento cross-cluster dietro il rollout in corso.

Contributi Chiave

1. Infrastruttura Disaggregata per l'RL Agente: ROLLART è il primo sistema che affronta congiuntamente la divergenza prefill/decode, gli stragglers degli ambienti a coda lunga, il sottoutilizzo delle ricompense stateless e la variabilità della larghezza di banda cross-cluster su scala di produzione.
2. Modello di Programmazione Dichiarativa: Fornisce un'interfaccia unificata per dichiarare affinità hardware e delegare task stateless tramite decoratori, astraggendo la complessità della gestione delle risorse eterogenee.
3. Disaccoppiamento a Livello di Traiettoria: Introduce un design in cui le singole traiettorie progrediscono indipendentemente attraverso generazione, interazione con l'ambiente e ricompensa, eliminando le barriere di sincronizzazione a livello di batch.
4. Validazione su Scala di Produzione: Implementato con successo su un cluster Alibaba con oltre 3.000 GPU per addestrare un modello Mixture-of-Experts (MoE) con centinaia di miliardi di parametri per il prodotto Qoder, operando in modo continuo per una settimana.

Risultati

• Miglioramento del Throughput: ROLLART raggiunge un throughput 2,65–4,58× superiore rispetto a un baseline sincrono potenziato (Sync+).
• Riduzione del Tempo di Addestramento: Rispetto a vari baseline, ROLLART riduce il tempo di addestramento di:
  • 2,05× rispetto a un baseline sincrono potenziato (Sync+).
  • 1,35× rispetto a un baseline One-off.
  • 1,31× rispetto ad AReaL.
• Efficienza delle Risorse: L'offloading della ricompensa a infrastrutture serverless ha aumentato l'utilizzo della GPU per la ricompensa dal 6% all'88% e dimezzato il tempo di rollout per step.
• Scalabilità: Ha dimostrato una superiore efficienza di scaling su Qwen3-14B, fornendo un throughput da 1,33–2,08× superiore rispetto ai baseline all'aumentare della dimensione del cluster da 64 a 128 GPU.
• Trade-off della Staleness: È stato riscontrato che un limite di asincronia $\alpha=1$ bilancia efficacemente la velocità di addestramento e la qualità della convergenza del modello.

Significato

Il paper sostiene che ROLLART affronti efficacementamente il "problema dell'eterogeneità delle risorse" che ha limitato lo scaling dell'RL agente. Allontanandosi da architetture monolitiche o grossolanamente disaccoppiate, ROLLART dimostra che una disaggregazione fine-grained e consapevole dell'affinità hardware è essenziale per massimizzare il throughput nell'RL agente multi-task. La capacità del sistema di sostenere un alto throughput e la tolleranza ai guasti su un cluster di oltre 3.000 GPU ne valida la stabilità per l'uso in produzione, offrendo un blueprint per l'addestramento di modelli agentici su larga scala su infrastrutture eterogenee.