GPT-5.6 e o controle de esforço de raciocínio em LLMs

Quando pensar mais vira custo

Controle de esforço de raciocínio virou o ajuste mais importante para quem opera LLM em produção. Todo mundo já sentiu essa dor na prática: você aumenta os tokens de pensamento para melhorar a resposta em matemática ou código, e de repente a latência dobra, a conta da API triplica e o usuário abandona antes do resultado chegar. Foi exatamente essa tensão que voltou ao centro com a família GPT-5.6, lançada em três tamanhos com cinco ou seis níveis de esforço. Não é mais só sobre ter o modelo mais inteligente, e sim sobre dosar inteligência por chamada sem quebrar o produto.

O fato: raciocínio com modos virou padrão

Já faz quase dois anos desde que a OpenAI lançou o o1 e popularizou a ideia de modelos de raciocínio. Quatro meses depois veio o DeepSeek-R1, com a receita aberta de reinforcement learning with verifiable rewards, o famoso RLVR, que mostrou como transformar um LLM convencional em um modelo que pensa passo a passo. Agora a GPT-5.6 consolida o próximo passo lógico: não basta um modelo que raciocina, ele precisa raciocinar em vários níveis. Cada tamanho vem com modos como baixo, médio, alto e variações extras, e isso está virando padrão de mercado. Outros labs seguem o mesmo caminho porque cliente empresarial não quer só acurácia, quer previsibilidade de custo.

Para deixar claro, modelo de raciocínio aqui não significa que a máquina raciocina como um humano. Em pesquisa de LLMs, o termo descreve um modelo que gera um trace intermediário, uma espécie de rascunho interno onde ele testa hipóteses, volta atrás e se corrige antes da resposta final. Esses momentos de autocorreção ficaram conhecidos como momentos aha. O ponto central do artigo original é justamente esse: como treinar um único modelo para operar bem em diferentes orçamentos de pensamento, em vez de treinar vários modelos separados para cada caso.

Como funciona o controle de esforço na prática

Existem duas formas básicas de melhorar desempenho em tarefas de raciocínio: escalar em treino e escalar em inferência. No treino, a receita do DeepSeek-R1 foi direta e brutalmente eficaz. Você pega domínios verificáveis, principalmente matemática checada com SymPy ou similar e código checado com compilador e testes unitários, e dá recompensa simples, zero para errado e um para certo. O trace intermediário nem entra na recompensa. Mesmo assim, só com o sinal do resultado final, o modelo aprende a gerar explicações, fazer backtracking e se corrigir. É contraintuitivo, mas funciona, e o paper mostra que tentar supervisionar cada passo com process reward models não ajudou tanto quanto se esperava.

Na inferência, controlar esforço significa controlar quantos tokens de pensamento o modelo pode gastar antes de responder. Na visão de operador, isso se traduz em três mecanismos que quase todo provider usa por baixo dos panos, mesmo que não conte. O primeiro é budget forcing, truncar ou estender a geração com prompts de sistema e tokens de parada. O segundo é mistura de dados no fine tuning, onde o mesmo modelo vê exemplos curtos e longos para a mesma pergunta, condicionados a um token de modo como 'modo rápido' ou 'modo profundo'. O terceiro, e mais importante para GPT-5.6 e similares, é RL com penalidade de tamanho, onde a recompensa combina acerto com custo de tokens. Em inferência plausível, o modelo aprende uma política que tenta resolver com poucos passos e só continua se a confiança interna estiver baixa.

API, custo e latência

Pensa em arquitetura real. Quando você chama a API com effort baixo, o modelo gera algo como 300 a 800 tokens ocultos, responde em 2 a 4 segundos e custa centavos. No effort alto, o mesmo prompt pode gerar 8 mil a 20 mil tokens ocultos, levar 40 a 90 segundos e custar dez vezes mais. E tem um detalhe que muita gente ignora: esses tokens de raciocínio contam na janela de contexto e na fatura, mesmo que você não veja o trace completo. Para produto, isso muda tudo. Um chatbot de suporte não pode esperar 60 segundos por uma resposta perfeita, enquanto um agente de engenharia que vai gerar um patch crítico pode e deve esperar. O ajuste fino aqui não é prompt, é roteamento por esforço.

O que isso muda para quem constrói

Quem ganha com esforço controlável é quem tem carga heterogênea. Se você opera um assistente, um copiloto de código ou um pipeline de agentes, pode separar tarefas fáceis e difíceis e pagar inteligência só onde importa. Quem perde é quem usava um único setting para tudo, ou pagava caro no modo max para responder 'qual é seu horário de funcionamento', ou entregava resposta fraca no modo mini para um problema de otimização. O ajuste que precisa ser feito agora é operacional, não acadêmico. Você precisa medir taxa de acerto por nível de esforço no seu próprio dataset, não no benchmark do provider.

Uma ação prática que funciona bem: crie três faixas no seu roteador. Use esforço baixo para classificação, extração e respostas diretas com contexto curto. Use esforço médio para resumos, buscas com ferramentas e código simples. Reserve esforço alto apenas para matemática, debugging complexo e planejamento multi etapa. Registre por uma semana latência p95, custo por mil chamadas e taxa de re-tentativa. Na maioria dos casos que eu vejo, 70 por cento do tráfego roda bem no baixo e médio, e só 10 a 15 por cento realmente precisa do alto. O resto é preciosismo que queima margem.

• Instrumente custo por tarefa, não por modelo, e compare baixo contra alto no seu dado real.
• Use fallback progressivo: tente no médio, se a validação falhar, reenvie no alto com o trace anterior como contexto.
• Defina timeouts diferentes por esforço para não travar fila e estourar SLO em pico.

Isso escala ou só move o gargalo

Aqui fica a dúvida real que o hype esconde. Ter cinco ou seis botões de esforço resolve o problema ou só transfere a decisão difícil para o desenvolvedor. Na teoria, é ótimo ter granularidade. Na prática, calibrar esses modos é caro. Treinar com recompensa que mistura acerto e tamanho exige curadoria de dados verificáveis, avaliação constante contra reward hacking, onde o modelo aprende a responder curto e confiante mesmo quando está errado, e muita infra de RL. E tem o risco silencioso: modos baixos tendem a alucinar com elegância, porque cortam justamente o backtracking que gerava os momentos aha. Você economiza tokens, mas aumenta retrabalho humano.

Outro ponto que me incomoda: latência não cai linearmente com tokens. Por causa de batching, KV cache e orquestração de ferramentas, às vezes o modo médio custa quase o mesmo que o alto em tempo real, mas entrega bem menos qualidade. Vale a pena então manter seis níveis ou dois bem calibrados já resolvem. Minha leitura é que o mercado vai convergir para três modos úteis, rápido, equilibrado e profundo, e o resto é diferenciação de marketing. Ainda assim, para quem fatura por chamada, essa granularidade é poder de negociação.

Conclusão

No fim, modelos com esforço ajustável não são uma feature, são um novo modelo de custo para IA. A pergunta que fica é simples e incômoda: no seu produto, quanto de inteligência você realmente precisa pagar por resposta. Se você ainda não mede isso por tarefa, já está pagando caro demais.