Regimes de scaling em tempo de inferência exigem perfis de avaliação distintos

Um artigo de 14 autores da Case Western Reserve publicado em 4 de agosto no arXiv identifica uma falha crítica em como a comunidade de inferência avalia "test-time scaling": o rótulo conflua três algoritmos estruturalmente distintos cujos custos de computação, modos de falha e propriedades estatísticas não se transferem entre si.

O artigo formaliza test-time scaling como inferência orçada sobre a árvore de prefixo de um modelo autorregressivo e particiona o espaço de design em três regimes. Scaling sequencial de trajetória única estende a deliberação ao longo de um caminho—o modelo continua pensando antes de se comprometer. Scaling em nível folha amostra candidatos completos e os agrega através de votação ou verificação (best-of-N e variantes). Scaling em nível de prefixo busca estados parciais inacabados via beam search, MCTS ou expansão guiada por modelo de recompensa de processo. Cada um tem uma unidade de orçamento distinta: tokens em um único contexto, tokens amostrados totais ou nós em uma árvore de estado parcial. Um artigo relatando precisão com orçamento de tokens mas sem especificação de regime é, sob este framework, ininterpretável. Isso descreve a maioria dos resultados publicados.

A crítica de avaliação é concreta. Relatar precisão sem o protocolo de inferência torna os resultados incomparáveis entre estudos. Os autores propõem um perfil de avaliação que recupera métricas comuns (pass@k, acurácia de votação majoritária) enquanto separa o desempenho do sistema ponta a ponta dos diagnósticos de banco de candidatos—crítico quando um verificador roda no topo de um amostrador. Eles distinguem reprodutibilidade de repetição exata de reprodutibilidade distribucional e especificam os artefatos (sementes aleatórias, configs de amostrador, checkpoints de verificador) necessários para cada uma. O conjunto de dados acompanhante contém 2 bilhões de traços de raciocínio em benchmarks de conhecimento amplo, raciocínio simbólico e matemática, com sinais em nível de token e anotações de verificador.

Um estudo em larga escala abrangendo 30 bilhões de tokens em oito LLMs open-source (7B a 235B parâmetros) descobriu que nenhuma estratégia única de test-time domina universalmente. A escolha ótima depende do tipo de modelo e dificuldade do problema; beam search consistentemente desempenha mal em raciocínio complexo. Os resultados se alinham com descobertas anteriores: ganho de eficiência de 4x de alocação adaptativa ao prompt computacionalmente ótima versus best-of-N, e um benchmark de 12 modelos em sete domínios mostrando que pontuações baixas podem refletir configuração de avaliação em vez de capacidade quando um orçamento restritivo único é relatado. O framework Hariri dá aos achados taxonomia: best-of-N é nível folha, tree-search é nível de prefixo. Relatar ambos como "test-time compute" sem rótulos de regime torna nenhum dos dois acionável.

Para líderes de plataforma ML, o modo de falha é over-provisioning de um regime enquanto ignora outros. Extensão sequencial queima memória de KV-cache e aumenta latência; amostragem paralela queima throughput e depende da qualidade do verificador; busca em nível de prefixo adiciona complexidade de agendamento de comprimentos de estado parcial irregulares. O trabalho FastTTS em ASPLOS '26 documentou reduções de latência de 38–68% em dispositivos com memória limitada abordando os padrões de execução irregular que a busca em nível de prefixo gera—um problema único para esse regime, invisível a qualquer benchmark que não especificasse qual estava rodando.

O artigo organiza o ecossistema de raciocínio open-weight por mecanismos do lado do modelo (regime de treinamento, janela de contexto, comprimento nativo de CoT) versus mecanismos de interface (parâmetros de amostragem, verificador, lógica de agregação), fornecendo decomposição mais limpa para equipes gerenciando frotas heterogêneas.

Para arquitetos de inferência: antes de fazer benchmark de um modelo de raciocínio ou configurar servimento, identifique qual regime você está executando. Orçamentos de computação, perfis de latência e tetos de qualidade não são intercambiáveis entre eles.