Custo de LLM: como estimar e reduzir gasto de inferência
LLMs entregam valor, mas também cobram por cada token processado.
Na prática, isso significa que uma aplicação aparentemente simples pode ficar cara quando usa janelas de contexto grandes, chamadas repetidas, histórico longo ou prompts verborrágicos. Além disso, quanto mais o produto escala, mais pequenos desperdícios passam a aparecer na fatura.
Por isso, estimar o custo de LLM não deve ser uma etapa deixada para depois do deploy. Desde os primeiros testes, o time precisa entender volume, tokens de entrada, tokens de saída, cache, roteamento e latência.
Neste guia, você verá um modelo simples para projetar gasto de inferência, as principais alavancas para reduzir custo sem diluir qualidade, os trade-offs mais comuns e as métricas mínimas para monitorar em produção.
Para contexto técnico, vale consultar o guia da NVIDIA sobre benchmarking de inferência de LLM, além das referências de fornecedores sobre prompt caching, gestão de contexto e semantic caching.
1) Modelo simples para projetar custos
O primeiro passo é criar uma planilha ou um cartão no dashboard de produto com entradas e saídas explícitas.
Dessa forma, o time deixa de discutir custo de forma abstrata e passa a simular cenários com base em volume, modelo, tokens e comportamento real dos usuários.
Entradas por caso de uso
Comece registrando as principais variáveis:
- volume diário de requisições (Q);
- tokens médios de entrada (Tin);
- tokens médios de saída (Tout);
- preço por unidade de cobrança do modelo, como 1K ou 1M tokens (Pin/Pout);
- percentual de prompts com cache (Hit%);
- percentual de chamadas roteadas para modelo menor (Route%).
Além disso, separe os casos de uso por criticidade. Um chatbot de suporte, por exemplo, pode ter padrões de custo diferentes de um fluxo de análise documental ou geração de relatórios.
Cálculo base sem cache e roteamento
Como ponto de partida, use uma fórmula simples:
Custo/dia ≈ Q × [(Tin/1.000) × Pin + (Tout/1.000) × Pout]
Essa conta não substitui a calculadora oficial de cada provedor. No entanto, ela ajuda o time a entender a ordem de grandeza do gasto e comparar cenários antes de escalar.
Ajustes realistas
Depois do cálculo base, inclua ajustes que aproximam a estimativa da operação real.
Com cache, reduza o custo dos tokens de entrada proporcionalmente ao Hit%, especialmente quando há trechos repetidos no início do prompt. Em provedores com prompt caching, prompts com prefixos idênticos podem ser processados com menor custo e menor latência.
Com semantic caching, respostas para consultas repetidas ou semanticamente semelhantes podem ser reaproveitadas. Nesse caso, a aplicação consulta o cache antes de chamar o LLM, o que pode reduzir chamadas desnecessárias em fluxos recorrentes. A Microsoft documenta esse padrão em políticas de semantic caching para Azure OpenAI.
Além disso, use roteamento ou cascata de modelos. Parte das requisições pode ser atendida por um modelo menor, enquanto casos mais complexos escalam para um modelo maior. Pesquisas sobre routing e cascading para LLMs discutem justamente esse trade-off entre custo e qualidade.
Por fim, avalie batching quando houver tarefas compatíveis. Ao agrupar classificações ou extrações semelhantes, o time pode reduzir overhead de chamadas e organizar melhor o processamento.
2) As principais alavancas de redução (o que realmente move a agulha)
Reduzir custo de inferência não significa apenas trocar para um modelo mais barato.
Na prática, a economia vem da combinação entre prompts mais enxutos, melhor gestão de contexto, cache, roteamento, limites de geração e monitoramento contínuo.
A. Prompts mais enxutos
A primeira alavanca é melhorar a eficiência de tokens.
Para isso, remova redundâncias, substitua instruções longas por regras claras e use exemplos mínimos. Além disso, evite repetir contexto fixo em todas as chamadas quando ele puder ser resumido, referenciado ou cacheado.
O guia da OpenAI sobre otimização de prompts é uma boa referência para revisar instruções, testar variações e medir impacto em qualidade.
No entanto, prompt enxuto não significa prompt vago. Se a instrução ficar curta demais, o modelo pode perder aderência à tarefa. Por isso, toda redução de tokens precisa ser comparada com um baseline de qualidade.
B. Gestão de contexto
Outra alavanca importante é controlar janela e histórico.
Em conversas longas, elimine trechos antigos ou irrelevantes. Quando fizer sentido, substitua passagens extensas por resumos estruturados. Dessa maneira, o modelo recebe apenas o contexto necessário para responder bem.
Além disso, em fluxos com RAG, controle tamanho, granularidade e quantidade dos trechos recuperados. Se o retrieval envia conteúdo demais, o prompt infla, o custo aumenta e a resposta pode ficar menos objetiva.
Para aprofundar essa parte, vale conectar este tema ao conteúdo da Tekne sobre RAG sem mistério: escolha o vector DB e avalie a recuperação.
C. Cache de prompt e cache semântico
O cache é uma das alavancas mais fortes em aplicações com padrões repetitivos.
Com prompt caching, o provedor pode reaproveitar partes idênticas do prompt, especialmente instruções de sistema, políticas, exemplos e contexto fixo. Assim, chamadas com o mesmo prefixo tendem a consumir menos recursos do que processar tudo novamente.
Já o semantic caching atua em outro nível. Em vez de buscar apenas prompts idênticos, ele tenta identificar perguntas semanticamente parecidas e retornar respostas previamente armazenadas. No Azure, esse padrão aparece em políticas como llm-semantic-cache-lookup.
Ainda assim, cache sem estratégia pode gerar respostas desatualizadas. Por isso, defina TTL, regras de invalidação e critérios para não cachear consultas sensíveis, reguladas ou altamente contextuais.
D. Consolidação e batching de chamadas
Quando várias subtarefas são compatíveis, consolide chamadas.
Por exemplo, em vez de chamar o LLM dez vezes para classificar dez textos curtos, talvez seja possível enviar um lote com estrutura padronizada e receber uma saída única em formato controlado.
Como resultado, o time reduz overhead, melhora rastreabilidade e simplifica o cálculo de custo por tarefa.
No entanto, o batching também tem limites. Se o lote ficar grande demais, pode aumentar latência, dificultar tratamento de erro e tornar a resposta mais frágil. Portanto, teste tamanho de lote, tempo de resposta e taxa de falhas antes de levar para produção.
E. Seleção e cascata de modelos
A seleção de modelo também move a agulha.
Em muitos produtos, nem toda requisição precisa do modelo mais capaz. Perguntas simples, classificações diretas e respostas padronizadas podem ser atendidas por um modelo menor. Já casos ambíguos, críticos ou com baixa confiança podem escalar para um modelo maior.
Nesse contexto, um router decide quando usar cada modelo. Além disso, a cascata permite começar barato e escalar apenas quando necessário.
Ainda assim, uma cascata agressiva pode reduzir custo e piorar qualidade em casos difíceis. Por isso, monitore fallback rate, qualidade por segmento e custo por acerto útil.
F. Outras alavancas
Quando o time hospeda modelos, técnicas como quantização, poda e destilação podem reduzir custo de infraestrutura.
Além disso, limites de geração, como max tokens, ajudam a evitar respostas longas demais. Essa é uma medida simples, mas útil para controlar custo e previsibilidade.
Por outro lado, limitar demais a geração pode cortar respostas antes da conclusão. Dessa forma, o limite deve ser ajustado por tipo de tarefa, e não aplicado de forma genérica.
3) Trade-offs: onde a economia pode cobrar seu preço
Toda otimização de custo precisa ser acompanhada de avaliação de qualidade.
Caso contrário, o time pode reduzir a fatura e, ao mesmo tempo, piorar a experiência do usuário, aumentar retrabalho ou gerar respostas menos confiáveis.
Prompt enxuto demais
Prompts mais curtos reduzem tokens, mas também podem remover instruções importantes.
Por isso, compare qualidade antes e depois de cada mudança. Sempre que possível, use a mesma amostra de avaliação para medir aderência, completude, clareza e taxa de erro.
Contexto curto demais
Reduzir contexto pode diminuir custo, mas também pode aumentar alucinações.
Quando o modelo não recebe fontes suficientes, ele tende a completar lacunas com inferências. Portanto, monitore groundedness, citações, referências e taxa de respostas sem base adequada.
Cascata agressiva
A cascata de modelos reduz custo quando os casos simples ficam com modelos menores.
No entanto, se o router classificar mal a complexidade, perguntas difíceis podem receber respostas fracas. Por isso, acompanhe taxa de escalonamento, queda de qualidade e volume de correções humanas.
Cache sem estratégia
Cache pode economizar bastante, mas também pode devolver informação antiga.
Assim, defina TTL, invalidação por mudança de fonte e regras para impedir cache em casos sensíveis. Além disso, registre quando uma resposta veio do cache, porque isso ajuda auditoria e depuração.
4) Métricas mínimas para monitorar (e decidir promoção vs. rollback)
Depois do deploy, o time precisa monitorar custo, qualidade, latência e saúde do sistema.
Dessa forma, decisões de promoção, rollback ou ajuste deixam de depender de achismo.
Custo por acerto útil
A principal métrica deve ser o custo por acerto útil.
Em vez de medir apenas custo por requisição, acompanhe quanto custa concluir uma tarefa com score de qualidade acima do limiar. Por exemplo: custo por ticket resolvido, custo por resposta aprovada ou custo por documento classificado corretamente.
Tokens por requisição
Também monitore tokens de entrada e saída por requisição.
Além disso, acompanhe a taxa de cache hit em prompt caching e semantic caching. Essa métrica ajuda a entender se a estratégia de cache está realmente funcionando.
Roteamento
No caso de múltiplos modelos, acompanhe o percentual atendido por modelo menor e a taxa de escalonamento para o modelo maior.
Ao mesmo tempo, cruze esses dados com qualidade. Se o modelo menor atende muito volume, mas piora a experiência, a economia pode estar escondendo custo operacional.
Qualidade
A qualidade deve ser medida por rubricas, LLM-as-a-Judge e amostra humana.
Ainda assim, avaliação automática não deve ser usada sem controle. Mantenha uma amostra revisada por pessoas para validar se o score reflete utilidade, aderência e segurança.
Latência
Acompanhe p50 e p95 por etapa, incluindo retrieval, geração, rerank e pós-processamento.
Esse ponto é importante porque algumas economias aumentam latência. Por exemplo, uma cascata mal desenhada pode chamar dois modelos em sequência e piorar a UX, mesmo reduzindo custo médio.
Saúde do sistema
Por fim, monitore erros de moderação, vazamento de PII, retries, rate limits e falhas por timeout.
Esses custos indiretos muitas vezes não aparecem na primeira conta, mas afetam operação, confiança e experiência do usuário.
5) Roteiro prático de 7 dias (sem “bla-bla-bla”)
Reduzir custo de LLM não precisa começar com uma grande reestruturação.
Pelo contrário, em uma semana já é possível criar uma linha de base, testar alavancas e decidir quais mudanças devem seguir para produção.
Dia 1: mapeie casos de uso
Comece listando os principais fluxos que chamam LLMs.
Para cada um, registre volume, modelo usado, tokens médios, custo estimado, latência e criticidade. Assim, o time identifica onde a otimização terá maior impacto.
Dia 2: estime o custo base
Em seguida, aplique a fórmula de custo por volume, tokens e preço.
Além disso, separe custo por tarefa, não apenas por chamada. Isso ajuda a evitar otimizações que reduzem gasto por requisição, mas aumentam retrabalho.
Dia 3: redesenhe prompts
Depois, revise prompts longos e corte contexto supérfluo.
Mantenha instruções essenciais, critérios de saída e exemplos mínimos. No entanto, teste a nova versão contra a anterior para garantir que a economia não reduziu qualidade.
Dia 4: habilite cache
No quarto dia, habilite prompt caching ou semantic caching nos fluxos repetitivos.
Além disso, defina TTL, regras de invalidação e campos de log para identificar respostas cacheadas.
Dia 5: implemente roteamento
Em seguida, configure um modelo menor como padrão para casos simples.
Quando houver baixa confiança, alta complexidade ou risco elevado, escale para um modelo maior. Dessa forma, o produto economiza sem tratar todos os casos como se fossem críticos.
Dia 6: teste A/B e canary
Antes de liberar para todo o tráfego, rode um teste A/B offline com a mesma amostra.
Depois, faça um canary online com 5% a 20% do tráfego, dependendo do risco do produto. Durante o teste, acompanhe custo, qualidade, p95, fallback rate e reclamações.
Dia 7: aprove ou faça rollback
Por fim, aprove apenas a variante que reduzir custo por acerto útil sem piorar qualidade, segurança ou latência.
Se o p95 subir demais, a qualidade cair ou o cache gerar respostas desatualizadas, faça rollback e ajuste a estratégia.
Conclusão
Estimar custo de LLM começa com uma conta simples: volume × tokens × preço.
No entanto, reduzir gasto de inferência exige disciplina operacional. Prompts enxutos, contexto sob controle, cache, roteamento, limites de geração e métricas bem definidas precisam trabalhar juntos.
Quando o time monitora custo por acerto útil, tokens por requisição, taxa de cache hit, fallback rate, qualidade e p95 de latência, fica mais fácil decidir promoção ou rollback com evidência.
Como resultado, a otimização deixa de ser apenas uma tentativa de economizar e passa a ser uma prática de produto. O objetivo não é gastar menos a qualquer custo, mas encontrar o melhor equilíbrio entre qualidade, velocidade, segurança e eficiência.
Para aprofundar a aplicação prática desse fluxo, continue no blog da Tekne com LLMOps na prática: do prompt ao pipeline de avaliação e RAG sem mistério: escolha o vector DB e avalie a recuperação.
Além disso, para acelerar a implementação com suporte hands-on, conheça o Bootcamp de ML & IA da Tekne.
