AWS et vLLM intègrent P-EAGLE pour accélérer jusqu'à 1,69 fois l'inférence des grands LLM

AWS et l'équipe de vLLM ont présenté P-EAGLE, une nouvelle façon d'accélérer l'inférence des grands modèles de langage sans changer le modèle principal. L'approche est déjà intégrée à vLLM et, lors de tests avec GPT-OSS 20B, elle a offert jusqu'à 1,69 fois plus de débit que l'EAGLE-3 classique.

Où se situait le goulot d'étranglement

Le décodage spéculatif est considéré de longue date comme l'un des moyens les plus pratiques d'accélérer les LLM à l'inférence. Un modèle auxiliaire propose à l'avance plusieurs tokens suivants, et le modèle principal vérifie rapidement lesquels peuvent être acceptés. La méthode EAGLE apportait déjà un gain notable et était utilisée dans vLLM, SGLang et TensorRT-LLM.

Mais un problème important subsistait : pour générer K tokens de brouillon, le modèle drafter devait effectuer K forward passes séquentiels. Plus la spéculation était profonde, plus la latence du brouillon lui-même augmentait. L'EAGLE classique se heurtait donc à un plafond caché. Sur le papier, il aurait fallu spéculer plus profondément et accepter davantage de tokens par tour, mais en pratique le travail supplémentaire du drafter finissait par annuler le bénéfice.

Les auteurs de P-EAGLE suppriment précisément cette limite : les K tokens de brouillon sont générés en une seule passe. Cela fait pencher la balance en faveur d'une spéculation plus agressive, surtout pour les réponses longues et les tâches de code, où chaque opération séquentielle superflue se voit dans la latence et le débit.

Comment fonctionne P-EAGLE

L'architecture de P-EAGLE comporte deux étapes. D'abord, le modèle cible traite le prompt et prédit le token suivant, comme d'habitude. Au passage, le système conserve les hidden states internes des positions du prompt et du nouveau token.

Ensuite, le drafter assemble en parallèle les entrées de toutes les positions futures : pour les parties déjà connues de la séquence, il utilise de vrais embeddings et hidden states, et pour les positions qui n'existent pas encore, il substitue des masques apprenables et un vecteur caché commun. Plusieurs tokens futurs sont alors prédits en un seul forward pass, et non plus par une chaîne de plusieurs étapes.

L'entraînement sur des séquences longues constitue une difficulté à part. AWS indique que, pour GPT-OSS 120B sur UltraChat, la longueur médiane de la séquence, prompt et génération compris, atteignait 3891 tokens, et le 90e percentile 10800 tokens. Avec le brouillon parallèle, la mémoire augmente très vite, car le nombre de positions devient N × K. Pour y remédier, les auteurs ont ajouté un algorithme de sequence partition : il découpe une longue séquence en morceaux contigus, préserve les dépendances d'attention correctes entre eux et permet d'accumuler les gradients au sein d'un même exemple, et pas seulement entre différents batches.

Intégration et chiffres

La partie pratique ne s'arrête pas à l'article : P-EAGLE est déjà ajouté à vLLM, à partir de la version 0.16.0. Pour l'activer, il suffit d'utiliser le décodage spéculatif avec le flag parallel_drafting: true et de brancher un drafter head compatible. AWS a déjà publié des checkpoints prêts à l'emploi pour GPT-OSS 120B, GPT-OSS 20B et Qwen3-Coder 30B : on peut donc essayer la technologie sans entraînement depuis zéro.

• L'intégration est apparue dans vLLM avec la version 0.16.0
• Le mode s'active via le flag parallel_drafting: true
• Des modèles head P-EAGLE prêts à l'emploi sont disponibles pour GPT-OSS 120B, GPT-OSS 20B et Qwen3-Coder 30B
• Sur NVIDIA B200, le gain par rapport à l'EAGLE-3 classique va de 1,05× à 1,69×
• Le meilleur débit de P-EAGLE lors des tests a été atteint avec une profondeur de spéculation K=7

Les benchmarks dessinent un tableau stable. Sur MT-Bench, HumanEval et SPEED-Bench, la nouvelle méthode a gagné 55–69 % à faible concurrence et a conservé un avantage de 5–25 % même sous forte charge.

Outre la vitesse, l'acceptance length a elle aussi progressé : il s'agit du nombre moyen de tokens de brouillon que le vérificateur accepte par tour. Par exemple, avec K=7 sur HumanEval, P-EAGLE obtient 3,94 contre 3,03 pour EAGLE-3, et sur SPEED-Bench 3,38 contre 2,59.

AWS précise par ailleurs que l'exécution de GPT-OSS 20B avec un drafter EAGLE nécessite encore un correctif d'une ligne dans vLLM, qui doit être intégré à l'une des prochaines versions.

Ce que cela signifie

Pour les équipes qui utilisent déjà vLLM en production, P-EAGLE ressemble à une amélioration rare qui n'oblige pas à reconstruire toute la pile : le nouveau schéma est intégré à un runtime familier et s'active par la configuration, avec un checkpoint compatible. Si l'écosystème obtient rapidement davantage de modèles drafter entraînés en parallèle, cette variante du décodage spéculatif pourrait devenir le nouveau standard d'une inférence de LLM rapide et peu coûteuse.