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

La inferencia de LLM parece ser “solo otra API” hasta que se producen picos de latencia, las colas se saturan y tus GPUs se mantienen al 95% de uso de memoria sin una explicación obvia.

La supervisión se vuelve crítica en el momento en que pasas de una configuración de nodo único o comienzas a optimizar para el rendimiento. En ese punto, las métricas de API tradicionales no son suficientes. Necesitas visibilidad sobre los tokens, el comportamiento del agrupamiento por lotes (batching), el tiempo de cola y la presión del caché KV: los verdaderos cuellos de botella de los sistemas modernos de LLM.

Este artículo es parte de mi guía más amplia sobre observabilidad y supervisión, donde cubro los fundamentos de supervisión frente a observabilidad, la arquitectura de Prometheus y las mejores prácticas para producción. Aquí nos centraremos específicamente en supervisar cargas de trabajo de inferencia de LLM.

(Si estás decidiendo sobre la infraestructura, consulta mi guía sobre alojamiento de LLM en 2026. Si deseas profundizar en la mecánica del agrupamiento, los límites de VRAM y las compensaciones entre rendimiento 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á determinado por tokens, agrupamiento continuo, utilización del caché KV, saturación de GPU/CPU y dinámica de la cola. Dos solicitudes con tamaños de carga idénticos pueden tener latencias radicalmente diferentes dependiendo de max_new_tokens, conurrencia y reutilización del caché.

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

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

Los ejemplos son intencionalmente neutrales respecto al proveedor. Ya sea que luego agregues trazabilidad con OpenTelemetry, escalado automático o una malla de servicios, el mismo modelo de métricas aplica.

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

La supervisión tradicional de API (RPS, latencia p95, tasa de errores) es necesaria pero no suficiente. El servicio de LLM añade ejes adicionales:

1) La latencia tiene dos significados

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

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

2) El rendimiento está 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 agrupamiento continuo, la profundidad de la cola es lo que vendes. Observar la duración de la cola y el tamaño de la cola te indica si estás cumpliendo las expectativas de los usuarios.

4) La presión del caché es un precursor de caída

El agotamiento (o fragmentación) del caché KV a menudo se manifiesta como picos repentinos de latencia y tiempos de espera. vLLM expone el uso del caché KV como un medidor (gauge).

Lista de verificación de métricas para supervisión de inferencia de LLM

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

Señales doradas (con sabor LLM)

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

Si necesitas visibilidad de bajo nivel sobre el uso de memoria de GPU, temperatura y utilización fuera de Prometheus (para depuración o configuraciones de nodo único), consulta mi guía sobre aplicaciones de supervisión 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 trazabilidad, registros estructurados, pruebas sintéticas, perfiles de GPU y diseño de SLO, consulta mi guía exhaustiva sobre observabilidad para sistemas LLM.

Dimensiones útiles (etiquetas)

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

• model, endpoint, method (prefill/decode), status (success/error), instance

Evita etiquetas como:

• prompt en crudo, user_id en crudo, IDs de solicitud: estos explotan el conteo de series.

Exposición de métricas: endpoints /metrics integrados (vLLM, TGI, llama.cpp)

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

vLLM: /metrics compatible con Prometheus

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

Para la configuración de contenedores, servicio compatible con OpenAI y sintonización de tiempo de ejecución orientada al rendimiento, consulta Inicio rápido de vLLM: Servicio de LLM de alto rendimiento.

Ejemplos de métricas que verás típicamente:

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

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

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

Notables:

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

La configuración operativa—Docker, GPUs, banderas de lanzamiento y los fallos que aparecen como extracciones vacías o engañosas—se cubre en TGI - Text Generation Inference - Instalación, Configuración, Solución de problemas.

Servidor llama.cpp: habilitar endpoint de métricas

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

Para rutas de instalación, banderas clave de tiempo de ejecución y uso del servidor compatible con OpenAI, consulta Inicio rápido de llama.cpp con CLI y Servidor.

Si ejecutas llama.cpp detrás de un proxy, extrae el servidor directamente siempre que sea posible (para evitar que la latencia a nivel de proxy oculte el comportamiento de inferencia real).

Configuración de Prometheus: extrayendo 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 extracción sintonizado 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 deseas una explicación más profunda de configuraciones de extracción, exportadores, reetiquetado y reglas de alerta, consulta mi guía completa de configuración de supervisión de Prometheus.

Consejo profesional: añade una “etiqueta de servicio”

Si ejecutas múltiples modelos/replicas, añade reetiquetado para incluir una etiqueta service estable para los paneles.

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

Ejemplos de PromQL que puedes copiar y 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 ratio de fallo:

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

Latencia p95 para métricas de histograma (Prometheus)

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

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

Tiempo de cola p99

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

Tiempo medio 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 a menudo está limitada por cuellos de botella de decodificació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 del caché KV de vLLM (instantánea)

max(vllm:kv_cache_usage_perc)

Paneles de Grafana: paneles que realmente ayudan al equipo de guardia

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

Un diseño de panel minimalista y de alta señal:

Fila 1 — Experiencia del usuario

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

Fila 2 — Capacidad y saturación

4. Tamaño de cola (serie temporal)
5. Solicitudes en ejecución vs esperando (apilado)
6. Uso del caché KV % (medidor)

Fila 3 — Rendimiento

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

Si tienes streaming, añade 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, …) anterior
• Panel de mapa de calor: grafica las tasas de cubos (*_bucket) como un mapa de calor (Grafana soporta este enfoque)

Opción de implementación 1: Docker Compose (rápido local + nodo único)

Si estás decidiendo entre arquitecturas de inferencia local, autoalojadas o basadas en la nube, consulta el desglose completo en mi guía de comparación de alojamiento 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 instalar y usar Grafana en Ubuntu.

Aprovisionamiento 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

Aprovisionamiento de paneles (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 implementación 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Si usas kube-prometheus-stack (Prometheus Operator), extrae objetivos mediante ServiceMonitor.

Para las compensaciones de infraestructura entre Kubernetes, Docker de nodo único y proveedores de inferencia gestionados, consulta mi guía de alojamiento 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 los servicios vLLM y llama.cpp. Esto escala de forma limpia a medida que añades réplicas.

3) Alertas: reglas estilo SLO (ejemplo)

Aquí hay algunas buenas alertas de inicio:

• Alta latencia p95 (tasa de quema)
• Tiempo de cola p99 demasiado alto (usuarios esperando)
• Tasa de errores > 1%
• Uso del caché KV > 90% sostenido (precipicio 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: "TGI latencia p95 > 3s (10m)"

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

1) El objetivo de Prometheus está “CAÍDO”

Síntomas

• Prometheus UI → Objetivos muestra DOWN
• “contexto deadline exceeded” o conexión rechazada

Lista de verificación

• ¿El servidor está exponiendo realmente /metrics?
• ¿Puerto incorrecto? ¿Esquema incorrecto (http vs https)?
• Kubernetes: ¿el Service selecciona los pods? ¿La etiqueta release del ServiceMonitor es correcta?

Prueba rápida

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

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

Causas más comunes

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

Solución

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

3) Los percentiles de histograma parecen “planos” o incorrectos

Los histogramas de Prometheus requieren una 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 el cálculo de cuantiles 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

• El uso de RAM de Prometheus aumenta
• Errores de “demasiadas series”

Causa raíz típica

• Añadiste prompt, user_id o IDs de solicitud como etiquetas en un exportador personalizado.

Solución

• Elimina etiquetas de alta cardinalidad
• Pre-agrega en etiquetas de baja cardinalidad (modelo, endpoint, estado)
• Considera usar registros/trazas para depuración por solicitud en lugar de etiquetas

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

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

• Añade registros estructurados con metadatos de solicitud (modelo, conteo de tokens, TTFT)
• Añade trazabilidad (OpenTelemetry) alrededor de tu puerta de enlace + servidor de inferencia
• Usa ejemplos (cuando se soporta) para saltar de un pico de latencia a una traza

Un buen flujo de trabajo: pico en el panel de Grafana -> hacer clic en Explore -> filtrar por instancia/modelo -> revisar registros/trazas para ese periodo.

Esto sigue el modelo clásico métricas -> registros -> trazas descrito en guía de arquitectura de observabilidad y supervisión.

6) Quirkes de métricas de vLLM / multiproceso

Si tu pila de servicio se ejecuta en múltiples procesos, es posible que necesites la configuración multiproceso de Prometheus (depende de cómo el proceso expone métricas). La documentación de vLLM enfatiza exponer métricas a través de /metrics para polling de Prometheus; revisa el modo de métricas del servidor al desplegar.

Un panel y conjunto de alertas práctico para el “día 1”

Si quieres una configuración ligera que aún funcione en producción, comienza con:

Paneles del panel

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

Alertas

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

Guías de Observabilidad Relacionadas

• Guía de Observabilidad: Prometheus, Grafana & Supervisión de Producción
• Supervisión con Prometheus: Configuración y Mejores Prácticas
• Instalar y Usar Grafana en Ubuntu: Guía Completa

Guías de Infraestructura LLM Relacionadas

• Alojamiento de LLM en 2026: Local, Autoalojado y Nube Comparados
• Rendimiento de LLM en 2026: Benchmarks y Optimización

Notas finales

Prometheus + Grafana te da la visión “siempre activa” de la salud de la inferencia. Una vez que tengas lo básico, las siguientes grandes ganancias suelen venir de:

• SLO por modelo / inquilino
• Moldeado de solicitudes (tokens máximos, límites de concurrencia)
• Escalado automático vinculado al tiempo de cola y el margen del caché KV

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