Accélérer Gemma 4 : une inférence plus rapide avec un drafter de prédiction multi-token

• Quelques semaines après le lancement de Gemma 4, Google a dépassé les 60 millions de téléchargements et a dévoilé un drafter de prédiction multi-token (MTP) pour la gamme Gemma 4
• Le drafter MTP repose sur une architecture spécialisée de speculative decoding qui peut multiplier par trois la vitesse d’inférence sans dégrader la qualité de sortie ni la logique de raisonnement, avec des tests réalisés sur du matériel utilisant LiteRT-LM, MLX, Hugging Face Transformers et vLLM
• L’inférence LLM standard est fortement limitée par un goulot d’étranglement de bande passante mémoire, car des milliards de paramètres doivent être déplacés de la VRAM vers les unités de calcul pour générer un seul token ; avec MTP, un drafter léger propose plusieurs tokens futurs, puis le modèle cible les vérifie en parallèle
• Si le modèle cible accepte les tokens proposés, il valide toute la séquence en une seule passe avant et génère en plus un token supplémentaire, ce qui permet généralement à l’application de produire la séquence proposée et un token additionnel dans le temps d’un seul token
• Le drafter MTP partage les activations du modèle cible et le cache KV, applique un clustering efficace de l’embedder pour les modèles edge E2B et E4B, et ses poids sont disponibles sous licence Apache 2.0 sur Hugging Face et Kaggle

---

Pourquoi le speculative decoding est nécessaire

• L’inférence LLM standard est contrainte par la bande passante mémoire, ce qui crée un important goulot d’étranglement de latence
• Les processeurs passent l’essentiel de leur temps à déplacer des milliards de paramètres de la VRAM vers les unités de calcul afin de générer un seul token
• Cette structure empêche notamment le matériel grand public d’exploiter pleinement ses ressources de calcul et augmente la latence
• Le speculative decoding sépare la génération de tokens de leur vérification
• Un modèle cible lourd, par exemple Gemma 4 31B, est associé à un drafter léger, le modèle MTP, pour prédire plusieurs tokens futurs d’un coup en exploitant les ressources de calcul inoccupées
• Le drafter propose plusieurs tokens en moins de temps qu’il n’en faut au modèle cible pour en traiter un seul, puis le modèle cible vérifie les tokens proposés en parallèle

Comment fonctionne le MTP

• Les grands modèles de langage standard génèrent le texte de manière autorégressive, en produisant exactement un token à la fois
• Cette approche consacre la même quantité de calcul à une suite évidente comme « Actions speak louder than… » menant à « words » qu’à la résolution d’une énigme logique complexe
• Le MTP réduit cette inefficacité grâce au speculative decoding introduit par les chercheurs de Google dans Fast Inference from Transformers via Speculative Decoding
• Si le modèle cible accepte les tokens proposés, il valide toute la séquence en une seule passe avant, et le modèle cible lui-même génère simultanément un token supplémentaire
• L’application peut généralement produire la séquence proposée complète et un token supplémentaire dans le temps nécessaire à la génération d’un seul token

Les gains de performance pour les développeurs

• Pour les développeurs, la vitesse d’inférence constitue souvent un goulot d’étranglement majeur en production
• Dans les agents autonomes nécessitant une planification rapide en plusieurs étapes, les assistants de code et les applications mobiles réactives exécutées entièrement on-device, chaque milliseconde de latence compte
• En utilisant les modèles Gemma 4 avec ce drafter, on obtient les effets suivants

• Réactivité améliorée

  • Réduction importante de la latence pour les chats quasi temps réel, les applications vocales immersives et les workflows agentiques

• Développement local accéléré

  • Exécution plus rapide des modèles 26B MoE et 31B Dense sur PC personnels et GPU grand public pour prendre en charge des workflows complexes de code hors ligne et des workflows agentiques

• Performances on-device renforcées

  • Sortie plus rapide des modèles E2B et E4B sur des appareils edge, ce qui aide à réduire la consommation de batterie

• Aucune baisse de qualité

  • Comme le modèle Gemma 4 de base conserve la validation finale, il offre le même niveau de raisonnement et de précision, mais bien plus rapidement
  • Un exemple d’exécution de Gemma 4 26B sur une NVIDIA RTX PRO 6000 compare le nombre de tokens par seconde entre l’inférence standard et le drafter MTP, et montre une latence divisée par deux à qualité de sortie identique
  • La vidéo de comparaison peut être téléchargée

Optimisations internes du drafter MTP

• Plusieurs améliorations d’architecture ont été appliquées pour rendre le drafter MTP rapide et précis
• Le modèle de brouillon exploite naturellement les activations du modèle cible et partage son cache KV
• Grâce au partage du cache KV, le grand modèle ne perd pas de temps à recalculer un contexte qu’il a déjà traité
• Sur les modèles edge E2B et E4B, le calcul final des logits constitue un gros goulot d’étranglement ; une technique de clustering efficace a donc été implémentée dans l’embedder afin d’accélérer la génération
• Des optimisations spécifiques au matériel ont également été analysées
• Sur Apple Silicon, le modèle mixture-of-experts 26B présente des contraintes de routage particulières avec une taille de batch de 1, mais le traitement simultané de plusieurs requêtes permet d’obtenir jusqu’à environ 2,2x d’accélération en local
• Les tailles de batch données en exemple vont de 4 à 8, et des gains similaires apparaissent également sur NVIDIA A100 lorsque la taille de batch augmente
• L’architecture visuelle, le partage du cache KV et le fonctionnement de l’embedder efficace sont détaillés dans cette explication technique approfondie

Utilisation et disponibilité

• Le drafter MTP pour la gamme Gemma 4 est proposé sous la même licence open source Apache 2.0 que Gemma 4
• La manière d’utiliser MTP avec Gemma 4 est décrite dans la documentation
• Les poids du modèle peuvent être téléchargés sur Hugging Face et Kaggle
• L’inférence accélérée peut être testée avec transformers, MLX, vLLM, SGLang et Ollama
• Il est aussi possible de l’essayer directement via Google AI Edge Gallery sur Android ou iOS
• Google espère que cette amélioration de vitesse accélérera le développement dans Gemmaverse, l’écosystème Gemma

[GN⁺]

Commentaires Hacker News

• Gemma et Gemini utilisent beaucoup moins de tokens en sortie que d’autres modèles tout en restant assez proches des meilleures performances sur les benchmarks
  En comparant Gemma et Qwen, Qwen fait un peu mieux, mais passe 22 minutes sur la tâche, alors que Gemma termine souvent le même prompt en 4 minutes, même s’il se trompe sur l’alignement des boutons
  En apparence, Gemma est 5 à 10 % moins performant que les meilleurs modèles open source, mais n’utilise que 1/10 du temps

  • Dans la pratique, même en codant toute la journée avec le forfait de base Gemini à 15 dollars par mois, je n’atteins pas la limite
    Je n’ai jamais ressenti le besoin de passer à une offre supérieure comme celles à 100 dollars par mois que d’autres utilisent sur Claude ou Codex
    Cela dit, Gemini a vu ses performances baisser plusieurs fois au cours de l’année passée, et les limitations de débit se sont aussi durcies, donc on ne sait pas si ça restera aussi bon à l’avenir
  • Dans le podcast de Dwarkesh, Dylan Patel de SemiAnalysis a expliqué que Google pouvait se permettre des modèles plus gros que ses concurrents grâce à bien plus de capacité de calcul et à l’accès aux TPU
    Comme les grands modèles utilisent généralement moins de tokens à intelligence égale, cela semble pouvoir expliquer cette différence de consommation de tokens
  • Comme Gemma est rapide, il peut tourner même sur des GPU initialement un peu trop justes en taille
    Je l’ai essayé sur une 4070 : la sortie n’est pas incroyablement rapide, mais ça reste exploitable
    Je ne l’ai pas encore testé sur des tâches complexes, donc ce sera peut-être différent dans ce cas
  • En ce moment Claude est très à la mode, mais je n’ai jamais eu de problème avec Gemini ni ressenti le besoin de changer
    Après Google I/O, plus de gens découvriront peut-être à quel point Gemini est bon
  • C’est vrai, mais pour être équitable il faut additionner le volume cumulé de tokens produits
    S’il y a un problème d’alignement, il faut consommer à nouveau des tokens en entrée et en sortie pour le corriger

• La prise en charge de MTP est en cours d’ajout dans llama.cpp, au moins pour les modèles Qwen (https://github.com/ggml-org/llama.cpp/pull/20533)
  Gemma 4 devrait sans doute suivre bientôt
  Les progrès en qualité et en vitesse des modèles locaux et auto-hébergés ces derniers mois sont impressionnants

  • Il existe une PR plus récente qui semble devoir être fusionnée bientôt : https://github.com/ggml-org/llama.cpp/pull/22673
  • Il y a quelques jours, pour mon usage personnel, je suis repassé de Qwen3.6 à Gemma 4, et la version 26B de ce dernier a montré de meilleures performances moyennes que le 27B du premier
    Pour quelqu’un qui fait tourner des modèles locaux depuis longtemps, c’est une période vraiment passionnante
  • L’intérêt monte aussi autour de l’intégration de DFlash : https://github.com/ggml-org/llama.cpp/issues/21978
    J’ai hâte de voir ce que ça donne par rapport à MTP
  • J’aimerais aussi voir ça dans oMLX
    C’était un outil tout à fait correct
  • Je ne sais pas exactement où se situe l’inférence MTP dans la pile d’inférence, mais si quelqu’un sait si c’est implémentable dans l’écosystème MLX, ça m’intéresse

• Google porte presque à lui seul les modèles open source occidentaux
  Gemma 4 31B est excellent
  En revanche, faire tenir la meilleure version, avec la vision et bientôt le drafter, dans 24 Go de VRAM est assez pénible
  Ma configuration ne permet pas d’ajouter plus de GPU, et pour obtenir les meilleures performances il faudrait sans doute que j’achète une 4090 supplémentaire, ce qui coûte trop cher, ou bien que je remplace complètement la machine

  • Dans llama.cpp, avec --no-mmproj-offload, on peut garder le projecteur multimodal, c’est-à-dire la partie compréhension audio, image et PDF, dans la RAM système
    Bien sûr, il n’y a alors plus d’accélération GPU, mais cela économise de la VRAM
  • Je continue quand même à penser que Qwen est meilleur que Gemma
    On peut aussi l’ajuster davantage selon la tâche, pour choisir entre privilégier le raisonnement et la précision, ou la vitesse d’inférence

• Regarder un ordinateur écrire me rappelle l’époque où on se connectait à un BBS avec un modem
  C’est une grosse amélioration, comme passer de 300 bauds à 1200 bauds, mais ça reste assez lent, et un jour on se demandera sûrement comment on faisait pour tolérer ça

  • L’état actuel fait vraiment penser à l’époque du bas débit, et je me demande souvent à quoi ressemblera l’ère du « haut débit » à venir
    Voir les tokens défiler, c’est comme regarder un JPEG se charger ligne de pixels par ligne de pixels, et ça rappelle aussi toutes les animations de chargement ou de connexion que les applis implémentaient chacune de leur côté avant que les choses deviennent assez rapides
    Le travail de Cerebras ou Taalas donne des indices intéressants sur ce qui pourrait être possible dans cette direction
    C’est aussi amusant d’imaginer ce qu’on pourrait faire si même les modèles de pointe actuels pouvaient produire un million de tokens par seconde à très faible coût
  • Oui, ça rappelle l’époque du bas débit, mais je dirais qu’on est plus proche des 4800 bauds que de 300 à 1200
    Voici la comparaison modem vs Claude calculée par Claude : pour 2368 caractères, 300 bauds prend 1 min 19 s, 1200 bauds 19,7 s, 2400 bauds 9,9 s, 14,4K 1,6 s, 33,6K 705 ms, 56K 447 ms, et Claude 7,9 s
  • Une startup passée ici avait fabriqué du matériel sur mesure permettant à l’IA de répondre instantanément
    On était à plusieurs milliers de tokens par seconde

• La stratégie de Google semble un peu différente de celle des autres fournisseurs de frontier models
  Ils paraissent davantage se concentrer sur l’efficacité performance/calcul que sur la performance brute, ce qui explique peut-être pourquoi Gemini donne parfois l’impression d’être en retrait
  Les autres fournisseurs se heurtent à des limites de capacité et arrivent aussi au bout de ce qu’ils peuvent subventionner sur les coûts d’inférence
  La stratégie de Google semble être de faire passer ces modèles à l’échelle et de les déployer auprès de ses milliards d’utilisateurs existants

  • Je ne pense pas que Gemini soit en retard
    J’ai plutôt l’impression qu’il s’agit d’un autre type d’intelligence que les dernières générations de GPT-5 et de la famille Claude
    Ces derniers se concentrent de plus en plus sur la productivité et l’automatisation du travail, avec une optimisation pour de longues boucles de raisonnement agentique auto-correctif
    Gemini ressemble davantage à un modèle de base beaucoup plus intelligent, et en particulier en mode Deep Think, son intuition paraît bien plus profonde, mais il est moins bon sur les longues boucles agentiques d’auto-correction
    Depuis quelques mois, dans mon flux de travail, j’utilise Gemini pour les sauts créatifs et les intuitions, et je préfère Codex, Claude et GPT-5.5 Pro pour les tâches répétitives ou de précision
  • J’ai l’impression que la stratégie de tout le monde est en train d’évoluer dans cette direction

• Après une pause avec les modèles locaux, j’ai récemment configuré le modèle 26B A4B sur une RTX 3090 avec vLLM en 4 bits, et j’ai été complètement bluffé par la vitesse et la qualité qu’on peut obtenir pour moins de 1000 dollars d’investissement
  J’avais d’abord essayé avec Qwen, mais c’était instable, et les traces de raisonnement étaient absurdement longues

  • Certaines des premières versions quantifiées de qwen3.6 étaient corrompues
    Cela reste encore délicat, mais avec un peu de réglage c’est vraiment remarquable
    Les modèles locaux sont l’avenir, et c’est génial
  • Avec turboquant / Q4, ça tourne même sur une 3060, avec une vitesse tout à fait correcte de 40T/s sur une carte à environ 200 dollars
  • Le modèle A4B est extrêmement rapide et très bon pour les requêtes générales
    Il est clairement inférieur à Qwen 3.6 sur les tâches de code, mais cela montre surtout à quel point les modèles Qwen sont excellents
  • Le 31B aussi est étonnamment rapide pour un modèle dense
    Sur ma machine, par rapport à d’autres modèles 30B, le tg est au moins deux fois plus rapide que prévu, probablement grâce à l’attention hybride
    En revanche, le traitement de l’entrée est un peu plus lent

• Je me demande si quelqu’un a réussi à faire fonctionner ça dans LM Studio
  Il y a bien une option dans l’interface, mais elle ne semble pas vraiment s’activer

  • Ce n’est pas encore implémenté dans mlx[1] ni dans llama.cpp[2], donc cela peut prendre un peu de temps
    [1] https://github.com/ml-explore/mlx-lm/pull/990
    [2] https://github.com/ggml-org/llama.cpp/pull/22673
  • Si, ça fonctionne
    Comme il n’existe pas de petit modèle, il faut vérifier que vous n’utilisez pas un modèle sparse Gemma
    Et j’ai supprimé tous les modèles d’image de l’espace de travail
  • En général, ce que LM Studio n’aime pas, c’est la présence d’un fichier mmproj dans le dossier
    Il arrive que le simple fait de les supprimer fasse apparaître l’option
    Ces fichiers semblent liés d’une manière ou d’une autre aux capacités visuelles et empêcher le speculative decoding, ne me demandez pas pourquoi
    Avec Gemma, j’ai eu de meilleurs résultats avec le speculative decoding via la voie llama-server qu’avec LM Studio
  • J’ai déjà réussi à le faire fonctionner avec d’autres modèles
    En général, il faut que tout corresponde parfaitement entre fournisseur, quantification, etc.
    Trouver un ensemble compatible peut prendre un peu de temps

• Dans mes tests, le modèle Gemma 4 31B a montré le plus gros gain de vitesse sur les tâches de code avec le runner MLX d’Ollama, autour de 2x
  En revanche, la quantification réduit fortement le taux d’acceptation, donc il faut un Mac assez puissant
  Les trois autres modèles plus petits étaient moins convaincants, car le temps de validation du modèle de brouillon absorbait l’essentiel du gain de performance
  Je suis encore en train d’ajuster pour voir si je peux obtenir de meilleurs résultats
  On peut le tester dans Ollama 0.23.1 avec ollama run gemma4:31b-coding-mtp-bf16

• J’ai vraiment hâte d’essayer ça dès que ce sera fusionné dans llama.cpp
  Dans mon environnement, Gemma 4 26B-A4B est déjà environ 3 fois plus rapide que Qwen3.6-35B-A3B, donc l’idée d’y ajouter encore un gain de 1,5x est très séduisante
  J’ai aussi essayé des modèles de brouillon, mais les résultats étaient limités, et même un petit modèle de brouillon 3B avec le modèle dense Ministral 14B ajoutait déjà trop de surcoût

  • Avec une 5090 sous vLLM, on obtient 120 à 180 TPS avec une quantification awq 4 bits et le speculative decoding MTP
    Gemma4 26B dépasse les 200 TPS avec la même quantification
    Il faut aussi noter que Qwen a une efficacité d’inférence extrêmement faible
    Sa chaîne de pensée est en moyenne environ 3 fois plus longue que celle de Gemma

• Je me demande si c’est un peu l’équivalent de la prédiction de branchement dans un système d’exploitation
  Sauf qu’ici la probabilité est intégrée au modèle lui-même, donc sous une forme bien plus fiable

  • L’idée est proche, mais la façon d’échouer est meilleure
    Une mauvaise prédiction de branchement gaspille des cycles, alors qu’ici une mauvaise spéculation signifie généralement seulement qu’on ne gagne pas de tokens bonus
    https://arxiv.org/abs/2211.17192