Accueil › Glossaire › Speculative Decoding

Speculative Decoding

Le speculative decoding est une technique d’optimisation d’inférence qui accélère les LLM de 2 à 3× en utilisant un petit modèle « brouillon » pour proposer plusieurs tokens candidats, ensuite vérifiés en parallèle par le grand modèle cible via rejection sampling. La qualité de sortie est mathématiquement identique à la génération autoréessive standard.

Le problème : la bande passante mémoire, pas le calcul

Chaque token généré par un LLM autorégressif nécessite un passage complet du modèle. Pour un modèle de 70 milliards de paramètres, cela signifie charger 70 milliards de poids depuis la mémoire GPU à chaque token. L’analyse roofline montre que l’inférence LLM se situe à ~1 FLOP par octet, deux ordres de grandeur en dessous du point de crête compute-bound. Les unités de calcul du GPU sont en attente des données, pas surchargées.

L’observation clé d’Andrej Karpathy (2023) résume tout : faire passer un LLM sur 1 token prend presque autant de temps que le faire passer sur K tokens en batch. Le GPU a largement la capacité de vérifier 8 tokens en parallèle pour le même coût qu’en générer 1 séquentiellement. Le speculative decoding exploite directement cette asymétrie.

Comment fonctionne le speculative decoding

Le processus se déroule en boucle, avec deux modèles travaillant ensemble :

Étape 1 : Draft (spéculation). Le modèle brouillon (petit, rapide) génère K tokens candidats de manière autoréessive. Comme il est beaucoup plus petit que le modèle cible, cette étape est très rapide. Typiquement, K = 3 à 8 tokens sont proposés.

Étape 2 : Verify (vérification). Le modèle cible (grand, précis) reçoit la séquence originale + les K tokens candidats et les traite en un seul passage parallèle. Grâce au mécanisme d’attention des Transformers, le modèle peut calculer les probabilités de tous les tokens simultanément.

Étape 3 : Accept/Reject (rejection sampling). Pour chaque token candidat, le modèle cible compare sa propre distribution de probabilité avec celle du modèle brouillon. Si la probabilité du token sous le modèle cible est supérieure ou égale à celle sous le modèle brouillon (p_target ≥ p_draft), le token est automatiquement accepté. Sinon, il est accepté avec une probabilité de p_target/p_draft. Dès qu’un token est rejeté, tous les tokens suivants sont également rejetés, et le modèle cible génère le token correct à la position du premier rejet.

Étape 4 : Répétition. Le cycle recommence avec les tokens acceptés ajoutés à la séquence.

Les métriques clés

Taux d’acceptation (α). La probabilité qu’un token brouillon soit accepté par le modèle cible. C’est la métrique la plus importante. Un α élevé (0,7-0,9) signifie que le brouillon est très aligné avec la cible. Un α faible (0,3-0,5) signifie beaucoup de rejets, peu de gain. L’α dépend de la qualité du modèle brouillon, de la difficulté de la tâche, et de la stratégie d’échantillonnage (température, top-p).

Longueur d’acceptation (τ). Le nombre moyen de tokens acceptés par cycle de draft-verify. Pour K tokens proposés et un taux α, la longueur d’acceptation théorique est τ = (1 – α^(K+1)) / (1 – α). Avec α = 0,7 et K = 5 : τ ≈ 3,0 tokens par cycle.

Nombre de tokens spéculés (γ). Le nombre de tokens proposés par le modèle brouillon à chaque cycle. Plus γ est grand, plus le potentiel de speedup est élevé, mais plus le risque de rejet en cascade est grand. Le γ optimal dépend du taux α : avec un α élevé, un γ élevé est rentable ; avec un α faible, un γ modeste est préférable. Des techniques comme Pacer ajustent γ dynamiquement à chaque étape.

Les variantes du speculative decoding

Draft model (modèle brouillon séparé)

L’approche classique utilise un modèle brouillon séparé de la même famille que le modèle cible. Exemples : LLaMA 3.2 3B comme brouillon pour LLaMA 3.3 70B. Le brouillon doit partager le même tokenizer et vocabulaire. Plus le brouillon est aligné avec la cible (même distribution de probabilité), plus α est élevé.

Le choix du brouillon est crucial. Un brouillon trop petit sera très rapide mais avec un α faible. Un brouillon trop grand sera précis mais coûteux, réduisant le gain net. La règle de pouce : le brouillon doit être 5 à 10× plus petit que la cible.

EAGLE-3 (2025)

EAGLE-3 élimine le besoin d’un modèle brouillon séparé. Il ajoute une « tête de draft » légère (1-2 couches Transformer) directement au modèle cible, qui utilise les features des couches internes (pas seulement la dernière couche) via une fusion multi-couches.

L’innovation clé d’EAGLE-3 est le « training-time test » : pendant l’entraînement, la tête de draft s’entraîne non seulement sur des tokens réels mais aussi sur ses propres prédictions (potentiellement erronées). Cela la rend robuste à ses propres erreurs pendant l’inférence, contrairement à EAGLE-1 dont le taux d’acceptation chutait fortement aux positions éloignées.

EAGLE-3 n’ajoute que 1-2 % de paramètres supplémentaires au modèle. NVIDIA le recommande comme technique de référence sur GPU H100/H200/Blackwell. Les benchmarks montrent un speedup de 2-3× sur LLaMA 3.1 avec H100.

P-EAGLE (AWS/vLLM, 2026)

P-EAGLE (Parallel-Drafting EAGLE) est la dernière évolution, publiée par AWS et intégrée dans vLLM v0.16.0. Au lieu de générer les K tokens brouillon de manière autoréessive (K passes séquentielles dans la tête de draft), P-EAGLE les génère tous en un seul passage parallèle. Cela élimine le goulot séquentiel du drafting lui-même.

Les résultats sont significatifs : 55-69 % de throughput supplémentaire à faible concurrence et 5-25 % à haute concurrence par rapport à EAGLE-3 vanilla. Des têtes P-EAGLE pré-entraînées sont disponibles sur HuggingFace pour GPT-OSS 120B, GPT-OSS 20B et Qwen3-Coder 30B.

Autres variantes

Vérification en arbre (tree-structured verification)

Les variantes avancées (Medusa, EAGLE, SAGUARO) ne proposent pas une seule séquence linéaire de tokens mais un arbre de continuations. À chaque position, plusieurs alternatives sont proposées (top-K), formant un arbre de profondeur K avec un facteur de branchement variable.

L’attention en arbre (tree attention) permet de vérifier toutes les branches simultanément dans un seul passage du modèle cible, grâce à un masque d’attention spécialisé qui encode les dépendances de l’arbre. Le chemin le plus long entièrement accepté est retenu. DeFT (Decoding with Flash Tree-attention) optimise ce mécanisme pour les GPU NVIDIA.

Déploiement en production

Support dans les frameworks

vLLM. Support natif depuis la bibliothèque « Speculators » (août 2025). Supporte les draft models, EAGLE, EAGLE-3, P-EAGLE, N-Gram et Medusa. Configuration simple via les paramètres de serving.

SGLang. Support du speculative decoding avec optimisations multi-GPU. Utilisé par Together AI pour servir des modèles MoE comme DeepSeek V3.

TensorRT-LLM (NVIDIA). Support de toutes les variantes majeures avec des kernels GPU optimisés. NVIDIA recommande explicitement EAGLE-3 dans sa documentation.

Hugging Face Transformers. « Assisted Generation » implémente le speculative decoding via une API simple. Support des draft models et du prompt lookup.

Conseils de déploiement

Un point important pour les industries réglementées : le speculative decoding est « mathematically lossless ». Les tokens produits suivent exactement la distribution du modèle cible. Les résultats de benchmarks et d’audits sont identiques avec ou sans speculative decoding activé. Cela simplifie la conformité réglementaire.

Quand le speculative decoding est-il efficace ?

Verdict

Le speculative decoding est l’une des optimisations les plus impactantes de l’écosystème LLM en 2026. Son atout unique : accélérer l’inférence de 2-3× avec une garantie mathématique de qualité identique. Aucune autre technique d’accélération ne peut revendiquer cette propriété. C’est pourquoi il est passé du statut de publication académique (2022) à celui de standard de production (2026) en seulement trois ans, intégré dans tous les frameworks de serving majeurs et déployé par Google pour AI Overviews.

EAGLE-3 et P-EAGLE représentent l’état de l’art actuel pour les déploiements single-model (sans brouillon séparé). Pour ceux qui préfèrent la simplicité d’un modèle brouillon existant, le speculative decoding classique avec un petit modèle de la même famille reste le choix le plus éprouvé. Dans les deux cas, si vous servez un LLM en production et que vous n’utilisez pas le speculative decoding, vous laissez de la performance sur la table.