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

A inferência de LLM parece ser “apenas outra API” — até que a latência dispare, as filas se acumulem e suas GPUs fiquem com 95% de memória sem uma explicação óbvia.

A monitorização torna-se crítica no momento em que passa de uma configuração de nó único ou começa a otimizar para o throughput. Nesse ponto, as métricas de API tradicionais não são suficientes. Você precisa de visibilidade sobre tokens, comportamento de batching, tempo de fila e pressão no cache KV — os verdadeiros gargalos dos sistemas modernos de LLM.

Este artigo faz parte do meu guia de observabilidade e monitorização, onde abordo os fundamentos de monitorização vs observabilidade, a arquitetura do Prometheus e as melhores práticas em produção. Aqui, focaremos especificamente na monitorização de cargas de trabalho de inferência de LLM.

(Se estiver a decidir sobre infraestrutura, veja o meu guia sobre hospedagem de LLM em 2026. Se quiser um mergulho profundo na mecânica de batching, limites de VRAM e trade-offs entre throughput e latência, veja o guia de engenharia de desempenho de LLM.)

Ao contrário de serviços REST típicos, o serving de LLM é moldado por tokens, batching contínuo, utilização do cache KV, saturação de GPU/CPU e dinâmicas de fila. Dois pedidos com tamanhos de carga idênticos podem ter latências radicalmente diferentes dependendo de max_new_tokens, concorrência e reutilização de cache.

Este guia é um walkthrough prático e focado na produção para construir monitorização de inferência de LLM com Prometheus e Grafana:

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

Os exemplos são intencionalmente neutros em relação ao fornecedor. Se mais tarde adicionar rastreamento OpenTelemetry, autoscaling ou uma service mesh, o mesmo modelo de métricas se aplica.

Por que deve monitorizar a inferência de LLM de forma diferente

A monitorização de API tradicional (RPS, latência p95, taxa de erro) é necessária, mas não suficiente. O serving de LLM adiciona eixos adicionais:

1) A latência tem dois significados

• Latência E2E (end-to-end): tempo desde o pedido recebido → até o último token retornado.
• Latência inter-token: tempo por token durante o decode (crítico para a UX de streaming).

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

2) O throughput está em tokens, não em pedidos

Um serviço “rápido” que retorna 5 tokens não é comparável a um que retorna 500 tokens. O seu “RPS” deve ser frequentemente “tokens/seg”.

3) A fila é o produto

Se executar batching contínuo, a profundidade da fila é o que você vende. Observar duração da fila e tamanho da fila diz-lhe se está a cumprir as expectativas dos utilizadores.

4) A pressão no cache é um precursor de outage

O esgotamento (ou fragmentação) do cache KV muitas vezes manifesta-se como picos súbitos de latência e timeouts. O vLLM expõe a utilização do cache KV como um gauge.

Checklist de métricas para monitorização de inferência de LLM

Use isto como sua bússola. Você não precisa de tudo no primeiro dia — mas vai querer a maior parte eventualmente.

Sinais dourados (com sabor de LLM)

• Tráfego: pedidos/seg, tokens/seg
• Erros: taxa de erro, timeouts, OOMs, 429s (limitação de taxa)
• Latência: duração do pedido p50/p95/p99; latência de prefill vs decode; latência inter-token
• Saturação: utilização de GPU, uso de memória, uso do cache KV, tamanho da fila

Se precisar de visibilidade de baixo nível no uso de memória da GPU, temperatura e utilização fora do Prometheus (para depuração ou configurações de nó único), veja o meu guia sobre aplicações de monitorização 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, profiling de GPU e design de SLO — veja o meu guia aprofundado sobre observabilidade para sistemas de LLM.

Dimensões úteis (labels)

Mantenha a cardinalidade de labels baixa. Bons labels:

• model, endpoint, method (prefill/decode), status (sucesso/erro), instance

Evite labels como:

• prompt bruto, user_id bruto, ids de pedido — estes explodem o número de séries.

Expôr métricas: endpoints /metrics nativos (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 o seu logger de métricas Prometheus) e publica métricas de servidor/pedido com o prefixo vllm:, incluindo gauges como pedidos em execução e utilização do cache KV.

Para configuração de contentores, serving compatível com OpenAI e ajuste de runtime orientado a throughput, veja Início Rápido do vLLM: Serving de LLM de Alto Desempenho.

Exemplos de métricas que normalmente verá:

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

Hugging Face TGI: /metrics com fila + histogramas de pedido

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

As notá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)

A configuração operacional — Docker, GPUs, flags de lançamento e as falhas que aparecem como scrapes vazios ou enganosos — está coberta em TGI - Text Generation Inference - Instalação, Configuração, Resolução de Problemas.

Servidor llama.cpp: ativar endpoint de métricas

O servidor llama.cpp suporta um endpoint de métricas compatível com Prometheus que deve ser ativado com uma flag (e.g., --metrics).

Para caminhos de instalação, flags de runtime-chave e uso do servidor compatível com OpenAI, veja Início Rápido do llama.cpp com CLI e Servidor.

Se estiver a executar llama.cpp atrás de um proxy, faça scraping diretamente no servidor sempre que possível (para evitar que a latência a nível de proxy esconda o comportamento real de inferência).

Configuração do Prometheus: scraping dos 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 scrape 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 é novo no Prometheus ou quer uma explicação mais profunda de configurações de scrape, exporters, reetiquetagem e regras de alerta, veja o meu guia completo de configuração de monitorização Prometheus.

Dica profissional: adicionar um “label de serviço”

Se executar múltiplos modelos/réplicas, adicione reetiquetagem para incluir um label de service estável para dashboards.

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

Exemplos de PromQL que pode copiar/colar

Taxa de pedidos (RPS)

sum(rate(tgi_request_count[5m]))

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

Taxa de erro (%)

Se tem contadores *_success, calcule a razão de falha:

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

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

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

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

Tempo de fila p99

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 decode e largura de banda de memória — tópicos cobertos 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 em chamadas de plantão

O Grafana pode visualizar histogramas de múltiplas formas (percentis, mapas de calor, distribuições de buckets). O Grafana Labs tem um guia detalhado sobre visualização de histogramas do Prometheus.

Um layout de dashboard minimalista e de alto sinal:

Linha 1 — Experiência do utilizador

1. Latência de pedido p95 (série temporal)
2. Latência inter-token p95 (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. Pedidos em execução vs em espera (empilhado)
6. Utilização do cache KV % (gauge)

Linha 3 — Throughput

7. Pedidos/seg
8. Tokens gerados/pedido (p50/p95)

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

Exemplos de consultas do Grafana

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

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

Se estiver a decidir entre arquiteturas de inferência locais, auto-hospedadas ou baseadas em cloud, veja a análise completa no meu guia de comparação de hospedagem 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 preferir uma instalação manual do Grafana em vez de Docker, veja o meu guia passo a passo sobre instalar e usar o Grafana no Ubuntu.

Provisão de datasource do Grafana (grafana/provisioning/datasources/datasource.yml)

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

Provisão de dashboard (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 deployment 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Se usar kube-prometheus-stack (Prometheus Operator), faça scrape de alvos via ServiceMonitor.

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

1) Expôr o seu deployment 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) Criar 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 os serviços vLLM e llama.cpp. Isto escala de forma limpa à medida que adiciona réplicas.

3) Alertas: regras estilo SLO (exemplo)

Aqui estão bons alertas iniciais:

• Alta latência p95 (taxa de queima)
• Tempo de fila p99 muito alto (utilizadores à espera)
• Taxa de erro > 1%
• Utilização do cache KV > 90% sustentada (cliff de capacidade)

Exemplo de regra (duração do pedido 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: "TGI p95 latency > 3s (10m)"

Resolução de problemas: falhas comuns de Prometheus + Grafana em stacks de LLM

1) O alvo do Prometheus está “DOWN”

Sintomas

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

Checklist

• O servidor está realmente a expor /metrics?
• Porta errada? Esquema errado (http vs https)?
• Kubernetes: o Service está a selecionar os pods? O label release do ServiceMonitor está correto?

Teste rápido

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

2) Pode fazer scrape de métricas, mas os painéis estão vazios

Causas mais comuns

• Nome da métrica errado (versão do servidor mudou)
• Dashboard espera _bucket mas só tem um gauge/contador
• Intervalo de scrape do Prometheus muito longo para janelas curtas (e.g., [1m] com scrape de 30s pode ser ruidoso)

Correção

• Use o Explore do Grafana para pesquisar prefixos de métricas (e.g., tgi_ / vllm:)
• Aumente a janela de intervalo de [1m] → [5m]

3) Percentis de histograma parecem “planos” ou errados

Os histogramas do Prometheus requerem agregação correta:

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

O Prometheus documenta o modelo de bucket e o cálculo de quantis no lado do servidor.
O guia de visualização de histogramas 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 sobe
• Erros de “too many series”

Causa raiz típica

• Adicionou prompt, user_id ou ids de pedido como labels num exporter personalizado.

Correção

• Remova labels de alta cardinalidade
• Pré-agregue em labels de baixa cardinalidade (model, endpoint, status)
• Considere usar logs/rastreamento para depuração por pedido em vez de labels

5) “Temos métricas, mas não sabemos porque está lento”

As métricas são necessárias, mas às vezes precisa de correlação:

• Adicione logs estruturados com metadados do pedido (modelo, contagem de tokens, TTFT)
• Adicione rastreamento (OpenTelemetry) em torno do seu gateway + servidor de inferência
• Use exemplares (quando suportado) para saltar de um pico de latência para um rasto

Um bom fluxo de trabalho: pico no dashboard do Grafana -> clique em Explore -> filtre por instance/model -> verifique logs/rastros para esse período.

Isto segue o modelo clássico métricas -> logs -> rastros descrito no guia de arquitetura de observabilidade e monitorização.

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

Se o seu stack de serving correr em múltiplos processos, pode precisar de configuração multi-processo do Prometheus (depende de como o processo expõe métricas). A documentação do vLLM enfatiza a exposição de métricas via /metrics para polling do Prometheus; verifique o modo de métricas do servidor ao fazer deployment.

Um dashboard e conjunto de alertas práticos para o “dia-1”

Se quiser uma configuração esbelta que ainda funciona em produção, comece com:

Painéis do dashboard

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

Alertas

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

Guias de Observabilidade Relacionados

• Guia de Observabilidade: Prometheus, Grafana & Monitorização em Produção
• Monitorização Prometheus: Configuração & Melhores Práticas
• Instalar e Usar Grafana no Ubuntu: Guia Completo

Guias de Infraestrutura de LLM Relacionados

• Hospedagem de LLM em 2026: Local, Auto-Hospedado & Cloud Comparados
• Desempenho de LLM em 2026: Benchmarks & Otimização

Notas finais

Prometheus + Grafana dá-lhe a visão “sempre ativa” da saúde da inferência. Uma vez que tenha o básico, os próximos grandes ganhos geralmente vêm de:

• SLOs por modelo / inquilino
• Moldagem de pedidos (max tokens, limites de concorrência)
• Autoscaling ligado ao tempo de fila e margem do cache KV

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