La comunidad destapa el MTP oculto de Gemma 4, y Google termina dando soporte por una vía alterna

(reddit.com)

5 puntos por darjeeling 1 시간 전 | 2 comentarios | Compartir por WhatsApp

Google eliminó de la edición pública de Gemma 4 una función con la que el modelo había sido entrenado: MTP. Después de que la comunidad lo descubriera mediante ingeniería inversa, la empresa terminó ofreciendo soporte tardío en forma de un modelo asistente externo.

Desarrolladores de código abierto que analizaban archivos .litertlm (basados en TFLite), el formato distribuido por Google para dispositivos móviles y edge, encontraron algo sorprendente. La arquitectura MTP (Multi-Token Prediction, predicción multitéoken), que no existe en los pesos estándar públicos de HuggingFace, sí estaba incluida únicamente en los archivos compilados para edge.

Cuando esto se señaló públicamente, Google reconoció el hecho y respondió así:

"Los heads de predicción relacionados con MTP se excluyeron intencionalmente del modelo público para mantener la compatibilidad con la API de HuggingFace Transformers. Se conservaron en el runtime de LiteRT para mejorar el rendimiento on-device."

Qué es MTP

Un LLM normal genera tokens uno por uno, de forma secuencial. MTP es una técnica que predice varios tokens al mismo tiempo en un solo forward pass y, cuando se combina con speculative decoding, puede aumentar mucho la velocidad de inferencia sin cambios en la calidad de salida. En teoría, es una optimización sin pérdida (lossless).

El intento de ingeniería inversa de la comunidad

La persona que hizo el descubrimiento original logró extraer varios archivos .tflite desde un archivo .litertlm, publicó en HuggingFace los archivos extraídos y el procedimiento de reproducción, y pidió apoyo a gente con experiencia en C++. Después de eso, colaboradores de la comunidad comenzaron una labor de ingeniería inversa más a fondo.

Dificultad técnica: la estructura de kernels de TFLite era infernal. El flujo consistía en cuantizar a INT8 un vector de atención de ancho 1024 → multiplicarlo con pesos INT8 → volver a cuantizar el resultado → y luego descuantizarlo otra vez.

Resultado: tras varios días de trabajo intensivo, lograron reconstruir lo siguiente:

la estructura de GQA (Grouped-Query Attention) y el mapeo del caché KV externo
el funcionamiento de la ventana local deslizante
la ruta de cuantización de pre_project / q_proj / MLP / o_proj / post_project
el comportamiento parcial de RoPE
paridad end-to-end con TFLite, logrando 20/20 coincidencias top-1

La licencia es Apache 2.0, así que no hay problemas legales.

Rendimiento real: qué tan rápido es

Según mediciones de la comunidad (en Strix Halo):

Tarea	Antes	Después de aplicar MTP
Generación de código	8 tps	25 tps (aprox. 3x)
Escritura general	7~8 tps	11~14 tps

Comparado con el speculative decoding en modelos tipo LLaMA/Qwen3, que normalmente ronda entre 1.5~1.7x y como mucho 2x, llegar a 3x en tareas de código es una cifra inusual. Se interpreta que, por la naturaleza de la generación de código, hay mucho boilerplate repetitivo y por eso la tasa de aceptación de draft tokens es más alta.

Reacción de la comunidad y sospechas

Las críticas se concentraron en dos frentes.

① Crítica por falta de documentación (Undocumented): que el modelo hubiera sido entrenado con MTP, pero la función se retirara intencionalmente de la edición pública sin mencionarlo en ningún momento.

② Sospecha de intención comercial: la acusación de que "si un modelo open source local de 31B se vuelve demasiado rápido, podría amenazar la competitividad de su API comercial (como Flash Lite), así que lo degradaron intencionalmente". El modelo filtrado y luego eliminado de 122B también fue mencionado en el mismo contexto.

La decisión estructural de Google

Canal de distribución	¿Incluye MTP?
Pesos públicos en HuggingFace	❌ eliminado intencionalmente
LiteRT (edge/móvil)	✅ integrado
`gemma4_assistant` (nuevo 5/5)	✅ soporte alterno como modelo asistente externo

Respuesta oficial tardía de Google (5 al 6 de mayo)

Cuando la presión de la comunidad aumentó, Google publicó el 5 de mayo un modelo asistente separado llamado gemma4_assistant en HuggingFace, y en su blog oficial presentó el drafter MTP de Gemma 4. Es una forma de dar soporte por una vía alterna, separando como modelo externo una función que originalmente debería haber estado dentro del modelo.

Velocidad: hasta 3 veces más velocidad de inferencia sin degradación de calidad
Modelo asistente: un drafter ligero de alrededor de 500M parámetros
Uso: basta con pasarlo como argumento assistant_model= a la función generate(). No hace falta una implementación MTP personalizada
Entornos compatibles: HuggingFace Transformers, vLLM, MLX (Apple Silicon), LiteRT-LM

💡 Resumen en una línea: Google eliminó de la edición pública de Gemma 4 una función con la que el modelo había sido entrenado: MTP. Después de que la comunidad lo descubriera mediante ingeniería inversa, la empresa terminó ofreciendo soporte tardío en forma de un modelo asistente externo.