Custo de LLM: como estimar e reduzir gasto de inferência

LLMs entregam valor – e contam centavos por token. Sem um modelo simples de custo e rotinas de otimização, a conta cresce rápido com janelas de contexto maiores, chamadas repetidas e prompts verborrágicos. Este guia traz: (1) um modelo direto para projetar gastos por volume e contexto; (2) as principais alavancas para reduzir custo sem diluir qualidade; (3) trade-offs típicos ao economizar; e (4) as métricas mínimas que o time deve monitorar em produção. Para pano de fundo, veja compilações de estratégias de redução de custo (modelo certo, cache, engenharia de prompt, batching) e guias de fornecedores sobre prompt caching e gestão de contexto. 

1) Modelo simples para projetar custos

Comece com uma planilha (ou cartão no seu dashboard de produto) com entradas e saídas explícitas:

  • Entradas (por caso de uso):
     Volume diário de requisições (Q), tokens de entrada médios (Tin), tokens de saída médios (Tout), preço por 1K tokens do modelo (Pin/Pout), % de prompts com cache (Hit%), % de chamadas “baratas” via modelo menor (Route%).

  • Cálculo base (sem cache/roteamento):
     Custo/dia ≈ Q × [(Tin/1.000)×Pin + (Tout/1.000)×Pout].

  • Ajustes realistas:
    Cache: reduza Tin proporcionalmente a Hit% (prompt caching/semantic caching).
    Roteamento/cascata: parte de Q vai para modelo menor; só “escala” para o maior quando necessário. arXiv
    Consolidação/batching: combine pedidos compatíveis para diminuir overhead de chamadas (ver compêndios de custo).

2) As principais alavancas de redução (o que realmente move a agulha)


A. Prompts mais enxutos (token efficiency)

  • Remova redundâncias, instrua de forma específica, troque “longos contextos fixos” por regras resumidas e exemplos mínimos. Padrões de prompt enxuto cortam tokens sem perder clareza.

  • Em janelas longas, selecione apenas o contexto necessário (retrieval/condensado) em vez de despejar tudo.


B. Gestão de contexto (janela e histórico)

  • Context management: elimine conteúdo antigo/irrelevante do histórico e troque passagens longas por resumos; fornecedores já oferecem mecanismos para “compactar” conversas longas.

  • Controle tamanho e granularidade dos trechos recuperados (RAG) para não inflar o prompt mais que o necessário. (Ver nossa peça de RAG para critérios de recall/groundedness.)

 

C. Cache (prompt & semântico)

  • Prompt caching reduz custo de tokens de entrada quando o início do prompt é idêntico entre requisições; em alguns provedores, a queda pode chegar a grande parte do custo de input.
  • Semantic caching guarda respostas para consultas repetidas/semelhantes; casos relatam 20–30% de queries atendidas sem chamar o LLM.


D. Consolidação e batching de chamadas

  • Una subtarefas compatíveis em uma única chamada (ex.: múltiplas classificações) e, quando possível, processe em lote para reduzir overhead e latência total.

E. Seleção/cascata de modelos (router)

  • Adote modelo “bom o bastante” para casos simples e “escale” para modelos maiores apenas quando regras/heurísticas acusarem alta complexidade. Estratégias de model selection aparecem como pilar central de economia.

F. Outras alavancas

  • Quantização/poda/destilação (quando você hospeda modelos) e limites de geração (max tokens) para cortes imediatos de custo.

3) Trade-offs: onde a economia pode cobrar seu preço

  • Prompt enxuto demais → queda de aderência à instrução; meça qualidade antes/depois.

  • Contexto curto demais → alucinações por falta de base; confira groundedness e referências.

  • Cascata agressiva → ganho de custo com perda de qualidade em casos ambíguos; monitore o “fallback rate” para o modelo maior.

  • Cache sem estratégia → risco de resposta desatualizada; defina TTLs e invalidação por mudança de fonte.

4) Métricas mínimas para monitorar (e decidir promoção vs. rollback)

  • Custo por acerto útil (R$ por tarefa com score ≥ limiar).

     

  • Tokens por requisição (input/output) e % cache hit (prompt/semântico).

     

  • Roteamento: % atendido por modelo menor e taxa de escalonamento para modelo maior.

     

  • Qualidade: score de utilidade/aderência (rubrica/LLM-as-judge + amostra humana).

     

  • Latência: p50/p95 por etapa (retrieval, geração) para evitar “economia que atrapalha a UX”.

     

  • Saúde do sistema: erros de moderação/PII, taxas de retry/rate-limit (custos “ocultos”).

5) Roteiro prático de 7 dias (sem “bla-bla-bla”)

  1. Mapeie casos e estimativa base de custo (planilha) por uso.

  2. Redesenhe prompts (enxutos, objetivos) e corte contexto supérfluo.

  3. Habilite cache (prompt/semântico) nos fluxos repetitivos.

  4. Implemente roteamento: modelo pequeno por padrão; “escale” quando necessário.

  5. Defina limites (max tokens, TTL de cache) e logging estruturado de tokens/custos.

  6. Teste A/B offline (mesma amostra) e canary on-line (5–20% tráfego).

  7. Aprove a variante que baixar custo por acerto sem piorar p95/qualidade.

Conclusão

Estimar custo de LLM é simples — volume × tokens × preço —, mas reduzir gasto exige disciplina operacional: prompts enxutos, contexto sob controle, cache e roteamento inteligente. Quando você monitora custo por acerto útil, tokens por requisição, taxa de cache hit e p95 de latência, passa a decidir promoção vs. rollback com evidência — não com achismo. 

Se quiser aprofundar a aplicação prática disso no seu produto, continue no nosso blog com “LLMOps na prática: do prompt ao pipeline de avaliação” e “RAG sem mistério: escolhendo o vector DB e avaliando a recuperação”; e, para acelerar a implementação com suporte hands-on, conheça o Bootcamp de ML & IA da Tekne.

Pesquisar

Posts Recentes

Categorias