Google Diffusion, più velocità e meno qualità per l’IA open source

Google DeepMind ha rilasciato diffusiongemma-26B-A4B-it, primo modello open weights della famiglia Gemma costruito su architettura a diffusione invece che autoregressiva. Il modello genera blocchi da 256 token in parallelo per forward pass con bi-directional attention, raggiunge oltre 1.000 token al secondo su NVIDIA H100 e 700 token al secondo su RTX 5090, ma perde tra 5 e 19 punti di benchmark rispetto al fratello autoregressivo equivalente. La licenza è Apache 2.0, i pesi sono su Hugging Face, lo stack di serving copre vLLM, MLX, HF Transformers, con llama.cpp in arrivo.

Fino a oggi la generazione a diffusione per il testo era territorio di laboratori chiusi e startup: Inception Labs con Mercury e Mercury 2, l’esperimento Gemini Diffusion mostrato al Google I/O di maggio 2025 e mai aperto, il filone accademico di LLaDA. DiffusionGemma porta lo stesso paradigma in open weights, scaricabile, fine-tunabile, eseguibile su una GPU consumer di fascia alta sotto i 18GB di VRAM se quantizzato. Per chi sviluppa applicazioni a inferenza locale, l’asse della competizione si sposta sulla velocità di generazione a hardware fisso, accanto alla qualità per parametro.

La macchina da scrivere e la stampa rotativa

I modelli autoregressivi che usiamo tutti i giorni, da GPT a Claude a Gemini, generano testo come una macchina da scrivere: un token alla volta, ciascuno condizionato a tutti quelli precedenti. DiffusionGemma fa qualcosa di diverso. Parte da un blocco di 256 token di rumore e li ripulisce in parallelo attraverso passaggi successivi di denoising, con attenzione bidirezionale. È la differenza tra battere a macchina e mandare in stampa una pagina: il risultato finale è testo coerente, ma il processo produttivo è radicalmente più parallelo. Su NVIDIA H100 la velocità supera i 1.000 token al secondo, su RTX 5090 sta sopra i 700. La annuncio ufficiale di Google rivendica fino a quattro volte la velocità del Gemma 4 autoregressivo equivalente, a parità di footprint.

Il modello è un MoE con 26 miliardi di parametri totali e 3,8 miliardi attivi per step, otto esperti su 128 più uno condiviso. La base è la famiglia Gemma 4, su cui il team ha sostituito il decoder autoregressivo con una diffusion head. Input multimodale, output testo, finestra di contesto 256.000 token. La model card su Hugging Face documenta licenza Apache 2.0, dataset di training, configurazioni di serving.

NVIDIA ha già pubblicato una versione NVFP4 a 4 bit ottimizzata per RTX 5090, RTX 4090 e per le architetture Hopper e Blackwell datacenter. Il fine-tuning passa da Hackable Diffusion, Unsloth, NVIDIA NeMo. Sul cloud il modello arriva via Gemini Enterprise Model Garden e NVIDIA NIM. Lo stack è completo dal giorno uno, e questo è un segnale di per sé: Google sta cercando adozione di mercato, oltre il pilot di ricerca.

Quando un benchmark più basso è il prezzo dell’apertura

Su MMLU Pro DiffusionGemma fa 77,6%, contro 82,6% del Gemma 4 26B A4B autoregressivo. Su AIME 2026 il gap è più largo, 69,1% contro 88,3%. Su GPQA Diamond 73,2% contro 82,3%. Solo su HLE senza tool il modello a diffusione passa avanti, 11,0% contro 8,7%. Google ammette nella documentazione che “output quality is lower than standard Gemma 4” e suggerisce di usare la versione standard quando la qualità conta più della velocità. È un’ammissione rara nel mondo dei rilasci AI, dove la norma è confronti scelti per far brillare il nuovo arrivato.

In single-user e in scenari local low-concurrency il gap a favore di DiffusionGemma è netto. Nei serving cloud ad alta QPS, dove il batching maschera parte della latenza autoregressiva, il guadagno si riduce. Su Apple Silicon il vantaggio non si materializza affatto: il collo di bottiglia dei chip M sta nella banda di memoria, e il pattern di accesso della diffusione non sfrutta l’architettura unified memory. Chi sviluppa su Mac Studio o MacBook Pro M4 Max non ha alcuna ragione per migrare. Chi gira su workstation RTX 5090 o RTX 4090 sì.

Code infilling è il workload in cui la diffusione vince davvero. Unsloth ha mostrato un fine-tuning di DiffusionGemma per risolvere Sudoku, dove gli autoregressivi falliscono perché ogni token dipende da quelli futuri quanto da quelli passati. Stessa logica vale per in-line editing, refactor con vincoli bidirezionali, iterazioni rapide su prompt che richiedono coerenza globale invece che progressione lineare. Per assistenti conversazionali generalisti il vantaggio è meno chiaro, e la perdita in benchmark di ragionamento puro come AIME suggerisce di tenere il modello autoregressivo per i task in cui il ragionamento step-by-step conta.

I casi d’uso interessanti per il deployment B2B concreto sono tre: code completion dentro IDE locali, RAG su corpus documentale aziendale, editing assistito di testi lunghi con vincoli di coerenza globale. Tutti scenari in cui la latenza percepita conta più della parte alta dei benchmark di ragionamento. Sul costo per token i numeri parlano da soli: Mercury 2 viaggia tra 1 e 3 dollari per milione di token in output, mentre una RTX 5090 da 450 watt che genera 700 token al secondo costa meno di un centesimo per milione di token in puro consumo elettrico, ammortamento hardware escluso. Per workload ripetitivi a volume alto il calcolo è banale, e spiega perché il primo vero deploy enterprise di diffusion text generation arrivi probabilmente da chi ha già infrastruttura GPU locale e non vuole pagare API esterne. Lo stack di serving è già pronto: vLLM è il candidato naturale per il deployment con concorrenza moderata, NVIDIA NIM copre chi è già allineato all’ecosistema Hopper-Blackwell, e Hugging Face Transformers resta per i prototipi su singola macchina.

Open weights sì, ma per quale workload?

Inception Labs ha lanciato Mercury a febbraio 2025 e Mercury 2 a febbraio 2026, primo diffusion LLM commercial-scale, circa 1.000 token al secondo, 91,1% su AIME 2025, 73,6% su GPQA. Mercury è chiuso, accessibile via API a pagamento. The Decoder ha ricostruito la timeline: Gemini Diffusion mostrato al Google I/O 2025 era la risposta interna di Google, restata però in waitlist demo. Il filone accademico è guidato da LLaDA di Renmin University e Ant Group, il cui paper LLaDA è stato selezionato come oral a NeurIPS 2025, con LLaDA 2.0 scalato a 100 miliardi di parametri a dicembre 2025. DiffusionGemma è la prima volta che un attore di scala porta diffusion text generation in open weights davvero usabili.

Un modello aperto Apache 2.0 con pesi scaricabili e ispezionabili semplifica i discorsi sulla compliance con i responsabili sicurezza informatica e con i DPO. Le architetture a diffusione lasciano traccia diversa nei log rispetto agli autoregressivi, perché ogni token finale è il risultato di un denoising parallelo e non di una catena causale, e questo cambia le procedure di audit dell’output. Chi gestisce dati regolamentati troverà più semplice giustificare un deploy interno che un’API esterna, indipendentemente dalla qualità dichiarata.

Sotto i 18 GB di VRAM quantizzato il modello gira su un laptop normale di fascia workstation. È il pattern che abbiamo già visto con la famiglia Gemma 4, e ricorre l’argomento di possedere i pesi contro dipendere da API esterne. La differenza è che qui l’apertura è il prezzo dichiarato di una qualità inferiore, non un equivalente gratuito del modello premium.

Il regalo che legittima il premium

Google apre la generazione a diffusione ai dev locali, ammette per iscritto che la qualità scende rispetto all’autoregressivo, e in un colpo solo legittima il proprio modello chiuso come standard premium. Il messaggio implicito al mercato enterprise è: vuoi velocità a costo basso, prendi DiffusionGemma; vuoi ragionamento serio, paghi Gemini. La pressione competitiva di Mercury e LLaDA viene neutralizzata con una mossa che a Google costa poco, perché il modello rilasciato non cannibalizza l’offerta premium.

Il vantaggio per gli utilizzatori è asimmetrico. Premia chi gira su GPU discrete, sparisce su Apple Silicon, conta poco nei serving cloud ad alta concorrenza. Nel tessuto B2B italiano, dove le workstation aziendali sono in larga maggioranza Windows con GPU NVIDIA e i Mac Studio restano confinati a nicchie creative, il modello gioca a favore del segmento standard. Per i fornitori di applicazioni a inferenza locale è un’opzione concreta per task di editing, code completion, iterazione rapida; resta uno strumento di seconda scelta quando il workload richiede ragionamento multi-step.

Efficienza prima della potenza è il vero asse competitivo del 2026, e DiffusionGemma lo conferma. Il rapporto qualità-velocità a hardware fisso è la metrica vincente, sopra la dimensione assoluta. DiffusionGemma porta dimensione non è qualità in territorio nuovo: stessa dimensione, qualità inferiore, ma velocità quattro volte superiore su hardware giusto. Conta scegliere il workload prima del modello.

Il primo diffusion model open di scala arriva proprio da Google, non da Meta o Mistral, e dice qualcosa sulla direzione che la ricerca sta prendendo a Mountain View. La diffusione testuale era curiosità accademica, oggi è infrastruttura. Il prossimo passo logico è una versione più grande, magari un Gemini Diffusion 2 chiuso che recuperi il gap di qualità mantenendo il vantaggio di velocità. A quel punto la conversazione sui modelli piccoli bastano dovrà aggiungere una variabile: piccoli, ma anche veloci come.