Quand et pourquoi utiliser le speculative decoding

En production, chez l’un de nos clients, l’implémentation du speculative decoding avec Llama 3-70B et EAGLE-3 a permis d’observer des réductions de latence E2E allant jusqu’à ×2.5 sur des requêtes LLM hébergées.

Ce gain est considérable, mais il n’est pas garanti. La performance du speculative decoding dépend du hardware, du prompt, du QPS (Queries per second) et du régime d’exécution.

Cet article explique pourquoi, à l’aide de modèles mentaux simples, de métriques pertinentes, et de retours terrain.

1. Pourquoi l’inférence LLM reste un problème système

L’inférence des LLM est lente pour deux raisons structurelles.

La première est bien connue :

la génération est auto-régressive. Chaque token dépend des précédents, ce qui impose une exécution strictement séquentielle. On ne peut pas paralléliser la génération des tokens dans le temps, a priori.

Mais cette séquentialité n’explique pas entièrement la latence observée en production.

La seconde raison, souvent moins intuitive, est la suivante :

la phase de decoding est peu intensive en calcul et fortement contrainte par la mémoire.

À chaque pas de génération :

• on exécute un forward sur une seule position temporelle,
• avec un batch souvent faible,
• et donc avec un volume d’opérations relativement réduit.

Le GPU n’est pas saturé en calcul.

En revanche, il passe une part significative du temps à attendre les lectures mémoire (poids, KV cache).

Autrement dit, le decoding est majoritairement memory-bound plutôt que compute-bound:

• le facteur limitant n’est pas la puissance de calcul,
• mais la bande passante mémoire et la latence de transferts de données.

Ce régime est particulièrement difficile à passer à l’échelle :

• ajouter plus de compute n’aide pas,
• augmenter la taille du GPU ne change pas fondamentalement le goulot d’étranglement,
• la séquentialité empêche de masquer efficacement la latence mémoire.

C’est précisément dans ce contexte que le speculative decoding devient intéressant :

il exploite le compute idle du GPU pendant le decoding, en échange d’un surcoût contrôlé, pour réduire le nombre d’itérations séquentielles.

2. Speculative decoding : ce qu’il fait, et ce qu’il ne fait pas

Le speculative decoding introduit deux modèles :

• un draft model ( draft ), petit et rapide, généralement entre 0.5B et 8B
• un target / verifier model ( target ), grand et précis (celui que vous utilisez déjà et souhaitez accélérer)

Le mécanisme est le suivant :

1. A partir d’un prompt donné, le draft propose une séquence de ( k ) tokens de façon auto-régressive (classique, 1 token à la fois)
2. Le target vérifie ces tokens en parallèle.
3. Tant que les tokens sont compatibles avec la distribution du target, ils sont acceptés.
4. Dès qu’un token est rejeté :
   • il est remplacé par un token échantillonné depuis le modèle target,
   • les tokens suivants proposés ne sont pas pris en compte.
5. On réitère le processus

Point clé :

Le speculative decoding est lossless : la distribution finale des tokens générés est identique à celle du modèle cible seul, dès lors que le mécanisme d’acceptation et les paramètres d’échantillonnage sont strictement respectés.

3. Les régimes d’exécution : la clé pour comprendre les gains (ou les pertes)

3.1. Régime optimal — memory-bound, faible QPS (queries per second) , sorties longues

Le speculative decoding fonctionne bien lorsque :

• le GPU n’est pas saturé en requêtes,
• la latence est dominée par la phase de decoding,
• donc lorsque les sorties sont longues (beaucoup de tokens).

Dans ce régime :

• une partie du compute GPU est idle,
• le draft model utilise ce compute inutilisé,
• l’inter-token latency diminue significativement.

C’est dans ce cadre que l’on observe des speed-ups typiques de ×2 à ×2.7, donc des gains de latence réels.

3.2. Régime de dégradation — compute-bound, haut QPS, sorties courtes

À l’inverse, le speculative decoding peut devenir contre-productif lorsque :

• le QPS est élevé,
• le batch size est important,
• le GPU est alors déjà compute-bound.

Dans ce cas :

• ajouter le draft model ajoute du compute,
• le GPU risque de saturer,
• le speculative decoding peut dégrader la latence et le throughput.

Il existe un seuil de concurrence:

• en-dessous: le speculative decoding est plus rapide que le decoding classique (vanilla),
• au-dessus: régime de dégradation: speculative decoding devient plus lent que le vanilla decoding.

Ce seuil correspond au point d’intersection des courbes représentant le throughput en fonction de la concurrence, avec et sans speculative decoding.

4. Les métriques à surveiller

Acceptance rate per position

On définit cette métrique par:

$a_{i} = \mathbb{P}(\text{le token à la position } i \text{ est accepté})$

où i correspond au rang du token proposé par le draft dans un bloc spéculatif.

Exemple typique :

$a_{1}$ = 0.72; $a_{2}$ = 0.43 ; $a_{3}$ = 0.18

Lecture :

• 72 % des premiers tokens spéculés sont acceptés,
• 43 % des seconds,
• 18 % des troisièmes.

Il y a mécaniquement une décroissance rapide avec la position : dès qu’un token en position i est rejeté, tous les suivants proposés le sont automatiquement et plus le draft avance sans revalidation, plus la probabilité d’acceptation diminue.

Ce qui importe n’est pas seulement $a_1$​, mais l’ensemble de la séquence $(a_{i})_{i \in 1:K}$​, dont la forme conditionne le gain potentiel du speculative decoding.

Mean acceptance length

C’est la métrique clé à observer pour calculer votre speedup. La métrique correspond à:

Elle est donnée dans les logs via /metrics dans vLLM. Le +1 provient du fait qu’il y a un token bonus, car lorsque le modèle target rejette un token proposé par le modèle draft, il le rejette pour un autre token que l’on gardera.

Influence du sampling

Le mean acceptance length dépend directement des paramètres de génération.

Une température plus élevée (ou un top-p / top-k plus large) augmente la diversité des tokens proposés, ce qui réduit la corrélation locale entre draft et target, et donc l’acceptance. À l’inverse, un régime plus déterministe favorise des préfixes acceptés plus longs.

Les gains doivent toujours être mesurés avec les paramètres de sampling réellement utilisés en production.

De $L$ au speed-up réel

Important :

( L ) n’est pas un speed-up observé sur le decoding, mais une borne supérieure.

• ( L ) : longueur moyenne de tokens acceptés consécutivement,
• ( $C_{target}$) : coût d’un pas de decoding du target en temps,
• ( $C_{draft}$) : coût du draft en temps.

Un modèle mental utile (mais heuristique) est :

$\text{SPEED-UP} \approx \frac{L \cdot C_{target}}{C_{target} + C_{draft}}$

en pratique:

$\text{SPEED-UP} \approx 0.8 L$

À retenir :

• ( L ) est un plafond théorique, pas un gain garanti,
• le speed-up réel est toujours inférieur à (L),

Nota Bene

Plus votre Mean acceptance length est élevé, plus le point d’intersection cité plus haut est repoussé vers la droite. C’est-à-dire que plus la métrique est élevé, plus le speculative decoding reste avantageux sous charge par rapport au Vanilla decoding.

5. Pourquoi EAGLE-3 change la donne

Initialement, le speculative decoding utilisait des paires de modèles “naturelles”, par exemple LLaMA-70B avec un LLaMA-7B ou 8B comme draft.

Cette approche a montré rapidement ses limites :

• un modèle 7B–8B n’est pas négligeable en coût compute, mémoire et scheduling,
• il n’existe pas toujours de modèle plus petit naturellement compatible,
• surtout, un petit LM ne prédit pas forcément ce que dirait le modèle target, ce qui réduit fortement le taux d’acceptation (donc le mean acceptance length).

Or, pour le speculative decoding, l’objectif du draft n’est pas d’être un “bon LM”, mais de bien anticiper les choix du targer, du moins localement.

C’est précisément ce que changent les modèles EAGLE-3. Ces modèles très petits ($\approx 1B$) ont directement accès aux hidden states (les couches cachées) du modèle target.n

Les modèles EAGLE-3 ne minimisent pas une loss de langage standard ; ils optimisent directement :

$\mathbb{E}[\text{longueur de préfixe accepté}]$

Résultat : Cela permet d’améliorer la stabilité de l’acceptation, de ralentir la décroissance relative à la position, et d’exploiter efficacement le speculative decoding à un coût abordable.

Dans nos tests, EAGLE-3 fournit les meilleurs speed-ups mesurables en régime favorable.

6. Dépendance forte au prompt

Tous les prompts ne se valent pas, et l’écart peut être très important.

En pratique, le mean acceptance length (qui est un proxy du speed-up effectif) varie fortement selon la distribution de prompts :

• prompts structurés (code, Q&A, formats contraints, summary) → acceptance élevée,
• prompts ouverts, créatifs, très spécialisés et/ou dans une autre langue que l’anglais → acceptance plus faible.

Retour terrain :

• Mean acceptance length élevée sur de l’anglais,
• dégradations observées pour du français ou autre langue ou sur des prompts très spécialisés

Ce type d’écart est cohérent avec une hypothèse simple : les modèles EAGLE-3 sont (pour le moment) majoritairement entraînés sur des données anglaises, ce qui induit un meilleur alignement draft–verifier sur cette distribution.

Point clé :

Le taux d’acceptation n’est pas une propriété intrinsèque du modèle, mais du triplet (draft, verifier, distribution de prompts).

Le speculative decoding est donc fortement dépendant du prompt. Les gains doivent être mesurés explicitement sur vos prompts, via le mean acceptance length, pas un speed-up moyen agrégé.

7. Guide pratique et conclusion — le bon état d’esprit en production

Le speculative decoding n’est ni une option à activer par défaut, ni une optimisation “gratuite”.

C’est une optimisation système, fortement régime-dépendante, qui vise avant tout à réduire l’inter-token latency en exploitant du compute GPU autrement inutilisé.

Quand le speculative decoding est un bon candidat

Le speculative decoding est intéressant lorsqu’on veut diminuer la latence. Il fonctionne bien lorsque l’inférence est memory-bound, c’est-à-dire lorsque :

• les sorties sont longues,
• la charge (concurrency) est faible à modérée,
• le GPU est partiellement idle pendant le decoding.

Dans ce régime, le speculative decoding permet :

• une meilleure utilisation du hardware,
• des gains de latence significatifs (×2–×2.7),
• sans compromis sur la qualité (lossless).

Quand il vaut mieux l’éviter

À l’inverse, il peut devenir contre-productif lorsque :

• le QPS est élevé,
• sampling élevé (température > 0.8)
• les outputs sont courts,
• donc lorsque le GPU est déjà compute-bound.

Dans ce contexte, l’ajout du draft model augmente le compute total et peut dégrader la latence et réduire le throughput.

Recommandations de terrain:

• num_speculative_tokens = 3 est souvent le meilleur compromis,
• augmenter ce nombre sans avoir un mean acceptance length suffisant haut accroît fortement le risque de speed-down sous charge,
• les gains doivent toujours être mesurés sur vos prompts réels, via le mean acceptance length.

Message clé pour la production

En production, le speculative decoding doit être :

• mesuré (mean acceptance length, pas seulement latency),
• profilé (régime memory vs compute-bound),
• et idéalement activé de manière conditionnelle.