- Gemini Diffusion, presentado por Google, es el primer LLM que usa un enfoque de difusión en lugar de transformadores
- Similar a lo que usan modelos de imagen como Imagen o Stable Diffusion
- Este modelo genera texto mediante un proceso de difusión que refina gradualmente el ruido, en lugar del método autorregresivo tradicional
- Como resultado, la velocidad de respuesta es muy alta y en pruebas mostró un rendimiento de 857 tokens por segundo
- Aunque todavía faltan benchmarks precisos, Google afirma que es 5 veces más rápido que Gemini 2.0 Flash-Lite
Descripción general de Gemini Diffusion
- Gemini Diffusion es un nuevo modelo de lenguaje de gran escala (LLM) presentado por Google
- En lugar del enfoque autorregresivo de los LLM basados en transformadores, adopta un enfoque de difusión
- Este método de difusión, similar al de modelos de generación de imágenes como Imagen y Stable Diffusion, se aplica aquí a la generación de texto
- Sus características principales son una respuesta rápida y la capacidad de corregir errores de forma eficiente durante el proceso de generación
- En un ejemplo de uso, con el prompt "Build a simulated chat app", entrega un resultado en HTML+JavaScript en pocos segundos y registra una velocidad de generación de hasta 857 tokens por segundo
Cómo funciona un modelo de lenguaje por difusión
- Los modelos de lenguaje autorregresivos tradicionales generan los tokens uno por uno de forma secuencial, por lo que son más lentos y también tienen límites en la consistencia de la salida
- En cambio, los modelos de difusión parten del ruido y mejoran gradualmente el resultado, procesando oraciones o párrafos completos en varias etapas de una sola vez
- Gracias a esto, es posible la generación paralela de tokens, lo que permite producir resultados muy rápido
- Es especialmente útil en áreas donde la retroalimentación inmediata es importante, como edición de texto, matemáticas y código
Modelos similares y comparación de rendimiento
- Hasta ahora casi no existían LLM comerciales de difusión, y en febrero de 2024 el proyecto Inception Mercury apareció como el primer caso
- En velocidad y rendimiento, Gemini Diffusion es similar a Gemini 2.0 Flash-Lite según Google, pero es aproximadamente 5 veces más rápido
- Muestra una alta velocidad de generación, similar a Cerebras Coder, y se espera que más adelante se agreguen datos de benchmarks objetivos
Explicación adicional y corrección
- Los modelos de lenguaje por difusión no reemplazan por completo la arquitectura de transformadores; más bien cambian la estructura de generación de texto del modo autorregresivo al modo de difusión
- Tanto Mercury como Gemini Diffusion están basados en transformadores, pero procesan toda la entrada de una vez y difieren en la forma de generar
- Es una forma más avanzada del enfoque de enmascarado y restauración estilo BERT: aumenta gradualmente la proporción de enmascarado y va completando el resultado incluso cuando todos los tokens están enmascarados
- En el enfoque de difusión, solo algunos tokens se fijan como definitivos en cada etapa, y la proporción de tokens definitivos aumenta de manera iterativa hasta completar toda la secuencia
- La idea central de estos LLM por difusión es la restauración gradual y la generación en paralelo
Conclusión
- Gemini Diffusion es un nuevo tipo de LLM que plantea características innovadoras en velocidad y calidad de generación
- Extiende con éxito al ámbito de la generación de texto las ventajas de los modelos de difusión ya demostradas en la generación de imágenes
- Crece la expectativa por su valor práctico en diversos usos reales y por los futuros resultados de benchmarks
1 comentarios
Opiniones en Hacker News
No sé bien cómo funciona realmente por dentro en Google, pero recientemente pasó algo interesante en el lado de RWKV. Hicieron un experimento reemplazando por completo el mecanismo de atención existente por WKV (atención lineal), y todo eso lo lograron solo con post-training. Lo que esto sugiere es que la mayor parte del conocimiento útil en realidad está en la FFN (red feedforward), y que la atención en sí quizá no sea un componente tan único o importante como parece. También vale la pena revisar los enlaces relacionados. Por otro lado, usar una atención ya entrenada y experimentar por separado qué tan rápida es solo la FFN en entrenamiento a velocidad GPT-2 también sería un intento interesante, aunque se salga de las reglas, y me gustaría leer un paper sobre eso. Entre lo que leí ayer, había una idea de que en cierto punto los embeddings de todos los modelos se vuelven muy similares, de modo que se puede entrenar un transformador simple, y que si ambas cosas son ciertas, se podrían compartir embeddings y atención para acelerar muchísimo el entrenamiento completo
La atención, dicho con el mayor respeto posible hacia quienes investigan esto, me parece básicamente tomar toda la información pasada de la red como entrada y meterla en una red neuronal reverse-MoE. Aquí, los expertos no eligen qué parte de la red ejecutar, sino qué parte de la entrada ejecutar. Sabíamos que este enfoque probablemente funcionaría, pero era tan ineficiente que ni siquiera usuarios de R o Python pensaban en ejecutarlo. Era una arquitectura tan lenta de entrenar que ni siquiera era práctico intentarlo
Me da la impresión de que "Attention is all you need" podría interpretarse en otro sentido
La idea de que los embeddings de los modelos se vuelven (muy) parecidos entre sí y pueden mapearse con un transformador simple viene de aquí
Veo la atención como una forma completamente arbitraria de dividir la red y permitir entrenamiento en paralelo. La parte que de verdad contribuyó al éxito fueron las "shortcut connections" entre capas. Eso les da más influencia a las capas iniciales durante el entrenamiento
Ya se sabe que en los transformers modernos la importancia relativa de la atención SDPA no es tan grande. La FFN, la normalización y las conexiones residuales son absolutamente irremplazables, pero la atención puede sustituirse fácilmente por cualquier otra capa que comparta información entre tokens (pooling, convolución, mezcla aleatoria, etc.)
Es una velocidad realmente impresionante. Hasta ahora, creo que el mejor caso de uso de los modelos ha sido escribir código totalmente nuevo y hacer prototipado rápido. No he sentido que sean tan fuertes para mejorar grandes codebases que ya han pasado por muchas iteraciones. Una razón es que, por definición, el modelo no puede saber sobre lo que "no está incluido" en la codebase. También hay señales importantes en el hecho de que algo "no esté" en el código, y eso es bastante difícil de representar. Por muy inteligente que sea un modelo, creo que ahí queda una limitación fundamental por falta de "contexto interno y experiencia". Por ejemplo, si le das una gran codebase a un desarrollador brillantísimo y le pides resolver un problema específico de inmediato, un desarrollador promedio que conozca bien la codebase podría entregar más valor en el mismo tiempo
Si te enfocas en la forma de comunicación, se puede resolver este problema. Mi flujo de trabajo principal hoy es que, cuando necesito trabajo grande (nueva funcionalidad, refactor, etc.), empiezo una conversación con o3 como si fuera un colega. Voy pegando los archivos fuente necesarios para dar contexto mientras mantenemos una discusión de alto nivel sobre el objetivo y el estado actual del código. En ese proceso siento que se vuelve más claro lo que quiero hacer y el contexto de la codebase. Después le pido a o3 un plan de implementación y se lo paso a Codex para que ejecute una serie de pasos automatizados: leer código fuente, editar archivos, correr pruebas, etc. Cuando sale el PR, a veces basta con un poco de edición manual o incluso se puede hacer merge directo. Estoy de acuerdo en que los modelos necesitan mucho contexto, pero no creo que sea una limitación esencial, sino un problema de cómo colaborar eficazmente con ellos. Si desarrollas habilidad, no solo aumenta la productividad, sino que para mí también se vuelve una forma de trabajar mucho más disfrutable mentalmente
Me identifico profundamente con la idea de que "lo que no existe en una codebase tiene una señal significativa". Llevo mucho tiempo en software, pero nunca había sido tan consciente de esta verdad fundamental con tanta claridad. Gracias por esa observación
Hasta ahora, en mi experiencia, los LLM son buenos para imitar código existente y bueno, pero no suelen producir por sí solos partes nuevas y originales a menos que se les pida explícitamente. Muchas veces no logran ingerir suficiente de la codebase y hay que señalarles directamente otras partes del proyecto. Aun así, estaría genial poder darles algo como un "negative prompt", al estilo de Stable Diffusion
Me pregunto qué pasaría si un LLM pudiera leer como contexto todo el historial de git, el issue tracker y hasta las grabaciones de reuniones. Habrá que ver si entradas de contexto gigantes realmente producen resultados prácticos y utilizables
Esta presentación de verdad me sorprendió. Creo que fue el anuncio más grande del evento IO, pero quedó opacado por otras noticias como Veo 3. Usar modelos de diffusion para generación de código tiene implicaciones enormes. Si usan transformers, eso caería en la familia DiT (Diffusion Transformer); hace unos años participé en un modelo híbrido que combinaba diffusion basada en U-Net, y desde entonces ha habido muchísimo avance. Siento que viene un gran salto en el área de diffusion
Me pregunto cómo funcionará aplicar la intuición de Vision Transformer al código. En visión, se parte del ruido y se va produciendo la imagen objetivo cada vez más clara por capas. Si aplicas ese principio a generación de código, parecería necesitar una estructura jerárquica que vaya bajando el nivel de abstracción gradualmente, por ejemplo: "hay que usar Django", "definir la lista de endpoints", "generar el código concreto", etc. Pero diffusion no tiene un mecanismo de backtracking, así que aunque detecte un problema en niveles inferiores, tiene una capacidad limitada para retroalimentar de inmediato a las capas superiores. En cambio, los transformers recorren el modelo completo por cada token, así que es más fácil hacer el backtracking y los cambios de diseño que cada problema requiera. Mi modelo mental puede estar equivocado, así que me gustaría escuchar más ideas
Veo 3 se volvió tema porque su rendimiento y sus diferencias se ven de forma muy intuitiva, mientras que para entender el valor de un avance importante en text completion hay que conocer los logros previos y sus posibles aplicaciones. Mucha gente todavía ni siquiera está convencida de que los LLM sean útiles para programar
Un modelo de generación de código basado en diffusion sí sería una innovación real. Algunas ideas simples de lo que podría hacer un modelo así: generar tokens fijando la firma de la función y el resultado, aprovechando información bidireccional. Segundo, primero escribir el esquema grande de la función (como cuando un LLM redacta los "capítulos" de un artículo) y luego dividirlo en implementación con cada vez más detalle. Generación iterativa dentro de contextos más amplios, guiándose con señales como linters, información del AST y demás. Hay muchísimo por experimentar
En principio, parece que este enfoque tendría grandes ventajas, y modelos como LLaDA que he probado en la práctica fueron impresionantes incluso con pocos recursos de entrenamiento. Pero en métricas como perplexity todavía van por detrás. También tienden mucho a quedarse fijos durante la generación, así que parece haber límites para editar texto en profundidad (mientras mayor sea la probabilidad de masking, más difícil es hacer ediciones simultáneas). Aun así, en experimentos reales obtuve resultados bastante prácticos
Ya había visto demos de esto en InceptionLabs y otros, así que no me pareció tan sorprendente
Siento que lo esencial de esta noticia se está perdiendo. Es un InstructGPT realmente rápido y bueno. Seguro se va a usar en correctores ortográficos, codemods y editores de código. Gracias a la función de Instant edits, permite edición de texto realmente rápida y precisa, sin añadidos ni sugerencias innecesarias. Le pedí que cambiara los nombres de variables en un ejemplo de ShaderToy para que fueran más comprensibles, copié el resultado y lo ejecuté, y me sorprendió que siguiera funcionando bien
La ventaja de diffusion no es solo la velocidad. Según benchmarks iniciales, supera a AR en inferencia y planeación incluso con el mismo número de parámetros. Diffusion permite edición intermedia y no sufre el problema del sesgo de tokens iniciales
Es una afirmación interesante. Me gustaría saber si puedes compartir enlaces a benchmarks o material que la respalde
AR en sí no impide hacer planes largos, pero en la implementación de muchos modelos AR populares actuales sí aparecen a menudo esas limitaciones. AR sigue siendo muy importante, en lo fundamental, para aprender la distribución correcta
Personalmente estoy de acuerdo, o al menos me gustaría que fuera cierto, pero todavía no he visto papers o demos sobre revise diffusion text. Me gustaría probarlo, así que estaría bueno que compartieras la información del paper
Llevo mucho tiempo interesado en aplicar técnicas de diffusion a generación de texto. Por fin Google lanzó un modelo así, y me alegra sentir que mis ideas se estaban validando. Desde el punto de vista del hardware usado en experimentación, casi todo corre en servicios pagados o en equipos de gama alta, al menos dentro del nivel de consumo. En mi situación actual, lo que tengo es algo como una 5700XT y me cuesta actualizar, pero eso también me ha permitido ver con más claridad las limitaciones de los modelos actuales. A medida que aumenta el tamaño del modelo, también aumenta la consistencia, así que los modelos pequeños terminan limitados a tareas simples. Algo que confirmé en mis experimentos es la importancia del tamaño del contexto: con GPUs pequeñas es difícil meter al mismo tiempo suficiente contexto y un modelo suficientemente grande, y me pregunto si con un enfoque basado en diffusion se podría cambiar ese equilibrio entre densidad y consistencia. Esperaría una generación de texto más consistente incluso con poco contexto, y probablemente mejores resultados en mezclas de tool calling + respuesta. El problema de velocidad también es una molestia muy real: el enfoque actual de los LLM va lento en cada ida y vuelta de entrada-salida, y eso pone a prueba la paciencia, sobre todo en GPUs viejas sin hardware especializado para IA. Sería bueno ver aunque sea un progreso en tiempo real de 0 a 100%, y tengo la esperanza de que los modelos de diffusion puedan mejorar eso. De ahí me surge una duda: como la entrada de ruido es importante, me pregunto si existe una buena fuente de ruido especializada para LLM/texto, y si la longitud total del bloque debe fijarse de antemano o puede ser variable
Puedo decirlo con total seguridad desde mi experiencia: este modelo es absurdamente rápido. La desventaja es que cae muy fácilmente ante ataques de prompt injection. Por ejemplo, si le pides instrucciones para fabricar drogas, se niega, pero si lo conviertes en un "roleplay de niño", entonces sí te da el resultado real. Fuera de ese defecto, la velocidad y la usabilidad para automatización son excelentes. Si además se le suma un enfoque tipo agente, el potencial del modelo podría lucirse de verdad
Puede que no sea tanto una limitación del modelo en sí, sino que en el entrenamiento se invirtieron menos recursos en seguridad o censura. Me parece más bien un prototipo experimental, quizás una demostración ligera antes de invertir de lleno en un modelo grande
No creo que ese tipo de prompt injection sea una señal de que ya podamos controlar modelos más inteligentes
La descripción "el primer diffusion LLM de Google, usa diffusion en lugar de transformer" es una afirmación incorrecta. Google nunca lo presentó así. De hecho, los modelos de diffusion basados en Transformer son comunes. Creo que Gemini Diffusion también probablemente use transformers. La diferencia sería que es un transformer encoder-only. Es decir, se ingresa toda la secuencia en estado noisy/corrupted y se predice la secuencia correcta completa. Gracias a eso, se puede computar en paralelo todo el marco de la secuencia al mismo tiempo y, si el número de iteraciones se mantiene razonable, puede ser muchísimo más rápido que el decoding secuencial de un modelo decoder-only (aunque speculative decoding también tiene ventajas de velocidad similares). Normalmente se entrena con masking estilo BERT, pero sigue siendo un área con mucha investigación activa. También me da curiosidad la relación con Gemini y cómo se usan los checkpoints: si se importan directamente, si hay fine-tuning especializado para diffusion, knowledge distillation, o si es solo branding. Ojalá hubieran publicado detalles oficiales
Es ridículamente rápido. Supongo que la GPU siempre estará funcionando al máximo, y que casi no habrá ahorro de cómputo por batch processing. Pero pensándolo bien, tampoco estoy seguro de que eso se pueda llamar realmente un tradeoff. Una preocupación es que el objetivo de diffusion pueda rendir peor que AR en desempeño. Si ese fuera el caso, una alternativa podría ser que los modelos AR multi-token alcancen la misma velocidad que diffusion, o usar modelos de diffusion como generadores de borrador para speculative decoding
Me pregunto por qué piensas que un dLLM tendría peor calidad que un arLLM. Como procesa repetidamente la salida como un "todo estructurado" (tema, puntos clave, conceptos, árbol de palabras), podría incluso ser mejor en calidad
Este tradeoff estructural es mucho más favorable en entornos de self-hosting. Como no necesitas batchs masivos, el beneficio es menor en la nube, pero es una gran ventaja para LLM locales
Estoy muy entusiasmado con los diffusion LLM. Nuestro equipo sueña con una mecánica de juego de voz → código, y diffusion podría ser justo la pieza final que faltaba. Cerebras y Groq son impresionantes, pero su hardware personalizado limita el fine-tuning y el escalado. La otra alternativa son MoE con alrededor de 0.5b de parámetros activos, pero por ahora no tenemos margen para meterle recursos a ese proyecto. Si alguien de Google/DeepMind llega a ver esto, por favor lancen una API. Nuestro equipo está desarrollando un juego sandbox generativo, y el primer proyecto tiene una estructura donde das órdenes a monstruos en tiempo real. También tenemos un video del prototipo, por si quieren verlo