La decodificación especulativa en paralelo acelera SGLang hasta 4 veces y se publica como código abierto

Si ejecutas LLM en producción, seguramente ya has oído hablar de la decodificación especulativa. La idea es sencilla: un pequeño modelo de borrador predice rápidamente varios tokens por adelantado y un modelo grande los verifica en una sola pasada. Si las predicciones son correctas, obtienes varios tokens por el coste de un solo paso, sin que cambie la calidad de la respuesta. Por eso el método se ha convertido prácticamente en un estándar en las plataformas de inferencia en producción. Ahora, un nuevo trabajo lo lleva más allá: generación del borrador en paralelo conservando las dependencias causales. Sus autores anuncian hasta 4 veces más capacidad de procesamiento en SGLang, y el código se ha publicado en abierto.

El problema de EAGLE-3

EAGLE-3 se considera uno de los métodos más sólidos de decodificación especulativa. Genera el borrador de forma autorregresiva: para predecir el quinto token, primero debe predecir el cuarto, y así sucesivamente. Sus predicciones son precisas, pero esa precisión tiene un coste en tiempo. Cada token adicional del borrador implica otra pasada hacia delante secuencial. Surge así una trampa conocida: quieres predecir más tokens por adelantado, pero la propia generación del borrador empieza a ralentizar el proceso y se come la ganancia.

Imagina una cadena de montaje en la que cada operario espera a que termine el anterior. Añadir operarios no sirve de nada: la velocidad viene determinada por la longitud de la cadena.

Qué proponen en lugar de la cadena

DFlash dio un paso previo hacia la solución. Inspirado en los modelos de lenguaje por difusión, genera todo el borrador en paralelo: una sola pasada por la red de borrador produce un bloque completo de tokens. La latencia deja de crecer con la longitud del borrador. Pero el paralelismo total tiene un precio: los tokens del bloque se predicen casi de forma independiente, mientras que en el lenguaje la siguiente palabra depende mucho de la anterior. Esto puede reducir la proporción de tokens que acepta el modelo verificador.

A juzgar por su título, el nuevo trabajo resuelve precisamente esta tensión. Las dependencias causales entre los tokens del borrador se integran en la profundidad de la propia red: en lugar de pasos secuenciales en el tiempo, la dependencia se «codifica» en las capas que recorre una misma pasada en paralelo. Dicho de forma sencilla, el orden se tiene en cuenta dentro de una sola pasada, en vez de mediante varias pasadas consecutivas. Así, la generación del borrador conserva la velocidad de los métodos paralelos y se acerca a la precisión de los autorregresivos.

Para conocer los detalles concretos de la arquitectura, los tamaños de los modelos y las tablas completas de mediciones, conviene consultar el artículo y el repositorio. La cifra de «hasta 4 veces» se refiere a la capacidad de procesamiento en SGLang y, como siempre ocurre con «hasta», describe el mejor escenario, no el habitual.

Cómo aplicarlo en la práctica

Primero: si utilizas SGLang y ya tienes activada la decodificación especulativa, tiene sentido probar el nuevo método con tu propio tráfico. La ganancia depende mucho del modelo, la longitud de las respuestas, el tamaño del lote y la proporción de tokens que acepta el modelo verificador. Con respuestas cortas o lotes grandes, la mejora puede ser bastante más modesta de lo que sugiere el titular.

Segundo: no te fijes solo en los tokens por segundo. También importan el tiempo hasta el primer token, el comportamiento bajo una carga elevada y el consumo de memoria de GPU de la red de borrador. La memoria adicional destinada al borrador puede restar espacio a la caché KV y reducir el número de solicitudes simultáneas.

Tercero: entrenar la red de borrador requiere datos y recursos de cómputo. Si ajustas o cambias el modelo base, tendrás que volver a entrenar el modelo de borrador; de lo contrario, caerá la tasa de aceptación de tokens. Inclúyelo en el coste de implementación.

Limitaciones y conclusión

Por ahora, los resultados proceden de una sola publicación y hay pocas reproducciones independientes. El método está ligado a una plataforma concreta, y adaptarlo a vLLM, TensorRT-LLM o kernels propios requerirá trabajo. Aun así, la dirección está clara: la carrera no consiste en conseguir un modelo base más inteligente, sino en dedicar menos pasos secuenciales a cada token. Para los equipos cuya factura de GPU se ha convertido en su principal gasto, merece la pena probar en el próximo sprint un código abierto que promete multiplicar el rendimiento: basta con comparar la capacidad de procesamiento y la tasa de aceptación de tokens con solicitudes reales antes y después.