Resumen: La decodificación especulativa permite que vLLM verifique varios tokens propuestos en una sola pasada del modelo objetivo. En nuestros experimentos, su efecto en el rendimiento de tokens de salida varió según los métodos de borrado y las longitudes propuestas, y también dependió de la familia de modelos, el punto de control de borrado, la carga de trabajo y el comportamiento de aceptación.

Introducción: Los modelos de lenguaje grandes admiten una amplia gama de aplicaciones, pero servirles a gran escala requiere una optimización cuidadosa. La decodificación autocrónica estándar es la base utilizada por la mayoría de los sistemas de servicio de LLM: el modelo genera un token, lo adjunta a la secuencia y luego usa la secuencia actualizada para generar el siguiente token. Este proceso es simple y fiable, pero el bucle de servicio aún avanza un token comprometido a la vez, ya que los tokens de salida deben producirse en orden estricto de izquierda a derecha. La decodificación especulativa [1] se basa en esta base mediante un mecanismo de borrador y verificación. Un componente de borrador ligero propone tokens candidatos futuros y el modelo objetivo verifica esos candidatos antes de comprometerlos. Cuando varios tokens de borrador son aceptados, el sistema puede comprometer varios tokens de salida de un solo paso de verificación del modelo objetivo preservando el comportamiento de salida del modelo objetivo. Esta publicación explora cómo funciona la decodificación especulativa en vLLM y comparte mediciones de nuestro entorno de prueba. Primero, revisamos la base de decodificación autocrónica y el proceso de borrador y verificación. Luego, examinamos cinco enfoques de borrador especulativo: MTP nativo, Gemma 4 MTP, EAGLE-3, DFlash y DSpark. Estos métodos difieren en cómo el componente de borrador recibe información del modelo objetivo y si los tokens candidatos se generan secuencialmente, autocrónicamente, en paralelo o mediante un enfoque híbrido. Finalmente, mostramos cómo habilitar los métodos probados en nuestro entorno, informamos mediciones de nuestros experimentos en GPU AMD Instinct® MI300X y MI355X usando la plataforma de software abierta ROCm®, y discutimos consideraciones prácticas de ajuste y observabilidad.

Base de decodificación autocrónica: En la decodificación autocrónica estándar, cada paso de decodificación produce y compromete un nuevo token. Por ejemplo, generar cuatro tokens de salida requiere cuatro pasos de decodificación secuenciales: Paso 1:context→model→T1 Paso 2:context + T1→model→T2 Paso 3:context + T1 T2→model→T3 Paso 4:context + T1 T2 T3→model→T4 Después de cada paso, el token generado se adjunta a la secuencia y se convierte en la entrada del siguiente paso. Esto hace que el bucle de decodificación sea sencillo, pero también requiere un paso de decodificación del modelo para cada token de salida. Durante generaciones largas, este bucle token por token puede dominar la latencia y limitar el rendimiento del servicio.

La pregunta clave detrás de la decodificación especulativa es, por tanto: ¿Podemos preservar el comportamiento de salida del modelo original mientras reducimos la frecuencia a la que la generación avanza solo un token a la vez? La decodificación especulativa aborda esto separando la propuesta de la verificación. Un componente de borrador primero propone varios tokens candidatos futuros. El modelo original, actuando como el modelo objetivo, luego verifica esos candidatos antes de comprometerlos.

Idea central de la decodificación especulativa: La decodificación especulativa no reemplaza el modelo original. En su lugar, mantiene el modelo original como modelo objetivo, que sigue siendo responsable del resultado final, y añade una etapa de propuesta más rápida delante de él. El proceso tiene dos partes: Borrador: proponer varios tokens candidatos futuros. Verificación: usar el modelo objetivo para comprobar esos candidatos.

En cada ronda de decodificación especulativa, como se ilustra en la Figura 1, un componente de borrador ligero propone uno o más tokens futuros. Estos tokens solo son candidatos y no se comprometen inmediatamente. El modelo objetivo entonces evalúa la secuencia de tokens candidatos en una pasada de verificación. La verificación procede de izquierda a derecha. Cada token de borrador se comprueba usando el resultado del modelo objetivo en la posición correspondiente. Los tokens aceptados se comprometen a la secuencia de salida. Cuando un token de borrador es rechazado, los candidatos posteriores...