Capítulo 9 — Decodificación especulativa
Novena entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que muestra que el cuello de botella secuencial de la autorregresión tiene un hueco matemático — y expone la aritmética de cuándo compensa.
Por qué existe este capítulo
Los Capítulos 7 y 8 atacaron la concurrencia, manteniendo la GPU ocupada entre muchas secuencias. Ninguno cambia el hecho de que cada secuencia sigue recibiendo un token de salida por iteración. Ese suelo parece inescapable porque el forward pass del transformer depende genuinamente del token elegido en el paso anterior. La decodificación especulativa es la observación de que la dependencia es sobre la generación, no sobre la verificación: dado un candidato para el token t+1, el modelo objetivo puede correr un forward pass que a la vez pregunta "¿habría elegido esto?" y calcula la distribución para t+2 asumiendo que el candidato es correcto. El Capítulo 9 recorre el mecanismo, los algoritmos de draft (EAGLE, Medusa, Lookahead, MTP, n-gram, sufijo) y la aritmética de cuándo la especulación es una victoria.
9.1 La intuición de verificación preserva la corrección exactamente
Un mecanismo de draft barato propone N tokens candidatos. El objetivo — el modelo caro que queremos — corre un forward pass sobre el prefijo concatenado con los N candidatos. Como el forward pass de un transformer es paralelo entre posiciones, el objetivo produce su propia distribución de próximo token en cada una de las N+1 posiciones en ese único pass. El prefijo más largo en el que los candidatos coinciden con el objetivo se acepta; el primer desacuerdo es donde el motor se compromete con la elección del propio objetivo y descarta el resto. La regla de aceptación — acepta x extraído del draft q con probabilidad min(1, p(x)/q(x)); si no, muestrea del residuo normalizado (p−q)₊ — hace la distribución de salida idéntica a la del muestreo objetivo puro. La especulación preserva la corrección; el draft solo afecta a la velocidad. En GPUs modernas el forward pass de verificación con N=4 cuesta aproximadamente 1,2–1,5× un paso de decode normal, porque la atención abarca ahora N+1 posiciones de consulta pero se mantiene bien dentro del régimen limitado por memoria.
9.2 EAGLE ata el draft al estado oculto del objetivo
Las primeras implementaciones usaban un modelo pequeño distinto como draft — Llama-7B drafteando para Llama-70B — que funciona pero cuesta un segundo stream de HBM para los pesos del draft y limita la aceptación porque los dos modelos no comparten representaciones. EAGLE, refinado a través de EAGLE-2 y EAGLE-3 durante 2024–2025, ata el draft al objetivo: una única capa de transformer entrenada para predecir el estado oculto de la siguiente capa del objetivo, proyectado a través del propio embedding de salida del objetivo. No hay un conjunto separado de pesos de 7B que hacer fluir; la cabeza de draft son unos pocos cientos de megabytes. EAGLE-2 añade expansión dinámica de árbol de draft — un árbol de candidatos verificado en un solo pass de atención con máscara personalizada — para que el objetivo elija el mejor de varios caminos en vez de la única suposición del draft. EAGLE-3 añade mezcla de rasgos multi-capa, consumiendo capas intermedias del objetivo en vez de solo la penúltima. Las tasas de aceptación aterrizan en el 75–85 por ciento en chat y código con N de 5–8, lo que se traduce en aceleraciones end-to-end de 3–4× sobre decoding plano. Medusa toma la ruta alternativa — cabezas de draft paralelas que predicen varios tokens futuros en un solo pass en vez de autorregresivamente — con una historia de entrenamiento más sencilla y una aceptación algo menor. La decodificación por n-gramas y por sufijos es la comida gratis para cargas repetitivas (edición de código, salida por plantilla) donde el draft no es más que una consulta en el contexto reciente.
9.3 El propio forward de verificación se convierte en el techo
La fórmula del speedup es lo bastante exacta para escribirla: E[tokens_aceptados] / (T_draft/T_decode + 1 + α·N), donde α es el overhead de verificación por posición, típicamente 0,05–0,15. Aparecen dos techos. Primero, α·N crece con N, así que aumentar N indefinidamente no ayuda; el pico está en torno a N=6–8 con p=0,8, N=10–12 con p=0,9. Los motores que hardcodean N pierden el óptimo con la variación de carga. Segundo, y más sutilmente, la aceleración asintótica cuando p se acerca a 1 es 1/α — alrededor de 10× para α=0,10, 20× para α=0,05 — porque el propio forward de verificación es la pared. Los motores de producción han medido aceleraciones pico en este rango sobre cargas muy repetitivas y no las han superado. La especulación también interactúa con el batching: con batches grandes el forward del objetivo ya está cerca de estar limitado por cómputo, y los tokens extra de verificación lo empujan más, así que la aceleración se encoge a medida que el batch crece. El punto dulce de la especulación es batch bajo o medio en cargas críticas de latencia — justo el régimen donde vive el cómputo infrautilizado del Capítulo 1.
Lo que prepara el Capítulo 9
Los Capítulos 5 a 9 han agotado el toolkit de modelo y runtime — cuantización, pruning, destilación, batching, KV paginada, decodificación especulativa. Ninguno de estos se despacha como una librería que puedes pip install y olvidar. Alguien tiene que cablearlos en un runtime que sea dueño de un modelo en una GPU, corra un batch continuo y exponga una API de inferencia. Ese runtime es el motor. El Capítulo 10 recorre los cinco motores que dominan el stack de 2026 — vLLM, TensorRT-LLM, SGLang, TGI y Ollama — y los intercambios mecánicos que deciden cuál es la elección adecuada para un despliegue dado.
Próximamente — Capítulo 10: La capa del motor LLM. vLLM, TensorRT-LLM, SGLang, TGI, Ollama — motores como runtime de un solo nodo, elegidos por mecanismo en vez de por benchmark.
