DiffusionGemma de Google genera 256 tokens en paralelo y se autocorrige a medida que avanza

Los generadores de imágenes GenAI como Stable Diffusion no dibujan una imagen píxel a píxel de izquierda a derecha. Comienzan con ruido y refinan iterativamente toda la imagen en paralelo hasta que converge, en un proceso conocido como difusión. Durante años, aplicar ese mismo principio a la generación de texto había estado fuera de alcance a gran escala.

Los modelos de lenguaje estándar funcionan como una máquina de escribir: un token a la vez, de izquierda a derecha, sin posibilidad de revisar una salida comprometida. Ese patrón funciona en la nube, donde el tamaño de los lotes mantiene las GPU saturadas. Para implementaciones de inferencia local o de baja concurrencia, la GPU está inactiva la mayor parte del tiempo.

DiffusionGemma de Google, lanzado esta semana, es un modelo experimental de código abierto que aplica la difusión a la generación de texto a escala de producción. Construido sobre el gema 4 backbone y lanzado bajo la licencia Apache 2.0, es el primer modelo de lenguaje de difusión soportado de forma nativa en la plataforma de inferencia vLLM de código abierto. Genera un bloque de 256 tokens en paralelo en lugar de secuencialmente, y cada posición de token atiende a las demás. Google dice que DiffusionGemma genera texto hasta 4 veces más rápido que los modelos estándar en GPU. Con un tamaño de lote 1 en una sola Nvidia H100, la versión FP8 alcanza 1.008 tokens por segundo. En H200, alcanza 1288, aproximadamente seis veces la línea de base autorregresiva estándar, según los resultados de referencia de vLLM publicados hoy.

A pesar de las ganancias de velocidad, Google no sobrevendió el lanzamiento. la empresa publicación de lanzamiento reconoció directamente que la calidad de salida general de DiffusionGemma es inferior a la del Gemma 4 estándar y agregó: «Para aplicaciones que exigen la máxima calidad, recomendamos implementar el Gemma 4 estándar».

Qué hace DifusiónGemma

DiffusionGemma no genera tokens en orden. Comienza con un bloque de 256 tokens de marcador de posición aleatorios, en realidad un lienzo en blanco, y ejecuta múltiples pases de refinamiento en todo el bloque a la vez. En cada pasada, evalúa cada posición y fija aquellas en las que tiene más confianza. Las posiciones inciertas se aleatorizan y se reconsideran en la siguiente pasada, y el modelo utiliza lo que resolvió en la ronda anterior para informar el siguiente intento. El bloque converge progresivamente hasta que se estabilizan suficientes posiciones para anclar el resto.

De esa arquitectura se derivan dos cosas.

• Autocorrección. Un modelo autorregresivo que se compromete con un token incorrecto se queda atrapado en él, porque los tokens posteriores ya están condicionados al error. DiffusionGemma puede identificar posiciones de baja confianza y reevaluarlas en la siguiente pasada.

• Contexto bidireccional. Cada posición atiende a todas las demás posiciones del bloque simultáneamente, incluidos los tokens que aparecen más adelante en la secuencia. Eso hace que el modelo sea estructuralmente más adecuado para tareas de generación restringida donde falla la generación de izquierda a derecha.

Google demostró ambas propiedades con un solucionador de Sudoku perfeccionado. El modelo base no resolvió ningún acertijo. Después de realizar ajustes en un conjunto de datos de Sudoku, alcanzó una tasa de éxito del 80 % y convergió en 12 pasos de eliminación de ruido en lugar de 48. La ganancia de eficiencia provino directamente de la capacidad del modelo para autocorregirse y detenerse temprano.

como fue construido

DiffusionGemma se ejecuta como un modelo de mezcla de expertos de 26B que activa solo 3,8B de parámetros durante la inferencia. Cuantizado, cabe en 18 GB de VRAM en hardware de consumo, incluidas Nvidia RTX 4090 y 5090. Google y NVIDIA también lo optimizaron para servidores empresariales Hopper y Blackwell que utilizan núcleos NVFP4.

La integración de vLLM requirió nuevo trabajo porque DiffusionGemma no se ajusta al modelo de publicación estándar. Un lote típico de vLLM aplica el mismo tipo de atención a cada solicitud. Las solicitudes de DiffusionGemma alternan entre atención causal y bidireccional a medida que pasan por la lectura rápida, el refinamiento del lienzo y el compromiso de bloqueo. El equipo creó un cambio de atención por solicitud en los backends de Triton y FlashAttention 4 y reutilizó la ruta de decodificación especulativa existente para el ciclo de refinamiento.

La nueva interfaz ModelState que el equipo creó para esta integración está diseñada para admitir modelos de difusión adicionales en vLLM a medida que surgen.

Donde gana la velocidad y donde no

La ventaja de velocidad de DiffusionGemma es real pero condicional. El lugar donde se aplica depende completamente del contexto de implementación.

Los números. En el tamaño de lote 1 en un solo H100, los puntos de referencia publicados por vLLM sitúan el modelo FP8 aproximadamente cinco veces una línea de base autorregresiva estándar. En H200, aproximadamente seis veces. Esas cifras máximas reflejan condiciones óptimas: usuario único, hardware dedicado, cuantificación del 8PM.

Donde gana. Inferencia local, aplicaciones de usuario único y servicio de baja concurrencia. En esas condiciones, la GPU tiene cómputo adicional y el ancho de banda de la memoria es el cuello de botella. La generación de bloques paralelos de DiffusionGemma llena ese vacío.

Donde no es así. Servicio en la nube de alto rendimiento. Cuando un servidor procesa por lotes cientos de solicitudes simultáneas, los modelos autorregresivos ya saturan la computación disponible y la decodificación paralela de DiffusionGemma proporciona rendimientos decrecientes.

El techo de calidad. Guilherme O’Tina, investigador de IA, ponle un punto más fino en X. «Los artefactos locales y las alucinaciones son problemas diferentes y eso decide dónde gana realmente», escribió O’Tina.

como se compara

Los modelos de lenguaje de difusión no son nuevos. Los investigadores los han construido a escalas más pequeñas durante varios años, y Codificador de mercurio de Inception Labs aplicó el enfoque comercialmente a tareas de codificación en 2025. Lo que DiffusionGemma agrega es escala: una columna vertebral de 26 mil millones de MoE, servicio vLLM nativo y un modelo ajustado a instrucciones de propósito general en lugar de uno específico de dominio.

La comparación más útil para los ingenieros que evalúan esto con las herramientas de inferencia existentes es la decodificación especulativa, y la distinción es importante. La decodificación especulativa mantiene un modelo objetivo autorregresivo estándar y utiliza un modelo preliminar más pequeño para adivinar varias fichas por delante. El modelo objetivo los verifica de una sola vez. Si el muestreo es correcto, la distribución de la producción permanece idéntica al objetivo. La arquitectura no ha cambiado.

Andres Kuncevichun investigador de ML e IA centrado en sistemas de producción de IA, lo puso directamente en X. «DiffusionGemma es diferente. No solo adivina tokens futuros. Crea un lienzo ruidoso de 256 tokens y elimina repetidamente el ruido de todo el bloque en paralelo. Así que no es solo un truco de decodificación, es un paradigma de generación diferente», escribió Kuncevich.

En comparación con el Gemma 4 estándar, el intercambio es velocidad por calidad. Los datos de referencia de Google muestran a DiffusionGemma por debajo del estándar Gemma 4 en métricas generales de calidad de salida, y la brecha varía según la tarea.

En tareas estructuradas restringidas, incluido el relleno de código, la generación de plantillas y los problemas que requieren propagación de restricciones bidireccionales, la arquitectura tiene una ventaja estructural que el ajuste fino puede revelar, como lo demuestra el resultado del Sudoku. En la generación abierta, el Gemma 4 estándar sigue siendo la opción más fuerte.

Qué significa esto para las empresas

DiffusionGemma presta servicios a través de un punto final estándar compatible con vLLM OpenAI sin que se requieran cambios en la canalización específicos de difusión.

Esta no es una actualización del modelo de uso general.

Para los equipos que ejecutan inferencia local o de baja concurrencia, la elección de arquitectura acaba de ampliarse. Hasta ahora, reducir la latencia de generación en hardware GPU dedicado significaba utilizar un modelo más pequeño y aceptar el compromiso de calidad. DiffusionGemma ofrece una tercera ruta con el mismo espacio de parámetros, en hardware de consumo, con soporte vLLM el mismo día.

Para cargas de trabajo de generación restringida, vale la pena evaluar la atención bidireccional. El relleno de código, la generación de datos estructurados y las tareas donde el resultado correcto depende del contexto aún no generado son donde esta arquitectura tiene una ventaja estructural.

La interfaz ModelState creada para esta integración está diseñada para generalizarse a medida que surgen modelos de difusión adicionales.

La compensación por la calidad es real y Google lo reconoce. Para los equipos que ejecutan inferencia local en hardware GPU dedicado, vale la pena probarlo.