Test-Time Compute
Test-time compute como segunda ley de escala. Las tres palancas (más pasos, más candidatos, más estructura) y su perfil de calidad, coste y latencia en modelos razonadores.
Los enlaces con ?t= abren el vídeo en un segundo concreto.
Las ideas que debes retener
1. Qué es test-time compute y por qué importa
Durante mucho tiempo, la única palanca conocida para mejorar la calidad de un LLM era la escala de entrenamiento: más parámetros, más datos, más cómputo en el entrenamiento. Las "leyes de…
2. Las tres palancas
Hay tres mecanismos principales para traducir más cómputo en mejores respuestas.
Palanca 1: Más pasos internos
La cadena de pensamiento (chain-of-thought, Wei et al., 2022) es el mecanismo más directo. En lugar de generar la respuesta final inmediatamente, el modelo genera primero una secuencia de…
Texto del vídeo y descripción visual
Este vídeo no contiene voz. La pista de texto reproduce el contenido escrito; las descripciones siguientes explican los elementos visuales.
0:00 — Test-Time Compute: la segunda dimensión de escala.
La segunda dimensión de escala. Más pasos. Más candidatos. Mejores decisiones de cómputo.
Descripción visual: Tres mecanismos, secuencial, paralelo y estructurado, se revelan progresivamente para introducir tres formas de gastar más cómputo durante inferencia.
0:09 — No solo entrenar más. Pensar más.
Una palanca es el entrenamiento: más parámetros, más datos y más cómputo para construir el modelo. Las leyes de escala de Kaplan lo documentaron en 2020. Pero hay una segunda dimensión. Cuánto cómputo se invierte en cada respuesta individual. Eso es test-time compute.
Descripción visual: Dos columnas separan entrenamiento e inferencia y muestran que el presupuesto por respuesta es distinto del cómputo usado para construir los pesos.
0:26 — Forzar al modelo a seguir pensando.
Chain-of-thought descompone el problema en pasos intermedios. Los modelos razonadores pueden extender ese razonamiento. Una técnica llamada budget forcing suprime el token de fin y añade "Wait". En el estudio de s1-32B, budget forcing elevó AIME24 de 50% a aproximadamente 57%. Más pasos pueden mejorar la respuesta; no lo garantizan.
Descripción visual: Una secuencia Plantear → Separar → Comprobar se extiende con Wait antes del token de fin y termina mostrando la comparación AIME24 50% → ≈57%.
0:46 — Generar muchas respuestas. Quedarse con la mejor.
Best-of-N genera varias respuestas y usa un evaluador para seleccionar la mejor. Otra estrategia es elegir por mayoría. El criterio de selección importa tanto como el número de candidatos. En AIME 2024, o1 pasó de 74% con una muestra a 83% con consenso entre 64 muestras. Eso es selección por mayoría.
Descripción visual: Cuatro candidatos para 17 × 6 se evalúan y votan; después aparece la comparación reportada para o1 en AIME 2024, 74% con una muestra y 83% con consenso de 64 muestras.
1:09 — Explorar ramas. Descartar las malas.
La búsqueda en árbol no genera una única cadena lineal. Explora múltiples ramificaciones, evalúa cada una y poda las menos prometedoras. El coste depende de cuántas ramas se expanden. Para planificación compleja, permite comparar rutas alternativas antes de continuar. La mejora no es automática: depende de la tarea, del evaluador y del presupuesto de búsqueda.
Descripción visual: Un árbol parte del problema, expande rutas A/B/C, poda ramas y conserva una ruta seleccionada hasta Continuar para mostrar exploración, evaluación y poda.
1:29 — Cada token espera al anterior.
En la decodificación autorregresiva estándar, cada token depende de los anteriores. A una tasa fija de 100 tokens por segundo, generar una cadena de 5.000 tokens requiere 50 segundos. Acortar la cadena o generar tokens más rápido reduce esa espera. La dependencia secuencial sigue existiendo. La latencia es una restricción de diseño real.
Descripción visual: Una fila de tokens se acumula de forma secuencial y una barra de tiempo termina en el cálculo ilustrativo 5000 ÷ 100 = 50 s.
1:49 — Modelo grande o más tiempo de pensar.
Test-time compute y preentrenamiento son complementarios. En ciertas tareas, un modelo pequeño con más cómputo puede superar a uno grande con menos. El coste ya no lo fija solo el tamaño. Los sistemas eficientes ajustan el modelo y el presupuesto a cada problema. Esa decisión necesita evaluación por tarea. Eso es escala complementaria.
Descripción visual: Un plano compara tamaño del modelo con cómputo por consulta y sitúa un modelo pequeño con más inferencia frente a un modelo mayor para explicar la asignación complementaria.
