Skip to content

English · Español

Fase 34 — Observabilidad, coste y capacidad

Requiere: 33 — Serving de inferencia: de FastAPI a continuous batching Enseña: observability · red-metrics · opentelemetry · prometheus · grafana · cost-accounting Salta a cualquier capítulo desde el índice de referencia de fases.

Mapa del capítulo

Pre-escrita según A12. Esta entrada de fase existe antes de que Borja empiece el estudio. Los enunciados de teoría y laboratorio son borradores estables; las soluciones se escriben justo a tiempo en la apertura de la fase.

🇪🇸 Después de servir el modelo en Fase 33, ahora hay que verlo servir. RED (qué hace el servicio), USE (qué hace el hierro), trazas (qué pasó en una petición concreta) y coste (cuánto valió). Una observabilidad sin medir coste es un dashboard bonito; con coste, es ingeniería.

Objetivo

Cablear instrumentación alrededor del servidor de inferencia de la Fase 33 de manera que, tras 5 minutos de carga sintética, un único dashboard de Grafana responda a cuatro preguntas:

  1. Rate / errors / latency (tasa, errores y latencia) del servicio.
  2. Saturación de recursos (CPU, RAM, profundidad de cola, slots del KV cache).
  3. La traza (trace) de una petición — cada span desde HTTP-in hasta HTTP-out.
  4. Coste de esa petición, desglosado en prefill, decode y retrieval.

La fase introduce src/observability/ como el hogar canónico para métricas, trazas, logs estructurados y el rastreador de coste.

Orden de lectura

  1. theory/00-motivation.md — por qué "hacer que funcione" y "hacerlo observable" son problemas distintos.
  2. theory/01-red-use-metrics.md — las dos filosofías de métricas, qué miden, qué se les escapa y cómo se combinan para el servicio de LLM.
  3. theory/02-cost-accounting.md — la fórmula del coste, por qué el coste p95 importa más que la media, la trampa de la cardinalidad de etiquetas.
  4. theory/03-tracing-and-logging.md — spans de OpenTelemetry, propagación de contexto, la tríada trace_id/span_id/request_id en structlog.
  5. lab/00-prom-grafana-up.md — levantar Prometheus + Grafana localmente vía docker-compose. Bootstrap de un solo disparo.
  6. lab/01-instrument-server.md — añadir las seis métricas centrales al servidor de la Fase 33.
  7. lab/02-tracing-end-to-end.md — cablear OTel a través del camino de la petición; visualizar una traza en Tempo.
  8. lab/03-cost-and-loadtest.md — implementar el rastreador de coste; ejecutar un test de carga; poblar el dashboard; commitear la captura.

solutions/ está vacío durante la pre-escritura — se puebla en la apertura de fase, después de que el servidor Fase 33 de Borja esté en su sitio.

Definition of Done

Ver PHASE_34_PLAN.md §6. Brevemente:

  • Módulo src/observability/ cableado al servidor de la Fase 33.
  • JSON del dashboard committeado en infra/grafana/dashboards/llm.json.
  • Captura de un test de carga de 5 minutos a ≥100 RPS en experiments/34-load-test/.
  • Coste por cada 1k tokens de salida reportado como un número único con p95 (p. ej., "media €0.0083, p95 €0.041").
  • /quiz 34 ≥ 70%.

Lo que esta fase intencionadamente NO cubre

  • Observabilidad distribuida entre múltiples nodos. Territorio de la Fase 35 (ahí es donde aparecen múltiples nodos).
  • Métricas específicas de GPU (USE estilo nvidia-smi). También Fase 35.
  • Almacenamiento a largo plazo de métricas (Mimir, Thanos). YAGNI para un proyecto de aprendizaje; un Prometheus en memoria está bien.
  • Profiling a nivel de código estilo APM (py-spy, pyroscope). Tocado ya en la Fase 33; no se reintroduce aquí.
  • Alertado + paging (Alertmanager, PagerDuty). Territorio de la Fase 38.
  • Seguimiento de métricas de calidad del modelo a lo largo del tiempo (drift, regresión). Fase 38 + Fase 40.

El alcance de la Fase 34 es la observabilidad operativa de una pila de servicio LLM de un solo nodo. Nada más.

Lecturas recomendadas

Opcional — enriquece pero no es necesario para aprobar la fase.