Imaginez un interrupteur. Pas de compromis sur la qualité. Pas de nouveau matériel. Juste 2× à 3× plus rapide. Cet interrupteur existe depuis mai 2026 dans llama.cpp, vLLM, et Ollama. Il s'appelle speculative decoding. Et il est désactivé par défaut chez quasiment tout le monde.
Le problème dont personne ne parle
Générer du texte avec un LLM, c'est masochiste par design. Le modèle produit un token à la fois. Chaque token exige un forward pass complet à travers les milliards de paramètres. Séquentiel. Obligatoirement.
Sur un RTX 3090, ça donne : 7B tourne à 95 tokens/sec, 32B à 30 tokens/sec. Pas parce que le GPU est lent — il est idiot. Il passe son temps à lire les poids en mémoire plutôt qu'à calculer. La génération LLM est memory-bandwidth-bound, pas compute-bound. Vous avez payé une carte à 1 000 € pour qu'elle lise des fichiers.
Un post Hacker News de juillet 2026, intitulé "The Free Speed Toggle Your Local LLM Is Probably Not Using", a relancé le débat. 400+ upvotes. Des commentaires frustrés. Une communauté qui réalise qu'elle tourne au ralenti depuis des mois sans le savoir.
Comment ça marche — sans le charabia
Speculative decoding repose sur une idée simple : utiliser un petit modèle rapide pour faire des prédictions en avance, et un grand modèle lent pour valider.
Concrètement :
- Le draft model (0,5B–3B paramètres) génère 4 tokens en rafale. Vite.
- Le target model (32B–70B) reçoit le contexte + les 4 tokens proposés. Il les vérifie en un seul forward pass, pas quatre.
- Les tokens validés sont gardés. Le premier désaccord déclenche un reject — le target model impose son token, et on recommence.
La propriété qui tue : l'output est bit-for-bit identique à ce que le grand modèle aurait produit seul. Ce n'est pas une approximation. Ce n'est pas un compromis qualité/vitesse. C'est mathématiquement équivalent.
Le speedup vient de là : valider 4 tokens en 1 pass coûte moins que générer 4 tokens en 4 passes. Si le draft model est bon — même famille architecturale, même vocabulary que le target — le taux d'acceptation monte à 75–80%. Résultat : entre 1,8× et 3× plus rapide selon le hardware.
Hardware | Target | Draft | Acceptation | Speedup |
RTX 3090 | Llama 3.1-32B | Llama 3.1-0.5B | ~75% | 1.8–2.2× |
RTX 4090 | Qwen3.6-35B | Qwen3.6-7B | ~70% | 1.5–1.8× |
H100 | Llama 3.1-70B | Llama 3.1-3B | ~80% | 2.5–3.0× |
Depuis mai 2026, c'est natif. Et personne n'a activé l'interrupteur.
La technique existe depuis 2023 dans la littérature académique. DeepMind, OpenAI — ils la connaissaient. En production interne, probablement depuis 2024. Pour le commun des devs locaux : silence radio.
Jusqu'à mai 2026. La PR #22673 a été mergée dans llama.cpp. Ollama v0.30 suit dans la foulée. vLLM était déjà là, TensorRT-LLM aussi. En quelques semaines, les quatre runtimes principaux de l'écosystème LLM local supportent speculative decoding nativement.
La commande llama.cpp :
./main -m target_model.gguf \
--draft-model draft_model.gguf \
--draft-min-accept-tokens 4 \
-p "votre prompt" \
-n 512Deux lignes de diff dans votre configuration. Deux fois plus vite.
Alors pourquoi personne ne l'utilise ?
L'anatomie d'un échec d'adoption
La documentation sur speculative decoding commence invariablement par expliquer le principe théorique. Excellent. Elle oublie systématiquement de dire quel draft model choisir.
C'est là que ça casse.
Prenez un Qwen3.5-0.5B comme draft pour un Llama 3.1-32B. Architectures différentes, vocabulaires différents. Taux d'acceptation : 30%. Non seulement le speedup disparaît — vous pouvez vous retrouver plus lent qu'avant. Le draft génère des tokens que le target rejette en masse. Overhead de compute, zéro gain.
La règle est simple mais rarement expliquée : même famille, même vocabulary, même tokenizer. Qwen draft pour Qwen target. Llama draft pour Llama target. Pas de mélange.
Deuxième obstacle : la VRAM. Sur un RTX 3060 avec 12 Go, vous chargez déjà Mistral-7B en Q4 (6 Go). Ajouter un draft model de 0,5 Go laisse 5,5 Go pour la fenêtre de contexte — qui rétrécit. Pour les petits GPU, speculative decoding est contre-productif. Ça exige au minimum 16 Go pour en tirer quelque chose.
Troisième problème : c'est désactivé par défaut. Pas coché, pas documenté en page d'accueil, pas suggéré dans les tutoriels débutants. La technique est là. Elle attend. Dans le silence.
Ce que personne ne précise dans les benchmarks enthousiastes
Les chiffres de 3× circulent. Ils sont réels. Mais ils concernent des scénarios spécifiques.
Pour les déploiements multi-utilisateurs — vLLM servant 100 requêtes simultanées — le gain tombe à 10–30%. La latence en batch est dominée par la phase de prefill (calcul des prompts), où speculative decoding n'intervient pas. C'est une technique d'optimisation single-user decode latency, pas de throughput serveur.
Autre subtilité : le speedup est front-loaded. Les 50 premiers tokens d'une génération ont un taux d'acceptation de 85%. À 200+ tokens, on descend à 40%. Le modèle diverge progressivement. Pour les générations courtes — chatbot, code completion — speculative decoding est une bénédiction. Pour les longs monologues ou les résumés massifs, moins.
Et ça ne s'améliore pas si votre draft model est mal choisi. Pas de magie. Un draft random donne un taux d'acceptation aléatoire. Résultat : calcul en double pour rien.
Pourquoi c'est quand même une révolution (pour les bons cas d'usage)
Votre agent de code local tourne à 30 tok/sec. Il devient lent après 5 minutes de contexte. Vous avez l'impression de regarder l'IA réfléchir en direct, et pas dans le bon sens.
Avec speculative decoding et un bon draft model : 60–70 tok/sec. La sensation de fluidité change. La latence perçue passe sous le seuil où le cerveau commence à s'impatienter.
Pour un copilot en local (VS Code extension sur Llama 32B), la différence entre 200ms et 100ms est celle entre "ça rame" et "c'est utilisable". Subjectif ? Oui. Mais c'est exactement ce qui détermine l'adoption.
Pour les équipes fintech qui tournent en inférence locale pour des raisons de conformité (les données ne quittent pas le réseau), c'est une économie directe. 2× plus rapide = 2× moins de GPUs pour le même throughput. Sur 100 machines à 100 €/mois équivalent cloud, c'est 60 000 €/an de gagnés.
Les trois techniques qui ont changé le LLM local en 2026
Speculative decoding n'est pas seule. Trois innovations ont collectivement rendu les LLMs locaux compétitifs avec les APIs cloud — ce qui semblait improbable fin 2024.
Multi-Token Prediction : le modèle est entraîné pour prédire plusieurs tokens simultanément. Le speedup est inclus dans l'architecture elle-même — Qwen3.6 et Gemma4 le font nativement. Pas de draft model à gérer, taux d'acceptation 100% par construction.
Sparse MoE : Mixture of Experts active seulement 3–5B paramètres sur 35B à chaque inférence. Le modèle lit moins de poids, donc va plus vite. Deepseek-V3, Qwen3.6, tous MoE. L'overhead VRAM est réel (il faut charger tous les experts en mémoire), mais le bandwidth savings compense sur GPU moderne.
Speculative decoding : le seul des trois qui fonctionne sans ré-entraînement, sur des modèles déjà existants, activé par deux lignes de config.
Ce trio a transformé le RTX 3090 en machine de production viable pour des modèles 32B. En 2024, c'était de la science-fiction. Aujourd'hui, c'est dans le Modelfile d'Ollama.
Comment l'activer maintenant
llama.cpp (natif depuis mai 2026, PR #22673) :
./main -m qwen3.5-32b-Q4_K_M.gguf \
--draft-model qwen3.5-0.5b-Q4_K_M.gguf \
--draft-min-accept-tokens 4 \
-p "votre prompt ici"vLLM :
from vllm import LLM
llm = LLM(model="Qwen/Qwen3.5-32B", draft_model="Qwen/Qwen3.5-0.5B")
output = llm.generate("votre prompt", speculative_num_tokens=4)Ollama (v0.30+, via Modelfile) :
FROM qwen3.5:32b
PARAMETER draft_model "qwen3.5:0.5b"Règle d'or : choisissez un draft model de la même famille que votre target. Même tokenizer, même vocabulary. Visez 10–20% de la taille du target model comme sweet spot. 3B draft pour 32B target, pas 0,5B (trop aléatoire) ni 7B (trop lourd).
Verdict
Speculative decoding, c'est l'une des rares optimisations sans trade-off de l'histoire du LLM local. Lossless. Natif. Gratuit. Sur le bon matériel (16 Go+ VRAM) avec le bon draft model (même famille que le target), le gain est réel et immédiat.
L'ironie : c'est désactivé par défaut. La documentation est mauvaise. La majorité des tutoriels n'en parlent pas. Et les gens continuent à se plaindre que les LLMs locaux sont lents.
Bref. Activez l'interrupteur.
Sources
- NVIDIA Technical Blog — Introduction to Speculative Decoding : https://developer.nvidia.com/blog/an-introduction-to-speculative-decoding-for-reducing-latency-in-ai-inference/
- Red Hat Developer — How Speculative Decoding Delivers Faster LLM Inference (juin 2026) : https://developers.redhat.com/articles/2026/06/12/how-speculative-decoding-delivers-faster-llm-inference
- llama.cpp PR #22673 (mai 2026, merge speculative decoding natif) : https://github.com/ggerganov/llama.cpp
- BentoML LLM Handbook — Speculative Decoding : https://bentoml.com/llm/inference-optimization/speculative-decoding
- RunAIHome — Why Local LLMs Got Good Mid-2026 (juin 2026) : https://runaihome.com/blog/why-local-llms-got-good-mid-2026-speculative-decoding-moe/
- SesameDisk — Speculative Decoding for Faster LLM Inference : https://sesamedisk.com/speculative-decoding-llm-inference-speedup/
- Blog post original "The Free Speed Toggle Your Local LLM Is Probably Not Using" (juillet 2026) : https://vettedconsumer.com/speculative-decoding-explained-the-free-speed-toggle-your-local-llm-is-probably-not-using/
- Baseten — How to Optimize LLM Inference Speed : https://www.baseten.co/blog/how-to-optimize-llm-inference-speed-and-reduce-costs-in-production/
Idée d'illustration : Vue en coupe d'un pipeline d'inférence LLM. À gauche : séquence linéaire monotone de tokens générés un par un, chaque token une brique grise qui tombe lentement. À droite : le pipeline speculative decoding — un petit modèle (visuel compact, vert) propulse 4 tokens en avant comme des balles, et le grand modèle (massive, bleu) les valide d'un seul regard. Style néobrutaliste typographique, fond noir, palette verte/bleue/blanche. Pas de fioritures. Pas d'IA futuriste générique. Juste la mécanique.