Guías de modelos y modalidades26 de octubre de 2026Flatkey Team

Decodificación especulativa para la inferencia de LLM: mejoras de rendimiento y compensaciones

Guía práctica sobre la decodificación especulativa para la inferencia de LLM: cómo funciona, cuándo ayuda, en qué se diferencian EAGLE y Medusa, y qué evaluar antes del despliegue.

Decodificación especulativa para la inferencia de LLM: mejoras de rendimiento y compensaciones

El servicio de decodificación especulativa de LLM puede reducir el tiempo de espera del siguiente token, sin pedirle al modelo objetivo que se convierta en un modelo diferente. En lugar de permitir que el gran modelo objetivo produzca solo un token por paso de decodificación, un proponente más económico redacta una continuación breve. El modelo objetivo verifica esa continuación en paralelo, confirma el prefijo aceptado y continúa desde el primer desacuerdo.

Esto suena como un acelerador universal. No lo es. El resultado depende de la calidad del borrador, la combinación de solicitudes, el procesamiento por lotes, la configuración de muestreo, el margen de memoria de la GPU y de si su carga de trabajo está realmente limitada por la decodificación. Esta guía explica qué sucede internamente, cómo EAGLE y Medusa cambian el diseño y cómo decidir si la decodificación especulativa tiene lugar en su pila de servicio.

La regla práctica: trate la decodificación especulativa como una optimización de servicio medida, no como una configuración de aceleración de un artículo académico. Manténgala solo cuando mejore el objetivo de latencia o de rendimiento de tokens de salida que importa para su tráfico real, sin reducir la concurrencia ni la fiabilidad.

Flujo de trabajo de decodificación especulativa de LLM que muestra propuestas de borrador verificadas por un modelo objetivo

¿Qué es la inferencia de LLM con decodificación especulativa?

La generación autorregresiva es secuencial: el token t + 1 depende de los tokens anteriores. Por tanto, un decodificador normal espera a que un gran modelo objetivo se ejecute una vez por cada token generado. La decodificación especulativa cambia la programación, no la distribución objetivo: un mecanismo de borrador más pequeño o especializado predice varios tokens candidatos; el modelo objetivo puntúa o verifica conjuntamente las posiciones candidatas; el sistema acepta el prefijo coincidente y recurre al respaldo en la primera posición rechazada.

El artículo original sobre decodificación especulativa describe esto como una forma de obtener muestras exactas del modelo objetivo mientras se evalúan varias posiciones candidatas en paralelo. Su resultado reportado de 2–3× fue un resultado de referencia para su configuración de T5, no una promesa para todos los modelos o servicios. Lee el artículo original.

Un diagrama de inferencia de LLM con decodificación especulativa

request + current context
            |
            v
  draft mechanism proposes:  [A] [B] [C] [D]
            |
            v
  target model verifies all proposed positions in one pass
            |
            +-- accepts [A] [B] [C] -> commit that prefix (and possibly one extra target token)
            |
            +-- rejects at [C] -> commit [A] [B], sample/correct at [C], then repeat

El trabajo ahorrado no es el cálculo del borrador en sí. La posible ventaja proviene de sustituir varias iteraciones de decodificación seriales del modelo objetivo por una pasada de verificación del modelo objetivo. Si la propuesta suele ser incorrecta, el objetivo aún tiene que recuperarse con frecuencia y la ganancia se reduce.

La métrica que importa: tokens aceptados por verificación del objetivo

La señal de estado más útil es el número de tokens propuestos que superan la verificación. Los equipos suelen denominarlo tasa de aceptación o longitud aceptada. Realiza un seguimiento de ambas:

Métrica	Lo que indica	Por qué puede ser engañosa por sí sola
Tasa de aceptación	Qué proporción de tokens propuestos acepta el objetivo	No incluye el coste del borrador ni el coste de verificación del objetivo.
Longitud media aceptada	Cuántos tokens de borrador confirmados se obtienen por ronda	Los promedios pueden ocultar solicitudes de cola larga y distintos modos de muestreo.
Latencia entre tokens (ITL)	Tiempo entre tokens transmitidos en streaming	Esta suele ser la métrica de decodificación visible para el usuario.
Tokens de salida agregados/segundo	Capacidad de servicio útil entre solicitudes simultáneas	Puede mejorar mientras un usuario interactivo con bajo QPS percibe poco beneficio, o al revés.
Memoria de GPU y número de solicitudes activas	Si el proponente desplaza la caché KV o la concurrencia	Una solicitud individual más rápida puede ser una configuración peor a nivel de flota.

Para una prueba A/B justa, mantén constantes la revisión del modelo, el tokenizador, la cuantización, la longitud máxima de salida, la mezcla de prompts, los parámetros de muestreo, el hardware y la política de concurrencia. Compara la latencia de extremo a extremo, el tiempo hasta el primer token, el ITL p50/p95, los tokens de salida/segundo y la tasa de errores. Un único número de «tokens/segundo» sin la forma de su carga no es suficiente para elegir una configuración.

Dónde ayuda la decodificación especulativa y dónde no

El servicio de LLM con decodificación especulativa suele ser más atractivo cuando la decodificación está limitada por memoria y cada solicitud tiene suficiente longitud de generación para que importen las rondas de verificación repetidas. La guía actual de vLLM lo plantea específicamente como una forma de reducir la latencia entre tokens para cargas de trabajo limitadas por memoria con QPS de medio a bajo, y señala que las ganancias reales dependen de la familia de modelos, el tráfico, el hardware y la configuración de muestreo. Consulta la guía de decodificación especulativa de vLLM.

Es menos convincente en estos casos:

El prefill domina la solicitud. Los prompts largos con respuestas cortas dedican la mayor parte del tiempo a ingerir contexto. El borrador modifica el trabajo de decodificación, no el trabajo de prefill del prompt que ya domina la latencia de extremo a extremo.
La aceptación es baja. La decodificación creativa, un modelo de borrador no compatible o una configuración que produce continuaciones candidatas débiles pueden provocar fallos de verificación repetidos.
Tu servidor ya está saturado por lotes. Con alta concurrencia, la GPU objetivo puede estar ocupada eficientemente por el programador normal. Añadir un generador de borradores puede consumir memoria o capacidad de cómputo que, de otro modo, atendería más solicitudes.
El margen de la caché KV es limitado. Un modelo de borrador adicional o el estado del proponente pueden reducir el número de secuencias activas antes de que comiencen las expulsiones o las colas. Revisa los requisitos de memoria de GPU para LLM antes de interpretar una aceleración de una sola solicitud como una ganancia para la flota.
El modelo objetivo no es compatible con el proponente elegido. Los métodos basados en modelos requieren artefactos, tokenización y soporte de servicio compatibles; nunca supongas que un modelo pequeño es un modelo de borrador válido solo porque es más barato.

Por tanto, la pregunta correcta no es «¿Puede la decodificación especulativa hacer que este modelo sea más rápido?». Es «¿Qué restricción de nivel de servicio mejora bajo nuestra distribución de tráfico?»

Modelos de borrador, EAGLE y Medusa: tres formas de proponer tokens

Modelo de borrador independiente

El diseño clásico combina un modelo de borrador rápido con un modelo objetivo más grande. El borrador propone k tokens; el objetivo los verifica. Esto puede ser conceptualmente simple, pero añade otro artefacto de modelo, huella de memoria, trabajo de compatibilidad y una superficie operativa que versionar y supervisar.

Úsalo cuando dispongas de un proponente de baja latencia y compatibilidad demostrable, y de suficiente capacidad de GPU para preservar la concurrencia del servicio objetivo. Empieza con un conjunto pequeño de longitudes especulativas, en lugar de asumir que una propuesta más profunda siempre es mejor.

LLM de decodificación especulativa EAGLE

EAGLE es un enfoque basado en modelos que genera borradores a nivel de características en lugar de utilizar únicamente una ruta de propuesta convencional de modelo pequeño de tokens. El artículo describe el condicionamiento de su predicción de características con una secuencia de tokens un paso adelantada para abordar la incertidumbre a nivel de características. En las configuraciones probadas en el artículo, informa de mejoras de latencia y rendimiento mientras preserva la distribución del texto generado; es evidencia útil del potencial del método, no una previsión de capacidad para otro modelo o flota de GPU. Lee el artículo de EAGLE.

Para los operadores, la implicación es sencilla: EAGLE puede resultar atractivo cuando hay artefactos compatibles disponibles para la familia objetivo, pero no es un interruptor genérico para cada checkpoint. Valida la combinación exacta de objetivo/proponente y la versión del motor de servicio antes de promoverla.

LLM de decodificación especulativa Medusa

Medusa incorpora múltiples cabezales de decodificación en un modelo base y utiliza atención basada en árboles para crear y verificar varias continuaciones candidatas. Esto evita mantener un modelo de borrador independiente completo, pero los cabezales deben entrenarse o ajustarse para el modelo base. El artículo de Medusa distingue una ruta con modelo base congelado del ajuste fino conjunto e informa aceleraciones de referencia para esas configuraciones experimentales. Lee el artículo de Medusa.

La compensación operativa es distinta de la de un par de modelo de borrador: potencialmente menos gestión de modelos independientes, pero un artefacto específico del modelo y un requisito de entrenamiento o integración. Trátalo como una elección de servicio del modelo, no como un truco de tiempo de ejecución.

Un plan práctico de implementación para la inferencia de GPU

1. Establece una línea base representativa

Captura al menos una muestra de solicitudes similar a producción: rangos de longitud de prompts, rangos de longitud de salida, idioma o tipo de tarea, configuraciones de temperatura/top-p, comportamiento de streaming y niveles de concurrencia. Registra la línea base por separado para el tiempo hasta el primer token y para la decodificación. Si la carga de trabajo está dominada por prompts, no dejes que una prueba de tokens de salida oculte un problema de prefill.

2. Elige una estrategia de proponente y una profundidad conservadora

Comienza con un método compatible —modelo de borrador, EAGLE, Medusa u otro proponente compatible con el motor— y una longitud de candidato pequeña. vLLM, por ejemplo, documenta configuraciones de --speculative-config como un método, un modelo proponente y num_speculative_tokens; consulta la documentación correspondiente a la versión antes de copiar cualquier configuración a producción. Para una configuración operativa más amplia, consulta la guía de implementación de vLLM. No ajustes la profundidad especulativa y el procesamiento por lotes al mismo tiempo en la primera pasada.

3. Ejecuta una matriz de carga, no una sola prueba

Prueba la misma muestra de tráfico con concurrencia baja, media y similar al pico. Para cada punto, compara:

Latencia de extremo a extremo de referencia frente a especulativa.
Latencia entre tokens p50 y p95 para solicitudes de streaming.
Tokens de salida agregados/segundo y solicitudes completadas/segundo.
Longitud aceptada, frecuencia de rechazo y latencia del proponente.
Memoria de GPU, presión de la caché KV, retraso en cola y tasa de errores/tiempos de espera.

Si es posible, divide los resultados por rango de prompt y rango de salida. Una configuración que ayuda con completados largos de código puede no ayudar con respuestas breves de chat, y un buen resultado sin conexión puede degradarse después de incluir las colas.

4. Establece protecciones antes del canario

Define umbrales de reversión antes de que el tráfico perciba el cambio: por ejemplo, una regresión en el ITL p95, una caída de solicitudes completadas/segundo con carga máxima, un aumento de eventos de falta de memoria o un colapso persistente de la tasa de aceptación. Enruta solo una porción elegible al principio y conserva una ruta de referencia para una comparación rápida.

5. Sigue midiendo después del lanzamiento

La aceptación cambia con las actualizaciones del modelo, las distribuciones de prompts, los formatos de uso de herramientas y los valores predeterminados de muestreo. Vuelve a ejecutar la comparación después de cualquier cambio sustancial en el modelo objetivo, tokenizador, cuantización, GPU, motor de servicio o perfil de tráfico.

Un punto de partida mínimo de vLLM

Para un motor de servicio que lo admita, la configuración debe indicar el método del proponente en lugar de ocultarlo en un valor predeterminado opaco. La documentación actual de vLLM usa una estructura como esta para un modelo de borrador independiente:

vllm serve <target-model> \
  --speculative-config '{
    "method": "draft_model",
    "model": "<compatible-draft-model>",
    "num_speculative_tokens": 5
  }'

Los marcadores de posición son deliberados. El modelo compatible, el número de tokens especulativos, la configuración de paralelismo y el presupuesto de memoria deben elegirse a partir de los artefactos y la versión del motor que hayas probado. No copies este fragmento como evidencia de que una pareja específica de objetivo/borrador es compatible.

Mejoras de rendimiento y compensaciones de un vistazo

Decisión	Posible ventaja	Coste principal o modo de fallo	Qué medir primero
Activar un modelo de borrador independiente	Menos pasos seriales de decodificación del objetivo cuando la aceptación es alta	Memoria adicional de modelo, compatibilidad y latencia de borrador	Longitud aceptada, margen de caché KV, ITL p95
Aumentar la longitud especulativa	Más tokens potenciales por verificación	Más trabajo de borrador desperdiciado cuando se rechazan tokens posteriores	ITL neto y TPS de salida agregado, no solo aceptación
Usar EAGLE	Potente ruta de propuesta basada en modelos cuando los artefactos son compatibles	Requisitos de compatibilidad de familia de modelos y motor	Compatibilidad objetivo/proponente y resultados de referencia según la forma de carga
Usar Medusa	Propuesta multicabezal sin un modelo de borrador completo independiente	Cabezales específicos del modelo y trabajo de integración/entrenamiento	Comprobaciones de calidad de salida, soporte de servicio y ruta de reversión
Activarlo con QPS pico	Posible beneficio de rendimiento en el motor/carga de trabajo adecuados	La contención del programador, la memoria o el cómputo puede eliminar la ganancia	Solicitudes completadas/seg., tiempo en cola y tasa de errores

Preguntas frecuentes

¿La decodificación especulativa cambia la respuesta del modelo objetivo?

El muestreo especulativo adecuado utiliza verificación y corrección del modelo objetivo para que el muestreo pueda preservar la distribución objetivo. La garantía depende de utilizar un algoritmo correcto y una implementación compatible. Un cambio de servicio aún puede afectar al comportamiento operativo, como la latencia, las colas o los errores, así que evalúa la calidad y la fiabilidad además de la velocidad.

¿La decodificación especulativa mejora el tiempo hasta el primer token?

Por lo general, se dirige a la fase de decodificación después de que comienza la generación. Si el procesamiento de prompts domina tus solicitudes, el tiempo hasta el primer token puede cambiar poco. Mide el prefill y la decodificación por separado.

¿Cuántos tokens especulativos debo usar?

No existe un valor óptimo universal. Prueba un rango pequeño con tu modelo, proponente, configuración de muestreo, tipo de GPU y concurrencia. Una propuesta más larga solo gana cuando se aceptan suficientes de sus tokens y su trabajo adicional no reduce la capacidad de servicio.

¿Debo usar EAGLE o Medusa?

Elige el método que tu modelo objetivo y motor de servicio admitan bien, y después evalúalo con tu carga de trabajo. EAGLE se basa en artefactos compatibles de borrador a nivel de características; Medusa se basa en múltiples cabezales asociados con un modelo base. Ninguno es automáticamente intercambiable con un modelo de borrador genérico.

Pon la decisión en contexto

La decodificación especulativa es una capa de optimización del servicio de LLM. Funciona mejor junto con una elección clara de servicio de modelos, límites de capacidad realistas y supervisión explícita. Para una comparación más amplia de motores de servicio, consulta vLLM vs SGLang: rendimiento, latencia, soporte de modelos y operaciones. Para el aspecto de capacidad de las API de producción, consulta RPM vs TPM: límites de tasa de LLM y soluciones para 429.

Si estás planificando experimentos de GPU o un nuevo entorno de inferencia, explora Flatkey Compute y comienza con un plan de referencia que informe tanto de la latencia visible para el usuario como del rendimiento a nivel de flota. La mejor configuración de LLM con decodificación especulativa es la que mejora tu métrica restringida bajo carga real y puede revertirse de forma segura cuando cambia la carga de trabajo. Esta guía de LLM con decodificación especulativa es un punto de partida para esa disciplina de medición, no un sustituto de ella.