Beaucoup d’équipes qui se battent avec la latence d’inférence de leur LLM se résignent à choisir entre un petit modèle rapide et un grand modèle précis. Le speculative decoding, popularisé par les travaux de DeepMind et Google Research puis industrialisé par vLLM, llama.cpp et les principaux moteurs d’inférence, permet aujourd’hui d’avoir les deux : la précision du grand modèle, avec un throughput proche de celui du petit. En production, les gains observés tournent entre ×2 et ×3 sur la latence inter-tokens, sans aucune dégradation de la qualité des réponses — c’est mathématiquement garanti par la construction même de l’algorithme. Comment choisir une base vectorielle pour un RAG en production : Pinecone, Weaviate, Qdrant et pgvector comparés
À retenir en 30 secondes : le speculative decoding utilise un petit modèle « brouillon » (draft) pour prédire plusieurs tokens d’avance, que le grand modèle valide en parallèle en une seule passe. Les tokens validés sont acceptés, les autres rejetés et recalculés par le grand modèle. Résultat : le grand modèle produit la même sortie qu’en inférence classique, mais en appelant son forward pass moins souvent. Les gains dépendent du taux d’acceptation du draft (typiquement 60 à 80 %) et de la taille des deux modèles.
Le principe algorithmique en termes concrets
En inférence autorégressive classique, un LLM génère les tokens un par un : chaque nouveau token nécessite une passe complète du modèle, dominée par la latence mémoire du KV cache à l’échelle d’un modèle de plusieurs dizaines de milliards de paramètres. Le speculative decoding introduit un modèle brouillon beaucoup plus petit (typiquement 10 à 100 fois plus léger), qui propose rapidement K tokens d’avance. Le grand modèle, le modèle cible, évalue en parallèle ces K propositions en une seule forward pass avec attention masquée, et accepte ou rejette chacune via un critère de rejection sampling qui garantit mathématiquement que la distribution de sortie est strictement identique à celle du grand modèle seul. Caching sémantique pour LLMs : réduire latence et coûts d'inférence sans sacrifier la pertinence
Ce point mérite d’être souligné : le speculative decoding n’est pas une approximation. Les sorties produites sont indistinguables de celles d’une inférence autorégressive classique. La seule chose qui change, c’est le nombre de forward pass nécessaires pour atteindre N tokens — divisé par un facteur égal au nombre moyen de tokens acceptés par pass.
Choisir le bon modèle brouillon : la question centrale
Le gain réel dépend entièrement de la qualité du draft. Un draft trop faible produit un taux d’acceptation bas, et le temps gagné sur le grand modèle est consommé par les appels inutiles au petit modèle. Un draft trop proche du modèle cible annule le gain de latence du petit modèle. En pratique, trois stratégies dominent. La distillation d’un draft dédié à partir du modèle cible donne les meilleurs taux d’acceptation (jusqu’à 80 %) mais nécessite un entraînement spécifique — à rapprocher directement de notre guide sur la distillation de modèles LLM. L’utilisation d’un modèle plus petit de la même famille (par exemple Llama-3-1B comme draft pour Llama-3-70B) est le compromis le plus courant. Enfin, le self-speculative decoding utilise les premières couches du modèle cible comme draft, sans modèle externe — technique émergente avec un bon rapport simplicité/gain.
Intégration dans les moteurs d’inférence modernes
En 2026, le speculative decoding est natif dans la plupart des moteurs d’inférence self-hosted sérieux : vLLM, TensorRT-LLM, llama.cpp, SGLang. L’activation se fait via une ou deux options de configuration — généralement un chemin vers le modèle draft et une taille de spéculation (nombre de tokens avancés par pass). Côté API managée, Anthropic et OpenAI utilisent le speculative decoding en interne de manière transparente pour l’utilisateur — c’est l’une des raisons pour lesquelles la latence inter-tokens des API cloud ne cesse de baisser modèle après modèle à hardware constant. LLMOps : guide complet pour déployer et opérer un LLM en production
Pour les équipes qui déploient vLLM en production, la bascule vers le speculative decoding s’intègre naturellement dans le travail d’optimisation de la stack d’inférence que nous avons détaillé dans notre guide sur l’optimisation des coûts d’inférence LLM en production.
Mesurer l’impact réel : les métriques à suivre
Trois métriques permettent de piloter correctement le speculative decoding en production. Le taux d’acceptation (acceptance rate) mesure le pourcentage de tokens proposés par le draft qui sont effectivement validés par le modèle cible : viser 65 % minimum pour un gain significatif. La vitesse d’émission (tokens par seconde) mesure le gain net côté utilisateur : attendre un facteur ×2 à ×3 sur les workloads adaptés. Enfin, la charge GPU du draft doit rester marginale par rapport au grand modèle, faute de quoi le gain est annulé par la contention. Instrumenter ces métriques dans la stack d’observabilité, à l’image de ce que nous détaillons dans notre guide sur l’observabilité des systèmes LLM avec OpenTelemetry, est essentiel pour détecter les régressions.
Les cas où le speculative decoding est contre-productif
Trois configurations annulent le bénéfice de la technique. Premièrement, les workloads à batch size très élevé : le gros modèle sature déjà le GPU en inférence batch classique, et le speculative decoding ajoute une complexité sans gain. Deuxièmement, les générations très courtes (quelques dizaines de tokens) : l’overhead d’orchestration du draft dépasse le gain. Troisièmement, les prompts très atypiques ou hors distribution par rapport à l’entraînement du draft : le taux d’acceptation chute, et le coût du draft n’est pas remboursé. Un travail de profiling par type de workload reste donc indispensable avant toute généralisation.
Pour approfondir le sujet côté recherche, la publication fondatrice de Leviathan et al. sur arXiv reste la référence incontournable sur les garanties mathématiques du rejection sampling appliqué à la génération.
Mon point de vue d’expert
Je ne vois aucune raison, en 2026, qu’une équipe française qui opère sa propre inférence LLM n’ait pas activé le speculative decoding. L’investissement d’intégration est marginal (quelques jours), le gain de latence est substantiel (×2 à ×3 sur les workloads conversationnels classiques), et la qualité des réponses reste strictement identique. Les hésitations que je rencontre encore proviennent d’un manque de familiarité avec la garantie mathématique du rejection sampling, et de la crainte infondée que l’approche « introduise des hallucinations ». Elle n’en introduit aucune : la distribution de sortie est préservée formellement. Mon conseil pratique : commencez par le self-speculative decoding (zéro modèle externe à maintenir), mesurez le gain réel sur vos workloads, puis investissez dans un draft dédié distillé si les volumes le justifient.
FAQ : speculative decoding en production
- Le speculative decoding change-t-il les sorties du modèle ?
- Non. L’algorithme utilise un critère de rejection sampling qui garantit mathématiquement que la distribution de sortie est strictement identique à celle du modèle cible seul. Les mêmes graines aléatoires produisent les mêmes séquences. Il n’y a aucune approximation, aucune dégradation de qualité.
- Quelle taille idéale pour le draft par rapport au modèle cible ?
- Le compromis typique situe le draft entre 1/10 et 1/100 de la taille du modèle cible. Pour un modèle cible de 70B, un draft de 1B à 7B donne généralement les meilleurs taux d’acceptation (65 à 80 %). Trop petit, le draft prédit mal et son travail est jeté ; trop gros, il consomme la ressource GPU censée être gagnée.
- Combien de tokens avancer à chaque spéculation ?
- Le nombre optimal se situe généralement entre 4 et 8 tokens. Au-delà, le taux d’acceptation chute rapidement (chaque token supplémentaire est conditionné à l’acceptation du précédent), et le coût du draft inutile explose. En vLLM, la valeur par défaut est 5, c’est un bon point de départ.
- Peut-on combiner speculative decoding et prompt caching ?
- Oui, les deux optimisations sont orthogonales et se cumulent. Le prompt caching réduit le coût de la phase de prefill (traitement du prompt d’entrée) ; le speculative decoding réduit la latence de la phase de decoding (génération de la réponse). Les deux combinés transforment radicalement l’économie d’une application LLM à contexte long et réponses verbeuses.