Pare de escolher um único melhor modelo. O guia do GPT-6 da OpenAI defende o roteamento por tarefa

Muito programa de IA nas empresas ainda se apoia numa decisão tomada lá no começo: “aqui a gente usa o modelo X”. Fazia sentido quando um modelo estava claramente à frente e a diferença de preço era pequena. Faz menos sentido agora, quando um único fornecedor oferece uma família de modelos com pontos fortes diferentes, raciocínio ajustável e velocidade cobrada à parte, e um mesmo workflow agêntico chama o modelo dezenas de vezes para tarefas que não têm nada a ver uma com a outra.

O guia da OpenAI para a família GPT-6, publicado em 2 de outubro, parece um manual de produto. O que interessa para quem opera IA em produção é a arquitetura por baixo dele.

O que o guia diz

A OpenAI trata a escolha do modelo e do nível de raciocínio como um trade-off entre inteligência e preço e associa três modelos a três tipos de trabalho:

• GPT-6 Astra para o raciocínio mais difícil, quando é preciso o máximo de inteligência.
• GPT-6.1 Sol para código complexo, pesquisa e computer use. Ele também suporta workflows multiagente na Responses API, ainda em beta.
• GPT-6 Luna para tarefas focadas e repetidas em escala, com objetivo claro, como extrair campos de notas fiscais, classificar solicitações ou gerar resumos estruturados.

Em cima do modelo, escolhe-se o esforço de raciocínio: baixo para extrações de rotina e pequenas edições, médio para trabalho que exige julgamento, alto para depuração difícil ou revisão cuidadosa, e extra alto ou máximo só quando o alto não basta e o ganho justifica o tempo e o custo. Na API, o esforço pode mudar no meio da conversa sem quebrar o cache.

Depois vem a velocidade: o modo Fast dá respostas mais rápidas e estáveis por um preço maior por token, e o Ultrafast, disponível para o GPT-6 Astra, acelera a geração cobrando um adicional.

A parte de produção é a mais prática. Corte o contexto de que a tarefa não precisa. Rode tarefas independentes em paralelo. Coloque instruções estáveis e material de referência primeiro, para o cache de prompt funcionar; segundo a OpenAI, tokens de entrada em cache custam até 95% menos, dependendo do modelo, e a estimativa de custo deve incluir a escrita do cache e as tarifas de contexto longo. Use compactação em conversas longas. E, antes do deploy, rode tarefas representativas e meça taxa de sucesso, latência e custo por tarefa bem-sucedida.

A lição de arquitetura: rotear por etapa, não por fornecedor

Juntando as peças, a unidade de desenho deixa de ser “o modelo” e passa a ser a etapa:

1. Classificar a solicitação
2. Extrair os campos
3. Planejar ou comparar opções
4. Revisar o caso arriscado
5. Redigir a resposta

Modelo pequeno, esforço baixoModelo médio, esforço médio

Isso tem quatro consequências.

O roteamento vira um componente. Alguém precisa decidir, etapa por etapa, qual modelo, qual esforço e qual velocidade, e rever essa decisão quando preços e modelos mudam. Essa lógica mora num gateway ou na camada de orquestração, não espalhada pelos prompts. Na análise do C1 LLM Gateway, descrevemos o gateway como ponto de aplicação de política; rotear por tarefa é uma das políticas que ele deve carregar.

Quem decide a rota é a avaliação, não a fama do modelo. “Use o melhor modelo” é palpite. “Use a rota mais barata que passa no conjunto de avaliação desta etapa” é uma decisão que se defende diante do financeiro e da auditoria. E ainda entrega o conjunto de regressão de que você vai precisar quando um modelo for aposentado, tema do nosso texto sobre o ciclo de vida dos modelos.

Latência é orçamento, não detalhe. Uma etapa de atendimento ao cliente pode ter meta de dois segundos; uma conciliação noturna tem horas. Pagar por Fast ou Ultrafast só faz sentido onde existe meta de latência.

Contexto é linha de custo. Cache e compactação não são otimização para depois. A estrutura do prompt (o estável primeiro, o variável no fim) decide se o cache funciona, e o cache decide se um workflow de alto volume cabe no orçamento. Para empresas brasileiras, que pagam a API em dólar e fecham o orçamento em real, a diferença entre 100% e 5% do preço de entrada pesa duas vezes quando o câmbio sobe.

O que não mudou

O guia é explícito sobre algo fácil de pular: definir quais ações o modelo pode tomar sozinho e quais exigem aprovação, trocando regras genéricas do tipo “sempre pergunte” por limites claros. O roteamento otimiza custo e qualidade; não resolve quem tem autoridade. Um modelo mais barato numa etapa que pode enviar e-mail ou alterar um cadastro precisa dos mesmos controles de um modelo caro.

Também é um guia de um único fornecedor. A mesma lógica vale entre fornecedores, e uma camada de roteamento neutra mantém essa porta aberta. Para quem padronizou em Microsoft, o padrão se aplica igualmente aos modelos implantados no Microsoft Foundry: rota por etapa, conjunto de avaliação e custo por tarefa, sejam quais forem os modelos por trás.

O que fazer agora

1. Quebre cada workflow em produção em etapas e anote, por etapa, a régua de qualidade, a meta de latência e o custo aceitável.
2. Monte um conjunto pequeno de avaliação por etapa, não por aplicação.
3. Meça custo por tarefa bem-sucedida, incluindo novas tentativas, escrita de cache e tempo de correção humana, e não custo por token.
4. Leve o nome do modelo para a configuração de roteamento, para que a troca seja uma release de configuração com evidência de teste, não uma mudança de código.
5. Revise a estrutura dos prompts pensando em cache: instruções e referências estáveis primeiro, detalhes da tarefa no fim.
6. Separe autoridade de roteamento: a regra de aprovação acompanha a ação, não o modelo.

Para fechar

A pergunta “em qual modelo vamos padronizar?” está dando lugar a “que rota cada etapa merece?”. É uma pergunta melhor, porque se responde com evidência e pode ser revista sempre que preço ou modelo mudar. Quem responder etapa por etapa, com avaliação e com a métrica de custo por acerto, vai gastar menos e quebrar menos.