Google ha reso pubblico DiffusionGemma, un modello sperimentale open source che affronta la generazione del testo in modo radicalmente diverso rispetto agli LLM tradizionali. Non si tratta di un semplice aggiornamento della famiglia Gemma, bensì di un cambio di approccio nel modo in cui il modello produce output.
Mentre i classici modelli autoregressivi, quelli su cui si basano praticamente tutti i chatbot moderni, generano testo un token alla volta dall’inizio alla fine, DiffusionGemma parte da un “canvas” di token casuali e li raffina iterativamente in parallelo, fino a ottenere testo coerente e leggibile.
Il risultato pratico è una velocità di generazione fino a quattro volte superiore su GPU dedicate: oltre 1.000 token al secondo su un singolo NVIDIA H100 e più di 700 token al secondo su una NVIDIA GeForce RTX 5090.
Il modello è stato rilasciato sotto licenza Apache 2.0 su Hugging Face, con pesi liberamente accessibili. È costruito sul backbone di Gemma 4 e integra la ricerca di Google su Gemini Diffusion rilasciato lo scorso anno. La grossa novità è che per la prima volta si può testare in locale e sul proprio computer un modello con architettura diffusion. È uno modello per appassionati, power users e sviluppatori che hanno bisogno di latenza minima, anche a costo di qualche compromesso sulla qualità dell’output.
DiffusionGemma: l’architettura che sposta il collo di bottiglia
Per capire perché DiffusionGemma è più veloce, bisogna prima capire il limite strutturale dei modelli autoregressivi in inferenza locale. Su server cloud con migliaia di richieste concorrenti, il paradigma token-per-token funziona bene perché il batch satura le GPU. Ma in un setup locale, con un singolo operatore, la GPU passa la maggior parte del tempo ad aspettare: carica i pesi dalla memoria, genera un token, li carica di nuovo. Il collo di bottiglia è la larghezza di banda della memoria, non la potenza di calcolo.
DiffusionGemma inverte questa logica: genera e raffina un intero blocco di 256 token in parallelo per ogni forward pass, fornendo al processore un carico di lavoro massiccio e continuo che utilizza al massimo i tensor core altrimenti sottoutilizzati.
Dal punto di vista architetturale, il modello combina due meccanismi distinti. Durante il prefill, usa attention causale per ingurgitare il contesto del prompt e scrivere nella KV cache. Durante il denoising, passa a un’attention bidirezionale in cui ogni token del canvas può vedere tutti gli altri contemporaneamente, in entrambe le direzioni. Questo permette al modello di correggere errori in tempo reale, perché valuta l’intero blocco a ogni passo.
Per sequenze più lunghe di 256 token, un meccanismo “block autoregressive” elabora un blocco alla volta, impegnando ciascuno nella KV cache prima di passare al successivo. Si tratta di un’architettura Mixture of Experts (MoE) da 26 miliardi di parametri totali, di cui soltanto 3,8 miliardi attivi durante l’inferenza, il che consente il deployment quantizzato entro i 18 GB di VRAM di una GPU consumer di fascia alta.
Dove funziona bene, e dove no
L’attention bidirezionale apre casi d’uso che i modelli autoregressivi gestiscono con difficoltà. Il code infilling ne è l’esempio più diretto: completare codice all’interno di un file esistente, dove il contesto arriva da entrambi i lati del cursore, è un compito non lineare che il paradigma sinistra-destra affronta in modo goffo. Analogamente, la generazione di strutture JSON rigide beneficia della capacità del modello di mantenere una visione globale del blocco mentre lo costruisce.
Google ha dimostrato l’effetto del fine-tuning con la risoluzione del Sudoku. Un Sudoku in formato stringa a 81 caratteri è un problema con vincoli intersecanti rigidissimi in cui ogni cifra dipende da tutte le altre nella riga, colonna e quadrante. Il modello base non riesce a risolverlo quasi mai. Dopo un fine-tuning con Hackable Diffusion (un toolbox JAX modulare), il tasso di successo sale all’80%, con il modello che converge in 12 passi invece dei 48 del modello base.
DiffusionGemma produce output di qualità inferiore rispetto al Gemma 4 autoregressivo standard. Non è un sostituto per applicazioni che richiedono la massima qualità, né è pensato per servire un alto volume di richieste. Questo modello dà il meglio quando lo fai girare sul tuo PC, per uso personale, una domanda per volta.
Un esperimento aperto
Il fatto che Google abbia scelto di rilasciare DiffusionGemma come open source con licenza Apache 2.0, e di costruirlo sulla stessa architettura di Gemma 4, semplifica notevolmente l’integrazione in framework come vLLM, Hugging Face Transformers, SGLang e MLX.
Se stai lavorando su applicazioni AI interattive in locale, su strumenti di editing in linea, o su pipeline che richiedono generazione di testo a bassa latenza, questo è un modello che vale la pena esplorare. Il punto di partenza è accessibile: i pesi sono su Hugging Face, il deployment su vLLM è documentato, e il fine-tuning con Unsloth o NVIDIA NeMo è già supportato. È previsto anche il supporto nativo per llama.cpp.
