La communauté met au jour la dissimulation du MTP dans Gemma 4, puis Google propose tardivement une prise en charge de contournement

(reddit.com)

5 points par darjeeling 1 시간 전 | 2 commentaires | Partager sur WhatsApp

Google avait retiré de l’édition publique de Gemma 4 cette fonctionnalité pourtant présente lors de l’entraînement avec MTP, avant de commencer tardivement à la proposer sous la forme d’un modèle assistant externe après que l’affaire a été révélée par le reverse engineering de la communauté.

Des développeurs open source qui analysaient les fichiers .litertlm (basés sur TFLite), le format distribué par Google pour les appareils mobiles et edge, ont découvert un fait surprenant. Une architecture MTP (Multi-Token Prediction, prédiction multi-token) absente des poids standards publiés sur HuggingFace n’était incluse que dans les fichiers compilés pour l’edge.

Lorsque cela a été publiquement dénoncé, Google l’a reconnu et a répondu ceci :

> « Les têtes de prédiction liées au MTP ont été volontairement exclues du modèle public pour assurer la compatibilité avec l’API HuggingFace Transformers. Elles ont été conservées dans le runtime LiteRT afin d’améliorer les performances on-device. »

Qu’est-ce que le MTP

Un LLM classique génère les tokens un par un, de manière séquentielle. Le MTP est une technique qui prédit plusieurs tokens à la fois en un seul forward pass et qui, combinée au speculative decoding, peut fortement accélérer l’inférence sans modification de la qualité de sortie. Il s’agit en théorie d’une optimisation sans perte (lossless).

Les tentatives de reverse engineering de la communauté

L’auteur de la découverte initiale est parvenu à extraire plusieurs fichiers .tflite à partir d’un fichier .litertlm, puis a publié sur HuggingFace les fichiers extraits ainsi que la procédure de reproduction, en demandant l’aide de personnes à l’aise en C++. Des contributeurs de la communauté ont ensuite lancé un véritable effort de reverse engineering.

Difficulté technique : la structure des kernels TFLite était particulièrement pénible. Le schéma consistait à quantifier en INT8 des vecteurs d’attention de largeur 1024 → les multiplier par des poids INT8 → re-quantifier le résultat → puis le déquantifier à nouveau.

Résultat : après plusieurs jours de travail intensif, ils sont parvenus à reconstruire :

la structure GQA (Grouped-Query Attention) et le mapping du cache KV externe
le fonctionnement de la fenêtre locale glissante
les chemins de quantification pre_project / q_proj / MLP / o_proj / post_project
le fonctionnement partiel de RoPE
une parité TFLite end-to-end avec 20/20 de correspondance top-1

La licence étant Apache 2.0, il n’y a pas de problème juridique.

Performances réelles : à quel point est-ce rapide ?

Mesures réalisées par la communauté (sur Strix Halo) :

Tâche	Avant	Après application du MTP
Génération de code	8 tps	25 tps (environ 3x)
Rédaction générale	7~8 tps	11~14 tps

Comparé au speculative decoding classique sur les familles LLaMA/Qwen3, qui tourne généralement autour de 1,5~1,7x et au maximum 2x, atteindre 3x en génération de code est inhabituel. Cela s’expliquerait par le fait que le code contient beaucoup de boilerplate répétitif, ce qui augmente le taux d’acceptation des draft tokens.

Réactions de la communauté et soupçons

Les critiques se sont principalement concentrées sur deux points.

① Critique du caractère non documenté (Undocumented) : Google aurait entraîné le modèle avec MTP, puis l’aurait volontairement retiré de l’édition publique sans jamais le mentionner.

② Soupçon d’intention commerciale : selon cette thèse, « si un modèle open source 31B exécutable en local devenait trop rapide, il menacerait la compétitivité des API commerciales de l’entreprise (comme Flash Lite), d’où un nerf volontaire ». Le modèle 122B, qui avait aussi fuité avant d’être supprimé, a été mentionné dans le même contexte.

Le choix structurel de Google

Canal de distribution	MTP inclus ou non
Poids publics HuggingFace	❌ retrait volontaire
LiteRT (edge/mobile)	✅ intégré
`gemma4_assistant` (nouveau au 5/5)	✅ prise en charge détournée via un modèle assistant externe

Réponse officielle tardive de Google (5–6 mai)

Face à la pression croissante de la communauté, Google a publié le 5 mai un modèle assistant séparé, gemma4_assistant, sur HuggingFace, puis a annoncé via son blog officiel le drafteur MTP de Gemma 4. Il s’agit d’une prise en charge indirecte consistant à détacher en modèle externe une fonctionnalité qui aurait dû se trouver dans le modèle d’origine.

Vitesse : jusqu’à 3x d’accélération de l’inférence sans baisse de qualité
Modèle assistant : drafteur léger d’environ 500M de paramètres
Utilisation : il suffit de le passer à l’argument assistant_model= de la fonction generate(). Aucune implémentation MTP personnalisée n’est nécessaire
Environnements pris en charge : HuggingFace Transformers, vLLM, MLX (Apple Silicon), LiteRT-LM

> 💡 Résumé en une ligne : Google avait retiré de l’édition publique de Gemma 4 la fonctionnalité MTP utilisée à l’entraînement, avant de commencer tardivement à la reproposer sous forme de modèle assistant externe après sa mise au jour par le reverse engineering de la communauté.