Décodage spéculatif : Obtenir une accélération de 2 à 3x pour l'inférence LLM
Mis à jour le 11 décembre 2025
Mise à jour de décembre 2025 : Le décodage spéculatif passe du stade de la recherche à celui de standard de production. NVIDIA démontre des améliorations de débit de 3,6x sur les GPU H200. vLLM et TensorRT-LLM incluent un support natif. Les modèles brouillons proposent 5 à 8 tokens vérifiés en parallèle, exploitant la capacité GPU sous-utilisée par la génération token par token. Qualité de sortie inchangée ; latence réduite de 2 à 3x.
Les grands modèles de langage génèrent du texte un token à la fois, et chaque token nécessite une passe avant complète à travers des milliards de paramètres. Ce goulot d'étranglement séquentiel crée une latence qui frustre les utilisateurs en attente de réponses, même lorsque les GPU sont partiellement inactifs pendant le calcul. Le décodage spéculatif brise ce goulot d'étranglement en utilisant de petits modèles brouillons rapides pour proposer plusieurs tokens que les modèles cibles plus grands vérifient en parallèle, atteignant une accélération de 2 à 3x sans modifier la qualité de sortie.¹
La technique est passée de curiosité de recherche à standard de production en 2025. vLLM et TensorRT-LLM incluent tous deux un support natif du décodage spéculatif, NVIDIA démontrant des améliorations de débit de 3,6x sur les GPU H200.² Comprendre quand le décodage spéculatif aide, comment sélectionner les modèles brouillons et quels frameworks offrent les meilleures implémentations permet aux organisations de réduire considérablement les coûts d'inférence et la latence.
Comment fonctionne le décodage spéculatif
La génération autorégressive traditionnelle produit des tokens séquentiellement :
- Le modèle reçoit le prompt, génère les logits pour le prochain token
- Échantillonnage du token à partir de la distribution
- Ajout du token au contexte, répétition de la passe avant
- Continuation jusqu'à complétion
Chaque étape nécessite le calcul complet du modèle, mais les GPU ont une capacité bien supérieure à ce que la génération d'un seul token utilise. Le décodage spéculatif exploite cette capacité inutilisée :
Phase brouillon : Un petit modèle rapide génère K tokens spéculatifs rapidement. Le modèle brouillon peut produire 5 à 8 continuations candidates dans le temps que le modèle cible met pour un seul token.
Phase de vérification : Le modèle cible traite tous les K tokens en une seule passe avant parallèle, calculant les probabilités pour chaque position simultanément. Le parallélisme GPU permet la vérification de K tokens avec un coût similaire à la génération d'un seul.
Acceptation/rejet : Comparaison des distributions brouillon et cible à chaque position. Les tokens sont acceptés lorsque les distributions s'alignent ; rejetés et rééchantillonnés lorsqu'elles divergent. L'algorithme garantit que la sortie correspond exactement à ce que le modèle cible produirait indépendamment.³
L'accélération provient de l'acceptation de plusieurs tokens par passe avant du modèle cible. Si le taux d'acceptation du modèle brouillon est en moyenne de 60 % et propose 8 tokens, chaque passe de vérification produit environ 5 tokens contre 1 sans spéculation.
Benchmarks de performance
Les déploiements en production démontrent des accélérations substantielles à travers les familles de modèles :
Modèles Llama sur vLLM :⁴ - Llama 3.1-70B avec brouillon 1B : accélération de 2,31x - Llama 3.1-8B sur un seul A100 : réduction de latence de 1,8x - Llama 3.1-70B à faible taux de requêtes : réduction de latence de 1,6x
TensorRT-LLM sur H200 :⁵ - Llama 3.1-405B avec divers modèles brouillons : débit >3x - Combiné avec la quantification FP8 : amélioration totale de 3,6x
SGLang avec SpecForge :⁶ - Llama 4 Maverick : accélération de 2,18x sur MT-Bench - Llama 4 Scout : accélération de 2,0x
Méthode EAGLE (meilleure performance) :⁷ - Précision brouillon d'environ 0,8 (80 % d'acceptation) - Accélérations typiques de 2,5 à 2,8x - État de l'art sur le classement Spec-Bench
Les accélérations varient significativement selon les caractéristiques de la charge de travail. Les cas d'utilisation synchrones, sensibles à la latence, voient les gains les plus importants. Le traitement par lots à haut débit bénéficie moins car le calcul GPU devient le goulot d'étranglement plutôt que la génération séquentielle.
Implémentations des frameworks
Décodage spéculatif vLLM
vLLM supporte plusieurs méthodes de décodage spéculatif incluant le modèle brouillon, la correspondance ngram et EAGLE :
# Activer la spéculation avec modèle brouillon
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-model meta-llama/Llama-3.2-1B-Instruct \
--num-speculative-tokens 5 \
--speculative-draft-tensor-parallel-size 1
Intégration EAGLE (recommandée) :
# EAGLE atteint des taux d'acceptation plus élevés
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-model yuhuili/EAGLE-LLaMA3.1-Instruct-70B \
--speculative-method eagle \
--num-speculative-tokens 8
L'intégration Eagle 3 de vLLM offre jusqu'à 2,5x d'accélération dans divers scénarios.⁸ Le framework gère automatiquement la vérification des tokens et l'échantillonnage par rejet, maintenant l'équivalence de sortie avec la génération non spéculative.
Décodage spéculatif TensorRT-LLM
TensorRT-LLM offre une optimisation plus poussée pour le matériel NVIDIA :
# Construire le moteur avec décodage spéculatif
trtllm-build \
--speculative_decoding_mode draft_tokens_external \
--max_draft_len 8 \
--checkpoint_dir $TARGET_CHECKPOINT \
--output_dir $ENGINE_DIR
Pour la configuration du modèle brouillon :
# Modèle brouillon avec moteur séparé
trtllm-build \
--checkpoint_dir $DRAFT_CHECKPOINT \
--output_dir $DRAFT_ENGINE \
--max_batch_size 256
Les kernels personnalisés de TensorRT-LLM optimisent à la fois les phases de génération brouillon et de vérification, extrayant les performances maximales des Tensor Cores et de la bande passante mémoire.
Intégration Triton Inference Server
NVIDIA Triton Inference Server supporte le décodage spéculatif via le backend vLLM :⁹
model_repository/
└── speculative_llm/
├── config.pbtxt
└── 1/
└── model.py
L'intégration Triton permet un déploiement à l'échelle de production avec regroupement des requêtes, collecte de métriques et mise à l'échelle native Kubernetes tout en maintenant les avantages du décodage spéculatif.
Sélection du modèle brouillon
La qualité du modèle brouillon détermine l'efficacité du décodage spéculatif. Les mauvais modèles brouillons gaspillent du calcul sur des propositions que le modèle cible rejette.
Critères de sélection
Alignement d'architecture : Les modèles brouillons de la même famille que les cibles atteignent une acceptation plus élevée. Llama 3.2-1B en brouillon pour Llama 3.1-70B surpasse les petits modèles génériques car les données d'entraînement et la tokenisation sont alignées.¹⁰
Ratio de taille : Les modèles brouillons varient généralement de 1/10 à 1/50 de la taille cible. Les brouillons plus petits génèrent plus vite mais peuvent avoir une acceptation plus faible. Testez plusieurs tailles pour trouver le ratio optimal pour votre charge de travail.
Seuil de taux d'acceptation : Visez un taux d'acceptation de 60 % ou plus. En dessous de 50 %, la surcharge de vérification peut annuler les avantages de la spéculation. Utilisez le profilage pour mesurer l'acceptation réelle pour vos prompts spécifiques.
Affinage des modèles brouillons
Les modèles brouillons prêts à l'emploi sous-performent souvent sur les tâches spécifiques au domaine. L'affinage améliore considérablement l'acceptation :¹¹
# Affiner le modèle brouillon sur la distribution cible
from transformers import Trainer, TrainingArguments
# Générer des données d'entraînement en échantillonnant à partir du modèle cible
# Affiner le brouillon pour correspondre à la distribution de sortie de la cible
training_args = TrainingArguments(
output_dir="./draft_finetuned",
per_device_train_batch_size=8,
num_train_epochs=3,
learning_rate=2e-5,
)
trainer = Trainer(
model=draft_model,
args=training_args,
train_dataset=target_samples,
)
trainer.train()
Les organisations rapportent des améliorations du taux d'acceptation de 20 à 40 % grâce à l'affinage spécifique au domaine du brouillon. L'investissement est rentable pour les charges de travail d'inférence à haut volume.
SpecForge pour SGLang
SpecForge fournit un écosystème dédié pour l'entraînement des modèles brouillons :¹²
- Intégration native SGLang
- Recettes d'entraînement optimisées pour les variantes Llama 4
- Spéculateurs pré-entraînés pour les modèles courants
Le projet Speculators de Red Hat standardise le décodage spéculatif avec un format Hugging Face unifié et une intégration vLLM, simplifiant la découverte et le déploiement des modèles brouillons.¹³
Techniques avancées
Décodage auto-spéculatif (SWIFT)
SWIFT élimine les modèles brouillons séparés en sautant de manière adaptative les couches intermédiaires du LLM cible :¹⁴
- Aucun modèle auxiliaire requis
- Aucun entraînement supplémentaire nécessaire
- Accélération de 1,3x à 1,6x tout en préservant la distribution de sortie
La technique fonctionne en prédisant quelles couches peuvent être sautées en fonction de la confiance du token. Les continuations simples sautent plus de couches ; le raisonnement complexe utilise toute la profondeur du modèle.
# Configuration conceptuelle SWIFT
config = SwiftConfig(
skip_threshold=0.8, # Sauter les couches quand confiance > 0,8
min_layers=16, # Toujours utiliser au moins 16 couches
adaptive=True # Ajuster dynamiquement par token
)
SWIFT convient aux scénarios où maintenir un modèle brouillon séparé ajoute une complexité indésirable.
Spéculation ngram
Pour les sorties structurées ou les motifs prévisibles, la correspondance ngram fournit une spéculation sans réseaux de neurones :
# Spéculation ngram vLLM
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-model "[ngram]" \
--ngram-prompt-lookup-max 4 \
--num-speculative-tokens 4
La spéculation ngram identifie les motifs répétés dans le prompt ou l'historique de génération, proposant des tokens basés sur les séquences observées. L'approche fonctionne bien pour la génération de code, les données structurées et le contenu répétitif.
Têtes Medusa
Medusa attache des têtes de prédiction supplémentaires au modèle cible, générant plusieurs tokens candidats en parallèle :
# Medusa nécessite une modification du modèle
model = load_medusa_model("path/to/medusa_llama_70b")
# Les têtes supplémentaires prédisent les tokens aux positions +1, +2, +3, ...
Medusa élimine entièrement le modèle brouillon mais nécessite une modification et un réentraînement du modèle. Les organisations avec des déploiements de modèles personnalisés peuvent trouver Medusa intéressant malgré une complexité d'intégration plus élevée.
Quand le décodage spéculatif aide
Le décodage spéculatif offre les meilleurs rendements dans des conditions spécifiques :
Scénarios favorables : - Applications de chat interactives privilégiant la latence - Inférence mono-utilisateur où la sous-utilisation GPU est élevée - Génération longue (histoires, documents, code) - Charges de travail avec des motifs de tokens prévisibles
Scénarios moins favorables : - Traitement par lots à haut débit saturant déjà le GPU - Réponses très courtes (peu de tokens à spéculer) - Génération très créative/aléatoire avec faibles taux d'acceptation - Déploiements contraints en mémoire où le modèle brouillon ne rentre pas
Cadre de décision :
SI (utilisation GPU < 50% pendant la génération)
ET (longueur moyenne de réponse > 100 tokens)
ET (le modèle brouillon rentre en mémoire)
→ Activer le décodage spéculatif
SI (utilisation GPU > 80%)
OU (pression mémoire élevée)
→ Se concentrer sur les optimisations de regroupement à la place
Considérations d'infrastructure
Le décodage spéculatif introduit des exigences d'infrastructure spécifiques :
Surcharge mémoire : Les modèles brouillons consomment de la mémoire GPU supplémentaire. Assurez une marge suffisante : - Poids du modèle brouillon : ~1-8 Go selon la taille - Cache KV supplémentaire pour les tokens brouillons - Allocations de tenseurs de vérification
Motifs de calcul : Les phases de vérification créent des motifs de calcul en rafales différents de la génération autorégressive régulière. Surveillez la variabilité d'utilisation GPU et ajustez les tailles de lots en conséquence.
Servir le modèle brouillon : Les options incluent : - Co-localisé : Le brouillon s'exécute sur le(s) même(s) GPU que la cible - Séparé : GPU dédié pour la génération brouillon - Déchargé sur CPU : Les petits brouillons peuvent s'exécuter sur CPU pour économiser la mémoire
Les organisations déployant le décodage spéculatif à grande échelle peuvent tirer parti de l'expertise d'Introl en infrastructure GPU pour une configuration matérielle et une planification de capacité optimales.
Checklist de déploiement en production
Avant d'activer le décodage spéculatif en production :
1. Mesure de référence - Mesurer la latence et le débit actuels - Profiler l'utilisation GPU pendant la génération - Identifier les goulots d'étranglement (mémoire, calcul, communication)
2. Sélection du modèle brouillon - Tester plusieurs tailles de brouillon avec des prompts représentatifs - Mesurer les taux d'acceptation pour votre distribution spécifique - Envisager l'affinage si l'acceptation est inférieure à 60 %
3. Réglage de la configuration - Expérimenter avec num_speculative_tokens (généralement 4-8) - Équilibrer le taux d'acceptation vs la surcharge du brouillon - Profiler l'utilisation mémoire avec les tailles de lots cibles
**4. Rollo
[Contenu tronqué pour la traduction]
