DiffusionGemma: generación de texto 4 veces más rápida

 (blog.google)
3 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • DiffusionGemma es un modelo abierto experimental 26B MoE con licencia Apache 2.0 que genera bloques completos de texto al mismo tiempo mediante difusión de texto
  • En lugar de la generación secuencial de tokens de los LLM autorregresivos habituales, usa generación paralela de 256 tokens para ofrecer una generación de texto hasta 4 veces más rápida en GPUs dedicadas
  • Durante la inferencia, solo activa 3.8B parámetros de los 26B totales y, con cuantización, puede funcionar dentro del límite de 18 GB de VRAM en GPUs dedicadas avanzadas para consumo
  • La atención bidireccional y la autocorrección iterativa le dan ventajas en edición en línea, autocompletado de código, secuencias de aminoácidos y grafos matemáticos, es decir, tareas con estructuras no lineales
  • Como es un modelo experimental priorizado para velocidad y generación de layouts en paralelo, la calidad general de salida es inferior a la de Gemma 4 estándar, por lo que para aplicaciones que requieren la máxima calidad se recomienda desplegar Gemma 4 estándar

Nuevo valor para desarrolladores

  • DiffusionGemma es un modelo abierto experimental que explora la difusión de texto y va más allá del procesamiento secuencial token por token de los LLM autorregresivos habituales al generar bloques completos de texto al mismo tiempo
  • Este modelo es un Mixture of Experts (MoE) de 26B disponible bajo licencia Apache 2.0 y ofrece generación de texto hasta 4 veces más rápida en GPU
  • Se basa en la inteligencia por parámetro de la familia Gemma 4 y en Gemini Diffusion research, e integra una nueva cabeza de difusión para maximizar la velocidad de generación
  • Los modelos Gemma 4 autorregresivos siguen siendo el estándar para salidas de producción de alta calidad, mientras que DiffusionGemma está diseñado para investigadores y desarrolladores que exploran flujos de trabajo locales e interactivos donde la velocidad es crítica

  • Tradeoffs clave

    • La inferencia rápida traslada el cuello de botella de decodificación del ancho de banda de memoria al cómputo, ofreciendo una salida de tokens hasta 4 veces más rápida en GPUs dedicadas
    • Genera más de 1000 tokens por segundo en una sola NVIDIA H100 y más de 700 tokens por segundo en una NVIDIA GeForce RTX 5090
    • La accesibilidad de hardware proviene de una arquitectura que activa solo 3.8B parámetros durante la inferencia de los 26B totales del MoE
    • Con cuantización, puede funcionar dentro del límite de 18 GB de VRAM de GPUs dedicadas avanzadas para consumo
    • La atención bidireccional genera 256 tokens en paralelo en cada paso hacia adelante, permitiendo que todos los tokens se referencien entre sí
    • Esto aporta ventajas en dominios no lineales como edición en línea, autocompletado de código, secuencias de aminoácidos y grafos matemáticos
    • La autocorrección refina iterativamente la salida mientras el modelo evalúa el bloque completo de texto de una sola vez, corrigiendo errores en tiempo real
    • Su estado experimental y la recomendación para producción son claros: como prioriza la velocidad y la generación de layouts en paralelo, la calidad general de salida es inferior a la de Gemma 4 estándar

  • Ejemplo de fine-tuning

    • El rendimiento en tareas específicas puede mejorar con fine-tuning
    • Unsloth hizo fine-tuning de DiffusionGemma para resolver sudoku, una tarea que suele ser difícil para los modelos autorregresivos porque cada token depende de tokens futuros
    • La atención bidireccional de DiffusionGemma hace mucho más sencillas tareas como el sudoku

Por qué usar difusión en texto

  • La comunidad de investigación en IA ha explorado durante años la generación de texto basada en difusión, pero aplicarla a modelos grandes seguía siendo un reto
  • DiffusionGemma aborda este problema cambiando la forma en que el modelo utiliza el hardware

  • Tradeoffs frente a modelos existentes

    • La mayoría de los modelos de lenguaje generan un token a la vez de izquierda a derecha, como una máquina de escribir
    • En la nube, este enfoque es eficiente porque los servidores pueden agrupar solicitudes de miles de usuarios y compartir la carga del hardware
    • Cuando un solo usuario lo ejecuta en local, la generación palabra por palabra no aprovecha suficientemente una GPU o TPU dedicada, y gran parte del tiempo el hardware queda esperando la siguiente “pulsación”
    • DiffusionGemma redacta al mismo tiempo un párrafo completo de 256 tokens, entregando al procesador de la computadora un bloque de trabajo más grande de una sola vez
    • Esta arquitectura transforma la inferencia del modelo de una máquina de escribir secuencial a una gran imprenta que produce bloques completos de texto al mismo tiempo

  • Mejora de velocidad enfocada en inferencia local y de baja concurrencia

    • La mejora de velocidad de DiffusionGemma está diseñada para inferencia local y para inferencia de baja concurrencia
    • En serving en la nube con alto QPS, los modelos autorregresivos también pueden desplegarse para saturar eficientemente el cómputo
    • En entornos de alto QPS, la ventaja de decodificación paralela de DiffusionGemma se reduce y el costo de serving puede ser mayor
    • La ventaja de throughput es más fuerte en un solo acelerador con tamaños de lote de bajos a medianos

Cómo funciona la difusión de texto

  • La difusión de texto aplica al texto un proceso similar al de la generación de imágenes con IA, que comienza con ruido visual y mejora iterativamente hasta obtener una imagen nítida
  • En la primera etapa, el lienzo, el modelo comienza desde un lienzo compuesto por tokens placeholder aleatorios
  • En la etapa de refinamiento iterativo, el modelo realiza múltiples pasadas, fija los tokens correctos y los usa como pistas de contexto para refinar el resto
  • En la etapa final de refinamiento, el texto converge hacia una salida de alta calidad
  • Como el modelo puede procesar párrafos completos durante la generación, se vuelven posibles patrones de funcionamiento como cerrar correctamente formato complejo de Markdown o generar y renderizar código casi en tiempo real

Cómo empezar

  • Los pesos del modelo experimental están disponibles bajo la licencia permisiva Apache 2.0 y se puede acceder a ellos en Hugging Face
  • En la DiffusionGemma developer guide se puede ver cómo integrarlo, y en A Visual Guide to DiffusionGemma se puede profundizar en sus mecanismos internos
  • El serving del modelo puede realizarse con MLX, vLLM, Hugging Face Transformers
  • La integración con vLLM cuenta con el apoyo de Red Hat
  • Para experimentación rápida, se ofrece un tutorial de fine-tuning basado en Hackable Diffusion, una caja de herramientas modular de JAX diseñada para composición
  • El fine-tuning también puede explorarse con Unsloth y NVIDIA NeMo
  • El soporte oficial para llama.cpp llegará pronto

Optimización y entorno de ejecución

  • En colaboración con NVIDIA, se realizaron optimizaciones en toda la pila de hardware para ofrecer compatibilidad y rendimiento tanto en entornos de consumo como en sistemas empresariales
  • Los entornos de consumo admiten cuantización para GPUs GeForce RTX 5090 y 4090
  • Los entornos empresariales ofrecen alto rendimiento en Hopper y Blackwell con kernels avanzados NVFP4
  • También están contemplados NVIDIA DGX Spark y DGX Station para despliegue local de escritorio, así como RTX PRO para especialistas en IA
  • El soporte nativo de NVFP4 de punto flotante de 4 bits acelera el throughput de cómputo, permitiendo que el modelo se ejecute con mayor velocidad y una precisión casi sin pérdida
  • Se puede elegir entre ejecutar en GPU dedicada de escritorio, Gemini Enterprise Agent Platform Model Garden, o NVIDIA NIM

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Hace poco me cambié a OpenCode y probé bastante modelos que no son de los principales laboratorios frontier de EE. UU.; inesperadamente, el modelo que más me gustó fue Mercury
    No porque “fuera inteligente”, sino porque era absurdamente rápido. Se sentía más cercano a la programación en pareja que a la experiencia moderna tipo agente donde pones un prompt y esperas; obtenía las ventajas de la IA, pero también recuperaba parte de la sensación de programar de antes de la IA, así que era más divertido. No se sentía como una tragamonedas donde metes un prompt, esperas y rezas para que vaya en la dirección correcta; también terminé usando más seguido modelos pequeños como Gemini Flash Lite o GPT Mini/Nano. Me entusiasma que haya salido un modelo de pesos abiertos y pienso probarlo de inmediato

    • Si puedes ejecutar pruebas rápido y barato, y además crear rápido métricas de bajo costo para distinguir código malo o hecho al aventón, entonces cuando el tiempo importa, un modelo rápido pero un poco inferior puede ser mejor que uno mucho mejor pero lento
      Usando una métrica que mida la complejidad real en vez de la complejidad ciclomática, y haciendo que se revierta automáticamente hasta que la complejidad añadida esté dentro de un rango razonable para la funcionalidad, me ha ido bastante bien usando LLM
    • Mercury-2 es excelente. Lo uso seguido como árbitro en llm-consortium
      Como su ventana de contexto es relativamente pequeña, para usarlo en consorcios más grandes puedes armar algo parecido a un meta-consorcio recursivo:
      llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
      Ahora, si le das un prompt a cns-meta-glm-kimi, elige la mejor de 5 respuestas de kimi y glm respectivamente, y luego sintetiza las dos respuestas ganadoras
    • Me pregunto cuánto impacto tendrá esto en los modelos locales para programación. Si usas un modelo de difusión varias veces más rápido que Qwen o Gemma 4, yo tendría que preparar más cosas como antes de la IA, pero eso incluso podría ser algo bueno, y parecería posible trabajar localmente con modelos muy rápidos y baratos
      Si no haces cálculos pesados durante mucho tiempo, me imagino que el costo de ejecutarlo en hardware local también sería más barato
    • Sé exactamente a qué te refieres. En un proyecto personal me desesperé porque Claude era demasiado lento, así que me cambié a Google Antigravity y a los modelos Flash, y la diferencia de velocidad es enorme
      Puedo mantener mejor el ritmo y concentrarme más en el trabajo. No sabía que la velocidad hiciera una diferencia tan grande. En codebases muy complejas y grandes, el tiempo de respuesta lento de Claude puede valer la pena a cambio de la complejidad de la tarea, pero Antigravity y otros modelos rápidos encajan mucho mejor cuando quieres iterar escribiendo, ejecutando y depurando código de forma pequeña y ligera
    • Sí, la velocidad es lo principal. Está buenísimo que te genere POJO boilerplate o data classes a una velocidad absurda de 300+ tok/s; en un caso así, Flash-Lite resulta más útil que GPT-5.5
      Si es demasiado lento, te quedas atrapado en ese maldito loop de espera asíncrona

  • Google sigue demostrando su fuerza. Sorprende que Gemini no sea más competitivo que Claude o los modelos de OpenAI para código o uso tipo agente, pero está claro que Google todavía tiene talento de IA de primer nivel en la industria
    Dicho eso, parece que Google se está enfocando más en casos de uso que corran en el teléfono o casi en tiempo real que en LLM grandes orientados al razonamiento. Este tipo de mejoras de eficiencia probablemente va a ser muy importante para la IA en el futuro. La época en que regalaban tokens a precio de subsidio para amarrarte a un ecosistema se está acabando, y se acerca el momento de pagar el costo real. Va a ganar la empresa que encuentre cómo ejecutar modelos realmente inteligentes de forma rentable. DeepSeek cuesta más de un orden de magnitud menos que GPT 5.5 u Opus 4.8, y aunque es peor que ambos, no es catastróficamente peor. Si el mejor modelo de programación realmente me ahorra suficiente tiempo humano, con gusto pagaría 10 veces más, pero una diferencia de 100 veces ya es difícil de aceptar, como en benchmarks recientes donde GPT 5.5 Pro en algunos casos costaba más de 200 veces que DeepSeek y Opus 4.8 alrededor de 30 veces más

    • Fable cuesta el doble que Opus y también se ve bastante competitivo frente a GPT-Pro, así que si las salvaguardas de seguridad demasiado sensibles no son un gran problema, podría ser una opción razonable
      Google también tiene su propia opción de “Deep Research” en esta área y parece funcionar bien. Lo bueno de DeepSeek es que puede correr en hardware local sin costo de API. Si eso te importa, que esté un poco por debajo de Opus o GPT no es un gran problema
    • Al final, creo que Google va a ganar. Se está enfocando en lo importante: rendimiento por watt y rendimiento por dólar
      Está creando su propio hardware de inferencia y avanzando hacia edge computing para reducir latencia y overhead de cómputo. Los LLM grandes todavía no son rentables, y Google está dejando que sus competidores quemen capital de inversionistas para “vender” a los consumidores por debajo del costo. Incluso después de que estalle la burbuja de la IA, una empresa como Google va a seguir de pie, y esta burbuja parece estar destinada a quitarle la fachada a algunas grandes empresas

  • Algunas reacciones están pasando por alto las ventajas del enfoque de difusión. Podría tener un gran impacto en dispositivos edge como teléfonos o GPUs de computadoras
    El decodificador de un LLM tiene que considerar todos los tokens anteriores, así que calcula los tokens uno por uno. Los decodificadores LLM tradicionales escalan bien si la carga es suficiente como para agrupar varias inferencias en lote, y en ese entorno la ventaja de la difusión es limitada. En edge, el problema es distinto. Los aceleradores de inferencia se quedan hambrientos moviendo continuamente pesos de varios GB desde la RAM. La RAM de consumo como LPDDRx/GDDRx tiene menos ancho de banda que HBM, y como las solicitudes son seriales no se puede agrupar en lotes el cálculo de pesos compartidos. La difusión puede calcular tokens en paralelo, lo que alivia el cuello de botella del ancho de banda de memoria

    • Los dispositivos edge no solo tienen poco ancho de banda de memoria, también tienen un rendimiento de cómputo muy limitado. En la práctica, incluso sin muchos lotes se satura rápido la cantidad de cómputo disponible y se topa con límites claros de temperatura y energía
      Tampoco es cierto que en inferencia edge “las solicitudes sean intrínsecamente seriales”. Puede haber varias solicitudes al mismo tiempo, es decir, varios chats en curso, y si hay suficiente capacidad de memoria para almacenar el caché KV, se puede aplicar procesamiento por lotes. Si un modelo de difusión entrega menor calidad con más cómputo y además no está claro cuánto ahorra en ancho de banda de memoria, no veo bien cómo ayudaría
    • En general es correcto, pero está mezclando attention con la estructura autorregresiva/causal. El verdadero problema que impide usar más cómputo es la estructura autorregresiva/causal
      También se puede usar attention en difusión, y este modelo de hecho usa attention

  • NVIDIA está ofreciendo un endpoint gratuito para este modelo. Hay más detalles en https://build.nvidia.com/google/diffusiongemma-26b-a4b-it, y hay que crear una cuenta y probablemente también verificar el número de teléfono
    Incluso probé haciéndole dibujar un pelícano: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

    • Si fuera un modelo realmente rápido, incluso se le podrían pedir cuadros de animación. Por ejemplo, en el cuadro 1 el pie derecho a las 12 y el izquierdo a las 6, en el cuadro 2 el pie derecho a las 3 y el izquierdo a las 9
      Entonces, por supuesto, habría que reportar no tokens por segundo sino cuadros de pelícano por segundo
    • Me registré hace unas semanas y, aunque seguí el proceso, mi cuenta todavía no ha sido verificada. Si la cuenta no está verificada, no se puede usar la API

  • Buena explicación visual de cómo funcionan los modelos de difusión de texto como DiffusionGemma: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

  • Hasta hace unos días pensaba que Google no estaba diciendo absolutamente nada sobre el modelo de generación de texto por difusión que mostró en I/O hace un año
    Había rumores de que era demasiado caro de ejecutar, pero si se compara DiffusionGemma con Gemma normal en el mismo hardware 1x H100, como en el gráfico proporcionado, no parece ser así. Más allá de que sea un poco peor que Gemma, me pregunto cuál es la desventaja de esta velocidad

    • La respuesta a “me pregunto cuál es la desventaja de esta velocidad” parece ser esta parte:
      “La mejora de velocidad de DiffusionGemma fue diseñada para inferencia local y de baja concurrencia. En serving en la nube con QPS alto, los modelos autorregresivos pueden agruparse en lotes de manera eficiente para saturar el cómputo, por lo que la ventaja del decodificado paralelo de DiffusionGemma disminuye y el costo de serving puede ser mayor”
    • En un modelo autorregresivo estándar, si hay 256 usuarios, se podrían generar por ejemplo 256 tokens de una sola vez. Este enfoque puede generar 256 tokens para un solo usuario, pero necesita varias etapas de forward pass
      Así que el proceso de difusión usa más GFLOPs, y si ya hay suficientes usuarios, ya se puede equilibrar memoria y cómputo

  • “DiffusionGemma revierte esta ineficiencia. En vez de predecir palabras secuencialmente, crea al mismo tiempo un borrador completo de un párrafo de 256 tokens. Al darle al procesador de la computadora bloques de trabajo más grandes de una sola vez, aprovecha al máximo el hardware. Convierte la inferencia del modelo de una máquina de escribir que teclea carácter por carácter en una imprenta gigante que produce bloques completos de texto al mismo tiempo”
    “Funciona como un modelo mixture-of-experts (MoE) de 26B en total, con solo 3.8B parámetros activos durante la inferencia, y al cuantizarse entra cómodamente dentro del límite de 18GB de VRAM de una GPU dedicada de gama alta para consumo”
    Entonces, Gemma 4 26B es un modelo MoE que corre muy rápido en mi GPU de 24GB con ollama. Esto suena como speculative decoding, pero yo pensaba que eso no funcionaba en modelos MoE. Para quien no se dedica a seguir esto, hay demasiados cambios y es difícil mantenerse al día

    • Este es otro modelo, confusamente con casi el mismo número de parámetros que el gemma4 MoE existente. A simple vista no queda claro si uno fue entrenado a partir del otro de alguna forma
      El mecanismo no es igual al speculative decoding. El speculative decoding avanza secuencialmente, por lo general unos pocos tokens a la vez. La difusión no funciona así y trata bloques de texto completos de una sola vez. Todavía no he leído el material, pero supongo que lo habrán entrenado para que ciertos expertos se mantengan de forma estable a lo largo de todo el bloque de difusión

  • En mi 3090 Ti ni de cerca llega a la velocidad anunciada, pero es divertido ver cómo va “rellenando” la respuesta
    Probé la prueba del “pelícano SVG en bicicleta” de Simon y el resultado fue bastante minimalista, pero cumplió con los requisitos: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- ejecutado con cuantización Q4 en un llama.cpp parchado. También me pregunto si el resultado de Simon es muy distinto

  • ¿Cómo sería un modelo de razonamiento por difusión? ¿Sería algo como difundir durante mucho tiempo un bloque de [thinking] de longitud predefinida, y luego hacer que el bloque de salida final use el contenido de ese bloque de thinking como parte de la entrada?
    Y en primer lugar, ¿cómo decide un modelo de difusión la longitud de la salida? Me da curiosidad si es un parámetro fijado de antemano, o si difunde un token [end] en algún punto intermedio.

  • Está genial, pero incluso si los modelos locales ya están bastante bien, en la práctica se sienten claramente por debajo incluso de la API más barata, así que no me dan muchas ganas de sacrificar aunque sea un poco de calidad por velocidad.
    Seguro que tiene valor para algunos casos de uso, pero me da curiosidad qué casos concretos hay para realmente desplegarlo en producción.

    • Podría servir para escribir pruebas unitarias o para el bootstrap.
      No hace falta que sea nivel Opus para poder escribirlas, y también es fácil iterar.