Monitorear la inferencia de LLM en producción (2026): Prometheus y Grafana para vLLM, TGI, llama.cpp

La inferencia de LLM parece “solo otra API” — hasta que aparecen picos de latencia, se forman colas y tus GPUs se quedan en un 95% de memoria sin una explicación obvia.

El monitoreo se vuelve crítico en el momento en que te alejas de un entorno de un solo nodo o comienzas a optimizar para el throughput. En ese punto, las métricas tradicionales de API no son suficientes. Necesitas visibilidad sobre tokens, comportamiento de lotes, tiempo en cola y presión de caché KV — los verdaderos cuellos de botella de los sistemas LLM modernos.

Este artículo forma parte de mi guía más amplia sobre observabilidad y monitoreo, donde cubro fundamentos de monitoreo vs observabilidad, arquitectura de Prometheus y mejores prácticas en producción. Aquí, nos enfocaremos específicamente en monitoreo de cargas de trabajo de inferencia de LLM.

(Si estás decidiendo sobre infraestructura, consulta mi guía sobre anfitrionado de LLM en 2026. Si deseas una inmersión profunda en mecánicas de lotes, límites de VRAM y trade-offs entre throughput y latencia, consulta la guía de ingeniería de rendimiento de LLM.)

A diferencia de los servicios REST típicos, el servicio de LLM está definido por tokens, loteo continuo, utilización de caché KV, saturación de GPU/CPU y dinámica de cola. Dos solicitudes con tamaños de carga idénticos pueden tener latencias radicalmente diferentes según max_new_tokens, concurrency y reutilización de caché.

Esta guía es un recorrido práctico, orientado a producción, para construir monitoreo de inferencia de LLM con Prometheus y Grafana:

• Qué medir (p95/p99 latencia, tokens/seg, duración en cola, utilización de caché, tasa de errores)
• Cómo escanear /metrics desde servidores comunes (vLLM, Hugging Face TGI, llama.cpp)
• Ejemplos de PromQL para percentiles, saturación y throughput
• Patrones de despliegue con Docker Compose y Kubernetes
• Solución de problemas con los problemas que solo aparecen bajo carga real

Los ejemplos son intencionalmente neutrales en cuanto a proveedor. Ya sea que posteriormente agregues seguimiento de OpenTelemetry, escalado automático o una red de servicios, el mismo modelo de métricas se aplica.

Por qué debes monitorear la inferencia de LLM de manera diferente

El monitoreo tradicional de API (RPS, latencia p95, tasa de errores) es necesario pero no suficiente. El servicio de LLM agrega ejes adicionales:

1) La latencia tiene dos significados

• Latencia E2E: tiempo desde que se recibe la solicitud hasta que se devuelve el último token.
• Latencia inter-token: tiempo por token durante el descodificación (crítica para la experiencia de usuario en streaming).

Algunos servidores exponen ambos. Por ejemplo, TGI expone la duración de la solicitud y el tiempo promedio por token como histogramas.

2) El throughput se mide en tokens, no en solicitudes

Un servicio “rápido” que devuelve 5 tokens no es comparable con uno que devuelve 500 tokens. Tu “RPS” debería ser a menudo “tokens/seg”.

3) La cola es el producto

Si ejecutas loteo continuo, la profundidad de la cola es lo que vendes. Observar duración de cola y tamaño de cola te dice si estás cumpliendo con las expectativas de los usuarios.

4) La presión de caché es un precursor de interrupciones

La agotación de caché KV (o fragmentación) suele aparecer como picos repentinos de latencia y tiempos de espera. vLLM expone el uso de caché KV como un gauge.

Lista de verificación de métricas para el monitoreo de inferencia de LLM

Usa esto como tu brújula. No necesitas todo el día uno, pero eventualmente querrás la mayoría de ello.

Señales doradas (LLM-flavored)

• Tráfico: solicitudes/seg, tokens/seg
• Errores: tasa de errores, tiempos de espera, OOMs, 429s (limitación de tasa)
• Latencia: p50/p95/p99 duración de solicitud; latencia de prellenado vs descodificación; latencia inter-token
• Saturación: utilización de GPU, uso de memoria, utilización de caché KV, tamaño de cola

Si necesitas visibilidad a nivel bajo sobre el uso de memoria de GPU, temperatura y utilización fuera de Prometheus (para depuración o configuraciones de solo nodo), consulta mi guía sobre aplicaciones de monitoreo de GPU en Linux / Ubuntu.

Para una visión más amplia de la observabilidad de LLM más allá de las métricas — incluyendo seguimiento, logs estructurados, pruebas sintéticas, perfilado de GPU y diseño de SLO — consulta mi guía detallada sobre observabilidad para sistemas de LLM.

Dimensiones útiles (etiquetas)

Mantén la cardinalidad de etiquetas baja. Buenas etiquetas:

• modelo, endpoint, método (prefill/decode), estado (éxito/error), instancia

Evita etiquetas como:

• prompt crudo, user_id crudo, IDs de solicitud — estas explotan la cantidad de series.

Exponiendo métricas: puntos finales /metrics integrados (vLLM, TGI, llama.cpp)

La ruta más fácil es: usar las métricas que ya expone el servidor.

vLLM: /metrics compatible con Prometheus

vLLM expone un punto final /metrics compatible con Prometheus (vía su registrador de métricas de Prometheus) y publica métricas del servidor/solicitud con el prefijo vllm:, incluyendo gauges como solicitudes en ejecución y uso de caché KV.

Ejemplos de métricas que normalmente verás:

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

Hugging Face TGI: /metrics con cola + histogramas de solicitud

TGI expone muchas métricas de producción en /metrics, incluyendo tamaño de cola, duración de solicitud, duración de cola y tiempo promedio por token.

Notables:

• tgi_queue_size (gauge)
• tgi_request_duration (histograma, latencia E2E)
• tgi_request_queue_duration (histograma)
• tgi_request_mean_time_per_token_duration (histograma)

Servidor llama.cpp: habilitar el punto final de métricas

El servidor llama.cpp soporta un punto final de métricas compatible con Prometheus que debe habilitarse con una bandera (ej., --metrics).

Si estás ejecutando llama.cpp detrás de un proxy, escanea directamente al servidor siempre que sea posible (para evitar que la latencia del proxy oculte el comportamiento real de inferencia).

Configuración de Prometheus: escaneo de tus servidores de inferencia

Este ejemplo asume:

• vLLM en http://vllm:8000/metrics
• TGI en http://tgi:8080/metrics
• llama.cpp en http://llama:8080/metrics
• intervalo de escaneo ajustado para retroalimentación rápida

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"]

Si eres nuevo en Prometheus o quieres una explicación más profunda sobre configuraciones de escaneo, exportadores, reetiquetado y reglas de alerta, consulta mi guía completa sobre configuración de monitoreo con Prometheus.

Consejo profesional: agregar una etiqueta “servicio”

Si ejecutas múltiples modelos/replicas, agrega reetiquetado para incluir una etiqueta estable service para paneles.

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

Ejemplos de PromQL que puedes copiar/pegar

Tasa de solicitudes (RPS)

sum(rate(tgi_request_count[5m]))

Para vLLM, usa sus contadores de solicitud (los nombres varían según la versión), pero el patrón es el mismo: sum(rate(<counter>[5m])).

Tasa de errores (%)

Si tienes contadores *_success, calcula la tasa de fallos:

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

p95 latencia para métricas de histograma (Prometheus)

Los histogramas de Prometheus son conteos por cubo; usa histogram_quantile() sobre rate() de los cubos. Prometheus documenta este modelo y los trade-offs entre histograma y resumen.

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

p99 tiempo en cola

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

Tiempo promedio por token (latencia inter-token)

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

La latencia inter-token suele estar limitada por cuellos de botella de descodificación y ancho de banda de memoria — temas cubiertos en detalle en guía de optimización de rendimiento de LLM.

Profundidad de cola (instantánea)

max(tgi_queue_size)

Utilización de caché KV de vLLM (instantánea)

max(vllm:kv_cache_usage_perc)

Paneles de Grafana: paneles que realmente ayudan a los encargados de resolver problemas

Grafana puede visualizar histogramas de varias formas (percentiles, mapas de calor, distribuciones de cubos). Grafana Labs tiene una guía detallada sobre visualización de histogramas de Prometheus.

Un diseño de panel minimalista, de alto impacto:

Fila 1 — Experiencia del usuario

1. Latencia p95 de solicitud (series de tiempo)
2. Latencia p95 inter-token (series de tiempo)
3. Tasa de errores (series de tiempo + estadística)

Fila 2 — Capacidad y saturación

4. Tamaño de cola (series de tiempo)
5. Solicitudes en ejecución vs en espera (apilado)
6. Uso de caché KV % (gauge)

Fila 3 — Throughput

7. Solicitudes/seg
8. Tokens generados/solicitud (p50/p95)

Si tienes streaming, agrega un panel para “latencia del primer token” (TTFT) cuando esté disponible.

Consultas de ejemplo de Grafana

• Panel de latencia p95: la consulta histogram_quantile(0.95, …) mencionada anteriormente
• Panel de mapa de calor: grafica las tasas de cubos (*_bucket) como mapa de calor (Grafana soporta este enfoque)

Opción de despliegue 1: Docker Compose (rápido local + solo nodo)

Si estás decidiendo entre arquitecturas locales, autohospedadas o en la nube, consulta el análisis completo en mi guía de comparación de anfitrionado de LLM.

Crea una carpeta 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

Si prefieres una instalación manual de Grafana en lugar de Docker, consulta mi guía paso a paso sobre instalación y uso de Grafana en Ubuntu.

Provisionamiento de fuente de datos de Grafana (grafana/provisioning/datasources/datasource.yml)

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

Provisionamiento de paneles de Grafana (grafana/provisioning/dashboards/dashboards.yml)

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

Opción de despliegue 2: Kubernetes (Operador de Prometheus + ServiceMonitor)

Si usas kube-prometheus-stack (Operador de Prometheus), escanea objetivos mediante ServiceMonitor.

Para trade-offs de infraestructura entre Kubernetes, solo nodo Docker y proveedores de inferencia gestionada, consulta mi guía de anfitrionado de LLM en 2026.

1) Exponer tu despliegue de inferencia con un Service

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

2) Crear un 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

Repite para servicios de vLLM y llama.cpp. Esto escala limpiamente a medida que añades réplicas.

3) Alertas: reglas estilo SLO (ejemplo)

Aquí hay buenas alertas iniciales:

• Latencia p95 alta (tasa de quemado)
• Tiempo en cola p99 demasiado alto (usuarios esperando)
• Tasa de errores > 1%
• Uso de caché KV > 90% sostenido (cliff de capacidad)

Ejemplo de regla (duración de solicitud 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: "Latencia p95 de TGI > 3s (10m)"

Solución de problemas: fallos comunes de Prometheus + Grafana en pilas de LLM

1) El objetivo de Prometheus está “DESCONECTADO”

Síntomas

• Interfaz de usuario de Prometheus → Objetivos muestra DESCONECTADO
• “context deadline exceeded” o conexión rechazada

Lista de verificación

• ¿El servidor realmente expone /metrics?
• ¿Puerto incorrecto? ¿Esquema incorrecto (http vs https)?
• Kubernetes: ¿El Service selecciona pods? ¿La etiqueta release de ServiceMonitor es correcta?

Prueba rápida

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

2) Puedes escanear métricas, pero los paneles están vacíos

Causas más comunes

• Nombre de métrica incorrecto (versión del servidor cambió)
• El panel espera _bucket pero solo tienes un gauge/counter
• Intervalo de escaneo de Prometheus demasiado largo para ventanas cortas (ej., [1m] con 30s de escaneo puede ser ruidoso)

Solución

• Usa Grafana Explore para buscar prefijos de métricas (ej., tgi_ / vllm:)
• Aumenta el rango de ventana de [1m] → [5m]

3) Percentiles de histograma parecen “planos” o incorrectos

Los histogramas de Prometheus requieren agregación correcta:

• Usa rate(metric_bucket[5m])
• Luego sum by (le) (y opcionalmente otras etiquetas estables)
• Luego histogram_quantile()

Prometheus documenta el modelo de cubos y cálculo de percentiles del lado del servidor.
La guía de visualización de histogramas de Grafana incluye patrones de panel prácticos.

4) Explosión de cardinalidad (picos de memoria de Prometheus)

Síntomas

• Uso de RAM de Prometheus sube
• Errores de “demasiadas series”

Causa típica

• Agregaste prompt, user_id o IDs de solicitud como etiquetas en un exportador personalizado.

Solución

• Elimina etiquetas de alta cardinalidad
• Agrega previamente en etiquetas de baja cardinalidad (modelo, endpoint, estado)
• Considera usar logs/trazas para depuración por solicitud en lugar de etiquetas

5) “Tenemos métricas, pero no tenemos idea de por qué es lento”

Las métricas son necesarias, pero a veces necesitas correlación:

• Añade logs estructurados con metadatos de solicitud (modelo, conteo de tokens, TTFT)
• Añade seguimiento (OpenTelemetry) alrededor de tu puerta de entrada + servidor de inferencia
• Usa ejemplares (cuando se soporten) para saltar de un pico de latencia a una traza

Un buen flujo de trabajo: pico en el panel de Grafana → haz clic en Explore → estrecha por instancia/modelo → revisa logs/trazas para ese período.

Esto sigue el modelo clásico de métricas → logs → trazas descrito en guía de arquitectura de observabilidad y monitoreo.

6) Quirks de métricas de vLLM / múltiples procesos

Si tu pila de servicio se ejecuta en múltiples procesos, podrías necesitar la configuración de múltiples procesos de Prometheus (depende de cómo el proceso expone las métricas). Los documentos de vLLM destacan la exposición de métricas a través de /metrics para el escaneo de Prometheus; revisa el modo de métricas del servidor al desplegar.

Un conjunto de dashboard y alertas prácticos para el día 1

Si quieres un despliegue delgado que aún funcione en producción, comienza con:

Paneles de dashboard

1. Latencia p95 de solicitud
2. Tiempo promedio por token p95
3. Tamaño de cola
4. Duración de cola p95
5. Tasa de errores
6. Uso de caché KV %

Alertas

• Latencia p95 de solicitud > X por 10m
• Duración de cola p99 > Y por 10m
• Tasa de errores > 1% por 5m
• Uso de caché KV > 90% por 15m
• Objetivo de Prometheus desconectado (siempre)

Guías de observabilidad relacionadas

• Guía de observabilidad: Prometheus, Grafana y monitoreo en producción
• Monitoreo con Prometheus: Configuración y mejores prácticas
• Instalación y uso de Grafana en Ubuntu: Guía completa

Guías de infraestructura de LLM relacionadas

• Anfitrionado de LLM en 2026: Local, autohospedado y en la nube comparados
• Rendimiento de LLM en 2026: Benchmarks y optimización

Notas finales

Prometheus + Grafana te dan una vista “siempre activa” del estado de la inferencia. Una vez que tengas los fundamentos, las siguientes grandes victorias suelen venir de:

• SLOs por modelo / inquilino
• modelado de solicitudes (máximo de tokens, límites de concurrencia)
• escalado automático vinculado a tiempo en cola y margen de caché KV

Para una explicación más amplia sobre monitoreo vs observabilidad, fundamentos de Prometheus y patrones en producción, consulta mi guía completa sobre observabilidad.