Google ha lanzado drafters MTP para la familia Gemma 4, una mejora pensada para reducir la latencia de inferencia sin cambiar la calidad final de las respuestas. La promesa es muy atractiva para quienes despliegan modelos abiertos en local, estaciones de trabajo o servidores propios: hasta tres veces más velocidad en determinadas configuraciones, manteniendo el mismo modelo principal como verificador final de la salida.
La novedad ya empieza a moverse entre usuarios avanzados de vLLM, donde algunas pruebas con Gemma 4 31B y modelos cuantizados en FP8 apuntan a mejoras superiores a 3x en escenarios simples. No es todavía una experiencia completamente limpia en todos los entornos, y en algunos casos puede requerir aplicar parches recientes de vLLM, pero la dirección es clara: la inferencia de modelos grandes no solo va a mejorar con más GPU, también con técnicas más inteligentes para generar tokens.
Qué son los drafters MTP y por qué importan
La inferencia tradicional de un modelo de lenguaje funciona de forma autoregresiva: el modelo genera un token, después otro, luego otro. Es eficaz, pero también lento. Cada token exige mover enormes cantidades de parámetros desde la memoria de la GPU hacia las unidades de cómputo. En muchos casos, el cuello de botella no está en la capacidad de cálculo, sino en el ancho de banda de memoria.
La propuesta de Multi-Token Prediction, o MTP, consiste en introducir un modelo auxiliar mucho más ligero, llamado drafter o assistant model. Este modelo pequeño intenta anticipar varios tokens futuros. Después, el modelo principal, por ejemplo Gemma 4 31B, verifica en paralelo si esos tokens son válidos. Si los acepta, se han generado varios tokens en el tiempo que normalmente costaría producir uno.
La idea pertenece al terreno de la decodificación especulativa. No se trata de sustituir al modelo grande por uno pequeño, sino de usar el modelo pequeño para proponer y el grande para validar. Por eso Google sostiene que no hay degradación de calidad ni de lógica de razonamiento: la salida final sigue pasando por el modelo principal.
En la práctica, esto puede cambiar bastante la experiencia. Un asistente de programación, un agente local, una interfaz conversacional o una aplicación de voz no solo necesitan respuestas correctas, sino respuestas rápidas. Ahí cada token por segundo cuenta. Si MTP permite que modelos como Gemma 4 26B o 31B se sientan más ágiles en hardware accesible, el salto no será solo de benchmark, sino de usabilidad.
| Elemento | Qué hace | Por qué importa |
|---|---|---|
| Modelo principal | Genera y verifica la respuesta final | Mantiene la calidad y el razonamiento |
| Assistant model / drafter | Propone varios tokens futuros | Reduce esperas entre tokens |
| Decodificación especulativa | Verifica en paralelo las propuestas | Aumenta tokens por segundo sin cambiar la salida |
| KV cache compartida | Evita recalcular contexto ya procesado | Reduce trabajo duplicado |
| vLLM | Sirve el modelo con API compatible con OpenAI | Facilita despliegues en servidores propios |
Cómo se está probando en vLLM
La integración con vLLM es una de las más interesantes para administradores y equipos que ya sirven modelos en producción. Google menciona soporte para Transformers, MLX, vLLM, SGLang y Ollama, además de LiteRT-LM para entornos edge. La documentación de vLLM ya recoge el uso de assistant models para Gemma 4, incluidos los drafters gg-hf-am/gemma-4-E2B-it-assistant, gg-hf-am/gemma-4-E4B-it-assistant, gg-hf-am/gemma-4-26B-it-assistant y gg-hf-am/gemma-4-31B-it-assistant.
El ejemplo más directo para Gemma 4 31B en vLLM sería levantar el modelo principal con un speculative-config que apunte al drafter correspondiente:
vllm serve google/gemma-4-31B-it \
--tensor-parallel-size 2 \
--max-model-len 8192 \
--speculative-config '{"model": "gg-hf-am/gemma-4-31B-it-assistant", "num_speculative_tokens": 4}'En pruebas reales con modelos cuantizados, como FP8, pueden aparecer incompatibilidades si el drafter hereda una configuración de cuantización que no le corresponde. En la discusión técnica de vLLM se menciona precisamente el caso de gemma4_mtp.py y la necesidad de evitar que determinadas capas del assistant model carguen con quant_config del modelo objetivo. Por eso algunos usuarios están aplicando un ajuste manual con quant_config=None mientras esperan una integración estable en una release oficial.
Este matiz es importante. Google ha publicado los drafters y vLLM ya documenta el camino de uso, pero no todos los despliegues van a funcionar igual de bien con cualquier combinación de versión, cuantización, backend de atención y GPU. Quien trabaje con vLLM 0.20.1 o builds recientes debería validar el entorno antes de llevarlo a producción.
Más velocidad sin comprar otra GPU
La parte más atractiva de MTP es económica. Muchos despliegues de modelos abiertos están limitados por coste de hardware, consumo eléctrico o disponibilidad de GPU. Si una técnica de inferencia permite exprimir mejor una máquina existente, el impacto puede ser mayor que una simple mejora incremental.
En servidores propios, más tokens por segundo pueden significar menor latencia para usuarios, mayor capacidad por nodo o menos necesidad de escalar horizontalmente. En estaciones de trabajo, puede hacer más usable un modelo grande para programación, análisis documental o agentes locales. En portátiles y dispositivos edge, la mejora puede traducirse en respuestas más rápidas y menor consumo relativo, aunque dependerá mucho del modelo y del hardware.
Google señala que los drafters MTP para Gemma 4 se publican bajo la misma licencia Apache 2.0 que la familia Gemma 4. Eso facilita su adopción en proyectos abiertos, pruebas internas y productos comerciales, siempre dentro de los términos de uso aplicables. También encaja con una tendencia más amplia: los modelos abiertos ya no compiten solo en calidad, sino en eficiencia de despliegue.
Hay otro detalle técnico relevante. En los modelos E2B y E4B, los assistant models usan centroids masking, una técnica que reduce el cálculo del lm_head al seleccionar un subconjunto de candidatos del vocabulario. vLLM explica que esto puede reducir esa parte del cálculo desde un vocabulario de unos 262.000 tokens a unos 4.000 candidatos, con impacto mínimo en la calidad de los tokens propuestos. En el caso de 26B y 31B, los assistant models disponibles no usan esa optimización, pero siguen permitiendo speculative decoding con varias propuestas por paso.
La mejora no será idéntica en todos los escenarios. La velocidad depende de la longitud de salida, el batch size, la tasa de aceptación de tokens especulativos, el tipo de GPU, la cuantización, la implementación del runtime y el perfil de la tarea. Google habla de hasta 3x, mientras que la ficha de Hugging Face del assistant model menciona mejoras significativas de hasta 2x en su descripción general. Las pruebas comunitarias ya están mostrando resultados muy buenos, pero conviene medir cada caso.
Una señal para el futuro de los modelos abiertos
Gemma 4 ya había llegado con una propuesta clara: modelos abiertos multimodales, variantes densas y MoE, contextos largos y despliegue desde móviles hasta servidores. Los drafters MTP añaden una capa práctica que puede ser decisiva para adopción real. Un modelo bueno que responde despacio puede quedarse en laboratorio. Un modelo algo más ágil puede entrar en flujos diarios de trabajo.
Para vLLM, esta integración también es relevante. El motor se ha convertido en una pieza central para servir modelos en entornos compatibles con la API de OpenAI. Añadir soporte para MTP en Gemma 4 refuerza su papel como infraestructura de inferencia para equipos que quieren controlar sus propios despliegues, ajustar cuantización y experimentar con modelos abiertos de alto rendimiento.
La lectura de fondo es sencilla: la inferencia se está sofisticando. Ya no basta con cargar un modelo y generar tokens uno a uno. KV cache compartida, speculative decoding, MTP, cuantización FP8 o FP4, kernels optimizados y batch scheduling serán cada vez más importantes para que los modelos grandes resulten útiles fuera de los grandes centros de datos.
Para desarrolladores y administradores, el mensaje es doble. Merece la pena probar MTP porque las ganancias pueden ser grandes. Pero también hay que hacerlo con mentalidad de ingeniería: comparar outputs, medir tokens por segundo, revisar latencia p95, comprobar memoria, validar compatibilidad con cuantización y no asumir que un benchmark simple representa todo un workload real.
Gemma 4 con drafters MTP no convierte mágicamente una GPU modesta en un clúster de inferencia, pero sí muestra cómo las optimizaciones de software pueden devolver mucho margen al hardware existente. Y en un momento en el que cada GPU cuenta, eso ya es una noticia importante.
Preguntas frecuentes
¿Qué es un drafter MTP en Gemma 4?
Es un modelo auxiliar ligero que propone varios tokens futuros para que el modelo principal los verifique en paralelo. Su objetivo es acelerar la generación sin cambiar la calidad final de la respuesta.
¿Se pierde calidad al usar MTP?
Según Google, no debería haber degradación porque el modelo principal conserva la verificación final. Aun así, en entornos reales conviene validar resultados y tareas críticas antes de producción.
¿Funciona ya en vLLM?
La documentación de vLLM ya incluye ejemplos para Gemma 4 con assistant models, pero algunas instalaciones pueden requerir builds recientes o parches todavía no integrados en una release estable.
¿Qué mejora de velocidad se puede esperar?
Google habla de hasta 3x en determinados escenarios. La mejora real dependerá del modelo, hardware, batch size, cuantización, número de tokens especulativos y tipo de tarea.
