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

Los sistemas de LLM fallan de maneras que la monitorización de APIs tradicional no puede detectar: las colas se llenan en silencio, la memoria de la GPU se satura mucho antes de que la CPU parezca estar ocupada, y la latencia se dispara en la capa de agrupamiento (batching) en lugar de en la capa de aplicación.

Esta guía cubre una estrategia de observabilidad para la inferencia de LLM y aplicaciones de LLM: qué medir, cómo instrumentarlo con Prometheus, OpenTelemetry y Grafana, y cómo desplegar la canalización de telemetría a gran escala.

Las pilas completas de asistentes añaden recuperación, llamadas a herramientas y enrutamiento sobre la inferencia cruda; la Arquitectura de Asistentes de IA mapea dónde encaja la observabilidad entre esas capas.

TL;DR (Resumen ejecutivo)

Los sistemas de LLM se degradan de maneras que la monitorización clásica de “latencia HTTP + tasa de error” no puede explicar. La Observabilidad para sistemas de LLM de grado de producción debe responder, rápida y defendiblemente:

• Si la experiencia del usuario se está degradando (latencia de cola, tiempo hasta el primer token, latencia inter-token, errores y abortos).
• Dónde se pasa el tiempo (encolamiento vs agrupamiento 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 caché KV/cola, tokenización de CPU).
• Cómo derivan el costo y la capacidad (tokens por solicitud, tokens/seg por GPU, tasa de aciertos en caché, generaciones desperdiciadas).
• Si la telemetría es segura para almacenar (los prompts pueden contener PII; prevenir fugas de información sensible en registros/atributos).

El diseño más resiliente es una canalización de múltiples señales:

• Métricas para detección rápida y planificación de capacidad (Prometheus + PromQL; almacenamiento a largo plazo opcional vía Thanos/Cortex/Mimir/VictoriaMetrics).
• Traces para causalidad a nivel de solicitud (OpenTelemetry con OTLP; backends como Tempo/Jaeger/Zipkin/Elastic APM).
• Registros para contexto, correlacionados con traces (Loki/Elastic/OpenSearch), diseñados para metadatos de baja cardinalidad.
• Perfilado para cuellos de botella de CPU/memoria y latencia de cola (Grafana Pyroscope).
• Pruebas sintéticas y de carga para detectar regresiones antes que los usuarios (Grafana k6; sondeo estilo caja negra).
• SLOs para medir resultados de usuario y impulsar alertas accionables (presupuestos de error; estilo tasa de quema).

Qué hace diferente la observabilidad para sistemas de LLM

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

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

• Trabajo variable por solicitud: las cuentas de tokens (entrada/salida) varían ampliamente, por lo que las “solicitudes por segundo” pueden parecer estables mientras el rendimiento de tokens colapsa. TGI y vLLM exportan explícitamente telemetría relacionada con tokens y latencia de tokens para soportar este estilo de monitorización.
• Encolamiento + agrupamiento continuo: el rendimiento depende de las disciplinas de agrupamiento/cola; el tamaño de la cola y el tamaño del lote se convierten en indicadores de primera clase (TGI expone ambos).
• UX de streaming: a los usuarios les importa la TTFT (tiempo hasta el primer token) y la latencia inter-token tanto como el tiempo total de respuesta; OpenTelemetry incluso estandariza las métricas de servidor TTFT/tiempo por token bajo las convenciones semánticas de GenAI.
• La presión de la GPU domina los modos de fallo: la utilización de la GPU y la memoria de la GPU (incluida la memoria utilizada) son centrales para la fiabilidad; el exportador DCGM de NVIDIA existe específicamente para exponer telemetría de GPU en un endpoint /metrics de Prometheus.
• Canalizaciones de múltiples pasos: la recuperación, llamadas a herramientas, filtros de seguridad y post-procesamiento significan que la latencia de extremo a extremo es una composición de múltiples spans/colas, lo que hace esencial el seguimiento distribuido y un diseño cuidadoso de métricas.

Ejemplos concretos de servidores de inferencia populares resaltan esto:

• NVIDIA Triton Inference Server expone métricas como texto plano vía /metrics (comúnmente :8002/metrics) y proporciona banderas para habilitar/deshabilitar métricas y seleccionar un puerto de métricas.
• vLLM expone un extenso endpoint de métricas de Prometheus /metrics con un prefijo vllm:; su documentación incluye contadores para tokens de generación e histogramas como tiempo hasta el primer token.
• Hugging Face TGI 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 centrales de observabilidad y telemetría de LLM requerida

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

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

Traces: Los traces son cómo atribuyes latencia y fallos a través de las etapas de recuperación/herramientas/seguridad/inferencia; OpenTelemetry enmarca los traces/exportadores como una forma neutral del proveedor para emitir y enviar telemetría a recolectores o backends.

Registros: Los registros proporcionan contexto legible por humanos y el “por qué”, pero solo permanecen usables a gran escala si evitas indexar valores ilimitados (ejemplo: Loki indexa solo etiquetas y almacena fragmentos de registros comprimidos en almacenamiento de objetos).

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

Pruebas sintéticas y de carga: Grafana k6 es una herramienta de pruebas de carga de código abierto, y Grafana señala que la Monitorización Sintética está impulsada por k6 y se extiende más allá de simples comprobaciones 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 (compensaciones precisión/recuerdo/tiempo de detección).

Plan de métricas clave de LLM

Convenciones semánticas de OpenTelemetry GenAI para estandarización

OpenTelemetry proporciona convenciones semánticas GenAI (estado: “Desarrollo”) con nomenclatura estándar para métricas 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 una palanca práctica para estrategias portátiles de “monitorización de modelos de LLM con OpenTelemetry”: emitir una vez y enrutar la misma telemetría a backends OSS o de proveedores más tarde.

Diseñando la canalización de telemetría

Pull vs Push

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

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

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

• Usar pull para servidores de inferencia/exportadores (endpoints de métricas Triton/vLLM/TGI; exportador DCGM; métricas de nodo).
• Usar push OTLP para traces/registros/métricas OTel (el Protocolo OpenTelemetry define transporte/codificación/entrega entre fuentes, recolectores y backends).
• Usar remote write (escritura remota) al escalar más allá de un solo Prometheus (Prometheus proporciona orientación de ajuste de escritura remota; Mimir/Thanos/Cortex proporcionan opciones de almacenamiento a largo plazo y/o HA).

Agentes vs sidecars vs recolectores de gateway

OpenTelemetry documenta un patrón de despliegue de agente, donde la telemetría se envía a un Recolector ejecutándose junto a la aplicación o en el mismo host (sidecar/DaemonSet), y luego se exporta.

Para Kubernetes, la inyección de sidecar es soportada vía el Operador de OpenTelemetry (inyección basada en anotaciones).

Regla práctica para pilas de LLM:

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

Muestreo y control de cardinalidad

OpenTelemetry aclara que el muestreo de cola (tail sampling) permite decisiones de muestreo usando criterios derivados de un trace (no posible solo con muestreo de cabeza).

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

“Trampas de cardinalidad” específicas de LLM para prohibir temprano:

• Texto de prompt, texto de respuesta, IDs de conversación, IDs de solicitud como etiquetas/atributos.
• Blobs de argumentos de herramientas como atributos de span.
• Etiquetas “user_id” ilimitadas.

Prefiere dimensiones limitadas: model, model_family, endpoint, region, status_code, deployment, tenant (solo si está limitado).

Comparación de herramientas de observabilidad de LLM

Herramientas mapeadas a tareas de observabilidad

Grafana vs alternativas para visualización

• Los paneles de Grafana están compuestos de paneles que consultan fuentes de datos (incluyendo Loki y Mimir) para producir gráficos y visualizaciones.
• Kibana proporciona paneles/visualizaciones como la capa de UI dentro del Elastic Stack.
• 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 Influx.

Prometheus vs alternativas para backends de métricas

• Almacenamiento local de Prometheus: si no se establecen banderas de retención, la retención predeterminada es de 15d (planifica retención/costo temprano).
• Grafana Mimir se describe como almacenamiento a largo plazo horizontalmente escalable, HA, multi-tenant para métricas de Prometheus y OpenTelemetry.
• Thanos se describe como una configuración de Prometheus de alta disponibilidad con capacidades de almacenamiento a largo plazo.
• Cortex se describe a sí mismo como una solución de almacenamiento a largo plazo horizontalmente escalable, HA, multi-tenant para métricas de Prometheus y OpenTelemetry.
• VictoriaMetrics Cloud documenta la integración de escritura remota de Prometheus para almacenamiento a largo plazo.
• Amazon Managed Service for Prometheus describe una oferta gestionada que escala con las necesidades de ingestión/consulta y soporta PromQL y escritura remota.

Recetario de implementación práctica

Nombres y tipos de métricas para implementar hoy

Las convenciones semánticas GenAI de OpenTelemetry (estado: Desarrollo) definen nombres de métricas en los 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 del lado del servidor que puedes raspar ya:

• El endpoint de Prometheus de vLLM incluye contadores (ej., total de tokens de generación) e histogramas (TTFT) y documenta una estrategia de etiquetas 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 /metrics y alternadores de métricas.

Ejemplos de PromQL para paneles de latencia y rendimiento de LLM

# Latencia de extremo a extremo p95 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/seg (salida) a través de todos los modelos
sum(rate(llm_tokens_total{direction="out"}[5m]))

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

# TTFT p95 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 OpenTelemetry que especifica cómo la telemetría es codificada/transmitida entre fuentes, recolectores y backends.
• La documentación de configuración del SDK de OpenTelemetry documenta variables de entorno como OTEL_EXPORTER_OTLP_ENDPOINT (y opciones de protocolo) para exportar telemetría.
• OpenTelemetry Python contrib documenta soporte de instrumentación de FastAPI para instrumentación automática y manual.
• Las convenciones semánticas GenAI incluyen un mecanismo de estabilidad opt-in vía OTEL_SEMCONV_STABILITY_OPT_IN para la migración de convenciones GenAI.

Ejemplo corto en Python: métricas + traces + registros

El fragmento a continuación demuestra:

• Exposición de métricas de Prometheus (/metrics) para “monitorización de inferencia de LLM con Prometheus”
• Traces de OpenTelemetry exportados vía OTLP (neutral al proveedor)
• Registros estructurados correlacionados con el contexto del trace, con un predeterminado seguro para la 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 (traces OTLP)
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 LLM", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Registro (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 LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Latencia de extremo a extremo de solicitud LLM (segundos)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Proveedor de tracer de OpenTelemetry ---
resource = Resource.create({"service.name": "api-inferencia-llm"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # configurar vía vars 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 a 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/salida cruda 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 de tamaño/tiempo explícitas, el tiempo de retención predeterminado es de 15d.
• Escritura remota de Prometheus: Prometheus documenta el ajuste de escritura remota para escalar más allá de los “valores predeterminados sensatos”.
• Grafana Tempo: posicionado como un backend de tracing de alta escala y puede generar métricas de spans usando el metrics-generator (escrituras remotas a una fuente de datos de Prometheus).
• Almacenamiento de Loki: los docs de Loki enfatizan la indexación solo por etiquetas y el almacenamiento de fragmentos comprimidos (almacenamiento de objetos), haciendo que la estrategia de etiquetas sea central para la escala y el costo.

Seguridad y privacidad: los prompts pueden contener PII

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

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

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

• Por defecto, no registrar prompts/respuestas crudas; registrar conteos de tokens, nombre del modelo, latencia e IDs de trace en su lugar.
• Redactar/descartar atributos sensibles en recolectores/canalizaciones (el filtrado a nivel de Recolector es un enfoque común en los ecosistemas).
• Hacer cumplir RBAC y políticas de retención para registros/traces; considerar escáneres de datos sensibles donde sea apropiado (ej., los proveedores documentan escáneres para telemetría).

Lista de verificación para solución de problemas

Si tu panel de Grafana para latencia de LLM se ve 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/instancias de raspado).
  • OTLP: confirmar configuración de endpoint del exportador (los SDKs usan OTEL_EXPORTER_OTLP_ENDPOINT, configuraciones de protocolo).
• Incompatibilidad de esquema
  • El panel 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 los costos de RAM/CPU/disco/red y proporciona orientación de cardinalidad.
• Uso incorrecto de histogramas
  • Asegúrate de calcular cuantiles desde series _bucket con rate() y le; Prometheus explica las compensaciones del cálculo de cuantiles de histograma.
• Brechas en el muestreo de traces
  • Si muestras agresivamente por cabeza (head-sample), los traces lentos/de error raros desaparecen; el muestreo de cola conserva traces “importantes” basándose en criterios de trace completos.
• Problemas de métricas de spans de Tempo
  • Si usas metrics-generator de Tempo y span-metrics, confirma que está habilitado y ajustado (Tempo documenta procesadores metrics-generator y span-metrics; existe solución de problemas para problemas del generador).
• Métricas de GPU ausentes
  • Confirmar que el exportador DCGM está desplegado y /metrics es accesible (el exportador DCGM expone métricas de GPU vía HTTP para Prometheus).

Enlaces útiles

• Agentes de Sondeo en Asistentes de IA: 11 Patrones de Implementación — la sección de lista de verificación de observabilidad cubre exactamente qué métricas de agentes de fondo, campos de registro y vistas administrativas instrumentar para sistemas de sondeo de producción
• Observabilidad: Guía de Monitorización, Métricas, Prometheus y Grafana
• A2A vs MCP: ¿Realmente Necesitan Ambos Protocolos los Agentes de IA? — las secciones de observabilidad y seguridad allí cubren qué rastrear en sistemas multi-agente que combinan ambos protocolos
• Patrones de Orquestación Multi-Agente — la sección de observabilidad cubre requisitos de seguimiento distribuido específicos para cada patrón: reproducción de pizarra para enjambre, atribución de costo por agente y monitorización de convergencia para malla
• Protocolo A2A de Google en 2026: Adopción, Hype y Realidad — las secciones de seguridad y errores comunes cubren exactamente qué observabilidad necesitas al desplegar agentes a través de fronteras A2A
• ¿Qué es el Protocolo A2A? Tarjetas de Agente y Tareas Explicadas — la sección de observabilidad explica qué necesita capturar un trace de tarea cruz-agente: cambios de estado de tarea, cadenas de delegación, artefactos y mensajes entre agentes
• Monitorización con Prometheus: Configuración y Mejores Prácticas
• Rendimiento de LLM: Benchmarks, Cuellos de Botella y Optimización
• Alojamiento de LLM: Local, Autoalojado e Infraestructura en la Nube Comparados
• Tutorial Paso a Paso de RAG
• Docs de configuración de Prometheus
• Formatos de exposición de Prometheus
• Mejores prácticas de instrumentación de Prometheus
• Nomenclatura 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 paneles de Grafana
• Provisionamiento de Grafana
• Métricas de NVIDIA Triton Inference Server
• API de métricas de TorchServe
• Exportador NVIDIA DCGM
• Gráfico Helm kube-prometheus-stack
• Introducción al Operador de Prometheus
• Especificación del exportador de Prometheus de OpenTelemetry
• Guía de Prometheus para recibir OTLP
• Tracing de LangSmith con OpenTelemetry