Custo de LLMs em produção: como estimar e controlar

O custo de LLMs em produção é um daqueles assuntos que todo mundo ignora até a primeira fatura chegar. Aí o papo muda de tom rápido.

Se você está construindo qualquer coisa com LLM, seja um agente, uma ferramenta interna ou um produto com acesso a usuários reais, o custo vai aparecer cedo ou tarde. E quando aparece sem você ter feito a conta antes, dói mais do que deveria.

O que faz o custo de LLM crescer sem você perceber

O modelo cobra por token: entrada, saída, e dependendo do provedor, tokens de contexto em cache também entram na conta. O problema não é o preço unitário em si. É o volume silencioso que cresce enquanto você não está olhando.

Três situações que derrubam a estimativa original:

• Prompts que crescem com o uso: quando você concatena histórico de conversa ou documentos sem limitar o tamanho, cada chamada fica maior que a anterior. Parece pequeno no início, explode com escala.
• Chamadas auxiliares desnecessárias: chamar o modelo para validar, resumir ou classificar coisas que lógica simples resolve custa mais do que parece no agregado diário.
• Modelo errado para a tarefa: usar o modelo mais caro para absolutamente tudo é o desperdício mais comum que vejo em projetos com LLM. E o mais fácil de corrigir.

Não é o preço por token que mata o orçamento. É o volume mal calculado antes de escalar.

Como estimar o custo antes de ir para produção

Você precisa responder três perguntas antes de qualquer deploy com LLM:

• Quantas chamadas por hora, dia e mês esse fluxo vai gerar?
• Qual o tamanho médio do prompt de entrada e da resposta esperada?
• Quais chamadas são críticas para qualidade e quais são auxiliares?

Com esses números na mão, você consegue calcular uma estimativa razoável. A página de preços da Anthropic e dos outros provedores tem o custo por token por modelo em tabela limpa. Você multiplica o volume esperado, adiciona uma margem de 30% para variação real, e já tem um número honesto para apresentar antes de colocar o projeto para rodar.

O erro clássico é estimar só o caminho feliz: uma chamada limpa, resposta curta, tudo certo. Na prática, você vai ter retries, contextos maiores do que o planejado e casos de borda que o modelo leva mais tokens para resolver. Conta isso desde o início ou vai se surpreender depois.

Os padrões que mais pesam na conta de LLMs em produção

Alguns padrões têm custo estruturalmente mais alto. Não são problemas em si, mas você precisa saber o que está escolhendo ao adotá-los.

Conversas longas sem compressão de contexto

Cada mensagem nova em um chat que mantém histórico completo aumenta o tamanho do prompt de entrada. Uma conversa de 30 trocas pode facilmente custar 10x mais do que a primeira mensagem. Sem estratégia de compressão ou truncamento, isso escala de um jeito que vai aparecer na fatura antes do que você espera.

Agentes com múltiplos passos

Um agente que faz 5 chamadas por ciclo custa 5x mais por operação do que uma chamada direta. Não é motivo para evitar agentes, mas é motivo para medir quantos passos o agente realmente usa no fluxo real, não só no caminho feliz do seu teste local.

Classificação e roteamento com modelo pesado

Usar Claude Opus ou GPT-4o para classificar a intenção de uma mensagem antes de chamar o modelo correto é over-engineering caro. Um modelo menor resolve essa tarefa com qualidade suficiente e a uma fração do custo. Essa escolha tem impacto direto no custo por operação.

Como monitorar o custo de LLMs em produção em tempo real

Estimar na largada não resolve o problema a longo prazo. Você precisa de visibilidade contínua do que está acontecendo.

A maioria dos provedores expõe uso de tokens por chamada na resposta da API. Se você está logando essas respostas (e deveria estar), já tem os dados. O próximo passo é agregar por fluxo, por usuário ou por feature, dependendo do que faz sentido para o seu produto.

O LiteLLM como gateway centralizado facilita essa visibilidade porque você passa todas as chamadas por um ponto único que já agrega métricas por modelo e por fluxo. Faz sentido quando você usa múltiplos provedores e quer visibilidade consolidada sem ter que agregar manualmente.

Para rastreamento mais granular, com breakdown de custo por trace e por etapa do agente, o Langfuse self-hosted é o que eu uso no meu setup. Você consegue ver exatamente onde o custo está concentrado, o que é muito mais útil do que olhar a fatura total do provedor no final do mês.

Quando vale pagar pelo modelo mais caro

Não toda chamada justifica o modelo mais capaz. Pra mim, a divisão ficou assim depois de mapear os fluxos por criticidade:

Tarefas que merecem o modelo mais caro:

• Geração de texto que vai direto para o usuário final sem revisão humana
• Raciocínio com múltiplos passos onde erro de lógica tem consequência real
• Análise onde interpretação errada muda o resultado do negócio

Tarefas que um modelo menor resolve bem:

• Extração de campos estruturados de texto bem definido
• Classificação de categoria com exemplos claros no prompt
• Resumo de documentos com instrução simples e saída previsível

Essa lógica de roteamento por tipo de tarefa é, na minha visão, o maior alavancador de custo disponível sem sacrificar qualidade percebida pelo usuário. Dá trabalho mapear no início, mas o retorno aparece na primeira fatura depois da otimização.

O que reduz custo sem sacrificar qualidade

Algumas otimizações têm ROI claro e valem implementar logo no início:

• Prompt caching: se você tem um system prompt longo que se repete em várias chamadas, prompt caching pode reduzir o custo dessas chamadas em até 90%. É a otimização com melhor relação esforço/retorno que eu conheço para uso com LLMs.
• Limite no tamanho da resposta: configurar um teto para o tamanho máximo da resposta nos casos onde você espera texto curto evita que o modelo gere conteúdo que você não vai usar.
• Compressão de contexto: em agentes ou conversas longas, manter o contexto enxuto é uma das poucas otimizações que reduz custo e pode melhorar qualidade ao mesmo tempo. O modelo foca no que é relevante, não no histórico completo de 40 mensagens.
• Roteamento por modelo: tarefas simples em modelo simples, tarefas complexas em modelo complexo. A regra parece óbvia, mas raramente é aplicada desde o primeiro deploy.

FAQ sobre custo de LLMs em produção

Qual modelo mais barato ainda entrega qualidade aceitável?

Depende da tarefa. Para classificação, extração e resumo simples, Claude Haiku e GPT-4o mini resolvem bem na maioria dos casos. Para geração crítica ou raciocínio mais complexo, Sonnet ou GPT-4o. Teste com os seus casos reais antes de assumir que precisa do modelo mais caro para tudo.

Como sei se o custo está fora de controle?

Se o custo médio por operação varia mais de 3x entre chamadas do mesmo fluxo, alguma coisa está crescendo sem controle. Pode ser histórico de contexto acumulando, retry em loop ou prompt sendo montado de formas diferentes dependendo do caminho de código.

Faz sentido usar modelos locais para reduzir custo?

Para volume alto e tarefas que um modelo menor resolve, pode fazer sentido. O custo de operar infra local pode ser menor do que pagar API em escala. Mas exige avaliar qualidade com rigor. Modelo local que alucina mais não é barato: o custo aparece em retrabalho e em confiança perdida do usuário.

Preciso de ferramenta específica para monitorar custos?

Não necessariamente. Se você está logando as respostas da API, já tem os dados de token. O básico é agregar por fluxo e criar um alerta quando o custo médio por chamada subir de forma inesperada. Ferramenta específica ajuda quando você tem múltiplos modelos e precisa de granularidade por feature ou por usuário.

Custo de LLMs em produção é decisão técnica, não só financeira

Custo de LLMs em produção não é problema do time de finanças. É decisão técnica: qual modelo usar, qual tamanho de prompt, qual frequência de chamada, quando usar cache. Se você não está medindo isso, está voando cego.

O bom é que a maioria das otimizações de custo também são otimizações de qualidade. Prompt mais curto e focado normalmente produz resposta melhor. Modelo certo para a tarefa gera menos lixo. Contexto controlado mantém o modelo no que importa.

O que fazer agora:

Começa logando o uso de tokens por fluxo se você ainda não faz isso. Depois mapeia quais fluxos têm o custo mais alto e avalia se o modelo usado é o mais adequado para aquela tarefa. Se você tem system prompt longo repetindo em toda chamada, prompt caching é o próximo passo antes de qualquer outra otimização. Esse ciclo, feito uma vez, vai te dar controle real antes que a surpresa apareça na fatura.