Principe du décodage spéculatif

Le décodage spéculatif sépare proposition et vérification. Un composant léger, appelé draft, génère une séquence de tokens candidats. Le modèle cible (le LLM original) les évalue en un seul passage de décodage. Chaque token est accepté ou rejeté de gauche à droite ; les tokens acceptés sont immédiatement engagés, les suivants sont abandonnés dès la première réfutation. Cette mécanique permet de réduire le nombre de passes du modèle cible lorsqu’une proportion suffisante de tokens est acceptée, ce qui diminue la latence de génération par rapport au décodage autorégressif classique où chaque token nécessite une passe distincte.

Méthodes de rédaction évaluées

vLLM a testé cinq approches de draft : native MTP, Gemma 4 MTP, EAGLE‑3, DFlash et DSpark. Les trois catégories sous‑jacentes sont :

• Modules MTP natifs : intégrés à l’architecture du modèle cible, ils utilisent un chemin auxiliaire de prédiction et génèrent les tokens séquentiellement.

• Drafters MTP séparés : checkpoints distincts couplés au modèle cible, partageant le KV‑cache et les activations du modèle cible, également séquentiels.

• Réseaux de draft conditionnés : modèles spécialisés entraînés pour un modèle cible donné. EAGLE‑3 produit des tokens autorégressifs à partir des états cachés du modèle cible, DFlash crée des blocs parallèles à partir des mêmes états, et DSpark ajoute une correction causale légère et une sélection de préfixe basée sur la confiance.

Résultats sur les GPU AMD

Les expériences ont été menées sur les GPU AMD Instinct ™ MI300X et MI355X sous la plateforme ROCm™ open. Le débit de tokens (tokens/s) a varié fortement selon la méthode de draft, la longueur de la proposition et la famille de modèle cible. Par exemple, sur le MI300X, le draft native MTP a atteint un gain de 1,8× par rapport à l’autoregression pure, tandis que DFlash a montré un gain maximal de 2,3× avec des propositions de 8 tokens. En revanche, DSpark a présenté des gains plus modestes (≈1,4×) lorsque le taux d’acceptation était inférieur à 60 %.

Le comportement d’acceptation dépend du modèle cible : les modèles de petite taille (≈7 B paramètres) acceptent en moyenne 70 % des tokens proposés, alors que les modèles de grande taille (≥13 B) n’acceptent que 45 % des tokens, ce qui réduit l’avantage du draft. De plus, la longueur de la proposition influe directement sur le nombre de passes du modèle cible ; des propositions trop longues augmentent le taux de rejet et entraînent des recalculs supplémentaires, annulant les gains de débit.

Limites et considérations pratiques

Le décodage spéculatif ne supprime pas la charge du modèle cible ; il la redistribue entre le draft et la vérification. Sur les GPU AMD, la bande passante du KV‑cache et la latence du transfert entre les deux réseaux restent les goulots d’étranglement majeurs. La configuration optimale nécessite de calibrer la longueur de proposition en fonction du taux d’acceptation observé pour chaque modèle et chaque charge de travail. Enfin, l’observabilité du processus (mesure du taux d’acceptation, suivi du temps de vérification) est indispensable pour éviter les scénarios où le draft génère systématiquement des tokens rejetés, ce qui augmenterait la latence globale plutôt que de la réduire.