El equipo EAGLE, vLLM, y TorchSpec lanzaron conjuntamente EAGLE 3.1, corrigiendo un verdadero bug de producción en decoding especulativo: a medida que la profundidad de especulación aumenta, el modelo drafter desvía su atención de los tokens sink hacia sus propios tokens generados, degradando la longitud de aceptación y la estabilidad de salida. El fix son dos cambios arquitectónicos — normalización FC aplicada después de cada hidden state target y antes de la capa FC para acotar las magnitudes de los hidden states, más feedback hidden-state post-norm para que el drafter se comporte como invocación recursiva en lugar de capas anexadas. Ya mergeado en el main de vLLM, enviando en v0.22.0, retrocompatible con checkpoints EAGLE 3 existentes.
Las ganancias reportadas son concretas. En cargas long-context, hasta 2× longitud de aceptación más larga vs EAGLE 3. En Kimi K2.6-NVFP4 SPEED-Bench coding, lifts de throughput por usuario de 2.03× en concurrencia 1, 1.71× en concurrencia 4, y 1.66× en concurrencia 16. El patrón — lift más grande en baja concurrencia, estrechándose a medida que la concurrencia sube — es lo que los constructores deben esperar de cualquier ganancia de decoding especulativo: el decoding especulativo gana cuando el modelo está cuello de botella en ancho de banda de memoria por request, ese es el régimen en baja concurrencia. En alta concurrencia estás cuello de botella en throughput agregado y el win especulativo es más pequeño. No hay comparaciones directas contra Medusa o baselines de draft-model vanilla en el release, esa es la brecha metodológica para flaggear.
La lectura de ecosistema reside en el camino de integración más que en los números. EAGLE ha sido la familia de decoding especulativo de producción por dos años; vLLM es el motor de inferencia por defecto para LLMs self-hosted; TorchSpec provee el lado de entrenamiento. Cuando los tres convergen en un release que corrige una inestabilidad conocida con un cambio algorítmico retrocompatible, eso es la stack de inferencia reduciendo su varianza load-bearing, no agregando una feature. El draft model open-sourced para Kimi K2.6 en HuggingFace significa que los constructores en Kimi ya tienen el artefacto; para otros modelos base, el trabajo del lado de entrenamiento está en TorchSpec. Los loops agentic con ventanas de contexto creciendo son donde el drift de atención más dolía — trazas largas de agente, completion de código en archivos largos, document QA — y esas son exactamente las cargas donde 2× longitud de aceptación se traduce en wins de latencia visibles al usuario.
Si corres vLLM en producción: programa el upgrade 0.22.0 y re-entrena tus draft models en TorchSpec cuando puedas. Si construyes SaaS de inferencia: este es el cambio que silenciosamente mejora la curva de costo long-context para todos los que usan tu stack.