Décodage spéculatif : inférence des LLM 20 à 50 % plus rapide

Un modèle de 70 milliards de paramètres génère un jeton (token) par passage avant, et chaque passage recharge les poids depuis la mémoire VRAM, calcule l’attention sur tout le contexte et synchronise la mémoire. Entre les jetons, le GPU reste inactif en attendant que les dépendances séquentielles soient résolues.

Sur un H100, un modèle de 70B produit un jeton tous les 30 à 50 ms. Le GPU dispose de suffisamment de puissance de calcul pour traiter plusieurs jetons en parallèle, mais la dépendance séquentielle l’en empêche : chaque jeton dépend du précédent, et le pipeline se bloque.

Le décodage spéculatif brise ce goulot d’étranglement en permettant de générer plusieurs jetons dans le temps qu’il faut normalement pour en générer un seul, sans modifier la distribution de sortie. Les jetons obtenus sont statistiquement identiques à ceux que vous obtiendriez avec un décodage autorégressif standard ; la seule différence réside dans la vitesse à laquelle vous les obtenez.

Ce guide couvre les mécanismes, les variantes disponibles en 2026, les compromis liés au taux d’acceptation et la mise en place pratique avec llama.cpp, vLLM, SGLang et TensorRT-LLM.

Comment fonctionne le décodage autorégressif (et pourquoi il est lent)

Avant de comprendre le décodage spéculatif, il est nécessaire de comprendre la contrainte autorégressive qu’il contourne. La génération autorégressive standard traite les jetons séquentiellement :

1. Exécuter un passage avant à travers le modèle avec le contexte actuel.
2. Échantillonner le prochain jeton à partir de la distribution de sortie.
3. Ajouter le jeton au contexte.
4. Répéter.

Chaque étape nécessite un passage avant complet — chargement des poids depuis la VRAM, calcul de l’attention sur l’ensemble du contexte et production d’un seul jeton. Pour un modèle avec 70 milliards de paramètres, cela prend environ 30 à 50 ms par jeton sur un H100. Le GPU a de la capacité de calcul en surnombre — il pourrait traiter plus de travail en parallèle — mais la dépendance séquentielle l’en empêche.

L’écart entre calcul et bande passante mémoire

Les GPU modernes ont plus d’opérations en virgule flottante (FLOPs) qu’ils n’en ont besoin pour la génération d’un seul jeton, donc le véritable goulot d’étranglement est la bande passante mémoire — les poids doivent être transférés depuis la VRAM vers les unités de calcul pour chaque passage avant. Lors de la génération d’un jeton à la fois, le GPU passe la plupart de son temps à attendre les transferts mémoire plutôt qu’à effectuer des calculs utiles.

Le décodage spéculatif remédie à cela en donnant plus de travail au GPU par transfert mémoire. Au lieu d’un jeton par passage avant, il génère K jetons par passage avant, amortissant le coût mémoire sur plusieurs sorties.

Le mécanisme Brouillon-Vérification (Draft-Verify)

Le décodage spéculatif fonctionne en cycles répétés de brouillon et de vérification. Un mécanisme de brouillon rapide propose K jetons candidats — provenant d’un petit modèle de brouillon, d’une recherche de n-grammes ou d’une tête de prédiction attachée au modèle cible — et le modèle cible vérifie les K jetons en un seul passage avant. La phase de brouillon est peu coûteuse, typiquement 5 à 20 % du temps de passage avant du modèle cible, tandis que la vérification compare chaque jeton de brouillon contre ce que le modèle cible aurait généré, acceptant le préfixe le plus long correspondant et rééchantillonnant à partir de la première rejection.

La vérification de K jetons coûte à peu près le même prix que la génération d’un jeton de manière autorégressive, donc lorsque le brouillon est correct, vous obtenez K jetons pour le prix d’une étape de vérification.

Un exemple concret

Supposons que le modèle de brouillon propose 5 jetons : ["I", " like", " cooking", " and", " traveling"]. Le modèle cible les vérifie en un seul passage avant :

Le modèle cible accepte les jetons 1 et 2, puis génère " playing" pour le jeton 3, produisant trois jetons en un cycle au lieu de trois passages avant séparés. Si le brouillon avait été correct jusqu’au jeton 5, vous obtiendriez cinq jetons pour le coût d’une vérification — une accélération de 5x sur ce cycle seul.

Le goulot d’étranglement de la vérification

En pratique, la vérification domine le temps d’exécution — entre 42 et 95 % du cycle, selon la méthode et la taille du modèle. Le passage avant du modèle cible est le goulot d’étranglement, et les jetons rejetés représentent du calcul gaspillé.

C’est pourquoi le taux d’acceptation est si important. Chaque jeton rejeté après le premier est du travail de vérification gaspillé. Les meilleures méthodes de décodage spéculatif maximisent le nombre attendu de jetons acceptés par cycle, et non pas seulement le taux d’acceptation brut.

La garantie mathématique

L’une des propriétés les plus importantes du décodage spéculatif est qu’il produit des jetons provenant de la exactement même distribution que l’échantillonnage autorégressif standard du modèle cible. L’étape de vérification utilise l’échantillonnage par rejet — lorsque le brouillon propose le jeton x, le modèle cible calcule sa propre probabilité p(x) et le brouillon calcule p_brouillon(x). La probabilité d’acceptation est :

min(1, p(x) / p_brouillon(x))

Lorsque le modèle cible est d’accord (p(x) ≥ p_brouillon(x)), le jeton est toujours accepté. Lorsque le modèle cible n’est pas d’accord, le jeton est accepté avec une probabilité proportionnelle au ratio, et les jetons rejetés sont rééchantillonnés à partir d’une distribution résiduelle :

r(x) = max(0, p(x) - p_brouillon(x)) / Σ max(0, p(y) - p_brouillon(y))

Cette procédure garantit que la séquence de sortie suit exactement la distribution du modèle cible, ce qui explique pourquoi le décodage spéculatif est sans perte. Le modèle de brouillon influence la vitesse, pas la qualité — les jetons que vous obtenez sont statistiquement indiscernables de ceux du décodage standard, avec la même perplexité et la même distribution. La seule différence est la latence.

Stratégies de modèles de brouillon

Le mécanisme de brouillon est la variable qui compte le plus. Différentes approches présentent des compromis différents entre complexité de mise en place, taux d’acceptation et accélération.

Modèles de brouillon autonomes

L’approche la plus simple consiste à charger un modèle plus petit en parallèle du modèle cible — typiquement un modèle de 1 à 3 milliards de paramètres servant de brouillon pour un modèle cible de 7 à 70 milliards.

Avantages :

• Conceptuellement simple
• Fonctionne avec n’importe quel modèle cible
• Le modèle de brouillon peut être ajusté pour correspondre à la distribution du modèle cible

Inconvénients :

• Nécessite de charger un second modèle en VRAM (1 à 4 Go selon la taille)
• La qualité du modèle de brouillon détermine directement le taux d’acceptation
• Les brouillons inter-familles (par exemple, Qwen servant de brouillon pour Llama) fonctionnent généralement mal

Règle générale : Utilisez des modèles de la même famille. Gemma 2 2B sert bien de brouillon pour Gemma 2 27B. Llama 3.2 1B sert bien de brouillon pour Llama 3.1 70B. Les brouillons inter-familles ont tendance à avoir des taux d’acceptation faibles car les distributions de jetons divergent.

Trouver des modèles de brouillon compatibles

Tous les petits modèles ne fonctionnent pas comme modèles de brouillon pour un modèle cible donné. Le facteur critique est l’alignement de distribution — à quel point les probabilités de sortie du modèle de brouillon correspondent à celles du modèle cible.

La règle d’or : si le taux d’acceptation du modèle de brouillon tombe en dessous de 50 %, le décodage spéculatif peut en réalité ralentir le processus. La surcharge de l’exécution du modèle de brouillon plus la vérification l’emporte sur l’avantage lorsque la plupart des propositions sont rejetées.

EAGLE et EAGLE-3 : Têtes de prédiction

EAGLE (Efficient Architecture Guided Language Model Estimation) élimine le besoin d’un modèle de brouillon séparé. Au lieu de cela, il attache des têtes de prédiction autorégressives légères aux couches internes du modèle cible.

Comment fonctionne EAGLE

EAGLE entraîne des têtes de prédiction qui prennent les états cachés des couches intermédiaires du modèle cible et prédisent les jetons futurs. Pendant l’inférence :

1. Le modèle cible exécute un passage avant à travers ses couches.
2. À chaque couche, la tête EAGLE lit l’état caché et propose des jetons pour les positions futures.
3. Plusieurs têtes fonctionnent en parallèle, chacune prédisant un pas de temps futur différent.
4. Le modèle cible vérifie toutes les propositions en un seul passage.

L’avantage : les têtes EAGLE sont entraînées spécifiquement pour correspondre à la distribution du modèle cible. Elles voient les représentations internes du modèle directement, ce qui leur donne un alignement bien meilleur que celui d’un modèle de brouillon autonome.

Améliorations d’EAGLE-3

EAGLE-3 (2025) affine l’approche avec trois changements clés :

1. Sélection de couches : Au lieu d’attacher des têtes à chaque couche, EAGLE-3 utilise l’optimisation bayésienne pour sélectionner la couche de sortie optimale, réduisant la surcharge.
2. Prédiction multi-jetons : Chaque tête prédit plusieurs jetons simultanément, augmentant la profondeur du brouillon sans coût de calcul proportionnel.
3. Efficacité d’entraînement : EAGLE-3 s’entraîne sur les propres données de génération du modèle cible, améliorant les taux d’acceptation sur les charges de travail dans la distribution.

Taux d’acceptation : EAGLE-3 atteint typiquement des taux d’acceptation de 60 à 80 % sur les charges de travail dans la distribution, comparé à 40-60 % pour les modèles de brouillon autonomes. Sur les charges de travail de génération de code avec une forte répétition, l’acceptation peut dépasser 85 %.

Mise en place : EAGLE-3 nécessite des têtes pré-entraînées pour votre modèle cible. NVIDIA fournit des têtes EAGLE-3 pour plusieurs modèles populaires via TensorRT-LLM et la collection de modules de décodage spéculatif sur HuggingFace. Des implémentations tierces existent pour vLLM et SGLang.

P-EAGLE : Brouillon Parallèle (Mars 2026)

La principale limitation d’EAGLE-3 est le brouillon autorégressif — chaque jeton de brouillon dépend du précédent, donc générer K jetons de brouillon nécessite K passages avant séquentiels à travers la tête de brouillon, et la surcharge du brouillon croît linéairement avec K. P-EAGLE lève cette limite en générant tous les K jetons de brouillon en un seul passage avant à travers un drafteur léger de 4 couches entraîné à prédire jusqu’à 10 jetons en parallèle.

Le résultat : P-EAGLE offre une accélération allant jusqu’à 1,69x par rapport à EAGLE-3 vanilla sur des charges de travail réelles sur NVIDIA B200. L’avantage s’élargit à des valeurs K plus élevées — là où le brouillon séquentiel d’EAGLE-3 devient un goulot d’étranglement, le brouillon parallèle de P-EAGLE n’entraîne aucun coût supplémentaire.

Mise en place dans vLLM : Téléchargez une tête P-EAGLE pré-entraînée depuis HuggingFace, définissez "parallel_drafting": true dans votre configuration vLLM, et utilisez le même drapeau --speculative-model — vLLM gère le reste. P-EAGLE est l’état de l’art actuel pour le décodage spéculatif basé sur EAGLE, et si vous déployez EAGLE en 2026, P-EAGLE est la variante à utiliser.

Décodage spéculatif par n-grammes

Le décodage spéculatif par n-grammes remplace un brouillon neuronal par une correspondance de motifs contre l’historique du prompt. L’algorithme recherche des séquences d’n-grammes répétées dans le contexte, et lorsque la séquence de jetons actuelle correspond à un motif précédemment vu, il propose les jetons qui ont suivi ce motif plus tôt — par exemple, si le modèle a déjà généré def calculate_total(items): et rencontre def calculate_total( à nouveau, il sait que les prochains jetons seront probablement items): basé sur l’occurrence précédente.

Les variantes de carte n-grammes (ngram-map-k, ngram-map-k4v) utilisent des tables de hachage pour des recherches plus rapides au lieu d’un balayage linéaire, la clé de hachage étant l’n-gramme actuel de taille N et la valeur étant la séquence de jetons qui a suivi.

Avantages :

• Zéro surcharge VRAM — aucun modèle supplémentaire à charger (~16 Mo pour la table de hachage)
• Extrêmement rapide pour les charges de travail répétitives (édition de code, refactoring, génération de modèles)
• Les taux d’acceptation peuvent atteindre 90 %+ sur les charges de travail à forte auto-similarité

Inconvénients :

• Inutile pour la génération nouvelle — si le motif n’est pas apparu auparavant, le n-gramme n’a rien à proposer
• Le taux d’acceptation chute à près de zéro sur les charges de travail créatives ou diversifiées
• Profondeur de brouillon limitée (typiquement 2-4 jetons par correspondance)

Idéal pour : Refactoring de code, remplissage de modèles, documentation répétitive et toute charge de travail où le modèle revisite des motifs similaires. Le pire pour : l’écriture créative, le chat ouvert et les tâches de raisonnement.

Réglage des paramètres

Les paramètres des n-grammes comptent plus qu’on ne le pense. Les valeurs par défaut fonctionnent pour le code, mais les charges de travail textuelles nécessitent un ajustement :

Pour les charges de travail textuelles, réduisez size-n à 8-10 et augmentez min-hits à 2. Cela échange la fréquence de correspondance contre des taux d’acceptation plus élevés par correspondance.

Décodage auto-spéculatif

Le décodage auto-spéculatif (également appelé LayerSkip ou auto-spéculation) utilise le calcul partiel du modèle lui-même comme brouillon, de sorte qu’aucun modèle séparé n’est nécessaire.

Comment ça marche

Au lieu d’exécuter le modèle complet pour chaque jeton, le décodage auto-spéculatif exécute une version tronquée — en sautant certaines couches de transformateur — pour générer des jetons de brouillon à moindre coût, et le modèle complet vérifie ensuite les propositions.

Par exemple, un modèle de 32 couches pourrait fonctionner avec seulement 16 couches pour le brouillon, puis vérifier avec les 32 couches. Le passage avant tronqué est plus rapide car il traite moins de couches, et les jetons de brouillon bénéficient de voir les mêmes couches initiales que le modèle cible.

Avantages :

• Aucun poids de modèle supplémentaire à charger
• Naturellement aligné avec la distribution cible (même architecture, couches partielles)
• Fonctionne bien pour les modèles avec une redondance significative dans les couches plus profondes

Inconvénients :

• Nécessite de modifier le moteur d’inférence pour prendre en charge les passages avant partiels
• Complications de cache KV — le brouillon utilise un cache KV partiel qui doit être réconcilié avec le cache du modèle complet
• Les taux d’acceptation sont typiquement inférieurs à ceux d’EAGLE ou des modèles de brouillon bien ajustés

Implémentation llama.cpp : La PR #18471 a introduit le décodage auto-spéculatif en utilisant l’historique du contexte comme brouillon. Le modèle réutilise les jetons de son propre historique de génération pour proposer des continuations, particulièrement efficace pour les charges de travail de codage où les motifs se répètent dans la même fenêtre de contexte.

MTP (Prédiction Multi-Jetons)

Le MTP est une forme spécialisée de décodage spéculatif intégrée directement dans certains points de contrôle de modèles. Qwen 3.6 propose des variantes GGUF standard et activées pour le MTP.

En quoi cela diffère : Les têtes MTP sont intégrées dans l’architecture du modèle pendant l’entraînement. Le modèle transporte des têtes de prédiction supplémentaires qui proposent plusieurs jetons futurs en un seul passage avant. Il n’y a pas de modèle de brouillon séparé — les têtes MTP font partie du modèle cible lui-même.

Compromis :

• Aucun modèle de brouillon à gérer — le MTP est activé avec --spec-type draft-mtp --spec-draft-n-max N
• Les têtes MTP ajoutent ~1-2 Go de surcharge VRAM
• Fonctionne le mieux sur les architectures MoE (Qwen 3.6 35B-A3B) où le routage sparse garde les têtes MTP peu coûteuses

Pour des benchmarks détaillés sur le MTP vs le décodage standard sur Qwen 3.6 27B et 35B, voir Qwen 3.6 MTP vs Standard sur GPU 16GB.

Taux d’acceptation : ce qu’ils signifient en pratique

Le taux d’acceptation (α) est l’unique métrique la plus importante pour les performances du décodage spéculatif. Il détermine si vous obtenez une accélération ou si vous payez une surcharge.

La formule d’accélération

Jetons acceptés attendus par passage de vérification :

E[acceptés] = α × K

Où K est le nombre de jetons de brouillon proposés par cycle. Si α = 0,7 et K = 5, vous acceptez 3,5 jetons par passage — une accélération de 3,5x par rapport au décodage standard (qui produit 1 jeton par passage).

Taux d’acceptation par méthode

Lorsque le taux d’acceptation chute

Le taux d’acceptation n’est pas constant au cours d’une génération. Il varie selon :

• Position du jeton : Les jetons précoces ont tendance à avoir une acceptation plus élevée (plus de contexte, moins d’incertitude). Les jetons tardifs diminuent à mesure que le modèle explore des continuations plus diversifiées.
• Type de charge de travail : L’édition de code avec des motifs répétitifs voit α > 80 %. L’écriture créative ouverte voit α < 40 %.
• Température : Une température plus élevée augmente la divergence entre le brouillon et le modèle cible, abaissant l’acceptation. Le décodage spéculatif fonctionne mieux à basse température (0,0-0,7).

Seuil critique : Si votre taux d’acceptation effectif (α × K) tombe en dessous de 1,0, le décodage spéculatif est plus lent que le décodage standard. La surcharge du brouillon plus le temps de vérification dépassent le coût d’une seule étape autorégressive.

Décodage spéculatif en production : ce qui se passe réellement

Les articles de recherche rapportent des accélérations de 2 à 4x, mais les benchmarks en production racontent une histoire plus nuancée — les accélérations diminuent avec la taille du lot, la vérification domine le temps de cycle, et aucune méthode unique ne gagne sur chaque charge de travail.

Résultats de SpecDecode-Bench (2026)

Une évaluation systématique de cinq variantes de décodage spéculatif (n-gramme, EAGLE, EAGLE-3, Modèle-de-brouillon, MTP) sur vLLM à travers quatre modèles et six charges de travail a révélé :

1. Le décodage spéculatif fonctionne, mais les accélérations diminuent avec la taille du lot. À une taille de lot de 1, EAGLE atteint jusqu’à 1,96x sur Llama-3-70B. Avec une taille de lot de 128, cela tombe à 1,21x. Le système devient limité par le calcul à haute concurrence, et le GPU a moins de capacité de calcul inoccupée à consacrer à la spéculation.

2. La vérification domine le temps d’exécution (42-95 %). Le passage avant du modèle cible est le goulot d’étranglement. Réduire la vérification gaspillée sur les jetons rejetés est l’avenue la plus prometteuse pour l’amélioration.

3. Aucune méthode unique ne gagne partout. EAGLE-3 est le meilleur choix général. Les méthodes de modèle de brouillon excellent lorsque le modèle cible est grand (70B+). Le n-gramme est optimal pour l’édition de code et les tâches à fort chevauchement.

4. L’analyse oracle révèle un écart. La borne supérieure théorique pour les stratégies combinées n-gramme + EAGLE atteint ~4,9x sur les charges de travail d’édition de code, mais les implémentations actuelles atteignent 2-3x. Il y a de la place pour l’optimisation.

Attentes d’accélération pratiques

L’effet de la taille du lot est critique. À petits lots, le GPU a du calcul inoccupé à consacrer à la spéculation. À grands lots, le système est déjà saturé, et le décodage spéculatif ajoute une surcharge sans bénéfice proportionnel.

Surveillance en production

Vous devez suivre le taux d’acceptation en production. Un taux d’acceptation en baisse signale que votre modèle de brouillon diverge du modèle cible — soit parce que la charge de travail a changé, soit parce que le modèle de brouillon a besoin d’un réentraînement.

Métriques clés à surveiller :

• Taux d’acceptation par demande (doit rester stable autour de votre référence)
• Jetons par seconde avec et sans décodage spéculatif (l’accélération réelle)
• Temps de vérification en pourcentage du temps de cycle (doit être de 42-95 %)
• Temps de passage avant du modèle de brouillon (doit être < 20 % du temps du modèle cible)

Si votre taux d’acceptation tombe en dessous de 40 %, désactivez le décodage spéculatif pour cette demande. La surcharge n’en vaut pas la peine.

Mise en place pratique

Le choix du moteur compte autant que la stratégie de brouillon — voir Ollama vs vLLM vs LM Studio et autres runtimes locaux pour voir comment chaque runtime gère le batching, la compatibilité API et le débit avant de choisir une voie de décodage spéculatif.

llama.cpp

Pour la configuration générale du serveur et le chargement GGUF, commencez par le démarrage rapide llama.cpp ; les drapeaux ci-dessous ajoutent le décodage spéculatif par-dessus.

llama.cpp prend en charge plusieurs méthodes de décodage spéculatif via le drapeau --spec-type :

# Modèle de brouillon (autonome)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Obligatoire : --parallel 1 pour le décodage spéculatif

# n-gramme
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gramme (réglage pour charges de travail textuelles)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Auto-spéculatif (charges de travail de codage)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Drapeaux critiques :

• --parallel 1 — Le décodage spéculatif dans llama.cpp nécessite le mode lot unique. C’est une limitation actuelle.
• --spec-draft-n-max — Nombre de jetons de brouillon par cycle. Commencez avec 3-5 ; des valeurs plus élevées augmentent la pression sur la VRAM.
• --spec-ngram-simple-size-n — Longueur de recherche du n-gramme. La valeur par défaut 12 fonctionne bien pour le code ; réduisez à 8 pour le texte.

Pièges courants :

• Oublier --parallel 1 — le serveur ignorera silencieusement le décodage spéculatif.
• Utiliser des modèles de brouillon inter-familles — les taux d’acceptation s’effondrent, annulant toute accélération.
• Définir --spec-draft-n-max trop haut — chaque jeton de brouillon supplémentaire coûte de la VRAM pour le tampon de brouillon. Les rendements décroissants apparaissent autour de 5-8.

vLLM

Le démarrage rapide vLLM couvre le déploiement de base ; les drapeaux ci-dessous activent le décodage spéculatif sur un serveur vLLM existant.

vLLM prend en charge le décodage spéculatif via les drapeaux --speculative-model et --speculative-num-steps :

# Modèle de brouillon
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (brouillon parallèle)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gramme
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

Le décodage spéculatif de vLLM est intégré avec le batching continu, donc il fonctionne sous des charges de travail concurrentes. Le planificateur gère plusieurs emplacements de jetons dans un seul passage avant, et le gestionnaire de mémoire gère le cache KV pour les modèles de brouillon et cible.

SGLang

SGLang prend en charge le décodage spéculatif via son drapeau --speculative-algorithm :

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

L’architecture RadixAttention de SGLang s’accommode bien du décodage spéculatif car le cache de préfixe réduit le coût de vérification — le modèle cible réutilise l’attention mise en cache pour les préfixes partagés, rendant chaque passage de vérification moins cher qu’un passage avant à froid.

TensorRT-LLM

TensorRT-LLM fournit un décodage spéculatif de qualité production avec Triton Inference Server. La mise en place est plus complexe mais offre les meilleures performances sur le matériel NVIDIA :

1. Construisez le moteur TensorRT pour les modèles cible et de brouillon.
2. Configurez le référentiel de modèles avec model.yaml spécifiant la configuration de décodage spéculatif.
3. Lancez Triton avec l’API LLM / backend PyTorch.

TensorRT-LLM prend en charge les variantes de modèle de brouillon et EAGLE-3. Pour les charges de travail de génération de code, TensorRT-LLM avec le décodage spéculatif n-gramme a démontré une réduction de latence de 2 à 3x dans les déploiements de production.

Quand utiliser le décodage spéculatif

L’utiliser quand

• Modèles cibles grands (7B+) : La surcharge du mécanisme de brouillon est amortie sur le calcul du modèle cible. Le décodage spéculatif brille lorsque le modèle cible est lent — plus le modèle cible est grand, plus l’accélération est précieuse.
• Charges de travail à basse température : Le décodage spéculatif fonctionne mieux à une température de 0,0-0,7, où la distribution du modèle cible est concentrée et le brouillon a plus de chances de correspondre.
• Applications interactives : Les charges de travail sensibles à la latence (chat, complétion de code, appels d’outils d’agents) en bénéficient le plus. Le traitement par lots où vous saturiez déjà le GPU voit moins d’avantages.
• Génération et édition de code : La forte répétition dans les motifs de code rend le n-gramme et le décodage auto-spéculatif particulièrement efficaces.

Le sauter quand

• Modèles cibles petits (< 3B) : La surcharge du modèle de brouillon approche du temps de passage avant du modèle cible. L’accélération est marginale ou négative.
• Échantillonnage à haute température : À une température > 0,7, la distribution du modèle cible est trop large pour que le brouillon puisse correspondre de manière fiable.
• Écriture créative et génération ouverte : Les faibles taux d’acceptation sur le contenu nouveau rendent la surcharge non rentable.
• Grands lots (> 32) : Le système devient limité par le calcul, et le décodage spéculatif ajoute une surcharge sans bénéfice proportionnel. SpecDecode-Bench montre une accélération passant de 1,96x à 1,21x lorsque la taille du lot passe de 1 à 128.

Combinaison de méthodes

Les configurations avancées combinent plusieurs stratégies de décodage spéculatif. L’analyse oracle de SpecDecode-Bench a montré que la combinaison adaptative de n-gramme et EAGLE peut pousser l’accélération à 4,9x sur les charges de travail d’édition de code.

L’idée est d’utiliser le n-gramme pour les motifs qui sont apparus auparavant, où l’acceptation est élevée et la surcharge est proche de zéro, et de revenir à EAGLE pour les jetons nouveaux. En pratique, cela nécessite un support moteur pour la spéculation multi-méthodes — vLLM et TensorRT-LLM ont un support expérimental, mais les implémentations de qualité production sont encore en maturation.

Pour l’instant, la combinaison la plus pratique est MTP + n-gramme dans llama.cpp. Le MTP gère la spéculation neuronale, tandis que le n-gramme attrape les motifs répétitifs que le MTP rate. Sur Qwen 3 27B, cette combinaison atteint 120 jetons/sec comparé à 67 jetons/sec en standard — une accélération de 1,8x.

Considérations de coût

Le décodage spéculatif échange du calcul contre de la latence. Le calcul total par jeton est à peu près le même — vous faites simplement plus de travail en parallèle plutôt que séquentiellement.

Impact sur le coût GPU :

• La latence des demandes uniques s’améliore de 20 à 50 %, ce qui compte pour les applications interactives.
• Le débit (jetons/sec sur plusieurs demandes) s’améliore moins — le GPU est déjà saturé à de grands lots.
• L’utilisation de la VRAM augmente de l’empreinte du modèle de brouillon (1-4 Go pour les brouillons autonomes, minime pour n-gramme/EAGLE).

Inférence cloud : À 2-4 $/h par H100, le décodage spéculatif réduit la latence par demande sans augmenter le coût par jeton. Pour le traitement par lots où vous saturiez déjà le GPU, le bénéfice coût est minime — vous payez pour le même temps GPU de toute façon.

Quand le décodage spéculatif fait économiser de l’argent : Applications interactives où vous facturez par demande et souhaitez réduire le temps jusqu’au premier jeton. Une accélération de 2x signifie que vos utilisateurs attendent deux fois moins longtemps, et vous pouvez servir plus de demandes par seconde sur le même matériel.

Quand ce n’est pas le cas : Traitement par lots où vous maximisiez déjà l’utilisation du GPU. Le calcul supplémentaire du décodage spéculatif n’augmente pas le débit — il change simplement le profil de latence.

Ce qui vient ensuite

Le décodage spéculatif passe d’une nouveauté de recherche à un standard de production. La frontière pousse au-delà des limitations actuelles :

• Décodage Spéculatif Spéculatif (SSD) : Parallélise les étapes de brouillon et de vérification sur du matériel séparé. Le modèle de brouillon s’exécute de manière asynchrone, pré-spéculant pour plusieurs résultats de vérification probables. Les premiers résultats montrent une accélération allant jusqu’à 2x par rapport au décodage spéculatif optimisé, et 5x par rapport au décodage autorégressif. Pas encore prêt pour la production, mais la direction est claire.

• SpecSA (Vérification Spéculative Sparse) : Combine le décodage spéculatif avec l’attention sparse dynamique. Transforme l’attention sparse en une charge de travail orientée vérification, atteignant jusqu’à 3,49x de débit de bout en bout par rapport au décodage sparse autorégressif. Pertinent pour les modèles de contexte long où l’attention sparse est déjà utilisée.

• Spéculation adaptative : Commutation automatique entre les méthodes n-gramme, EAGLE et modèle de brouillon en fonction des caractéristiques de la charge de travail. L’analyse oracle montre un potentiel inexploité significatif — les implémentations actuelles atteignent 2-3x, mais la borne théorique est de 4,9x.

• Décodage spéculatif multimodal : Extension du brouillon-vérification aux modèles vision-langage et à la génération vidéo. Les premières enquêtes montrent que les mêmes principes s’appliquent, mais les stratégies de vérification doivent s’adapter aux modalités non textuelles.

Cadre de décision