DiffusionGemma: Google lleva los modelos de difusión a la generación de texto

Google DeepMind publicó DiffusionGemma, una nueva rama experimental dentro de la familia Gemma. No sigue simplemente la ruta tradicional de los grandes modelos autoregresivos que predicen un token cada vez. En cambio, lleva la idea de los modelos de difusión a la generación de texto: primero crea un lienzo textual con ruido y luego refina todo el segmento mediante varias rondas de eliminación de ruido.

La posición oficial es clara: es un modelo abierto experimental para investigadores y desarrolladores que quieran explorar flujos de generación de texto locales, interactivos y de baja latencia. No está pensado para sustituir por completo al Gemma 4 estándar en escenarios de calidad de producción.

Información clave

Elemento	DiffusionGemma
Fecha de lanzamiento	2026-06-10
Naturaleza del modelo	Modelo abierto experimental
Base	Gemma 4 backbone + Gemini Diffusion research
Arquitectura	26B total Mixture of Experts, con 3.8B parámetros activos durante inferencia
Método de generación	Difusión de texto con denoising paralelo sobre un canvas de 256 tokens
Licencia	Apache 2.0
Objetivo de velocidad	Hasta unas 4x de mejora en generación de texto en GPU dedicadas
Hardware típico	Con cuantización puede desplegarse dentro de unos 18GB de VRAM en GPU de consumo de gama alta
Disponibilidad	Hugging Face, Kaggle, Google Cloud Model Garden

Hay dos puntos especialmente importantes. Primero, no es un modelo pequeño: es un MoE de 26B. Segundo, durante la inferencia solo activa 3.8B parámetros y trata de desplazar el cuello de botella desde el ancho de banda de memoria hacia el cómputo.

En qué se diferencia de un LLM normal

Un LLM autoregresivo tradicional funciona como una máquina de escribir: genera de izquierda a derecha, token por token. Es un método estable, maduro y adecuado para texto largo de alta calidad. Pero en inferencia local para un solo usuario aparece un problema práctico: muchas veces la GPU no queda suficientemente alimentada y el cuello de botella está en leer pesos repetidamente y decodificar token por token.

DiffusionGemma cambia de enfoque. Primero crea un canvas aleatorio de 256 tokens y luego hace varias rondas de refinement paralelo. En cada ronda, los tokens del canvas pueden verse entre sí. El modelo no solo mira hacia el pasado; puede usar atención bidireccional dentro del bloque.

Esto trae tres resultados directos:

La generación no es estrictamente de izquierda a derecha; todo el bloque converge a la vez.
El modelo puede corregir posiciones anteriores durante el proceso de generación.
Resulta más natural para infilling de código, edición en línea, cierre de formatos, Sudoku y otras tareas con restricciones no lineales.

En otras palabras, DiffusionGemma no busca “un modelo más grande por la misma ruta”, sino que prueba otra ruta para generar texto: tratar el texto como un canvas que puede pulirse repetidamente.

Por qué puede ser más rápido

El punto clave que Google enfatiza es que DiffusionGemma intenta mover el cuello de botella desde memory bandwidth hacia compute.

Un modelo autoregresivo accede repetidamente a los pesos del modelo por cada token generado. En escenarios locales, de un solo usuario y batch bajo, la potencia de cómputo de la GPU no siempre se utiliza bien. DiffusionGemma procesa un canvas de 256 tokens de una vez, dando a la GPU un bloque mayor de trabajo paralelo y facilitando que los tensor cores trabajen.

Los datos publicados por Google incluyen:

Más de 1000 tokens/s en una sola NVIDIA H100.
Más de 700 tokens/s en una NVIDIA GeForce RTX 5090.
Hasta unas 4x de mejora en generación de texto en GPU dedicadas.

Pero esta conclusión de velocidad tiene límites. Google también advierte que la ventaja de DiffusionGemma encaja sobre todo en inferencia local, de baja concurrencia, con un único acelerador y batch bajo o medio. En servicios cloud de alto QPS, los modelos autoregresivos pueden usar lotes grandes para saturar el hardware, reduciendo la ventaja de la decodificación paralela de DiffusionGemma e incluso aumentando el coste de servicio.

Esto importa: es más una nueva ruta para interacción local en tiempo real que un acelerador universal para todos los despliegues.

Cómo funciona la arquitectura

La guía para desarrolladores da una explicación más concreta. La generación de DiffusionGemma puede dividirse en dos fases:

Prefill / Incremental Prefill

Usa causal attention para leer el prompt y escribir el contexto en la KV cache. Para texto largo, después de completar cada bloque de 256 tokens, el modelo confirma el resultado en la KV cache y procesa el siguiente bloque.
Denoising

Usa bidirectional attention para eliminar ruido iterativamente en el canvas actual. Los query tokens del bloque actual pueden ver otros tokens del canvas y también usar el contexto histórico ya escrito en la KV cache.

Este diseño se llama block autoregressive denoising. No abandona por completo la secuencialidad: mantiene estabilidad entre bloques en textos largos, mientras permite generación paralela dentro de cada bloque.

El compromiso es razonable. Si todo fuera paralelo, la consistencia de textos largos sería difícil; si todo fuera autoregresivo, volveríamos al cuello de botella token por token. DiffusionGemma elige “orden entre bloques, difusión dentro del bloque”.

Escenarios adecuados

DiffusionGemma no está pensado principalmente para chat normal, sino para escenarios interactivos que necesitan baja latencia, reescritura rápida, autocompletado local y restricciones globales.

Direcciones típicas:

Edición en línea: el usuario cambia una frase y el modelo completa rápidamente un reemplazo local.
Code infilling: no escribir desde el principio del archivo hasta el final, sino rellenar un hueco en medio.
Cierre de formatos como Markdown / JSON / XML: el modelo puede ver todo el bloque de salida y corregir mejor paréntesis, etiquetas y listas.
Estructuras textuales no lineales: grafos, tablas, Sudoku, secuencias de aminoácidos, estructuras matemáticas de grafos, etc.
Herramientas locales en tiempo real: herramientas de desarrollo, plugins de editores y asistentes de escritorio que necesitan actualizar mientras el usuario escribe.

La guía oficial también incluye un ejemplo de fine-tuning con Sudoku. El modelo base no está entrenado específicamente para resolver Sudoku y su tasa de éxito inicial está cerca de 0%. Con una receta sencilla de JAX SFT, la precisión sube al 80% y bajan los pasos de inferencia. El objetivo del ejemplo no es decir que “sirve para Sudoku”, sino mostrar que el denoising bidireccional encaja mejor con tareas de fuertes restricciones, muchas variables y consistencia global.

Escenarios poco adecuados

DiffusionGemma sigue siendo experimental, así que no basta con mirar la velocidad.

Google lo dice de forma directa: como prioriza velocidad y generación con diseño paralelo, su calidad general de salida es inferior a la de Gemma 4 estándar. Para aplicaciones que requieren la máxima calidad, se sigue recomendando Gemma 4 estándar.

Tampoco encaja necesariamente en:

Escritura larga de alta calidad.
Servicios API cloud de alta concurrencia.
Tareas de producción que requieren gran estabilidad de salida y exactitud factual.
Inferencia local basada principalmente en memoria unificada de Apple Silicon.

El último punto también viene de la explicación oficial: la aceleración de DiffusionGemma depende de una alta arithmetic intensity en el acelerador. Arquitecturas de memoria unificada como Apple Silicon suelen estar más limitadas por ancho de banda de memoria durante la inferencia, por lo que quizá no vean la misma aceleración relativa frente a modelos autoregresivos.

Despliegue y herramientas

DiffusionGemma ya está disponible en Hugging Face, y también puede accederse desde Kaggle y Google Cloud Model Garden. La guía oficial para desarrolladores da un ejemplo de servidor local OpenAI-compatible con vLLM:

1
2
3
4
5
6
7
8
9


vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}' \
  --diffusion-config '{"canvas_length": 256}' \
  --enable-chunked-prefill

El ecosistema mencionado por Google también incluye:

vLLM
Hugging Face Transformers
SGLang
MLX
Hackable Diffusion
Unsloth
NVIDIA NeMo
NVIDIA NIM

Además, Google afirma que el soporte para llama.cpp llegará pronto. Para usuarios de modelos locales, esa señal es importante, pero hasta que el soporte esté realmente disponible, conviene guiarse por la herramienta que funcione en la práctica.

Relación con Gemma 4

DiffusionGemma no es un sustituto de Gemma 4. Es más bien una rama experimental de la familia Gemma 4.

Puede entenderse así:

Gemma 4 estándar: mejor para salida de producción donde la calidad es prioritaria.
DiffusionGemma: mejor para exploración de velocidad, baja latencia, interacción local y generación no lineal.

Se construye sobre el backbone de Gemma 4 y la investigación de Gemini Diffusion, pero su objetivo no es simplemente mejorar benchmarks. Quiere comprobar si la difusión de texto puede cambiar los flujos de trabajo de los desarrolladores, especialmente aquellas formas de interacción que la generación autoregresiva ha limitado: editores en tiempo real, autocompletado en medio del código y reparación instantánea de contenido estructurado.

Por qué merece atención

DiffusionGemma merece atención no porque se convierta de inmediato en “el modelo de texto más fuerte”, sino porque mueve un supuesto básico de la generación de texto.

Durante los últimos años, los modelos de texto han tomado casi por defecto la ruta autoregresiva. Es una ruta madura, pero también convierte la salida en un proceso lineal: primero se escribe el principio, luego lo demás, y los errores tempranos son difíciles de corregir. La generación textual por difusión ofrece otra posibilidad: construir primero un todo y luego corregir partes locales repetidamente hasta que todo el bloque quede claro.

Esto tiene mucho potencial para herramientas de desarrollo. La edición real no empieza siempre en una hoja en blanco y avanza hacia abajo. Incluye insertar, borrar, completar, arreglar formato, corregir zonas locales y rellenar huecos intermedios. La estructura de DiffusionGemma se parece más a ese escenario de “edición local + restricciones globales”.

Resumen

DiffusionGemma es un modelo abierto experimental cuyo punto central es sustituir la generación tradicional token por token por difusión de texto y denoising paralelo dentro de bloques. En GPU dedicadas, escenarios locales de baja concurrencia e interacción en tiempo real, puede ofrecer una ventaja de velocidad clara. También encaja mejor en edición en línea, autocompletado de código, texto estructurado y tareas con restricciones de múltiples variables.

Pero no es un sustituto de Gemma 4 con calidad de producción. Por ahora encaja mejor en investigación, prototipos de herramientas y experimentos de desarrolladores. Al elegir modelo, conviene colocarlo en la columna de “modelo de interacción de baja latencia”, no en la de “mejor modelo generalista”.

Referencias: