Qué es Gemma 4 assistant-MTP: cómo los modelos borrador de Multi-Token Prediction aceleran la inferencia

Cuando veas nombres como assistant-MTP, assistant o MTP drafter en modelos relacionados con Gemma 4, no los trates como modelos de chat independientes.

Su definición más precisa es esta: son modelos borrador de predicción de múltiples tokens emparejados con los modelos principales Gemma 4, usados para Speculative Decoding.

En una frase: el modelo principal toma la decisión final, mientras assistant-MTP escribe un borrador por adelantado. Si el borrador acierta, el modelo principal puede confirmar varios tokens a la vez y la generación se acelera.

Qué Es Exactamente

MTP significa Multi-Token Prediction.

assistant-MTP de Gemma 4 puede entenderse como un modelo auxiliar ligero, también llamado a menudo drafter, draft model o modelo borrador. Normalmente se usa en pareja con el modelo principal Gemma 4 correspondiente, por ejemplo:

Gemma 4 12B con su 12B assistant-MTP correspondiente
Gemma 4 26B con su 26B assistant-MTP correspondiente
Gemma 4 31B con su 31B assistant-MTP correspondiente

Su función no es responder directamente al usuario, sino predecir para el modelo principal los siguientes tokens probables.

La salida final sigue siendo verificada y decidida por el modelo principal. Por eso assistant-MTP se parece más a un “lector anticipado” o “cabezal borrador” que a un nuevo modelo de chat.

Por Qué La Generación Normal Es Lenta

Los modelos de lenguaje autorregresivos tradicionales suelen generar texto así:

Predicen el siguiente token a partir del contexto existente.
Añaden ese token de vuelta al contexto.
Predicen el siguiente token.
Repiten hasta completar la generación.

Este proceso es estable, pero naturalmente serial. Incluso si los siguientes tokens son fáciles de adivinar, como formatos fijos, plantillas de código o frases comunes, el modelo debe calcularlos uno por uno.

En inferencia local o en GPU de consumo, esta generación token a token amplifica el cuello de botella del ancho de banda de memoria: cada token generado requiere mover repetidamente una gran cantidad de pesos del modelo, y las unidades de cómputo no siempre se aprovechan por completo.

La idea de MTP es aprovechar ese hueco: dejar que un modelo borrador más ligero prediga varios tokens primero y luego entregarlos al modelo principal para verificación paralela.

Cómo Funciona Speculative Decoding

El flujo puede dividirse en cuatro pasos:

assistant-MTP predice primero varios tokens futuros.

Por ejemplo, puede adivinar 4 tokens candidatos a la vez.
El modelo principal lee esos tokens candidatos.

El modelo principal no confía ciegamente en el borrador, sino que comprueba en paralelo si esos tokens encajan con su propia distribución.
Los tokens acertados se aceptan.

Si los primeros 3 tokens pasan la verificación, equivale a que el modelo principal haya generado 3 tokens en un solo paso.
La generación retrocede en la primera posición incorrecta.

Si el 4.º token no se acepta, la generación continúa desde ahí con la lógica normal del modelo principal.

Así que esto no es “sacrificar calidad por velocidad”. El modelo principal sigue realizando la verificación final; simplemente se adelantan posibles tokens correctos para comprobarlos.

Por Qué La Salida Puede Mantenerse Consistente

El malentendido más común sobre speculative decoding es: si se usa un modelo pequeño, ¿el resultado empeora?

En speculative decoding estándar, la respuesta suele ser no. El modelo borrador solo propone candidatos, mientras que el modelo principal los acepta o rechaza. Los tokens aceptados deben ajustarse a la lógica de muestreo del modelo principal; los tokens que no encajan se rechazan.

Esto significa que, en teoría, la distribución final de salida puede mantenerse consistente con la generación sin modelo borrador. Google también posiciona el MTP drafter de Gemma 4 como una forma de mejorar la velocidad sin reducir la calidad de salida ni el comportamiento de razonamiento.

En ingeniería real, el resultado final también depende de la implementación del framework de inferencia, los parámetros de muestreo, la completitud del soporte MTP y si el modelo principal y el assistant están emparejados correctamente.

Por Qué Puede Acelerar

La aceleración viene de dos factores:

El modelo borrador es más ligero, así que predecir tokens candidatos cuesta menos.
El modelo principal puede verificar varios tokens candidatos a la vez, reduciendo la espera token por token.

Si assistant-MTP acierta con frecuencia, una sola pasada forward del modelo principal puede aceptar varios tokens, y el rendimiento mejora de forma notable. Cuando Google lo anunció, mencionó que Gemma 4 con un MTP drafter puede lograr hasta alrededor de 3x de aceleración en cierto hardware y ciertos frameworks.

Pero esa cifra no se reproduce de forma estable en cualquier escenario. La aceleración real depende de:

Tamaño del modelo principal.
Grado de coincidencia entre el assistant y el modelo principal.
Cuántos speculative tokens se predicen cada vez.
Tipo de prompt.
Temperatura de muestreo.
Implementación del framework de inferencia.
Ancho de banda de GPU / CPU / memoria.

En general, texto formateado, código, estructuras fijas y frases comunes son más fáciles de predecir para el modelo borrador. La generación muy abierta, aleatoria o con temperature alta puede acelerar menos.

Cómo Usarlo

assistant-MTP necesita soporte del framework de inferencia. Descargar el modelo assistant no significa que se pueda chatear con él directamente.

Hay dos patrones de uso comunes.

Método 1: Soporte MTP Integrado En El Modelo Principal

Algunos frameworks pueden leer directamente la estructura MTP de Gemma 4 y activarla mediante parámetros. Por ejemplo, una dirección habitual en la comunidad de vLLM es usar speculative config:

1
2


vllm serve google/gemma-4-31B-it \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

Este método no siempre requiere especificar un modelo assistant por separado; depende del formato del modelo y de la implementación del framework.

Método 2: Cargar Por Separado El Modelo assistant / drafter

En escenarios de inferencia local como GGUF / llama.cpp, es más común cargar por separado el modelo principal y el modelo draft. La idea es similar a esta:

1
2
3
4
5
6


llama-server \
  -m gemma-4-12B-it-Q4_K_M.gguf \
  --model-draft gemma-4-12B-it-assistant-MTP-Q8_0.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 4 \
  --ctx-size 8192

Lo importante aquí es:

-m apunta al modelo principal.
--model-draft apunta al modelo borrador assistant-MTP.
--spec-type draft-mtp activa el modo borrador MTP.
--spec-draft-n-max 4 significa redactar como máximo 4 tokens.

Los parámetros pueden cambiar entre versiones de llama.cpp, así que antes de usarlo conviene revisar el --help de la versión actual y la tarjeta del modelo.

Cómo Ajustar Los Parámetros

`--spec-draft-n-max`

Este parámetro controla cuántos tokens puede redactar assistant-MTP como máximo en una vez.

Puedes empezar con un valor pequeño:

1

--spec-draft-n-max 2

Luego probar:

1

--spec-draft-n-max 4

Un valor mayor no siempre es más rápido. Si baja la tasa de acierto del borrador, el modelo principal rechazará candidatos con frecuencia y se desperdiciará cómputo.

temperature

Cuanto mayor sea la temperature, más aleatoria será la salida y más difícil será para assistant-MTP adivinar los siguientes tokens del modelo principal.

Si el objetivo es velocidad y estabilidad, puedes empezar con:

1

--temp 0.7

O más bajo:

1

--temp 0.4

Para autocompletado de código, reparación de formato y salidas estructuradas, una temperature baja suele ser más adecuada.

Longitud De Contexto

MTP no es magia de VRAM. Tanto el modelo principal como el modelo borrador consumen recursos, y los contextos largos siguen consumiendo KV cache.

En máquinas con 8GB o 12GB de VRAM, no empieces directamente con 64K / 128K. Puedes probar primero:

1

--ctx-size 8192

Después de confirmar estabilidad, súbelo poco a poco.

Tareas Adecuadas

assistant-MTP encaja mejor en estos escenarios:

Autocompletado de código.
Salidas estructuradas como JSON / Markdown / XML.
Informes con formato fijo.
Pasos matemáticos o salidas tipo tabla.
Preguntas y respuestas con baja temperature y mayor determinismo.
Reducir latencia al chatear con modelos locales.

Lo común en estas tareas es que los tokens posteriores tienen patrones fuertes, por lo que el modelo borrador los predice con más facilidad.

Tareas Poco Adecuadas

No debe tratarse como una herramienta para “hacer más inteligente al modelo”.

assistant-MTP no vuelve más inteligente al modelo principal ni mejora la exactitud factual. Resuelve velocidad de generación, no calidad de razonamiento.

Estos escenarios pueden aportar poco beneficio:

Escritura creativa con temperature muy alta.
Muestreo muy aleatorio.
Desajuste entre el modelo borrador y el modelo principal.
Soporte MTP incompleto en el framework de inferencia.
VRAM ya muy ajustada y necesidad de cargar además un modelo draft.

Especialmente en máquinas con poca VRAM, recuerda que assistant-MTP también ocupa VRAM o RAM. La ganancia de velocidad puede quedar compensada por el uso adicional de recursos.

Malentendidos Comunes

Malentendido 1: assistant-MTP Es Un Modelo De Chat

No. Es un modelo auxiliar para speculative decoding con el modelo principal. Chatear directamente con él no tiene sentido práctico y puede dar resultados pobres.

Malentendido 2: Al Usar MTP La Salida Siempre Será Igual

El objetivo teórico es preservar la distribución de salida del modelo principal, porque la verificación final la realiza el modelo principal. Pero la implementación, los parámetros de muestreo y la versión del framework pueden afectar el comportamiento real. Conviene hacer pruebas comparativas antes de producción.

Malentendido 3: Cuanto Mayor Sea `--spec-draft-n-max`, Mejor

No necesariamente. Cuantos más tokens se redacten, mayor puede ser la probabilidad de fallar. Hay que observar la tasa de aceptación y los tokens/s, no solo el valor del parámetro.

Malentendido 4: Puede Resolver La Falta De VRAM

No. MTP acelera la inferencia, no comprime VRAM. En máquinas con poca VRAM, primero conviene ajustar cuantización, longitud de contexto y capas descargadas a GPU; luego considerar MTP.

Cómo Saber Si Realmente Acelera

No te fíes solo de la sensación. Haz una prueba A/B con el mismo conjunto de prompts:

Ejecuta sin MTP y registra tokens/s.
Ejecuta con MTP y registra tokens/s.
Mantén el mismo modelo, contexto, temperature y prompt.
Compara calidad de salida y latencia.

Puedes probar con tres tipos de prompt:

1

Escribe una función en Python que convierta una tabla Markdown a CSV.

1
2


Corrige el siguiente JSON y devuelve solo JSON válido:
{"name":"demo","items":[{"id":1,"tags":["a","b",],},]}

1

Devuelve 5 pasos de resolución de problemas de Linux en un formato fijo. Cada elemento debe incluir: problema, comando y criterio de juicio.

Si estas tareas estructuradas se vuelven claramente más rápidas y la calidad no baja, assistant-MTP merece quedarse en tu entorno.

Resumen

Gemma 4 assistant-MTP es un modelo borrador de Multi-Token Prediction usado junto con el modelo principal. Mediante speculative decoding, predice varios tokens por adelantado y luego deja que el modelo principal los verifique en paralelo, reduciendo la latencia de la generación token por token.

Su valor es la velocidad, no una mejora de capacidad del modelo. La forma correcta de usarlo es: el modelo principal se encarga de la salida final, assistant-MTP redacta por adelantado y el framework de inferencia verifica y acepta los tokens candidatos.

Si ya puedes ejecutar Gemma 4 de forma estable, entonces considera MTP. Empieza con un número pequeño de speculative tokens, observa tokens/s, uso de VRAM y calidad de salida, y decide si incorporarlo a tu script diario.

Referencias: