Todos los Trucos de 'IA Más Rápida' Eran Parches. DiffusionGemma Es el Primer Modelo que Realmente Puedes Ejecutar

Prediciendo 1 token a la vez. Eso es lo que ha estado limitando a los modelos desde el principio, incluidos los locales.

La limitación no tenía nada que ver con hardware insuficiente o modelos demasiado pequeños. Era arquitectónica, integrada desde el inicio.

Para generar cada token, tu GPU carga todos los pesos del modelo desde memoria, produce 1 token, y luego empieza de nuevo. Ese cuello de botella del ancho de banda de memoria es por lo que la inferencia local siguió siendo frustrante incluso en hardware decente. Y es por lo que 5 años de optimizaciones (flash attention, cuantización, decodificación especulativa) trabajaron alrededor del mismo techo estructural sin moverlo jamás.

Hay algo que pasa cuando te das cuenta de que has estado optimizando la métrica correcta en la capa equivocada. Flash attention fue un avance genuino, la cuantización INT4 fue un avance genuino, y la H100 a $40,000 por tarjeta fue un avance genuino para quien pudiera pagarla. Y nada de eso movió la limitación fundamental. Los pesos aún tenían que cargarse para cada token individual. Los tensor cores de la GPU, diseñados para operaciones masivas de matrices en paralelo, estaban mayormente inactivos durante la inferencia, solo esperando el siguiente ciclo de memoria. Cada ingeniero que ejecutó inferencia local en una GPU de consumo de gama alta sintió esto como una especie de frustración de bajo grado: los números deberían funcionar, pero no lo hacen del todo.

La Carrera que Nadie Cuestionó

Flash attention llegó en 2022. Legítimamente brillante: reescribir el cómputo de atención para ser consciente de I/O, manteniendo valores intermedios en SRAM en lugar de escribir constantemente de vuelta a HBM. Aceleraciones reales, medibles, desplegadas en todas partes en 18 meses. El paper obtuvo 15,000 citas en aproximadamente 2 años.

Luego el campo siguió agregando capas sobre la misma base. Cuantización INT4, GGUF, decodificación especulativa, la LPU de Groq construida desde cero alrededor de inferencia AR, H100s a $40,000 por tarjeta, luego H200s, luego GB200s. Empresas enteras valoradas en miles de millones bajo la premisa de que hacer AR más rápido era el problema que valía la pena resolver. Groq construyó silicio personalizado desde cero alrededor de inferencia AR, y la industria lo llamó visionario. Nadie en la sala sugirió que tal vez la arquitectura misma era la pregunta.

Toda la industria se organizó alrededor de un solo cuello de botella. Nadie cuestionó si el cuello de botella era arquitectónico.

Para ser justos: ¿por qué lo harían? Los modelos se enviaron, los productos funcionaron. El stack de entrenamiento, la infraestructura de servicio de inferencia, el ecosistema de kernels CUDA, cada patrón de despliegue desde vLLM hasta TGI hasta Ollama, todo construido alrededor de predicción autorregresiva del siguiente token. Cuestionar la arquitectura desde dentro de ese ecosistema es como cuestionar si los autos deberían tener ruedas mientras estás en medio de diseñar una llanta más rápida. El costo de cambio no era solo técnico. Era el costo hundido acumulado de la industria: cada kernel CUDA, cada optimización de servicio, cada compra de hardware justificada contra números de throughput AR.

Inception Labs fue el primero en realmente enviar algo diferente. Mercury salió a principios de 2025, Mercury 2 a principios de 2026, 1,000+ tokens por segundo. Números genuinamente impresionantes. Completamente inaccesible: API comercial, pesos cerrados, no podías ejecutarlo tú mismo. Útil como señal de mercado, no accionable para quien construyera en su propio hardware.

DiffusionGemma se envió el 10 de junio de 2026, pesos abiertos bajo Apache 2.0, soporte vLLM desde el día 0, ejecutándose en una RTX 4090.

Para la comunidad de desarrolladores, "primer lanzamiento abierto de un laboratorio tier-1" significa soporte vLLM día-0, una tarjeta de modelo HuggingFace, integración Unsloth, y una comunidad que tendrá fine-tunes interesantes en días. La brecha entre un paper de investigación y algo en lo que realmente puedes construir se cerró aproximadamente 18 meses más rápido de lo que cualquiera esperaba cuando Gemini Diffusion se anunció como experimento en I/O 2025.

Esta es la diferencia entre "alguien probó que funciona en teoría" y "puedes descargar los pesos esta noche".

5 años de workarounds. La solución real corrió en tu GPU ayer.

Lo que DiffusionGemma Realmente Cambia (y lo que No)

El bucle de inferencia AR está limitado por memoria. Para generar 256 tokens, tu GPU carga la matriz de pesos completa desde memoria 256 veces, 1 carga por token. Los tensor cores, diseñados para multiplicaciones de matrices en paralelo a escala masiva, ejecutan su cómputo real en aproximadamente 1% del tiempo total. El otro 99% es esperar que lleguen datos desde VRAM. Imagina dotar una cocina con chefs con estrella Michelin y enrutar cada plato individual a través de un almacén a 300 metros de distancia entre platos. Esa es tu H100 en inferencia AR. Por eso escalar los FLOPS teóricos de una GPU raramente se tradujo linealmente a velocidad de inferencia: no estabas limitado por cómputo, estabas limitado por memoria, y comprar una tarjeta con más tensor cores ayudaba menos que comprar una con mayor ancho de banda de memoria. Cada optimización desde flash attention en adelante trabajaba en acortar esa espera del 99%, no en eliminarla. El techo siempre era el mismo techo, solo se aproximaba desde un ángulo ligeramente diferente.

DiffusionGemma carga los pesos una vez por pasada de denoising y genera 256 tokens en paralelo. El cuello de botella cambia. Los tensor cores son ahora el techo real, ejecutando atención bidireccional sobre el bloque completo de 256 tokens en cada pasada hacia adelante. Para esto fueron diseñados estos chips. La pared del ancho de banda de memoria no desaparece, deja de ser lo que te limita.

Números de Google y NVIDIA: 700+ tokens/seg en RTX 5090, 1,000+ en H100, 4x más rápido que Gemma 4 AR en hardware equivalente. El modelo es de 26B parámetros como Mixture of Experts, 3.8B activos durante inferencia, funciona en 18GB VRAM cuando está cuantizado.

Las limitaciones son reales y vale la pena declararlas claramente.

DiffusionGemma queda atrás de Gemma 4 AR en benchmarks de razonamiento por un margen significativo. AIME 2026: 69.1% vs 88.3%. LiveCodeBench v6: 69.1% vs 77.1%. GPQA Diamond: 73.2% vs 82.3%. Estas son brechas de 15-20 puntos en tareas de razonamiento difícil, no errores de redondeo.

La ventana de contexto es de 8,192 tokens. La mayoría de modelos AR actuales funcionan a 128K+. Para cualquier cosa agéntica o de contexto largo, esto es una pared real. Un archivo TypeScript moderadamente complejo consume 3,000 tokens. 3 archivos y ya estás en el techo.

Google mismo lo llama "experimental". Las recetas de fine-tuning aún se estaban publicando en el lanzamiento. El soporte MLX para Apple Silicon estaba incompleto el día 0. Para servicio en la nube de alto volumen, los modelos AR aún procesan en lotes más eficientemente a escala.

El rendimiento es real, y también lo es el techo. La pregunta es si el techo importa para tu caso de uso.

La Prueba Más Allá de la Velocidad

Un tablero de Sudoku tiene 81 celdas. Cada una está limitada por su fila, su columna, y su cuadrado 3x3 simultáneamente. Para resolverlo correctamente, necesitas mantener todas esas limitaciones a la vista a la vez.

Un modelo autorregresivo genera 1 celda a la vez, de izquierda a derecha, de arriba a abajo. Para cuando llena la celda 72, no puede volver y corregir la celda 3. Se condiciona solo en lo que ya generó. Esto no es una falla de escala o un problema de datos de entrenamiento. Es una propiedad estructural de la generación secuencial. Puedes hacer un modelo AR más grande, más rápido, mejor en reconocimiento de patrones, y aún llenará celdas sin resolución de limitaciones globales, porque estructuralmente no puede mirar hacia adelante.

Google ejecutó una prueba sobre esto directamente. Modelo base DiffusionGemma en puzzles Sudoku: 0% tasa de éxito. Fine-tuning SFT estándar con una receta JAX en un dataset Sudoku: 80% tasa de éxito, con 4x menos pasos de inferencia que la línea base.

La mejora vino de la atención bidireccional, no de velocidad bruta. Cada token en el bloque de 256 tokens atiende a cada otro token durante la generación. El modelo ve todo el tablero a la vez. Propaga limitaciones a través del bloque completo en cada pasada de denoising y se autocorrige antes de que el output se finalice.

Creo que aquí es donde se subestima la significancia a largo plazo de los LLMs de difusión, incluso en la cobertura del lanzamiento. Los números de velocidad obtienen los titulares. La bidireccionalidad es la propiedad más interesante.

Tu codebase es más difícil que un tablero de Sudoku. Cada función está limitada por los tipos que retorna, las APIs que llama, los contratos que asume implícitamente a través de archivos. Code infilling (llenar el cuerpo de una función dado lo que viene antes y después) es estructuralmente exactamente este problema. Los modelos AR manejan infilling a través de un objetivo de entrenamiento especial fill-in-the-middle, que es un workaround para la limitación direccional. DiffusionGemma lo maneja arquitectónicamente. Mismo problema, diferente capa de la solución. El mismo patrón aparece en migraciones de esquemas SQL, generación de archivos de configuración, cualquier cosa donde estés llenando estructura con limitaciones duras en ambos lados. Una migración agregando una columna necesita ser consistente tanto con el esquema existente como con las consultas downstream que la referencian. AR genera de izquierda a derecha sin reconsiderar elecciones anteriores basándose en limitaciones posteriores. Puedes trabajar alrededor de esto con prompting cuidadoso y generación multi-pasada. Workarounds, cada uno de ellos.

Pasé 3 meses persiguiendo firmas de tipo sutilmente inconsistentes a través de archivos en sesiones de Claude Code. La ventana de contexto estaba dividiendo los contratos relevantes entre 2 sesiones. La atención bidireccional dentro de un bloque de generación no resuelve completamente la coherencia cross-file, pero cambia dónde se origina la inconsistencia. Problema diferente, solución diferente.

Cuándo Cambiar, Cuándo Quedarse

El arbitraje para un builder ejecutando Claude Code diariamente se ve así.

DiffusionGemma tiene sentido para tareas donde el cuello de botella es throughput en outputs cortos a medianos con limitaciones estructurales: generación de boilerplate en lote, code infilling donde el contexto circundante está disponible, llenar plantillas estructuradas (esquemas API, archivos de configuración, stubs de migración), ciclos de iteración rápida donde estás regenerando 10-20 variantes bajo 4,000 tokens. El modelo está disponible ahora, pesos abiertos bajo Apache 2.0, listo para vLLM, desplegable en RTX 4090. El costo variable de API en esas tareas va a cero. La economía cambia de manera específica y real para workflows locales de alta repetición.

Quédate con Claude para cadenas de razonamiento multi-paso, debugging que requiere rastrear lógica a través de muchos pasos, decisiones de arquitectura que necesitan contexto coherente grande, cualquier tarea de producción donde necesites más de 8K tokens en una sola pasada, cualquier cosa en el tier de razonamiento pesado donde ese delta de 15-20 puntos es la diferencia entre un output útil y una respuesta plausible pero incorrecta.

La limitación de ventana de contexto es el limitador práctico real. 8,192 tokens suena como mucho hasta que un solo archivo moderadamente complejo toma 3,000 de ellos. Eso no es un problema de fine-tuning. Está integrado en el tamaño actual del bloque de generación. Versiones futuras empujarán esto hacia arriba. Por ahora hace de DiffusionGemma una herramienta específica para tareas, no un reemplazo general drop-in.

Karen de Contabilidad preguntaría si esto justifica comprar una segunda GPU. La respuesta honesta: si ya estás ejecutando un stack de modelo local en una RTX 4090, es una situación de pull-and-test, no una decisión de hardware. Si estás empezando desde nada, el punto de equilibrio en hardware dedicado vs créditos API requiere números reales de throughput de tu workflow real, no entusiasmo sobre el benchmark 😅. La receta de fine-tuning JAX en la guía del desarrollador está documentada lo suficiente como para que un experimento SFT de 500 muestras en un dominio específico sea un proyecto de fin de semana (más alcanzable que "voy a reescribir esto en Rust este fin de semana" de todos modos).

En el lado de infra: si ya estás enrutando tareas a través de diferentes backends de modelo, el patrón detrás de construir agentes CLI-nativos para workloads sensibles al throughput se vuelve más relevante con un backend de difusión local en la mezcla. DiffusionGemma encaja limpiamente en esa arquitectura.

La Suposición que Nunca Cuestionaste

Tengo una integración WooCommerce en mi pipeline que parsea feeds CSV de distribuidor en un formato que no ha cambiado desde 2019. He reconstruido la infraestructura circundante 3 veces. El parser CSV sigue siendo la misma función, mismo orden de columnas, mismo workaround regex para un caso edge que encontré en 2021. Nadie lo toca porque funciona. La pregunta "¿debería esto seguir siendo un parser CSV en 2026?" nunca se ha hecho. En algún punto dejó de ser una decisión y se convirtió en mobiliario.

Cada stack tiene mobiliario.

El patrón aparece cada vez que una limitación técnica permanece estable lo suficiente como para volverse invisible. En 2023, inferencia local significaba cargar un modelo 7B y ver tokens llegar a 3 por segundo. La latencia lo hacía inútil para cualquier cosa interactiva. Los desarrolladores lo probaron, lo encontraron impráctico, cambiaron a llamadas API, y la decisión se solidificó: la inferencia local es para hobbyistas, el trabajo real va a través de la API. Lo que nadie codificó en esa decisión fue la fecha de expiración. "La inferencia local es lenta" suena como un hecho sobre física. "La inferencia local en hardware 2023 con modelos 2023 era demasiado lenta para ese caso de uso" es una afirmación sobre un contexto específico, y los contextos específicos cambian.

AR no se eligió sobre difusión porque alguien ejecutó una comparación y concluyó que era mejor. Se eligió porque la generación de texto por difusión no era viable. La suposición "usamos AR" era una limitación pragmática que se volvió invisible en el momento en que dejó de ser contestada.

Si estás trabajando en cuáles defaults en tu stack vale la pena revisar, cómo hice las decisiones de enrutamiento intencionales con contratos de prompt es donde empecé. O si el stack mismo es territorio más nuevo, Vibe Coding, For Real cubre construir sobre principios explícitos desde el inicio, disponible gratis en Kindle Unlimited.

Para los builders: si tu workflow tiene una capa de generación repetitiva con limitaciones estructurales, empieza con la receta de fine-tuning Sudoku en la guía del desarrollador. Ejecútala, mira qué cambia entre 0% y 80% de precisión, y pregúntate qué implica eso para tus propias tareas con limitaciones pesadas.

La decisión de enrutamiento es ahora una decisión real de arquitectura: no qué API es más barata este mes, sino qué limitación estructural puede resolver este modelo que el otro arquitectónicamente no puede.

Fuentes

• DiffusionGemma: The Developer Guide, Google Developers Blog, 10 de junio, 2026
• Run DiffusionGemma on NVIDIA, NVIDIA Technical Blog, 10 de junio, 2026
• DiffusionGemma benchmarks, Unsloth, junio 2026
• Google's DiffusionGemma: first open diffusion release from a tier-one lab, Decrypt, 10 de junio, 2026

Este post puede contener enlaces de afiliado. Si haces clic en ellos, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).