Monitore a Inferência de LLM em Produção (2026): Prometheus & Grafana para vLLM, TGI, llama.cpp

A inferência de LLM parece “apenas outra API” — até que ocorram picos de latência, filas se formem novamente e seus GPUs fiquem em 95% de memória sem explicação óbvia.

O monitoramento torna-se crítico assim que você ultrapassar uma configuração de único nó ou começar a otimizar para throughput. Nesse momento, métricas tradicionais de API não são suficientes. Você precisa de visibilidade sobre tokens, comportamento de lotes, tempo de fila e pressão de cache KV — os verdadeiros gargalos dos sistemas modernos de LLM.

Este artigo faz parte do meu guia mais amplo sobre observabilidade e monitoramento, onde abordo fundamentos de monitoramento vs observabilidade, arquitetura do Prometheus e melhores práticas para produção. Aqui, focaremos especificamente no monitoramento de cargas de inferência de LLM.

(Se você está decidindo sobre infraestrutura, veja meu guia sobre hosting de LLM em 2026. Se quiser uma imersão profunda em mecânicas de lotes, limites de VRAM e trade-offs entre throughput e latência, veja o guia de engenharia de desempenho de LLM.)

Diferente de serviços REST típicos, o atendimento de LLM é moldado por tokens, batches contínuos, utilização de cache KV, saturação de GPU/CPU e dinâmicas de fila. Dois pedidos com tamanhos de carga idênticos podem ter latência radicalmente diferente dependendo de max_new_tokens, concorrência e reutilização de cache.

Este guia é um passeio prático e orientado para produção para construir monitoramento de inferência de LLM com Prometheus e Grafana:

• O que medir (p95/p99 latência, tokens/sec, duração da fila, utilização de cache, taxa de erro)
• Como coletar /metrics de servidores comuns (vLLM, Hugging Face TGI, llama.cpp)
• Exemplos de PromQL para percentis, saturação e throughput
• Padrões de implantação com Docker Compose e Kubernetes
• Solução de problemas com os problemas que só aparecem sob carga real

Os exemplos são intencionalmente neutros em relação a fornecedores. Se você depois adicionar rastreamento OpenTelemetry, autoscaling ou uma malha de serviço, o mesmo modelo de métrica se aplica.

Por que você deve monitorar a inferência de LLM de forma diferente

O monitoramento tradicional de API (RPS, latência p95, taxa de erro) é necessário, mas não suficiente. O atendimento de LLM adiciona eixos adicionais:

1) Latência tem dois significados

• Latência E2E: tempo desde que a solicitação é recebida até que o último token seja retornado.
• Latência inter-token: tempo por token durante a decodificação (crítico para UX de streaming).

Alguns servidores expõem ambos. Por exemplo, TGI expõe duração da solicitação e tempo médio por token como histogramas.

2) Throughput está em tokens, não em solicitações

Um serviço “rápido” que retorna 5 tokens não é comparável com um que retorna 500 tokens. Sua “RPS” deve frequentemente ser “tokens/sec”.

3) A fila é o produto

Se você executar lotes contínuos, a profundidade da fila é o que você vende. Observar duração da fila e tamanho da fila diz se você está atendendo as expectativas dos usuários.

4) Pressão de cache é precursor de falhas

Exaustão de cache KV (ou fragmentação) frequentemente aparece como picos súbitos de latência e timeout. O vLLM expõe utilização de cache KV como um gauge.

Checklist de métricas para monitoramento de inferência de LLM

Use isso como seu farol. Você não precisa de tudo no primeiro dia — mas eventualmente querrá a maioria delas.

Sinais dourados (flavorados com LLM)

• Tráfego: solicitações por segundo, tokens por segundo
• Erros: taxa de erro, timeout, OOMs, 429s (limitação de taxa)
• Latência: p50/p95/p99 duração da solicitação; latência de preenchimento vs decodificação; latência inter-token
• Saturação: utilização de GPU, uso de memória, utilização de cache KV, tamanho da fila

Se você precisa de visibilidade de baixo nível sobre uso de memória da GPU, temperatura e utilização fora do Prometheus (para depuração ou configurações de único nó), veja meu guia sobre aplicações de monitoramento de GPU em Linux / Ubuntu.

Para uma visão mais ampla da observabilidade de LLM além das métricas — incluindo rastreamento, logs estruturados, testes sintéticos, perfis de GPU e design de SLO — veja meu guia detalhado sobre observabilidade para sistemas LLM.

Dimensões úteis (rótulos)

Mantenha a cardinalidade dos rótulos baixa. Rótulos bons:

• modelo, endpoint, método (prefill/decode), status (sucesso/erro), instância

Evite rótulos como:

• prompt bruto, user_id bruto, IDs de solicitação — esses explodem a contagem de séries.

Expondo métricas: endpoints /metrics embutidos (vLLM, TGI, llama.cpp)

O caminho mais fácil é: use as métricas que o servidor já expõe.

vLLM: /metrics compatível com Prometheus

O vLLM expõe um endpoint /metrics compatível com Prometheus (via seu logger de métricas do Prometheus) e publica métricas de servidor/solicitação com o prefixo vllm:, incluindo gauges como solicitações em execução e utilização de cache KV.

Exemplos de métricas que você normalmente verá:

• vllm:num_requests_running
• vllm:num_requests_waiting
• vllm:kv_cache_usage_perc

Hugging Face TGI: /metrics com filas + histogramas de solicitações

O TGI expõe muitas métricas de produção em /metrics, incluindo tamanho da fila, duração da solicitação, duração da fila e tempo médio por token.

Destacáveis:

• tgi_queue_size (gauge)
• tgi_request_duration (histograma, latência E2E)
• tgi_request_queue_duration (histograma)
• tgi_request_mean_time_per_token_duration (histograma)

Servidor llama.cpp: ative o endpoint de métricas

O servidor llama.cpp suporta um endpoint de métricas compatível com Prometheus que deve ser ativado com uma bandeira (ex: --metrics).

Se você estiver executando o llama.cpp atrás de um proxy, colete diretamente o servidor sempre que possível (para evitar latência no nível do proxy que esconde o comportamento real de inferência).

Configuração do Prometheus: coletando seus servidores de inferência

Este exemplo assume:

• vLLM em http://vllm:8000/metrics
• TGI em http://tgi:8080/metrics
• llama.cpp em http://llama:8080/metrics
• intervalo de coleta ajustado para feedback rápido

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "vllm"
    metrics_path: /metrics
    static_configs:
      - targets: ["vllm:8000"]

  - job_name: "tgi"
    metrics_path: /metrics
    static_configs:
      - targets: ["tgi:8080"]

  - job_name: "llama_cpp"
    metrics_path: /metrics
    static_configs:
      - targets: ["llama:8080"]

Se você é novo no Prometheus ou quer uma explicação mais detalhada sobre configurações de coleta, exportadores, relabeling e regras de alerta, veja meu guia completo sobre configuração de monitoramento com Prometheus.

Dica profissional: adicione um rótulo “service”

Se você executar múltiplos modelos/replicatas, adicione relabeling para incluir um rótulo estável service para dashboards.

relabel_configs:
  - target_label: service
    replacement: "llm-inference"

Exemplos de PromQL que você pode copiar/colar

Taxa de solicitação (RPS)

sum(rate(tgi_request_count[5m]))

Para vLLM, use seus contadores de solicitação (os nomes variam por versão), mas o padrão é o mesmo: sum(rate(<counter>[5m])).

Taxa de erro (%)

Se você tiver contadores *_success, calcule a proporção de falha:

1 - (
  sum(rate(tgi_request_success[5m]))
  /
  sum(rate(tgi_request_count[5m]))
)

p95 latência para métricas de histograma (Prometheus)

Histogramas do Prometheus são contagens de bucket; use histogram_quantile() sobre rate() dos buckets. O Prometheus documenta esse modelo e os trade-offs entre histograma e resumo.

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_duration_bucket[5m]))
)

p99 tempo de fila

histogram_quantile(
  0.99,
  sum by (le) (rate(tgi_request_queue_duration_bucket[5m]))
)

Tempo médio por token (latência inter-token)

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_mean_time_per_token_duration_bucket[5m]))
)

A latência inter-token é frequentemente limitada por gargalos de decodificação e largura de banda de memória — temas abordados em detalhe no guia de otimização de desempenho de LLM.

Profundidade da fila (instantâneo)

max(tgi_queue_size)

Utilização do cache KV do vLLM (instantâneo)

max(vllm:kv_cache_usage_perc)

Dashboards do Grafana: painéis que realmente ajudam os on-call

O Grafana pode visualizar histogramas de várias formas (percentis, mapas de calor, distribuição de buckets). A Grafana Labs tem um guia detalhado sobre visualização de histogramas do Prometheus.

Um layout de dashboard minimalista com alto sinal:

Linha 1 — Experiência do usuário

1. Latência p95 da solicitação (série temporal)
2. Latência p95 inter-token (série temporal)
3. Taxa de erro (série temporal + estatística)

Linha 2 — Capacidade e saturação

4. Tamanho da fila (série temporal)
5. Solicitações em execução vs. em espera (empilhadas)
6. Utilização do cache KV (%) (gauge)

Linha 3 — Throughput

7. Solicitações por segundo
8. Tokens gerados por solicitação (p50/p95)

Se você tiver streaming, adicione um painel para “latência do primeiro token” (TTFT) quando disponível.

Consultas de exemplo do Grafana

• Painel de latência p95: a consulta histogram_quantile(0.95, …) acima
• Painel de mapa de calor: grafique as taxas dos buckets (*_bucket) como um mapa de calor (o Grafana suporta essa abordagem)

Opção de implantação 1: Docker Compose (local rápido + único nó)

Se você está decidindo entre arquiteturas locais, auto-hospedadas ou baseadas em nuvem, veja a análise completa em meu guia de comparação de hosting de LLM.

Crie uma pasta como:

monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inference.json

docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Se você preferir uma instalação manual do Grafana em vez de Docker, veja meu guia passo a passo sobre instalação e uso do Grafana no Ubuntu.

Provisionamento de fonte de dados do Grafana (grafana/provisioning/datasources/datasource.yml)

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

Provisionamento de dashboards do Grafana (grafana/provisioning/dashboards/dashboards.yml)

apiVersion: 1
providers:
  - name: "LLM"
    folder: "LLM"
    type: file
    disableDeletion: true
    options:
      path: /var/lib/grafana/dashboards

Opção de implantação 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Se você usar kube-prometheus-stack (Prometheus Operator), colete alvos via ServiceMonitor.

Para trade-offs de infraestrutura entre Kubernetes, único nó Docker e provedores gerenciados de inferência, veja meu guia de hosting de LLM em 2026.

1) Exponha sua implantação de inferência com um Service

apiVersion: v1
kind: Service
metadata:
  name: tgi
  labels:
    app: tgi
spec:
  selector:
    app: tgi
  ports:
    - name: http
      port: 8080
      targetPort: 8080

2) Crie um ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tgi
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: tgi
  endpoints:
    - port: http
      path: /metrics
      interval: 5s

Repita para serviços vLLM e llama.cpp. Isso escala limpo conforme você adiciona réplicas.

3) Alertas: regras estilo SLO (exemplo)

Aqui estão bons alertas iniciais:

• Latência p95 alta (taxa de queima)
• Tempo de fila p99 muito alto (usuários esperando)
• Taxa de erro > 1%
• Uso de cache KV > 90% sustentado (cliff de capacidade)

Exemplo de regra (duração da solicitação p95):

- alert: LLMHighP95Latency
  expr: histogram_quantile(0.95, sum by (le) (rate(tgi_request_duration_bucket[5m]))) > 3
  for: 10m
  labels:
    severity: page
  annotations:
    summary: "Latência p95 do TGI > 3s (10m)"

Solução de problemas: falhas comuns de Prometheus + Grafana em pilhas de LLM

1) Alvo do Prometheus está “BAIXO”

Sintomas

• UI do Prometheus → Alvos mostra BAIXO
• “context deadline exceeded” ou conexão recusada

Checklist

• O servidor realmente expõe /metrics?
• Porta errada? Esquema errado (http vs https)?
• Kubernetes: o Service está selecionando pods? O rótulo release do ServiceMonitor está correto?

Teste rápido

curl -sS http://tgi:8080/metrics | head

2) Você pode coletar métricas, mas os painéis estão vazios

Causas mais comuns

• Nome de métrica errado (versão do servidor mudou)
• O painel espera _bucket mas você tem apenas um gauge/counter
• Intervalo de coleta do Prometheus muito longo para janelas curtas (ex: [1m] com coleta de 30s pode ser ruidoso)

Correção

• Use o Explore do Grafana para pesquisar prefixos de métrica (ex: tgi_ / vllm:)
• Aumente a janela de intervalo de [1m] → [5m]

3) Percentis de histograma parecem “planos” ou errados

Histogramas do Prometheus exigem agregação correta:

• use rate(metric_bucket[5m])
• depois sum by (le) (e opcionalmente outros rótulos estáveis)
• depois histogram_quantile()

O Prometheus documenta o modelo de bucket e cálculo de quantil do lado do servidor.
O guia de visualização de histograma do Grafana inclui padrões práticos de painéis.

4) Explosão de cardinalidade (picos de memória do Prometheus)

Sintomas

• Uso de RAM do Prometheus aumenta
• Erros de “muitas séries”

Causa típica

• Você adicionou prompt, user_id ou IDs de solicitação como rótulos em um exportador personalizado.

Correção

• Remova rótulos de alta cardinalidade
• Agregue previamente em rótulos de baixa cardinalidade (modelo, endpoint, status)
• Considere usar logs/traces para depuração por solicitação em vez de rótulos

5) “Temos métricas, mas não temos ideia de por que está lento”

Métricas são necessárias, mas às vezes você precisa de correlação:

• Adicione logs estruturados com metadados da solicitação (modelo, contagens de token, TTFT)
• Adicione rastreamento (OpenTelemetry) ao redor de sua porta de entrada + servidor de inferência
• Use exemplares (quando suportado) para pular de um pico de latência para um rastreamento

Um bom fluxo de trabalho: pico no painel do Grafana → clique em Explore → estreite por instância/modelo → verifique logs/traces para esse período.

Isso segue o modelo clássico de métricas → logs → traces descrito em guia de arquitetura de observabilidade e monitoramento.

6) Quirks de métricas de vLLM / multi-processo

Se seu stack de servidores executar em múltiplos processos, você pode precisar da configuração de múltiplos processos do Prometheus (depende de como o processo expõe métricas). Os documentos do vLLM enfatizam expor métricas via /metrics para coleta do Prometheus; verifique o modo de métricas do servidor ao implantar.

Um painel e conjunto de alertas “day-1” práticos

Se você quiser uma configuração leve que ainda funcione em produção, comece com:

Painéis do dashboard

1. Latência de solicitação p95
2. Tempo médio por token p95
3. Tamanho da fila
4. Duração da fila p95
5. Taxa de erro
6. Uso de cache KV %

Alertas

• Latência de solicitação p95 > X por 10m
• Duração da fila p99 > Y por 10m
• Taxa de erro > 1% por 5m
• Uso de cache KV > 90% por 15m
• Alvo do Prometheus desligado (sempre)

Guias de observabilidade relacionados

• Guia de observabilidade: Prometheus, Grafana & Monitoramento em Produção
• Monitoramento com Prometheus: Configuração & Melhores Práticas
• Instale e use o Grafana no Ubuntu: Guia Completo

Guias de infraestrutura de LLM relacionados

• Hosting de LLM em 2026: Local, Auto-hospedado e Nuvem Comparados
• Desempenho de LLM em 2026: Benchmarks e Otimização

Notas finais

Prometheus + Grafana lhe dão a visão “sempre ligada” da saúde da inferência. Depois de ter os fundamentos, os próximos grandes ganhos normalmente vêm de:

• SLOs por modelo / inquilino
• modelagem de solicitação (limites de tokens, limites de concorrência)
• autoscaling ligado a tempo de fila e headroom de cache KV

Para uma explicação mais ampla de monitoramento vs observabilidade, fundamentos do Prometheus e padrões de produção, veja meu guia completo sobre observabilidade.