A conta que não fecha: por que baratear tokens não barateia IA

Um ensaio sobre engenharia de custo em LLMs, o "colapso de preços" da inferência e o que empresas brasileiras descobrem quando a fatura chega. Escrito para times de produto, engenharia e liderança que precisam decidir quanto de inteligência colocar em cada requisição — e para quem.

---

Abertura

Uma cena que tenho visto se repetir, com pequenas variações, em quase toda mesa de café com fundadores este ano começa assim: alguém puxa um slide, do nada, para justificar por que "agora vale a pena colocar IA em tudo".

Ela chegou à reunião de outubro com um slide bem simples: em março de 2023, um milhão de tokens de entrada do GPT‑4 custavam trinta dólares; em maio de 2024, o GPT‑4o entregava algo comparável por cinco. Se em 2022 o preço era de sessenta dólares, em modelos pequenos open‑source otimizados a mesma conta já rodava por seis centavos.[^1] A tela seguinte trazia o pitch: com essa queda de três ordens de magnitude, dava para embutir IA generativa em quatro fluxos do produto sem estourar orçamento. O CFO concordou. Seis meses depois, a fatura de infraestrutura, integração e retrabalho de processo havia crescido mais do que a economia prometida pela queda de tokens. O preço unitário caiu, sim. A conta, não.

A pergunta que ficou daquela reunião não me larga desde então, e é a pergunta estruturante deste ensaio: se o custo por token de LLM caiu tanto, por que a conta empresarial de IA continua difícil de fechar — e quem, de fato, paga por essa diferença? Não é uma pergunta técnica no sentido estrito. É uma pergunta sobre onde o custo vive quando ele deixa de viver no preço de lista do provedor. Sobre o que "otimizar" significa quando o número em que você olha na tabela do fornecedor já é irrelevante diante do desenho do sistema em volta dele. E, para quem opera no Brasil, sobre por que uma queda de preço mundial não se traduz em adoção proporcional aqui.

Este é um ensaio para quem já sabe o que é um token, já rodou um agente em produção, já viu uma fatura da OpenAI, Anthropic ou Google Cloud subir de forma inesperada, e desconfia — corretamente — de que o problema não está no preço, mas em algum lugar mais fundo. É denso de propósito, cita fontes com data e link para verificação, e assume que o leitor prefere um mapa honesto do território a uma promessa de atalho. Se você procura "dez truques para gastar menos com LLM", há muitos textos assim disponíveis. Este não é um deles.

Estado da arte

O campo de "otimização de custos em LLMs" — se já se pode chamar isso de campo — se organizou em pouco mais de dois anos em torno de três frames principais, que raramente conversam entre si.

O primeiro frame é o do hacker de prompt. Sua linha mestra é que o custo de LLM se resolve na fronteira: compressão de instruções, cortes de exemplos few‑shot, redução de janela de contexto, truncamento de histórico. Ferramentas como o LLMLingua, da Microsoft Research, viraram símbolo dessa vertente — compressão semântica que reduz tokens de entrada sem colapsar qualidade em uma classe grande de tarefas.[^2] É a leitura mais popular, mais escrita em blog técnico, e a que gera resultado imediato. Também é a mais superficial, porque trata o LLM como caixa isolada e não como parte de um sistema.

O segundo frame é o do engenheiro de custo. Aqui, a discussão se desloca para arquitetura: caching de prefixo, semantic caching, batch de requisições, roteamento entre modelos de tiers diferentes. É o frame defendido por guias práticos como o da Exadel (2026), que propõe um framework de engenharia de custo em LLMs análogo ao que times de infraestrutura fazem há uma década com cloud spend[^3], e por textos como o do Dataa.dev, focado em model routing, observabilidade de consumo e budget management[^4]. A promessa aqui é maior — reduções de 95 a 99% no custo por requisição em pipelines revistos, versus baseline ingênuo, segundo compilações recentes.[^5] Também é onde a maioria das empresas sérias está hoje, quando estão em algum lugar.

O terceiro frame — o menos escrito, o mais interessante — é o da governança de token como decisão de portfólio. Nessa leitura, que aparece de forma dispersa em textos como o do Startups.com Lexicon e em análises da Epoch AI sobre queda desigual de preços entre tarefas[^6][^7], otimizar custo deixa de ser um problema de engenharia e vira um problema de alocação de inteligência. Qual funcionalidade merece um modelo de fronteira? Qual aceita degradação controlada? Onde a lógica determinística substitui o LLM inteiro? Aqui a pergunta é menos "como gastar menos" e mais "como decidir melhor".

Há ainda uma quarta corrente, marginal mas relevante para este ensaio, que é a da crítica social ao custo de adoção. Estudos como o TIC Empresas 2024, discutido pelo Info4 Blog no recorte brasileiro, apontam que apenas cerca de 13% das empresas no país declararam usar IA em 2024, e que a barreira central não é o preço da API, é o pacote completo de licenciamento, infraestrutura, treinamento e reconfiguração de processos.[^8] Essa corrente raramente aparece nos guias técnicos, porém é ela que explica por que a curva global de preços não se traduz em adoção proporcional na periferia.

Este ensaio se insere na intersecção dos três últimos frames, com uma tese de trabalho: a queda de preços de tokens é real, mas resolve muito menos do que parece resolver, e o que sobra depois dela é um problema de arquitetura, governança e valores — não de preço unitário. Vou tentar sustentar essa tese sem transformá‑la em dogma, apontando onde ela quebra ao longo do caminho.

1. O que exatamente estamos contando quando contamos tokens

Antes de discutir otimização, vale ser preciso sobre o objeto. Um token, para efeito de faturamento, é uma unidade de subpalavra usada pelo tokenizer do modelo — em inglês, algo próximo de três a quatro caracteres em média; em português, um pouco menos favorável, porque o BPE dos modelos foi treinado majoritariamente em inglês e "engole" pior palavras acentuadas ou compostas. Um prompt em português médio consome, empiricamente, entre 20 e 40% mais tokens do que a mesma ideia expressa em inglês, algo que raramente entra nas planilhas de custo, mas deveria.

O provedor cobra por token em duas categorias distintas: entrada (o que você manda ao modelo — instrução, contexto, histórico, dados) e saída (o que o modelo devolve). A relação de preços entre as duas é sempre assimétrica, com saída custando de duas a cinco vezes mais que entrada, refletindo o custo de compute autoregressivo. A tabela abaixo consolida os patamares atuais aproximados, em novembro de 2025:

| Tier | Exemplo | Entrada (US$/1M tokens) | Saída (US$/1M tokens) | |---|---|---|---| | Frontier | GPT‑4.x, Claude 3.5 Opus, Gemini 1.5 Pro | 5 – 15 | 15 – 75 | | Standard | GPT‑4o, Claude 3.5 Sonnet | 2,5 – 5 | 10 – 15 | | Small/mini | GPT‑4o mini, Claude Haiku, Gemini Flash | 0,15 – 0,50 | 0,60 – 1,50 | | Open-source hospedado | Llama 3.x 70B, Mistral | 0,10 – 0,90 | 0,20 – 0,90 | | Open-source pequeno | Llama 3.x 8B otimizado | 0,03 – 0,10 | 0,05 – 0,20 |

Fontes: agregação de guias públicos de pricing (Exadel 2026, Startups.com Lexicon 2026, AIMagicX 2026, Sesamedisk 2024, e páginas oficiais dos provedores em nov/2025)[^3][^6][^9][^10].

O que essa tabela deixa ver e a maioria dos textos entusiasmados esconde é a amplitude de duas ordens de magnitude dentro do próprio universo comercial. Trocar de tier não é ajuste fino — é decisão de produto. Um agente que hoje roda em Sonnet a três dólares por milhão de tokens de entrada custa, num modelo mini, algo próximo de trinta centavos. Mas o mini não faz as mesmas coisas com a mesma qualidade em todas as tarefas — e é aí que a economia deixa de ser matemática para virar julgamento.

Há também uma segunda camada, quase invisível, que é o custo de contexto persistente. Modelos com janelas de 128 mil ou 1 milhão de tokens só cobram pelo que efetivamente é enviado, mas o design de sistemas RAG e agentes conversacionais tende a inflar contexto de forma silenciosa: histórico completo de conversa, documentos recuperados por embeddings, ferramentas descritas em detalhe, exemplos few‑shot, instruções de sistema. Um agente ingênuo em produção pode enviar 8 mil tokens de contexto a cada chamada de usuário, quando 1.500 bem selecionados dariam conta. Multiplicado por milhões de chamadas, é essa a diferença entre uma fatura administrável e uma fatura que estoura o board.

2. A queda de preços foi real, e foi desigual

Precisamos dar ao "colapso de preços" o crédito que ele merece. Entre março de 2023 e maio de 2024, o custo de rodar um modelo classe GPT‑4 caiu por um fator próximo de 6 na entrada e de 4 na saída, apenas dentro da OpenAI[^1][^11]. Quando se considera modelos abertos e otimizações de inferência, alguns modelos pequenos entregam capacidades de 2022 por menos de um centésimo do custo original.[^12] Isso não é hype — é dado observável em faturas.

Porém — e aqui entra o trabalho mais interessante do Epoch AI, publicado em 2025 — os preços não caem uniformemente entre tarefas.[^7] Tarefas de raciocínio complexo, uso de ferramentas, multi‑hop reasoning e coding avançado seguem restritas aos modelos de fronteira, cujos preços caem mais devagar que os de modelos genéricos. O Epoch mostra que, quando se controla por capacidade em benchmarks difíceis (MMLU‑Pro, GPQA, SWE‑bench), a queda real de preço fica bem abaixo da manchete de "custo caiu 95%". Em algumas classes de tarefa, o preço por unidade de capacidade real caiu no máximo pela metade em dois anos — significativo, mas nada perto do "colapso" narrado.

A consequência prática é dolorosa para quem planeja: a redução de preço aproveita muito bem tarefas simples (classificação, extração, sumarização curta), aproveita moderadamente tarefas médias (transformação de dados, RAG básico), e aproveita pouco tarefas complexas (agentes com raciocínio multipasso, revisão de código, análise clínica). Se o seu produto é um chatbot de FAQ, você surfa a curva; se é um agente autônomo com decisões encadeadas, você continua pagando quase o mesmo por qualidade equivalente à de dois anos atrás.

Em paralelo, algo pouco discutido acontece do lado do consumo: o uso cresce mais rápido do que o preço cai. Aplicações agentivas, que virou palavra do momento, encadeiam de cinco a cinquenta chamadas de LLM para completar uma tarefa que antes era uma. Cada round de reasoning, cada tool call, cada verificação intermediária é uma requisição faturada. É a lógica industrial clássica reaparecendo em software: quando o preço unitário cai, a demanda infla — o paradoxo de Jevons vestido de IA generativa.[^13] Não é acaso: é economia elementar aplicada a um insumo cognitivo cuja elasticidade de demanda é altíssima.

Assim, o quadro real é: preço unitário caindo rápido, consumo crescendo mais rápido, e queda desigual entre tarefas. A soma disso tudo, para a empresa média, é que a fatura tende a subir mesmo quando o preço cai — a menos que arquitetura, roteamento e governança acompanhem o ritmo. E aí entra o segundo problema.

3. A coreografia de chamadas — onde o custo mora de verdade

Vou insistir num ponto que é a linha mestra deste ensaio: o custo real de uma aplicação com LLM em produção não vive no preço do provedor. Vive no desenho do fluxo.

Um exemplo que aparece variado em quase todo caso técnico honesto que li: um time começa um agente de atendimento com uma única chamada a GPT‑4o para cada mensagem do usuário. Simples, funciona. Cresce, adiciona busca em base de conhecimento — agora são duas chamadas: uma para reformular a pergunta, outra para responder. Adiciona verificação de política — três chamadas. Adiciona ferramenta para consultar sistema — quatro, cinco, dependendo do fluxo. Adiciona fallback em caso de baixa confiança — mais uma. Adiciona logging estruturado que passa por LLM para categorizar — mais uma.

De repente, o que era uma requisição virou oito. E cada uma dessas oito manda o mesmo histórico de conversa, a mesma instrução de sistema, o mesmo bloco de política. O custo por mensagem do usuário, que parecia ser de meio centavo, é de quatro centavos. Multiplicado por dez mil usuários ativos por dia, dá quatrocentos dólares por dia, doze mil por mês, cento e quarenta e quatro mil por ano — em algo que a apresentação inicial estimava em cinco mil.

É neste ponto que técnicas conhecidas de engenharia de custo mostram valor. Aponto quatro que a literatura recente convergiu em recomendar como base minimamente séria[^3][^4][^5][^14]:

Prompt caching de prefixo. Provedores como Anthropic e OpenAI hoje oferecem caching de prefixo com desconto de 50 a 90% no custo de tokens repetidos. Se seu prompt de sistema tem 3 mil tokens fixos, você deveria estar pagando 10% deles, não 100%. A maioria das aplicações que auditei simplesmente não configura isso.

Semantic caching. Quando duas perguntas de usuários diferentes são semanticamente equivalentes ("como cancelar minha assinatura?" vs "quero desfazer meu contrato"), você não precisa chamar o LLM duas vezes. Sistemas de semantic cache com embeddings e limiar de similaridade evitam de 20 a 40% de chamadas em aplicações de alto volume[^5]. Custa pouco implementar. Poucas empresas fazem.

Roteamento hierárquico. Consultas simples vão para mini/flash, tarefas complexas vão para frontier, e um classificador leve — que pode ser um próprio modelo pequeno — decide qual delas é qual. Casos documentados apontam redução de 40 a 60% no custo médio por requisição sem perda perceptível de qualidade nas tarefas principais[^3][^4].

Substituição por lógica determinística. Este é o mais desconfortável e o mais impactante. Muitas chamadas de LLM em pipelines existentes fazem trabalho que uma regex, um SQL ou uma função de dez linhas fariam melhor, mais rápido e de graça. Extrair uma data de um texto estruturado, validar um formato, classificar entre três categorias fixas — não precisa de modelo generativo. A tentação de colocar LLM em tudo é o principal vetor de desperdício em 2024‑2025.

Somadas com agressividade, essas quatro técnicas justificam a estatística citada em compilações recentes de redução de 95 a 99% no custo por requisição versus baseline ingênuo[^5]. É um número real, mas precisa vir com um asterisco importante: ele mede redução em relação a um baseline que jamais deveria ter existido. É como celebrar economia de 90% ao trocar um carro engatado sempre em primeira marcha por um carro dirigido normalmente. A "otimização" é, em boa parte, correção de erro de projeto original.

4. O custo invisível que não aparece na fatura do provedor

Aqui a discussão precisa se abrir. Falamos até agora do preço por token. Mas para empresas que estão decidindo se adotam IA generativa em produção, esse preço é uma parcela — muitas vezes uma parcela minoritária — do custo total.

Um levantamento discutido pelo Info4 Blog em 2025, baseado nos dados de TIC Empresas do CGI.br, aponta que apenas cerca de 13% das empresas brasileiras declararam usar IA em 2024, e que custo de tecnologia aparece como barreira central, ao lado de fatores culturais e de capacidade interna.[^8] O ponto importante: quando entrevistadores desagregam esse "custo de tecnologia", ele quase nunca é o preço da API. É a soma de licenciamento de plataformas, infraestrutura de nuvem para embeddings e vetores, custo de observabilidade, custo de compliance com LGPD, treinamento de times, contratação de perfis escassos e — o mais caro de todos — reconfiguração de processos que existiam antes.

Um caso que ilustra bem, e é típico: uma empresa B2B de serviços profissionais avalia colocar um assistente de LLM em duas frentes — atendimento e revisão de documentos. Estimativa de tokens: mil dólares por mês. Estimativa realista de custo do projeto no primeiro ano: cento e cinquenta mil dólares, distribuídos entre plataforma de MLOps, integração com sistema legado, revisão jurídica, adaptação de fluxos de trabalho para lidar com respostas de IA, e um time interno mínimo de duas pessoas para operar. A empresa desiste — não porque tokens sejam caros, mas porque o pacote completo não fecha na margem daquele segmento. A queda de preços de token, para essa empresa, é irrelevante. A conta que precisa cair está em outro lugar.

Isto tem uma consequência conceitual que raramente aparece em textos técnicos: baratear tokens pode aumentar, não reduzir, a desigualdade de adoção de IA. Grandes empresas, com capital, times técnicos maduros e processos digitalizados, capturam quase inteiramente o ganho da curva de preço, porque o resto do custo elas já tinham absorvido. Pequenas e médias, especialmente em contextos como o brasileiro, continuam esbarrando em barreiras que a queda de preço de inferência não move. O "colapso" celebrado nas manchetes é assimétrico por natureza: quem já estava dentro do jogo joga mais barato; quem estava do lado de fora continua olhando pela janela.

Este é um ponto onde a conversa técnica precisa ceder espaço para uma leitura estrutural. Otimização de custo, no sentido mais interessante, deixa de ser sobre engenharia interna e vira uma pergunta sobre onde a IA generativa efetivamente cabe e sob que condições. Um provedor global anunciar corte de 50% no preço da API resolve muito para quem já tinha os outros 90% do problema resolvido, e pouco para quem tinha 10%. Isso não é anti‑tecnologia, é aritmética honesta.

5. Roteamento como decisão de portfólio — a governança de tokens

Se a queda de preço não resolve por si só, e se o desperdício vive no desenho do sistema, o passo natural é institucionalizar a decisão sobre quando e como usar cada modelo. Aqui a linguagem técnica precisa migrar para linguagem de gestão — e este é o movimento que separa times maduros dos que ainda estão no "let's see" com IA.

O conceito central é o de roteamento (model routing): um mesmo produto usa vários modelos, e alguma camada de decisão — pode ser uma heurística simples, um classificador leve, um roteador aprendido, ou uma combinação dos três — decide qual modelo atende qual requisição. Chen et al. (2023), em FrugalGPT, mostraram que uma cascata bem calibrada de modelos consegue reduzir custo em até 98% em benchmarks de QA, mantendo acurácia comparável ao GPT‑4 puro. Ong et al. (2024), com o RouteLLM, formalizaram o mesmo princípio como um problema de aprendizado: treinar um roteador para prever, requisição a requisição, se o modelo forte é necessário ou se o modelo barato já entrega o suficiente. Em ambos os casos a lógica é a mesma — tratar o parque de modelos como portfólio, não como escolha única.

Porém, roteamento não é só técnica de compressão de custo. É decisão de governança. Cada requisição roteada carrega, implícito, um risco: o modelo barato pode errar onde o caro acertaria, e nem todo erro tem o mesmo custo de negócio. Um resumo mal feito de reunião interna é aceitável; uma orientação clínica mal formulada, uma cláusula contratual perdida ou um cálculo tributário errado, não. Assim, a pergunta operacional deixa de ser "qual modelo é o melhor" e passa a ser "qual é a matriz de risco × custo × latência para cada classe de requisição que este produto atende".

Na prática, times que amadurecem esse desenho acabam construindo três camadas de decisão que se sobrepõem. A primeira é a classificação da requisição — o que está sendo pedido, com que criticidade, sob qual SLA. A segunda é o roteamento propriamente dito — dado o perfil da requisição, qual modelo, qual contexto, qual profundidade de raciocínio. A terceira, a mais negligenciada, é a observabilidade econômica — quanto custou cada rota, qual foi a taxa de acerto, qual foi o custo por caso resolvido de fato, não por token consumido.

| Camada | Pergunta que responde | Métrica típica | |---|---|---| | Classificação | Que tipo de pedido é este? | Distribuição por classe, taxa de misclassification | | Roteamento | Qual modelo atende melhor esta classe? | Acurácia por rota, custo médio, latência p95 | | Observabilidade | Estamos gastando bem? | Custo por caso resolvido, não por token |

Sem a terceira camada, roteamento vira teatro — o dashboard mostra queda no custo por token e ninguém percebe que o custo por caso resolvido subiu, porque o modelo barato passou a exigir três tentativas onde o caro resolvia em uma. Esse é o erro mais comum que vejo em times que "adotaram FrugalGPT" sem adaptar a métrica de sucesso: otimizaram a variável errada e comemoraram o número que não importa.

Trazendo para o vocabulário de gestão: roteamento é alocação de capital cognitivo. Cada modelo é um ativo com perfil próprio de retorno, risco e liquidez (latência). Um portfólio bem construído mistura ativos conforme o mandato — e o mandato, no caso da IA em produção, é entregar o resultado de negócio com o menor custo total de propriedade, não o menor preço por unidade de insumo. Confundir as duas coisas é o que faz uma queda de 50% na API não virar queda de 50% no P&L.

O ponto que fecha a seção é este: enquanto a discussão pública segue presa ao preço por milhão de tokens, a discussão dentro das empresas que estão levando IA a sério já migrou para governança de portfólio. Não é mais uma escolha de fornecedor, é um desenho de alocação — com política de risco, banda de custo aceitável por classe de requisição, e revisão periódica das rotas conforme os modelos evoluem. Quem trata roteamento como detalhe de engenharia continua reagindo a cada anúncio de corte de preço como se fosse notícia. Quem trata como decisão de portfólio já sabe que o próximo corte de preço só importa se mudar a fronteira de eficiência da carteira — e, na maior parte das vezes, não muda.

---