Inférence LLM : accélérer avec le décodage spéculatif

Pour un développeur, la question concrète est de savoir si la réponse s’affiche plus vite avec les requêtes de son application. Pour l’équipe chargée du service d’inférence, il faut vérifier que ce gain tient face aux requêtes simultanées et à la pression mémoire. Pour une équipe cliente d’une API hébergée, il faut d’abord savoir si le fournisseur expose ou documente cette optimisation.

Documentation vérifiée le 30 octobre 2026 : vLLM, SGLang et NVIDIA TensorRT-LLM. Les commandes ci-dessous suivent leur documentation en ligne. Ce sont des exemples de configuration, pas des résultats de benchmark réalisés pour cet article.

Qu’est-ce que le décodage spéculatif ?

Un mécanisme peu coûteux propose les prochains tokens ; le modèle cible décide lesquels peuvent entrer dans la réponse. Un token est une unité de texte traitée par le modèle, souvent une partie de mot. Le modèle cible est celui dont on veut préserver le comportement.

Imaginez un assistant qui prépare une phrase pour un rédacteur exigeant. L’assistant peut prendre de l’avance, mais rien ne parvient au lecteur avant validation. L’astuce consiste à faire évaluer toute la suite proposée par le modèle cible en une seule passe, au lieu d’attendre une étape de génération distincte pour chaque nouveau token. NVIDIA décrit ce fonctionnement comme un mécanisme de proposition suivi d’une passe de vérification par le modèle cible. Documentation TensorRT-LLM

Dans ce schéma, les lettres représentent des identifiants de tokens. Le modèle de proposition suggère A B C. En décodage glouton, qui choisit le prochain token le plus probable, supposons que le modèle cible approuve A B, mais préfère ensuite X. La réponse validée devient A B X. Toute suite proposée après le C rejeté est également abandonnée, puisqu’elle reposait sur un préfixe incorrect.

Lorsque la sortie est échantillonnée, l’acceptation ne se résume pas à vérifier si les modèles ont choisi le même mot. L’échantillonnage spéculatif standard s’appuie sur les probabilités du modèle cible et du mécanisme de proposition, avec une distribution de correction lorsqu’une proposition est rejetée. C’est cette correction qui préserve la distribution de probabilités du modèle cible. L’algorithme original autorise également un token supplémentaire issu du modèle cible lorsque toute l’ébauche est acceptée. Article original de Leviathan, Kalman et Matias

Le petit modèle fournit donc des propositions : il ne prend pas le relais pour répondre. Avec une vérification exacte, un mauvais modèle de proposition doit pénaliser la vitesse, sans se substituer discrètement au modèle cible.

Que signifie « sans recourir à un modèle moins performant » ?

La garantie à exiger est la préservation de la distribution du modèle cible. Cela ne promet ni la même réponse aléatoire à chaque exécution, ni la disparition des erreurs du modèle cible, ni un meilleur raisonnement. vLLM documente des effets numériques et liés au traitement par lots qui peuvent produire des différences, même lorsque l’algorithme est sans perte. Garanties de vLLM sur le décodage sans perte

Pendant l’évaluation, conservez les mêmes poids, la même quantification et les mêmes paramètres d’échantillonnage pour le modèle cible. Sinon, vous modifiez plusieurs variables à la fois et ne pouvez plus attribuer une différence de qualité à un changement précis.

Les principales variantes et leur prise en charge dans les moteurs

Choisissez un mécanisme de proposition compatible avec votre modèle cible précis et la version de votre moteur d’inférence. Le principe reste le même : proposer, puis vérifier. C’est l’origine des propositions qui change.

Un modèle de proposition distinct

Un modèle de langage plus petit génère les tokens candidats à partir de ses propres poids. C’est la configuration la plus intuitive, mais elle impose de charger et d’exploiter un autre modèle. La compatibilité et le degré d’accord avec la cible comptent : « plus petit » ne veut pas forcément dire « utile ». vLLM attend normalement un vocabulaire partagé, tout en documentant une option limitée pour des vocabulaires différents. Modèles de proposition dans vLLM

Si le service frôle déjà sa limite mémoire, ajouter un second modèle n’est pas forcément le bon point de départ. En revanche, pour un service sensible à la latence qui dispose de capacité libre et d’un modèle de proposition bien adapté, c’est une expérimentation contrôlée raisonnable.

Le décodage spéculatif avec EAGLE

EAGLE, pour Extrapolation Algorithm for Greater Language-model Efficiency, utilise un mécanisme auxiliaire de proposition entraîné et associé au modèle cible. Il s’appuie sur les représentations internes de ce dernier pour proposer la suite. Ces composants appris, souvent appelés têtes, nécessitent un checkpoint compatible. vLLM distingue les configurations eagle et eagle3. Documentation EAGLE de vLLM

Considérez le modèle cible et son checkpoint EAGLE comme une paire qui doit être compatible. Ne choisissez pas un checkpoint simplement parce que son nom mentionne la même famille de modèles. La famille exacte, la révision du modèle et l’implémentation du moteur doivent toutes figurer dans le dossier de déploiement.

Le décodage spéculatif avec MTP

La prédiction de plusieurs tokens, ou MTP pour Multi-token prediction, exploite une capacité native du modèle à proposer les tokens à venir. vLLM la documente pour les familles de modèles compatibles et fournit un exemple de lancement sans identifiant de modèle de proposition distinct. Un modèle dépourvu de cette capacité ne l’acquiert pas simplement parce que vous définissez method sur mtp. Documentation MTP de vLLM

Si vous exploitez déjà un checkpoint compatible MTP, essayez d’abord la configuration documentée avant d’ajouter un modèle de proposition indépendant. Vous aurez moins de choix de compatibilité à trancher, même si les performances restent à mesurer.

Le tableau suivant renvoie directement aux documentations des moteurs. Il indique où trouver les configurations, sans affirmer que tous les modèles fonctionnent dans chaque cas.

Le nom d’un algorithme ne décrit pas son organisation à l’exécution. Les notes de version actuelles de TensorRT-LLM suppriment le mode d’exécution avec un moteur de proposition séparé et conservent les implémentations qui intègrent ce mécanisme au modèle comme sous-module. Cela ne signifie pas que l’approche proposition/cible a disparu. Cela signifie que d’anciennes instructions de déploiement peuvent décrire un mode d’exécution absent de votre version installée. Notes de version TensorRT-LLM

Quand l’inférence LLM accélère-t-elle vraiment ?

La spéculation n’est gagnante que si la sortie utile arrive plus vite, une fois tout le travail supplémentaire pris en compte. Le taux d’acceptation compte, mais ce n’est qu’un élément du calcul.

Les tokens acceptés doivent compenser le coût des propositions

Le taux d’acceptation est le nombre de tokens proposés puis acceptés divisé par le nombre total de tokens proposés. À lui seul, il ne dit rien du coût de leur production. Un modèle de proposition plus lent peut être plus souvent d’accord avec la cible et malgré tout ralentir le service.

Voici un critère de décision utile :

(temps de proposition + temps de vérification + temps de coordination) ÷ tokens de sortie validés < temps de décodage par token sans spéculation

C’est un bilan des coûts, pas une prédiction de benchmark. Mesurez le tour complet sur votre matériel. Les « tokens de sortie validés » comprennent aussi le token de correction ou le token supplémentaire fourni par le modèle cible, pas seulement les propositions acceptées.

Pour un assistant de modification de code, la répétition de structures locales peut rendre les propositions utiles. Pour un assistant de support, le modèle de proposition peut s’accorder avec la cible sur les formules de politesse et les transitions, mais peiner sur les réponses propres au produit. Mesurez séparément ces usages avant de décider d’un déploiement à partir d’un taux d’acceptation moyen.

Des ébauches plus longues produisent aussi davantage de travail susceptible d’être jeté. N’augmentez leur profondeur que tant que la sortie validée supplémentaire compense le surcoût de proposition, de vérification et de mémoire. Fireworks fait la même distinction dans ses conseils de réglage : le taux d’acceptation ne suffit pas à démontrer un gain de vitesse. Conseils de benchmark de Fireworks

La taille des lots change le gain possible

Commencez par les usages interactifs limités par le décodage, puis testez au pic de requêtes simultanées. vLLM recommande spécifiquement la spéculation pour les charges limitées par la bande passante mémoire, à un rythme de requêtes faible à modéré. Dans une telle étape, le déplacement des données du modèle freine davantage l’exécution que la puissance de calcul disponible. Recommandations de vLLM selon la charge

La vérification parallèle peut exploiter une puissance de calcul jusque-là sous-utilisée. Mais un serveur très sollicité emploie peut-être déjà cette capacité pour d’autres requêtes. Conséquence : une latence plus faible sur une conversation isolée ne prouve pas que le débit total d’un service chargé augmente.

Le continuous batching change les requêtes qui partagent chaque étape de génération. Évaluez la spéculation avec cet ordonnancement, en reproduisant le rythme réel d’arrivée des requêtes. Un service de développement peu sollicité et un service de production avec une file d’attente constituent des expériences différentes.

N’imposez pas de seuil universel de taille de lot. La limite utile dépend du modèle, du matériel, de la méthode de proposition et de l’ordonnanceur. Suivez à la fois la latence et la capacité : la vitesse à laquelle la réponse s’affiche, et le trafic que le service peut absorber en respectant son objectif de latence.

La mémoire peut annuler le gain

Le mécanisme de proposition prend sa part d’un budget de mémoire GPU limité. Les poids distincts, l’état des propositions et les espaces de travail de vérification peuvent occuper de la place qui servirait autrement aux requêtes. Le KV cache, qui stocke l’état d’attention des tokens existants, fait partie de ce budget.

Prenons un assistant documentaire rapide sur les prompts courts, mais proche de sa capacité maximale avec de longs documents. Un essai concluant sur des prompts courts ne dit pas si le mécanisme de proposition tient encore en mémoire aux côtés du cache de production. Testez la longueur de contexte maximale que vous comptez prendre en charge, avec un niveau réaliste de requêtes simultanées.

Les conseils de SGLang en cas de mémoire insuffisante prévoient explicitement de réduire la réservation mémoire, les tailles de capture des graphes, la taille de l’arbre de propositions et le nombre de requêtes simultanées. Si vous devez réduire ce dernier pour faire tenir la spéculation en mémoire, c’est un compromis à mesurer, pas une optimisation gratuite. Résolution des problèmes mémoire dans SGLang

Accélérer ce qui fait réellement attendre l’utilisateur

Une réponse lente peut venir d’une longue attente avant le début de la sortie, d’un affichage progressif trop lent ou de délais extérieurs au modèle. La spéculation vise la génération. Si votre application passe l’essentiel de son temps à chercher des documents ou à attendre le retour d’un outil, accélérer la boucle de décodage changera peut-être à peine l’expérience.

Dans vos mesures, distinguez l’attente en file, le prefill et le décodage. Le prefill traite le prompt ; le décodage génère la suite. Le guide de l’inférence LLM explique ces étapes, tandis que le guide des tokens par seconde distingue la vitesse de sortie du débit global de traitement des requêtes.

Comment activer le décodage spéculatif ?

Activez la spéculation dans le processus serveur, puis comparez avec le même modèle cible sans cette option. Ces exemples supposent que le moteur est déjà installé, que le matériel peut accueillir les modèles sélectionnés et que vous avez accès à leurs poids. Consultez la documentation correspondant à la version déployée : une page latest en ligne ne garantit pas la compatibilité avec un conteneur plus ancien.

Configurer le décodage spéculatif dans vLLM

vLLM utilise un objet JSON transmis par --speculative-config. Cet exemple avec modèle de proposition distinct reprend le modèle cible, le modèle de proposition et la longueur d’ébauche de sa documentation de service en ligne :

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

Le 5 correspond au nombre de tokens proposés dans cet exemple, pas à un optimum recommandé. La documentation déprécie les anciens paramètres séparés --speculative-model et --num-speculative-tokens. Exemples de lancement vLLM

Pour un exemple de MTP natif, le checkpoint de base Xiaomi MiMo documenté se lance ainsi :

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

Il s’agit d’un exemple avec un autre modèle, pas d’un modèle de proposition directement interchangeable pour la cible Qwen ci-dessus. La contrainte est la compatibilité du checkpoint : MTP doit être présent dans le modèle et pris en charge par votre moteur. Exemple de lancement MTP dans vLLM

Configurer le décodage spéculatif dans SGLang

L’exemple actuel de SGLang pour l’ordonnanceur avec chevauchement des opérations utilise une paire Qwen avec un modèle de proposition indépendant :

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

Ce mode avec chevauchement exige actuellement --speculative-eagle-topk 1. Un arbre plus large repris d’un autre exemple n’est pas compatible avec ce mode. Conservez ensemble les paramètres d’ordonnancement et de proposition documentés. Exemple SGLang avec ordonnanceur à chevauchement

Pour les charges variables, SGLang documente séparément la spéculation adaptative pour les configurations EAGLE compatibles. Lisez les conditions requises avant de compter sur un ajustement automatique de la profondeur des propositions. Spéculation adaptative dans SGLang

Configurer TensorRT-LLM

TensorRT-LLM reçoit les paramètres de spéculation dans une configuration YAML. Enregistrez ceci dans speculative.yaml :

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

La longueur d’ébauche et le checkpoint proviennent de l’exemple de configuration spéculative de NVIDIA. Lancez le modèle cible correspondant avec l’interface en ligne de commande du serveur documentée :

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

Vérifiez la génération du checkpoint autant que le nom de la configuration. NVIDIA documente Eagle comme un alias de compatibilité pour Eagle3, mais les générations antérieures de checkpoints EAGLE restent incompatibles avec ce mode. Restriction de TensorRT-LLM sur les checkpoints

Si vous choisissez aussi le moteur d’inférence, consultez le comparatif plus général entre vLLM et SGLang. Un bon modèle de proposition ne compense pas l’absence d’une autre fonction indispensable à votre application.

Peut-on en profiter avec une API hébergée ?

Oui, lorsque le fournisseur le documente et l’active ; les réglages accessibles dépendent du service. Il n’est pas nécessaire de posséder les GPU pour profiter d’une optimisation du service d’inférence du fournisseur.

Fireworks AI, fournisseur d’inférence hébergée, documente des modèles de proposition par défaut pour la plupart des modèles pris en charge sur ses déploiements dédiés. Un modèle sans mécanisme de proposition par défaut fonctionne sans spéculation fondée sur un modèle, sauf configuration contraire. Fireworks gère la configuration de l’inférence serverless : les paramètres des déploiements dédiés ne prouvent donc pas que tous les points de terminaison serverless utilisent la spéculation. Documentation des déploiements Fireworks

Pour les applications qui régénèrent un fichier avec de petites modifications, Fireworks documente aussi Predicted Outputs : le texte attendu est fourni dans le champ prediction de la requête. Ce texte connu constitue une autre source de propositions, qui peut fonctionner en complément de la spéculation fondée sur un modèle. C’est utile lorsque vous connaissez déjà une grande partie de la réponse, plutôt que lorsque vous posez une question ouverte. Predicted Outputs de Fireworks

Pour un autre service hébergé, exigez sa propre documentation avant d’annoncer ce bénéfice ou d’ajouter un paramètre. La compatibilité de l’API ne dit rien, à elle seule, du modèle de proposition éventuellement utilisé derrière le service.

Les promesses à relativiser

Le décodage spéculatif améliore le service d’inférence sous certaines conditions ; il ne multiplie pas systématiquement sa vitesse. Cet article ne promet aucun gain chiffré : un résultat obtenu avec une autre cible, un autre modèle de proposition, un autre GPU et un autre trafic ne décrit pas votre service.

« Plus de tokens acceptés signifie une application plus rapide » oublie le coût des propositions, l’attente en file et tout ce que fait l’application autour de la génération. « Une ébauche plus longue est meilleure » ignore le travail abandonné après un rejet. « Sans perte signifie des textes identiques » confond une distribution d’échantillonnage avec un résultat aléatoire particulier.

L’erreur la plus coûteuse consiste à transformer un résultat obtenu sur un service peu sollicité en promesse de capacité en production. Un assistant de code peut sembler plus rapide à son développeur alors que le service partagé prend en charge moins de sessions simultanées. Décidez si vous optimisez la latence de réponse, le débit soutenu ou les deux, et inscrivez ce choix dans vos critères de déploiement.

Que mettre en place dès la semaine prochaine ?

Les développeurs devraient tester un mécanisme de proposition compatible lorsque le décodage est le goulot d’étranglement. Les équipes d’exploitation devraient exiger un gain sous charge de production. Les équipes clientes d’une API hébergée devraient commencer par les réglages réellement documentés par leur fournisseur.

Si l’essentiel de l’attente précède la génération, traitez d’abord ce goulot d’étranglement. Si le mécanisme de proposition ne tient pas en mémoire ou qu’aucun checkpoint compatible n’existe, conservez le fonctionnement normal du modèle cible. La disponibilité d’une fonction ne prouve pas que votre déploiement en a besoin.

Les questions des développeurs

Abonnez-vous à la newsletter pour des guides pratiques sur la conception et l’exploitation de systèmes d’IA.