O problema
"Usa o modelo mais caro, assim garantimos qualidade." É a resposta mais fácil de defender numa reunião e a mais cara de manter em produção. O problema não é que o modelo maior seja ruim — é que "garantir qualidade" não é um requisito mensurável, e sem um requisito mensurável não existe forma de saber se o modelo menor já teria bastado.
A economia de tokens não é sobre economizar dinheiro por economizar. É sobre alinhar o custo de execução ao custo do erro. Um classificador interno que erra ocasionalmente e tem revisão humana no fim da esteira pode rodar num modelo mais barato e rápido. Um assistente que gera a resposta final enviada a um cliente, sem revisão, onde um erro factual gera retrabalho ou dano de reputação, justifica um modelo com mais capacidade — não porque é mais "seguro" em abstrato, mas porque o custo do erro nesse caso é alto.
O framework: custo do erro, não benchmark
Comparar modelos por pontuação em benchmark público é o primeiro instinto e o critério errado pra a maioria das decisões de arquitetura. Benchmarks medem capacidade geral; a decisão que importa é local ao seu caso de uso.
Pergunte, nessa ordem:
- Qual é o custo de um erro nesta tarefa específica? Alto (decisão financeira, saída pro cliente sem revisão, ação irreversível) empurra pra mais capacidade. Baixo (rascunho revisado, classificação interna, sugestão descartável) não justifica o modelo mais caro.
- Existe revisão humana ou automatizada no caminho? Se existe, o modelo pode errar mais e ainda assim o sistema como um todo ser confiável — a revisão é a rede de segurança, não o modelo sozinho.
- A tarefa é sensível a latência? Um modelo maior geralmente é mais lento; se o produto exige resposta em tempo real, isso entra na equação junto com custo.
- O volume é alto o suficiente pra o custo por token importar de verdade? Um endpoint chamado 10 vezes por dia não tem a mesma pressão de custo que um chamado 10 milhões de vezes.
Prompt caching e batch processing mudam a equação
Duas alavancas mudam o cálculo de custo sem trocar de modelo:
Prompt caching reduz o custo de reenviar o mesmo contexto grande repetidamente — um system prompt extenso, um documento de referência, instruções de ferramenta. Se sua aplicação reenvia o mesmo bloco de contexto em múltiplas chamadas, cachear esse bloco pode ser uma redução de custo maior do que trocar pra um modelo mais barato e perder qualidade.
Message Batches processa um volume grande de requisições de forma assíncrona, com desconto sobre o processamento padrão, sem SLA de latência garantido. Faz sentido pra volume alto, sem requisito de resposta imediata — reprocessamento de um catálogo inteiro, por exemplo. Não faz sentido pra uma interação de usuário em tempo real, que precisa de resposta síncrona.
O erro comum é tratar essas duas alavancas como truques de otimização de última hora, quando na verdade deveriam entrar na decisão de arquitetura desde o início — a escolha de modelo, cache e batch são parte do mesmo cálculo de custo, não etapas separadas.
O padrão a evitar
Usar o modelo mais caro por padrão, sem medir o requisito, é o distrator mais comum em cenários desse domínio. Ele nunca é tecnicamente errado — o modelo maior quase sempre "funciona" — mas ignora a restrição real: custo e latência não são infinitos, e gastar capacidade onde o erro é barato é desperdício de orçamento que poderia ir pra onde o erro é caro.
Coloque em prática
O laboratório desta lição implementa uma função que recebe sinais sobre uma tarefa (custo do erro, existência de revisão, sensibilidade a latência, volume) e recomenda o nível de capacidade de modelo apropriado, junto com se cache ou batch deveriam entrar na conta.