O custo de um token em produção

Todo time que lança uma feature com LLM lê a tabela de preços do provedor uma vez, multiplica por um número imaginário de requisições e conclui que é barato. Aí chega a primeira fatura mensal e é cinco vezes a estimativa. Não havia nada errado com a tabela de preços. O que estava errado era o modelo de como os tokens são consumidos. Um token em produção não é um preço unitário. É um preço unitário multiplicado por um formato, e o formato é o que você controla de fato.

Tokens são um custo unitário com um formato

A conta de uma requisição é tokens de entrada mais tokens de saída, e o lado da entrada é quase sempre onde mora a surpresa. Um system prompt de dois mil tokens é enviado em toda chamada. Um histórico de conversa cresce a cada turno. Um contexto de RAG recheado com dez chunks porque dez pareceu mais seguro que quatro. Um loop de tool calling que manda a transcrição inteira de volta a cada passo. Multiplique qualquer um desses pelo tráfego real e o preço por token deixa de importar. O formato importa: quanto você envia, com que frequência e quantas vezes por ação do usuário.

Para onde o dinheiro vai de verdade

Nas features que auditei, os três maiores multiplicadores escondidos são sempre os mesmos. Retries: um timeout seguido de retry dobra o custo das requisições mais lentas, que também são as maiores. Loops de agente: uma tarefa de oito passos envia o contexto oito vezes, então o custo cresce mais ou menos com o quadrado do tamanho da conversa, não linearmente. E excesso de retrieval: times enchem o contexto com trechos extras por segurança e pagam por cada um em toda requisição, tenha o modelo usado ou não. Nenhum desses aparece na estimativa feita pela tabela de preços. Todos aparecem na fatura.

As cinco alavancas

Quando você enxerga custo como formato, as alavancas ficam óbvias. Encurte o que envia: enxugue o system prompt, resuma turnos antigos, recupere menos chunks e melhores. Cacheie o que repete: um prefixo estável pode ser cacheado pela maioria dos provedores, e uma requisição determinística pode ser cacheada por você. Roteie por dificuldade: um modelo pequeno cuida da maioria fácil e um modelo de fronteira cuida da minoria difícil. Limite os loops: orçamento de passos é orçamento de custo. E limite a saída: peça o formato que precisa, com structured outputs, em vez de deixar o modelo escrever uma redação que você depois vai parsear.

Custo também é decisão de latência e qualidade

O mesmo formato que dirige o custo dirige a latência, porque tokens de entrada levam tempo para processar e tokens de saída levam tempo para gerar. Cortar um contexto pela metade geralmente deixa a feature mais rápida e mais barata ao mesmo tempo. Às vezes deixa melhor, porque um modelo que recebe quatro trechos relevantes responde com mais precisão do que um que recebe doze misturados. É o caso raro em engenharia em que os três eixos apontam para o mesmo lado, e vale aproveitar antes de partir para um modelo menor.

Orçamento por feature, não por mês

A prática que empurro em todo time é anexar um orçamento de custo a cada feature na fase de design, expresso por ação do usuário: esta sumarização pode custar tanto, esta execução de agente pode custar tanto. Depois medir em produção com o mesmo cuidado que latência, por feature e por tenant, e alertar quando uma feature ultrapassa o orçamento. A fatura mensal é um indicador atrasado. O custo por ação é o indicador antecipado, e é ele que avisa que uma mudança de prompt ou um bug de loop está queimando dinheiro em silêncio três semanas antes de o financeiro perceber.