DiffusionGemma introduce un nuovo paradigma per la generazione del testo con modelli diffusion, aprendo scenari interessanti per inference a bassa latenza, edge AI e code infilling.
Google DeepMind sposta il paradigma da autoregressive a diffusion. Analisi tecnica, benchmark e codice per metterlo subito alla prova.
Il 10 giugno 2026 Google DeepMind ha pubblicato DiffusionGemma, il primo modello text-diffusion open-weight della famiglia Gemma. Distribuito con licenza Apache 2.0 e supportato nativamente da vLLM, segna una rottura netta con l’approccio autoregressive che ha dominato gli LLM negli ultimi anni. Per chi lavora su inference a bassa latenza, edge AI o code infilling, è un cambio di paradigma da studiare subito.
Diffusion sul testo: cosa cambia davvero
Gli LLM tradizionali generano un token alla volta, in sequenza. DiffusionGemma genera blocchi da 256 token in parallelo, raffinandoli iterativamente attraverso passi di denoising, la stessa logica dei modelli diffusion per le immagini, applicata al linguaggio: il blocco iniziale è una sequenza di token “rumorosi” mascherati o sostituiti casualmente, senza significato; a ogni passo il modello stima quali token reali si nascondano dietro il rumore e aggiorna l’intera distribuzione del blocco, convergendo verso un output coerente in poche decine di iterazioni. È il duale testuale del progressivo emergere di un’immagine da una nuvola di pixel: invece di rimuovere rumore pixel su pixel, si raffinano probabilità token su token, simultaneamente su tutta la finestra. La “qualità” del testo non si costruisce parola dopo parola, ma emerge per condensazione globale.
La conseguenza pratica è duplice: throughput più alto e attenzione bidirezionale all’interno del blocco, perché ogni token “vede” tutti gli altri durante il raffinamento. Non è un dettaglio cosmetico: rende il modello strutturalmente più adatto a inline editing, code infilling e task non lineari dove il contesto futuro è informativo quanto quello passato.
Numeri sul tavolo
L’architettura è un MoE da 26B parametri totali, 3,8B attivi per forward pass, costruito sulla base Gemma 4 con ricerca derivata da Gemini Diffusion. Su una singola H100 la model card riporta oltre 1.000 token/s; il team vLLM misura 1.288 token/s in FP8 su H200, grazie a per-request attention switching su Triton e FlashAttention 4. Su consumer GPU (RTX 5090) il throughput supera i 700 token/s. Con quantizzazione NVFP4 il modello entra in 18 GB di VRAM, abilitando deployment locali su hardware accessibile. Lo speed-up massimo dichiarato è 4x rispetto a un autoregressive equivalente. Una demo pubblica su Sudoku mostra il margine del fine-tuning: da 0 a 80% di puzzle risolti, con convergenza in 12 step di denoising invece di 48.
Dove conviene davvero e dove no
Google posiziona DiffusionGemma come sperimentale: la qualità out-of-the-box è inferiore a Gemma 4 su MMLU e coding benchmark. Nessuna sorpresa, è il prezzo del throughput. Ha senso valutarlo per:
- Workload locali interattivi: completamenti IDE, editor assistant, ambienti air-gapped
- Inline editing e code infilling: l’attenzione bidirezionale è strutturalmente più adatta
- Domain-specific con fine-tuning: la convergenza accelerata sul Sudoku suggerisce un margine reale
Sconsigliato per serving multi-tenant in alta concorrenza, dove il vantaggio single-request evapora, e per task generalisti, dove Gemma 4 resta superiore in accuratezza.
In sintesi
DiffusionGemma non sostituisce gli autoregressive: apre un secondo binario. Per chi progetta architetture AI in produzione, il vero esercizio non è “passare a diffusion”, ma mappare i propri workload sulle proprietà del paradigma: latenza percepita, struttura del task, vincoli di deployment. È esattamente la valutazione che separa l’adozione opportunistica da quella ingegneristicamente solida.