Uno, la diffusione dentro l’LLM: generare più token per passo senza cambiare le risposte

In una redazione il caporedattore non scrive i pezzi: li rilegge. Il praticante butta giù tre paragrafi di corsa, il caporedattore li scorre e tiene tutto fino alla prima frase che lui non avrebbe mai scritto; da lì in poi riscrive a modo suo. Se il praticante conosce bene il giornale, la maggior parte del testo passa, e il caporedattore ha lavorato un terzo del tempo. Il trucco regge a una condizione: il praticante deve scrivere quasi come lui. E costa comunque uno stipendio in più.

È, in piccolo, l’idea dello speculative decoding, la tecnica con cui oggi si accelera la generazione dei modelli linguistici: un modello piccolo propone, quello grande verifica. Unlocking Lossless Speedups in LLMs via Discrete Diffusion, uscito su arXiv il 3 settembre 2026 (2609.04010) e in questi giorni nella lista dei paper di tendenza su Papers with Code, propone di non assumere il praticante: è lo stesso caporedattore a scrivere la bozza, con un secondo paio d’occhiali leggero. Il lavoro è firmato da Subham Sekhar Sahoo e da sedici coautori dell’Institute of Foundation Models, dell’Università dell’Illinois, di Cornell Tech, di Harvard e di Cerebras. I modelli risultanti si chiamano Uno, perché mettono i due modi di generare in un’architettura sola.

Un token alla volta, anche quando il testo è prevedibile

Un modello autoregressivo genera un token per volta: per scrivere il decimo deve aver scritto il nono. È una scelta che funziona benissimo per la qualità e male per la velocità, per due ragioni che il paper mette in fila. La lingua è piena di sequenze prevedibili che si potrebbero scrivere a blocchi; e la decodifica è spesso limitata dalla memoria, non dal calcolo: per ogni token la GPU deve spostare pesi e cache, e intanto le unità di calcolo restano ferme. Oggi pesa di più che in passato, perché i ragionamenti si allungano e perché nell’addestramento con rinforzo la generazione dei tentativi domina il tempo totale.

Le vie d’uscita note sono due, e gli autori le trovano entrambe insufficienti. Lo speculative decoding (EAGLE-3, DFlash) è lossless, cioè produce esattamente la stessa distribuzione del modello grande, ma richiede di addestrare e tenere in memoria un modello bozza separato, con la sua cache. I modelli linguistici a diffusione (i d-LLM: DiffusionGemma, Nemotron-Labs-Diffusion, Mercury 2) generano più token in parallelo per costruzione, ma modificano i pesi del modello e pagano in qualità. E il loro vantaggio, osserva il paper, svanisce quando il batch cresce: vale per l’utente solo davanti allo schermo, non per un server che serve decine di richieste insieme, né per un agente che apre rami, chiama strumenti e riprova.

Due strade negli stessi pesi

La proposta si chiama LLM aumentato con la diffusione. Ogni livello del modello ha due insiemi di pesi. I pesi autoregressivi, $\theta_{AR}$, si addestrano come sempre (pre-training, fine-tuning, rinforzo) e decidono la qualità delle risposte. Accanto a ogni loro matrice c’è un adattatore LoRA di rango 128, $\theta_\Delta$, che serve solo alla velocità. La strada di bozza usa $\theta_{AR} + \theta_\Delta$; la strada di verifica usa soltanto $\theta_{AR}$. Siccome le due strade condividono quasi tutto, la bozza somiglia molto a ciò che il modello scriverebbe da solo, che è proprio la condizione del praticante bravo.

Gli adattatori si addestrano in una fase a parte, la Diffusion Distillation, con i pesi autoregressivi congelati. Il modello riceve un blocco di $B$ token del tutto casuali, dopo un contesto pulito, e deve trasformarlo in un solo passo di denoising nel blocco che il modello autoregressivo avrebbe scritto un token dopo l’altro. Un solo passaggio in avanti calcola insieme le previsioni del «maestro» (i pesi base, sulle posizioni pulite) e dello «studente» (base più adattatori, sulle posizioni rumorose), grazie a un LoRA con un interruttore per posizione. L’obiettivo combina due termini:

$$\mathcal{L}(\theta_\Delta) = \mathbb{E}\big[\,\alpha\,\mathcal{L}_{\mathrm{DCD}} + \beta\,\mathcal{L}_{\mathrm{TV}}\,\big],$$

dove $\mathcal{L}_{\mathrm{DCD}}$ è una distillazione per divergenza KL, presa dalla consistency distillation discreta, e $\mathcal{L}_{\mathrm{TV}}$ è la distanza di variazione totale fra la distribuzione della bozza e quella autoregressiva, token per token. Il secondo termine è quello che conta: nello speculative decoding la probabilità che un token venga accettato dipende proprio da quella distanza, e ridurla allunga il tratto di bozza che sopravvive. Le ablazioni lo confermano: con il solo termine TV il modello accetta in media 2,39 token per passaggio; con la sola distillazione, o con i due termini a pari peso, si ferma a 2,23. Nella ricetta finale la distillazione resta, con un peso di un centesimo.

Bozza in un colpo, verifica classica

In generazione il campionatore, che gli autori chiamano Ψ-Spec, alterna due passaggi. Nel primo la strada di diffusione trasforma un blocco di rumore in $B$ token proposti; il primo lo scrivono i soli pesi base, quindi è accettato per costruzione. Nel secondo i pesi base verificano la bozza con la stessa correzione per rifiuto dello speculative decoding classico, tengono il prefisso più lungo accettato e, al primo rifiuto, campionano al suo posto un token dal modello originale. Da qui il limite al numero di token prodotti per passaggio in avanti, il TPF:

$$1 \le \mathrm{TPF} \le \frac{B+1}{2}.$$

Il 2 al denominatore è il prezzo del metodo: ogni giro costa due passaggi, e anche la bozza perfetta non va oltre la metà di $B+1$. Il campionatore ha due varianti. A batch alto, quando la GPU è già piena di calcolo, si propone una sola sequenza (linear sampler). A batch 1, quando il calcolo è sottoutilizzato, si propongono molte alternative ad albero e si verificano tutte insieme (tree sampler). Poiché il modello verificatore non cambia mai, il testo in uscita segue la stessa distribuzione del modello di partenza.

I numeri: due esperimenti

Il primo esperimento parte da zero. Gli autori addestrano un Transformer denso che chiamano 8B (6,95 miliardi di parametri nel corpo, più circa 2 negli enormi vocabolari di ingresso e uscita) su circa 23 mila miliardi di token di dati interni, fino a un contesto di 512 mila token. Poi aggiungono gli adattatori e li addestrano su 7 miliardi di token: circa sessanta ore su 64 GPU H200. La proporzione è il dato che resta: la velocità costa circa tre decimillesimi dei token spesi per la qualità. Sul test standard del paper (mille token in ingresso, ottomila in uscita, una sola H200, bfloat16), al batch massimo che il modello base sostiene (64), Uno produce 5255 token al secondo di throughput di sistema contro i 3577 del modello autoregressivo base: circa 1,5 volte. A batch 1 il rapporto sale a circa 2,2 volte: 383 token al secondo contro 176.

Il secondo esperimento è quello che interessa di più a chi serve modelli aperti. Gli autori prendono Qwen3-8B, lo lasciano intatto e aggiungono 0,35 miliardi di parametri di adattatori, addestrati per 32 ore su 32 H200 con 14,7 miliardi di token di OpenThoughts, cioè su dati diversi da quelli originali del modello. A throughput di sistema UnoQwen supera i 5700 token al secondo, circa 1,6 volte il modello base; a batch 1 arriva a circa 2,5 volte il base. In entrambi i casi è più veloce di DFlash e di EAGLE-3. Ha anche il picco di memoria più basso (122,2 GiB contro circa 130) perché usa una cache sola, e meno parametri aggiunti di DFlash, che ne ha 1,05 miliardi.

C’è poi il rinforzo. Dal checkpoint di fine-tuning gli autori addestrano quattro esperti (matematica, codice, strumenti, ricerca web) aggiornando solo i pesi base, mentre gli adattatori restano quelli di prima. Ci si aspetterebbe che la bozza, ferma, si allontani dal verificatore che cambia. Il TPF medio, misurato dopo aver fuso i quattro esperti in un modello solo, scende invece di poco, da 2,25 a 2,10, e l’addestramento con rinforzo, da un capo all’altro, accelera fino al 40%, soprattutto per matematica e codice. I dettagli, avverte il paper, arriveranno in una revisione successiva.

Dove i titoli corrono più delle tabelle

Il lavoro è solido nell’idea e generoso nei confronti, ma va letto con qualche cautela.

I moltiplicatori non tornano tutti. L’abstract promette «fino a 3 volte» e la conclusione «fino a 2 volte al batch massimo»; le tabelle del modello costruito da zero danno 1,5 volte al batch massimo e 2,2 a batch 1, e un riquadro di sintesi parla di «oltre 2 volte a ogni dimensione di batch», in contrasto con la frase che lo precede. Il guadagno a batch pieno resta il risultato più interessante del paper, ma la cifra da tenere a mente è 1,5–1,6, non 3.

«Uno batte Mercury 2 e DiffusionGemma» è soprattutto una frase sul modello base. Se il metodo non perde niente, la qualità di Uno è quella del suo modello autoregressivo, addestrato su 23 mila miliardi di token di dati proprietari. Il confronto sui benchmark agentici misura quindi quel modello contro dei d-LLM, più che la diffusione contro la diffusione; e non è un filotto completo: su un benchmark di scienza e conoscenza Mercury 2 resta avanti, e a batch 1 DiffusionGemma è più veloce di Uno (836 token al secondo contro 383). Il rapporto 4,6 volte su Mercury 2 mette poi a confronto il throughput massimo di Uno con un dato pubblico di Mercury a batch 10, su GPU Blackwell più veloci e con una quantizzazione non dichiarata. Il batch 10 è scritto nel testo, ma fra le riserve gli autori citano solo hardware e precisione; e la tabella in appendice attribuisce a Mercury 1197 token al secondo, non i 1154 del testo. Resta un confronto indiretto.

La media nasconde la matematica. Il calo del 6% nel TPF dopo il rinforzo è una media: su GSM8K il valore passa da 2,66 a 1,95, su MATH500 da 2,27 a 1,93, mentre altri benchmark salgono. Proprio sulla matematica, dove il rinforzo accelera di più, la bozza invecchia di più; sul codice il quadro è misto (HumanEval sale, MBPP scende).

Due passaggi per giro sono un tetto strutturale. Esistono campionatori che fondono bozza e verifica in un passaggio solo, ma senza kernel dedicati non rendono; gli autori li rimandano a lavori futuri, insieme alla possibilità, solo accennata, di usare più passi di denoising come nuova leva di calcolo al momento dell’inferenza. Il throughput, infine, è misurato su prompt casuali di lunghezza fissa, una scelta onesta per non premiare chi ragiona meno, ma lontana dal traffico reale.

Una nota di merito: su un metodo concorrente, I-DLM, il paper dichiara di non essere riuscito a riprodurre l’accelerazione senza perdite con gli adattatori e il codice pubblicati. Codice e checkpoint di Uno sono rilasciati, e le stesse verifiche si potranno fare su di loro.

Perché conta adesso

Negli ultimi due anni la diffusione per il testo si è presentata come alternativa all’autoregressione: più veloce, un po’ meno brava. Questo paper la ridimensiona a qualcosa di più utile, un acceleratore che si monta sopra un modello esistente senza toccarne le risposte. Per chi gestisce un servizio il punto non è il 2,5 a batch 1, che lo speculative decoding già offre in varie forme, ma l’1,5 a batch pieno: la differenza fra una demo veloce e una bolletta GPU più leggera. Se i numeri reggeranno fuori da una singola H200 e da un test sintetico, il praticante in redazione non servirà più: il caporedattore avrà imparato a scrivere la bozza da solo, e a rileggerla.