Speculative Decoding : le guide complet pour accélérer l’inférence des LLM

Qu’est-ce que le speculative decoding et comment fonctionne-t-il ?

Le speculative decoding est une technique d’optimisation d’inférence qui permet d’accélérer considérablement la génération de texte des grands modèles de langage (LLM) sans en dégrader la qualité. Son principe s’inspire directement de l’exécution spéculative utilisée en architecture des processeurs depuis des décennies : plutôt que d’attendre le résultat d’une opération pour lancer la suivante, on anticipe et on exécute des opérations en parallèle.

Dans le contexte des LLM, cette approche repose sur un constat simple : un forward pass sur un modèle de 70 milliards de paramètres prend environ 200 millisecondes pour générer un seul token. Avec le décodage auto-régressif standard, générer une phrase de 12 tokens nécessite 12 exécutions séquentielles soit environ 600 ms pour seulement 3 tokens. Le goulot d’étranglement n’est pas la puissance de calcul mais la bande passante mémoire : le modèle doit recharger ses poids à chaque itération.

Le principe général : de l’exécution spéculative au decoding

L’idée centrale du speculative decoding est de faire travailler deux modèles en tandem. Un modèle brouillon (draft model), beaucoup plus petit et rapide typiquement 10 à 50 fois plus petit que le modèle principal propose une séquence de 3 à 5 tokens en un temps record : un modèle de 1 milliard de paramètres génère un token en environ 1 milliseconde. Le modèle cible (70B dans l’exemple canonique), lui, ne vérifie qu’en une seule passe parallèle l’ensemble des tokens proposés. Si la prédiction est correcte, on obtient 3 à 5 tokens validés pour le coût d’un seul forward pass du gros modèle.

Cette approche fonctionne car la plupart des tokens dans une phrase sont « faciles » à prédire (conjonctions, articles, mots fréquents). Le petit modèle excelle sur ces tokens triviaux pendant que le grand modèle concentre son attention sur les décisions difficiles. En production, cela se traduit par une accélération de 2x à 3,5x de l’inférence, atteignant 2 à 2.5x pour un modèle cible de 70B avec un spéculateur de 1B. Des pics à 4x sont mesurés sur la génération de code structuré, et les coûts GPU baissent de 40% à 60%, une pratique qui s’apparente à l’écriture d’un code propre et structuré.

Le mécanisme de vérification par rejection sampling

La clé de voûte du speculative decoding réside dans son mécanisme de validation : le rejection sampling modifié. Si le modèle cible valide les tokens proposés par le modèle brouillon, on les accepte tous. En cas de désaccord, on applique une règle probabiliste : le token rejeté est remplacé par un échantillon tiré de la distribution du modèle cible.

Cette correction garantit une distribution de sortie strictement identique à celle du décodage standard les résultats sont dits lossless, sans dégradation de précision jusqu’aux limites de précision du matériel. Les calculs de probabilités étant parallélisables entre positions, la vérification des 3 à 5 tokens spéculatifs complet en un seul forward pass. Le taux d’acceptation, qui peut dépasser 85% avec des méthodes avancées comme EAGLE-2, détermine directement le gain final observé, un paramètre clé du réglage des LLM.

Comment implémenter le speculative decoding avec vLLM

Configuration de base avec vLLM (draft model classique)

vLLM est l’un des frameworks les plus simples pour déployer le speculative decoding en production. Toute la configuration se fait au lancement du serveur, via le flag `, speculative-config` qui accepte un JSON. Cette option active le draft model sans modifier une seule ligne de votre code d’inférence.

Activer via --speculative-config JSON : passez un fichier ou une chaîne JSON décrivant la méthode et les modèles.
Définir speculative_config.method : utilisez ` »method »: « draft_model »` pour le schéma classique à deux modèles.
Spécifier modèle et tokenizer : indiquez le chemin du modèle brouillon et son tokenizer ; ils doivent correspondre à ceux du modèle cible.
Lancer l’inférence normalement : une fois le serveur démarré, vos requêtes HTTP et vos scripts Python restent inchangés.

Les alternatives d’implémentation : Ollama et TensorRT-LLM

vLLM n’est pas la seule option. D’autres outils intègrent nativement le speculative decoding, souvent avec un niveau de complexité variable. Voici les principales alternatives à connaître pour choisir selon votre stack technique.

Ollama 0.4+ via draft_mode : activez le decoding spéculatif en définissant `draft_mode` sur le modèle souhaité.
TensorRT-LLM Engine builder : permet de compiler un moteur optimisé avec un modèle de draft intégré.
Baseten intégration de production : ce fournisseur de MLOps propose un pipeline TensorRT-LLM clé en main pour déployer cette technique.
vLLM supporte EAGLE, MTP, ngram : au-delà du draft classique, vLLM gère aussi les méthodes avancées et le ngram spéculatif.

Exemple de code : modèle speculator 1B avec cible 70B

Illustrons avec un cas concret : un modèle vérificateur de 70B de paramètres (par exemple Llama-3-70B) assisté d’un spéculateur de 1B. Ce ratio de taille respecte la règle des 10 à 15 % du modèle principal. Le petit modèle génère, d’abord 3 à 5 tokens spéculativement ; le modèle 70B les vérifie ensuite en un seul forward pass parallèle. En production, cette configuration offre un ratio de vitesse de 2 à 2,5 fois par rapport au décodage auto-régressif classique.

python

Configuration vLLM par programme

from vllm import LLM, SamplingParams
from vllm.spec_decode.config import SpeculativeConfig

config = SpeculativeConfig(
method= »draft_model »,
draft_model_name= »redhat-ai-speculators/llama-3-8b-speculator »,
draft_tokenizer_name= »meta-llama/Llama-3-8B »,
num_speculative_tokens=5
)

llm = LLM(
model= »meta-llama/Llama-3-70B »,
speculative_config=config,
tensor_parallel_size=2
)
Dans cet exemple, le speculator de 1B (ou 8B) propose 5 tokens en environ 1 milliseconde. Sans optimisation, générer 3 tokens avec le modèle 70B prend 600 millisecondes (3 forward pass de 200 ms chacun). Avec le draft model, la vérification parallèle réduit ce temps à une seule passe de 200 ms, soit une accélération de 2,5 fois sur ce segment. L’overhead en VRAM reste limité au KV cache du petit modèle, bien inférieur à celui d’un second modèle 70B. Cette approche est particulièrement efficace pour des workloads interactifs à faible batch size.

Impact du speculative decoding sur la latence et les performances

Le goulot d’étranglement de l’inférence des LLM n’est pas la puissance de calcul, mais la bande passante mémoire. Un décodeur auto-régressif classique génère chaque token séquentiellement : pour produire 3 tokens, il exécute 3 forward pass distincts. Si un forward pass dure 200 millisecondes, la génération de ces 3 tokens prend 600 ms. Le speculative decoding inverse cette logique : le petit modèle brouillon génère plusieurs candidats en un temps négligeable environ 1 milliseconde par token et le grand modèle les vérifie tous en un seul forward pass parallèle.

Ce que mesurent réellement les benchmarks

Les gains observés varient selon le type de contenu généré. Pour du code structuré, le pic d’accélération peut atteindre 4x, car les motifs syntaxiques sont hautement prévisibles pour le modèle brouillon. Sur un modèle cible de 70B paramètres, le ratio de vitesse se situe généralement entre 2 et 2,5x dans les cas réels, avec un pic à 3,5x dans les configurations les plus favorables. Les démonstrations de Hannes Hapke sur vLLM montrent une amélioration de latence de 35% sur des workloads interactifs typiques.

Impact sur les coûts d’infrastructure

La réduction de latence se traduit directement en économies GPU. Le speculative decoding permet d’annoncer une réduction de 40% à 60% des coûts GPU, car le modèle cible effectue moins de forward pass pour le même nombre de tokens générés. C’est un levier particulièrement pertinent pour les workloads interactifs à faible batch size, où le modèle reste sous-utilisé en termes de calcul mais saturé en bande passante mémoire. En revanche, pour les workloads offline à haute concurrence, les gains s’estompent la parallélisation du batch comble déjà le goulot mémoire, et l’overhead du modèle brouillon devient un frein plutôt qu’un accélérateur.

Les différentes méthodes de speculative decoding (Medusa, EAGLE, MTP)

La méthode classique draft-target repose sur deux modèles distincts : un petit modèle brouillon (typiquement 0,5 à 2B paramètres) propose 3 à 5 tokens, que le grand modèle vérifie en un seul passage. Simple à mettre en œuvre, elle consomme cependant beaucoup de VRAM puisqu’il faut charger deux modèles complets.

Medusa adopte une approche radicalement différente : au lieu d’un second modèle, on ajoute plusieurs têtes de prédiction fine-tunées directement sur le modèle original. Le modèle cible reste inchangé, et les heads supplémentaires partagent ses couches profondes, ce qui réduit considérablement l’empreinte mémoire tout en accélérant la génération.

EAGLE (et sa version EAGLE-2) représente l’état de l’art : elle extrapole les features au niveau des hidden states plutôt que de prédire des tokens isolés. Cette finesse explique son taux d’acceptation supérieur à 85%, le plus élevé du marché. Son overhead VRAM de seulement +1,5 Go en fait la solution la plus économe un atout décisif pour les déploiements sur GPU contraints. Combinée à vLLM, EAGLE-2 atteint des gains de 2x à 4x en conditions réelles.

MTP (Multi-Token Prediction), popularisée par DeepSeek, entraîne le modèle à prédire plusieurs tokens simultanément dès la phase d’entraînement. Les têtes multiples partagent le même tronc, offrant un bon compromis entre performance et simplicité d’implémentation. Pour du code structuré, les benchmarks montrent des pics à 4x d’accélération, car les motifs répétitifs sont particulièrement bien prédits.

Le choix se résume souvent à un arbitrage : EAGLE-2 pour maximiser le taux d’acceptation avec un overhead minimal, Medusa pour éviter tout second modèle, ou MTP quand on contrôle l’entraînement depuis zéro. TensorRT-LLM supporte en outre DFlash, une variante qui peut atteindre des gains jusqu’à 15x sur certains workloads spécifiques.

Comment choisir le bon modèle brouillon (draft model) et comprendre ses limites

Critères de sélection d’un draft model efficace

Le choix du modèle brouillon (ou draft model) détermine directement le taux d’acceptation des tokens proposés et, par extension, le gain de latence final. Voici les critères essentiels à respecter :

• Taille 10 à 50x inférieure au modèle cible pour ne pas saturer la mémoire GPU.
• Ratio 1/8 à 1/10 recommandé, par exemple un Llama-3-8B pour un Llama-3-70B.
• Même famille et tokenizer que le modèle cible pour une compatibilité totale.
• Alignement de domaine critique pour maintenir un taux de prédiction élevé.
• Modèles Red Hat AI speculators disponibles sur Hugging Face pour tester rapidement.

Un modèle brouillon typique compte 0,5 à 2 milliards de paramètres pour un vérificateur de 70B, soit une empreinte minimale compensant largement la complexité ajoutée. La règle empirique reste la suivante : si le modèle brouillon est trop gros, le coût de son forward pass séquentiel annule le bénéfice de la vérification parallèle ; s’il est trop petit, son taux de prédiction s’effondre.

Limitations, compromis et cas d’usage adaptés

Le speculative decoding n’est pas une solution universelle. Il brille dans les scénarios où la latence interactive prime sur le débit brut. Voici ses principales limites à connaître avant de l’adopter :

• Optimal pour batch size faible et les workloads interactifs type chat ou agent.
• Inefficace en haute concurrence : au-delà d’une certaine charge, le batch large rend la vérification parallèle moins rentable.
• VRAM partagée, KV caches séparés : les deux modèles se partagent la mémoire, mais doublent l’espace de cache.
• Incompatible pipeline parallelism vLLM dans certaines versions : vérifier la configuration avant déploiement.
• Modèles mal alignés = taux effondré : un draft model hors domaine peut chuter sous 50% d’acceptation.

L’empreinte mémoire additionnelle (+1,5 Go pour EAGLE-2 par exemple) est un compromis à considérer : elle réduit l’espace disponible pour la longueur de contexte, mais reste négligeable face aux 2x à 4x de gains mesurés en conditions réelles. Si votre infrastructure est dimensionnée pour de la génération offline ou des batchs massifs, le décodage classique reste plus simple à maintenir.

Fondements mathématiques et garanties théoriques du speculative decoding

D’où vient cette confiance dans le résultat ? Tout repose sur un rejection sampling modifié, un algorithme qui garantit une distribution de sortie strictement identique à celle du modèle cible. Les tokens proposés par le modèle brouillon ne sont pas acceptés aveuglément : ils sont validés ou rejetés selon leurs probabilités respectives. Cette vérification mathématique rend la méthode théoriquement lossless, jusqu’aux limites de précision du matériel.

L’efficacité repose sur deux observations structurelles. D’abord, certains tokens sont triviaux à prédire (ponctuation, mots fréquents), d’autres non la spéculation exploite cette hétérogénéité. Ensuite, l’inférence est limitée par la bande passante mémoire, pas par le calcul : les GPU atteignent des centaines de trillions d’opérations par seconde, mais les poids doivent transiter depuis la mémoire à quelques trillions d’octets par seconde seulement. Paralléliser la vérification de plusieurs tokens en un seul forward pass contourne ce goulot d’étranglement. En pratique, la correction des probabilités s’effectue de manière indépendante pour chaque position, ce qui rend le calcul parfaitement parallélisable et explique les accélérations de 2x à 3,5x observées.

{
« @context »: « https://schema.org »,
« @type »: « Article »,
« headline »: « Speculative Decoding : le guide complet pour accélérer l’inférence des LLM »,
« description »: « Le speculative decoding accélère l’inférence des LLM sans dégrader la qualité. »,
« datePublished »: « 2026-10-05 »,
« author »: {
« @type »: « Organization »,
« name »: « alex-test.xyz »
},
« publisher »: {
« @type »: « Organization »,
« name »: « alex-test.xyz »,
« url »: « https://alex-test.xyz »
}
}

{
« @context »: « https://schema.org »,
« @type »: « FAQPage »,
« mainEntity »: [
{
« @type »: « Question »,
« name »: « Qu’est-ce que le speculative decoding et comment fonctionne-t-il ? »,
« acceptedAnswer »: {
« @type »: « Answer »,
« text »: « Le speculative decoding est une technique d’optimisation d’inférence qui permet d’accélérer considérablement la génération de texte des grands modèles de langage (LLM) sans en dégrader la qualité. Son principe s’inspire directement de l’exécution spéculative utilisée en architecture des processeurs  »
}
}
]
}