Neste artigo
- Por que a maioria das aplicações opera às cegas
- Custo por requisição: o que você precisa registrar
- Latência por rota: por que média não basta
- Taxa de erro: o que conta como erro num sistema com LLM
- Cache hit rate: o custo que você evitou
- Conectando métricas técnicas ao produto
- O dashboard mínimo para o primeiro deploy
- Dúvidas comuns sobre monitoramento de LLMs
- Conclusão e próximo passo
Você coloca um LLM em produção, o produto parece funcionar, os usuários usam. Aí chega a fatura do mês e tem um número que não faz sentido. Esse é o padrão mais comum que vejo em aplicações com LLM que não foram instrumentadas desde o início.
O problema não é o custo em si. É não saber de onde ele vem. Quando você não mede por rota, por tipo de requisição, por feature, o que você tem é um número global que não te diz nada sobre onde agir. A conta vai sair do controle antes de você perceber que saiu.
Neste artigo, cubro quatro métricas que são o mínimo viável para operar uma aplicação com LLM em produção: custo por requisição, latência por rota, taxa de erro e cache hit rate. E mais importante: como conectar essas métricas ao impacto real no produto, não apenas ao dashboard técnico.
Por que a maioria das aplicações opera às cegas
O setup padrão de quem está começando é direto: chama a API, recebe a resposta, entrega para o usuário. Nenhum log de tokens consumidos, nenhuma separação de rota, nenhuma instrumentação de tempo. Funciona no sentido de que o produto responde. Mas você está voando sem instrumentos.
O que acontece em produção é que certas features consomem uma ordem de magnitude a mais do que outras, e isso só aparece quando alguém vai investigar a fatura. Um endpoint de sumarização de documento longo processando dezenas de milhares de tokens por requisição versus um chatbot que usa oitocentos tokens em média. Se você não separou, está somando tudo num único número sem utilidade analítica.
O problema de latência segue a mesma lógica. Uma rota que usa streaming e outra que espera a resposta completa têm comportamentos completamente diferentes. Se você medir latência como média global, vai suprimir os outliers que estão destruindo a experiência do usuário.
Custo por requisição: o que você precisa registrar
Todo provedor de LLM cobra por token, com preços diferentes para input e output. O custo por requisição é direto: tokens de input consumidos vezes o preço de input, mais tokens de output vezes o preço de output.
Ao construir seu sistema de monitoramento, peça para a IA gerar a lógica de cálculo de custo para o modelo que você usa. Os preços por token são públicos na documentação de cada provedor e mudam com frequência, então vale configurar os valores como variável de ambiente em vez de valor fixo no código.
O que você quer registrar por requisição é: qual rota foi chamada, qual modelo foi usado, quantos tokens de input e output foram consumidos e o custo calculado com timestamp. A estrutura importa menos do que o hábito de capturar.
Com dados por rota, você consegue comparar o custo médio de cada endpoint e identificar onde o investimento está concentrado. Às vezes é justificado. Às vezes é um prompt que cresceu sem controle e ninguém percebeu. Essa visibilidade é o primeiro passo para qualquer otimização.
Latência por rota: por que média não basta
Latência de LLM tem uma distribuição que não é normal. Você vai ter requisições rápidas e requisições que demoram muito, dependendo do tamanho da resposta, do estado do servidor do provedor e de quantas ferramentas o agente chamou no caminho.
Medir só a média é enganoso. O que você precisa são os percentis P50, P90 e P99.
- P50 te diz o que a maioria dos usuários experimenta
- P90 te diz o que o décimo pior percentil experimenta
- P99 te diz onde estão os outliers que estão recebendo uma experiência ruim
Em produção você vai querer isso num sistema de métricas existente, seja Prometheus, Datadog ou qualquer ferramenta que você já usa. O ponto é separar por rota, não agregar tudo. Uma média global de 1,8 segundo pode estar escondendo uma rota específica que responde em oito segundos para dez por cento dos usuários. Para entender como montar o stack de observabilidade, o artigo sobre Prometheus e Grafana com Docker Compose cobre a parte prática da infraestrutura.
Taxa de erro: o que conta como erro num sistema com LLM
Taxa de erro em LLM é mais sutil do que em uma API convencional. Você tem os erros óbvios: timeout da API, rate limit, resposta malformada. Esses são fáceis de capturar no tratamento de exceções.
O que fica de fora da maioria dos sistemas de monitoramento são os erros silenciosos: o modelo retornou algo que não segue o formato esperado, o JSON veio incompleto, a resposta estava em inglês quando devia estar em português, a extração de dados retornou campos vazios que deviam estar preenchidos. Esses erros passam pelo HTTP 200 mas são falhas reais do ponto de vista do produto.
A forma de capturar isso é ter validação na saída do modelo e registrar falhas de validação como uma categoria separada de erro. Não misture com erros de rede. São problemas com causas diferentes e soluções diferentes. Peça para uma IA ajudar a construir o schema de validação para cada rota, descrevendo quais campos são obrigatórios e quais formatos são esperados.
A taxa de erro de validação por rota é uma das métricas mais úteis para detectar degradação de qualidade antes que o usuário perceba. Se essa taxa sobe sem que você tenha mudado nada, o modelo pode ter mudado por atualização silenciosa do provedor, ou os dados de entrada mudaram de formato upstream.
Cache hit rate: o custo que você evitou
Dependendo do tipo de aplicação, uma fração relevante das requisições são idênticas ou quase idênticas. Perguntas frequentes num chatbot, sumarizações do mesmo documento, classificações de textos repetidos. Cache semântico ou cache exato podem reduzir custo real de forma significativa.
Mas cache sem monitoramento é quase inútil analiticamente. O que você quer saber é o cache hit rate por rota e o custo evitado por período. Isso te diz se o cache está valendo o overhead de manutenção e justifica o investimento de engenharia.
O custo evitado é calculado somando o custo médio das requisições que foram servidas via cache, usando como referência o custo médio da rota equivalente sem cache. Esse número é o argumento de negócio para manter a camada de cache funcionando.
Na minha experiência, cache hit rate abaixo de quinze por cento em rotas que deveriam se beneficiar de cache é sinal de que a estratégia de chave está errada ou o TTL está muito curto. Acima de sessenta por cento começa a fazer diferença relevante na fatura mensal.
Conectando métricas técnicas ao produto
O que descrevi até aqui são métricas de engenharia. Úteis para debugar, mas não suficientes para justificar investimento ou corte de feature numa conversa com produto ou com quem paga a fatura.
A conexão que precisa existir é entre custo por requisição e valor gerado por requisição. Isso varia por produto, mas em geral você quer saber: qual é o custo de LLM por conversão, por usuário retido, por ticket resolvido sem escalonamento humano.
Se a feature de sumarização custa um valor específico por uso e a taxa de retenção de usuários que usam essa feature é significativamente maior, você tem um argumento para o custo. Se não tem como medir o impacto, você está operando com uma variável de custo sem justificativa analítica.
O dashboard mínimo para o primeiro deploy
O que recomendo ter desde o primeiro deploy em produção:
- Custo total por dia, separado por rota
- Custo médio por requisição por rota, com tendência semanal
- P50, P90 e P99 de latência por rota
- Taxa de erro de API e taxa de erro de validação, separados
- Cache hit rate por rota e custo evitado estimado
- Tokens médios de input e output por rota, para detectar crescimento silencioso de prompt
Esse conjunto de métricas não exige infraestrutura complexa. Um banco de dados simples com as colunas certas e queries agregadas já entrega a visibilidade necessária. Peça para uma IA ajudar a montar as queries de agregação descrevendo os campos que você está registrando e o que você quer enxergar.
Dúvidas comuns sobre monitoramento de LLMs
Com que frequência revisar as métricas?
Custo e latência merecem revisão semanal nos primeiros meses após o deploy. Depois que o comportamento está estável, a revisão pode ser mensal com alertas automáticos para anomalias. Taxa de erro de validação deve ser monitorada diariamente nos primeiros ciclos após qualquer mudança de prompt ou modelo.
Como saber se uma mudança de prompt aumentou o custo?
Comparando o custo médio por requisição da rota antes e depois da mudança. Se você versionou o prompt e registrou o identificador da versão nos logs, consegue fazer essa comparação diretamente. Sem versionamento, você está dependendo de memória ou de períodos arbitrários.
O provedor de LLM não já oferece métricas de uso?
Sim, mas em nível de conta, não de rota da sua aplicação. O que o provedor mostra é o total consumido por modelo por período. Para entender qual feature está gerando o custo, você precisa instrumentar no seu lado. As métricas do provedor são o total da fatura. As suas métricas são a decomposição que te diz onde agir.
Quando os sinais indicam que preciso trocar de modelo ou retreinar?
Quando a taxa de erro de validação sobe persistentemente sem mudança na sua parte, o modelo pode ter mudado. Quando o custo por requisição cresce sem aumento equivalente de tokens, revise o contrato com o provedor. Para entender quando o comportamento do modelo mudou a ponto de exigir retreinamento, o artigo sobre quando retreinar um modelo de IA cobre os sinais de degradação com mais detalhe.
Conclusão e próximo passo
Você não vai conseguir otimizar o que não mede. Em aplicação com LLM, onde o custo por requisição pode variar numa ordem de magnitude dependendo do uso, medir tarde é medir caro. Instrumentar desde o primeiro deploy não é trabalho de duas semanas. É registrar os campos certos e montar as queries de agregação. O custo de implementar é pequeno. O custo de não ter quando você precisar é bem maior.
Se você quer avançar com isso, o próximo passo é:
- Identificar as três rotas mais usadas da sua aplicação e começar a logar tokens e latência para elas
- Montar um dashboard simples com custo por rota por semana
- Adicionar validação de saída em pelo menos uma rota e registrar a taxa de erro de validação
Para entender como avaliar se as respostas do modelo estão com qualidade aceitável além das métricas de latência e custo, o artigo sobre como avaliar respostas de LLM em produção cobre os métodos que vão além do achismo. E para a camada de controle sobre o que o modelo pode ou não fazer, o artigo sobre guardrails para IA em produção mostra como estruturar isso.
