En bref (TL;DR) : Le décodage spéculatif accélère la génération de tokens des LLM sans modifier le résultat : un petit modèle brouillon (draft model) propose rapidement plusieurs tokens, puis le grand modèle les vérifie en une seule passe avant (forward pass) conjointe. L'unique question qui détermine son utilité : mon inférence est-elle limitée par la mémoire (memory-bound, le gain en vaut la peine, jusqu'à ~2x) ou limitée par le calcul (compute-bound, gain quasi nul) ? Pour la plupart des utilisateurs individuels et des petites configurations de lots (batchs) sur du matériel local, la réponse est memory-bound — et le gain de vitesse est réel.
Ce qu'accomplit le décodage spéculatif
Le décodage spéculatif (speculative decoding) sépare la génération de la vérification. Un petit modèle brouillon rapide génère k propositions de tokens d'un coup. Le grand modèle de vérification lit l'ensemble des k propositions en une seule passe avant et en accepte autant que celles qui correspondent à sa propre distribution. Dès la première divergence, le décodage reprend de manière classique à partir de ce point.
Le résultat : au lieu de k étapes séquentielles, il suffit d'une passe pour le brouillon et d'une autre pour la vérification. Avec un taux d'acceptation de 4 propositions sur 5, le nombre de grandes passes avant est environ réduit de moitié.
Pourquoi ce gain de vitesse est sans perte (lossless)
Contrairement à la quantification (quantization) ou à la réduction du contexte, la vérification ne modifie pas la sortie : la règle d'acceptation est conçue de telle sorte que la distribution de sortie correspond exactement à celle du grand modèle. C'est pourquoi le mécanisme est nommé « Lossless Speedup of Autoregressive Decoding » dans l'article original de Levi et al. (2022) — la longueur du brouillon représente un compromis entre le parallélisme et le taux d'acceptation.
L'unique question qui détermine le gain
L'accélération (speedup) dépend du régime d'inférence. Cette règle de décision sous-tend tout l'article :
| Régime | Caractéristiques | Effet du décodage spéculatif |
|---|---|---|
| Memory-bound (Limité par la mémoire) | Petits lots (souvent 1), les cœurs de calcul du GPU attendent les données de la mémoire | Important : jusqu'à ~2x moins d'étapes |
| Compute-bound (Limité par le calcul) | Grands lots, les FLOPs du GPU sont pleinement exploités | Faible à nul : la vérification « consomme » les unités parallélisées |
Règle pratique : Lors d'un prompt unique sur un GPU local (Mac mini, carte RTX en flux unique), l'inférence est presque toujours memory-bound — le décodage spéculatif s'avère rentable. En revanche, pour les lots serveurs entièrement regroupés (large batches), le gain se réduit.
Mesures en production
Voici les ordres de grandeur présentés dans la vidéo originale et publiés par Berkeley et Red Hat :
- Berkeley : Accélération de ~1,96x pour les petits lots, ~1,21x pour les plus grands — le gain diminue à mesure que la taille du lot augmente.
- Red Hat : +27 % de tokens/s et −19 % sur les coûts par million de tokens en activant le décodage spéculatif dans la stack vLLM.
Moins d'étapes pour une sortie identique signifie directement des coûts inférieurs par million de tokens — cette accélération est donc aussi un avantage financier, et pas seulement une astuce de latence.
Bloc de configuration vLLM à copier
Choisissez un modèle brouillon de la même famille (le plus petit représentant), longueur du brouillon entre 4 et 8 tokens :
vllm serve Qwen/Qwen3-32B \
--speculative-config '{"method": "draft", "model": "Qwen/Qwen3-0.6B", "num_speculative_tokens": 5}'
Alternativement, avec un jeu de méthodes intégré (par ex. EAGLE), si le modèle choisi le prend en charge :
# vllm serve Qwen/Qwen3-32B --speculative-config
method: eagle3
num_speculative_tokens: 2
Liste de contrôle (Checklist) pour votre propre stack
- Ma configuration est-elle memory-bound ? (Prompts individuels, petit lot → oui.)
- Le modèle brouillon est-il de la même famille que le modèle cible ? — Même tokenizer, meilleure acceptation.
- Démarrer avec
num_speculative_tokensentre 4 et 8, journaliser (logger) le taux d'acceptation et ajuster. - Pour les grands lots : mesurer le gain au lieu de le supposer ; l'accélération peut tendre vers zéro.
FAQ
Pourquoi le décodage spéculatif est-il vraiment sans perte, bien qu'un modèle plus petit fasse les propositions ? Parce que le petit modèle ne fournit que des propositions, tandis que la distribution finale est vérifiée par le grand modèle en une seule passe. La règle d'acceptation garantit mathématiquement que la distribution de sortie est identique à la sortie séquentielle du grand modèle. Le modèle brouillon ne peut donc pas « diluer » la sortie — il ne peut que réduire le nombre de passes.
Comment choisir le modèle brouillon (draft model) ? Prenez le plus petit représentant de la même famille de modèles, comme Qwen3-0.6B comme brouillon pour Qwen3-32B. Une même famille implique un tokenizer identique et des distributions conditionnelles similaires, ce qui maintient un taux d'acceptation élevé. Un modèle brouillon générique et hors domaine entraîne généralement des rejets plus fréquents et donc une accélération moindre.
Le gain est-il également rentable pour les grands lots (batchs) ? Oui, mais avec une tendance à la baisse. Dans les situations memory-bound (lot de 1 à 8), des gains de ~1,9x sont courants ; plus les FLOPs du GPU sont exploités, plus le gain tend vers 1,2x ou moins. La raison : la vérification des tokens brouillons occupe les mêmes unités de calcul parallèles qui sont déjà pleinement sollicitées lors du traitement par lots.
Quel est l'impact sur les coûts ? Moins de grandes passes avant pour un texte équivaut directement à moins de secondes GPU par million de tokens — les −19 % chez Red Hat correspondent exactement à ce calcul. À capacité matérielle constante, le débit augmente, ce qui fait baisser le prix par million de tokens. L'économie des coûts est cependant liée à la condition d'être memory-bound — en mode lot complet, elle diminue avec l'accélération elle-même.
Comment savoir si le décodage spéculatif ne fonctionne pas pour moi ? La plupart des stacks de service (y compris vLLM) enregistrent (log) le taux d'acceptation du brouillon par étape. Un taux d'acceptation proche de la longueur du brouillon indique un gain maximal ; un taux inférieur à ~50 % signifie : brouillon trop long ou famille de modèles trop éloignée — il faut réduire la longueur du brouillon ou prendre un modèle de la même famille. Si le GPU tourne à pleine charge (grand lot), un gain minime est normal et ne constitue pas une erreur de configuration.
Sources
- Levi, G., Fusco, J., Sakr, S., Gerards, M. (2022): Lossless Speedup of Autoregressive Decoding — https://arxiv.org/abs/2203.16487
- Vidéo originale sur le mécanisme : Speculative Decoding: The ONLY Video You Need to Speed Up Inference — https://www.youtube.com/watch?v=_hEGvCwHyH8
- Documentation vLLM sur le Speculative Decoding — https://docs.vllm.ai/en/latest/features/spec_decode.html
- Optimisation de l'inférence LLM de Berkeley (chiffres d'accélération) — https://llm-d.ai/
- Red Hat : Benchmark à +27 % Tokens/s / −19 % de coûts avec décodage spéculatif — https://www.redhat.com/en