Observabilidad para sistemas de LLM: Métricas, rastreos, registros y pruebas en producción

LLM sistemas fallan de maneras que la supervisión tradicional de API no puede detectar — las colas se llenan silenciosamente, la memoria de GPU se satura mucho antes de que la CPU parezca ocupada, y la latencia explota en la capa de lotes en lugar de en la capa de aplicación. Esta guía cubre una estrategia de observabilidad completa para la inferencia de LLM y aplicaciones de LLM: qué medir, cómo instrumentar con Prometheus, OpenTelemetry y Grafana, y cómo desplegar la tubería de telemetría a gran escala.

TL;DR (Resumen ejecutivo)

Los sistemas de LLM degradan en formas que la supervisión clásica de “latencia HTTP + tasa de errores” no puede explicar. La Observabilidad para sistemas de LLM a nivel de producción debe responder rápidamente y defensivamente:

• ¿Si la experiencia del usuario está empeorando (latencia de cola, tiempo hasta primer token, latencia entre tokens, errores y abortos).
• ¿Dónde se gasta el tiempo (en cola vs lotes vs ejecución del modelo; recuperación/herramientas/filtros de seguridad vs inferencia).
• ¿Qué se satura primero (utilización de GPU y presión de memoria, presión de KV-cache/cola, tokenización de CPU).
• ¿Cómo se desvían el costo y la capacidad (tokens por solicitud, tokens/sec por GPU, tasa de aciertos en caché, generaciones desperdiciadas).
• ¿Si la telemetría es segura para almacenar (los prompts pueden contener PII; evitar fugas de información sensible en logs/atributos).

El diseño más resiliente es una tubería de múltiples señales:

• Métricas para detección rápida y planificación de capacidad (Prometheus + PromQL; almacenamiento a largo plazo opcional mediante Thanos/Cortex/Mimir/VictoriaMetrics).
• Trazas para causalidad a nivel de solicitud (OpenTelemetry con OTLP; backends como Tempo/Jaeger/Zipkin/Elastic APM).
• Logs para contexto, correlacionados con trazas (Loki/Elastic/OpenSearch), diseñados para metadatos de baja cardinalidad.
• Perfiles para puntos calientes de CPU/memoria y latencia de cola (Grafana Pyroscope).
• Pruebas sintéticas + de carga para detectar regresiones antes que los usuarios lo hagan (Grafana k6; pruebas de tipo blackbox).
• SLOs para medir resultados del usuario y promover alertas accionables (presupuesto de errores; estilo de tasa de quema).

¿Qué hace diferente la observabilidad para sistemas de LLM?

Nota de alcance: el marco objetivo de LLM es no especificado. Los ejemplos en este artículo cubren servidores/marcos comunes (Triton, vLLM, TGI, LangChain/LangSmith) y permanecen aplicables a otros stacks sustituyendo métricas y spans equivalentes.

Los LLM introducen comportamientos operativos que difieren de los servicios web convencionales:

• Trabajo variable por solicitud: la cantidad de tokens (entrada/salida) varía ampliamente, por lo que “solicitudes por segundo” pueden parecer estables mientras que el throughput de tokens colapsa. TGI y vLLM exportan explícitamente telemetría relacionada con tokens y latencia de tokens para apoyar este tipo de monitoreo.
• Colas + lotes continuos: el throughput depende de disciplinas de lotes/colas; el tamaño de la cola y el tamaño del lote se convierten en indicadores de primer orden (TGI expone ambos).
• Experiencia de usuario en streaming: los usuarios se preocupan al menos tanto por TTFT y latencia entre tokens como por el tiempo total de respuesta; OpenTelemetry incluso estandariza métricas de TTFT/tiempo por token bajo convenciones semánticas de GenAI.
• Presión de GPU domina los modos de falla: la utilización de GPU y la memoria de GPU (incluyendo memoria usada) son centrales para la fiabilidad; el exportador de DCGM de NVIDIA existe específicamente para exponer telemetría de GPU en un endpoint de Prometheus /metrics.
• Pipelines de múltiples pasos: recuperación, llamadas a herramientas, filtros de seguridad y postprocesamiento significan que la latencia de extremo a extremo es una composición de múltiples spans/colas — haciendo esencial el rastreo distribuido y el diseño cuidadoso de métricas.

Ejemplos concretos de servidores de inferencia populares destacan esto:

• Servidor de inferencia NVIDIA Triton expone métricas como texto plano a través de /metrics (comúnmente :8002/metrics) y proporciona banderas para habilitar/deshabilitar métricas y seleccionar un puerto de métricas.
• vLLM expone un amplio endpoint de Prometheus /metrics con un prefijo vllm:; su documentación incluye contadores para tokens de generación y histogramas como tiempo hasta primer token.
• TGI de Hugging Face documenta un endpoint /metrics con tamaño de cola, tamaño de lote, duración de solicitud de extremo a extremo, tokens generados y duración de cola.

Tareas clave de observabilidad y telemetría requerida para LLM

La observabilidad para sistemas de LLM es más fácil de implementar cuando mapeas tareas → señales → herramientas, y luego restringes cardinalidad y muestreo desde el primer día.

Métricas: Para sistemas de servicio en línea, la propia guía de instrumentación de Prometheus destaca el recuento de consultas, errores y latencia como métricas clave; los LLM expanden esto con TTFT, throughput/latencia por token, longitud de cola, tamaño de lote y utilización de GPU.

Trazas: Las trazas son cómo atribuyes latencia y fallas a través de etapas de recuperación/herramientas/seguridad/inferencia; OpenTelemetry enmarca trazas/exportadores como una manera neutral de proveedores para emitir y enviar telemetría a recolectores o backends.

Logs: Los logs proporcionan contexto legible para humanos y “por qué”, pero solo permanecen útiles a gran escala si evitas indexar valores no acotados (ejemplo: Loki indexa etiquetas solo y almacena fragmentos comprimidos de logs en almacenamiento de objetos).

Perfiles: El perfilado continuo captura comportamiento de CPU/memoria en producción con muestreo de baja sobrecarga; Grafana Pyroscope está explícitamente posicionado para esto.

Pruebas sintéticas y de carga: Grafana k6 es una herramienta de prueba de carga de código abierto, y Grafana señala que el monitoreo sintético está impulsado por k6 y va más allá de las simples verificaciones de protocolo.

SLOs: La guía de SRE de Google define un SLO como un valor/rango objetivo para un nivel de servicio medido por un SLI, y proporciona orientación para alertar sobre SLOs (intercambios de precisión/recordatorio/tiempo de detección).

Blueprints clave de métricas de LLM

Convenciones semánticas de GenAI de OpenTelemetry para estandarización

OpenTelemetry proporciona convenciones semánticas de GenAI (estado: “Desarrollo”) con nombres estándar para métricas de GenAI como:

• gen_ai.client.token.usage y gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token, y gen_ai.server.time_to_first_token

Esta estandarización es un palo práctico para estrategias portables de “monitoreo de modelos LLM con OpenTelemetry”: emitir una vez y enrutar la misma telemetría a backends OSS o de proveedores más adelante.

Diseño de la tubería de telemetría

Pull vs push

Prometheus es pull-first. Los procesos exponen métricas en un formato de exposición compatible, y Prometheus las raspa según trabajos de raspado configurados.

Push es para excepciones. La guía de “Cuándo usar el Pushgateway” de Prometheus recomienda explícitamente el Pushgateway solo en casos limitados (no como un reemplazo general de push), y el README del Pushgateway enfatiza que no puede “convertir a Prometheus en un sistema de monitoreo basado en push”.

Patrón práctico específico de LLM:

• Usa pull para servidores de inferencia/exportadores (endpoints de métricas de Triton/vLLM/TGI; exportador DCGM; métricas de nodo).
• Usa OTLP push para trazas/logs/métricas de OTel (el protocolo OpenTelemetry define transporte/encoding/delivery entre fuentes, recolectores y backends).
• Usa remote write al escalar más allá de un solo Prometheus (Prometheus proporciona orientación para ajustar remote write; Mimir/Thanos/Cortex proporcionan opciones de almacenamiento a largo plazo y/o HA).

Agente vs sidecar vs recolectores gateway

OpenTelemetry documenta un patrón de despliegue de agente, donde la telemetría se envía a un recolector que se ejecuta junto con la aplicación o en el mismo host (sidecar/DaemonSet), luego se exporta.

Para Kubernetes, se admite la inyección de sidecar mediante el Operador de OpenTelemetry (inyección basada en anotaciones).

Regla práctica para stacks de LLM:

• Usa un agente DaemonSet para enriquecimiento a nivel de host y pipelines compartidos entre muchos pods.
• Usa un sidecar cuando necesites aislamiento estricto por carga de trabajo o filtrado local dedicado (común cuando los prompts puedan contener datos sensibles).
• Usa un recolector gateway para muestreo centralizado de cola, lotes, reintentos y exportación de fan-out.

Muestreo y control de cardinalidad

OpenTelemetry aclaró que el muestreo de cola permite decisiones de muestreo usando criterios derivados de una traza (no posible con muestreo de cabeza solo).

La guía de instrumentación de Prometheus advierte contra el uso excesivo de etiquetas, proporciona una regla de dedo para mantener baja cardinalidad y aconseja rediseñar métricas si la cardinalidad potencial excede ~100.

“Trampas de cardinalidad” específicas de LLM a evitar desde el principio:

• Texto de prompt, texto de respuesta, IDs de conversación, IDs de solicitud como etiquetas/atributos.
• Blobs de argumentos de herramienta como atributos de span.
• “user_id” no acotado como etiquetas.

Prefiere dimensiones acotadas: modelo, familia de modelos, endpoint, región, código de estado, implementación, inquilino (solo si acotado).

Comparación de herramientas de observabilidad de LLM

Herramientas mapeadas a tareas de observabilidad

Grafana vs alternativas para visualización

• Los dashboards de Grafana están compuestos por paneles que consultan fuentes de datos (incluyendo Loki y Mimir) para producir gráficos y visualizaciones.
• Kibana proporciona dashboards/visualizaciones como la capa de UI dentro del stack de Elastic.
• OpenSearch Dashboards proporciona herramientas de visualización de datos para OpenSearch.
• La documentación de InfluxData posiciona Chronograf como el componente de visualización dentro del ecosistema de Influx.

Prometheus vs alternativas para backends de métricas

• Almacenamiento local predeterminado de Prometheus: si no se establecen banderas de retención, la retención predeterminada es 15d (planifique la retención/costo desde el principio).
• Grafana Mimir se describe como almacenamiento a largo plazo, escalable horizontalmente y de alta disponibilidad para métricas de Prometheus y OpenTelemetry.
• Thanos se describe como un conjunto de Prometheus de alta disponibilidad con capacidades de almacenamiento a largo plazo.
• Cortex se describe como una solución de almacenamiento a largo plazo, escalable horizontalmente y de alta disponibilidad para métricas de Prometheus y OpenTelemetry.
• VictoriaMetrics Cloud documenta la integración de escritura remota de Prometheus para almacenamiento a largo plazo.
• El servicio gestionado de Amazon para Prometheus describe una oferta gestionada que escala con las necesidades de ingesta/consulta y admite PromQL y escritura remota.

Cocina de implementación práctica

Nombres y tipos de métricas para implementar hoy

Las convenciones semánticas de GenAI de OpenTelemetry (estado: Desarrollo) definen nombres de métricas que puedes estandarizar inmediatamente:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Ejemplos de servidor que puedes raspar ahora mismo:

• El endpoint de Prometheus de vLLM incluye contadores (ej., total de tokens de generación) y histogramas (TTFT) y documenta una estrategia de etiqueta model_name.
• TGI documenta métricas incluyendo tamaño de cola, duración de solicitud, tokens generados y tiempo medio por token.
• Triton documenta la exposición de /metrics y conmutadores de métricas.

Ejemplos de PromQL para dashboards de latencia y throughput de LLM

# p95 de latencia de extremo a extremo para un histograma de aplicación
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Porcentaje de tasa de error (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Tokens/sec (salida) a través de todos los modelos
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Tamaño de cola de TGI (gauge)
max(tgi_queue_size) by (instance)

# p95 de TTFT de vLLM
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

La guía de histogramas de Prometheus explica que los cuantiles de histograma se calculan en el servidor desde los buckets usando histogram_quantile().

Notas de instrumentación de OpenTelemetry para sistemas de LLM

• OTLP es el Protocolo de OpenTelemetry que especifica cómo se codifica/transmite la telemetría entre fuentes, recolectores y backends.
• La documentación de configuración del SDK de OpenTelemetry menciona variables de entorno como OTEL_EXPORTER_OTLP_ENDPOINT (y opciones de protocolo) para exportar telemetría.
• La documentación de Python contrib de OpenTelemetry menciona el soporte de instrumentación automática y manual para FastAPI.
• Las convenciones semánticas de GenAI incluyen un mecanismo de estabilidad opt-in mediante OTEL_SEMCONV_STABILITY_OPT_IN para la migración de convenciones de GenAI.

Ejemplo corto de Python: métricas + trazas + logs

El fragmento a continuación demuestra:

• Exposición de métricas de Prometheus (/metrics) para “monitoreo de inferencia de LLM con Prometheus”
• Trazas exportadas mediante OTLP (neutral de proveedores)
• Logs estructurados correlacionados con contexto de trazas, con un valor predeterminado seguro para privacidad (no registrar prompts crudos)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (métricas basadas en pull)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (exportador OTLP de trazas)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="API de inferencia de LLM", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Logging (valor predeterminado seguro para privacidad) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Métricas de Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Total de solicitudes de LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Latencia de solicitud de LLM de extremo a extremo (segundos)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Proveedor de trazas de OpenTelemetry ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # configurar mediante variables de entorno OTEL_EXPORTER_OTLP_*
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "no especificado"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Evitar registrar el prompt completo; emitir metadatos seguros
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Reemplazar con llamada real de LLM (cliente Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "¡Hola desde el modelo."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # No incluir prompt/output crudo a menos que la política lo permita.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Despliegue, escalado, seguridad y solución de problemas

Opciones de despliegue

Escalado y retención: restricciones prácticas

• Almacenamiento local de Prometheus: sin banderas explícitas de tamaño/tiempo, el tiempo de retención predeterminado es 15d.
• Escritura remota de Prometheus: Prometheus documenta ajustes de escritura remota para escalar más allá de los “valores predeterminados razonables”.
• Grafana Tempo: posicionado como backend de trazas de alta escala y puede generar métricas desde spans usando el generador de métricas (escrituras remotas a una fuente de datos de Prometheus).
• Almacenamiento de Loki: la documentación de Loki enfatiza el indexado solo por etiquetas y almacenamiento de fragmentos comprimidos (almacenamiento de objetos), haciendo central la estrategia de etiquetas para escala y costo.

Seguridad y privacidad: los prompts pueden contener PII

La guía de seguridad de OpenTelemetry advierte que la recolección de telemetría puede capturar inadvertidamente información sensible/personal; eres responsable de manejarla adecuadamente.

El modelo de seguridad de Prometheus advierte que los endpoints de Prometheus no deben exponerse a redes públicamente accesibles (como internet) porque sirven información sobre sistemas monitoreados.

Controles de privacidad operativos que mantienen “observabilidad para sistemas de LLM” seguros:

• Por defecto, no registrar prompts/responses crudos; registrar en su lugar conteo de tokens, nombre del modelo, latencia y IDs de trazas.
• Redactar/eliminar atributos sensibles en recolectores/pipelines (el filtrado en recolectores es un enfoque común en ecosistemas).
• Imponer RBAC y políticas de retención para logs/trazas; considerar escáneres de datos sensibles donde sea adecuado (ej., proveedores documentan escáneres para telemetría).

Lista de verificación para solución de problemas

Si tu dashboard de Grafana para latencia de LLM parece incorrecto, depura en este orden:

• Salud de ingestión
  • Prometheus: validar éxito de raspado y semántica de configuración (la configuración de Prometheus define trabajos de raspado/instancias).
  • OTLP: confirmar configuración del endpoint del exportador (SDKs usan OTEL_EXPORTER_OTLP_ENDPOINT, ajustes de protocolo).
• Discrepancia de esquema
  • El dashboard espera model, pero tu servidor emite model_name (vLLM documenta explícitamente etiquetas model_name).
• Explosión de cardinalidad
  • Alguien etiquetó por IDs de solicitud/hashes de prompt; Prometheus advierte que los conjuntos de etiquetas aumentan costos de RAM/CPU/disco/red y proporciona orientación sobre cardinalidad.
• Uso incorrecto de histogramas
  • Asegúrate de calcular cuantiles desde series _bucket con rate() y le; Prometheus explica las concesiones en cálculo de cuantiles de histograma.
• Barreras de muestreo de trazas
  • Si muestreas demasiado agresivamente en la cabeza, trazas lentas/error desaparecen; el muestreo de cola retiene “trazas importantes” basadas en criterios completos de traza.
• Problemas de métricas de span en Tempo
  • Si usas generador de métricas y métricas de span en Tempo, confirma que estén habilitadas y ajustadas (Tempo documenta generador de métricas y procesadores de métricas de span; existe solución de problemas para problemas del generador).
• Métricas de GPU ausentes
  • Confirma que el exportador DCGM esté desplegado y que /metrics sea alcanzable (el exportador DCGM expone métricas de GPU sobre HTTP para Prometheus).

Enlaces útiles

• Observabilidad: Guía de monitoreo, métricas, Prometheus y Grafana
• Monitoreo con Prometheus: Configuración y mejores prácticas
• Rendimiento de LLM: Benchmarks, cuellos de botella y optimización
• Anfitrion de LLM: Comparación de local, autoanfitrionado e infraestructura en la nube
• Tutoriales paso a paso de RAG
• Documentación de configuración de Prometheus
• Formatos de exposición de Prometheus
• Mejores prácticas de instrumentación de Prometheus
• Nombres de métricas de Prometheus
• Histogramas y resúmenes de Prometheus
• Reglas de alerta de Prometheus
• Visión general de alertas de Prometheus
• Configuración de Alertmanager
• Modelo JSON de dashboards de Grafana
• Provisionamiento de Grafana
• Métricas del servidor de inferencia NVIDIA Triton
• API de métricas de TorchServe
• Exportador DCGM de NVIDIA
• Chart de kube-prometheus-stack de Helm
• Getting started con Prometheus Operator
• Especificación del exportador de Prometheus de OpenTelemetry
• Guía de Prometheus para recibir OTLP
• Rastreo con OpenTelemetry en LangSmith