L'équipe EAGLE, vLLM, pis TorchSpec ont sorti conjointement EAGLE 3.1, en corrigeant un vrai bug de production dans le décodage spéculatif : à mesure que la profondeur de spéculation augmente, le modèle drafter détourne son attention des tokens sink vers ses propres tokens générés, dégradant la longueur d'acceptation pis la stabilité de sortie. Le fix est deux changements architecturaux — normalisation FC appliquée après chaque hidden state target pis avant la couche FC pour borner les magnitudes des hidden states, plus feedback hidden-state post-norm pour que le drafter se comporte comme une invocation récursive plutôt que des couches appendues. Déjà mergé dans le main de vLLM, livraison dans v0.22.0, rétrocompatible avec les checkpoints EAGLE 3 existants.
Les gains rapportés sont concrets. Sur les charges long-context, jusqu'à 2× longueur d'acceptation plus longue vs EAGLE 3. Sur Kimi K2.6-NVFP4 SPEED-Bench coding, lifts de throughput par utilisateur de 2.03× à concurrence 1, 1.71× à concurrence 4, pis 1.66× à concurrence 16. Le pattern — plus gros lift à basse concurrence, qui rétrécit à mesure que la concurrence monte — c'est ce que les bâtisseurs devraient attendre de n'importe quel gain de décodage spéculatif : le décodage spéculatif gagne quand le modèle est goulé sur la bande passante mémoire par request, c'est le régime à basse concurrence. À haute concurrence tu es goulé sur le throughput agrégé pis le win spéculatif est plus petit. Pas de comparaisons directes contre Medusa ou les baselines de draft-model vanilla montrées dans le release, c'est le gap méthodologique à flagger.
La lecture écosystème siège dans le chemin d'intégration plus que dans les chiffres. EAGLE est la famille de décodage spéculatif de production depuis deux ans ; vLLM est le moteur d'inférence par défaut pour les LLMs self-hosted ; TorchSpec fournit le côté entraînement. Quand les trois convergent sur un release qui corrige une instabilité connue avec un changement algorithmique rétrocompatible, c'est la stack d'inférence qui réduit sa variance load-bearing, pas qui ajoute une feature. Le draft model open-sourcé pour Kimi K2.6 sur HuggingFace veut dire que les bâtisseurs sur Kimi ont déjà l'artefact ; pour les autres modèles de base, le travail côté entraînement est sur TorchSpec. Les boucles agentiques avec fenêtres de contexte qui grossissent sont là où le drift d'attention faisait le plus mal — longues traces d'agent, complétion de code dans de longs fichiers, document QA — pis c'est exactement les charges où 2× longueur d'acceptation se traduit en wins de latence visibles à l'utilisateur.
Si tu roules vLLM en prod : planifie l'upgrade 0.22.0 pis ré-entraîne tes draft models sur TorchSpec quand tu peux. Si tu bâtis du SaaS d'inférence : c'est le changement qui améliore silencieusement la courbe de coût long-context pour tout le monde qui utilise ta stack.