Acelerar Gemma 4: inferencia más rápida con un drafter de predicción de múltiples tokens
(blog.google)- Google superó las 60 millones de descargas pocas semanas después del lanzamiento de Gemma 4 y presentó un drafter de predicción de múltiples tokens (MTP) para la familia Gemma 4
- El drafter MTP es una arquitectura especializada de decodificación especulativa (speculative decoding) que aumenta la velocidad de inferencia hasta 3 veces sin degradar la calidad de salida ni la lógica de razonamiento, y fue probado en hardware que usa LiteRT-LM, MLX, Hugging Face Transformers y vLLM
- La inferencia estándar de los LLM genera un fuerte cuello de botella de ancho de banda de memoria porque debe mover miles de millones de parámetros desde la VRAM a las unidades de cómputo para generar un solo token; MTP hace que un drafter liviano proponga varios tokens futuros y luego el modelo objetivo los valide en paralelo
- Si el modelo objetivo está de acuerdo con los tokens del borrador, acepta la secuencia completa en una sola pasada hacia adelante y además genera un token adicional, por lo que la aplicación normalmente puede emitir la secuencia propuesta y un token extra en el tiempo que suele tardar en generar un solo token
- El drafter MTP comparte las activaciones del modelo objetivo y la caché KV, aplica clustering eficiente del embedder en los modelos edge E2B y E4B, y sus pesos están disponibles con licencia Apache 2.0 en Hugging Face y Kaggle
Por qué se necesita la decodificación especulativa
- La inferencia estándar de los LLM está limitada por el ancho de banda de memoria, lo que crea un gran cuello de botella de latencia
- Los procesadores pasan la mayor parte del tiempo moviendo miles de millones de parámetros desde la VRAM a las unidades de cómputo para generar un solo token
- Esta estructura, especialmente en hardware de consumo, impide aprovechar bien los recursos de cómputo y aumenta la latencia
- La decodificación especulativa separa la generación y la verificación de tokens
- Empareja un modelo objetivo pesado, por ejemplo Gemma 4 31B, con un drafter liviano, el modelo MTP, para predecir varios tokens futuros a la vez usando recursos de cómputo que de otro modo quedarían ociosos
- El drafter propone varios tokens en menos tiempo del que tarda el modelo objetivo en procesar uno, y el modelo objetivo valida en paralelo los tokens propuestos
Cómo funciona MTP
- Los modelos de lenguaje grandes estándar generan texto de forma autorregresiva y producen exactamente un token a la vez
- Este enfoque dedica la misma cantidad de cómputo tanto a una continuación sencilla como predecir “words” después de “Actions speak louder than…” como a resolver acertijos lógicos complejos
- MTP reduce esta ineficiencia mediante la decodificación especulativa introducida por investigadores de Google en Fast Inference from Transformers via Speculative Decoding
- Si el modelo objetivo está de acuerdo con los tokens del borrador, acepta la secuencia completa en una sola pasada hacia adelante, y el propio modelo objetivo también genera un token adicional al mismo tiempo
- La aplicación normalmente puede emitir toda la secuencia propuesta más un token adicional en el tiempo que tarda en generar un solo token
Impacto en rendimiento para desarrolladores
- Para los desarrolladores, la velocidad de inferencia suele ser un cuello de botella clave en despliegues de producción
- En agentes autónomos que requieren planificación rápida en varios pasos, asistentes de programación y aplicaciones móviles reactivas que corren completamente en el dispositivo, incluso una latencia de milisegundos importa
- Al usar modelos Gemma 4 junto con este drafter, se pueden obtener los siguientes efectos
-
Mejor capacidad de respuesta
- Se puede reducir notablemente la latencia en chats casi en tiempo real, aplicaciones de voz inmersivas y flujos de trabajo agentivos
-
Desarrollo local más rápido
- Ejecuta con mayor velocidad modelos 26B MoE y 31B Dense en computadoras personales y GPUs de consumo, lo que ayuda con flujos de trabajo complejos de programación offline y agentes
-
Mejor rendimiento en el dispositivo
- Hace que los modelos E2B y E4B generen más rápido en dispositivos edge, lo que ayuda a reducir el consumo de batería del dispositivo
-
Sin pérdida de calidad
- Como el modelo base Gemma 4 conserva la verificación final, ofrece el mismo nivel de razonamiento y precisión mucho más rápido
- Un ejemplo de Gemma 4 26B ejecutándose en una NVIDIA RTX PRO 6000 compara los tokens por segundo entre la inferencia estándar y el drafter MTP, y muestra que la latencia se reduce a la mitad con la misma calidad de salida
- El video comparativo se puede descargar
Optimizaciones internas del drafter MTP
- Para que el drafter MTP sea rápido y preciso, se aplicaron varias mejoras arquitectónicas
- El modelo de borrador aprovecha de forma natural las activaciones del modelo objetivo y comparte su caché KV
- Gracias a la caché KV compartida, no pierde tiempo recalculando el contexto que el modelo grande ya procesó
- En los modelos edge E2B y E4B, como el cálculo final de logits se convierte en un gran cuello de botella, se implementó una técnica eficiente de clustering en el embedder para acelerar más la generación
- También se analizaron optimizaciones específicas por hardware
- En Apple Silicon, el modelo mixture-of-experts de 26B tiene desafíos de enrutamiento particulares cuando el tamaño de lote es 1, pero al procesar varias solicitudes al mismo tiempo logra una mejora local de velocidad de hasta aproximadamente 2.2 veces
- Los tamaños de lote de ejemplo son 4~8, y en NVIDIA A100 aparecen mejoras similares al aumentar el tamaño de lote
- La arquitectura visual, el uso compartido de la caché KV y el funcionamiento del embedder eficiente se pueden revisar en la explicación técnica detallada
Cómo usarlo y dónde está disponible
- El drafter MTP para la familia Gemma 4 se ofrece con la misma licencia Apache 2.0 de código abierto que Gemma 4
- En la documentación se puede ver cómo usar MTP junto con Gemma 4
- Los pesos del modelo se pueden descargar desde Hugging Face y Kaggle
- Se puede experimentar con inferencia más rápida en transformers, MLX, vLLM, SGLang y Ollama
- También se puede probar directamente en Google AI Edge Gallery para Android o iOS
- Google espera que esta mejora de velocidad acelere el desarrollo en Gemmaverse, el ecosistema de Gemma
1 comentarios
Comentarios de Hacker News
Gemma y Gemini usan muchísimos menos tokens de salida que otros modelos y aun así se acercan bastante al rendimiento de los benchmarks de primer nivel
Si comparas Gemma con Qwen, Qwen rinde un poco mejor, pero suele dedicar 22 minutos a una tarea, mientras que Gemma a menudo termina el mismo prompt en 4 minutos aunque se equivoque alineando botones
A simple vista, Gemma rinde entre un 5 y un 10% por debajo de los modelos abiertos líderes, pero usa solo 1/10 del tiempo
Ni siquiera siento la necesidad de subir de plan como otras personas que publican planes de 100 dólares al mes en Claude o Codex
Eso sí, Gemini ha bajado de rendimiento varias veces durante el último año y sus límites de velocidad también se han endurecido, así que no sé si seguirá así de bueno en el futuro
Como los modelos grandes suelen usar menos tokens por la misma unidad de inteligencia, eso parece explicar la diferencia en uso de tokens
Lo probé en una 4070 y, aunque la salida no fue increíblemente rápida, sí era usable
Todavía no lo he probado en tareas complejas, y ahí supongo que será distinto
Quizá después de Google I/O más gente se dé cuenta de lo bueno que es Gemini
Si aparece un problema de alineación, hay que volver a gastar tokens de entrada y salida para corregirlo
Se está añadiendo soporte para MTP a llama.cpp, y al menos para los modelos de Qwen ya está en marcha(https://github.com/ggml-org/llama.cpp/pull/20533)
Parece que Gemma 4 también llegará pronto
Las mejoras de calidad y velocidad en los modelos locales y autoalojados en los últimos meses han sido impresionantes
Para alguien que lleva mucho tiempo ejecutando modelos locales, es una época realmente interesante
Tengo muchas ganas de ver cómo se compara con MTP
Era una herramienta bastante decente
Google está sosteniendo casi por sí solo los modelos open source del mundo occidental
Gemma 4 31B es excelente
Eso sí, hacer que la mejor versión quepa en 24GB de VRAM, incluyendo capacidad visual y el drafter que viene pronto, es bastante doloroso
Mi build no puede agregar más GPU, y para sacar el máximo rendimiento parece que tendría que comprar otra 4090, que es demasiado cara, o reemplazar todo de plano
--no-mmproj-offload, puedes dejar el proyector multimodal, es decir, la parte de comprensión de audio, imagen y PDF, en la RAM del sistemaClaro, así ya no tiene aceleración por GPU, pero se ahorra VRAM
También puedes ajustarlo más según la tarea, así que puedes elegir si priorizar razonamiento y precisión o la velocidad de inferencia
Ver a la computadora escribir me recuerda a cuando antes uno se conectaba a una BBS por módem
Esto se siente como pasar de 300 baudios a 1200, así que sí es una gran mejora, pero sigue siendo bastante lento, y algún día probablemente nos preguntaremos cómo tolerábamos usar esto así
Ver fluir los tokens se siente como ver un JPEG cargando unas cuantas líneas de píxeles a la vez, y también me recuerda a todas esas animaciones de carga y conexión que cada app implementaba antes de que la velocidad fuera suficiente
El trabajo de Cerebras o Taalas da pistas interesantes de lo que podría ser posible en esa dirección
También es divertido imaginar qué sería posible si incluso los modelos de punta actuales pudieran usarse a un millón de tokens por segundo y a un costo muy bajo
La comparación que calculó Claude entre módem y Claude fue esta: para 2368 caracteres, 300 tarda 1 minuto 19 segundos, 1200 tarda 19.7 segundos, 2400 tarda 9.9 segundos, 14.4K tarda 1.6 segundos, 33.6K tarda 705ms, 56K tarda 447ms y Claude tarda 7.9 segundos
Era del orden de miles de tokens por segundo
La estrategia de Google parece un poco distinta de la de otros proveedores frontier
Parece que se enfoca más en la eficiencia de rendimiento por cómputo que en el rendimiento puro, y quizá por eso Gemini se vea rezagado en apariencia
Otros proveedores están chocando con límites de capacidad y también con los límites de subsidiar los costos de inferencia
La estrategia de Google parece orientada a escalar y desplegar estos modelos para sus miles de millones de usuarios existentes
Más bien se siente como un tipo de inteligencia distinto al de la línea reciente de GPT-5 y Claude
Estos últimos se enfocan cada vez más en productividad y automatización del trabajo, y están optimizados para bucles de razonamiento largos, agentivos y de autocorrección
Gemini se siente como un modelo base mucho más inteligente y, sobre todo en modo Deep Think, su intuición se siente mucho más profunda, pero no se le da igual de bien los bucles agentivos de autocorrección de largo alcance
Durante varios meses, mi flujo de trabajo ha sido usar Gemini para saltos creativos e insights, y preferir Codex, Claude y GPT-5.5 Pro para tareas repetitivas o de alta precisión
Dejé de usar modelos locales un tiempo y hace poco configuré el modelo 26B A4B en una RTX 3090 con vLLM a 4 bits, y quedé totalmente sorprendido por la velocidad y la calidad que se pueden obtener con una inversión de menos de 1000 dólares
Al principio lo probé con Qwen, pero era inestable y sus rastros de razonamiento eran absurdamente largos
Sigue siendo delicado, pero con un poco de ajuste realmente es impresionante
Los modelos locales son el futuro, y eso está genial
En tareas de programación sí queda claramente por detrás de Qwen 3.6, pero eso más bien habla de lo bueno que es el modelo Qwen
En mi computadora, comparado con otros modelos de 30B, el tg es al menos el doble de rápido de lo que esperaba, probablemente gracias a la atención híbrida
Eso sí, el procesamiento de entrada es un poco más lento
Me pregunto si alguien ha logrado hacer funcionar esto en LM Studio
La opción aparece en la UI, pero no parece activarse
[1] https://github.com/ml-explore/mlx-lm/pull/990
[2] https://github.com/ggml-org/llama.cpp/pull/22673
Como no hay modelos pequeños, hay que revisar que no estés usando un modelo sparse de Gemma
Y además eliminé todos los modelos de imagen del espacio de trabajo
A veces, si los borras, empieza a aparecer
Parece que esos archivos están conectados de alguna forma con la capacidad visual y bloquean la decodificación especulativa, pero no me preguntes por qué
Con Gemma, me funcionó mejor usar decodificación especulativa por la ruta de llama-server que en LM Studio
Normalmente el proveedor, la cuantización, etc., tienen que coincidir perfectamente entre sí
Puede tomar tiempo encontrar un conjunto que haga buena pareja
En mis pruebas, el modelo Gemma 4 31B mostró la mayor mejora de velocidad en tareas de programación al usar el runner MLX de Ollama, aproximadamente 2x
Pero como la cuantización reduce mucho la tasa de aceptación, hace falta una Mac bastante potente
En los otros tres modelos más pequeños no fue tan bueno, porque el tiempo de validación del modelo draft se comía casi toda la mejora de rendimiento
Sigo ajustándolo para ver si se puede sacar más rendimiento
Puedes probarlo ejecutando
ollama run gemma4:31b-coding-mtp-bf16en Ollama 0.23.1En cuanto se fusione en llama.cpp, quiero probarlo de inmediato
En mi entorno, Gemma 4 26B-A4B es alrededor de 3 veces más rápido que Qwen3.6-35B-A3B, así que solo pensar en sumarle una aceleración de 1.5x ya resulta muy atractivo
También probé modelos draft, pero los resultados fueron limitados, y un modelo draft más pequeño de 3B junto con el modelo denso Ministral 14B ya introducían demasiado overhead
Gemma4 26B supera los 200TPS con la misma cuantización
También importa que Qwen tiene una eficiencia de inferencia extremadamente baja
Su cadena de pensamiento es en promedio unas 3 veces más larga que la de Gemma
Me pregunto si esto es como la predicción de saltos de un sistema operativo
Solo que, como la probabilidad está incorporada en el propio modelo, es una forma mucho más confiable
Un fallo en la predicción de saltos quema ciclos, pero aquí una mala conjetura normalmente solo significa que no obtienes tokens de bonificación
https://arxiv.org/abs/2211.17192