Google a livré aujourd'hui le support natif des drafters Multi-Token Prediction dans LiteRT-LM, le framework d'inférence production open-source à github.com/google-ai-edge/LiteRT-LM. La sortie Gemma 4 12B d'hier a flaggé les drafters MTP comme la pièce de réduction de latence baked-in dans le modèle ; le chiffre concret est arrivé ce matin. Le speedup de décodage est 1,6x sur Gemma 4 E2B et 2,2x sur E4B, sans dégradation de qualité claimée. End-to-end, le runtime LiteRT-LM est rapporté à 1,8x à 3,7x plus rapide que llama.cpp, MLX, Cactus et ONNX sur prefill plus décodage pour les variantes Gemma 4. Les APIs s'étendent au-delà des surfaces Kotlin et C++ existantes pour ajouter Swift et JavaScript, ce qui met le runtime sur les paths iOS, web et Node.js sans ports séparés.
Le mécanisme c'est du speculative decoding via un drafter MTP léger co-entraîné avec le modèle Gemma 4 primaire. Le speculative decoding standard existe dans llama.cpp, vLLM et l'écosystème MLX depuis deux ans, mais le bottleneck a toujours été le data interplay entre drafter et verifier : si le drafter roule sur un hardware IP différent du modèle primaire, le round trip mange le speedup. Le claim engineering spécifique de LiteRT-LM c'est l'enforcement de memory locality, le drafter MTP léger ET le modèle primaire s'exécutent sur le même hardware IP (e.g., le GPU), ce qui retire le round trip cross-IP qui limite les implémentations spéculatives naïves. C'est la part qui vaut la pause pour les builders qui considèrent si le 2,2x est reproductible sur leur stack : ça dépend de si ton framework d'inférence respecte la contrainte de locality ou non. Chiffres des benchmarks propres de Google ; la reproduction indépendante sur des charges qui matchent les tiennes est le standard next step avant de parier ton infra sur le chiffre.
Deux fils d'écosystème à tracker. Premièrement, MTP-as-acceleration est maintenant une primitive builder concrète plutôt qu'une curiosité de recherche. Le modèle ship avec le drafter baked-in (variantes Gemma 4 mid-sized), et le framework d'inférence respecte le contrat de locality, et le speedup est publié avec des comparaisons aux frameworks que les builders utilisent vraiment. C'est le stack complet dont t'as besoin pour qu'un feature de speculative decoding devienne defaults-on plutôt qu'expert-only. D'autres familles de modèles avec des drafters MTP (le travail MTP de DeepSeek, la recherche spéculative de Meta et autres) ont maintenant un pattern d'implémentation de référence à suivre. Deuxièmement, la cohorte de comparaison matter stratégiquement. LiteRT-LM se positionne contre llama.cpp (le default open-source d'inférence locale), MLX (le default Apple Silicon), Cactus (le framework d'inférence mobile) et ONNX (le standard de sérialisation cross-platform). Google nomme les incumbents et met des chiffres concrets à côté, ce qui signale que LiteRT-LM est positionné comme un contender pour le slot default-local-inference plutôt qu'un prototype de recherche.
Lundi matin, si tu roules Gemma 4 localement sur llama.cpp, MLX ou ONNX aujourd'hui : pull LiteRT-LM et benchmark sur ta charge réelle avant de décider de switcher. Le 2,2x est l'upper bound de Google ; sur du hardware consumer le chiffre réel est plus souvent dans la plage 1,7x à 2,2x, ce qui est quand même meaningful mais vaut la peine d'être mesuré sur ta longueur de contexte et ta batch size. Si tu ship Gemma 4 dans des apps iOS ou web, les nouvelles APIs Swift et JavaScript changent ce qui est faisable sur ces surfaces, traite comme une évaluation fraîche plutôt que de t'appuyer sur des conclusions de framework antérieures. Si tu construis de l'infra d'inférence pour n'importe quelle famille de modèle MTP-equipped, le pattern d'enforcement de locality est la leçon d'engineering qui vaut la peine d'être portée vers d'autres runtimes ; drafter et verifier co-localisés sur le même hardware IP est la part qui rend le speculative decoding rapide en pratique plutôt qu'uniquement sur papier. Et comme toujours avec les benchmarks vendor contre des frameworks open, les chiffres de comparaison 1,8x à 3,7x sont vendor-published ; la reproduction indépendante par les communautés llama.cpp et MLX est la validation qui matter.