I modelli linguistici autoregressivi hanno una descrizione del lavoro bizzarra: prevedere un token, poi un altro, poi un altro, per sempre. Quel ciclo seriale spiega perché un modello possa scrivere una buona spiegazione e fare comunque sembrare un terminale interattivo collegato alla Luna.

I modelli linguistici a diffusione provano un trucco diverso. Invece di fissare il testo rigorosamente da sinistra a destra, partono da posizioni mascherate o rumorose e ne raffinano molte iterativamente. In teoria questo significa generazione parallela. In pratica c’è una battuta pessima: il modello lavora su più token insieme, ma ripete una costosa fase di denoising e spesso non può riutilizzare pulitamente la cache di attenzione interna.

Questo problema di cache — non la mancanza di paper intelligenti — mi ha fatto trattare la diffusione testuale come teatro della ricerca, non come sostituto dell’inferenza locale. Il lavoro recente su Fast-dLLM rende quel giudizio meno comodo. Non sbagliato. Meno comodo.

Parallelismo non significa automaticamente velocità

Un normale modello autoregressivo porta avanti una cache key-value mentre genera. I token precedenti non devono essere ricalcolati da zero a ogni passo. È uno dei motivi per cui l’approccio da sinistra a destra resta brutalmente pratico nonostante la sua natura seriale.

Un modello a diffusione ha vita più dura. Una posizione può cambiare in un passaggio successivo e le rappresentazioni attorno a essa diventano invalide. Riutilizzare lo stato in cache è quindi approssimato, non gratuito. Generare troppe posizioni in parallelo confonde le dipendenze; essere prudenti fa evaporare il parallelismo promesso in passaggi ripetuti.

Questo è il vero problema di engineering. «La diffusione può generare in parallelo» è una proprietà, non un risultato di benchmark.

Fast-dLLM di NVIDIA Research affronta il problema con due elementi: una cache approssimata a blocchi per modelli bidirezionali a diffusione e decoding parallelo consapevole della confidenza. Le posizioni stabili possono avanzare insieme; quelle incerte non dovrebbero essere costrette in un abbraccio prematuro. Gli autori riportano fino a 27,6× di throughput nei loro esperimenti LLaDA e Dream, con minima perdita di accuratezza. È un risultato della loro valutazione, non un numero che io abbia riprodotto.

La precisazione non è decorativa. «Fino a» è il punto in cui le slide di benchmark diventano folklore.

L’affermazione più utile è più piccola

Il successore Fast-dLLM v2 avanza una proposta più concreta: adattare un modello autoregressivo preaddestrato in un modello a diffusione a blocchi, preservarne le prestazioni e ottenere fino a 2,5× di velocità rispetto al decoding autoregressivo standard nei loro esperimenti.

Riporta anche circa 1 miliardo di token di fine-tuning contro i 580 miliardi citati per il modello Dream full-attention: una differenza di 500×, secondo gli autori. Se questa ricetta funziona anche fuori dal paper, la domanda utile cambia da «qualcuno addestrerà un nuovo foundation model a diffusione?» a «un modello capace esistente può acquisire una modalità di decoding più veloce senza un retraining faraonico?»

È una domanda più interessante per chi gestisce modelli invece di ammirare i loro conteggi di parametri.

Perché non lo chiamo ancora una svolta per l’IA locale

Tre ragioni.

Primo: throughput non è latenza per l’utente. Un sistema può elaborare un batch grande in modo brillante e impiegare comunque troppo per produrre la prima risposta utile. Conta per chat interattiva, uso di strumenti e coding. Un grafico di token al secondo senza tempo al primo token è una storia incompleta.

Secondo: l’approssimazione della cache è un compromesso di qualità da caratterizzare su carichi banalmente ostili: modifiche strutturate lunghe, codice con dipendenze distanti, output vincolato e un prompt seguito da una correzione. Non sono difetti che emergono in un benchmark di prosa piacevole.

Terzo: il deployment è l’esattore. Il framework open source dLLM è utile proprio perché il campo ha accumulato implementazioni di ricerca incompatibili. Mira a standardizzare training, inferenza e valutazione per LLaDA e Dream. È progresso. È anche la prova che il percorso di serving non è ancora noioso — e l’infrastruttura noiosa vince.

Non mi serve un’architettura filosoficamente elegante. Me ne serve una che entri in uno stack di serving affidabile, esponga metriche sane, sopravviva alla quantizzazione e dimostri un vantaggio sui prompt che mi interessano. Fino ad allora un modello autoregressivo con una cache ben compresa resta la scelta predefinita.

Cosa testerei prima di credere al titolo

Un confronto locale serio deve fissare compito e soglia di qualità, poi misurare:

  1. Tempo al primo output visibile, non solo throughput aggregato.
  2. Tempo end-to-end per una risposta breve e una lunga strutturata.
  3. Qualità del compito su modifiche al codice, estrazione e JSON vincolato — non solo prosa fluida.
  4. Uso della memoria mentre cresce il contesto, perché il design della cache è tutta la trama.
  5. Prestazioni con batch di uno. L’inferenza personale raramente arriva come coda da datacenter.

Separerei anche due affermazioni che vengono troppo spesso graffettate insieme: generazione parallela e inferenza locale utile. La prima è una capacità architetturale. La seconda richiede toolchain, kernel hardware, comportamento di quantizzazione e profilo di latenza che non la tradiscano.

Il giusto livello di entusiasmo

I modelli linguistici a diffusione non sono più solo un elegante controfattuale alla previsione del token successivo. Decoding attento alla cache e diffusione a blocchi li rendono una direzione credibile per la ricerca sull’inferenza; il 2,5× riportato merita scrutinio, non applausi da una distanza sicura.

Ma non è il permesso di sostituire uno stack locale funzionante con un preprint e una preghiera.

Per ora tratterei il lavoro in stile Fast-dLLM come candidato da benchmark: riprodurlo sull’hardware e sul percorso di serving realmente usati, pubblicare la latenza del primo token accanto al throughput e rifiutare ogni aumento di velocità che cambi silenziosamente qualità o forma del carico. Se sopravvive, la diffusione potrebbe finalmente guadagnarsi un posto accanto al decoding autoregressivo — invece di un’altra sedia nella sezione «architettura interessante, chiamami quando gira».

Fonti verificate

  • Fast-dLLM — NVIDIA Research, maggio 2025. Progetto della cache e risultato riportato fino a 27,6×.
  • Fast-dLLM v2 — NVIDIA Research, settembre 2025. Circa 1B token di fine-tuning, confronto 500× con i 580B di Dream e accelerazione fino a 2,5×.
  • dLLM: Simple Diffusion Language Modeling — Zhou et al., febbraio 2026. Ambito dichiarato di standardizzazione di training, inferenza e valutazione.