Speculative decoding: el secretario que adelanta lo que va a decir el jefe — fundamentos, matemáticas y estado mayo 2026

· Por José Manuel Román

Este post complementa los de KV cache: la memoria de trabajo y Quantization para inferencia LLM. Ambos son palancas de aceleración dentro de un único forward pass. Speculative decoding es la palanca complementaria: en lugar de hacer cada forward pass más barato, intenta producir más tokens por forward pass. Es ortogonal a quantization y al KV cache, y se acumula multiplicativamente con ambos.

Estás aquí: DEPLOY

Estás aquí: DEPLOY · más tokens por forward pass sin tocar calidad1 · Data2 · Tune3 · Eval4 · Deploy5 · Observe6 · Retrain

TL;DR

La inferencia LLM autoregresiva tiene un problema estructural: cada token nuevo necesita un forward pass completo del modelo, y los forward passes de decode están memory-bandwidth-bound, no compute-bound (el detalle está en KV cache). La GPU pasa la mayor parte del tiempo esperando a que llegue el siguiente peso desde HBM. Speculative decoding aprovecha ese tiempo muerto haciendo dos cosas en paralelo: un modelo pequeño y barato (draft) genera γ tokens autoregresivamente —rápido pero impreciso—, y el modelo grande (target) verifica esos γ tokens en un único forward pass paralelo, casi al mismo coste que un forward pass de un solo token. Una regla de aceptación basada en rejection sampling decide cuántos tokens del draft se aceptan, y la matemática prueba —no aproxima, prueba— que la distribución del output coincide exactamente con muestrear directamente del target. La técnica tiene techo: nunca se generan más de 1/(1-α) tokens por step, con α la tasa de aceptación. Las cinco familias dominantes en mayo de 2026 son vanilla SD (Leviathan 2023), Medusa (cabezas paralelas extra), EAGLE-1/2/3 (draft que opera a nivel de hidden states), MTP (multi-token prediction nativo de DeepSeek-V3) y P-EAGLE (draft que produce los γ tokens en un único forward pass, integrado en vLLM 0.16+). En workloads de baja concurrencia con prompts cortos y outputs largos —el caso típico del asistente conversacional on-premise— el speedup real está entre 2× y 4× en hardware moderno.

La analogía: el secretario que adelanta y el jefe que valida

Imagina una rueda de prensa muy concurrida con un sistema de transcripción en tiempo real. Hay dos personas trabajando:

El secretario está sentado frente al teclado. Sabe de qué va el tema, ha leído los briefings y conoce las muletillas del jefe. Cuando el jefe abre la boca, el secretario empieza a teclear inmediatamente lo que cree que va a decir. Es rápido —teclea tres o cuatro palabras antes de que el jefe las pronuncie— pero a veces se equivoca, especialmente cuando el jefe coge un giro inesperado.

El jefe lee periódicamente la pantalla del secretario. Lee un bloque entero de un golpe —tres o cuatro palabras— y compara mentalmente lo escrito con lo que él habría dicho. Si coincide con su intención, deja el texto y sigue. Si en algún punto el secretario se desvió, corrige justo ahí, y lo que el secretario tecleó después de la divergencia se descarta (porque podría estar mal por culpa del error anterior). Si el bloque entero estaba bien, el jefe aprovecha y añade una palabra más mientras corrige.

El resultado: el texto final es idéntico al que habría dictado el jefe a solas, pero se produce más rápido porque el secretario adelanta trabajo.

La analogía se sostiene en cuatro detalles:

  • El secretario es el draft model. Pequeño, barato, rápido, aproximado.
  • El jefe es el target model. Lento, caro, pero es la única autoridad sobre la calidad del output.
  • El bloque que lee el jefe de un golpe es el forward pass paralelo del target sobre prompt + γ tokens del draft. El coste de verificar γ tokens es casi el mismo que el de generar uno (porque el cuello de botella es cargar los pesos desde HBM, no las operaciones).
  • La regla de “corrige justo donde divergió” es el rejection sampling que preserva la distribución del target.

A partir de aquí entramos al mecanismo y a por qué la calidad se preserva exactamente, no aproximadamente.

El mecanismo desnudo

Llamemos p a la distribución del target (lo que produciría si fuese el único en hablar) y q a la del draft. La iteración de speculative decoding tiene tres pasos:

Paso 1 — Draft. El draft genera γ tokens autoregresivamente: x_1, x_2, ..., x_γ. Cada uno por su forward pass propio. Como el draft es pequeño, los γ steps cuestan poco. Típicamente γ ∈ [4, 8].

Paso 2 — Verify. El target ejecuta un único forward pass sobre la secuencia completa prompt + x_1 ... x_γ. Por la atención causal, ese forward pass produce simultáneamente las distribuciones p(·|prompt, x_<i) para cada posición i. Es decir, en un solo paso obtiene la verificación de los γ tokens y, además, una distribución extra p(·|prompt, x_1...x_γ) para el siguiente token.

Paso 3 — Accept/reject token a token. Para cada x_i de izquierda a derecha aplica:

  • Si p(x_i) ≥ q(x_i): aceptar siempre.
  • Si p(x_i) < q(x_i): aceptar con probabilidad p(x_i)/q(x_i).
  • Si rechaza: parar, muestrear un token de reemplazo desde la distribución residual normalizada norm(max(0, p − q)), y descartar el resto.
  • Si llega al final habiendo aceptado los γ tokens: añadir un token bonus muestreado directamente de p(·|prompt, x_1...x_γ), que ya está en los logits del forward del target.

Resultado por iteración: entre 1 y γ+1 tokens nuevos. En el mejor caso (todos aceptados + bonus) se generan γ+1 tokens al coste de un único forward pass del target más γ forward passes del draft, contra γ+1 forward passes del target en la versión sin speculative.

1. Draft model (q) genera γ=4 tokens autoregresivamentex₁x₂x₃x₄4 forward passes baratos

2. Target model (p) verifica los 4 tokens en UN forward pass paraleloforward pass único sobre [prompt, x₁, x₂, x₃, x₄]obtiene p(·|prompt, x<i) para i=1..5

3. Rejection sampling izquierda-a-derechax₁ ✓p≥qx₂ ✓aceptadox₃ ✓aceptadox₄ ✗rechazado

4. Resultado de esta iteraciónx₁x₂x₃x’₄x’₄ = muestra de norm(max(0, p−q)) en pos 4se descarta el bonus (sólo si todos aceptados)

→ 4 tokens nuevos en una sola iteración del target. Sin speculative serían 4 iteraciones.

Por qué la calidad no se degrada (la prueba)

Esta es la parte de la técnica que más confunde la primera vez. Parece magia: ¿cómo es posible que muestrear de un draft cualquiera y luego “validar” produzca exactamente la misma distribución que muestrear del target original?

La prueba cabe en dos líneas. Para cualquier token x, la probabilidad final de emitirlo es la suma de dos eventos disjuntos: que el draft lo proponga y se acepte, o que el draft proponga otra cosa, se rechace, y al muestrear del residual salga x. Formalmente:

$$P(\text{emit } x) = q(x) \cdot \min!\left(1, \frac{p(x)}{q(x)}\right) + P(\text{reject}) \cdot \frac{\max(0, p(x)-q(x))}{\sum_y \max(0, p(y)-q(y))}$$

El primer término es min(p(x), q(x)). El segundo es max(0, p(x) − q(x)) (la masa total rechazada Σ max(0, p−q) cancela exactamente el denominador). Sumando: min(p(x), q(x)) + max(0, p(x) − q(x)) = p(x). El output es estadísticamente indistinguible de muestrear directamente del target, hasta diferencias numéricas de coma flotante.

Esto es importante operacionalmente: significa que speculative decoding no es una compresión perceptual, no es un trade-off de calidad-velocidad, no requiere validación adicional con evals. Si el target hubiese pasado un eval determinado, el sistema con speculative también lo pasa.

La matemática que importa: techo y speedup

Llamemos α a la tasa de aceptación: la probabilidad esperada de que un token draft individual sea aceptado. Asumiendo que las aceptaciones de tokens consecutivos son independientes (aproximación razonable en práctica), el número esperado de tokens generados por iteración es:

$$E[\text{tokens por step}] = \sum_{k=0}^{\gamma} \alpha^k + \alpha^{\gamma+1} = \frac{1 - \alpha^{\gamma+1}}{1 - \alpha}$$

Y el speedup teórico respecto a generar un token por iteración del target —con c = T_draft / T_target el coste relativo del draft— es:

$$\text{Speedup} = \frac{1 - \alpha^{\gamma+1}}{(1 - \alpha)(\gamma c + 1)}$$

Hay un techo que muchas implementaciones intentan superar inútilmente: cuando γ → ∞, el speedup converge a:

$$\lim_{\gamma \to \infty} E[\text{tokens por step}] = \frac{1}{1 - \alpha}$$

Es un techo algorítmico, no de hardware. Con α = 0.7 nunca se generan más de 3.33 tokens por iteración por más que el hardware mejore. Con α = 0.8 → 5. Con α = 0.9 → 10. Por eso EAGLE-3, que apunta a α > 0.8 en muchos benchmarks, no es una mejora incremental sobre vanilla SD (α ≈ 0.5-0.6): es un cambio de régimen porque sube el techo, no se limita a acercarse a él.

Ejemplo numérico concreto, Llama 3 70B target con un draft que da α = 0.75, γ = 5, c = 0.1:

  • Tokens esperados por step: (1 − 0.75⁶) / (1 − 0.75) = (1 − 0.178) / 0.25 = 3.29
  • Speedup: 3.29 / (5 × 0.1 + 1) = 3.29 / 1.5 = 2.19×

Si subimos α a 0.85 con la misma configuración: tokens por step = (1 − 0.85⁶) / 0.15 = (1 − 0.377) / 0.15 = 4.16, speedup = 4.16 / 1.5 = 2.77×. Un cambio de α = 0.75 → 0.85 (10 puntos absolutos) sube el speedup un 27 %. Por eso la investigación de los últimos dos años se centra en empujar α: ahí está el premio.

Las cinco familias modernas (mayo 2026)

FamiliaAñoIdea centralTamaño draftα / τ típicoSpeedup
Vanilla SD2023Pareja target + draft same-family, rejection sampling1/10 – 1/100 target0.5 – 0.82-3×
Medusa2024N cabezas extra en paralelo predicen t+1, t+2, …; tree attention verifica varios candidatossin draft, +1-2 % paramstop-5 > 0.82.18-2.83×
EAGLE-1/2/32024-25Draft autoregresivo a nivel de features (hidden states), no de tokens. Reusa embedding del target1 bloque transformer (~0.5-2 % params)EAGLE-3: α > 0.8, τ hasta 7.5hasta 6.5× peak
MTP (DeepSeek-V3)2024Cabezas multi-token entrenadas desde cero como parte del modelo; en inferencia hacen de draft “gratis”14B params en V3 671Bα > 0.8 (MTP1)1.5-1.8×
P-EAGLE2026EAGLE pero produciendo los γ drafts en un único forward pass (paralelo, no autoregresivo)igual que EAGLE+30 % sobre EAGLE-34-5× vs AR

Tres observaciones operacionales:

  1. EAGLE domina en producción porque su overhead es mínimo (un bloque transformer, ~1 % del target en parámetros) y su α es alto. El draft no necesita su propio KV cache “completo” porque comparte features del target.
  2. Medusa fue importante históricamente —demostró que se podía hacer speculative sin draft separado—, pero EAGLE lo superó en todos los benchmarks publicados durante 2024-2025.
  3. MTP es especial: no es algo que añadas a un modelo existente. Es algo que el modelo entrenó nativamente. Si compras DeepSeek-V3, MTP viene gratis y da un ~1.8× sin tocar nada. Si compras Llama 3, no hay MTP que valga; usa EAGLE-3.

Hay además dos técnicas relacionadas que merecen mención breve, ambas sin draft model: Lookahead decoding (Fu et al. 2024), que formula decoding como iteración de Jacobi y extrae n-gramas de la trayectoria; y REST (He et al. 2024), que mantiene un datastore de n-gramas y propone drafts por longest-prefix match contra los últimos tokens generados. Ambas dan 1.5-2× sin VRAM extra. Útiles cuando no tienes draft model entrenado y no quieres mantener uno.

Implementaciones reales en mayo 2026

  • vLLM v0.16+: soporta unificadamente EAGLE-1/2/3, P-EAGLE, Medusa, MTP nativo (DeepSeek-V3 y variantes), n-gram/suffix decoding sin draft, draft model arbitrario y MLP speculators. El flag canónico es --speculative-config '{"method":"eagle3", "model":"...", "num_speculative_tokens": 5}'.
  • SGLang: soporte EAGLE-3 nativo con --speculative-algorithm EAGLE3. Para DeepSeek-V3 usa MTP vía adaptador EAGLE. Tiene framework propio de entrenamiento de drafts (SpecForge).
  • TensorRT-LLM: Medusa, EAGLE (variante simplificada sin árbol), ReDrafter, Lookahead. Reportan ~2.2× con EAGLE.
  • llama.cpp: speculative básico solo con draft model (--model-draft). Sin EAGLE/Medusa/MTP nativos hasta donde he verificado. Speedup típico 1.5-2.5× single-user.

Cuándo speculative NO ayuda

La técnica tiene tres puntos ciegos importantes:

Batch grande. El GPU pasa de memory-bound (decode con concurrencia baja) a compute-bound (decode con concurrencia alta). En régimen compute-bound los forward passes “casi gratis” del target dejan de serlo: γ tokens pasan a costar γ veces más en lugar de casi 1. El cruce típico está en batch 16-32 para modelos densos; para MoE con pocos parámetros activos por token el cruce ocurre más tarde. En picos de carga, speculative puede empeorar el throughput agregado por GPU.

Prefill / TTFT. Speculative decoding no toca el prefill. La fase de procesar el prompt completo sigue siendo idéntica. El TTFT no mejora y puede empeorar marginalmente por el setup del draft. Si el SLA es TTFT-bound (asistentes con outputs cortos, búsqueda, RAG con respuestas breves), no es la herramienta correcta.

Outputs cortos. Si el modelo genera 10-20 tokens y se acaba la respuesta, el overhead fijo del setup no se amortiza. Speculative brilla con outputs largos (300+ tokens): asistentes generativos, code completion extenso, redacción.

Pitfalls operacionales

VRAM extra del draft. En vanilla SD, cargar un draft completo más su KV cache cuesta caro. Llama 3 8B en BF16 como draft de un 70B son ~16 GB de pesos más KV cache. En un H100 80 GB con el target ya casi lleno, eso puede forzar a reducir el KV cache del target y bajar la concurrencia máxima. EAGLE resuelve este problema: el draft es un bloque transformer (~1 GB para un 70B) y reusa features del target.

Quantization del draft. Cuantizar el draft a INT4 con GPTQ degrada α sustancialmente (los errores en logits se acumulan en la comparación contra p). AWQ aguanta mejor pero también baja α. Práctica común en 2026: target en FP8 o INT4, draft en FP16/BF16. El draft es lo suficientemente pequeño como para que el ahorro de VRAM por cuantizarlo no compense la caída de α y, por tanto, de speedup. El detalle de cada formato está en Quantization.

Interacción con continuous batching. No lo rompe, pero crea nested raggedness: cada request del batch puede aceptar un número distinto de tokens en cada iteración. PagedAttention de vLLM lo absorbe, pero el planificador pierde eficiencia. A QPS bajo (asistente conversacional, baja concurrencia simultánea) la combinación es excelente. A QPS alto, hay tensión real y trabajos como Goodput-optimized speculative decoding (Liu et al., 2024) optimizan γ dinámicamente según el estado del batch.

Sampling temperature. α cae con temperaturas altas. A T = 1.0 con outputs creativos (redacción libre), α puede bajar 10-15 puntos respecto a T = 0 con la misma pareja modelo-draft. El speedup escala consecuentemente.

Implicaciones en hardware on-premise

En una RTX 4090 (24 GB, Ada Lovelace)

El uso clásico es vanilla SD con dos modelos cuantizados: por ejemplo, Llama 3 70B AWQ-INT4 como target (~35 GB → necesita TP=2 sobre dos 4090) y Llama 3 8B AWQ-INT4 como draft. En la práctica, el caso single-card más realista es Llama 3 8B target + un modelo de 1B como draft o Qwen 3 14B target + Qwen 3 0.5B como draft: caben holgadamente y dan 1.8-2.5× con tareas conversacionales. Para EAGLE en consumer, los drafts oficiales para familias populares (Llama 3, Qwen 3) están publicados en Hugging Face y ocupan 0.5-2 GB extra.

Aquí EAGLE-3 brilla:

  • Llama 3 70B FP8 + EAGLE-3 draft FP16: el draft ocupa ~0.7 GB; el target ~70 GB con TP=2 (35 GB por GPU). El speedup observado en benchmarks reproducibles está entre 2.5× y 4× a batch 1-4, cayendo a casi break-even a batch 32.
  • DeepSeek-V3 671B FP8 + MTP nativo: el modelo viene con MTP entrenado; no hay nada que añadir. El speedup es 1.5-1.8× con cero VRAM extra. Es la opción más eficiente operacionalmente: cero piezas adicionales.
  • Combinar con disaggregated serving: como detalla Disaggregated serving, prefill y decode pueden vivir en pods distintos. Speculative se aplica solo en los pods de decode, lo cual encaja perfectamente con la separación (prefill es compute-bound y no se beneficiaría).

La regla de pulgar en cluster H100 mayo 2026: si el modelo es DeepSeek-V3 / V4 → MTP nativo, sin más; si es Llama 3 / Qwen 3 → EAGLE-3 con draft oficial; si es exótico → vanilla SD con un draft de la misma familia.

Lo que no hemos cubierto

  • Entrenamiento de drafts EAGLE custom con SpecForge: cómo recolectar trayectorias del target y entrenar el draft on-policy.
  • Speculative Prefill (arXiv:2502.02789): variante para acelerar TTFT, mecanismo distinto del decode aquí descrito.
  • Tree attention en detalle: cómo Medusa y EAGLE-2 verifican varios candidatos a la vez con máscaras de atención específicas.
  • MoE + speculative: la combinación tiene interacciones no triviales con el router de expertos. Los activated params bajos hacen que el régimen memory-bound se mantenga incluso a batch alto, lo que cambia las reglas.

Ver también

Referencias