Le décodage spéculatif parallèle accélère SGLang jusqu’à 4 fois et passe en open source

Si vous exploitez des LLM en production, vous avez probablement déjà entendu parler du décodage spéculatif. Le principe est simple : un petit modèle de proposition prédit rapidement plusieurs tokens à l’avance, puis le grand modèle les vérifie en une seule passe. Si les prédictions sont correctes, vous obtenez plusieurs tokens pour le coût d’une seule étape, sans modifier la qualité de la réponse. C’est précisément ce qui a fait de cette méthode une pratique presque standard dans les piles d’inférence en production. De nouveaux travaux proposent désormais d’aller plus loin : générer les tokens candidats en parallèle tout en conservant leurs dépendances causales. Ils annoncent un débit multiplié jusqu’à 4 fois dans SGLang, avec un code rendu public.

Le problème d’EAGLE-3

EAGLE-3 est considéré comme l’une des approches les plus performantes du décodage spéculatif. Son modèle de proposition est autorégressif : pour prédire le cinquième token, il faut d’abord prédire le quatrième, et ainsi de suite. Ses prédictions sont précises, mais cette précision a un coût en temps. Chaque token candidat supplémentaire exige une nouvelle passe avant séquentielle. On retrouve alors un piège bien connu : à vouloir prédire davantage de tokens à l’avance, le modèle de proposition finit lui-même par ralentir le traitement et absorber les gains.

Imaginez une chaîne de montage où chaque ouvrier attend que le précédent ait terminé. Ajouter des ouvriers ne sert à rien : la vitesse dépend de la longueur de la chaîne.

L’alternative à la génération en chaîne

DFlash avait déjà fait un premier pas vers une solution. Inspiré des modèles de langage à diffusion, il génère tous les tokens candidats en parallèle : une seule passe dans le réseau de proposition produit tout un bloc de tokens. La latence cesse ainsi d’augmenter avec la longueur de la séquence proposée. Mais ce parallélisme intégral a un prix : les tokens du bloc sont prédits presque indépendamment les uns des autres, alors que, dans la langue, le mot suivant dépend fortement du précédent. Le taux de tokens acceptés par le modèle de vérification peut donc diminuer.

À en juger par leur titre, les nouveaux travaux cherchent précisément à résoudre cette contradiction. Les dépendances causales entre les tokens candidats sont intégrées à la profondeur du réseau de proposition : au lieu de passer par des étapes successives dans le temps, elles sont « encodées » dans les couches traversées au cours d’une même passe parallèle. Autrement dit, l’ordre est pris en compte à l’intérieur d’une seule passe, plutôt qu’au fil de plusieurs passes consécutives. La génération des candidats conserve ainsi la rapidité des approches parallèles, tout en se rapprochant de la précision des approches autorégressives.

Pour les détails de l’architecture, les tailles des modèles et les tableaux complets de mesures, mieux vaut consulter l’article scientifique et le dépôt de code. Le chiffre « jusqu’à 4 fois » concerne le débit dans SGLang et, comme toujours avec « jusqu’à », décrit le meilleur scénario, et non le cas typique.

Comment l’utiliser en pratique

Premier point : si vous utilisez SGLang et avez déjà activé le décodage spéculatif, il est pertinent de tester cette nouvelle méthode sur votre propre trafic. Les gains dépendent fortement du modèle, de la longueur des réponses, de la taille des lots et du taux de tokens acceptés par le modèle de vérification. Avec des réponses courtes ou de grands lots, l’effet peut être nettement plus modeste que ne le laisse entendre le titre.

Deuxième point : ne regardez pas uniquement le nombre de tokens par seconde. La latence du premier token, le comportement sous forte charge et la mémoire GPU consommée par le réseau de proposition comptent également. La mémoire supplémentaire allouée à ce réseau peut réduire l’espace disponible pour le cache KV et limiter le nombre de requêtes simultanées.

Troisième point : entraîner le réseau de proposition exige des données et des ressources de calcul. Si vous affinez ou remplacez le modèle de base, il faudra réentraîner le modèle de proposition, sous peine de voir baisser le taux de tokens acceptés. Intégrez cette contrainte au coût du déploiement.

Limites et conclusion

Ces résultats proviennent pour l’instant d’une seule publication, et les reproductions indépendantes restent rares. La méthode est liée à une pile logicielle précise ; son portage vers vLLM, TensorRT-LLM ou des noyaux de calcul maison demandera du travail. La direction est néanmoins claire : la course ne porte pas sur un modèle de base plus intelligent, mais sur la réduction du nombre d’étapes séquentielles nécessaires par token. Pour les équipes dont la facture GPU est devenue le premier poste de dépenses, ce code ouvert, qui promet de multiplier les performances, mérite un essai dès le prochain sprint : il suffit de comparer le débit et le taux de tokens acceptés sur des requêtes réelles, avant et après.