Como reduzir custo de tokens de LLM: cache, roteamento e compactação

Como reduzir custo de tokens de LLM: cache, roteamento e compactação

Para reduzir o custo de tokens de um LLM, comece medindo quanto cada fluxo gasta por tarefa concluída. Depois aplique três alavancas, nesta ordem: reaproveitar o que se repete com prompt caching, enviar tarefas simples para modelos menores e encurtar o contexto que não precisa ir inteiro. Cada corte só vale se um conjunto fixo de testes mostrar que a qualidade se manteve.

Principais pontos

• Meça custo por tarefa resolvida, não custo por chamada. Uma resposta barata que gera retrabalho sai cara.
• Prompt caching funciona melhor quando a parte fixa do prompt (instruções, regras, catálogo) vem primeiro e a parte variável (a mensagem do cliente) vem por último.
• Modelos menores atendem bem tarefas de classificação, extração e respostas padronizadas. Reserve o modelo maior para o que exige julgamento.
• Compactar contexto significa resumir histórico e recuperar só os trechos relevantes, sem apagar o que a decisão depende.
• Todo corte de custo deve passar por um conjunto de casos de teste com critério de aprovação definido antes da mudança.

Onde o custo de tokens realmente nasce

Antes de otimizar, é preciso saber o que está sendo pago. O custo de uma chamada vem de duas partes: os tokens de entrada (tudo o que você envia ao modelo) e os tokens de saída (o que ele escreve). Em muitos fluxos de empresa, a entrada domina, porque cada chamada repete as mesmas instruções, as mesmas regras de negócio e um histórico de conversa que só cresce.

Um agente de atendimento no WhatsApp, por exemplo, costuma enviar a cada mensagem o prompt de sistema completo, a política de trocas, o tom de voz e as últimas mensagens da conversa. O cliente escreveu uma frase curta, mas a chamada carrega um bloco enorme que quase não muda.

Por isso a primeira tarefa é medir. Registre, por fluxo, quantos tokens de entrada e saída cada chamada usa, quantas chamadas são necessárias para resolver um caso e quantos casos precisam de intervenção humana. A prática de unit economics, descrita pela FinOps Foundation, ajuda a ligar o gasto a uma unidade de valor, como "conversa resolvida" ou "pedido classificado". Sem essa unidade, não há como saber se uma mudança melhorou ou piorou a conta.

Como o prompt caching reduz o custo de entrada?

Prompt caching permite que o provedor reaproveite o processamento de um trecho inicial do prompt que se repete entre chamadas. Em termos práticos, a parte estável do prompt é processada uma vez e as chamadas seguintes pagam menos para lê-la. Os detalhes variam por provedor, mas a lógica geral é a mesma. A documentação da Anthropic sobre prompt caching descreve o mecanismo, o tamanho mínimo do trecho elegível, o tempo de validade do cache e a diferença de custo entre escrever e ler. Confira esses valores na fonte, pois mudam com o tempo e com o modelo.

O que depende de você é a organização do prompt. O cache costuma valer para o prefixo: se qualquer parte do início mudar, o reaproveitamento se perde dali em diante. Isso leva a regras simples de montagem:

• Coloque primeiro o que não muda: papel do agente, regras, política da empresa, exemplos fixos e definições de ferramentas.
• Coloque depois o que muda pouco: dados do cliente ou da conta, que valem para a sessão inteira.
• Coloque por último o que muda a cada chamada: a mensagem atual e os resultados de ferramentas.
• Não insira data, hora, identificador de requisição ou qualquer valor dinâmico no começo do prompt. Um único campo variável no início anula o cache.
• Mantenha a ordem e o texto das ferramentas estáveis entre chamadas. Reordenar a lista já muda o prefixo.

Há um ponto de atenção: o cache tem validade curta. Fluxos com tráfego contínuo aproveitam bem; fluxos com chamadas espaçadas podem pagar a escrita repetidas vezes sem ganhar a leitura. Antes de investir, verifique nos registros do provedor quantos tokens estão sendo lidos do cache e quantos estão sendo escritos. Se a taxa de leitura for baixa, o problema quase sempre está na ordem do prompt ou no intervalo entre chamadas.

Se você ainda está escrevendo o prompt de atendimento, vale ler como escrever instruções para um agente de atendimento. Um prompt bem separado em blocos fixos e variáveis é, ao mesmo tempo, mais fácil de manter e mais barato de executar.

Quando usar um modelo menor?

Roteamento de modelos é a prática de escolher o modelo conforme a dificuldade da tarefa. Nem toda etapa de um fluxo exige o modelo mais capaz. Muitas são mecânicas: identificar a intenção da mensagem, extrair nome e número do pedido, classificar o assunto, formatar uma resposta a partir de dados já validados.

Um guia de decisão simples, em lista:

• Classificação de intenção com poucas categorias claras: candidato a modelo menor.
• Extração de campos de um texto curto (nome, data, número de pedido): candidato a modelo menor.
• Reescrita ou formatação de uma resposta já decidida por regra: candidato a modelo menor.
• Resposta que combina várias políticas, exceções e tom delicado (reclamação, cobrança): mantenha o modelo maior ou escale para humano.
• Decisão com consequência financeira ou jurídica: modelo maior com validação, e aprovação humana quando a política exigir.
• Tarefa nova, sem casos de teste: comece pelo modelo maior, meça, e só então tente descer.

Existem duas formas comuns de rotear. A primeira é estática: cada etapa do fluxo tem um modelo definido de antemão. É a mais previsível e a mais fácil de auditar. A segunda é dinâmica: um classificador leve decide, por mensagem, se ela vai para o modelo pequeno ou para o grande. Ela economiza mais em volume alto, mas introduz um novo ponto de erro, porque um classificador que subestima a dificuldade manda casos complexos para o modelo errado.

Uma regra prudente é começar estático, por etapa, e só adotar roteamento dinâmico quando houver dados suficientes para validá-lo. Defina também uma saída de segurança: se o modelo menor devolver baixa confiança, formato inválido ou uma resposta que falha numa verificação, a chamada sobe para o modelo maior ou vai para uma pessoa. Esse desenho é parecido com os padrões de encadeamento e roteamento descritos no artigo da Anthropic sobre como construir agentes eficazes.

Se a dúvida for comparar modelos de provedores diferentes para uma tarefa específica, o método de teste do artigo Kimi K2.5 vs Claude Opus 4.5 mostra como montar uma comparação com critérios claros em vez de impressões.

Como compactar o contexto sem perder o que importa?

O terceiro caminho é enviar menos texto. Contexto maior não significa resposta melhor: informação irrelevante gasta tokens e pode distrair o modelo. A Anthropic discute isso em engenharia de contexto para agentes, com a ideia de manter no contexto apenas o conjunto mais enxuto de informações que sustenta a próxima decisão.

Técnicas que costumam funcionar:

• Resumir o histórico: em vez de reenviar toda a conversa, mantenha as últimas mensagens literais e um resumo estruturado do que veio antes (pedido do cliente, dados já confirmados, pendências).
• Recuperar, não colar: em vez de incluir o manual inteiro, busque os trechos relevantes para aquela pergunta. É a lógica de recuperação descrita em materiais como o da AWS sobre geração aumentada por recuperação.
• Limpar resultados de ferramentas: uma consulta a ERP ou CRM pode devolver dezenas de campos. Passe ao modelo apenas os campos que a decisão usa.
• Limitar a saída: peça respostas curtas e em formato definido quando o fluxo não precisa de texto longo. Tokens de saída costumam custar mais que os de entrada.
• Remover exemplos redundantes: poucos exemplos bons valem mais que muitos parecidos.

O risco da compactação é descartar um detalhe que mudava a decisão. Um resumo que esquece "o cliente já pediu cancelamento" faz o agente oferecer o produto de novo. Por isso, defina quais fatos nunca podem ser perdidos (identificação, promessas feitas, restrições, consentimento) e guarde-os em campos estruturados fora do resumo livre. Em contexto de LGPD, aproveite a compactação também para não carregar dados pessoais desnecessários na chamada: enviar menos é, ao mesmo tempo, mais barato e mais alinhado à minimização de dados.

Como provar que a qualidade não caiu?

Economizar sem medir é apostar. Antes de qualquer mudança, monte um conjunto de casos de teste com situações reais anonimizadas: os casos comuns, os difíceis e os que já deram problema. Defina para cada um o que é uma resposta aceitável. Esse conjunto vira a régua para comparar a configuração atual com a configuração mais barata.

A Anthropic explica como estruturar esse tipo de avaliação em Demystifying evals for AI agents, e a OpenAI mantém um guia de avaliações com a mesma lógica. Quando a correção exige julgamento e não apenas comparação exata, pode-se usar outro modelo como avaliador, desde que calibrado por revisão humana. O artigo sobre LLM como juiz detalha esse método.

Defina três números antes de começar, sem inventar metas de mercado: o piso de qualidade aceitável nos testes, o limite de casos que podem ir para humano e o custo por tarefa resolvida na configuração atual. Uma mudança só entra em produção se mantiver a qualidade acima do piso e reduzir o custo por tarefa. Se reduzir o custo e aumentar o retrabalho humano, o ganho é ilusório. Para estruturar os critérios de decisão de um piloto, o guia de métricas e gates de um piloto de automação serve de base.

Plano passo a passo para aplicar

A ordem importa porque cada passo cria a base de medição do seguinte:

• Passo 1: escolha um único fluxo com volume recorrente e registre tokens de entrada, tokens de saída, número de chamadas e desfecho por caso.
• Passo 2: monte o conjunto de testes e fixe o piso de qualidade com quem é dono do processo.
• Passo 3: reorganize o prompt em blocos fixos primeiro e variáveis por último, remova valores dinâmicos do início e ative o cache.
• Passo 4: confira nos registros se as leituras de cache realmente acontecem. Se não, corrija a ordem ou o intervalo entre chamadas.
• Passo 5: identifique as etapas mecânicas do fluxo e teste um modelo menor em cada uma, uma por vez, com fallback para o modelo maior.
• Passo 6: compacte o contexto (resumo estruturado, recuperação de trechos, limpeza de retornos de ferramentas) e rode os testes de novo.
• Passo 7: compare custo por tarefa resolvida e qualidade com a linha de base. Decida se expande, ajusta ou para.
• Passo 8: mantenha o monitoramento. Modelos e preços mudam, e um prompt novo pode quebrar o cache sem aviso.

Cenário ilustrativo: uma loja online tem um agente que responde dúvidas de pedido e troca no WhatsApp. Cada chamada envia a política de trocas completa, o tom de voz e todo o histórico. A equipe reorganiza o prompt para deixar política e tom no início, move o horário atual para o final, usa um modelo menor só para identificar a intenção e extrair o número do pedido, e passa a enviar um resumo estruturado em vez da conversa inteira. Em seguida roda o mesmo conjunto de casos de teste antes e depois. Se os casos de reclamação delicada pioraram, mantém o modelo maior apenas nessa rota. O ganho aparece no custo por pedido resolvido, e a qualidade é comprovada pelos testes, não por impressão. Para ver o que mantém humano nesse tipo de fluxo, leia SAC com IA: o que automatizar e o que manter.

Como esse trabalho se encaixa no método de implantação

O método que usamos para projetos de IA segue quatro movimentos, e a otimização de custo cabe em todos. Mapear: levantar o processo atual e a linha de base de gasto e qualidade. Limitar: restringir dados e ações, o que também reduz o contexto enviado. Pilotar: aplicar cache, roteamento e compactação em um fluxo real, com registros e métrica de sucesso combinada. Transferir: entregar o painel de custo por tarefa e a rotina de reavaliação, para que a equipe decida se expande, ajusta ou interrompe.

A otimização deve vir depois de o fluxo funcionar e ser medido. Cortar custo de um agente que ainda erra apenas deixa o erro mais barato.

Perguntas frequentes

Prompt caching muda a resposta do modelo? Em princípio não, pois o cache reaproveita o processamento do mesmo trecho de entrada e o conteúdo enviado continua igual. O que pode mudar é a latência, em geral para melhor. Ainda assim, rode seus testes depois de ativar, porque reorganizar o prompt para o cache funcionar pode alterar o comportamento.

Modelo menor sempre sai mais barato no fim? Nem sempre. Se ele erra mais e gera repetição de chamadas, correção manual ou escalonamento para humano, o custo por tarefa resolvida pode subir. Compare sempre o custo total até a resolução, não o preço por token isolado.

Por onde começar se o gasto já está alto e não há medição? Comece registrando tokens e desfechos de um único fluxo por um período curto, sem mudar nada. Com essa linha de base, a primeira ação costuma ser reorganizar o prompt para o cache, que muda menos o comportamento do que trocar de modelo. Só depois teste modelos menores e compactação.

Compactar contexto afeta a conformidade com a LGPD? Pode ajudar, desde que o resumo não crie um novo armazenamento sem controle. Enviar apenas os dados necessários ao modelo está alinhado à minimização, mas resumos que contenham dados pessoais precisam de regras de retenção e acesso. Para o enquadramento geral, veja LGPD e inteligência artificial.

Fontes

• Anthropic: prompt caching
• Anthropic: Effective context engineering for AI agents
• FinOps Foundation: unit economics
• Anthropic: Demystifying evals for AI agents