Trajectory presenta C-LoRA: throughput 2.81× superiore per il continual learning con più adattatori

Il team di Trajectory, in collaborazione con UC Berkeley Sky Lab e Anyscale, ha pubblicato un report su C-LoRA (Continuous Multi-LoRA Training), uno stack di training concorrente progettato per carichi di continual learning. Il codice è interamente open-source nel repository NovaSky-AI/SkyRL su GitHub.

Il risultato principale è un guadagno di 2.81× nell’experiment-throughput end-to-end rispetto a un framework single-tenant, senza alcuna regressione sulle metriche di ricompensa nei test effettuati.

Cos’è C-LoRA e perché serve

Il continual learning richiede che un modello si aggiorni in tempo reale dai feedback e dalle interazioni in produzione. Un agente di coding potrebbe apprendere pattern di engineering mentre uno sviluppatore corregge il suo lavoro; un agente di supporto potrebbe risolvere ticket complessi grazie agli interventi degli operatori. L’infrastruttura tradizionale, però, assume un ciclo lineare: allocazione GPU, inizializzazione del modello, esecuzione del job, spegnimento. Il continual learning rompe questo schema, rendendo il training parte di un sistema live.

Trajectory mappa ogni esperimento su un adattatore LoRA dedicato, su un motore multi-tenant sempre attivo. Questo approccio aggira quattro inefficienze tipiche:

• Cold start lenti: ogni job seriale deve ricaricare checkpoint, inizializzare il runtime distribuito e scaldare i motori di inferenza. Per modelli grandi, questa fase può superare i 30 minuti per esecuzione.
• RL memory-intensive: modelli come Qwen3.5-397B richiedono fino a otto nodi H200 per entrare in memoria. LoRA riduce i consumi di un ordine di grandezza, congelando il modello base e allenando solo piccoli pesi adattatori.
• Sistemi single-tenant: tradizionalmente si esegue un esperimento alla volta. Multi-LoRA permette di multiplexare il throughput per un fattore N.
• Bassa utilizzazione dei job: trainer e motori di inferenza restano in attesa l’uno dell’altro. Il bilanciamento multi-LoRA satura la capacità inutilizzata.

Come funziona l’architettura

La maggior parte dei guadagni di throughput deriva dall’inferenza. In vLLM, tutti gli adattatori sono caricati in memoria GPU. I passi di decode possono mescolare token di diversi adattatori nello stesso batch. Il kernel chiave è SGMV decode, che fonde il lavoro per-adattatore in un singolo lancio GPU per passo di decode. Dopo ogni passo di ottimizzazione, i pesi LoRA aggiornati vengono caricati in-place nel motore di inferenza, mentre lo scheduler non si blocca, permettendo ad altri tenant di continuare a decodificare.

Il training è invece ancora serializzato: un adattatore attivo allena sulla GPU, gli altri restano in memoria CPU pinzata. Ogni tenant ha il suo stato in un AdapterStore (parametri LoRA, pesi master FP32, momenti dell’ottimizzatore, buffer gradienti). Il motore carica lo stato di un tenant, esegue un passo forward-backward, poi lo riscarica.

I numeri sul campo

Trajectory ha testato su un singolo nodo H200 con il modello Qwen3-4B-Instruct-2507, eseguendo sync RL su GSM8K in configurazione agentic. La policy parte da circa il 40% di accuratezza al passo 0 e supera il 90% entro il passo 9. Con otto run multi-LoRA concorrenti, il tempo finale di esperimento è stato di 5433 secondi (2.81× speedup). Otto esperimenti sono terminati prima di tre esecuzioni seriali consecutive. Anche il tempo medio per esperimento è migliorato, con un picco di 1.88× a N=4.

Tutti i livelli di concorrenza hanno raggiunto reward_accuracy sopra il 90% entro il passo 9.

I trade-off

Il throughput maggiore ha un costo: la latenza per passo aumenta. A N=8, il primo esperimento seriale finisce 1.97× più velocemente rispetto a C-LoRA, e il tempo medio per passo sale da 191 a 500 secondi (2.62× più lento). La maggior parte dell’incremento è nel rollout (da 162 a 401 secondi, circa il 77%). A N=2, raddoppiare il carico aggiunge solo il 15% di tempo di rollout — il caso ideale per multi-LoRA.

Il pattern è stato confermato su carichi più complessi (τ-bench retail con NVIDIA-Nemotron-3-Nano-30B MoE): N=2 ha terminato 10 passi 1.28× più velocemente, con un per-tenant step time aumentato di 1.57×.

Punti di forza e limiti

Punti di forza:

• 2.81× di guadagno end-to-end a otto run concorrenti.
• Nessuna regressione di accuratezza: i run seguono la baseline seriale entro ±1σ nei passi finali.
• LoRA riduce la memoria di un ordine di grandezza rispetto al full fine-tuning.
• Codice completamente open-source su NovaSky-AI/SkyRL.

Limiti attuali:

• Latenza per passo e tempo del primo esperimento degradano all’aumentare di N.
• Il training resta serializzato per tenant; solo l’inferenza è multiplexata.
• Testato principalmente su modelli di medie dimensioni, non su frontiera.
• Richiede un nodo 8× H100/H200 e build Megatron.