Décodage spéculatif pour l’inférence de LLM : gains de débit et compromis
Le service de LLM à décodage spéculatif peut réduire le temps d’attente du prochain jeton, sans demander au modèle cible de devenir un modèle différent. Au lieu de laisser le grand modèle cible produire un seul jeton par étape de décodage, un proposeur moins coûteux génère une courte continuation. Le modèle cible vérifie cette continuation en parallèle, valide le préfixe accepté et poursuit à partir du premier désaccord.
Cela ressemble à un accélérateur universel. Ce n’en est pas un. Le résultat dépend de la qualité du brouillon, du mix de requêtes, du traitement par lots, des paramètres d’échantillonnage, de la marge de mémoire GPU disponible et du fait que votre charge de travail soit réellement limitée par le décodage. Ce guide explique ce qui se passe en coulisses, comment EAGLE et Medusa modifient la conception, et comment déterminer si le décodage spéculatif a sa place dans votre pile de serving.
La règle pratique : considérez le décodage spéculatif comme une optimisation de serving à mesurer, et non comme un paramètre d’accélération théorique. Conservez-le uniquement lorsqu’il améliore l’objectif de latence ou de débit de jetons de sortie qui compte pour votre trafic réel, sans réduire la concurrence ni la fiabilité.
Qu’est-ce que l’inférence de LLM par décodage spéculatif ?
La génération autorégressive est séquentielle : le jeton t + 1 dépend des jetons qui le précèdent. Un décodeur normal attend donc qu’un grand modèle cible s’exécute une fois par jeton généré. Le décodage spéculatif modifie l’ordonnancement, et non la distribution cible : un mécanisme de brouillon plus petit ou spécialisé prédit plusieurs jetons candidats ; le modèle cible évalue ou vérifie ensemble les positions candidates ; le système accepte le préfixe correspondant et revient en arrière à la première position rejetée.
L’article original sur le décodage spéculatif le décrit comme un moyen d’obtenir des échantillons exacts du modèle cible tout en évaluant en parallèle plusieurs positions candidates. Son résultat rapporté de 2 à 3× était un résultat de benchmark pour sa configuration T5, et non une promesse pour tous les modèles ou services. Lire l’article original.
Diagramme d’inférence de LLM par décodage spéculatif
request + current context
|
v
draft mechanism proposes: [A] [B] [C] [D]
|
v
target model verifies all proposed positions in one pass
|
+-- accepts [A] [B] [C] -> commit that prefix (and possibly one extra target token)
|
+-- rejects at [C] -> commit [A] [B], sample/correct at [C], then repeat
Le travail économisé n’est pas le calcul du brouillon lui-même. Le gain potentiel vient du remplacement de plusieurs itérations de décodage sériel du modèle cible par un passage de vérification du modèle cible. Si la proposition est souvent erronée, le modèle cible doit tout de même corriger fréquemment la sortie et le gain diminue.
La métrique qui compte : les jetons acceptés par vérification du modèle cible
Le signal de santé le plus utile est le nombre de jetons proposés qui passent la vérification. Les équipes l’appellent souvent taux d’acceptation ou longueur acceptée. Suivez les deux :
| Métrique | Ce qu’elle indique | Pourquoi elle peut être trompeuse isolément |
|---|---|---|
| Taux d’acceptation | La part des jetons proposés que le modèle cible accepte | Il n’inclut pas le coût du brouillon ni celui de la vérification par le modèle cible. |
| Longueur acceptée moyenne | Le nombre de jetons de brouillon validés obtenus par tour | Les moyennes peuvent masquer les requêtes à longue traîne et les différents modes d’échantillonnage. |
| Latence inter-jeton (ITL) | Le temps entre les jetons diffusés en flux | Il s’agit généralement de la métrique de décodage visible par l’utilisateur. |
| Nombre agrégé de jetons de sortie par seconde | La capacité de service utile sur l’ensemble des requêtes simultanées | Elle peut s’améliorer alors qu’un utilisateur interactif à faible QPS ne constate qu’un faible bénéfice, ou l’inverse. |
| Mémoire GPU et nombre de requêtes actives | Si le proposeur évince le cache KV ou réduit la concurrence | Une requête unique plus rapide peut constituer une configuration moins performante à l’échelle de la flotte. |
Pour un test A/B équitable, maintenez constants la révision du modèle, le tokenizer, la quantification, la longueur maximale de sortie, le mélange de prompts, les paramètres d’échantillonnage, le matériel et la politique de concurrence. Comparez la latence de bout en bout, le délai avant le premier jeton, l’ITL p50/p95, les jetons de sortie par seconde et le taux d’erreur. Un unique chiffre de « jetons/s » sans la forme de sa charge ne suffit pas pour choisir une configuration.
Là où le décodage spéculatif aide — et là où il n’aide pas
Le service de LLM avec décodage spéculatif est généralement le plus intéressant lorsque le décodage est limité par la mémoire et que chaque requête génère suffisamment de texte pour que les tours de vérification répétés soient significatifs. Les recommandations actuelles de vLLM le présentent spécifiquement comme un moyen de réduire la latence inter-jeton pour des charges de travail limitées par la mémoire, avec un QPS moyen à faible, et précisent que les gains réels dépendent de la famille de modèles, du trafic, du matériel et des paramètres d’échantillonnage. Consulter le guide du décodage spéculatif de vLLM.
Il est moins convaincant dans les cas suivants :
- Le préremplissage domine la requête. Les prompts longs avec des réponses courtes passent la majeure partie de leur temps à ingérer le contexte. Le brouillon modifie le travail de décodage, et non le travail de préremplissage du prompt qui domine déjà la latence de bout en bout.
- L’acceptation est faible. Un décodage créatif, un modèle de brouillon mal adapté ou une configuration produisant de faibles continuations candidates peuvent provoquer des échecs de vérification répétés.
- Votre serveur est déjà saturé par les lots. À forte concurrence, le GPU cible peut être efficacement occupé par l’ordonnanceur normal. L’ajout d’un générateur de brouillon peut consommer de la mémoire ou du calcul qui auraient autrement servi davantage de requêtes.
- La marge du cache KV est limitée. Un modèle de brouillon ou un état de proposeur supplémentaire peut réduire le nombre de séquences actives avant le début des évictions ou de la mise en file d’attente. Consultez les exigences de mémoire GPU pour les LLM avant d’interpréter une accélération sur requête unique comme un gain pour la flotte.
- Le modèle cible n’est pas compatible avec le proposeur choisi. Les méthodes basées sur un modèle exigent des artefacts, une tokenisation et une prise en charge du service compatibles ; ne supposez jamais qu’un petit modèle constitue un modèle de brouillon valide simplement parce qu’il est moins coûteux.
La bonne question n’est donc pas « Le décodage spéculatif peut-il accélérer ce modèle ? » mais « Quelle contrainte au niveau du service améliore-t-il sous notre distribution de trafic ? »
Modèles de brouillon, EAGLE et Medusa : trois façons de proposer des jetons
Modèle de brouillon distinct
La conception classique associe un modèle de brouillon rapide à un modèle cible plus grand. Le brouillon propose k jetons ; le modèle cible les vérifie. Cette approche peut être simple sur le plan conceptuel, mais elle ajoute un artefact de modèle, une empreinte mémoire, du travail de compatibilité et une surface opérationnelle supplémentaire à versionner et surveiller.
Utilisez-la lorsque vous disposez d’un proposeur dont la compatibilité et la faible latence sont démontrées, ainsi que d’une capacité GPU suffisante pour préserver la concurrence du service cible. Commencez par un petit ensemble de longueurs spéculatives, plutôt que de supposer qu’une proposition plus profonde est toujours meilleure.
LLM de décodage spéculatif EAGLE
EAGLE est une approche basée sur un modèle qui produit des brouillons au niveau des caractéristiques plutôt qu’en n’utilisant qu’un chemin de proposition conventionnel de petit modèle de jetons. L’article décrit le conditionnement de sa prédiction de caractéristiques par une séquence de jetons à un pas d’avance afin de traiter l’incertitude au niveau des caractéristiques. Dans les configurations testées par l’article, il rapporte une latence et un débit améliorés tout en préservant la distribution du texte généré ; il s’agit d’une preuve utile du potentiel de la méthode, et non d’une prévision de capacité pour un autre modèle ou une autre flotte de GPU. Lire l’article sur EAGLE.
Pour les opérateurs, l’implication est simple : EAGLE peut être intéressant lorsque des artefacts pris en charge sont disponibles pour la famille cible, mais ce n’est pas une option générique pour chaque checkpoint. Validez l’association exacte cible/proposeur et la version du moteur de service avant de la promouvoir.
LLM de décodage spéculatif Medusa
Medusa place plusieurs têtes de décodage sur un modèle backbone et utilise une attention basée sur des arbres pour créer et vérifier plusieurs continuations candidates. Cela évite de maintenir un modèle de brouillon entièrement indépendant, mais les têtes doivent être entraînées ou ajustées pour le backbone. L’article sur Medusa distingue une voie à backbone gelé d’un ajustement conjoint et rapporte des accélérations de benchmark pour ces configurations expérimentales. Lire l’article sur Medusa.
Le compromis opérationnel diffère de celui d’une paire modèle de brouillon/modèle cible : potentiellement moins de gestion de modèles séparés, mais un artefact spécifique au modèle et une exigence d’entraînement ou d’intégration. Considérez-le comme un choix de service de modèle, et non comme une astuce d’exécution.
Un plan de déploiement pratique pour l’inférence GPU
1. Établir une référence représentative
Capturez au moins un échantillon de requêtes proche de la production : tranches de longueur de prompt, tranches de longueur de sortie, langue ou type de tâche, paramètres de température/top-p, comportement de diffusion en flux et niveaux de concurrence. Enregistrez la référence séparément pour le délai avant le premier jeton et pour le décodage. Si la charge de travail est riche en prompts, ne laissez pas un benchmark de jetons de sortie masquer un problème de préremplissage.
2. Choisir une stratégie de proposeur et une profondeur prudente
Commencez avec une méthode prise en charge — modèle de brouillon, EAGLE, Medusa ou un autre proposeur pris en charge par le moteur — et une petite longueur candidate. vLLM, par exemple, documente des paramètres --speculative-config tels qu’une méthode, un modèle proposeur et num_speculative_tokens ; consultez la documentation correspondant à votre version avant de copier une configuration en production. Pour une configuration opérationnelle plus large, consultez le guide de déploiement vLLM. Lors de la première itération, n’ajustez pas simultanément la profondeur spéculative et le traitement par lots.
3. Exécuter une matrice de charge, pas un seul benchmark
Testez le même échantillon de trafic à une concurrence faible, moyenne et proche du pic. Pour chaque point, comparez :
- La latence de bout en bout de référence par rapport au mode spéculatif.
- La latence inter-jeton p50 et p95 pour les requêtes diffusées en flux.
- Le nombre agrégé de jetons de sortie par seconde et de requêtes terminées par seconde.
- La longueur acceptée, la fréquence de rejet et la latence du proposeur.
- La mémoire GPU, la pression sur le cache KV, le délai de file d’attente et le taux d’erreurs/de délais d’expiration.
Si possible, répartissez les résultats par tranche de prompt et tranche de sortie. Une configuration qui aide les longues complétions de code peut ne pas aider les courtes réponses de chat, et un bon résultat hors ligne peut se dégrader une fois la mise en file d’attente incluse.
4. Définir des garde-fous avant le canari
Définissez les seuils de retour arrière avant que le trafic ne voie la modification : par exemple, une régression de l’ITL p95, une baisse des requêtes terminées par seconde à charge de pointe, une augmentation des événements de mémoire insuffisante ou un effondrement persistant du taux d’acceptation. Au départ, n’acheminez qu’une tranche éligible et conservez un chemin de référence pour une comparaison rapide.
5. Continuer à mesurer après le lancement
L’acceptation évolue avec les mises à jour de modèles, les distributions de prompts, les formats d’utilisation d’outils et les paramètres d’échantillonnage par défaut. Réexécutez la comparaison après toute modification importante du modèle cible, du tokenizer, de la quantification, du GPU, du moteur de service ou du profil de trafic.
Un point de départ vLLM minimal
Pour un moteur de service qui le prend en charge, la configuration doit indiquer la méthode de proposeur au lieu de la masquer dans une valeur par défaut opaque. La documentation actuelle de vLLM utilise une structure comme celle-ci pour un modèle de brouillon distinct :
vllm serve <target-model> \
--speculative-config '{
"method": "draft_model",
"model": "<compatible-draft-model>",
"num_speculative_tokens": 5
}'
Les espaces réservés sont intentionnels. Le modèle compatible, le nombre de jetons spéculatifs, les paramètres de parallélisme et le budget mémoire doivent être choisis parmi les artefacts et la version du moteur que vous avez testés. Ne copiez pas cet extrait comme preuve qu’une paire cible/brouillon donnée est prise en charge.
Gains de débit et compromis en un coup d’œil
| Décision | Avantage probable | Coût principal ou mode de défaillance | À mesurer en premier |
|---|---|---|---|
| Activer un modèle de brouillon distinct | Moins d’étapes de décodage sériel du modèle cible lorsque l’acceptation est élevée | Mémoire supplémentaire pour le modèle, compatibilité et latence du brouillon | Longueur acceptée, marge du cache KV, ITL p95 |
| Augmenter la longueur spéculative | Davantage de jetons potentiels par vérification | Davantage de travail de brouillon gaspillé lorsque les jetons ultérieurs sont rejetés | ITL net et TPS de sortie agrégé, et non l’acceptation seule |
| Utiliser EAGLE | Voie de proposition solide basée sur un modèle lorsque les artefacts sont pris en charge | Exigences de compatibilité avec la famille de modèles et le moteur | Compatibilité cible/proposeur et résultats de benchmark selon la charge |
| Utiliser Medusa | Proposition à plusieurs têtes sans modèle de brouillon complet distinct | Têtes spécifiques au modèle et travail d’intégration/d’entraînement | Vérifications de la qualité de sortie, prise en charge du service et chemin de retour arrière |
| L’activer au QPS de pointe | Bénéfice de débit possible dans le bon moteur/la bonne charge de travail | La contention de l’ordonnanceur, de la mémoire ou du calcul peut annuler le gain | Requêtes terminées/s, temps d’attente en file et taux d’erreur |
FAQ
Le décodage spéculatif modifie-t-il la réponse du modèle cible ?
Un échantillonnage spéculatif correct utilise la vérification et la correction par le modèle cible afin que l’échantillonnage puisse préserver la distribution cible. Cette garantie dépend de l’utilisation d’un algorithme correct et d’une implémentation compatible. Une modification du service peut néanmoins affecter le comportement opérationnel — par exemple la latence, la mise en file d’attente ou les erreurs — évaluez donc la qualité et la fiabilité ainsi que la vitesse.
Le décodage spéculatif améliore-t-il le délai avant le premier jeton ?
En général, il cible la phase de décodage après le début de la génération. Si le traitement des prompts domine vos requêtes, le délai avant le premier jeton peut peu changer. Mesurez séparément le préremplissage et le décodage.
Combien de jetons spéculatifs dois-je utiliser ?
Il n’existe pas de valeur optimale universelle. Testez une petite plage avec votre modèle, votre proposeur, vos paramètres d’échantillonnage, votre type de GPU et votre concurrence. Une proposition plus longue ne l’emporte que si suffisamment de ses jetons sont acceptés et si son travail supplémentaire ne réduit pas la capacité de service.
Dois-je utiliser EAGLE ou Medusa ?
Choisissez la méthode que votre modèle cible et votre moteur de service prennent bien en charge, puis évaluez-la sur votre charge de travail. EAGLE s’appuie sur des artefacts de brouillon au niveau des caractéristiques pris en charge ; Medusa s’appuie sur plusieurs têtes associées à un backbone. Aucun des deux n’est automatiquement interchangeable avec un modèle de brouillon générique.
Placer la décision dans son contexte
Le décodage spéculatif est une couche d’optimisation du service de LLM. Il fonctionne au mieux avec un choix clair de service de modèle, des limites de capacité réalistes et une surveillance explicite. Pour une comparaison plus large des moteurs de service, consultez vLLM vs SGLang : débit, latence, prise en charge des modèles et opérations. Pour l’aspect capacité des API de production, consultez RPM vs TPM : limites de débit des LLM et correctifs 429.
Si vous planifiez des expérimentations GPU ou un nouvel environnement d’inférence, découvrez Flatkey Compute et commencez par un plan de benchmark qui rapporte à la fois la latence visible par l’utilisateur et le débit à l’échelle de la flotte. La meilleure configuration de LLM avec décodage spéculatif est celle qui améliore votre métrique contrainte sous charge réelle — et qui peut être annulée en toute sécurité lorsque la charge de travail évolue. Ce guide sur le décodage spéculatif pour les LLM est un point de départ pour cette discipline de mesure, et non un substitut à celle-ci.
Sources
- Leviathan, Kalman et Matias — Inférence rapide à partir de Transformers via le décodage spéculatif
- Cai et al. — Medusa : cadre simple d’accélération de l’inférence de LLM avec plusieurs têtes de décodage
- Li et al. — EAGLE : l’échantillonnage spéculatif exige de repenser l’incertitude des caractéristiques
- Documentation vLLM — Décodage spéculatif
