O preço da IA não mora no token

A pergunta parece simples: quanto custa usar esta IA? A resposta costuma vir em uma tabela com dois números, preço por token de entrada e preço por token de saída. É uma resposta útil para comparar fornecedores, mas perigosa quando vira a métrica final da decisão. Uma operação não compra tokens. Ela compra respostas, classificações, documentos processados, atendimentos resolvidos, códigos revisados e decisões tomadas. O token é a unidade de consumo do motor, não a unidade de valor do negócio. Esse desvio explica por que uma API anunciada como barata pode gerar uma conta maior no fim do mês. Um modelo pode cobrar pouco por unidade e exigir mais chamadas para chegar a uma resposta aceitável. Pode receber um contexto enorme em toda requisição, mesmo quando apenas uma pequena parte é relevante. Pode produzir uma saída longa que ninguém usa. Pode falhar em uma etapa e obrigar o sistema a tentar de novo. O preço exibido é baixo, mas o caminho percorrido até o resultado ficou caro.

A etiqueta é só o primeiro número

Uma análise publicada pela Exame nesta semana colocou o problema em termos muito mais honestos: o custo de uma aplicação de IA combina tokens de entrada e saída, tamanho do contexto, uso de cache, volume de chamadas e complexidade da tarefa ^[1]. A lista parece técnica, mas ela descreve uma diferença de gestão. O preço por token pertence ao fornecedor. O custo por tarefa pertence a quem desenhou a operação. Duas empresas podem usar o mesmo modelo e pagar valores muito diferentes porque fizeram escolhas diferentes antes e depois da chamada. Uma envia o manual inteiro em todas as interações, outra recupera apenas o trecho necessário. Uma deixa o agente repetir a mesma busca até acertar, outra define limite, validação e rota de escalonamento. Uma mede apenas a fatura da API, outra soma infraestrutura, observabilidade, suporte humano e retrabalho. O modelo é igual. O sistema econômico não é.

O custo escondido está no caminho. Pense em um agente que precisa responder a uma solicitação de suporte. A tarefa começa com uma instrução de sistema, histórico do cliente, regras da empresa e documentos recuperados. Depois vêm uma chamada para buscar dados, outra para interpretar a resposta, talvez uma terceira para corrigir o formato e uma quarta para gerar a mensagem final. Se o primeiro modelo falha em uma verificação, o fluxo tenta novamente. O usuário enxerga uma resposta. A operação enxerga uma cadeia de chamadas. É nesse ponto que a linguagem de token esconde a linguagem de processo. O contexto enviado em cada rodada pode ser maior do que a pergunta original. Ferramentas podem devolver dados redundantes. Um agente pode incluir no prompt o resultado inteiro de uma consulta quando bastariam três campos. E o sistema pode gastar o mesmo orçamento para casos simples e casos complexos, porque não existe uma rota de triagem. A conta cresce não por uma decisão isolada, mas por pequenas ineficiências repetidas milhares de vezes.

O custo de uma aplicação de IA é determinado pela combinação de diversas variáveis. Às vezes, uma opção pode ter um preço menor por token, mas exigir mais chamadas ou mais correções. Em outros casos, uma alternativa aparentemente mais cara pode alcançar o resultado esperado de forma mais eficiente e reduzir o custo total [1].

- Bin Duan, CTO da Huawei Cloud na América Latina [1]

Cache e contexto mudam a matemática

Contexto repetido é um dos lugares mais fáceis de encontrar desperdício. Instruções estáveis, políticas, exemplos, descrições de produto e trechos de uma base de conhecimento podem aparecer em centenas ou milhares de requisições. Reenviar tudo como entrada nova transforma o prompt em uma taxa recorrente. O cache de contexto existe justamente para evitar que o sistema trate informação idêntica como se fosse nova a cada chamada. A documentação oficial da API do Gemini mostra que a cobrança separa dimensões como tokens de entrada, tokens de saída, leitura de contexto em cache e armazenamento do cache ^[2]. Isso não significa que ativar cache resolva qualquer arquitetura. O contexto precisa ser estável o bastante para ser reutilizado, a invalidação precisa ser confiável e o benefício precisa superar a complexidade operacional. Mas significa que o desenho do prompt já é uma decisão financeira. A equipe que organiza o que é permanente e o que é variável consegue negociar a conta antes de negociar um desconto. O tamanho do contexto também merece uma regra simples: não envie informação apenas porque existe espaço para enviá-la. Janela maior aumenta capacidade, mas não transforma documento irrelevante em contexto útil. Um agente que recebe cem páginas para responder uma pergunta que depende de dois parágrafos não está sendo inteligente. Está sendo caro.

O que medir em uma tarefa real

• Quantidade de chamadas até a conclusão, incluindo tentativas, validações, buscas e correções.
• Tokens de entrada e saída por etapa, separando o contexto fixo da informação variável.
• Taxa de acerto na primeira tentativa e frequência de reprocessamento humano ou automático.
• Latência total e impacto de chamadas paralelas, filas, timeouts e fallback para outro modelo.
• Custo completo por tarefa, somando API, ferramentas, armazenamento, observabilidade e tempo humano de revisão.
• Valor operacional entregue, como atendimento resolvido, documento aprovado ou hora realmente economizada.

Essa medição não precisa começar com uma plataforma sofisticada de FinOps. Uma planilha com vinte execuções de uma tarefa importante já revela mais do que a comparação entre duas páginas de preços. Registre o caso, o modelo, o contexto, as chamadas, a resposta, o retrabalho e o resultado. Depois compare o custo médio, o custo do pior caso e a dispersão entre as execuções. A média mostra a tendência. O pior caso mostra o risco que a operação precisa suportar. Também vale separar duas perguntas que costumam ser misturadas. A primeira é quanto custa produzir uma resposta. A segunda é quanto custa produzir uma resposta que alguém pode usar. Se a saída barata exige dez minutos de revisão e a saída mais cara exige um minuto, o cálculo correto não é o preço da API. É a soma das duas coisas. Uma IA que reduz a fatura e aumenta o trabalho manual pode estar transferindo custo, não eliminando custo.

A arquitetura econômica começa antes do modelo

Depois de medir, as otimizações ficam menos misteriosas. Primeiro, classifique a tarefa por complexidade e use o modelo mais barato que atinge o padrão de qualidade necessário. Segundo, reduza o contexto até que cada informação enviada tenha uma função clara. Terceiro, reaproveite contexto estável com cache quando a repetição justificar a manutenção. Quarto, combine chamadas que podem acontecer em paralelo e elimine etapas que só existem porque o fluxo nunca foi revisado. Quinto, reserve o modelo mais capaz para os casos ambíguos, críticos ou que falharam na primeira rota. Isso é roteamento, mas não no sentido superficial de escolher um modelo em uma tabela. É desenhar uma política de decisão. Uma solicitação simples segue por uma rota curta. Uma solicitação com dados incompletos pede esclarecimento. Um caso de alto risco vai para revisão humana. Um resultado abaixo do limiar é escalonado para um modelo mais forte. O preço final cai porque o sistema deixa de tratar toda tarefa como exceção.

A jogada desta semana é deliberadamente pequena: escolha uma tarefa que acontece com frequência, acompanhe vinte execuções e registre tudo até o resultado final. Não comece trocando de fornecedor. Comece descobrindo onde o dinheiro está indo. Talvez o gargalo seja o modelo. Talvez seja o contexto repetido. Talvez sejam quatro chamadas que poderiam ser duas. Talvez a qualidade esteja boa, mas o processo humano de revisão esteja anulando a economia. Quando a conta estiver visível, a escolha técnica fica mais simples. Você poderá decidir entre modelo barato, modelo forte, cache, processamento em lote, roteamento ou revisão humana com base em custo e resultado, não em propaganda de preço por token. A IA não fica mais barata porque a tabela mudou. Ela fica economicamente viável quando o sistema inteiro aprende a gastar inteligência apenas onde ela produz decisão.