Nvidia ha sviluppato una versione ottimizzata di Nemotron-3-Super per ridurre il costo operativo dei grandi modelli linguistici senza rinunciare alle capacità necessarie per ragionamento, programmazione, elaborazione multilingue, gestione di contesti estesi e attività agentiche. Il nuovo modello, denominato Nemotron-Labs-3-Puzzle-75B-A9B, nasce dalla compressione di un sistema ibrido Mamba-Transformer con architettura Mixture of Experts e punta a rendere più efficiente la distribuzione su GPU dedicate all’inferenza.
Il modello originale comprendeva circa 120,7 miliardi di parametri complessivi e ne attivava 12,8 miliardi durante l’elaborazione di ciascun token. La versione Puzzle riduce il totale a circa 75,3 miliardi di parametri e porta quelli attivi a 9,3 miliardi. La diminuzione è quindi pari a circa il 38% per la dimensione complessiva e al 27% per la parte effettivamente utilizzata durante l’inferenza.
La riduzione non è stata ottenuta applicando un taglio uniforme a tutta la rete. Nvidia ha utilizzato una tecnica chiamata Iterative Puzzle, basata su una sequenza di compressioni progressive. Dopo ogni fase, il modello viene sottoposto a distillazione della conoscenza per recuperare le capacità perse e riallineare il comportamento della versione ridotta a quello del sistema di partenza.
La distillazione utilizza il modello più grande come riferimento e trasferisce al modello compresso non soltanto le risposte finali, ma anche la distribuzione delle probabilità prodotte durante l’elaborazione. Questo permette alla rete più piccola di apprendere relazioni e preferenze che non emergerebbero usando esclusivamente dati con una singola risposta corretta.
Il processo viene ripetuto più volte, anziché concentrare l’intera compressione in un solo intervento. La strategia consente di verificare dopo ogni passaggio quali capacità si siano degradate e di recuperarle prima di procedere con un’ulteriore riduzione. Da questa impostazione deriva il riferimento al “puzzle”: il modello viene ricomposto progressivamente in una configurazione più compatta, selezionando per ogni parte una quantità di risorse proporzionata alla sua effettiva importanza.
Uno degli elementi principali è il pruning eterogeneo. Gli esperti della componente Mixture of Experts, i canali intermedi e gli altri elementi della rete non vengono ridotti tutti nella stessa misura. I livelli che contribuiscono maggiormente alle prestazioni conservano una struttura più ampia, mentre le sezioni considerate meno determinanti vengono compresse in modo più aggressivo.
Nelle architetture MoE, ogni token viene inviato soltanto a una parte degli esperti disponibili. La dimensione complessiva del modello influenza quindi lo spazio di memoria richiesto per conservare i pesi, mentre il numero di parametri attivi incide direttamente sulla quantità di operazioni necessarie per generare ciascun token. Ridurre entrambe le componenti permette di intervenire sia sull’occupazione della GPU sia sul costo computazionale dell’inferenza.
Nvidia ha ridotto anche la dimensione dello stato interno dei livelli Mamba, passando da 128 a 96 canali. I moduli Mamba utilizzano uno stato ricorrente per rappresentare le informazioni accumulate nella sequenza e possono elaborare contesti lunghi con una crescita della complessità più favorevole rispetto all’attenzione completa.
I livelli di attenzione sono stati invece mantenuti sostanzialmente invariati. La decisione deriva dal fatto che la loro gestione della cache KV era già considerata efficiente e che un’ulteriore riduzione avrebbe potuto compromettere la capacità di recuperare informazioni precise da contesti molto estesi. La compressione è stata quindi concentrata sulle componenti nelle quali era possibile ottenere un risparmio maggiore con un impatto più contenuto sulla qualità.
Dopo la fase strutturale, il modello è stato ulteriormente ottimizzato attraverso apprendimento per rinforzo, quantizzazione e previsione di più token. L’apprendimento per rinforzo serve a recuperare parte delle capacità di ragionamento e di esecuzione delle istruzioni, premiando le risposte che soddisfano i criteri stabiliti durante l’addestramento.
La quantizzazione riduce invece la precisione numerica utilizzata per rappresentare i pesi e le attivazioni. Nvidia ha distribuito il modello nei formati BF16, FP8 e NVFP4, destinati a configurazioni hardware differenti. BF16 mantiene una precisione relativamente elevata, FP8 riduce memoria e banda sulle GPU Hopper come H100, mentre NVFP4 sfrutta le capacità di calcolo a quattro bit delle GPU Blackwell.
La disponibilità di più formati consente di scegliere un diverso equilibrio tra accuratezza, consumo di memoria e velocità. La versione a precisione più elevata può essere utilizzata quando la fedeltà al modello originale è prioritaria, mentre le varianti maggiormente quantizzate sono orientate ai sistemi nei quali throughput e costo per token assumono un peso superiore.
Un altro intervento riguarda la Multi-Token Prediction. Un modello autoregressivo tradizionale genera un token per volta e deve completare un passaggio di inferenza per ciascun nuovo elemento della sequenza. La previsione multi-token tenta invece di anticipare più token futuri nello stesso ciclo, sottoponendoli successivamente a una procedura di verifica.
Quando una parte consistente delle previsioni viene accettata, il numero di passaggi necessari per completare una risposta diminuisce. Nvidia dichiara di aver migliorato la lunghezza media delle sequenze accettate del 25-30%, aumentando la quantità di testo che può essere prodotta a ogni ciclo di elaborazione.
Il beneficio principale non deve essere confuso con la sola velocità percepita da un singolo utente. L’obiettivo dichiarato era mantenere una generazione di circa 100 token al secondo per sessione e, contemporaneamente, raddoppiare il numero di richieste gestibili dall’infrastruttura. In queste condizioni, la versione compressa ha raggiunto un throughput circa 2,03 volte superiore a quello del modello originale senza utilizzare la previsione multi-token.
Con la Multi-Token Prediction attiva, il miglioramento dichiarato arriva fino a 4,6 volte. Ciò significa che lo stesso sistema di GPU può elaborare un numero molto maggiore di richieste mantenendo un livello di servizio comparabile per ciascun utente. La riduzione del costo deriva quindi soprattutto da un migliore utilizzo dell’hardware, non soltanto da una risposta individuale generata più rapidamente.
Il vantaggio risulta particolarmente evidente nei contesti estremamente lunghi. Su una singola GPU H100, Nemotron-3-Super riusciva a gestire una richiesta con una lunghezza di un milione di token. La nuova configurazione può eseguirne fino a otto contemporaneamente, secondo i risultati comunicati durante la valutazione.
La gestione dei contesti lunghi richiede memoria non soltanto per i parametri del modello, ma anche per le informazioni temporanee generate durante l’elaborazione. Nei Transformer questa componente è rappresentata soprattutto dalla cache KV, che conserva chiavi e valori dei token precedenti per evitare di ricalcolarli a ogni passaggio. Quando la sequenza raggiunge centinaia di migliaia o milioni di token, questa memoria può diventare uno dei principali limiti alla concorrenza.
L’architettura ibrida combina i livelli di attenzione, utili per recuperare relazioni precise all’interno del contesto, con i moduli Mamba, più efficienti nell’elaborazione sequenziale. La compressione dei pesi e degli stati interni libera memoria che può essere utilizzata per mantenere contemporaneamente più sessioni con finestre contestuali molto estese.
Su un server composto da otto GPU B200, il modello ha ottenuto un throughput circa doppio rispetto alla versione di partenza. Il risultato mostra come il vantaggio non sia circoscritto a una singola scheda, ma possa essere sfruttato anche nelle infrastrutture dedicate alla distribuzione su larga scala.
Le valutazioni indicano che le prestazioni sono rimaste vicine a quelle di Nemotron-3-Super nei test di ragionamento, sviluppo software, multilinguismo e gestione del contesto lungo. Nel benchmark RULER con sequenze fino a un milione di token, la differenza rispetto al modello originale si è limitata a circa uno o due punti.
Risultati sostanzialmente comparabili sono stati osservati anche in prove come LiveCodeBench, GPQA e SciCode, utilizzate per misurare rispettivamente capacità di programmazione, ragionamento scientifico e risoluzione di problemi tecnici. La compressione non è però priva di compromessi: alcune valutazioni sulla capacità di seguire istruzioni e sulle attività agentiche hanno mostrato riduzioni più visibili, con il calo maggiore registrato su Arena-Hard-V2.
Questi risultati evidenziano che la conservazione delle prestazioni medie non garantisce una stabilità identica in tutte le applicazioni. Un modello ottimizzato per l’inferenza può continuare a ottenere punteggi elevati nei benchmark generali e perdere affidabilità in situazioni che richiedono interpretazione sottile delle istruzioni, scelta autonoma degli strumenti o pianificazione su più passaggi.
La valutazione in produzione deve quindi considerare il carico specifico. Un sistema destinato alla generazione di codice o all’analisi di documenti estesi può beneficiare direttamente dell’aumento di throughput. Un agente autorizzato a eseguire procedure operative richiede invece test aggiuntivi per verificare che la compressione non abbia alterato il rispetto delle regole, la scelta degli strumenti o la capacità di interrompersi davanti a un’incertezza.
Il valore della tecnica dipende dal costo per richiesta completata. Se un’infrastruttura può servire il doppio degli utenti con lo stesso numero di GPU, la spesa attribuita a ciascuna sessione può ridursi in modo consistente. Con l’impiego della previsione multi-token, il risparmio potenziale aumenta ulteriormente, purché il tasso di accettazione rimanga elevato sui carichi reali.
La riduzione dei parametri attivi abbassa anche il traffico di memoria necessario durante la generazione. Nei grandi modelli, l’inferenza è spesso limitata non soltanto dalla capacità di calcolo, ma dalla velocità con cui i pesi vengono trasferiti dalla memoria della GPU alle unità di elaborazione. Un modello più compatto permette di utilizzare in modo più efficiente la banda disponibile.
La tecnica Iterative Puzzle mostra quindi un approccio alla compressione diverso dalla semplice quantizzazione applicata a un modello già completato. Nvidia interviene sulla struttura della rete, sul numero di esperti, sui canali interni e sugli stati Mamba, recupera progressivamente la qualità tramite distillazione e apprendimento per rinforzo e applica infine formati numerici e tecniche di decodifica orientati all’hardware.
Il risultato è un modello progettato non soltanto per ottenere un buon punteggio, ma per aumentare il numero di richieste gestibili da ciascuna GPU. Nell’AI generativa su larga scala, la sostenibilità economica dipende sempre più da questa relazione tra qualità e capacità di servizio. Un modello leggermente più piccolo può risultare molto più utile quando conserva le funzioni essenziali e riduce in modo sostanziale memoria, latenza e costo di inferenza.