Molt, il framework di NVIDIA per l’RL agentico: un trilione di parametri in novemila righe di Python

Chi ha lavorato nella cucina di una mensa aziendale sa che cambiare una ricetta non è mai soltanto cambiare una ricetta. Per aggiungere un’erba al sugo bisogna passare dal responsabile degli acquisti, riprogrammare il forno combinato, rifare le porzioni sui vassoi da trecento coperti. Il cuoco sa benissimo che cosa vuole provare, ma l’impianto che serve a sfamare tutti lo costringe a chiedere il permesso a macchine che non conosce. Nelle cucine piccole si sperimenta di più per una ragione semplice: il cuoco riesce a vedere tutta la cucina.

È il problema che si pone Molt: A Scalable PyTorch-Native Training Framework for Agentic Reinforcement Learning, depositato su arXiv il 22 luglio 2026 (2607.21653) e rivisto il 16 settembre. Lo firmano undici ricercatori di NVIDIA, con Jian Hu primo autore e Yi Dong in chiusura, e fra i nomi ci sono Pavlo Molchanov e Jan Kautz. Jian Hu è anche il primo autore di OpenRLHF, un framework open source per l’addestramento con rinforzo dei modelli linguistici, e il paper lo dichiara: Molt nasce da lì. Il codice è pubblico su GitHub, nel repository NVIDIA-NeMo/labs-molt.

Che cosa non funzionava

Il reinforcement learning agentico è la tecnica con cui si insegna a un modello non a rispondere bene a una domanda, ma a portare a termine un compito in più passi: chiamare uno strumento, leggere il risultato, correggersi, andare avanti. Il ricercatore che lavora su questi sistemi cambia di continuo tre cose: il ciclo dell’agente, la funzione che assegna il premio, l’algoritmo che trasforma i premi in aggiornamenti dei pesi. E deve farlo su modelli che, per essere interessanti, sono ormai enormi.

Gli strumenti esistenti risolvono la scala in modi diversi. verl (HybridFlow) punta sulla flessibilità dell’esecuzione distribuita, slime aggancia Megatron-Core e SGLang, AReaL ha lavorato sull’asincronia. Gli autori mettono sul tavolo un altro costo: le righe di codice. Con il loro metodo di conteggio, Molt ha il 15% delle righe di verl e il 37% di quelle di slime, e rivendica di essere arrivato a un modello da mille miliardi di parametri. È la combinazione, non uno dei due numeri, la tesi del paper.

L’agente resta com’è: il confine è l’API

La scelta più interessante di Molt riguarda l’agente. Ogni framework ha un suo punto d’ingresso per l’agente (OpenRLHF e verl hanno le loro classi, slime accetta funzioni di generazione personalizzate), e Molt non fa eccezione. Ma dentro quel punto d’ingresso l’agente continua a chiamare il modello con lo SDK di OpenAI o con quello di Anthropic, come farebbe in produzione, senza chiamate di tracciamento e senza chiedere esplicitamente le probabilità: cambia l’indirizzo del server a cui si rivolge. Dietro quell’indirizzo c’è un livello di cattura che inoltra la richiesta a vLLM e, mentre il modello genera, registra gli identificativi dei token e le loro probabilità al momento del campionamento. Il ricercatore scrive una classe con un metodo run che restituisce il premio; il resto lo fa il framework. Per i compiti in cui è il framework a gestire la generazione c’è un’interfaccia alternativa, Env, sul modello di Gym.

Il contratto che tiene in piedi tutto è scritto in una riga. Per ogni token registrato $x_i$ con maschera d’azione $m_i$:

$$m_i = 1 \;\Longrightarrow\; x_i \text{ è il token restituito dal motore di rollout.}$$

Detto altrimenti: si addestra solo su ciò che il modello ha effettivamente generato, token per token, non su una ritrascrizione del testo. Il paper non si ferma sul perché, ma il rischio è noto: ritokenizzare una conversazione dopo il fatto può produrre sequenze diverse da quelle campionate, e allora le probabilità su cui si calcola la correzione non corrispondono più ai token.

Il caso più delicato è la compattazione del contesto. Un agente che lavora a lungo riassume o taglia i turni vecchi per stare nella finestra: la conversazione che il modello vede cambia a metà strada. Il livello di cattura controlla a ogni richiesta se la nuova conversazione prolunga quella registrata. Se sì, aggiunge al segmento corrente; se la storia è stata riscritta, apre un segmento nuovo. Tutti i segmenti di uno stesso tentativo condividono l’identificativo e il premio finale, che gli stimatori a gruppi contano una volta sola. Così l’agente può sostituire una lunga conversazione con un riassunto senza che l’addestramento perda il contesto in cui ciascuna azione è stata presa.

Tutto in parallelo, e senza un imbuto centrale

Il secondo pilastro è l’asincronia. Invece di alternare giri di generazione e giri di addestramento, Molt tiene un bacino di rollout sempre in corsa su GPU separate e mette insieme i batch man mano che si completano i gruppi di tentativi richiesti dagli stimatori come GRPO. Gli strumenti degli agenti hanno latenze molto diverse, e aspettare il più lento a ogni giro è tempo buttato. La profondità della coda regola quanto lavoro si accumula e, di conseguenza, quanto è vecchia la politica che ha generato i dati.

Quando i pesi cambiano, la generazione si mette in pausa, i nuovi parametri passano direttamente dall’attore ai motori via NCCL e le richieste in corso ripartono. Una stessa traiettoria può quindi contenere token generati da versioni diverse della politica. Per questo ogni token si porta dietro la probabilità registrata nel momento in cui è stato campionato, e con questo rollout parziale la correzione per importanza deve essere attiva. Anche la normalizzazione della perdita è fissata con cura: la media è calcolata sull’intera finestra dell’ottimizzatore, qualunque sia il modo in cui i dati sono ripartiti fra microbatch e rank,

$$\mathcal{L} = \frac{\sum_{i \in \mathcal{W}} m_i \, \ell_i}{\sum_{i \in \mathcal{W}} m_i},$$

dove $\ell_i$ include già gli eventuali pesi di correzione o di scarto. Il dettaglio conta: se il denominatore cambiasse con la ripartizione, lo stesso esperimento lanciato su un numero diverso di GPU ottimizzerebbe un obiettivo leggermente diverso.

Il terzo pilastro riguarda i dati pesanti. Un agente che usa un desktop, alla OSWorld, produce traiettorie piene di screenshot. Con molti agenti in parallelo, raccogliere tutto il batch in un unico processo di controllo significa concentrare lì tutta quella memoria. Molt lascia i dati dove sono nati: il lavoratore che ha finito un rollout deposita token, maschere, probabilità, rotte degli esperti e immagini nell’object store di Ray del proprio nodo, e sulla coda viaggiano solo un riferimento e pochi campi leggeri. Ogni rank dell’addestramento recupera soltanto le esperienze che gli sono state assegnate.

I numeri

La prova di scala è una frase: Molt ha eseguito il percorso completo, cioè rollout dell’agente, aggiornamento dei pesi nei motori e un passo di addestramento, su una politica da mille miliardi di parametri, con le stesse interfacce usate sui modelli piccoli. Il paper non dice su quale modello, su quante GPU, né con quali tempi.

Il confronto di velocità è più circostanziato. Su Qwen3-30B-A3B, due nodi da otto H100 (otto GPU per l’addestramento, otto per la generazione), problemi di matematica tratti da DAPO-Math, 32 prompt con quattro campioni per passo e risposte fino a 8.192 token, Molt impiega 119,4 ± 2,3 secondi per passo contro i 109,5 ± 10,3 di slime. Riportato ai token generati, fa 461 token per GPU al secondo contro 502: circa il 92% di slime. Molt è un po’ più lento. La dispersione fra le tre esecuzioni indipendenti è più bassa (2,3 secondi contro 10,3), ma tre esecuzioni sono poche per parlare di stabilità, e il paper infatti non lo fa. Il confronto, poi, è fra due pile intere, con motori di generazione (vLLM contro SGLang) e parallelismi diversi: misura il sistema, non il solo framework.

Poi c’è un carico multimodale, sempre su sedici H100: Qwen3.6-35B-A3B su una ricetta con strumenti in più turni (geo3k), contesto da 32K. Qui si provano due opzioni. La testa di predizione multi-token, usata come bozza per lo speculative decoding, accorcia la generazione. Lo stato dell’ottimizzatore Adam spostato nella memoria della CPU abbassa il picco di memoria dell’attore, al prezzo di un addestramento più lento.

Con la cache dei prefissi, quando la richiesta la trova, ricalcolare il contesto dell’agente richiede 0,05 secondi; manca però un valore senza cache con cui confrontarlo.

Che cosa il paper non dimostra

La cosa più importante da sapere sul confronto con slime la scrivono gli autori stessi: nel test di velocità il filtro di coerenza scarta i batch, quindi la pipeline cronometrata gira senza produrre aggiornamenti effettivi della politica. È una misura di costo di esecuzione, onesta come tale, ma non dice niente su chi addestri meglio. E in tutto il paper non c’è una curva di apprendimento, né un modello che alla fine risolva più compiti di prima. È un paper di sistemi, e va letto così.

La prova sul trilione di parametri è un’esistenza, non una misura: un passo completo eseguito, senza tempi, costi o qualità. Il conteggio delle righe dipende da un perimetro scelto dagli autori, che lo descrivono con precisione, ma altri conteggi darebbero altri rapporti. Il conteggio considera poi solo il codice proprio del framework, non le librerie su cui si appoggia (NeMo AutoModel, vLLM, Ray), e OpenRLHF, da cui Molt discende, resta più compatto. L’object store distribuito, terzo pilastro del progetto, non ha una misura: il paper non dice quanta memoria risparmi rispetto alla raccolta centralizzata. Lo speedup di 5,14 volte, infine, viene soprattutto da vLLM e dalla testa di predizione multi-token del modello: Molt lo rende disponibile con un’opzione, non lo inventa. Resta un solo carico di lavoro, con quattro prompt per passo.

Perché conta adesso

Se l’addestramento con rinforzo degli agenti deve uscire dai laboratori che possono permettersi un team di infrastruttura, la domanda di Molt è quella del cuoco della mensa: quanto dell’impianto bisogna capire per cambiare una ricetta. La risposta proposta è che l’agente non si tocca, il confine è un’API che gli sviluppatori conoscono già, e il resto sta in poche migliaia di righe leggibili. Che sia NVIDIA a proporlo, con GPU da vendere e un interesse evidente a far crescere questo tipo di carico, non toglie valore all’idea ma è un contesto da ricordare. Il prossimo obiettivo dichiarato sono due trilioni di parametri. La verifica più utile, però, sarà un’altra: vedere un agente addestrato con Molt diventare davvero più bravo.