Decodificación especulativa: cuándo acelera un LLM

Si desarrollas la aplicación, lo que interesa es saber si la respuesta se transmite más rápido con tu carga de trabajo. Si operas el servicio de inferencia, hay que comprobar si esa mejora se mantiene con solicitudes simultáneas y presión de memoria. Si contratas una API alojada, la primera cuestión es si el proveedor ofrece o siquiera documenta esta optimización.

Documentación verificada el 30 de octubre de 2026: vLLM, SGLang y NVIDIA TensorRT-LLM. Los comandos siguientes siguen su documentación vigente; son ejemplos de configuración, no resultados de pruebas de rendimiento realizadas para este artículo.

¿Qué es la decodificación especulativa?

Un mecanismo de bajo costo propone los siguientes tokens; el modelo objetivo decide cuáles pueden incorporarse a la respuesta. Un token es una unidad de texto que procesa el modelo, a menudo una parte de una palabra. El modelo objetivo es aquel cuyo comportamiento se quiere conservar.

Imagina a un asistente que redacta una frase para un editor meticuloso. El asistente puede adelantarse, pero nada llega al lector sin la revisión del editor. La ventaja es que el modelo objetivo puede evaluar en conjunto la continuación propuesta, sin esperar un paso de generación independiente por cada token nuevo. NVIDIA describe el proceso como un mecanismo de generación de borradores seguido de una pasada de verificación del modelo objetivo. Documentación de TensorRT-LLM

En la imagen, las letras representan identificadores de tokens. El modelo que genera el borrador propone A B C. En la decodificación voraz, que selecciona el siguiente token de mayor probabilidad, supongamos que el modelo objetivo coincide en A B, pero prefiere X a continuación. La respuesta confirmada pasa a ser A B X. También se descarta cualquier continuación del borrador posterior al token rechazado C, porque dependía del prefijo incorrecto.

Cuando la salida se genera por muestreo, la aceptación requiere algo más que comprobar si ambos modelos eligieron la misma palabra. El muestreo especulativo estándar utiliza las probabilidades del modelo objetivo y del mecanismo de propuesta, con una distribución de corrección cuando se rechaza una propuesta. Esa corrección es lo que preserva la distribución de probabilidad del modelo objetivo. El algoritmo original también permite añadir un token del modelo objetivo cuando se acepta todo el borrador. Artículo original de Leviathan, Kalman y Matias

Por tanto, el modelo más pequeño aporta propuestas; no sustituye al modelo objetivo para responder. Con un verificador exacto, un mal generador de borradores debería perjudicar la velocidad, sin pasar a decidir la respuesta de forma silenciosa.

¿Qué significa «sin usar un modelo peor»?

La garantía que hay que exigir es que se preserve la distribución del modelo objetivo. Eso no promete la misma respuesta aleatoria en cada ejecución, ni elimina los errores del modelo objetivo, ni mejora su razonamiento. vLLM documenta efectos numéricos y del procesamiento por lotes que pueden producir diferencias incluso cuando el algoritmo es sin pérdidas. Garantías de vLLM sobre la ausencia de pérdidas

Al evaluar la especulación, mantén fijos los pesos del modelo objetivo, la cuantización y los ajustes de muestreo. Si cambias varias cosas a la vez, no podrás atribuir una diferencia de calidad a un cambio concreto.

Principales variantes y documentación de cada motor

Elige un mecanismo de propuesta compatible con tu modelo objetivo concreto y con la versión del motor de inferencia que utilizas. El proceso básico sigue siendo proponer y verificar; lo que cambia es de dónde sale el borrador.

Un modelo independiente para generar el borrador

Un modelo de lenguaje más pequeño genera tokens candidatos con sus propios pesos. Es la configuración más intuitiva, pero obliga a cargar y operar otro modelo. La compatibilidad y el grado de coincidencia importan: que sea «más pequeño» no significa automáticamente que sea «útil». vLLM normalmente requiere un vocabulario compartido, aunque también documenta una opción limitada para vocabularios distintos. Modelos de borrador en vLLM

Si el servicio ya está cerca del límite de memoria, añadir un segundo modelo puede ser un mal primer paso. En cambio, para un servicio sensible a la latencia, con capacidad disponible y un modelo de borrador bien emparejado, es un experimento controlado razonable.

Decodificación especulativa con EAGLE

EAGLE, siglas de Extrapolation Algorithm for Greater Language-model Efficiency, utiliza un generador auxiliar de borradores entrenado y asociado al modelo objetivo. Este componente se apoya en representaciones internas del modelo objetivo para proponer la continuación. Estos componentes entrenados, a menudo llamados cabezas, requieren un checkpoint compatible. vLLM distingue entre las configuraciones eagle y eagle3. Documentación de EAGLE en vLLM

Trata el modelo objetivo y su checkpoint de EAGLE como una pareja compatible. No elijas un checkpoint solo porque su nombre incluya la misma familia de modelos. En el registro del despliegue deben constar la familia correcta, la revisión del modelo y la implementación del servicio de inferencia.

Decodificación especulativa con MTP

La predicción multitoken, o MTP por sus siglas en inglés, aprovecha la capacidad nativa de un modelo para proponer tokens futuros. vLLM la documenta como una opción para familias de modelos compatibles y ofrece un ejemplo de arranque que no requiere el identificador de un modelo de borrador independiente. Un modelo que no tenga esa capacidad no la adquiere por establecer method en mtp. Documentación de MTP en vLLM

Si ya utilizas un checkpoint compatible con MTP, prueba primero la configuración documentada antes de añadir un modelo de borrador independiente sin relación con él. Así reduces las decisiones de compatibilidad, aunque todavía tendrás que medir el rendimiento.

La tabla siguiente enlaza directamente a la documentación de los motores. Sirve para localizar las opciones de configuración; no implica que todos los modelos funcionen en todas las combinaciones.

El nombre de un algoritmo y la forma de ejecutarlo son cosas distintas. Las notas de la versión actual de TensorRT-LLM eliminan la vía de ejecución con un motor de borrador separado y conservan las implementaciones que integran el generador de borradores como un submódulo dentro del modelo. Eso no significa que haya desaparecido el enfoque de borrador y modelo objetivo. Significa que unas instrucciones de despliegue antiguas pueden describir una vía de ejecución que la versión instalada ya no ofrece. Notas de versiones de TensorRT-LLM

Cuándo acelera la generación y cuándo no

La especulación solo aporta una ventaja si la salida útil llega antes, contando todo el trabajo adicional. La tasa de aceptación importa, pero es solo una parte del cálculo.

La aceptación debe compensar el costo del borrador

La tasa de aceptación se calcula dividiendo los tokens aceptados del borrador entre los tokens propuestos. Por sí sola no dice nada sobre el costo de generar esas propuestas. Un modelo de borrador más lento puede coincidir más a menudo con el objetivo y, aun así, ralentizar el servicio.

Una regla útil para decidir es:

(tiempo de generación del borrador + tiempo de verificación + tiempo de coordinación) ÷ tokens de salida confirmados < tiempo de decodificación por token sin especulación

Es una comprobación de costos, no una predicción de rendimiento. Mide la ronda completa en tu hardware. Los «tokens de salida confirmados» incluyen los tokens de corrección o adicionales que aporta el modelo objetivo, además de las propuestas aceptadas del borrador.

En un asistente de edición de código, la repetición de estructuras locales puede hacer útiles las propuestas. En uno de soporte, el borrador puede acertar con las fórmulas de cortesía que enlazan las frases, pero fallar en las respuestas específicas sobre el producto. Mide ambas cargas de trabajo por separado antes de usar una tasa media de aceptación para decidir un despliegue.

Los borradores más largos también generan más trabajo que puede terminar descartado. Aumenta la profundidad del borrador solo mientras la salida confirmada adicional compense el trabajo de generación, verificación y el consumo extra de memoria. Fireworks hace la misma distinción operativa en sus recomendaciones de ajuste: la aceptación, por sí sola, no demuestra una mejora de velocidad. Guía de pruebas de rendimiento de Fireworks

El tamaño del lote cambia el margen de mejora

Empieza con cargas interactivas limitadas por la decodificación y después prueba con la concurrencia máxima. vLLM orienta expresamente la especulación a cargas limitadas por la memoria con tasas de solicitudes medias o bajas. En un paso limitado por la memoria, mover los datos del modelo frena más el avance que la capacidad de cálculo disponible. Recomendaciones de vLLM según la carga de trabajo

La verificación en paralelo puede aprovechar capacidad de cálculo que de otro modo quedaría infrautilizada. Sin embargo, un servidor muy ocupado puede estar destinando ya esa capacidad a otras solicitudes. Por eso, reducir la latencia de un chat aislado no demuestra que un endpoint con mucho tráfico vaya a aumentar su capacidad total de procesamiento.

El procesamiento continuo por lotes cambia qué solicitudes comparten cada paso de generación. Evalúa la especulación con ese planificador e incluye el patrón de llegada de solicitudes que atiendes en la práctica. Un endpoint de desarrollo con poco tráfico y uno de producción con una cola de espera son experimentos distintos.

No fijes un límite universal para el tamaño del lote. El punto a partir del cual deja de compensar depende del modelo, el hardware, el método de generación del borrador y el planificador. Evalúa tanto la latencia como la capacidad: a qué velocidad se transmite una respuesta y cuánto tráfico sostiene el servicio sin superar su objetivo de latencia.

La memoria puede anular la mejora

El generador de borradores compite por un presupuesto limitado de memoria de GPU. Los pesos independientes, el estado del borrador y las áreas de trabajo de verificación pueden ocupar espacio que de otro modo se dedicaría a atender solicitudes. La caché KV, que almacena el estado de atención de los tokens existentes, forma parte de ese presupuesto.

Piensa en un asistente de documentos que responde rápido a prompts cortos, pero trabaja cerca de su límite de capacidad con documentos largos. Que la especulación funcione bien en una prueba con prompts cortos no demuestra que el borrador siga cabiendo junto a la caché de producción. Prueba el contexto más largo que vayas a admitir, con una concurrencia realista.

Las recomendaciones de SGLang para los errores de memoria insuficiente incluyen expresamente reducir la reserva de memoria, los tamaños de captura de grafos, el tamaño del árbol de borradores y las solicitudes simultáneas. Si hay que reducir la concurrencia para que la especulación quepa en memoria, existe un costo que medir; la optimización no sale gratis. Resolución de problemas de memoria en SGLang

Acelera la parte que hace esperar al usuario

Una respuesta lenta puede deberse a una espera larga antes de que aparezca el texto, a una transmisión lenta una vez iniciada o a demoras ajenas al modelo. La especulación se centra en la generación. Si tu aplicación dedica la mayor parte del tiempo a buscar documentos o esperar una llamada a una herramienta, acelerar el bucle de decodificación puede cambiar muy poco la experiencia.

Mide por separado la espera en cola, el procesamiento inicial del prompt y la decodificación. La fase de prefill procesa el prompt; la de decode genera la continuación. La guía de inferencia LLM explica esas etapas, y la guía de tokens por segundo distingue la velocidad de salida de la capacidad total de procesamiento de solicitudes.

Cómo activar la decodificación especulativa

Activa la especulación en el proceso que sirve el modelo y compáralo con el mismo modelo objetivo funcionando sin ella. Estos ejemplos presuponen que el motor ya está instalado, que el hardware tiene capacidad para alojar los modelos elegidos y que tienes acceso a sus pesos. Usa la documentación correspondiente a la versión que despliegas; una página latest no garantiza la compatibilidad con un contenedor antiguo.

Decodificación especulativa en vLLM

vLLM utiliza un objeto JSON que se pasa mediante --speculative-config. Este ejemplo con un modelo de borrador independiente usa el modelo objetivo, el generador de borradores y la longitud del borrador que aparecen en su documentación para servir modelos en línea:

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

El 5 es la cantidad de propuestas del ejemplo, no un valor óptimo recomendado. La documentación marca como obsoletas las antiguas opciones independientes --speculative-model y --num-speculative-tokens. Ejemplos de arranque de vLLM

Como ejemplo de MTP nativo, el checkpoint base de Xiaomi MiMo documentado se ejecuta así:

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

Este ejemplo utiliza otro modelo; no ofrece un generador de borradores que se pueda conectar directamente al modelo objetivo Qwen anterior. La condición determinante es la compatibilidad del checkpoint: MTP debe existir en el modelo y tu motor debe admitirlo. Ejemplo de arranque con MTP en vLLM

Decodificación especulativa en SGLang

El ejemplo actual de SGLang para su planificador con solapamiento incluye una pareja Qwen con un modelo objetivo y un generador de borradores independiente:

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

La vía actual con solapamiento exige --speculative-eagle-topk 1. Un árbol más ancho copiado de otro ejemplo es incompatible con esa vía. Mantén juntos los ajustes documentados del planificador y de la generación de borradores. Ejemplo del planificador con solapamiento de SGLang

Para cargas de trabajo cambiantes, SGLang documenta por separado la especulación adaptativa en configuraciones EAGLE compatibles. Revisa los requisitos de esa función antes de dar por hecho que la profundidad del borrador se ajustará sola. Especulación adaptativa en SGLang

Configuración de TensorRT-LLM

TensorRT-LLM acepta los ajustes de especulación mediante un archivo YAML. Guarda lo siguiente como speculative.yaml:

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

La longitud del borrador y el checkpoint proceden del ejemplo de configuración especulativa de NVIDIA. Inicia el modelo objetivo correspondiente con la interfaz de línea de comandos del servidor documentada:

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

Comprueba tanto la generación del checkpoint como el nombre de la configuración. NVIDIA documenta Eagle como un alias de compatibilidad de Eagle3, pero las generaciones anteriores de checkpoints EAGLE siguen siendo incompatibles con esa vía. Restricción de checkpoints en TensorRT-LLM

Si además del método especulativo estás eligiendo un motor de inferencia, consulta la comparativa entre vLLM y SGLang. Un buen generador de borradores no compensa la ausencia de otra función que tu aplicación necesite.

¿También se beneficia un equipo que usa una API alojada?

Sí, cuando el proveedor lo documenta y lo habilita; el control disponible depende del servicio. No necesitas tener tus propias GPU para beneficiarte de una optimización del servicio de inferencia del proveedor.

Fireworks AI, proveedor de inferencia alojada, documenta generadores de borradores predeterminados para la mayoría de los modelos compatibles en despliegues dedicados. Un modelo sin generador predeterminado se ejecuta sin especulación basada en modelos, salvo que se configure de otro modo. Fireworks gestiona la configuración del servicio serverless, así que las opciones de los despliegues dedicados no demuestran que todos los endpoints serverless utilicen especulación. Documentación de despliegues de Fireworks

Para quien necesita regenerar un archivo con pequeños cambios, Fireworks también documenta Predicted Outputs: se proporciona el texto esperado en el campo prediction de la solicitud. Ese texto conocido aporta otra fuente de propuestas y puede funcionar junto a la especulación basada en modelos. Resulta útil cuando ya se conoce gran parte de la respuesta, en lugar de plantear una pregunta abierta. Predicted Outputs de Fireworks

Si utilizas otro endpoint alojado, exige su propia documentación antes de atribuirle esta ventaja o añadir un ajuste. La compatibilidad de la API, por sí sola, no indica qué modelo de borrador se ejecuta detrás del endpoint, ni siquiera si existe alguno.

Qué promesas conviene poner en duda

La decodificación especulativa mejora el servicio de inferencia bajo ciertas condiciones; no multiplica la velocidad de forma universal. Aquí no se promete una aceleración numérica porque un resultado obtenido con otro modelo objetivo, otro generador de borradores, otra GPU y otra mezcla de tráfico no describe tu servicio.

«Más tokens aceptados significa una aplicación más rápida» deja fuera el costo del borrador, las colas y todo lo que hace la aplicación alrededor de la generación. «Un borrador más largo es mejor» ignora el trabajo que se descarta tras un rechazo. «Sin pérdidas significa cadenas de texto idénticas» confunde una distribución de muestreo con un resultado aleatorio concreto.

El error más costoso es convertir un resultado obtenido en un endpoint con poco tráfico en una afirmación sobre la capacidad en producción. Un asistente de programación puede parecer más rápido a quien lo desarrolla mientras el endpoint compartido admite menos sesiones simultáneas. Decide si buscas optimizar la latencia de respuesta, la capacidad de procesamiento sostenida o ambas, y deja esa decisión explícita en los criterios para pasar a producción.

Qué puedes poner a prueba la próxima semana

Quien desarrolla la aplicación debería probar un mecanismo de propuesta compatible cuando la decodificación sea el cuello de botella. Quien opera el servicio debería exigir una mejora con carga de producción. Los equipos que usan una API alojada deberían empezar por los controles que su proveedor documenta.

Si la mayor parte de la espera ocurre antes de la generación, resuelve primero ese cuello de botella. Si el borrador no cabe en memoria o no existe un checkpoint compatible, mantén el modelo objetivo funcionando de la forma habitual. Que una función esté disponible no demuestra que tu despliegue la necesite.

Preguntas frecuentes al implementar la técnica

Suscríbete al boletín para recibir guías prácticas sobre cómo crear y operar sistemas de IA.