Los regímenes de escalado en tiempo de inferencia requieren perfiles de evaluación distintos

Un artículo de 14 autores de Case Western Reserve publicado el 4 de agosto en arXiv identifica una falla crítica en cómo la comunidad de inferencia evalúa "test-time scaling": la etiqueta conflúa tres algoritmos estructuralmente distintos cuyos costos de computación, modos de fallo y propiedades estadísticas no se transfieren entre sí.

El artículo formaliza test-time scaling como inferencia presupuestada sobre el árbol de prefijo de un modelo autorregresivo y particiona el espacio de diseño en tres regímenes. El escalado secuencial de trayectoria única extiende la deliberación a lo largo de una ruta—el modelo continúa pensando antes de comprometerse. El escalado a nivel de hoja muestrea candidatos completos y los agrega mediante votación o verificación (best-of-N y variantes). El escalado a nivel de prefijo busca estados parciales incompletos vía búsqueda de haz, MCTS o expansión guiada por modelo de recompensa de proceso. Cada uno tiene una unidad de presupuesto distinta: tokens en un solo contexto, tokens muestreados totales o nodos en un árbol de estado parcial. Un artículo que reporta precisión con presupuesto de tokens pero sin especificación de régimen es, bajo este marco, ininterpretable. Esto describe la mayoría de los resultados publicados.

La crítica de evaluación es concreta. Reportar precisión sin el protocolo de inferencia hace los resultados incomparables entre estudios. Los autores proponen un perfil de evaluación que recupera métricas comunes (pass@k, precisión de votación mayoritaria) mientras separa el rendimiento de sistema end-to-end de los diagnósticos de banco de candidatos—crítico cuando un verificador se ejecuta sobre un muestreador. Distinguen reproducibilidad de repetición exacta de reproducibilidad distribucional y especifican los artefactos (semillas aleatorias, configs de muestreador, checkpoints de verificador) necesarios para cada una. El conjunto de datos adjunto contiene 2 mil millones de trazas de razonamiento en benchmarks de conocimiento amplio, razonamiento simbólico y matemáticas, con señales a nivel de token y anotaciones de verificador.

Un estudio a gran escala abarcando 30 mil millones de tokens en ocho LLMs de código abierto (parámetros de 7B a 235B) encontró que ninguna estrategia única de test-time domina universalmente. La opción óptima depende del tipo de modelo y dificultad del problema; la búsqueda de haz consistentemente tiene un rendimiento inferior en razonamiento complejo. Los resultados se alinean con hallazgos anteriores: ganancia de eficiencia de 4x de asignación adaptativa al prompt computacionalmente óptima versus best-of-N, y un benchmark de 12 modelos en siete dominios mostrando que puntuaciones bajas pueden reflejar configuración de evaluación en lugar de capacidad cuando se reporta un presupuesto restrictivo único. El marco Hariri da a estos hallazgos taxonomía: best-of-N es nivel de hoja, tree-search es nivel de prefijo. Reportar ambos como "test-time compute" sin etiquetas de régimen no hace ninguno accionable.

Para líderes de plataforma ML, el modo de fallo es el sobre-aprovisionamiento de un régimen mientras se ignoran otros. La extensión secuencial quema memoria KV-cache e incrementa latencia; el muestreo paralelo quema rendimiento y depende de la calidad del verificador; la búsqueda a nivel de prefijo añade complejidad de programación de longitudes de estado parcial irregulares. El trabajo FastTTS en ASPLOS '26 documentó reducciones de latencia de 38–68% en dispositivos con memoria limitada abordando los patrones de ejecución irregular que genera la búsqueda a nivel de prefijo—un problema único para ese régimen, invisible a cualquier benchmark que no especificara cuál se estaba ejecutando.

El artículo organiza el ecosistema de razonamiento open-weight por mecanismos del lado del modelo (régimen de entrenamiento, ventana de contexto, longitud nativa de CoT) versus mecanismos de interfaz (parámetros de muestreo, verificador, lógica de agregación), proporcionando descomposición más limpia para equipos que manejan flotas heterogéneas.

Para arquitectos de inferencia: antes de hacer benchmark de un modelo de razonamiento o configurar servicio, identifique qué régimen está ejecutando. Los presupuestos de computación, perfiles de latencia y topes de calidad no son intercambiables entre ellos.