Partire dal rumore: e se il codice non si scrivesse da sinistra a destra?

Guarda un modello mentre risponde. Le parole compaiono in fila, una dopo l'altra, da sinistra a destra, e ogni token esce solo dopo che è uscito quello prima. È talmente normale che non ci facciamo più caso, ma è una scelta, non una legge di natura: il modello calcola la probabilità del prossimo pezzo dato tutto quello che ha già scritto, e ripete. Se al terzo paragrafo capisce di aver impostato male il primo, non può tornare indietro. Può solo aggiungere.

C'è un altro modo di generare, ed è quello che da cinque anni fa le immagini. Si parte da rumore puro e lo si ripulisce a poco a poco, finché non resta qualcosa di sensato. Per anni è rimasto confinato ai pixel. Nel 2026 è arrivato sul testo e sul codice, e i numeri che porta con sé sono grossi: oltre mille token al secondo, contro le decine dei modelli che usi ogni giorno. Anche il prezzo è grosso, e per fortuna lo ha misurato Google.

Distruggere è facile, ricostruire è il modello

L'idea nasce nel 2015, in un paper di Jascha Sohl-Dickstein, Eric Weiss, Niru Maheswaranathan e Surya Ganguli intitolato Deep Unsupervised Learning using Nonequilibrium Thermodynamics. Il titolo cita la termodinamica, e non per vezzo:

"The essential idea, inspired by non-equilibrium statistical physics, is to systematically and slowly destroy structure in a data distribution through an iterative forward diffusion process. We then learn a reverse diffusion process that restores structure in data."

Il ragionamento è un'inversione elegante. Costruire un generatore di immagini è difficile; rovinare un'immagine è facilissimo, e si sa fare in modo esatto: aggiungi un pizzico di rumore, poi un altro, poi un altro ancora, e dopo qualche centinaio di passi la foto è indistinguibile da uno schermo di neve. Quel processo in avanti non richiede addestramento, è una formula.

Il modello impara solo il passo inverso: data un'immagine un po' rumorosa, prevedi il rumore che è stato aggiunto. Ripetendo quel piccolo passo all'indietro qualche centinaio di volte, si parte dalla neve e si arriva a una fotografia. Nel 2020 Jonathan Ho, Ajay Jain e Pieter Abbeel mostrano che funziona davvero, con un risultato che all'epoca è lo stato dell'arte: su CIFAR-10 senza condizionamento, Inception score 9,46 e FID 3,17. Nello stesso abstract c'è la frase che riguarda noi: il loro schema di generazione "can be interpreted as a generalization of autoregressive decoding". La generazione token per token, in questa luce, è un caso particolare.

Un anno dopo Yang Song e colleghi riscrivono tutto il campo in un'unica formulazione matematica, e aprono il paper con una riga che è la miglior definizione di generatività che io conosca:

"Creating noise from data is easy; creating data from noise is generative modeling."

Fra gli autori di quel paper c'è Stefano Ermon. Tienilo a mente, perché torna fra due sezioni.

Perché prima le immagini, e solo dopo il testo

Se l'idea è così generale, perché per cinque anni i modelli a diffusione hanno fatto quadri e non frasi? Per un dettaglio che sembra tecnico e invece è sostanziale: il rumore.

Un'immagine è continua. Un pixel vale 0,73, e puoi aggiungergli 0,02 di disturbo: il risultato è ancora un pixel, solo un po' sporco. Un token non funziona così. È un elemento di un vocabolario discreto, come una parola in un dizionario: fra "return" e "returns" non c'è niente in mezzo, e "aggiungere un po' di rumore" a un token non significa nulla. Se hai presente come si tagliano le parole in token, il problema si vede subito.

La soluzione adottata è cambiare cosa significa "distruggere". Invece di sporcare, si nasconde: il processo in avanti maschera i token, uno dopo l'altro, finché la frase non è una fila di caselle vuote. Il processo inverso indovina cosa c'era nelle caselle. È diffusione con il rumore sostituito dal mascheramento, e nel febbraio 2025 il modello LLaDA è il primo a mostrare che regge la scala: un modello da 8 miliardi di parametri addestrato così risulta "competitive with strong LLMs like LLaMA3 8B in in-context learning".

Nello stesso paper c'è un risultato che dice bene la differenza fra i due mondi. LLaDA batte GPT-4o nel completare una poesia al contrario, partendo dall'ultimo verso. Un modello autoregressivo è addestrato a guardare solo indietro, e quando gli chiedi di risalire una catena al rovescio va in difficoltà: è il fenomeno che in letteratura chiamano reversal curse. Un modello che lavora su tutta la finestra insieme non ha quel vincolo, perché per lui non esiste un "prima".

Quello che si guadagna: poter tornare indietro

Qui sta la parte interessante per chi scrive software, e non l'ho trovata nei comunicati stampa ma in un paper accademico di settembre, Exploring the Potential of Diffusion Large Language Models in Code Generation, che ha messo alla prova nove modelli a diffusione su quattro benchmark. La loro motivazione è la tesi di questo pezzo, scritta da loro: la generazione da sinistra a destra "misaligns with how programming actually works", che è fatta di "back-and-forth editing".

Pensa a come scrivi una funzione. Butti giù la firma, poi il corpo, poi ti accorgi che ti serve un parametro in più e risali a cambiare la firma. Poi rinomini una variabile in tre punti. Poi cancelli due righe che non servono. Nessuno scrive un file dall'alto in basso senza mai risalire: il codice si scrive a strati, non in fila.

Un modello autoregressivo quel movimento non può farlo dentro una generazione: può solo produrre una nuova versione da capo. Un modello a diffusione, invece, tiene tutta la tela sotto gli occhi a ogni passo e può cambiare un token che aveva già messo, perché nel frattempo ne ha deciso un altro trenta posizioni più avanti. Non è un caso che sul riempimento di un buco in mezzo al codice, il classico fill-in-the-middle, questi modelli vadano forte: Mercury Coder dichiara 82,2 su quel compito.

Il 2026, con i numeri

Due uscite hanno portato la cosa fuori dai laboratori.

Mercury, di Inception Labs. L'azienda è fondata da Stefano Ermon, cioè il coautore del paper del 2021 di due sezioni fa: la persona che ha contribuito a unificare la teoria adesso vende il prodotto. I numeri della loro pagina: i modelli girano "at over 1000 tokens/sec on NVIDIA H100s", con Mercury Coder Mini misurato a 1.109 token al secondo. Nella loro stessa tabella, il confronto è con 201 di Gemini 2.0 Flash-Lite, 61 di Claude 3.5 Haiku, 59 di GPT-4o Mini. Il processo lo descrivono "coarse-to-fine": l'uscita viene raffinata "from pure noise over a few denoising steps", modificando "multiple tokens in parallel". Il 24 febbraio di quest'anno è arrivato Mercury 2, l'8 settembre Mercury 2.5, dichiarato "the largest diffusion language model ever trained" con 1.107 token al secondo su GPU comuni. Un caso d'uso che citano vale più di un benchmark: la compattazione del contesto in un flusso di coding scende da circa 150 secondi a 27.

DiffusionGemma, di Google, uscita il 10 giugno con licenza Apache 2.0. È il primo modello a diffusione testuale con i pesi aperti, e la guida ufficiale spiega il meccanismo senza metafore: il modello "starts with a canvas of random placeholder tokens and iteratively refines them in parallel". La tela è di 256 token, l'attenzione è bidirezionale, e i token su cui il modello è già sicuro aiutano a risolvere quelli vicini. Quando il blocco è pulito viene fissato nella cache e si passa al successivo. Sono 25,2 miliardi di parametri totali con 3,8 attivi, e la velocità dichiarata è di oltre 700 token al secondo su una RTX 5090, oltre mille su una H100.

Nota il dettaglio del blocco, perché è la cosa che i riassunti saltano: dentro i 256 token la generazione è parallela, ma da un blocco al successivo si procede in ordine. Non è la fine della sequenzialità. È la sequenzialità spostata di due ordini di grandezza più in là.

La parte onesta: la tabella di Google

Un modello che va dieci volte più veloce deve pagare qualcosa, e il dato migliore per capire quanto non viene da un critico: sta nella scheda ufficiale di DiffusionGemma, dove Google confronta il proprio modello a diffusione con il fratello autoregressivo della stessa taglia.

Benchmark	DiffusionGemma 26B	Gemma 4 26B
MMLU Pro	77,6%	82,6%
AIME 2026	69,1%	88,3%
LiveCodeBench v6	69,1%	77,1%
MMMU Pro (vision)	54,3%	73,8%

Perde su tutte e quattro, e sulla matematica da competizione il divario è di quasi venti punti. Google stessa presenta il modello come sperimentale.

Lo stesso schema si vede nei numeri di Mercury, se si guarda la riga giusta. HumanEval 88,0 è un ottimo risultato, ma HumanEval è fatto di funzioncine autoconclusive. Su LiveCodeBench, che pesca problemi recenti e difficili, Mercury Coder Mini dichiara 17,0. Il paper accademico su nove modelli chiude nello stesso modo: sono "competitive with autoregressive LLMs with similar sizes", competitivi a parità di taglia, con un vantaggio sull'estrapolazione della lunghezza e sulla comprensione di codice lungo. Nessuno ha ancora mostrato un sorpasso.

Aggiungo il caveat che vale per tutti i numeri di velocità qui sopra: li dichiara chi vende il modello, misurati sul proprio hardware e sui propri casi. Sono verosimili e in linea fra loro, ma non sono misure indipendenti.

Cosa farne stasera

La domanda pratica non è "quale modello è meglio", che a questo stadio non ha una risposta. È: dove la velocità cambia il progetto, invece di essere un numero sulla brochure?

Cambia dove la latenza è il vincolo, e sono più posti di quanti sembri. Un agente che compatta il contesto ogni venti minuti, e ti lascia fermo mentre lo fa. Un sistema che lancia dieci sottoagenti in parallelo e aspetta il più lento. Qualunque cosa debba rispondere mentre una persona guarda o parla. In quei punti un modello dieci volte più veloce non ti dà un risultato migliore, ti dà un'architettura diversa: puoi permetterti di chiamarlo cento volte invece che una.

Non cambia dove il collo di bottiglia è altrove. Se il problema è la qualità del ragionamento su un bug difficile, la tabella di Google dice che qui si perde, non si guadagna. E se il problema è che il codice si scrive in fretta e si verifica lentamente, generare il doppio più veloce peggiora la congestione invece di risolverla.

C'è però una cosa che resta anche togliendo tutti i numeri, ed è la ragione per cui vale la pena tenere d'occhio questa roba. Per tre anni abbiamo dato per scontato che un modello scriva come una telescrivente, e abbiamo costruito prompt, tecniche di ragionamento e strumenti attorno a quel vincolo. Non era un vincolo della macchina: era il modo che avevamo. Un modello che lavora su tutta la tela e può tornare sui propri passi somiglia molto di più a una persona che scrive codice, e questo è vero anche se oggi, sui problemi difficili, prende ancora meno punti.

Fonti: