Test-Time Compute
Test-time compute (tambem chamado de inference-time compute) e a pratica de deixar um LLM "pensar" por mais tempo durante a inferencia - gerando mais tokens de raciocinio, rodando multiplas cadeias ou amostrando muitos candidatos e escolhendo o melhor - para melhorar a qualidade da resposta sem retreinar o modelo. Popularizado pelo o1 da OpenAI e pelo DeepSeek-R1 em 2024-2025, ele transformou o raciocinio de um problema de treinamento em um botao de runtime.
Test-time compute (tambem chamado de inference-time compute) e a pratica de deixar um LLM "pensar" por mais tempo durante a inferencia - gerando mais tokens de raciocinio, rodando multiplas cadeias ou amostrando muitos candidatos e escolhendo o melhor - para melhorar a qualidade da resposta sem retreinar o modelo. Popularizado pelo o1 da OpenAI e pelo DeepSeek-R1 em 2024-2025, ele transformou o raciocinio de um problema de treinamento em um botao de runtime.
Por Que Importa
Durante a maior parte da era dos LLMs, a unica forma de tornar um modelo mais inteligente era treinar um modelo maior com mais dados. O test-time compute quebrou essa dependencia. O o1 da OpenAI mostrou que o mesmo modelo base, recebendo 10-30x mais tokens para raciocinar antes de responder, iguala ou supera modelos muito maiores sem raciocinio em benchmarks de matematica, programacao e logica. Isso reformula os orcamentos de inferencia: em vez de "use o maior modelo que voce puder pagar", as equipes agora perguntam "quanto de raciocinio quero pagar nesta consulta?". A economia do raciocinio mudou - e o design de produto tambem, porque a qualidade do raciocinio agora e ajustavel no nivel da requisicao.
Como Funciona
Chain-of-thought mais longa: o modelo gera centenas ou milhares de tokens internos de raciocinio antes da resposta visivel. Mais raciocinio -> melhores respostas.
Multiplas amostras (self-consistency): gere N respostas diferentes e escolha aquela que o modelo alcanca com mais frequencia. Simples e eficaz em matematica.
Tree search / beam search: explore varios ramos de raciocinio em paralelo, descarte os ruins e estenda os promissores.
Process reward models: um segundo modelo pontua cada passo de raciocinio e direciona o modelo principal para caminhos melhores. Usado na supervisao de processo da OpenAI.
Busca guiada por verificador: gere muitos candidatos, rode um verificador externo (testes unitarios, checador matematico, juiz LLM) e retorne o melhor.
Best-of-N + rerank: variante mais simples. Gere 16-64 candidatos, reordene com um reward model e retorne o melhor.
O Trade-off
Toda tecnica de test-time compute compra precisao com latencia e custo:
Latencia: uma resposta que leva 500ms sem raciocinio pode levar 5-30 segundos com test-time compute pesado.
Custo: os tokens de raciocinio custam tanto quanto qualquer outro token de saida. Uma resposta do o1 com 10.000 tokens de raciocinio custa cerca de 30-50x uma resposta simples do GPT-4o.
Retornos decrescentes: a curva de precisao vs computacao se achata. Ir de 1.000 para 10.000 tokens de raciocinio ajuda mais do que ir de 10.000 para 100.000.
Nem sempre util: buscas factuais simples e conversa fiada amigavel nao se beneficiam do raciocinio. Forcar o o1 em "como esta o tempo" desperdica dinheiro.
Quando Usar
Matematica e logica formal: o test-time compute ajuda enormemente. Modelos de raciocinio superam modelos base em 20-40 pontos no GSM8K, MATH e AIME.
Geracao de codigo com testes: gere, rode testes, itere. A busca guiada por verificador brilha.
Planejamento de multiplas etapas: decisoes de agentes, instrucoes complexas, otimizacao com multiplas restricoes.
Consultas unicas de alto risco: medica, juridica, financeira - onde pagar 5 segundos e US$ 0,30 por uma resposta correta e barato comparado ao custo de errar.
Quando Nao Usar
UX de chat com orcamento abaixo de 1 segundo: a latencia arruina a experiencia do usuario.
Cargas de trabalho em volume: a inflacao de 20-50x nos tokens torna qualquer endpoint de alto volume antieconomico.
Recuperacao ou resumo simples: respostas de uma tacada so resolvem; pensar por mais tempo nao ajuda.
Escrita criativa aberta: mais deliberacao deixa as saidas com cara de duras.
Modelos de Raciocinio vs Modelos Comuns
| Aspecto | Comum (GPT-4o, Claude 3.5) | Raciocinio (o1, R1, Claude Opus 4.6 thinking) |
|---|---|---|
| Velocidade de resposta | Rapida | Lenta |
| Custo de token | Baixo | Alto |
| Matematica / logica | Razoavel | Excelente |
| Escrita criativa | Forte | As vezes engessada |
| UX de chat | Ideal | Exagero |
| Melhor uso | A maioria das requisicoes | Consultas dificeis |
O roteamento de modelos - enviar consultas simples para um modelo rapido e consultas dificeis para um modelo de raciocinio - e o padrao de producao usual.
Erros Comuns
Usar modelos de raciocinio em tudo: infla rapidamente o custo e a latencia sem melhorar a maioria das respostas.
Sem limite de orcamento para tokens de raciocinio: um rastro de raciocinio sem limites pode consumir milhares de dolares em uma unica consulta.
Ignorar o caching: os rastros de raciocinio costumam ser repetitivos. O prompt caching pode reduzir o custo de forma substancial.
Pular a avaliacao: as equipes assumem que raciocinio = melhor. Para o dominio especifico delas, pode nao ser - faca benchmark antes de se comprometer.
Confundir tokens de raciocinio com saida: os usuarios nao deveriam ver o rastro de raciocinio, a nao ser que pecam. E um monologo interno.
Fontes: