Gemma 4 a été publié sans données MTP — Voici pourquoi c'est important

Google a publié Gemma 4 le 3 avril 2026 — une famille de modèles open-weight avec de solides résultats aux benchmarks, des capacités multimodales et jusqu’à 256K tokens de contexte. Sur le papier, c’est une sortie impressionnante. Mais en quelques heures, la communauté a découvert quelque chose de manquant : les têtes de Multi-Token Prediction avaient été retirées des poids publics.

Le modèle a été entraîné avec le MTP. Le propre framework LiteRT de Google inclut les composants MTP. Mais la version que tout le monde peut télécharger depuis HuggingFace ? Génération autorégressive standard uniquement. Pas d’accélération. Pas de décodage spéculatif.

Cet article explique ce qu’est le MTP, pourquoi c’est important, et ce que cette décision signifie pour quiconque utilise Gemma 4 sur son propre matériel.

Qu’est-ce que Gemma 4 ?

Gemma 4 est la dernière famille de modèles open-weight de Google DeepMind, publiée sous licence Apache 2.0. Elle se décline en quatre tailles :

Parmi les capacités clés : le support multimodal natif, l’appel de fonctions, la sortie JSON structurée et un entraînement sur plus de 140 langues. La variante 31B se classe 3e au classement texte de LMArena.

Sous le capot, Gemma 4 introduit plusieurs innovations architecturales : des couches alternées d’attention locale par fenêtre glissante et d’attention globale, le RoPE proportionnel (p-RoPE), les Per-Layer Embeddings (PLE), le cache KV partagé et une optimisation mémoire « Keys equal Values ».

En termes de chiffres, c’est une sortie solide. Le problème, c’est ce qui n’est pas dans les poids publics.

Qu’est-ce que le Multi-Token Prediction ?

Les grands modèles de langage standard génèrent du texte un token à la fois. Chaque token nécessite une passe avant complète à travers le modèle. Le token suivant ne peut pas commencer tant que le précédent n’est pas terminé. C’est le décodage autorégressif, et il est intrinsèquement séquentiel.

Le Multi-Token Prediction (MTP) change la donne en ajoutant des têtes de prédiction supplémentaires au modèle. Au lieu de prédire uniquement le prochain token, le modèle prédit les tokens N+1, N+2, N+3, et ainsi de suite — le tout en une seule passe avant.

Voici comment cela fonctionne :

1. Phase d’entraînement : Des têtes de prédiction légères supplémentaires sont entraînées en parallèle du modèle principal. Chaque tête apprend à prédire une position future différente (1 en avance, 2 en avance, 3 en avance, etc.)
2. Phase d’inférence : Les têtes supplémentaires génèrent des tokens « brouillons » en parallèle. Le modèle principal les vérifie ensuite tous en une seule passe avant.
3. Vérification : Si les tokens brouillons correspondent à ce que le modèle principal aurait généré, ils sont tous acceptés en une fois — sautant ainsi plusieurs étapes de décodage séquentiel. Si un token brouillon est incorrect, la génération reprend à cette position.

Cela est étroitement lié au décodage spéculatif, mais avec un avantage clé : les tokens brouillons proviennent du modèle lui-même plutôt que de nécessiter un modèle « brouillon » séparé et plus petit.

Quelle est l’accélération avec le MTP ?

L’accélération dépend de la fréquence à laquelle les tokens brouillons sont corrects (le « taux d’acceptation »). DeepSeek V3 a démontré l’impact en conditions réelles :

Un taux d’acceptation de 2,4 signifie qu’en moyenne, chaque passe avant à travers le modèle principal produit 2,4 tokens au lieu d’un seul. La sortie est mathématiquement identique au décodage standard — chaque token est vérifié. Vous obtenez la même qualité à presque le double de la vitesse.

Prêt à développer votre entreprise?

Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.

Demander une démo Se connecter

Ce qui s’est passé avec Gemma 4

Un utilisateur de HuggingFace (@shadowlilac ) a découvert que le package LiteRT de Google pour Gemma 4 contient des têtes de prédiction MTP et une fonctionnalité de prédiction multi-tokens. Mais les poids publiés sur HuggingFace n’en contiennent aucune.

Les composants MTP ont été délibérément retirés :

• Pas de têtes MTP dans le checkpoint
• Pas de MTP dans la configuration du modèle
• Pas de MTP dans la passe avant

L’explication de Google

Un ingénieur de Google (@srikanta-221 ) a confirmé que c’était intentionnel :

Le modèle public expose uniquement une interface autorégressive standard « pour une large compatibilité ». Les têtes MTP sont exclues de la configuration du modèle, de la passe avant et du checkpoint. Cela garantit la compatibilité avec les API HuggingFace Transformers et maintient un comportement cohérent du checkpoint et de l’exécution.

Google présente le MTP comme une « optimisation au moment du déploiement » plutôt que comme une fonctionnalité centrale du modèle. Les têtes de prédiction MTP ne sont conservées que dans les modèles exportés via LiteRT — le propre framework d’inférence sur appareil de Google.

Pourquoi c’est un problème

L’explication ne résiste pas à l’examen :

1. Le modèle a été entraîné avec le MTP. La capacité existe. La retirer de la publication est un choix, pas une limitation technique.

2. Les moteurs tiers ne peuvent pas l’implémenter. vLLM, llama.cpp, SGLang et d’autres frameworks d’inférence ne peuvent pas utiliser le décodage spéculatif basé sur le MTP sans les têtes de prédiction. Ces moteurs servent la grande majorité des déploiements LLM open-source.

3. Les utilisateurs obtiennent la version lente. Sans MTP, Gemma 4 fonctionne à la vitesse autorégressive standard. L’écart de performance est déjà visible en pratique :

4. Cela crée un verrouillage écosystémique. Le propre framework LiteRT de Google bénéficie de l’avantage de vitesse. Tout le monde obtient un modèle plus lent. Pour une publication « open-weight » sous Apache 2.0, c’est une asymétrie significative.

Comment fonctionne le décodage spéculatif (et pourquoi le MTP est meilleur)

Pour comprendre pourquoi les têtes MTP manquantes sont importantes, il est utile de voir où le MTP s’inscrit dans l’évolution de l’optimisation de l’inférence.

Approche 1 : Décodage spéculatif traditionnel

Un modèle « brouillon » séparé et plus petit propose des tokens. Le modèle principal les vérifie en parallèle. Si les brouillons sont corrects, plusieurs tokens sont acceptés par étape.

• Avantages : Fonctionne avec n’importe quelle paire de modèles
• Inconvénients : Nécessite de maintenir et charger un second modèle ; la qualité du modèle brouillon limite l’accélération ; surcharge mémoire supplémentaire

Approche 2 : MTP (Têtes de prédiction intégrées)

Le modèle principal possède ses propres têtes de prédiction légères qui génèrent des tokens brouillons. Aucun modèle séparé n’est nécessaire.

• Avantages : Pas de modèle supplémentaire nécessaire ; une intégration plus étroite signifie des taux d’acceptation plus élevés ; surcharge mémoire réduite
• Inconvénients : Ne fonctionne que si les têtes de prédiction sont incluses dans la publication

Pourquoi le MTP l’emporte

Les têtes de prédiction MTP sont entraînées en même temps que le modèle principal. Elles partagent les mêmes représentations internes et apprennent la propre distribution de tokens du modèle. Cela produit généralement des taux d’acceptation plus élevés qu’un modèle brouillon externe, ce qui signifie plus de tokens acceptés par étape de vérification et une génération globalement plus rapide.

Les têtes de prédiction sont également petites — n’ajoutant généralement que 1 à 3 % au nombre total de paramètres du modèle. La surcharge mémoire est négligeable par rapport au chargement d’un modèle brouillon séparé.

Rejoignez notre newsletter

Recevez gratuitement les derniers conseils, tendances et offres.

Adresse e-mail

S'abonner

L’impact global

Il ne s’agit pas seulement de Gemma 4. Cette décision crée un précédent quant au degré réel d’ouverture des publications open-weight.

Ce que les utilisateurs perdent :

• Le décodage spéculatif basé sur le MTP sur tout moteur d’inférence tiers
• La possibilité d’affiner ou d’expérimenter avec les têtes MTP
• La parité de performance avec les propres outils de déploiement de Google

Ce que les utilisateurs conservent :

• Les poids du modèle de base (qui sont véritablement bons)
• Le décodage spéculatif traditionnel utilisant un modèle brouillon séparé (l’issue vLLM #38893 suit le support Eagle3 pour Gemma 4)
• Les techniques standard de quantification et d’optimisation

La réponse de la communauté a été directe. Le consensus après 24 heures était que les résultats de benchmark de Gemma 4 sont compétitifs — il égale ou suit légèrement Qwen 3.5 — mais que le produit « n’est pas terminé ». La vitesse, la stabilité et l’outillage nécessitent du travail. Parmi les problèmes supplémentaires : HuggingFace Transformers manquait initialement du support de l’architecture Gemma 4, PEFT ne gère pas les nouveaux types de couches, et les utilisateurs Mac rencontrent des plantages lors du chargement des modèles les plus grands.

Que pouvez-vous faire ?

Si vous évaluez Gemma 4 pour un déploiement, voici des options pratiques :

Utilisez le décodage spéculatif traditionnel. Des modèles brouillons externes peuvent toujours accélérer l’inférence de Gemma 4. Des frameworks comme vLLM ajoutent le support du décodage spéculatif Eagle3 spécifiquement pour Gemma 4. L’accélération n’égalera pas le MTP intégré, mais c’est mieux que rien.

Envisagez des alternatives pour les charges de travail critiques en vitesse. Qwen 3.5 offre un débit en tokens par seconde nettement supérieur sur du matériel équivalent. Si la vitesse d’inférence est votre contrainte principale, Qwen offre actuellement un meilleur rapport vitesse-qualité.

Surveillez les solutions de contournement de la communauté. Les exports LiteRT contiennent les têtes MTP. Des chercheurs pourraient trouver des moyens de les extraire et de les rattacher aux poids HuggingFace, bien que Google n’ait pas officiellement soutenu cette voie.

Faites part de vos retours. Les ingénieurs de Google surveillent activement les fils de discussion sur HuggingFace. Des demandes claires et techniques pour la publication des têtes MTP ont du poids.

Conclusion

Gemma 4 est une famille de modèles performante avec de véritables innovations architecturales et de solides résultats aux benchmarks. La décision de retirer les têtes de prédiction MTP de la publication publique — tout en les conservant dans le propre framework LiteRT de Google — compromet le « open » d’open-weight.

Le MTP n’est pas une optimisation mineure. Il peut offrir des accélérations d’inférence de 1,5 à 2x sans aucun impact sur la qualité de sortie. Le retenir des poids publics alors que le modèle a clairement été entraîné avec crée un système à deux vitesses : une inférence rapide pour les outils de Google, une inférence lente pour tous les autres.

Pour la communauté IA open-source, le message est clair : vérifiez ce qui se trouve réellement dans les poids, pas seulement les benchmarks. Une licence ouverte ne signifie pas toujours une publication ouverte.

Construit avec FlowHunt . Restez informé des dernières avancées en IA open-source sur notre blog .