Decodificación especulativa: Inferencia de LLM 20-50% más rápida

Un modelo de 70B genera un token por pasada directa (forward pass), y cada recarga los pesos desde la VRAM, calcula la atención en todo el contexto y sincroniza la memoria. Entre tokens, la GPU se queda inactiva mientras espera a que se resuelvan las dependencias secuenciales.

En una H100, un modelo de 70B produce un token cada 30-50 ms. La GPU tiene suficiente capacidad de cómputo para procesar múltiples tokens en paralelo, pero la dependencia secuencial lo impide: cada token depende del anterior, lo que provoca una pausa en el flujo de trabajo.

La decodulación especulativa rompe ese cuello de botella permitiéndote generar múltiples tokens en el tiempo que normalmente se tarda en generar uno, sin alterar la distribución de salida. Los tokens que obtienes son estadísticamente idénticos a los que obtendrías con la decodulación autorregresiva estándar; la única diferencia es la velocidad a la que los obtienes.

Esta guía cubre la mecánica, las variantes disponibles en 2026, las compensaciones en la tasa de aceptación y la configuración práctica en llama.cpp, vLLM, SGLang y TensorRT-LLM.

Cómo funciona la decodulación autorregresiva (y por qué es lenta)

Antes de poder entender la decodulación especulativa, necesitas comprender la restricción autorregresiva que esta técnica rodea. La generación autorregresiva estándar procesa los tokens secuencialmente:

1. Ejecuta una pasada directa a través del modelo con el contexto actual.
2. Muestrea el siguiente token de la distribución de salida.
3. Anexa el token al contexto.
4. Repite.

Cada paso requiere una pasada directa completa: carga los pesos desde la VRAM, calcula la atención en todo el contexto y produce un único token. Para un modelo con 70B parámetros, esto toma aproximadamente 30-50 ms por token en una H100. La GPU tiene capacidad de cómputo de sobra —podría procesar más trabajo en paralelo— pero la dependencia secuencial lo impide.

La brecha entre cómputo y VRAM

Las GPUs modernas tienen más FLOPs de los que necesitan para la generación de un solo token, por lo que el verdadero cuello de botella es el ancho de banda de memoria: los pesos deben transmitirse desde la VRAM a las unidades de cómputo en cada pasada directa. Al generar un token a la vez, la GPU pasa la mayor parte del tiempo esperando transferencias de memoria en lugar de realizar cómputos útiles.

La decodulación especulativa aborda esto proporcionándole a la GPU más trabajo por transferencia de memoria. En lugar de un token por pasada directa, genera K tokens por pasada directa, amortizando el costo de memoria sobre múltiples salidas.

El mecanismo de Borrador y Verificación

La decodulación especulativa funciona en ciclos repetidos de borrador y verificación. Un mecanismo de borrador rápido propone K tokens candidatos —desde un pequeño modelo de borrador, una búsqueda de n-gramos o un cabezal de predicción adjunto al modelo objetivo— y el modelo objetivo verifica los K en una sola pasada directa. La fase de borrador es barata, típicamente el 5-20% del tiempo de la pasada directa del modelo objetivo, mientras que la verificación compara cada token borrado contra lo que el objetivo habría generado, aceptando el prefijo coincidente más largo y re-muestreando desde el primer rechazo en adelante.

Verificar K tokens cuesta aproximadamente lo mismo que generar un token de manera autorregresiva, por lo que cuando el borrador es correcto, obtienes K tokens por el precio de un paso de verificación.

Un ejemplo concreto

Supongamos que el modelo de borrador propone 5 tokens: ["I", " like", " cooking", " and", " traveling"]. El modelo objetivo los verifica en una sola pasada directa:

El objetivo acepta los tokens 1 y 2, luego genera " playing" para el token 3, produciendo tres tokens en un ciclo en lugar de tres pasadas directas separadas. Si el borrador hubiera sido correcto hasta el token 5, obtendrías cinco tokens por el costo de una verificación: una aceleración de 5x solo en ese ciclo.

El cuello de botella de la verificación

En la práctica, la verificación domina el tiempo de ejecución: entre el 42-95% del ciclo, dependiendo del método y el tamaño del modelo. La pasada directa del modelo objetivo es el cuello de botella, y los tokens rechazados representan cómputo desperdiciado.

Por eso la tasa de aceptación es tan importante. Cada token rechazado después del primero es trabajo de verificación desperdiciado. Los mejores métodos de decodulación especulativa maximizan los tokens aceptados esperados por ciclo, no solo la tasa de aceptación bruta.

La garantía matemática

Una de las propiedades más importantes de la decodulación especulativa es que produce tokens de la misma distribución exacta que el muestreo autorregresivo estándar del modelo objetivo. El paso de verificación usa muestreo por rechazo: cuando el borrador propone el token x, el modelo objetivo calcula su propia probabilidad p(x) y el borrador calcula p_borrador(x). La probabilidad de aceptación es:

min(1, p(x) / p_borrador(x))

Cuando el objetivo está de acuerdo (p(x) ≥ p_borrador(x)), el token siempre se acepta. Cuando el objetivo no está de acuerdo, el token se acepta con una probabilidad proporcional a la relación, y los tokens rechazados se re-muestrean de una distribución residual:

r(x) = max(0, p(x) - p_borrador(x)) / Σ max(0, p(y) - p_borrador(y))

Este procedimiento garantiza que la secuencia de salida siga exactamente la distribución del modelo objetivo, lo cual es por qué la decodulación especulativa es sin pérdidas. El modelo de borrador influye en la velocidad, no en la calidad: los tokens que obtienes son estadísticamente indistinguibles de la decodulación estándar, con la misma perplejidad y distribución. La única diferencia es la latencia.

Estrategias de Modelos de Borrador

El mecanismo de borrador es la variable que más importa. Diferentes enfoques tienen diferentes compensaciones entre complejidad de configuración, tasa de aceptación y aceleración.

Modelos de Borrador Independientes

El enfoque más simple carga un modelo más pequeño junto al objetivo: típicamente un modelo de 1B-3B actuando como borrador para un objetivo de 7B-70B.

Ventajas:

• Conceptualmente sencillo
• Funciona con cualquier modelo objetivo
• El modelo de borrador puede ajustarse para coincidir con la distribución del objetivo

Desventajas:

• Requiere cargar un segundo modelo en la VRAM (1-4 GB dependiendo del tamaño)
• La calidad del modelo de borrador determina directamente la tasa de aceptación
• Los borradores cruzados entre familias (por ejemplo, Qwen borrando para Llama) típicamente funcionan mal

Regla general: Usa modelos de la misma familia. Gemma 2 2B funciona bien como borrador para Gemma 2 27B. Llama 3.2 1B funciona bien como borrador para Llama 3.1 70B. Los borradores cruzados entre familias tienden a tener tasas de aceptación bajas porque las distribuciones de tokens divergen.

Encontrando Modelos de Borrador Compatibles

No todos los modelos pequeños funcionan como modelos de borrador para un objetivo dado. El factor crítico es la alineación de la distribución: qué tan estrechamente coinciden las probabilidades de salida del modelo de borrador con las del objetivo.

La regla de oro: si la tasa de aceptación del modelo de borrador cae por debajo del 50%, la decodulación especulativa puede realmente ralentizarte. La sobrecarga de ejecutar el modelo de borrador más la verificación supera el beneficio cuando la mayoría de las propuestas son rechazadas.

EAGLE y EAGLE-3: Cabezales de Predicción

EAGLE (Estimación de Modelos de Lenguaje Guiada por Arquitectura Eficiente) elimina la necesidad de un modelo de borrador separado. En cambio, adjunta cabezales de predicción autorregresivos ligeros a las capas internas del modelo objetivo.

Cómo Funciona EAGLE

EAGLE entrena cabezales de predicción que toman estados ocultos de las capas intermedias del modelo objetivo y predicen tokens futuros. Durante la inferencia:

1. El modelo objetivo ejecuta una pasada directa a través de sus capas.
2. En cada capa, el cabezal EAGLE lee el estado oculto y propone tokens para posiciones futuras.
3. Múltiples cabezales operan en paralelo, cada uno prediciendo un paso de tiempo futuro diferente.
4. El modelo objetivo verifica todas las propuestas en una sola pasada.

La ventaja: los cabezales EAGLE se entrenan específicamente para coincidir con la distribución del modelo objetivo. Ven las representaciones internas del objetivo directamente, lo que les da una alineación mucho mejor que un modelo de borrador independiente.

Mejoras de EAGLE-3

EAGLE-3 (2025) refina el enfoque con tres cambios clave:

1. Selección de capas: En lugar de adjuntar cabezales a cada capa, EAGLE-3 usa optimización bayesiana para seleccionar la capa de salida óptima, reduciendo la sobrecarga.
2. Predicción de múltiples tokens: Cada cabezal predice múltiples tokens simultáneamente, aumentando la profundidad del borrador sin un costo de cómputo proporcional.
3. Eficiencia de entrenamiento: EAGLE-3 se entrena con los propios datos de generación del modelo objetivo, mejorando las tasas de aceptación en cargas de trabajo dentro de la distribución.

Tasas de aceptación: EAGLE-3 típicamente logra tasas de aceptación del 60-80% en cargas de trabajo dentro de la distribución, comparado con el 40-60% para modelos de borrador independientes. En cargas de trabajo de generación de código con alta repetición, la aceptación puede exceder el 85%.

Configuración: EAGLE-3 requiere cabezales preentrenados para tu modelo objetivo. NVIDIA proporciona cabezales EAGLE-3 para varios modelos populares a través de TensorRT-LLM y la colección de Módulos de Decodulación Especulativa en HuggingFace. Existen implementaciones de terceros para vLLM y SGLang.

P-EAGLE: Borrado Paralelo (Marzo 2026)

La principal limitación de EAGLE-3 es el borrado autorregresivo: cada token de borrado depende del anterior, por lo que generar K tokens de borrado requiere K pasadas directas secuenciales a través del cabezal de borrado, y la sobrecarga de borrado crece linealmente con K. P-EAGLE elimina este techo generando todos los K tokens de borrado en una sola pasada directa a través de un borrador ligero de 4 capas entrenado para predecir hasta 10 tokens en paralelo.

El resultado: P-EAGLE ofrece hasta una aceleración de 1.69x sobre EAGLE-3 vanilla en cargas de trabajo reales en NVIDIA B200. La ventaja se ensancha en valores K más altos: donde el borrado secuencial de EAGLE-3 se convierte en un cuello de botella, el borrado paralelo de P-EAGLE no incurre en costo adicional.

Configuración en vLLM: Descarga un cabezal P-EAGLE preentrenado desde HuggingFace, establece "parallel_drafting": true en tu configuración de vLLM y usa la misma bandera --speculative-model; vLLM se encarga del resto. P-EAGLE es el estado del arte actual para la decodulación especulativa basada en EAGLE, y si estás desplegando EAGLE en 2026, P-EAGLE es la variante a usar.

Decodulación Especulativa de n-gramos

La decodulación especulativa de n-gramos reemplaza un borrador neural con emparejamiento de patrones contra el historial del prompt. El algoritmo busca secuencias de n-gramos repetidos en el contexto, y cuando la secuencia de tokens actual coincide con un patrón visto previamente, propone los tokens que siguieron a ese patrón anteriormente: por ejemplo, si el modelo ya generó def calculate_total(items): y encuentra def calculate_total( nuevamente, sabe que los siguientes tokens probablemente serán items): basándose en la ocurrencia anterior.

Las variantes del mapa de n-gramos (ngram-map-k, ngram-map-k4v) usan tablas hash para búsquedas más rápidas en lugar de escaneo lineal, con la clave hash como el n-grama actual de tamaño N y el valor como la secuencia de tokens que siguió.

Ventajas:

• Cero sobrecarga de VRAM: no hay modelo adicional para cargar (~16 MB para la tabla hash)
• Extremadamente rápido para cargas de trabajo repetitivas (edición de código, refactorización, generación de plantillas)
• Las tasas de aceptación pueden alcanzar el 90%+ en cargas de trabajo con alta autosimilitud

Desventajas:

• Inútil para generación novel: si el patrón no ha aparecido antes, n-gram no tiene nada que proponer
• La tasa de aceptación cae a cerca de cero en cargas de trabajo creativas o diversas
• Profundidad de borrado limitada (típicamente 2-4 tokens por coincidencia)

Mejor para: Refactorización de código, llenado de plantillas, documentación repetitiva y cualquier carga de trabajo donde el modelo revisite patrones similares. Peor para: escritura creativa, chat abierto y tareas de razonamiento.

Ajuste de Parámetros

Los parámetros de n-gramos importan más de lo que esperas. Los valores por defecto funcionan para código, pero las cargas de trabajo de texto necesitan ajuste:

Para cargas de trabajo de texto, reduce size-n a 8-10 y aumenta min-hits a 2. Esto intercambia frecuencia de coincidencia por tasas de aceptación más altas por coincidencia.

Decodulación Autoespeculativa

La decodulación autoespeculativa (también llamada LayerSkip o autoespeculación) usa el propio cómputo parcial del modelo como borrado, por lo que no se necesita un modelo separado.

Cómo Funciona

En lugar de ejecutar el modelo completo para cada token, la decodulación autoespeculativa ejecuta una versión truncada —saltando algunas capas de transformador— para generar tokens de borrado baratos, y el modelo completo luego verifica las propuestas.

Por ejemplo, un modelo de 32 capas podría ejecutarse con solo 16 capas para el borrado, luego verificar con las 32 capas. La pasada directa truncada es más rápida porque procesa menos capas, y los tokens de borrado se benefician de ver las mismas capas iniciales que el objetivo.

Ventajas:

• No hay pesos de modelo adicionales para cargar
• Naturalmente alineado con la distribución objetivo (misma arquitectura, capas parciales)
• Funciona bien para modelos con redundancia significativa en capas más profundas

Desventajas:

• Requiere modificar el motor de inferencia para soportar pasadas directas parciales
• Complicaciones de caché KV: el borrado usa un caché KV parcial que debe reconciliarse con el caché del modelo completo
• Las tasas de aceptación son típicamente más bajas que EAGLE o modelos de borrador bien ajustados

Implementación en llama.cpp: El PR #18471 introdujo la decodulación autoespeculativa usando el historial de contexto como borrado. El modelo reutiliza tokens de su propio historial de generación para proponer continuaciones, particularmente efectivo para cargas de trabajo de codificación donde los patrones se repiten dentro de la misma ventana de contexto.

MTP (Predicción de Múltiples Tokens)

MTP es una forma especializada de decodulación especulativa construida directamente en ciertos checkpoints de modelos. Qwen 3.6 incluye variantes GGUF tanto estándar como habilitadas para MTP.

Cómo difiere: Los cabezales MTP están integrados en la arquitectura del modelo durante el entrenamiento. El modelo lleva cabezales de predicción extra que proponen múltiples tokens futuros en una sola pasada directa. No hay un modelo de borrador separado: los cabezales MTP son parte del modelo objetivo en sí.

Compensaciones:

• No hay modelo de borrador para gestionar: MTP se activa con --spec-type draft-mtp --spec-draft-n-max N
• Los cabezales MTP añaden ~1-2 GB de sobrecarga de VRAM
• Funciona mejor en arquitecturas MoE (Qwen 3.6 35B-A3B) donde el enrutamiento disperso mantiene los cabezales MTP baratos

Para benchmarks detallados sobre MTP vs decodulación estándar en Qwen 3.6 27B y 35B, ver Qwen 3.6 MTP vs Standard on 16GB GPU.

Tasas de Aceptación: Qué Significan en la Práctica

La tasa de aceptación (α) es la métrica más importante para el rendimiento de la decodulación especulativa. Determina si estás obteniendo una aceleración o pagando sobrecarga.

La Fórmula de Aceleración

Tokens aceptados esperados por pasada de verificación:

E[aceptados] = α × K

Donde K es el número de tokens de borrado propuestos por ciclo. Si α = 0.7 y K = 5, aceptas 3.5 tokens por pasada: una aceleración de 3.5x sobre la decodulación estándar (que produce 1 token por pasada).

Tasa de Aceptación por Método

Cuando la Tasa de Aceptación Cae

La tasa de aceptación no es constante a lo largo de una generación. Varía por:

• Posición del token: Los tokens tempranos tienden a tener mayor aceptación (más contexto, menos incertidumbre). Los tokens posteriores caen a medida que el modelo explora continuaciones más diversas.
• Tipo de carga de trabajo: La edición de código con patrones repetidos ve α > 80%. La escritura creativa abierta ve α < 40%.
• Temperatura: Una temperatura más alta aumenta la divergencia entre el borrador y el objetivo, reduciendo la aceptación. La decodulación especulativa funciona mejor a baja temperatura (0.0-0.7).

Umbral crítico: Si tu tasa de aceptación efectiva (α × K) cae por debajo de 1.0, la decodulación especulativa es más lenta que la decodulación estándar. La sobrecarga del borrado más el tiempo de verificación excede el costo de un solo paso autorregresivo.

Decodulación Especulativa en Producción: Qué Realmente Sucede

Los papers de investigación reportan aceleraciones de 2-4x, pero los benchmarks de producción cuentan una historia más matizada: las aceleraciones se reducen con el tamaño de lote, la verificación domina el tiempo de ciclo y ningún método único gana en cada carga de trabajo.

Hallazgos de SpecDecode-Bench (2026)

Una evaluación sistemática de cinco variantes de SD (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) en vLLM a través de cuatro modelos y seis cargas de trabajo reveló:

1. SD funciona, pero las aceleraciones se reducen con el tamaño de lote. En tamaño de lote 1, EAGLE logra hasta 1.96x en Llama-3-70B. En tamaño de lote 128, esto cae a 1.21x. El sistema se vuelve limitado por cómputo en alta concurrencia, y la GPU tiene menos capacidad ociosa para especular.

2. La verificación domina el tiempo de ejecución (42-95%). La pasada directa del modelo objetivo es el cuello de botella. Reducir la verificación desperdiciada en tokens rechazados es la vía más prometedora para la mejora.

3. Ningún método único gana en todas partes. EAGLE-3 es la mejor opción en general. Los métodos de modelo de borrador brillan cuando el modelo objetivo es grande (70B+). n-gram es óptimo para edición de código y tareas de alta superposición.

4. El análisis de oráculo revela una brecha. El límite superior teórico para estrategias combinadas de n-gram + EAGLE alcanza ~4.9x en cargas de trabajo de edición de código, pero las implementaciones actuales logran 2-3x. Hay margen para optimización.

Expectativas Prácticas de Aceleración

El efecto del tamaño de lote es crítico. En lotes pequeños, la GPU tiene cómputo ocioso para especular. En lotes grandes, el sistema ya está saturado, y la decodulación especulativa añade sobrecarga sin beneficio proporcional.

Monitoreo en Producción

Debes rastrear la tasa de aceptación en producción. Una tasa de aceptación en declive señala que tu modelo de borrador se está desviando del objetivo: ya sea porque la carga de trabajo cambió, o porque el modelo de borrador necesita reentrenarse.

Métricas clave para monitorear:

• Tasa de aceptación por solicitud (debería ser estable alrededor de tu línea base)
• Tokens por segundo con vs sin decodulación especulativa (la aceleración real)
• Tiempo de verificación como porcentaje del tiempo de ciclo (debería ser 42-95%)
• Tiempo de pasada directa del modelo de borrador (debería ser < 20% del tiempo del modelo objetivo)

Si tu tasa de aceptación cae por debajo del 40%, desactiva la decodulación especulativa para esa solicitud. La sobrecarga no vale la pena.

Configuración Práctica

La elección del motor importa tanto como la estrategia de borrado: ver Ollama vs vLLM vs LM Studio and other local runtimes para cómo cada runtime maneja el lote, la compatibilidad de API y el rendimiento antes de elegir un camino de decodulación especulativa.

llama.cpp

Para la configuración general del servidor y la carga de GGUF, comienza con el llama.cpp quickstart; las banderas a continuación añaden decodulación especulativa encima.

llama.cpp soporta múltiples métodos de decodulación especulativa a través de la bandera --spec-type:

# Modelo de borrador (independiente)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Obligatorio: --parallel 1 para decodulación especulativa

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (ajuste para carga de texto)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Autoespeculativo (cargas de trabajo de codificación)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Banderas críticas:

• --parallel 1: La decodulación especulativa en llama.cpp requiere modo de lote único. Esta es una limitación actual.
• --spec-draft-n-max: Número de tokens de borrado por ciclo. Comienza con 3-5; valores más altos aumentan la presión en la VRAM.
• --spec-ngram-simple-size-n: Longitud del n-grama de búsqueda. El valor por defecto 12 funciona bien para código; reduce a 8 para texto.

Errores comunes:

• Olvidar --parallel 1: el servidor ignorará silenciosamente la decodulación especulativa.
• Usar modelos de borrador cruzados entre familias: las tasas de aceptación colapsan, anulando cualquier aceleración.
• Establecer --spec-draft-n-max demasiado alto: cada token de borrado extra cuesta VRAM para el búfer de borrado. Los rendimientos decrecientes comienzan alrededor de 5-8.

vLLM

El vLLM quickstart cubre el despliegue base; las banderas a continuación habilitan la decodulación especulativa en un servidor vLLM existente.

vLLM soporta decodulación especulativa a través de las banderas --speculative-model y --speculative-num-steps:

# Modelo de borrador
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (borrado paralelo)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

La decodulación especulativa de vLLM está integrada con el lote continuo, por lo que funciona bajo cargas de trabajo concurrentes. El programador maneja múltiples ranuras de tokens dentro de una sola pasada directa, y el gestor de memoria maneja el caché KV para ambos modelos, borrador y objetivo.

SGLang

SGLang soporta decodulación especulativa a través de su bandera --speculative-algorithm:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

La arquitectura RadixAttention de SGLang se complementa bien con la decodulación especulativa porque el almacenamiento en caché de prefijos reduce el costo de verificación: el modelo objetivo reutiliza la atención en caché para prefijos compartidos, haciendo cada pasada de verificación más barata que una pasada directa fría.

TensorRT-LLM

TensorRT-LLM proporciona decodulación especulativa de grado de producción con Triton Inference Server. La configuración es más involucrada pero ofrece el mejor rendimiento en hardware NVIDIA:

1. Construye el motor TensorRT para ambos modelos, objetivo y borrador.
2. Configura el repositorio del modelo con model.yaml especificando la configuración de decodulación especulativa.
3. Inicia Triton con la API LLM / backend PyTorch.

TensorRT-LLM soporta tanto variantes de modelo de borrador como EAGLE-3. Para cargas de trabajo de generación de código, TensorRT-LLM con decodulación especulativa de n-gramos ha demostrado una reducción de latencia de 2-3x en despliegues de producción.

Cuándo Usar Decodulación Especulativa

Úsalo Cuando

• Modelos objetivo grandes (7B+): La sobrecarga del mecanismo de borrado se amortiza sobre el cómputo del objetivo. La decodulación especulativa brilla cuando el modelo objetivo es lento: cuanto más grande es el objetivo, más valiosa es la aceleración.
• Cargas de trabajo de baja temperatura: La decodulación especulativa funciona mejor a temperatura 0.0-0.7, donde la distribución del modelo objetivo está concentrada y el borrador tiene mejor chance de coincidir.
• Aplicaciones interactivas: Las cargas de trabajo sensibles a la latencia (chat, autocompletado de código, llamadas de herramientas de agentes) se benefician más. El procesamiento por lotes donde ya estás saturando la GPU ve menos beneficio.
• Generación y edición de código: La alta repetición en patrones de código hace que n-gram y la decodulación autoespeculativa sean particularmente efectivos.

Omitelo Cuando

• Modelos objetivo pequeños (< 3B): La sobrecarga del modelo de borrado se acerca al tiempo de pasada directa del objetivo. La aceleración es marginal o negativa.
• Muestreo de alta temperatura: A temperatura > 0.7, la distribución del modelo objetivo es demasiado amplia para que el borrador coincida de manera confiable.
• Escritura creativa y generación abierta: Las bajas tasas de aceptación en contenido novel hacen que la sobrecarga no valga la pena.
• Tamaños de lote grandes (> 32): El sistema se vuelve limitado por cómputo, y la decodulación especulativa añade sobrecarga sin beneficio proporcional. SpecDecode-Bench muestra la aceleración cayendo de 1.96x a 1.21x a medida que el tamaño de lote va de 1 a 128.

Combinando Métodos

Las configuraciones avanzadas combinan múltiples estrategias de decodulación especulativa. El análisis de oráculo de SpecDecode-Bench mostró que combinar adaptativamente n-gram y EAGLE puede impulsar la aceleración a 4.9x en cargas de trabajo de edición de código.

La idea es usar n-gram para patrones que han aparecido antes, donde la aceptación es alta y la sobrecarga es cercana a cero, y volver a EAGLE para tokens novel. En la práctica, esto requiere soporte del motor para especulación multimétodo: vLLM y TensorRT-LLM tienen soporte experimental, pero las implementaciones de grado de producción aún están madurando.

Por ahora, la combinación más práctica es MTP + n-gram en llama.cpp. MTP maneja la especulación neural, mientras que n-gram captura patrones repetitivos que MTP pasa por alto. En Qwen 3 27B, esta combinación logra 120 tokens/segundo comparado con 67 tokens/segundo estándar: una aceleración de 1.8x.

Consideraciones de Costo

La decodulación especulativa intercambia cómputo por latencia. El cómputo total por token es aproximadamente el mismo: solo estás haciendo más trabajo en paralelo en lugar de secuencialmente.

Impacto en el costo de GPU:

• La latencia de solicitud única mejora entre un 20-50%, lo cual importa para aplicaciones interactivas.
• El rendimiento (tokens/segundo a través de muchas solicitudes) mejora menos: la GPU ya está saturada en tamaños de lote grandes.
• El uso de VRAM aumenta por la huella del modelo de borrado (1-4 GB para borradores independientes, mínimo para n-gram/EAGLE).

Inferencia en la nube: A $2-4/hr por H100, la decodulación especulativa reduce la latencia por solicitud sin aumentar el costo por token. Para procesamiento por lotes donde ya estás saturando la GPU, el beneficio de costo es mínimo: estás pagando por el mismo tiempo de GPU de cualquier manera.

Cuando la decodulación especulativa ahorra dinero: Aplicaciones interactivas donde cobras por solicitud y quieres reducir el tiempo hasta el primer token. Una aceleración de 2x significa que tus usuarios esperan la mitad de tiempo, y puedes servir más solicitudes por segundo en el mismo hardware.

Cuando no: Procesamiento por lotes donde ya estás maximizando la utilización de la GPU. El cómputo extra de la decodulación especulativa no aumenta el rendimiento: solo cambia el perfil de latencia.

Qué Sigue

La decodulación especulativa está madurando de novedad de investigación a estándar de producción. El límite está empujando más allá de las limitaciones actuales:

• Speculative Speculative Decoding (SSD): Paraleliza las etapas de borrado y verificación a través de hardware separado. El modelo de borrado ejecuta asincrónicamente, pre-especulando para múltiples resultados de verificación probables. Los resultados tempranos muestran hasta 2x de aceleración sobre la decodulación especulativa optimizada, y 5x sobre la decodulación autorregresiva. Aún no está listo para producción, pero la dirección es clara.

• SpecSA (Verificación Especulativa Dispersa): Combina decodulación especulativa con atención dispersa dinámica. Convierte la atención dispersa en una carga de trabajo orientada a la verificación, logrando hasta 3.49x de rendimiento final sobre la decodulación dispersa autorregresiva. Relevante para modelos de contexto largo donde la atención dispersa ya está en uso.

• Especulación adaptativa: Cambiar automáticamente entre métodos de n-gram, EAGLE y modelo de borrado basándose en características de la carga de trabajo. El análisis de oráculo muestra un potencial significativo sin explotar: las implementaciones actuales logran 2-3x, pero el límite teórico es 4.9x.

• Decodulación especulativa multimodal: Extender borrado-verificación a modelos de lenguaje-visual y generación de video. Encuestas tempranas muestran que los mismos principios aplican, pero las estrategias de verificación necesitan adaptación para modalidades no textuales.

Marco de Decisión