Chapitre 9 — Décodage spéculatif

Neuvième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui découvre que le goulot séquentiel de l'autoregression a une faille mathématique — et montre l'arithmétique du moment où elle paie.

Pourquoi ce chapitre existe

Les Chapitres 7 et 8 ont attaqué la concurrence, tenant le GPU occupé sur de nombreuses séquences. Aucun ne change le fait que chaque séquence reçoit encore un token de sortie par itération. Ce plancher semble incontournable parce que la passe avant du transformer dépend réellement du token précédemment choisi. Le décodage spéculatif est l'observation que la dépendance porte sur la génération, non sur la vérification : étant donné un candidat pour le token t+1, le modèle cible peut lancer une passe avant qui demande à la fois « aurais-je choisi celui-ci ? » et calcule la distribution pour t+2 en supposant que le candidat est correct. Le Chapitre 9 parcourt le mécanisme, les algorithmes de brouillon (EAGLE, Medusa, Lookahead, MTP, n-gramme, suffixe) et l'arithmétique du moment où la spéculation est un gain.

9.1 L'insight de vérification préserve exactement la justesse

Un mécanisme de brouillon bon marché propose N tokens candidats. La cible — le modèle coûteux qu'on veut — lance une passe avant sur le préfixe concaténé aux N candidats. Comme la passe avant d'un transformer est parallèle sur les positions, la cible produit sa propre distribution du prochain token à chacune des N+1 positions dans cette passe unique. Le plus long préfixe sur lequel les candidats concordent avec la cible est accepté ; la première divergence est là où le moteur s'engage sur le choix propre de la cible et jette le reste. La règle d'acceptation — accepter x tiré du brouillon q avec probabilité min(1, p(x)/q(x)), sinon échantillonner à partir du résidu normalisé (p−q)₊ — rend la distribution de sortie identique à un échantillonnage cible pur. La spéculation préserve la justesse ; le brouillon n'affecte que la vitesse. Sur les GPU modernes, la passe de vérification à N=4 coûte environ 1,2–1,5× un pas de décodage normal, car l'attention couvre désormais N+1 positions de requête mais reste bien dans le régime lié à la mémoire.

9.2 EAGLE attache le brouillon à l'état caché de la cible

Les premières implémentations utilisaient un petit modèle séparé comme brouillon — Llama-7B rédigeant pour Llama-70B — ce qui fonctionne mais coûte un second flux HBM pour les poids du brouillon et plafonne l'acceptation car les deux modèles ne partagent pas leurs représentations. EAGLE, affiné par EAGLE-2 et EAGLE-3 sur 2024–2025, attache le brouillon à la cible : une seule couche de transformer entraînée à prédire le prochain état caché de la cible, projetée via le propre embedding de sortie de la cible. Il n'y a pas de jeu séparé de poids 7B à faire défiler ; la tête brouillon fait quelques centaines de mégaoctets. EAGLE-2 ajoute une expansion dynamique d'arbre de brouillons — un arbre de candidats vérifié en une passe d'attention avec un masque personnalisé — pour que la cible choisisse le meilleur parmi plusieurs chemins plutôt que la conjecture unique du brouillon. EAGLE-3 ajoute un mélange multi-couches, consommant des couches intermédiaires de la cible plutôt que la seule avant-dernière. Les taux d'acceptation atterrissent à 75–85 pour cent sur le chat et le code avec N entre 5 et 8, ce qui se traduit par des accélérations bout à bout de 3–4× face au décodage classique. Medusa prend l'autre voie — des têtes de brouillon parallèles qui prédisent plusieurs tokens futurs en une passe plutôt que de manière autoregressive — avec une histoire d'entraînement plus simple et une acceptation légèrement plus faible. Le décodage n-gramme et suffixe sont le repas gratuit pour les charges répétitives (édition de code, sorties de gabarit) où le brouillon est simplement une consultation dans le contexte récent.

9.3 La passe de vérification elle-même devient le plafond

La formule d'accélération est assez exacte pour l'écrire : E[tokens_acceptés] / (T_brouillon/T_décodage + 1 + α·N), où α est le surcoût de vérification par position, typiquement 0,05–0,15. Deux plafonds apparaissent. D'abord, α·N grandit avec N, donc augmenter N indéfiniment n'aide pas ; le pic est autour de N=6–8 à p=0,8, N=10–12 à p=0,9. Les moteurs qui codent N en dur ratent l'optimum quand la charge varie. Ensuite, plus subtilement, l'accélération asymptotique quand p tend vers 1 est 1/α — environ 10× pour α=0,10, 20× pour α=0,05 — car la passe de vérification est elle-même le mur. Les moteurs de production ont mesuré des pics d'accélération dans cette fourchette sur des charges très répétitives et ne les ont pas dépassés. La spéculation interagit aussi avec le batching : à forte taille de batch, la passe avant de la cible est déjà proche du calcul et les tokens de vérification supplémentaires la poussent plus loin, donc l'accélération se rétrécit quand le batch grandit. Le point idéal pour la spéculation est un batch bas à moyen sur des charges critiques en latence — précisément le régime où vit le calcul sous-utilisé du Chapitre 1.

Ce que prépare le Chapitre 9

Les Chapitres 5 à 9 ont épuisé la boîte à outils modèle et runtime — quantification, élagage, distillation, batching, KV paginé, décodage spéculatif. Aucun ne s'installe comme une bibliothèque qu'on pip install et qu'on oublie. Quelqu'un doit les câbler ensemble dans un runtime qui possède un modèle sur un GPU, fait tourner un batch continu et expose une API d'inférence. Ce runtime est le moteur. Le Chapitre 10 parcourt les cinq moteurs qui dominent la pile 2026 — vLLM, TensorRT-LLM, SGLang, TGI et Ollama — et les arbitrages mécaniques qui décident lequel est le bon choix pour un déploiement donné.

Prochaine étape — Chapitre 10 : La couche moteur LLM. vLLM, TensorRT-LLM, SGLang, TGI, Ollama — les moteurs comme runtime mono-nœud, choisis sur le mécanisme plutôt que sur le benchmark.