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

Un modèle de 70B génère un jeton par passe avant, et chaque passe recharge les poids depuis la VRAM, calcule l’attention sur l’ensemble du contexte et synchronise la mémoire. Entre les jetons, le GPU reste inactif pendant qu’il attend la résolution des dépendances séquentielles.

Sur un H100, un modèle de 70B produit un jeton toutes les 30-50 ms. Le GPU dispose de suffisamment de capacité 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 stagne.

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

Ce guide couvre les mécanismes, les variantes disponibles en 2026, les compromis de taux d’acceptation et la configuration pratique à travers llama.cpp, vLLM, SGLang et TensorRT-LLM.

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

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

1. Effectuer une passe avant à travers le modèle avec le contexte actuel.
2. Échantillonner le jeton suivant à partir de la distribution de sortie.
3. Ajouter le jeton au contexte.
4. Répéter.

Chaque étape nécessite une passe avant complète — 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 70B de paramètres, cela prend environ 30-50 ms par jeton sur un H100. Le GPU a de la capacité de calcul à revendre — il pourrait traiter plus de travail en parallèle — mais la dépendance séquentielle l’en empêche.

L’écart Calcul-VRAM

Les GPU modernes ont plus de FLOPs qu’il n’en faut pour la génération d’un seul jeton, de sorte que le vrai goulot d’étranglement est la bande passante mémoire — les poids doivent être diffusés de la VRAM vers les unités de calcul pour chaque passe 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 un calcul utile.

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

Le mécanisme de Brouillon-Vérification

Le décodage spéculatif fonctionne selon des cycles de brouillon-vérification répétés. Un mécanisme de brouillon rapide propose K jetons candidats — provenant d’un petit modèle de brouillon, d’une recherche n-gramme ou d’une tête de prévision attachée au modèle cible — et le modèle cible vérifie les K jetons dans une seule passe avant. La phase de brouillon est bon marché, typiquement 5-20 % du temps de la passe avant du modèle cible, tandis que la vérification compare chaque jeton de brouillon à ce que le modèle cible aurait généré, acceptant le préfixe correspondant le plus long et ré-échantillonnant à partir du premier rejet.

Vérifier K jetons coûte à peu près le même temps que de générer un jeton autorégressivement, donc lorsque le brouillon est correct, vous obtenez K jetons pour le prix d’une seule é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 dans une seule passe 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 seul cycle au lieu de trois passes avant séparées. Si le brouillon avait été correct jusqu’au jeton 5, vous obtiendriez cinq jetons pour le coût d’une vérification — un gain de vitesse de 5 fois pour ce seul cycle.

Le goulot d’étranglement de la vérification

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

C’est pourquoi le taux d’acceptation est si important. Chaque jeton rejeté après le premier est un travail de vérification gaspillé. Les meilleures méthodes de décodage spéculatif maximisent le nombre espéré de jetons acceptés par cycle, et non simplement 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 même distribution exacte que l’échantillonnage autorégressif standard depuis le 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_draft(x). La probabilité d’acceptation est :

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

Lorsque le modèle cible est d’accord (p(x) ≥ p_draft(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 rapport, et les jetons rejetés sont ré-échantillonnés à partir d’une distribution résiduelle :

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

Cette procédure garantit que la séquence de sortie suit exactement la distribution du modèle cible, ce qui est la raison pour laquelle 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 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 ont différents compromis entre complexité de configuration, taux d’acceptation et gain de vitesse.

Modèles de brouillon autonomes

L’approche la plus simple charge un modèle plus petit à côté de la cible — typiquement un modèle de 1B-3B faisant le brouillon pour une cible de 7B-70B.

Avantages :

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

Inconvénients :

• Nécessite de charger un deuxième modèle dans la VRAM (1-4 GB selon la taille)
• La qualité du modèle de brouillon détermine directement le taux d’acceptation
• Les brouillons entre familles (p. ex., Qwen faisant le brouillon pour Llama) ont généralement de mauvais résultats

Règle empirique : Utilisez des modèles de la même famille. Gemma 2 2B fait un bon brouillon pour Gemma 2 27B. Llama 3.2 1B fait un bon brouillon pour Llama 3.1 70B. Les brouillons entre familles ont tendance à avoir de faibles taux d’acceptation parce que 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 une cible donnée. Le facteur critique est l’alignement de distribution — à quel point les probabilités de sortie du modèle de brouillon correspondent à celles de la cible.

La règle d’or : si le taux d’acceptation du modèle de brouillon passe sous 50 %, le décodage spéculatif peut en fait vous ralentir. Le surcoût de l’exécution du modèle de brouillon plus de la vérification l’emporte sur le bénéfice 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 des jetons futurs. Lors de l’inférence :

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

L’avantage : les têtes EAGLE sont entraînées spécifiquement pour correspondre à la distribution du modèle cible. Elles voient directement les représentations internes de la cible, ce qui leur donne un bien meilleur alignement qu’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 des 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 le surcoût.
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 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, par rapport à 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 %.

Configuration : 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 de tiers existent pour vLLM et SGLang.

P-EAGLE : Brouillon en 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 passes avant séquentielles à travers la tête de brouillon, et le surcoût de brouillon croît linéairement avec K. P-EAGLE supprime cette limite en générant tous les K jetons de brouillon dans une seule passe avant à travers un rédacteur léger de 4 couches entraîné à prédire jusqu’à 10 jetons en parallèle.

Le résultat : P-EAGLE offre jusqu’à 1,69 fois de vitesse en plus par rapport à EAGLE-3 vanilla sur des charges de travail réelles sur NVIDIA B200. L’avantage s’élargit aux valeurs de 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.

Configuration dans vLLM : Téléchargez une tête P-EAGLE pré-entraînée de HuggingFace, réglez "parallel_drafting": true dans votre configuration vLLM, et utilisez le même drapeau --speculative-model — vLLM s’occupe du 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 n-gramme

Le décodage spéculatif n-gramme remplace un brouillon neuronal par une correspondance de motifs contre l’historique du prompt. L’algorithme cherche des séquences n-grammes répétées dans le contexte, et lorsque la séquence actuelle de jetons correspond à un motif vu précédemment, 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 la carte n-gramme (ngram-map-k, ngram-map-k4v) utilisent des tables de hachage pour des recherches plus rapides au lieu du balayage linéaire, avec la clé de hachage comme le n-gramme actuel de taille N et la valeur comme la séquence de jetons qui a suivi.

Avantages :

• Zéro surcoût 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, réorganisation, génération de modèles)
• Les taux d’acceptation peuvent atteindre 90 %+ sur les charges de travail avec une forte auto-similarité

Inconvénients :

• Inutile pour la génération novatrice — si le motif n’est pas apparu avant, le n-gramme n’a rien à proposer
• Le taux d’acceptation tombe à presque zéro sur les charges de travail créatives ou diverses
• Profondeur de brouillon limitée (typiquement 2-4 jetons par correspondance)

Le mieux pour : Réorganisation 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 : écriture créative, discussion ouverte, et tâches de raisonnement.

Ajustement des paramètres

Les paramètres n-gramme sont plus importants que vous ne le pensez. Les valeurs par défaut fonctionnent pour le code, mais les charges de travail texte ont besoin d’ajustement :

Pour les charges de travail texte, 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 spéculatif autonome

Le décodage spéculatif autonome (aussi appelé LayerSkip ou auto-spéculatif) 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 cela fonctionne

Au lieu d’exécuter le modèle complet pour chaque jeton, le décodage spéculatif autonome 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. La passe avant tronquée est plus rapide parce qu’elle traite moins de couches, et les jetons de brouillon bénéficient de voir les mêmes couches initiales que la 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 passes avant partielles
• 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 plus faibles que pour EAGLE ou les modèles de brouillon bien ajustés

Implémentation dans llama.cpp : PR #18471 a introduit le décodage spéculatif autonome en utilisant l’historique du contexte comme brouillon. Le modèle réutilise des jetons de son propre historique de génération pour proposer des prolongations, 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 (Multi-Token Prediction)

MTP est une forme spécialisée de décodage spéculatif construite directement dans certains points de contrôle de modèles. Qwen 3.6 fournit à la fois des variantes GGUF standard et 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 dans une seule passe 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 :

• Pas de modèle de brouillon à gérer — MTP est activé avec --spec-type draft-mtp --spec-draft-n-max N
• Les têtes MTP ajoutent ~1-2 GB de surcoût VRAM
• Fonctionne le mieux sur les architectures MoE (Qwen 3.6 35B-A3B) où le routage rare garde les têtes MTP bon marché

Pour des benchmarks détaillés sur MTP par rapport au décodage standard à travers Qwen 3.6 27B et 35B, voir Qwen 3.6 MTP vs Standard on 16GB GPU.

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

Le taux d’acceptation (α) est la métrique la plus importante pour les performances du décodage spéculatif. Il détermine si vous obtenez un gain de vitesse ou si vous payez un surcoût.

La formule de gain de vitesse

Jetons acceptés espérés par passe de vérification :

E[accepté] = α × 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 passe — un gain de vitesse de 3,5 fois par rapport au décodage standard (qui produit 1 jeton par passe).

Taux d’acceptation par méthode

Quand le taux d’acceptation baisse

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

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

Seuil critique : Si votre taux d’acceptation effectif (α × K) passe sous 1,0, le décodage spéculatif est plus lent que le décodage standard. Le surcoût du brouillon plus le temps de vérification excède le coût d’une étape autorégressive unique.

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

Les articles de recherche rapportent des gains de vitesse de 2 à 4 fois, mais les benchmarks de production racontent une histoire plus nuancée — les gains de vitesse 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.

Constatations de SpecDecode-Bench (2026)

Une évaluation systématique de cinq variantes de DS (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 DS fonctionne, mais les gains de vitesse diminuent avec la taille du lot. À la taille de lot 1, EAGLE atteint jusqu’à 1,96x sur Llama-3-70B. À la taille de lot 128, cela tombe à 1,21x. Le système devient limité par le calcul à haute concurrence, et le GPU a moins de capacité inoccupée à revendre pour la spéculation.

2. La vérification domine le temps d’exécution (42-95 %). La passe avant du modèle cible est le goulot d’étranglement. La réduction du gaspillage de vérification 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 polyvalent. 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 à forte chevauchement.

4. L’analyse Oracle révèle un écart. La limite 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 de gain de vitesse pratiques

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

Surveillance en production

Vous devriez suivre le taux d’acceptation en production. Un taux d’acceptation en baisse signale que votre modèle de brouillon diverge de la 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 requête (devrait être stable autour de votre baseline)
• Jetons par seconde avec ou sans décodage spéculatif (le gain de vitesse réel)
• Temps de vérification en pourcentage du temps de cycle (devrait être de 42-95 %)
• Temps de passe avant du modèle de brouillon (devrait être < 20 % du temps du modèle cible)

Si votre taux d’acceptation passe sous 40 %, désactivez le décodage spéculatif pour cette requête. Le surcoût n’en vaut pas la peine.

Configuration 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 batch, la compatibilité API et le débit avant de choisir un chemin de décodage spéculatif.

llama.cpp

Pour la configuration de serveur générale et le chargement GGUF, commencez par llama.cpp quickstart ; 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 à travers 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 (ajustement pour charge de travail texte)
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 mono-lot. 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 VRAM.
• --spec-ngram-simple-size-n — Longueur du n-gramme de recherche. 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 ignora silencieusement le décodage spéculatif.
• Utiliser des modèles de brouillon entre familles — les taux d’acceptation s’effondrent, annulant tout gain de vitesse.
• Régler --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 commencent vers 5-8.

vLLM

Le vLLM quickstart 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 à travers 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 en 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é au batch continu, donc il fonctionne sous charges de travail concurrentes. L’ordonnateur gère plusieurs emplacements de jetons dans une seule passe avant, et le gestionnaire 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 à travers 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’associe bien au décodage spéculatif parce que la mise en 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 passe de vérification moins coûteuse qu’une passe avant froide.

TensorRT-LLM

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

1. Construisez le moteur TensorRT pour les modèles cible et brouillon.
2. Configurez le dépôt de modèles avec model.yaml spécifiant la configuration du 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 la latence de 2 à 3 fois dans les déploiements de production.

Quand utiliser le décodage spéculatif

L’utilisez quand

• Grands modèles cibles (7B+) : Le surcoût du mécanisme de brouillon est amorti sur le calcul de la cible. Le décodage spéculatif brille lorsque le modèle cible est lent — plus la cible est grande, plus le gain de vitesse est précieux.
• Charges de travail à basse température : Le décodage spéculatif fonctionne le mieux à une température de 0,0-0,7, où la distribution du modèle cible est concentrée et le brouillon a une meilleure chance de correspondre.
• Applications interactives : Les charges de travail sensibles à la latence (discussion, complétion de code, appels d’outils d’agent) bénéficient le plus. Le traitement par lot où vous saturez déjà le GPU voit moins de bénéfice.
• Génération et édition de code : La forte répétition dans les motifs de code rend le décodage n-gramme et auto-spéculatif particulièrement efficace.

Passez dessus quand

• Petits modèles cibles (< 3B) : Le surcoût du modèle de brouillon approche le temps de la passe avant de la cible. Le gain de vitesse est marginal ou négatif.
• Échantillonnage à haute température : À une température > 0,7, la distribution du modèle cible est trop large pour que le brouillon corresponde de manière fiable.
• Écriture créative et génération ouverte : Les faibles taux d’acceptation sur le contenu novateur rendent le surcoût peu rentable.
• Grands lots (> 32) : Le système devient limité par le calcul, et le décodage spéculatif ajoute du surcoût sans bénéfice proportionnel. SpecDecode-Bench montre le gain de vitesse tombant de 1,96x à 1,21x lorsque la taille de lot passe de 1 à 128.

Combiner les méthodes

Les configurations avancées combinent plusieurs stratégies de décodage spéculatif. L’analyse oracle de SpecDecode-Bench a montré que combiner adaptativement n-gramme et EAGLE peut pousser le gain de vitesse à 4,9x sur les charges de travail d’édition de code.

L’idée est d’utiliser n-gramme pour les motifs qui sont apparus avant, où l’acceptation est élevée et le surcoût proche de zéro, et de recourir à EAGLE pour les jetons novateurs. En pratique, cela nécessite le soutien du moteur pour la spéculation multi-méthode — vLLM et TensorRT-LLM ont un soutien expérimental, mais les implémentations de qualité production sont encore en cours de maturation.

Pour l’instant, la combinaison la plus pratique est MTP + n-gramme dans llama.cpp. MTP gère la spéculation neuronale, tandis que n-gramme attrape les motifs répétitifs que MTP rate. Sur Qwen 3 27B, cette combinaison atteint 120 jetons/s par rapport à 67 jetons/s standard — un gain de vitesse de 1,8x.

Considérations de coût

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

Impact sur le coût GPU :

• La latence des requêtes uniques s’améliore de 20-50 %, ce qui compte pour les applications interactives.
• Le débit (jetons/s à travers de nombreuses requêtes) s’améliore moins — le GPU est déjà saturé à de grandes tailles de lot.
• L’utilisation de la VRAM augmente de l’empreinte du modèle de brouillon (1-4 GB 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 requête sans augmenter le coût par jeton. Pour le traitement par lot où vous saturez déjà le GPU, le bénéfice en coût est minimal — vous payez pour le même temps de GPU de toute façon.

Quand le décodage spéculatif économise de l’argent : Les applications interactives où vous facturez par requête et voulez réduire le temps jusqu’au premier jeton. Un gain de vitesse de 2x signifie que vos utilisateurs attendent la moitié du temps, et vous pouvez servir plus de requêtes par seconde sur le même matériel.

Quand ce n’est pas le cas : Le traitement par lot où vous maximisez 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 est en train de passer de la nouveauté de recherche au standard de production. La frontière pousse au-delà des limitations actuelles :

• Génération parallèle au niveau du modèle : le décodage spéculatif pousse plusieurs jetons par passe avant à la couche d’inférence sans toucher à la distribution de sortie. Les modèles de langage de diffusion misent structurellement différemment, générant plusieurs jetons par passe avant en tant que partie de l’architecture du modèle elle-même. Voir ce qui vient après les LLMs pour voir comment cela compare à l’approche brouillon-vérification ci-dessus, et aux modèles d’espace d’état et aux modèles de monde JEPA à l’autre bout du paysage post-transformateur.

• Décodage Spéculatif Spéculatif (SSD) : Parallélise les étapes de brouillage et de vérification sur un matériel séparé. Le modèle de brouillon s’exécute asynchronement, en pré-spéculant pour plusieurs résultats de vérification probables. Les premiers résultats montrent jusqu’à 2x de vitesse en plus 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 Rare) : Combine le décodage spéculatif avec l’attention rare dynamique. Transforme l’attention rare 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 autorégressif rare. Pertinent pour les modèles à long contexte où l’attention rare est déjà utilisée.

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

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

Cadre de décision