English · Español

04 — Speculative decoding y modelos de "reasoning"¶

🇪🇸 Dos técnicas que no son cambios de arquitectura, sino de cómo se usa el modelo en inferencia: speculative decoding (un modelo pequeño propone, el grande verifica; aceleras decode 2-5×) y reasoning models (más cómputo en test-time, vía cadenas-de-pensamiento entrenadas con RL). Ambas resuelven cuellos distintos al de la latencia por token; ninguna es relevante para el tutor de gramática.

Los tres primeros archivos de teoría cubrieron cambios arquitectónicos — MoE, MLA, Mamba. Este archivo cubre dos técnicas no arquitectónicas que aparecen a menudo en las mismas conversaciones de "frontera":

Speculative decoding — un truco de decoding. Mismo modelo. Multiplica los tokens-por-forward por 2–5× a costa de complejidad.
Reasoning models — un truco de entrenamiento y cómputo en inferencia. Comportamiento distinto del modelo (long chain-of-thought antes de responder). Multiplica la calidad en tareas de reasoning a costa de latencia y tokens gastados.

Ambas son populares recientemente. Ambas tienen cuellos de botella específicos que alivian. Ninguna ayuda al tutor de gramática. Lo cubriremos rápido.

Speculative decoding¶

La idea¶

El decode es memory-bound (Fase 21, Fase 22). Cada token requiere cargar todos los pesos desde la HBM a los SMs. La intensidad aritmética es baja; los tensor cores de la GPU están ociosos la mayor parte del tiempo.

Si pudiéramos obtener varios tokens por forward, el mismo tráfico de memoria daría más trabajo útil. Speculative decoding hace exactamente esto:

Un modelo draft (mucho más pequeño, más rápido) propone los siguientes \(k\) tokens autoregresivamente: \(\hat{x}_{t+1}, \ldots, \hat{x}_{t+k}\).
El modelo target (real) corre UN forward sobre la secuencia propuesta, produciendo distribuciones para cada una de las \(k\) posiciones en paralelo.
Verificamos: para cada \(i\), comparamos la distribución del target en la posición \(t+i\) con la del draft en la misma posición. Aceptamos \(\hat{x}_{t+i}\) con probabilidad \(\min(1, p_{\text{target}}(\hat{x}_{t+i}) / p_{\text{draft}}(\hat{x}_{t+i}))\). Paramos en el primer rechazo.
Los tokens aceptados son exactamente lo que el target habría producido (matemáticamente: es importance sampling). Calidad idéntica a la inferencia standalone del target; velocidad amortizada sobre varios tokens aceptados por cada forward del target.

Tokens esperados por forward: depende del acuerdo draft-target. Típico: 2–5× de aceleración. Mayor cuando el draft se parece mucho al target (dominio de tarea pequeño, como gramática); menor en prompts adversariales o fuera de distribución.

La familia¶

Speculative decoding vainilla (Leviathan et al., 2023): draft + target, como arriba.
Medusa (Cai et al., 2024): en lugar de un draft separado, añade múltiples "draft heads" al target — distintas cabezas de salida predicen \(t+1, t+2, t+3\). El mismo forward produce \(k\) propuestas. Más limpio que un modelo separado.
EAGLE (Li et al., 2024): mejor arquitectura del draft, aprende de los hidden states del target. Mayor tasa de aceptación.
Lookahead decoding (Fu et al., 2024): sin draft separado. El target propone tokens futuros mediante su propia historia tipo n-gram. Self-speculative.

Todos logran el mismo objetivo — más tokens por forward — con distintos tradeoffs de complejidad/calidad.

¿Ayudaría speculative decoding al tutor de gramática?¶

Test:

Cuello de botella: latencia de decode en un workload de inferencia memory-bound, mono-usuario, batch bajo.
¿El tutor de gramática lo tiene? El tutor de gramática es mono-usuario y de batch pequeño. El tiempo de decode por token en CPU local es ~3 ms. El corpus es tan pequeño que incluso un modelo "draft" sería apenas más pequeño que el target.
¿Qué costaría speculative decoding? Un modelo draft separado (p. ej., la baseline n-gram de la Fase 14) más la lógica de verificación. Carga de mantenimiento. Nuevos modos de fallo (drift en la tasa de aceptación).
Veredicto: Aplazar. No "nunca" — es plausible. Pero la ganancia a nuestra escala (3 ms → 1 ms) es marginal frente a la complejidad de implementación.

Un contrafáctico¶

Si el tutor de gramática sirviera a 10 000 usuarios concurrentes vía el servidor de la Fase 33 con batching continuo, y las queries de cada usuario fueran pequeñas (outputs cortos), y la GPU fuera memory-bound: sí, speculative decoding ayudaría. La baseline n-gram de la Fase 14 sería un excelente draft para generaciones cortas de tarea estrecha. Podría dar 3–4× tokens/s gratis.

Pero eso es una consideración de planificación de capacidad de la Fase 38, no una preocupación de arquitectura de frontera.

Reasoning models¶

La idea¶

Los LLM estándar generan tokens autoregresivamente. La cantidad de cómputo gastado por respuesta es aproximadamente proporcional a la longitud de la respuesta.

Los reasoning models (p. ej., OpenAI o1, DeepSeek R1, Claude con extended thinking) generan una cadena larga de tokens de pensamiento interno antes de producir la respuesta final. El pensamiento es mucho más largo que la respuesta; el modelo intercambia latencia por calidad. Críticamente, el modelo se entrena (vía RL o similar) para producir pensamiento útil, no cualquier token.

La afirmación de "escalado de cómputo en test-time": doblar el presupuesto de tokens de pensamiento mejora el rendimiento en tareas de reasoning duras (matemáticas, código, planificación multi-paso) más que doblar el tamaño del modelo. El cómputo gastado en inferencia es ahora un botón de calidad, no solo un coste de latencia.

Por qué esto no es un cambio de arquitectura¶

La arquitectura sigue siendo un transformer denso. El cambio está en los datos de entrenamiento y el reward (RL sobre trazas de reasoning) y en la política de inferencia (permitir generación interna larga antes de la respuesta). No "añades reasoning" cambiando el modelo; lo entrenas así.

¿Ayudaría el reasoning al tutor de gramática?¶

Test:

Cuello de botella: problemas complejos multi-paso donde la generación de un solo disparo rinde por debajo.
¿El tutor de gramática lo tiene? No. La corrección de conjugación es de un paso. "He goed to school" → "He went to school" requiere que el modelo: identifique el verbo (un lookup), identifique el tiempo (un lookup), encuentre la forma de pasado irregular (un lookup). Un modelo denso bien entrenado lo consigue de un disparo. La chain-of-thought ayuda cero.
¿Qué costaría añadir reasoning? Datos de entrenamiento RL (tenemos un corpus determinista, no trazas de reasoning calificadas). Nueva pipeline de entrenamiento. Mayor coste de inferencia (más tokens por respuesta).
Veredicto: Nunca. La tarea del tutor de gramática es exactamente no una tarea de reasoning. Añadir chain-of-thought lo ralentizaría sin ganancia de calidad.

La salvedad honesta¶

Para un agente tutor de gramática (Fase 32) que maneja casos ambiguos — "¿es 'fewer' o 'less' correcto aquí?" requiere considerar contexto — algo de razonamiento adicional podría ayudar. Pero son unos pocos tokens de "déjame revisar el contexto...", no las cadenas-de-pensamiento de miles de tokens que producen los reasoning models de frontera. El framework correcto es el flujo simple de constrained-decoding de la Fase 30 + Fase 32, no reasoning estilo o1 entrenado con RL.

Juntándolo: el árbol de decisión de arquitectura¶

La Fase 36 termina con un árbol de decisión (entregado como diagrama mermaid en diagrams/):

Inicio: ¿estoy descontento con el comportamiento de mi modelo actual?
├── Sí, es demasiado grande para caber en mis GPUs
│   ├── Inferencia: TP / FSDP / MLA (para KV cache)
│   └── Entrenamiento: ZeRO-3 / FSDP / TP
├── Sí, el entrenamiento es demasiado lento a capacidad fija
│   ├── Añadir más GPUs: DDP
│   └── Añadir más cómputo por parámetro: scale-up denso
├── Sí, mi modelo carece de capacidad a presupuesto de cómputo fijo
│   └── MoE (si te puedes permitir la complejidad del routing)
├── Sí, mi contexto es tan largo que la attention explota
│   ├── O(10k tokens): RoPE + chunking (Fase 16)
│   ├── O(100k tokens): MLA + GQA
│   └── O(1M+ tokens): Mamba (híbrido con capas de attention)
├── Sí, mi latencia de decode es demasiado alta
│   └── Speculative decoding (si tienes un buen draft model)
├── Sí, mi modelo falla en reasoning multi-paso
│   └── Entrenar con chain-of-thought RL (reasoning models)
└── No, mi modelo está bien
    └── No cambies nada. <-- AQUÍ VIVE EL TUTOR DE GRAMÁTICA

La hoja del árbol que carga el peso para el tutor de gramática es la última. La Fase 36 es la fase en la que Borja aprende a llegar con confianza a esa hoja.

Lo que esta fase NO cubre¶

Implementar speculative decoding. Solo survey. La Fase 30 (generación estructurada) podría alojar un experimento; la Fase 36 no.
Entrenamiento RL para reasoning models. Muy fuera de alcance — RLHF/RLAIF ya se sacó de la Fase 28 como solo concepto.
Comparar reasoning models (o1 vs R1 vs DeepThink): benchmarking de proveedores, no material curricular.
Self-consistency, tree-of-thought y otras variantes de cómputo en test-time. Mencionadas de pasada; no derivadas.
Arquitecturas multimodales (visión-lenguaje, audio). Fuera de alcance; §4 lo aplaza explícitamente.

Siguiente: lab/00-moe-on-grammar-tutor.md.