Operaciones on lo0 — Blog Técnico

Entornos mixtos NVIDIA + Intel para inferencia LLM: del cluster H100 central al NUC en la sucursal

Tue, 02 Jun 2026 04:30:00 +0200

Este post complementa los de Capacity planning para inferencia LLM on-premise (que asumía cluster NVIDIA puro), Siete capas del stack (que tampoco entraba en heterogeneidad de hardware) y El router de inferencia LLM (donde el routing por capability cobra todo su sentido cuando hay hardware mixto). Es la pieza que faltaba para hablar de “soberanía de hardware” sin reducirla a “qué fabricante elegir”.

TL;DR

Un cluster productivo de inferencia LLM en 2026 puede dejar de ser monolítico NVIDIA si acepta heterogeneidad como decisión arquitectónica. La motivación no es teoría sino tres ventajas operativas medibles. (1) Coste: un Intel Xeon 6 con AMX (Advanced Matrix Extensions) entrega 7B INT4 a ~80 tok/s sirviendo embeddings y reranker a una fracción del coste de dedicar una H100 a esa tarea; el capacity planning cierra mejor con Intel CPU manejando lo barato e NVIDIA H100 el LLM grande. (2) Soberanía y diversificación de cadena de suministro: NVIDIA tiene ~94 % del mercado de AI accelerators (noviembre 2025), single-vendor dependency con todos sus riesgos; Intel fabrica en Europa (Leixlip operativa, Magdeburg planeada) frente a NVIDIA design-only con foundry TSMC, lo que para una organización española/europea con exigencia ENS / NIS2 / EU AI Act es un argumento de hedge real. (3) Edge: un Intel NUC con CPU Lunar Lake (NPU 48 TOPS) o Panther Lake (NPU 50 TOPS + Xe3 120 TOPS = 180 TOPS plataforma) corre modelos 7B INT4 a velocidad usable, lo que abre el patrón “sucursal con inferencia local + DC central para casos complejos”. Hardware Intel relevante en junio 2026: Intel Gaudi 3 (128 GB HBM2e, 1835 TFLOPS BF16/FP8, 3.67 TB/s; competidor directo a H100 — Intel reclama +20 % en Llama 2 70B pero Signal65 publicó H200 9× sobre Gaudi 3 en Llama 3.1 405B, hay que citar ambos; Falcon Shores cancelado enero 2025, Jaguar Shores 2026 como apuesta de reinicio, Gaudi 4 confirmado que no existirá); Intel Xeon 6 con AMX (hasta 288 cores E-core en Sierra Forest o 86 P-core en Granite Rapids, 1024 FLOPS BF16/ciclo/core con AMX, Intel reclama 2.7× tok/s vs EPYC 9965 en vLLM CPU backend); Intel Arc Pro B60 (Battlemage, 24 GB GDDR6, 456 GB/s, 197 TOPS INT8, lanzado septiembre 2025 — variante dual-GPU 48 GB y rack “Battlematrix” con 8× = 192 GB VRAM); Intel NUC con NPU (Lunar Lake 48 TOPS, Arrow Lake similar, Panther Lake 50 TOPS CES 2026; realista para 7-13B INT4, no para los 30-70B que Intel afirma en su marketing). Software: OpenVINO 2025.3 con GenAI API y vLLM-OpenVINO; IPEX-LLM con integraciones a llama.cpp, vLLM, HF, LangChain; vLLM CPU backend con AMX; llama.cpp SYCL (mejor que Vulkan en Arc). Cuatro patrones canónicos: embeddings + reranker en Intel al lado del LLM en NVIDIA; guardrails + PII redact en NUC near edge; speculative drafter en NUC cerca del usuario y target en H100; dev workstations NUC. Observabilidad unificada vía DCGM + habana-metric-exporter + intel-gpu-exporter + Intel PCM federados en Prometheus. Pitfalls: tokenizer mismatch entre engines, latencia round-trip edge↔central, FP8 Hopper ≠ INT8 AMX en calidad, sincronización de versiones. Aplicado a un cluster genérico: DC central 4×H100 SXM + sidecar Xeon 6 AMX + 6-12 NUCs Intel en sucursales. Disclaimer crítico: a junio 2026 no hay casos públicos verificables de despliegue mixto NVIDIA + Intel en banca o gobierno europeo; el patrón es arquitectura emergente y recomendable, no práctica establecida con histórico industrial.

Estás aquí: DEPLOY (con heterogeneidad como decisión)

La analogía: la fábrica con varias máquinas distintas

Una fábrica seria tiene varias máquinas con propósitos distintos, no una sola máquina universal. Una prensa hidráulica de 200 toneladas para troquelado pesado; un torno de banco para piezas de revolución; una impresora 3D para prototipos rápidos; un robot de pick-and-place para SMD. Cada máquina hace lo que hace mejor que las demás en su nicho, y el gerente de planta dimensiona el mix según el portfolio real de productos, no según moda. Comprar tres prensas hidráulicas porque “son las más impresionantes” cuando el 60 % del trabajo son piezas de revolución es derrochar capital — el torno es más barato, más rápido para su nicho y libera la prensa para lo que de verdad la necesita.

Un cluster de inferencia LLM con NVIDIA H100 dedicada a hacer embeddings de un corpus RAG está usando una prensa hidráulica para taladrar pernos. La H100 es magnífica para LLM 70B en BF16 con concurrencia 40+; para embeddings de un documento de 800 tokens en bge-m3, lo que necesitas es un Intel Xeon 6 con AMX a una fracción del coste y consumo eléctrico. Un cluster que quiera servir guardrails ligeros (Llama Guard 4 8B) en cada request, con presupuesto de 50 ms, tampoco necesita ese guardrail en una H100 — un Intel NUC con NPU 48 TOPS cubre el caso con margen.

La fábrica heterogénea no es elegancia teórica: es maximizar utilización útil del capital fijo. El cluster heterogéneo de inferencia LLM tampoco lo es.

Tres razones operativas para la heterogeneidad

Razón 1 — coste

Una H100 SXM 80 GB en operación 24/7 consume ~700 W (medición real al wall ~697 W con vLLM Llama 3.1 405B batch=4) y representa entre 25 000 € y 35 000 € de hardware amortizado. Un Intel Xeon 6 con AMX (Granite Rapids 86 cores o Sierra Forest 288 cores E) consume 350-500 W para el socket y cuesta una fracción. La operativa: la H100 está reservada para el LLM grande (Llama 70B BF16 o FP8, donde su HBM3 y FP8 tensor cores valen su peso); el Xeon AMX absorbe embeddings (bge-m3, e5-large), reranker (bge-reranker-v2-m3), modelos pequeños (Llama 3.2 1B / 3B INT4) y batch processing offline. Es la misma lógica del capacity planning llevada un paso más allá: en vez de presupuestar VRAM de KV cache solo en H100, presupuestar cada workload en el silicio donde su arithmetic intensity case mejor.

Razón 2 — soberanía y diversificación de la cadena de suministro

A noviembre 2025, NVIDIA tiene aproximadamente 94 % del mercado de AI accelerators. Esa concentración es riesgo. Para una organización con exigencia ENS / NIS2 / EU AI Act, depender de un único proveedor con foundry concentrada en Taiwán (TSMC) introduce vulnerabilidades de cadena de suministro que regulaciones recientes (NIS2, supply chain provisions) están empezando a exigir documentar y mitigar. Intel diversifica: tiene fabs propias en Europa (Leixlip operativa en Irlanda; Magdeburg planeada en Alemania, con financiación EU Chips Act), lo que para un cliente público español o europeo es argumento contractual real, no marketing.

Disclaimer obligatorio: el roadmap Intel post-Falcon Shores es inestable. Intel canceló Falcon Shores en enero 2025 y relegó Gaudi 4 a “no existirá”; la apuesta de re-arranque es Jaguar Shores en 2026 como plataforma rack-scale, todavía sin specs públicas confirmadas. La diversificación es estratégicamente correcta, pero asumir continuidad de roadmap Intel al nivel del de NVIDIA en 2026 sería ingenuo. La estrategia operativa: Intel para cargas donde el lock-in es menor (CPU para embeddings, NUC para edge ligero — sustituibles por AMD/Apple/SiFive si Intel pivot otra vez), NVIDIA para el LLM grande donde la madurez del software stack todavía no tiene rival.

Razón 3 — edge

El patrón de “todo viaja al DC central” rompe en tres casos: latencia (sucursal a 100+ ms del DC, inaceptable para chat), soberanía de datos (prompts con datos personales / clasificados que no deben salir del perímetro local), y operación offline (sucursal con conectividad intermitente). El Intel NUC con CPU moderna (Lunar Lake / Arrow Lake / Panther Lake) trae NPU 48-50 TOPS + iGPU Xe2/Xe3 100-180 TOPS en un equipo de 0.5-1.5 L de volumen y 30-65 W de consumo. Modelos 7B INT4 corren a velocidad usable; con quantization más agresiva (Q3_K) cabe Llama 13B. Para sucursales con RAG sobre corpus local + LLM 7B + guardrails, el NUC es perfecto.

Hardware Intel relevante (junio 2026)

Pieza	Memoria	Performance clave	Lanzamiento	Estado
Intel Gaudi 3	128 GB HBM2e, 3.67 TB/s	1835 TFLOPS BF16/FP8; 1200 GB/s networking	abr-2024	Activo; sucesor Jaguar Shores 2026 (no Gaudi 4)
Intel Xeon 6 (Granite Rapids)	DDR5 + MRDIMM	86 P-cores, AMX 1024 FLOPS BF16/ciclo/core	2024-2025	Activo
Intel Xeon 6 (Sierra Forest)	DDR5	288 E-cores	2024	Activo
Intel Arc Pro B60 (Battlemage)	24 GB GDDR6, 456 GB/s	197 TOPS INT8; 12.28 TFLOPS FP32	sep-2025	Activo; variante dual 48 GB, rack 8× = 192 GB
Intel Data Center GPU Max	128 GB HBM	sucesor de Ponte Vecchio	descontinuado	Descontinuado ene-2026
Intel NUC (Lunar Lake)	DDR5x	NPU 48 TOPS + Xe2 67 TOPS = 120 TOPS plataforma	2024	Activo
Intel NUC (Arrow Lake)	DDR5	NPU 13 TOPS + Xe iGPU	2024	Activo (menos NPU que Lunar)
Intel NUC (Panther Lake)	DDR5x	NPU 50 TOPS + Xe3 120 TOPS = 180 TOPS plataforma	CES ene-2026	En despliegue

Intel Gaudi 3 — la nota crítica sobre el marketing

Intel publica que Gaudi 3 entrega +20 % throughput vs H100 en Llama 2 70B inferencia y 2× price/performance. La cifra aparece en whitepaper oficial y en presentaciones de lanzamiento. Sin embargo, Signal65 (firma independiente) publicó en 2025 que H200 supera a Gaudi 3 por factor 9× en Llama 3.1 405B. La discrepancia es relevante: ambos números pueden ser ciertos para sus benchmarks específicos (Llama 2 70B FP16 vs Llama 3.1 405B FP8) pero la conclusión operativa cambia radicalmente según con cuál te quedes.

Recomendación de este post: tratar Gaudi 3 como opción válida para Llama-class 70B en BF16/FP8 donde Intel reclama paridad o ventaja, no para modelos de frontera 200B+ donde NVIDIA mantiene márgen claro. Y considerar el riesgo de roadmap: Gaudi 4 no existirá; el sucesor de la línea es Jaguar Shores 2026 con arquitectura rack-scale completamente nueva — discontinuidad, no evolución.

Intel Xeon 6 con AMX — el caballo de batalla CPU

Las Advanced Matrix Extensions (AMX) son la pieza no obvia. Cada core P-core de Granite Rapids ejecuta hasta 1024 FLOPS BF16 por ciclo vía AMX, lo que convierte un Xeon 6 con 64-86 cores en un acelerador de matriz respetable para modelos pequeños/medianos. Cifras reales reportadas: Llama 3.2 INT4 a ~57 tok/s con AMX vs 28 tok/s sin AMX (factor 2× clean). En servir 7B INT4 con vLLM CPU backend + AMX, Intel reclama 2.7× tok/s vs EPYC 9965, cifra con sesgo de Intel pero corroborada cualitativamente por LMSYS en su despliegue DeepSeek R1 671B sobre Xeon 6 + SGLang.

Caso de uso operativo: embeddings y reranker en un sidecar Xeon 6 al lado del cluster H100. Modelos como bge-m3 (embedding multilingüe) o bge-reranker-v2-m3 corren a throughput aceptable en CPU AMX; no merecen H100 dedicada. Liberar la H100 para el LLM 70B aumenta el RPS efectivo del cluster sin comprar más GPUs.

Intel Arc Pro B60 y Battlematrix

Lanzada en septiembre 2025, la Arc Pro B60 (Battlemage) trae 24 GB GDDR6 con 456 GB/s de bandwidth y 197 TOPS INT8 a 200 W. Variante de Maxsun con dual-GPU 48 GB. La configuración rack “Battlematrix” combina 8 unidades = 192 GB VRAM agregada — el punto interesante: a un coste muy inferior a una H100 SXM 80 GB, lo que la hace candidata para LLM 30-70B INT4-INT8 servidos vía OpenVINO o llama.cpp SYCL.

Phoronix verificó que en SYCL la Arc Pro B70 alcanza paridad con Radeon PRO W7900 (generación anterior AMD) en DeepSeek R1 Llama 8B pp512. Vulkan backend pierde fuerte (~1/4 del rendimiento de SYCL); para Arc Pro siempre SYCL.

Intel NUC con NPU — el edge node

Los Intel NUC con CPU Lunar Lake (Core Ultra Series 2) traen NPU 4 con 48 TOPS y total plataforma 120 TOPS sumando iGPU Xe2 y CPU AVX. Panther Lake (CES enero 2026) sube a NPU 5 = 50 TOPS + Xe3 120 TOPS = 180 TOPS plataforma.

Intel afirma que Panther Lake “ejecuta modelos 30-70B locales”. Comprobación realista: es marketing. El 30-70B INT4 cabe en RAM (DDR5x 32-64 GB) pero la velocidad sostenida con quant Q4_K_M en un NUC ronda 2-8 tok/s; cómodo para uso ocasional, no para servir tráfico. El sweet spot real del NUC es 7B INT4 a 20-40 tok/s sobre iGPU/NPU, perfecto para sucursal de cliente con consultas casuales.

Software Intel — la pila relevante

OpenVINO 2025.3 (junio 2026) es la pieza central. Soporta deploy con un comando vía OVMS CLI con descarga automática desde HF Hub; integra OpenVINO GenAI con API C++/Python para pipelines generativas; expone API compatible con vLLM v1 (vLLM-OpenVINO). Soporte de modelos GGUF: DeepSeek Distill, Qwen 2/2.5, Llama 3. Optimizaciones: Sage Attention (primer token con prompts largos), KV-cache compression por canal.

Intel Extension for PyTorch (IPEX) — versión XPU 2.8.10+xpu — añade backends Intel a PyTorch. IPEX-LLM es el subproyecto que integra con llama.cpp, Ollama, HuggingFace, LangChain, LlamaIndex, vLLM y DeepSpeed. Mayo 2025: corrió DeepSeek V3/R1 671B y Qwen3MoE 235B en 1-2 Arc A770/B580 con FlashMoE.

vLLM CPU backend — el branch CPU de vLLM con optimizaciones AMX. Para 7B INT4 en Xeon 4ª gen con AMX: 12-50 tok/s; con Xeon Gold 6530 + INT4: ~80 tok/s. Cifras académicas (arXiv 2410.04466).

llama.cpp SYCL — el backend recomendado para Arc; Vulkan funciona pero ronda 1/4 del rendimiento SYCL en Arc B580. SYCL alcanza paridad con AMD generación anterior.

Habana SynapseAI — stack de Gaudi 3. PyTorch bridge habana_frameworks.torch registra device hpu; integración con torch.compile. No es port completo a oneAPI sino integración parcial via oneMKL. Implica que el ecosistema Gaudi mantiene cierta separación del oneAPI general de Intel — relevante de cara al hipotético Jaguar Shores y unificación futura.

Los cuatro patrones canónicos

Patrón 1 — embeddings + reranker en Intel

El más maduro y el más fácil de adoptar. En un sistema RAG típico, cada request del usuario invoca:

Embedding del query (50 ms en H100, 80 ms en Xeon AMX, 30 ms en Arc Pro B60).
Búsqueda vectorial (Qdrant / Milvus / Chroma; latencia ~10-30 ms).
Reranker sobre top-k candidatos (60 ms en H100, 100-150 ms en Xeon AMX).
LLM sobre prompt aumentado (200-500 ms TTFT, 30-50 ms/token).

Los pasos 1 y 3 son memory-bound + relativamente pequeños (modelos 100M-1B): Xeon 6 con AMX (Arc Pro B60 más rápida pero ya GPU dedicada) hace el trabajo a un coste de hardware una fracción del de una H100 dedicada. El paso 4 sigue en NVIDIA porque ahí es donde su arquitectura tensor + HBM3 + FP8 vale lo que cuesta.

Implicación operativa: un Xeon 6 sidecar (~40 cores, ~10-15 k€) sirviendo embeddings + reranker libera el equivalente de 1-2 H100 de carga “barata”, recuperando esa capacidad para el LLM grande. ROI en sizing claro.

Patrón 2 — guardrails + PII redact en NUC near edge

Una sucursal bancaria, un consultorio médico o una oficina jurídica genera prompts con datos personales o clasificados. Mandar esos prompts al DC central (aunque sea on-premise corporativo) puede chocar con políticas de retención local o con compliance específico (GDPR, secreto profesional).

Patrón: el NUC en la sucursal ejecuta dos pasos críticos antes del round-trip:

PII redact con Presidio (CPU-only, rápido) o Llama Guard 4 8B en NPU + iGPU del NUC. Reemplaza nombres, NIFs, números de cuenta por placeholders.
Guardrails ligeros (PromptGuard 2 86M, Llama Guard 4 8B) en NPU + iGPU. Filtra prompt injection, jailbreak, contenido prohibido.

Solo después, el prompt redacted viaja al DC central para que el LLM grande responda. La respuesta se devuelve al NUC, que re-hidrata los placeholders con los valores reales antes de mostrarla al usuario. Los datos sensibles nunca abandonan la sucursal.

Costes: NUC Panther Lake ~1500-2500 €/unidad, escalable a docenas de sucursales sin coste de GPU central adicional. Latencia: 50-150 ms del paso edge antes del round-trip de 200-500 ms del DC.

Patrón 3 — speculative decoding drafter en NUC

Speculative decoding usa un drafter pequeño que propone γ tokens y un target grande que los acepta/rechaza en un único forward pass. Si el drafter está geográficamente cerca del usuario (NUC en sucursal) y el target en el DC central, la latencia percibida del cliente cae aún más.

Setup: drafter Llama 3.2 1B INT4 en NUC + target Llama 3.1 70B FP8 en H100 central. El NUC genera γ=4 tokens en ~50 ms locales; el target los verifica en una pasada (40-80 ms incluyendo round-trip); si tasa de aceptación > 60 %, TTFT efectivo cae ~50 % vs Llama 70B sin speculative.

Restricción importante: drafter y target deben compartir tokenizer. Llama 3.2 1B y Llama 3.1 70B tienen tokenizer compatible. Mezclar Llama drafter con Qwen target rompe el patrón.

Patrón 4 — dev workstations NUC

El dev / CI iterando sobre prompts, evals, retrieval logic, no necesita GPU productiva para validar correctness. Un NUC con Llama 3.2 3B INT4 corre los tests funcionales end-to-end (incluyendo embeddings + retrieval + LLM + guardrails) en una décima parte del coste de iterar sobre una H100. Solo el último smoke test pre-prod usa el cluster productivo.

Patrón maduro en organizaciones con muchos desarrolladores y GPU productiva escasa. La iteración 10× más rápida y barata se traduce en velocidad de feature delivery.

Observabilidad unificada en cluster heterogéneo

El post de observabilidad GPU cubría DCGM Exporter para NVIDIA. En cluster mixto hace falta más:

Pieza hardware	Exporter	Métricas clave
NVIDIA H100/A100	`nvidia/dcgm-exporter`	DCGM_FI_DEV_* + DCGM_FI_PROF_*
Intel Gaudi 3	`HabanaAI/habana-metric-exporter`	habana_hpu_utilization, habana_hbm_used
Intel Arc Pro	`intel/intel-gpu-exporter` (no oficial; existen alternativas)	xe_engine_utilization, xe_memory_used
Intel Xeon CPU + AMX	`prometheus/node-exporter` + Intel PCM	cpu_amx_utilization (vía PCM)
Intel NUC (NPU+iGPU)	`intel/intel-gpu-exporter` + custom NPU exporter	npu_utilization, xe_iGPU

Todos federados en un único Prometheus + Grafana. Las dashboards se organizan por familia de hardware (NVIDIA, Intel server, Intel edge) más una vista agregada “cluster heterogéneo” con SLO por tenant que combina los cuatro.

Cardinalidad: ~1.5-2× la del cluster NVIDIA puro. Manejable con Thanos / Mimir para retención larga.

Routing por capability — del router L7 al heterogéneo

El router de inferencia LLM deja de ser un selector de versiones del mismo modelo para convertirse en un dispatcher por capability:

models:
 - name: "llama-70b-chat"
 endpoint: "vllm-llama70b.inference.svc:8000"
 backend: nvidia-h100
 capabilities: [chat, tool_use, json_mode]
 - name: "embedding-multilingual"
 endpoint: "ipex-bge-m3.inference.svc:8080"
 backend: intel-xeon-amx
 capabilities: [embeddings]
 - name: "reranker-multilingual"
 endpoint: "ipex-bge-reranker.inference.svc:8080"
 backend: intel-xeon-amx
 capabilities: [reranking]
 - name: "guardrail-prompt-injection"
 endpoint: "openvino-llama-guard.edge-suc01.local:8080"
 backend: intel-nuc-edge
 capabilities: [guardrails, redact-pii]
 region: sucursal-01
 - name: "llama-3b-draft"
 endpoint: "openvino-llama-3b.edge-suc01.local:8080"
 backend: intel-nuc-edge
 capabilities: [speculative-drafter]
 region: sucursal-01
 target_model: "llama-70b-chat"

El router resuelve model=embedding-multilingual → Intel Xeon; model=llama-70b-chat → H100; model=guardrail-prompt-injection con region=sucursal-01 → NUC local. Si el NUC de la sucursal cae, failover a una réplica equivalente en el DC central, asumiendo el coste de latencia.

LiteLLM Proxy, NVIDIA Dynamo y Envoy AI Gateway soportan este routing por capability. La pieza no obvia: el router debe conocer el tokenizer compatible entre drafter y target para el patrón 3, lo que se modela en metadata adicional del catálogo.

Pitfalls específicos

Tokenizer mismatch entre engines. OpenVINO con un GGUF de Llama 3.2 y vLLM con el mismo Llama 3.2 nominal pueden usar tokenizers ligeramente distintos (chat template, special tokens). Validar identidad de tokens con tokenizer.encode("hola") en ambos lados antes de asumir intercambiabilidad. Para speculative decoding, un solo token diferente rompe el patrón.

Latencia round-trip edge ↔ central. El patrón 2 y 3 asumen que el NUC y el DC están en la misma WAN corporativa con latencia controlada. Si la sucursal está sobre 4G/5G con jitter de 100-200 ms, el speculative drafter no compensa nada — al revés, añade latencia. Medir antes de prometer.

FP8 Hopper ≠ INT8 AMX en calidad de salida. El operador asume que una request que en H100 corre FP8 y en Xeon AMX corre INT8 producirá la misma salida. No es cierto: las dos quantizaciones tienen perfiles de degradación distintos. Si el sistema espera idempotencia (e.g., evals con golden output), validar offline que la versión Intel reproduce el comportamiento esperado dentro de tolerancia.

Sincronización de versiones de modelo entre sitios. El modelo en el DC central se actualiza, pero los NUCs de las sucursales mantienen la versión vieja del drafter o del guardrail durante semanas. Resultado: comportamiento divergente entre sucursales sin diagnóstico fácil. Política: modelo central y modelo edge avanzan juntos o con ventana documentada; el canary se extiende a la flota de NUCs.

Roadmap Intel inestable. Falcon Shores cancelado, Gaudi 4 no existirá, Jaguar Shores 2026 todavía sin specs públicas confirmadas. Comprar Gaudi 3 hoy es razonable si el caso de uso justifica los 18-24 meses de amortización; comprometer arquitectura a 5+ años sobre Intel accelerator es apuesta más arriesgada que la equivalente NVIDIA — al menos hasta que Jaguar Shores se materialice con software stack maduro.

Vacío de despliegues productivos públicos. A junio 2026, los despliegues Gaudi 3 confirmados son IBM Cloud, Dell AI Factory y un puñado de early adopters (Bharti Airtel, Bosch, Naver). No hay caso público verificable de cluster mixto NVIDIA + Intel en banca o gobierno europeo. Este patrón es arquitectura emergente recomendada, no práctica con histórico industrial. El primer adoptante asume coste de validación que un segundo adoptante evita.

Aplicado a un cluster on-premise genérico

Para una organización con un cluster genérico de inferencia LLM heterogéneo:

DC central: 4 nodos × 4×H100 SXM 80 GB con NVLink intra-nodo = 16 H100. Sirve LLM grandes (Llama 70B, Mixtral 8×22B, Qwen 72B) en BF16 o FP8.
Sidecar Xeon 6: 2-4 servidores Xeon 6 (Granite Rapids 64-86 cores) con AMX, 512 GB DDR5, en el mismo rack que el cluster H100. Sirve embeddings (bge-m3), reranker (bge-reranker-v2-m3), modelos pequeños (Llama 3.2 1B/3B) en vLLM CPU backend con AMX.
Sidecar Arc Pro (opcional): 1-2 servidores con 4-8× Arc Pro B60 24 GB cada uno (Battlematrix), para modelos 13-30B INT8 vía OpenVINO. Útil si el coste por LLM mediano debe bajar de la H100.
NUCs edge en sucursales: 1-2 NUCs Panther Lake por sucursal, con NPU 50 TOPS + Xe3 120 TOPS, sirviendo Llama Guard 4 + Presidio + drafter Llama 3.2 1B INT4 vía OpenVINO. Conectividad WAN corporativa con latencia < 80 ms hacia el DC.

Volumen estimado: cluster central ~120 kW de pico GPU + ~10-15 kW de sidecars Intel. Edge: ~50 W por NUC, despreciable comparado con coste de oficinas.

Observabilidad: Prometheus federado en el DC + scrape pull desde los NUCs (vía VPN corporativa). Dashboards “GPU NVIDIA fleet”, “Intel server fleet”, “Intel edge fleet” más una vista “SLO consolidado”.

Router: LiteLLM Proxy o NVIDIA Dynamo en el DC, con catálogo de modelos extendido para incluir backends Intel y regiones (sucursal-01, sucursal-02, …). Failover edge→central documentado.

Lo que no hemos cubierto (próximos posts)

Benchmarks reproducibles de Llama 70B en Gaudi 3 vs H100 SXM en hardware equivalente — el material que falta para tomar decisiones con datos propios, no de Intel ni de Signal65.
AMD ROCm en el mix: cómo entran MI300X / MI355X en este patrón heterogéneo y qué cambia el catálogo del router.
Apple Silicon como edge: M3/M4 Max con Neural Engine ~38 TOPS + GPU 40-core, hardware equivalente al NUC Panther Lake pero con software stack distinto (MLX).
Optimización de coste energético: cómo nvidia-smi -pl 500W + Intel TDP cap en Xeon 6 reduce factura un 25-30 % con 15-20 % de pérdida de throughput.
CI/CD de modelos para flota edge: cómo el rolling update de un Llama Guard llega a 50 NUCs de sucursales sin que ninguna pierda servicio.

Ver también

Capacity planning para inferencia LLM on-premise — el sizing que esta heterogeneidad permite optimizar tarea por tarea, no para todo en H100.
Siete capas del stack de inferencia LLM on-premise — las siete capas aplican igual sobre hardware heterogéneo; los backends son intercambiables si el contrato OpenAI-compatible se respeta.
El router de inferencia LLM — el router por capability es la pieza central del patrón heterogéneo.
Observabilidad GPU para inferencia LLM — extiende a Gaudi, Arc, Xeon AMX y NPU edge.
Quantization para inferencia LLM — FP8 Hopper, INT8 AMX, INT4 GGUF — la base de por qué los hardware mixtos exigen validación cruzada.
Speculative decoding — el patrón 3 del post; cómo el drafter near edge cierra latencia.
Guardrails y safety en LLMs y LLM Guard — los modelos que viven en el NUC del patrón 2.
Catálogo OSS para LLMOps — fichas de OpenVINO, IPEX-LLM, vLLM CPU backend.
OSS vs hyperscalers — el análisis paralelo de lock-in que sostiene el argumento de diversificación.

Referencias

Intel Gaudi 3

Intel — Gaudi 3 AI Accelerator White Paper. https://cdrdv2-public.intel.com/817486/gaudi-3-ai-accelerator-white-paper.pdf
Intel — Hot Chips 2024 Gaudi 3 deep dive. https://hc2024.hotchips.org/assets/program/conference/day1/60_HC2024.Intel.RomanKaplan.Gaudi3-0826.pdf
Signal65 / DataCenterDynamics — NVIDIA H200 outperforms Intel Gaudi 3 by factor of 9× across first Llama 3.1 405B benchmark test. https://www.datacenterdynamics.com/en/news/nvidia-h200-outperforms-intel-gaudi-3-by-factor-of-nine-across-first-llama-31-405b-benchmark-test-exclusive/
IEEE Spectrum — Intel Gaudi 3 review. https://spectrum.ieee.org/intel-gaudi-3
Tom’s Hardware — Intel cancels Falcon Shores GPU; Jaguar Shores to be successor. https://www.tomshardware.com/tech-industry/artificial-intelligence/intel-cancels-falcon-shores-gpu-for-ai-workloads-jaguar-shores-to-be-successor

Intel Xeon 6 + AMX

Intel — Xeon 6 (Granite Rapids) Product Brief. https://www.intel.com/content/dam/www/central-libraries/us/en/documents/2025-02/xeon-6-granite-rapids-product-brief.pdf
OpenMetal — Intel AMX AI Inference Performance. https://openmetal.io/resources/blog/intel-amx-ai-inference-performance/
LMSYS — Intel Xeon 6 + SGLang for DeepSeek R1 671B. https://www.lmsys.org/blog/2025-07-14-intel-xeon-optimization/
arXiv 2410.04466 — CPU-LLM benchmarks with AMX.
Intel community blog — Accelerating vLLM Inference on Intel Xeon 6 Processor.

Intel Arc Pro Battlemage

Intel — Arc Pro B60 Graphics Specifications. https://www.intel.com/content/www/us/en/products/sku/243916/intel-arc-pro-b60-graphics/specifications.html
StorageReview — Intel Arc Pro B60 Battlematrix Preview: 192GB VRAM for On-Premise AI. https://www.storagereview.com/review/intel-arc-pro-b60-battlematrix-preview-192gb-of-vram-for-on-premise-ai
Phoronix — Intel Arc Pro B-series review. https://www.phoronix.com/review/intel-arc-pro-b-series

Intel NUC / NPU

HotHardware — Intel CES 2026 Panther Lake is a Go. https://hothardware.com/news/intel-ces-2026-panther-lake-is-a-go
TechPowerUp — Intel Panther Lake Technical Deep Dive.
arXiv 2412.11053 — NITRO: LLM inference on laptop NPU.
Intel — AI PC brings larger LLM development to your desk.

Software

OpenVINO — Release Notes 2025.3. https://www.intel.com/content/www/us/en/developer/articles/release-notes/openvino/2025-3.html
HuggingFace — Deploy with OpenVINO. https://huggingface.co/blog/deploy-with-openvino
Intel — Intel Extension for PyTorch XPU 2.8.10. https://intel.github.io/intel-extension-for-pytorch/xpu/latest/tutorials/releases.html
IPEX-LLM — github.com/intel/ipex-llm.
Habana — SynapseAI PyTorch Theory of Operations. https://docs.habana.ai/en/latest/PyTorch/PyTorch_Gaudi_Theory_of_Operations.html

Market context

MLCommons — MLPerf Inference v6.0 benchmark results. https://www.spheron.network/blog/mlperf-inference-v6-benchmark-results-2026/
Intel newsroom — Gaudi 3 Expanded Availability. https://newsroom.intel.com/artificial-intelligence/intel-gaudi-3-expands-availability-drive-ai-innovation-scale

Sources: las URLs completas están enlazadas en línea sobre cada referencia.

Runbooks de incident response para inferencia LLM: cada alerta a una acción concreta con Kafka y Keep

Tue, 02 Jun 2026 04:30:00 +0200

Este post cierra la trilogía de observabilidad que abrieron Observabilidad GPU para inferencia LLM (qué métricas) y Anatomía de las doce métricas DCGM y cinco vLLM (qué anomalía documentada por métrica). Aquí cada anomalía recibe su acción concreta y se encaja en la maquinaria de gestión de incidentes que compliance exige.

TL;DR

Las alertas de observabilidad GPU son inútiles sin un procedimiento codificado por cada una; el operador que las interpreta a mano cada vez opera por intuición. La combinación correcta tiene tres piezas indispensables. (1) Catálogo de runbooks: para cada una de las seis alertas críticas (GpuHbmNearOom, GpuThermalOrPowerThrottle, GpuXidErrorDetected, GpuEccDoubleBit, VllmKvCachePoolNearFull, VllmTtftP95OutOfSlo), severity, mitigación inmediata, evidencia que capturar antes de remediar, acción de resolución, criterio de cierre y trigger de postmortem. (2) Pipeline reproducible: Prometheus + DCGM → Alertmanager → Kafka como event bus (topics gpu.alerts.enriched, incidents.lifecycle, audit.actions con retención WORM) → Keep como workflow engine (workflows declarativos YAML versionados en git) → ejecutores Kubernetes jobs / scripts / ChatOps. (3) Encaje formal en gestión de incidentes según el corpus normativo: ISO/IEC 27035 fases identify → report → assess → respond → learn; ENS controles op.exp.7 (gestión de incidentes), op.exp.8 (registro de actividad), op.exp.10 (notificación a usuarios); NIS2 art. 23 con notificación temprana 24 h, notificación formal 72 h e informe final 1 mes; EU AI Act art. 73 para incidente grave de un sistema de alto riesgo, plazos 2 a 15 días según severity; ISO/IEC 42001 cláusula 10 (mejora continua del AIMS). La taxonomía de acción es mitigación inmediata (drain, throttle, scale-down: contiene el daño en segundos) → diagnóstico (captura de evidencia con nvidia-smi -q, dmesg, vLLM /metrics snapshot, traza OTel relacionada; sin esto el postmortem no es defensible) → resolución (restart, reset, RMA, rollback) → postmortem (RCA por 5-whys, plan de prevención, actualización del runbook). Kafka aporta el audit trail inmutable que ENS y EU AI Act exigen — cada acción ejecutada por Keep o por humano se publica como evento en audit.actions con timestamp, actor, decisión y evidencia, retenido WORM mínimo 6 meses. Keep aporta los workflows como código: este post incluye tres workflows completos (XID con drain + ticket Jira, ECC DBE con paginación inmediata y bloqueo del nodo en scheduler, canary rollback automático por TTFT P95 fuera de SLO). Cuatro anti-patrones cierran el material: alertas sin runbook (la mayoría), runbook sin captura de evidencia previa (perpetúa el incidente porque la causa raíz se pierde), escalada por antigüedad en vez de severity (operador junior gestiona ECC DBE), ausencia de gate humano para acciones destructivas (Keep ejecutando nvidia-smi --gpu-reset sin confirmación). Aplicable a un cluster genérico de 4×H100 SXM con Kafka y Keep ya desplegados.

Estás aquí: OBSERVE → DEPLOY (incident response cierra el bucle)

La analogía: la sala de control de un reactor nuclear

En una sala de control de central nuclear, el operador de turno nunca decide qué hacer al ver una alarma. La decisión está pre-tomada y codificada en un procedimiento escrito (SOP) que cubre cada alarma del panel: si suena la X, abrir libro X, leer los pasos 1-N, ejecutar exactamente, llamar al supervisor en el paso M, escalar al director de planta en el paso N+3. La razón es estricta: las alarmas críticas son raras pero catastróficas si se gestionan mal; un operador improvisando en una emergencia toma decisiones peores que uno aplicando un procedimiento revisado por expertos y validado por simulación.

El reactor no espera que el operador sea genio. Espera que conozca los procedimientos al pie de la letra y que el sistema de gestión de operaciones le entregue el procedimiento correcto al momento. Si los procedimientos no están escritos, no están versionados, o no están integrados con las alarmas que disparan, la sala de control opera por intuición. La diferencia entre ambas operaciones —procedimentada vs intuitiva— es la diferencia entre una central que opera 30 años sin incidentes y otra que entra en lista negra.

El incident response de un cluster de inferencia LLM funciona idéntico. Las alertas DCGM y vLLM que los posts anteriores listaron son las alarmas del panel. Cada una necesita su SOP escrito, versionado, integrado con la alerta que la dispara y revisado tras cada incidente. Sin esa codificación, el operador de turno improvisa en mitad de un fallo de ECC DBE a las 4 de la mañana; con ella, ejecuta los nueve pasos del runbook 12 y el incidente se cierra en 20 minutos.

La arquitectura del incident pipeline

Prometheus + DCGM. Recolecta las métricas descritas en los dos posts anteriores. PrometheusRules definen las seis alertas críticas con for: <duración> para evitar ruido.

Alertmanager. Recibe alertas crudas; deduplica, agrupa por labels ({cluster, node, gpu, model}), enruta. En vez de enviar directamente a PagerDuty o Slack, envía a Kafka vía webhook receiver — esto convierte la alerta en un evento del bus que múltiples consumidores procesan (Keep para acción, audit topic para compliance, dashboards para visualización).

Kafka como event bus. Tres topics canónicos:

gpu.alerts.enriched — alertas con contexto añadido (tenant, modelo, versión, owner del namespace, severity efectiva). Retención: 7 días, replication factor 3.
incidents.lifecycle — eventos del ciclo del incidente: incident.opened, incident.acknowledged, action.proposed, action.executed, incident.escalated, incident.resolved, postmortem.attached. Retención: 90 días.
audit.actions — registro inmutable de cada acción ejecutada (por Keep automáticamente o por humano confirmando). Retención: 6 meses mínimo con compaction off + tiered storage, almacenamiento WORM. Es el topic que ENS op.exp.8, EU AI Act art. 12 y NIS2 obligan a conservar.

Keep como workflow engine. Consume de gpu.alerts.enriched, dispara workflows YAML versionados en git, ejecuta acciones (llamadas HTTP, kubectl jobs, mensajes Slack, tickets Jira) y publica el resultado en incidents.lifecycle + audit.actions. La elección de Keep sobre Alertmanager solo (o sobre PagerDuty solo) es deliberada: Keep separa declaración del runbook (YAML legible y revisable) de distribución de notificación (PagerDuty). El runbook es código versionado; las notificaciones son detalles operativos.

Ejecutores. Lo que de verdad mueve el cluster:

Kubernetes jobs: kubectl drain, kubectl cordon, kubectl rollout undo.
NVIDIA API: nvidia-smi --gpu-reset, dcgmi diag -r <level>.
ChatOps: confirmaciones humanas a través de Slack interactive messages antes de ejecutar acción destructiva.
Tooling externo: ticket Jira, notificación PagerDuty, llamada a CMDB.

Las seis alertas críticas y sus runbooks

Para cada alerta: severity, mitigación inmediata (segundos), evidencia que capturar antes de remediar, acción de resolución, criterios de cierre, trigger de postmortem.

RB-01 · `GpuHbmNearOom` — HBM > 92 % sostenido

Severity: WARNING. Riesgo OOM en la siguiente asignación de PagedAttention.

Mitigación inmediata. Reducir admission temporalmente bajando max_num_seqs del motor afectado vía hot reload (si el motor lo soporta) o restart escalonado de réplicas. Disparar scale-out adicional vía KEDA si hay nodos GPU libres. No es necesario drenar el nodo.

Evidencia a capturar.

nvidia-smi --query-gpu=index,memory.used,memory.free,memory.total --format=csv
nvidia-smi -q -d ROW_REMAPPER | grep -i pending
curl http://vllm-pod:8000/metrics | grep -E "gpu_cache_usage|num_requests"
kubectl logs <pod> --tail=200 | grep -i "preempt\|swap"

Guardar snapshot en audit.actions con timestamp y incident_id.

Resolución. Si la causa es pico de tráfico: dejar al autoscaler escalar a régimen estable, monitorizar 30 min. Si la causa es regresión de modelo (canary v2 consume más KV cache que v1): rollback del canary (ver RB-06). Si es leak (la métrica crece sin que el tráfico crezca): restart del pod con captura de heap dump.

Cierre. gpu_cache_usage_perc < 80 % sostenido durante 15 min Y num_requests_waiting == 0.

Postmortem. No obligatorio salvo si el incidente duró > 30 min o tuvo impacto en SLO.

RB-02 · `GpuThermalOrPowerThrottle` — bit ≠ 0 ni Idle en CLOCK_THROTTLE_REASONS

Severity: WARNING (térmico) o CRITICAL (HW Power Brake sostenido, riesgo PDU).

Mitigación inmediata. Identificar el bit (decodificar bitmap). Si es 0x40 HW_THERMAL o 0x20 SW_THERMAL: drenar workload del nodo a otras réplicas si la temperatura no baja en 2 min, evitar nuevos pods en ese nodo (kubectl cordon). Si es 0x80 HW_POWER_BRAKE: alerta a infraestructura de DC inmediatamente (probable PDU sobrecomprometida — caso Dell KB 000220508 / Lenovo HT514380), reducir TDP de las GPUs del rack vía nvidia-smi -pl a un valor menor para liberar carga sobre el breaker.

Evidencia.

nvidia-smi --query-gpu=index,temperature.gpu,temperature.memory,power.draw,clocks_throttle_reasons.active --format=csv
ipmitool sdr | grep -i "fan\|temp\|inlet"
# Datos de PDU si están instrumentadas (modbus / SNMP)

Resolución.

Térmico: revisar flujo de aire del rack, verificar rear-door HX, T_inlet, ventiladores DGX. Issue de infra, no de motor.
Power Brake: revisar dimensionado de PDU rama, breaker, distribución 415 VAC. Probable redistribución de carga a otra rama o limitación temporal de TDP.

Cierre. CLOCK_THROTTLE_REASONS == 0x1 (solo Idle) o 0x0 durante 30 min con carga normal.

Postmortem. Obligatorio si fue HW Power Brake — implica infraestructura eléctrica del DC.

RB-03 · `GpuXidErrorDetected` — `increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0`

Severity: CRITICAL.

Mitigación inmediata. kubectl cordon del nodo (sin más nuevos pods). Si el XID es 31/48/79/94/95 (hardware o cascada): drenar los pods existentes del nodo. Si el XID es 13/43 (posible software): mantener pods pero bloquear nuevos, capturar trace y workload activo.

Evidencia.

# El XID concreto del dmesg
dmesg | grep -i xid | tail -30
nvidia-smi -q -d ERROR
nvidia-smi -q -d PCIE
# Estado de las páginas retiradas
nvidia-smi -q -d ROW_REMAPPER
# Workload que estaba ejecutándose
kubectl get pods -o wide | grep <node>
kubectl logs <pod> --previous --tail=500

Resolución.

XID 13/43 (software exception / channel verif): si recurre solo con un modelo concreto, es bug del workload — issue al equipo de modelos. Si es transitorio, reiniciar el pod basta.
XID 31 (MMU fault): suele ser cascada de un XID 48 previo. Reset de la GPU (nvidia-smi --gpu-reset -i <index>) o reboot del nodo si reset no resuelve.
XID 48 / 95 (DBE / uncontained ECC): ver RB-04. El nodo entra en cuarentena.
XID 79 (fallen off the bus): reboot del nodo. Si recurre tras reboot, abrir RMA de la GPU. ByteDance reporta 43 % de coocurrencia con errores PCIe — verificar también el slot y el cable.
XID 94 / 145 / 149: catalogados en el Xid Catalog de NVIDIA con procedimiento específico.

Cierre. Smoke test del nodo pasado (dcgmi diag -r 3), 24 h sin nuevos XIDs, vuelta al pool.

Postmortem. Obligatorio. Incluir XID concreto, distribución de XIDs en el cluster, MTBE actualizado.

RB-04 · `GpuEccDoubleBit` — `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0`

Severity: CRITICAL — corrupción de datos en curso.

Mitigación inmediata. Drenar el nodo inmediatamente sin esperar evidencia adicional. Páginas guardia (PagerDuty / OpsGenie) ON-CALL primario. Marcar el nodo unschedulable y failed. El XID 48 tiene 100 % probabilidad de matar el job en curso según el dataset de Story of Two GPUs; cualquier inferencia ya está comprometida.

Evidencia (en paralelo a la mitigación).

nvidia-smi -q -d ECC
nvidia-smi -q -d ROW_REMAPPER # Pending: Yes esperado
dmesg | grep -E "Xid.*48|DBE|double-bit" | tail -50
# Captura completa del estado de la GPU
dcgmi diag -r 4 -i <gpu_index>

Resolución. Reset completo de la GPU (nvidia-smi --gpu-reset) o reboot del nodo si reset no completa. El reset activa el row remap. Tras el reboot:

nvidia-smi -q -d ROW_REMAPPER # Pending: No esperado
nvidia-smi -q -d ECC # contadores volátiles a 0

Si RETIRED_DBE > 8 páginas tras el remap: planificar reemplazo de GPU en próxima ventana — la degradación del silicio es progresiva. Documentado ~19 horas de downtime típico en el caso real publicado.

Cierre. Nodo en pool tras 48 h sin nuevos DBE.

Postmortem. Obligatorio. Si el incidente afectó a una request con datos personales / clasificados, evaluar notificación a DPO bajo GDPR art. 33 (no es necesariamente brecha, pero hay que evaluarlo).

RB-05 · `VllmKvCachePoolNearFull` — `gpu_cache_usage_perc > 95 %` sostenido 3 min

Severity: WARNING (riesgo de preempt-on-OOM, no de OOM real).

Mitigación inmediata. Activar scale-out del autoscaler bajando el umbral de KEDA temporalmente (de 0.85 a 0.75) durante 30 min. Si está en modo recompute, los preempts elevan TTFT pero no rompen requests; aceptable a corto plazo. Si está en modo swap, latencia se va al techo — preferible cortar tráfico nuevo (devolver 503 desde el router) durante 5 min.

Evidencia.

curl http://vllm-pod:8000/metrics | grep -E "gpu_cache|num_requests|num_preemptions"
kubectl get hpa vllm-llama70b
kubectl logs <pod> --tail=200 | grep -i preempt

Resolución. Si recurre regularmente: capacity planning revisado, posiblemente reducir max_num_seqs o subir réplicas estables. Ver Capacity planning.

Cierre. Pool < 85 % sostenido 30 min, sin preempts en último 15 min.

Postmortem. No obligatorio salvo recurrencia > 3 veces / semana.

RB-06 · `VllmTtftP95OutOfSlo` — TTFT P95 > 1.5 s durante 5 min

Severity: CRITICAL (violación de SLO contractual).

Mitigación inmediata. Diagnóstico rápido del régimen (en orden de probabilidad):

Si hay canary v2 activo y el ratio ttft_p95(v2)/ttft_p95(v1) > 1.30: rollback automático del canary vía Argo Rollouts (argo rollouts abort vllm-llama70b).
Si num_requests_waiting > 5: scale-out vía KEDA.
Si DRAM_ACTIVE > 90 % + gpu_cache_usage_perc > 90 %: cuello en HBM, palanca de quantization o reducción de contexto.
Si CLOCK_THROTTLE_REASONS != 0: ver RB-02.

Evidencia.

# Snapshot del histograma
curl http://vllm-pod:8000/metrics | grep time_to_first_token
# Distribución por versión si hay canary
# Estado DCGM del momento
curl http://dcgm-exporter:9400/metrics | grep -E "PIPE_TENSOR|DRAM_ACTIVE|THROTTLE"
# Tráfico activo
kubectl top pods -n inference

Resolución. Depende del diagnóstico. Casos típicos:

Canary regresión → rollback completo (ver Canary).
Saturación de capacidad → escalar réplicas o aceptar 503 temporal con Retry-After.
Prefill bound → activar/calibrar chunked prefill o disaggregated serving (ver Disaggregated serving).

Cierre. TTFT P95 dentro de SLO sostenido 30 min.

Postmortem. Obligatorio. Documentar causa raíz y palanca aplicada; actualizar runbook.

Workflows Keep YAML — tres ejemplos completos

Los runbooks son útiles solo si están codificados en el workflow engine. Keep permite declararlos en YAML versionados en git.

Workflow 1 — `xid-detected.yaml`

workflow:
 id: xid-detected-drain
 name: "XID error detected — cordon node and capture evidence"
 description: "RB-03 implementation"
 triggers:
 - type: alert
 filters:
 - key: alertname
 value: GpuXidErrorDetected
 steps:
 - name: capture-evidence
 provider:
 type: bash
 with:
 command: |
 set -e
 NODE="{{ alert.labels.node }}"
 GPU="{{ alert.labels.gpu }}"
 INC_ID="{{ alert.fingerprint }}"
 mkdir -p /var/evidence/$INC_ID
 kubectl debug node/$NODE -it --image=nvcr.io/nvidia/cuda:12.4.0-base-ubuntu22.04 -- \
 bash -c "nvidia-smi -q -d ERROR,PCIE,ROW_REMAPPER > /host/var/evidence/$INC_ID/smi.txt"
 kubectl describe node $NODE > /var/evidence/$INC_ID/node.txt
 - name: cordon-node
 provider:
 type: kubernetes
 with:
 action: cordon
 name: "{{ alert.labels.node }}"
 if: "{{ alert.labels.severity == 'critical' }}"
 actions:
 - name: open-jira-ticket
 provider:
 type: jira
 config: "{{ providers.jira-prod }}"
 with:
 project: GPUOPS
 issuetype: Incident
 summary: "RB-03: XID {{ alert.annotations.xid_code }} on {{ alert.labels.node }}/{{ alert.labels.gpu }}"
 description: |
 Severity: {{ alert.labels.severity }}
 XID: {{ alert.annotations.xid_code }}
 Evidence: /var/evidence/{{ alert.fingerprint }}
 Runbook: https://runbooks.example.local/RB-03
 - name: notify-slack
 provider:
 type: slack
 config: "{{ providers.slack-gpu-incidents }}"
 with:
 message: |
 :warning: *RB-03 triggered*
 Node: `{{ alert.labels.node }}` GPU: `{{ alert.labels.gpu }}`
 XID: `{{ alert.annotations.xid_code }}`
 <{{ jira.url }}|Jira ticket>
 - name: emit-audit
 provider:
 type: kafka
 config: "{{ providers.kafka-audit }}"
 with:
 topic: audit.actions
 message:
 incident_id: "{{ alert.fingerprint }}"
 action: "cordon_node"
 actor: "keep-workflow"
 workflow_id: "xid-detected-drain"
 target: "{{ alert.labels.node }}"
 timestamp: "{{ now }}"

Workflow 2 — `ecc-dbe.yaml` — paginación inmediata

workflow:
 id: ecc-dbe-critical
 name: "ECC double-bit — page on-call and quarantine node"
 triggers:
 - type: alert
 filters:
 - key: alertname
 value: GpuEccDoubleBit
 steps:
 - name: cordon-immediately
 provider:
 type: kubernetes
 with:
 action: cordon
 name: "{{ alert.labels.node }}"
 - name: drain-workload
 provider:
 type: kubernetes
 with:
 action: drain
 name: "{{ alert.labels.node }}"
 options:
 ignore-daemonsets: true
 delete-emptydir-data: true
 grace-period: 120
 - name: page-oncall
 provider:
 type: pagerduty
 config: "{{ providers.pagerduty-critical }}"
 with:
 service_key: "{{ env.PD_SERVICE_KEY }}"
 severity: critical
 summary: "RB-04 ECC DBE on {{ alert.labels.node }}/{{ alert.labels.gpu }} — node drained"
 - name: emit-lifecycle
 provider:
 type: kafka
 config: "{{ providers.kafka-incidents }}"
 with:
 topic: incidents.lifecycle
 message:
 incident_id: "{{ alert.fingerprint }}"
 event: incident.opened
 severity: critical
 runbook: RB-04
 requires_postmortem: true
 - name: notify-dpo
 provider:
 type: email
 with:
 to: dpo@example.local
 subject: "ECC DBE en GPU productiva — evaluación necesaria"
 body: |
 Incidente RB-04 ECC DBE detectado en {{ alert.labels.node }}.
 Modelo afectado: {{ alert.labels.model }}.
 Por favor evaluar si hubo procesamiento de datos personales/clasificados
 durante la ventana de error y necesidad de notificación GDPR art. 33.

Workflow 3 — `canary-rollback.yaml` — TTFT P95 fuera de SLO

workflow:
 id: canary-rollback-ttft
 name: "Rollback canary when TTFT P95 ratio v2/v1 > 1.30"
 triggers:
 - type: alert
 filters:
 - key: alertname
 value: VllmTtftP95OutOfSlo
 - key: canary_active
 value: "true"
 steps:
 - name: check-ratio
 provider:
 type: prometheus
 config: "{{ providers.prom-prod }}"
 with:
 query: |
 histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{version="v2"}[5m])))
 /
 histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{version="v1"}[5m])))
 condition: result > 1.30
 actions:
 - name: argo-rollback
 provider:
 type: kubernetes
 with:
 action: exec
 command:
 - kubectl
 - argo
 - rollouts
 - abort
 - "{{ alert.labels.rollout }}"
 - -n
 - "{{ alert.labels.namespace }}"
 - name: notify-and-audit
 provider:
 type: kafka
 config: "{{ providers.kafka-audit }}"
 with:
 topic: audit.actions
 message:
 incident_id: "{{ alert.fingerprint }}"
 action: canary_rollback
 ratio: "{{ steps.check-ratio.result }}"
 actor: keep-workflow
 timestamp: "{{ now }}"

Cada workflow se guarda en repos/keep-workflows/ versionado en git, revisado por pull request, validado por CI (keep workflow validate). El runbook escrito vive como docs/runbooks/RB-XX.md enlazado desde el workflow YAML — los dos siempre evolucionan juntos.

El schema canónico de eventos Kafka

Para que los topics sean consumibles por compliance, postmortem tooling y dashboards sin que cada consumer tenga que adivinar el shape, se fija schema con Avro / Protobuf.

{
 "name": "IncidentLifecycleEvent",
 "type": "record",
 "fields": [
 { "name": "incident_id", "type": "string" },
 { "name": "event", "type": { "type": "enum", "symbols": [
 "incident.opened", "incident.acknowledged", "action.proposed",
 "action.executed", "action.failed", "incident.escalated",
 "incident.resolved", "postmortem.attached"
 ]}},
 { "name": "timestamp", "type": "string", "logicalType": "timestamp-millis" },
 { "name": "actor", "type": "string" },
 { "name": "severity", "type": { "type": "enum", "symbols": ["low","warning","critical"] } },
 { "name": "runbook", "type": ["null","string"], "default": null },
 { "name": "alert_name", "type": "string" },
 { "name": "labels", "type": { "type": "map", "values": "string" } },
 { "name": "annotations", "type": { "type": "map", "values": "string" } },
 { "name": "evidence_uri", "type": ["null","string"], "default": null },
 { "name": "requires_postmortem", "type": "boolean", "default": false }
 ]
}

Para audit.actions (WORM), un schema separado más exigente con campos no-modificables:

{
 "name": "AuditAction",
 "type": "record",
 "fields": [
 { "name": "incident_id", "type": "string" },
 { "name": "action", "type": "string" },
 { "name": "actor", "type": "string" },
 { "name": "actor_type", "type": { "type": "enum", "symbols": ["human","workflow","scheduler"] } },
 { "name": "workflow_id", "type": ["null","string"], "default": null },
 { "name": "target", "type": "string" },
 { "name": "command", "type": ["null","string"], "default": null },
 { "name": "result", "type": { "type": "enum", "symbols": ["success","failure","partial"] } },
 { "name": "timestamp", "type": "string", "logicalType": "timestamp-millis" },
 { "name": "evidence_uri", "type": ["null","string"], "default": null },
 { "name": "approver", "type": ["null","string"], "default": null }
 ]
}

El topic se configura con cleanup.policy=delete, retention.ms=15552000000 (6 meses) y min.insync.replicas=2 con acks=all para garantizar durabilidad. Para retención más larga sin coste de Kafka, tiered storage a Ceph RGW o S3-compatible — el log nuevo en hot tier, el viejo en cold tier transparente al consumer.

Encaje formal en gestión de incidentes

Los runbooks no son una práctica de SRE aislada — encajan en cuatro marcos normativos que las plataformas LLM productivas tocan a diario.

ISO/IEC 27035 — gestión de incidentes de seguridad de la información

Define el ciclo formal en cinco fases: plan & prepare → detect & report → assess & decide → respond → lessons learned. Cada fase tiene salidas exigibles documentalmente. La traducción al stack:

Plan & prepare: los runbooks RB-01 a RB-06 + los workflows Keep son parte del Information Security Incident Management Plan. Versionados en git, revisados anualmente.
Detect & report: las alertas Prometheus que entran a Kafka son la materialización.
Assess & decide: la severity en gpu.alerts.enriched + la lógica del workflow Keep.
Respond: ejecución de los steps + actions del workflow.
Lessons learned: postmortem obligatorio para los runbooks que lo marcan; salida documentada en el repo de postmortems + actualización del runbook.

ENS (Esquema Nacional de Seguridad) — controles op.exp

op.exp.7 Gestión de incidentes: el catálogo de runbooks + el pipeline Keep / Kafka materializan la “respuesta organizada y procedimentada”.
op.exp.8 Registro de actividad: el topic audit.actions con retención WORM 6 meses (mínimo nivel ALTO).
op.exp.9 Registro de la gestión de incidentes: el topic incidents.lifecycle con el ciclo completo de cada incidente.
op.exp.10 Protección de los registros de actividad: WORM + cifrado en reposo + control de acceso (consumers compliance solo-lectura).

NIS2 — notificación a autoridad competente

Para entidades esenciales / importantes, el art. 23 fija tres plazos a partir del significant impact detectado:

24 horas: notificación temprana (“early warning”) al CSIRT nacional (INCIBE-CERT en España).
72 horas: notificación formal con assessment inicial.
1 mes: informe final con causa raíz, impacto, medidas correctivas.

Los datos para esos informes salen directamente de incidents.lifecycle + audit.actions con un consumer que genera el dossier en el formato requerido. Sin el pipeline auditable, los plazos NIS2 son inalcanzables.

EU AI Act — art. 73 (serious incident reporting)

Aplicable a sistemas de alto riesgo. Plazos:

2 días: para incidentes que provoquen fallecimiento o daño irreversible a personas o infraestructuras críticas.
10 días: para incidentes que produzcan disrupción seria de infraestructura crítica.
15 días: para el resto de “serious incidents”.

La definición de “serious incident” incluye fallos sistemáticos del modelo, brecha de fundamental rights, daño material o medioambiental. Los runbooks deben marcar qué alertas pueden derivar en serious incident (típicamente cualquier cosa que afecte la salida del modelo en un contexto de alto riesgo) y disparar un sub-workflow específico de evaluación legal.

ISO/IEC 42001 — AIMS cláusula 10 mejora continua

El postmortem obligatorio post-incidente alimenta la cláusula 10. La actualización del runbook tras cada incidente que descubre un patrón nuevo es la “acción correctiva con verificación de eficacia” que la norma exige. Ver ISO 42001 AIMS.

Cuatro anti-patrones

Anti-patrón 1 — alertas sin runbook. La alerta dispara, el operador junior de guardia mira el dashboard, busca en Confluence, no encuentra nada actualizado, llama al senior por Slack, espera 20 minutos. En ese tiempo el incidente ha crecido. Regla: ninguna alerta entra a producción sin runbook publicado y workflow Keep aprobado. CI valida que cada PrometheusRule con severity ≥ warning tiene su keep workflow correspondiente.

Anti-patrón 2 — runbook sin captura de evidencia previa. El workflow ejecuta nvidia-smi --gpu-reset en cuanto llega el XID, perdiendo el estado que habría diagnosticado la causa raíz. El siguiente XID idéntico exige rehacer el diagnóstico desde cero. Regla: steps antes de actions; toda evidencia se captura primero, las acciones destructivas después.

Anti-patrón 3 — escalada por antigüedad en vez de severity. El operador junior de guardia gestiona un ECC DBE porque “le toca”. Le falta contexto para entender row remap, retired pages o el riesgo de corrupción de datos. Regla: paginación por severity, no por rotación: RB-04 y RB-03 dispararon ON-CALL primario senior con escalada automática a infra/hardware si no acuse en 10 min.

Anti-patrón 4 — ausencia de gate humano para acciones destructivas. El workflow ejecuta kubectl drain automáticamente sobre cualquier alerta marcada como CRITICAL. En la primera falsa alarma (un transitorio que se autoresolvió en 30 s), Keep drenó un nodo productivo durante hora pico. Regla: acciones destructivas (drain, reset, RMA, rollback completo) exigen confirmación humana vía Slack interactive message, con timeout configurable. Excepción justificada: ECC DBE confirmado por > 1 medición — el riesgo de corrupción supera el de falsa alarma.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4 nodos × 4×H100 SXM 80 GB con Kafka y Keep ya desplegados:

Kafka: cluster de 3 brokers en nodos no-GPU del cluster K8s; topics gpu.alerts.enriched, incidents.lifecycle, audit.actions configurados con replication factor 3, min.insync.replicas 2. Audit con tiered storage a Ceph RGW para retención > 6 meses sin coste brutal.
Keep: 2 réplicas del operator + 1 réplica del worker en un namespace keep; conectado a Prometheus (provider read), Kafka (provider read + write), Slack, PagerDuty, Jira, Kubernetes (provider con SA específico con permisos get/list/patch nodes, create jobs).
Workflows: ~25-40 YAML en el repo infra/keep-workflows/, sincronizado con el cluster vía Flux o Argo CD. Validados por CI (keep workflow validate) en cada PR.
Volumen de eventos: para 16 GPUs en operación normal con alertas debounced, ~50-200 eventos/día en gpu.alerts.enriched. En incidente típico, picos de 500-2000 eventos/día.
Compliance consumers: un consumer python en namespace compliance que genera reportes NIS2 / ENS / EU AI Act semanalmente, leyendo audit.actions y incidents.lifecycle.

Lo que no hemos cubierto (próximos posts)

Playbooks de postmortem — la mecánica de RCA con 5-whys, Ishikawa adaptado a LLM, integración con MLflow tracking de re-training si el postmortem produce dataset enriquecido.
Chaos engineering para LLM — inyección controlada de XID errors, ECC simulados, latencia HBM artificial para validar runbooks antes del incidente real.
Multi-cluster incident coordination — cómo coordinar Keep entre clusters geográficos cuando un incidente afecta a múltiples regiones.
Integración con CMDB y procurement — el ciclo RMA → ticket → ServiceNow → reposición de hardware automatizado vía workflow.
Forense LLM — extracción de la traza OTel completa de una request afectada por un incidente, redacted PII, conservación en evidence vault.

Ver también

Anatomía de las doce métricas DCGM y cinco vLLM — la anomalía documentada por métrica que estos runbooks resuelven.
Observabilidad GPU para inferencia LLM — la lista compacta y las seis alertas críticas.
Tracing LLM con OpenTelemetry GenAI — la traza OTel que se captura como evidencia.
Canary, blue-green y shadow — el mecanismo de rollback que RB-06 invoca.
Autoscaling LLM en Kubernetes — la palanca de escalado que RB-01 y RB-05 invocan.
Capacity planning — el head-room presupuestado para absorber incidentes sin SLO break.
ISO/IEC 42001 AIMS para LLM on-premise — la cláusula 10 que estos postmortems materializan.
Controles técnicos ENS × 42001 × EU AI Act — el mapeo de controles que estos runbooks satisfacen.
EU AI Act: mapeo a arquitectura LLM — el art. 73 de incidentes graves que activa el sub-workflow legal.
Cinco niveles de madurez — los runbooks codificados son requisito del nivel 3-4.

Referencias

ISO/IEC 27035-1:2023 — Information security incident management — Principles and process.
ISO/IEC 27035-2:2023 — Information security incident management — Guidelines to plan and prepare for incident response.
ENS — Real Decreto 311/2022, Anexo II controles op.exp.7 a op.exp.10.
Directiva NIS2 (UE 2022/2555) — art. 23 (notificación de incidentes significativos).
Reglamento EU AI Act (UE 2024/1689) — art. 73 (reporting of serious incidents).
ISO/IEC 42001:2023 — AI management system — cláusula 10 (mejora continua).
Keep project — keephq.dev y github.com/keephq/keep (documentación de workflows YAML, providers).
Apache Kafka — Tiered Storage y cleanup.policy (docs.confluent.io / kafka.apache.org).
Confluent — Schema Registry y best practices para eventos lifecycle.
NVIDIA — Xid Errors Documentation y procedimientos de remediación.
Google SRE Book — Effective Troubleshooting y Postmortem Culture.
Atlassian — Incident Management Handbook (referencia para severity matrices).

Anatomía de las doce métricas DCGM y cinco vLLM: analogías, anomalías documentadas y casos reales 2024-2026

Tue, 02 Jun 2026 04:00:00 +0200

Este post profundiza la lista de métricas presentada en Observabilidad GPU para inferencia LLM. Allí cada métrica recibió su umbral V/Á/R y query PromQL; aquí cada una recibe su analogía explicativa y la anomalía documentada en producción con caso público referenciado. Es el post que conviene tener abierto cuando una alerta dispara y todavía no se sabe qué hacer con ella; el siguiente post sobre runbooks traduce cada anomalía a acción concreta.

TL;DR

Las doce métricas DCGM (compute, memoria, térmico-energético, salud) y las cinco del motor vLLM (concurrencia, KV pool, latencias del SLO) cubiertas en el post anterior pintan la cabina del cluster, pero la lista sin contexto no enseña a diagnosticar. Cada métrica tiene un patrón anómalo recurrente documentado en literatura pública —papers académicos, issues GitHub, KBs de OEMs, blogs de operadores— que el operador veterano reconoce al instante y el junior no. Este post desarrolla cada métrica con una analogía propia que fija qué pregunta responde y con la anomalía estadísticamente relevante con cifras de incidentes documentados. Tres ejemplos del calibre: Meta publicó que durante el entrenamiento de Llama 3 405B sobre 16.384 H100 hubo 419 fallos no planificados en 54 días —uno cada 3 horas—, con GPU + HBM3 acumulando el 47 % del total; el paper Story of Two GPUs (arXiv 2503.11901) cuantifica que H100 tiene 3.2× peor MTBE por ECC uncorrectable que A100 atribuible a la densidad superior de HBM3; el issue vllm#16300 documenta que en un cluster de 8×A100 80 GB TP=8 entrega peor throughput que TP=4 porque la saturación de NVLink mata el speedup de partition. Las KBs Dell 000220508 y Lenovo HT514380 formalizan el caso recurrente de HW Power Brake en racks H100 sobrecomprometidos a nivel de PDU. El issue vllm#25677 mostró chunked prefill 10× más lento que sin él en Qwen3-30B-A3B (mala calibración de max_num_batched_tokens). El issue vllm#11912 documenta regresión de TPOT de 15.7 ms a 25.7 ms cruzando versión 0.6.4. Cada caso incluye URL verificable. La regla operativa: cuando llega una alerta, mira primero el patrón anómalo asociado a la métrica que disparó, antes de abrir la traza de la request; el 80 % de las degradaciones casan con uno de los patrones documentados.

Estás aquí: OBSERVE — la capa de diagnóstico

Familia 1 — Compute

`DCGM_FI_PROF_SM_OCCUPANCY` — ¿hay trabajo paralelo en los motores?

La analogía. Una cocina industrial con 32 fogones y un único chef. La métrica responde "¿cuántos fogones tienen una sartén encima ahora mismo?". Si la mitad están vacíos, la cocina está infrautilizada — los pedidos van uno detrás de otro porque el chef no abre paralelo. Si todos están ocupados pero el chef está sin moverse mirando un cronómetro, los fogones están encendidos pero no se cocina (un kernel patológico saturando SMs sin hacer trabajo útil).

La anomalía documentada. La trampa más conocida: SM occupancy alto no implica throughput real. El artículo “GPU Utilization Is a Counter, Not a Cause” (Ingero, mayo 2026) lo formuló con una frase exacta: “un kernel que corre al 5 % del pico de FLOPS durante 100 ms todavía marca 100 % en SM_ACTIVE”. En workloads MoE, el efecto se vuelve patológico: los expertos sobrecargados producen el Straggler Effect (paper arXiv 2503.05066) — los SMs aparecen ocupados esperando al experto saturado, y el dashboard de utilización pinta verde mientras la latencia se va al techo.

Implicación operacional. No fiar el sizing ni el autoscaling solo a SM occupancy. Combinar siempre con PIPE_TENSOR_ACTIVE (¿hay compute útil?) y DRAM_ACTIVE (¿la memoria es el cuello?). El régimen normal LLM en decode es 30–55 %, no 99 %; ver 99 % sostenido con TPOT alto es síntoma de bug del kernel o de straggler MoE.

`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE` — ¿los tensor cores producen?

La analogía. Una fábrica con dos líneas: la artesanal (CUDA cores) y la automatizada (tensor cores). La métrica responde "¿qué porcentaje del tiempo está activa la línea automatizada?". Si compras una H100 por sus tensor cores y la línea automatizada está al 5 %, has pagado un Ferrari para llevar mensajería en bicicleta.

La anomalía documentada. El issue vllm#20783 (julio 2025) tituló literalmente “Performance Anomaly: compressed-tensors no muestra speedup sobre BF16 en H100”. El operador esperaba 1.5–2× con cuantización FP8 y obtuvo paridad con BF16; la métrica PIPE_TENSOR_ACTIVE reveló que el path FP8 no estaba ejecutándose en los HMMA (la unidad tensor de FP16/BF16/FP8) y caía a CUDA cores. El issue vllm#31475 documentó el caso paralelo en MI300X: FP8 más lento que BF16 por regresión en el path ROCm. DCGM expone counters separados por unidad (HMMA para FP16/BF16/FP8, IMMA para INT8, DMMA para TF32/FP32); si HMMA está bajo aunque el modelo es BF16, el engine no usa tensor cores.

Implicación operacional. Verificar PIPE_TENSOR_ACTIVE después de cada cambio de quantization o versión del motor; un cambio supuestamente neutro puede haber desactivado el path optimizado. Para prefill esperar 50–80 %; para decode 15–30 % es normal (decode es memory-bound, no compute-bound). Cifra < 5 % en prefill = el motor no está usando tensor cores.

`DCGM_FI_PROF_DRAM_ACTIVE` — ¿está la HBM saturada?

La analogía. Una autopista con N carriles. La métrica responde "¿qué porcentaje del tiempo están todos los carriles ocupados moviendo coches?". Cuando los tensor cores piden datos más rápido de lo que la HBM los entrega, la autopista está al 95 % y los motores esperan. En decode, este es el régimen normal — paseas los pesos del modelo y el KV cache por cada token.

La anomalía documentada. El paper “Mind the Memory Gap: Unveiling GPU Bottlenecks in Large-Batch LLM Inference” (arXiv 2503.08311) cuantifica que a contextos ≥ 128k, la lectura del KV cache domina el tiempo total de decode y satura la HBM3 (3.35 TB/s en H100). Patrón distintivo: DRAM_ACTIVE > 80 % con PIPE_TENSOR_ACTIVE ~10–20 %. Subir el batch ya no ayuda — el cuello no son FLOPS, es bandwidth. La palanca útil es comprimir KV: ver Quantization para --kv-cache-dtype=fp8 que recorta el footprint de KV ~50 %.

Implicación operacional. Si DRAM_ACTIVE > 95 % sostenido y gpu_cache_usage_perc < 70 %, algo está pidiendo HBM que no es tu motor (leak en una librería, otro proceso compartiendo GPU sin MIG). Investigar inmediatamente con nvidia-smi y fuser /dev/nvidia*.

Familia 2 — Memoria

`DCGM_FI_DEV_FB_USED` — ¿cuánta VRAM lleva consumida?

La analogía. El nivel de combustible del depósito de un avión en vuelo: el piloto necesita saber cuánto queda y a qué ritmo se consume, no solo la cifra puntual. Una H100 al 88 % de FB used estable puede operar tranquila; la misma cifra subiendo 2 %/min anuncia OOM en 7 minutos.

La anomalía documentada. El issue dcgm-exporter#512 documenta una sorpresa relevante para clusters MIG: DCGM_FI_DEV_FB_USED y DCGM_FI_DEV_FB_FREE están ausentes en GPU instances H100 con MIG activado — sí presentes en A100 y B200, pero un bug del exporter los esconde en H100-MIG. Operadores que asumen el dashboard cubre todo descubren la ceguera el día del primer OOM. Issue dcgm-exporter#271 documenta otro detalle: FB_USED + FB_FREE no siempre suma constante porque hay overhead reservado por el driver que aparece en el delta. El paper original de PagedAttention/vLLM estimaba que serving frameworks pre-PagedAttention desperdiciaban 60–80 % del KV cache por fragmentación; PagedAttention lo bajó a < 4 %.

Implicación operacional. En clusters MIG H100, verificar que DCGM_FI_DEV_FB_USED aparece por instance antes de confiar en alertas; si está ausente, monitorizar vía nvidia-smi --query-gpu=memory.used directamente. Regla operativa: alertar sobre delta (subida sostenida), no solo umbral absoluto.

`DCGM_FI_DEV_FB_FREE` — el complemento absoluto

La analogía. El indicador “kilómetros restantes” del coche moderno: complementa al porcentaje con una cifra absoluta directamente accionable.

La anomalía documentada. Cuando un PagedAttention pool agresivo deja FB_FREE en valores absolutos pequeños (< 2 GiB), cualquier asignación normal de buffers transitorios (activaciones de un prefill grande) puede empujar al OOM. El patrón clásico: porcentaje “verde” (87 %) pero absoluto “rojo” (< 4 GiB libres en una H100 de 80 GB).

Implicación operacional. Alerta complementaria con umbral absoluto: DCGM_FI_DEV_FB_FREE < 4096 (MiB). Es la red de seguridad para los casos donde el porcentaje engaña porque el motor está configurado con gpu_memory_utilization muy alto.

`DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL` — ¿el bus interno aguanta?

La analogía. Una autopista interestatal entre cuatro ciudades. Cada coche que cruza para hacer un all-reduce de tensor parallel paga peaje y consume ancho. Cuando hay más coches que la autopista soporta, la latencia para llegar a destino se dispara — aunque cada coche individual sea rápido.

La anomalía documentada. El issue vllm#16300 (abril 2025) tituló “Performance degradation with tp=8 compared to tp=4 on 8×A100(80G)” y documentó TP=8 entregando peor throughput que TP=4 en el mismo cluster, mismo modelo, misma quantization. Causa raíz: el tensor parallelism requiere all-reduce tras cada bloque de atención y MLP; a TP=8, el coste de comunicación entre 8 GPUs (incluso vía NVSwitch) crece más rápido que el speedup del partition compute. La regla práctica que emerge: TP=4 + 2 réplicas suele entregar mejor latencia/throughput que TP=8 + 1 réplica salvo para contextos extremadamente largos (≥128k) donde necesitas la VRAM agregada. Capacidad teórica NVLink 4.0 en H100 SXM: ~450 GB/s por GPU; régimen TP=4 sostenido típico: 50–150 GB/s.

Implicación operacional. Si NVLINK_BANDWIDTH_TOTAL > 90 % capacidad sostenido, no es problema resoluble subiendo paralelismo — al revés, bajar TP. La métrica es ortogonal al sizing del capacity planning: el techo no es solo VRAM/tiempo, también el bus.

Familia 3 — Térmico y energético

`DCGM_FI_DEV_GPU_TEMP` — ¿la GPU respira?

La analogía. La temperatura corporal de un atleta de élite en pleno esfuerzo. 36–37 °C es normal; 38 °C es estrés sostenible; por encima de 39 °C el cuerpo activa mecanismos de protección (sudoración, ralentización) que degradan el rendimiento. La GPU hace lo mismo: por encima de un umbral térmico, reduce su clock automáticamente. Si no lo hiciera, se rompería.

La anomalía documentada. El H100 SXM5 con TDP 700 W tiene thresholds térmicos no enteramente públicos (NVIDIA no los publica exhaustivamente en datasheet), pero el comportamiento es bien conocido: por encima de ~85 °C edge o ~95 °C HBM aparece el bit 0x40 HW_THERMAL en clock throttle reasons. Operadores en el foro NVIDIA developer reportan que con temperatura de entrada al rack > 27 °C, el throttle es habitual. El paper de NVIDIA HGX Platform indica que el flujo de aire mínimo recomendado es > 1000 CFM/kW; densidades > 30 kW/rack a 700 W TDP exigen liquid cooling obligatorio porque el aire forzado no llega.

Implicación operacional. Si GPU_TEMP > 83 °C sostenido, mirar primero CLOCK_THROTTLE_REASONS (bit 0x40) y temperatura de entrada al rack — no es problema del motor, es del flujo de aire. Para racks legacy aire-cooled, plantear redistribuir carga térmica o instalar rear-door HX.

`DCGM_FI_DEV_POWER_USAGE` — ¿cuánto pide al enchufe?

La analogía. El consumo instantáneo de un electrodoméstico industrial conectado a una toma trifásica con un breaker dimensionado. Si la lavadora arranca a 9 kW y el breaker es de 10 kW, vives al filo; si la lavadora se “lleva bien” con el breaker es porque alguien dimensionó conscientemente.

La anomalía documentada. Medición real publicada: una H100 SXM5 con vLLM corriendo Llama 3.1 405B batch=4 consume ~697 W at-wall sostenido (NVIDIA TDP 700 W). Ahora la palanca operativa interesante: bajar nvidia-smi -pl de 700 W a 500 W entrega ~30 % de ahorro energético con solo ~20 % de pérdida de throughput. Cluster de 4 nodos × 8 H100 a 700 W = ~22 kW solo de GPU; a 500 W = ~16 kW. La diferencia paga la factura eléctrica entera de un trimestre en clusters operados ininterrumpidamente. Una rama PDU 415 VAC trifásica 60–80 A soporta ~32 kW, ~4 DGX H100. Legacy 208 V no soporta densidad H100 — referencia: NVIDIA DGX SuperPOD Electrical Specifications.

Implicación operacional. Métrica útil para tres cosas: (1) detectar workloads anómalamente bajos (idle inesperado), (2) calcular showback de coste energético real por tenant (no estimaciones), (3) alertar si el draw se acerca al límite de PDU rama. Tener mapeado GPU → PDU rama → breaker en CMDB.

`DCGM_FI_DEV_CLOCK_THROTTLE_REASONS` — ¿quién pisa el freno?

La analogía. El testigo de “modo limitado” en el salpicadero de un coche moderno. Cuando se enciende, el coche reduce su rendimiento automáticamente, pero no te dice por qué salvo que sepas leer la combinación de letras. Los bits del bitmap son esas letras.

La anomalía documentada. Caso público formalmente reconocido por dos OEMs distintos: Dell KB 000220508 y Lenovo HT514380 abordan el mismo fenómeno: HW Power Brake Slowdown active (bit 0x80) en H100 SXM. La causa no es la GPU — es la PDU del chasis enviando una señal eléctrica de power-brake porque la rama del rack está cerca del límite del breaker. El operador ve throughput caído 30–50 % sin XID ni ECC, y el motor de inferencia “está sano”; el problema está en electricidad. Foro NVIDIA developer en “HW Power Brake Slowdown” corrobora el patrón. El bit 0x40 HW_THERMAL aparece en racks mal ventilados; el bit 0x04 SW_POWER_CAP aparece si alguien dejó nvidia-smi -pl 500 y nadie revertirá.

Implicación operacional. Cualquier bit ≠ 0 ni Idle (bit 0x01) sostenido es alerta inmediata. La descodificación recomendada: registrar el valor bitmap completo en el log + atributo throttle.reasons.decoded=["HW_THERMAL", "HW_POWER_BRAKE"] en el span OTel. Sin esto, el incident response no sabe qué hacer.

Familia 4 — Salud (los reportes catastróficos)

`DCGM_FI_DEV_XID_ERRORS` — los códigos rojos del driver

La analogía. Las luces de alarma críticas en una sala de control nuclear. No suben gradualmente; aparecen o no aparecen. Cada XID es un código predefinido (XID 13 = excepción del motor de gráficos; XID 31 = fault de MMU; XID 43 = stopped channel; XID 79 = GPU fallen off the bus; XID 95 = uncontained ECC), y cada uno tiene su procedimiento documentado.

La anomalía documentada. El caso público más estudiado: Meta publicó que durante el entrenamiento de Llama 3 405B sobre 16.384 H100 en 54 días hubo 419 fallos no planificados, uno cada 3 horas a escala de cluster. GPU acumuló 148 (35 %) + HBM3 72 (17 %) = casi la mitad de todos los fallos. El paper “Story of Two GPUs: Characterizing the Resilience of Hopper H100 and Ampere A100” (arXiv 2503.11901) cuantifica con un dataset distinto (2.1M GPU-horas) que H100 tiene 3.2× peor MTBE para ECC uncorrectable que A100. El paper de ByteDance MegaScale reporta que XID 79 (“GPU fallen off the bus”) coocurre con errores PCIe en el 43 % de los casos. El foro NVIDIA developer documenta casos persistentes de XID 31 (MMU fault) que siguen a la GPU al cambiar de slot PCIe — bug hardware del módulo, no del backplane.

Implicación operacional. Cualquier incremento del contador es alerta inmediata: muchos XID exigen reset del nodo o RMA de la GPU. La distinción XID-por-XID importa: XID 13/43 suele ser bug de software si coincide con cambio reciente; XID 31/48/79/94/95 suele ser hardware. Mantener tabla canónica xid → procedimiento. Ver los runbooks para la traducción a acción concreta.

`DCGM_FI_DEV_ECC_DBE_VOL_TOTAL` — los errores que corrompen datos

La analogía. Un libro de contabilidad donde a veces alguien borra una entrada y la rescribe (ECC single-bit corregido — anota un cambio en el margen y sigue) y a veces alguien quema dos páginas a la vez (double-bit — la información se perdió, hay que parar la auditoría).

La anomalía documentada. El paper “Characterizing GPU Resilience” cuantifica para H100: cuando XID 48 (DBE) aparece, el job en curso muere con 100 % de probabilidad (5/5 en el dataset estudiado). La recuperación documentada: drenar el nodo + reset + completar row remap = ~19 horas de downtime de nodo. La densidad HBM3 explica el peor MTBE vs HBM2e: hay más celdas por unidad de área, mayor probabilidad estadística de degradación. En Llama 3, HBM3 causó 72 de 419 interrupciones (17 %).

Implicación operacional. Cualquier valor > 0 = alerta crítica. La GPU debe ser drenada inmediatamente, retirada del scheduler, reset completo, validación de row remap con nvidia-smi -q -d ROW_REMAPPER (Pending: No), y antes de volver al pool, smoke test extenso. Si el row remap usa > 4–8 páginas de spare en una GPU, planificar reemplazo en próxima ventana — la degradación es progresiva.

`DCGM_FI_DEV_RETIRED_DBE` — las páginas marcadas para retirar

La analogía. Las baldosas que el restaurador del museo marca con cinta amarilla porque están dañadas. No suponen peligro inmediato (la sala sigue abierta), pero la acumulación dice que el suelo se está degradando estructuralmente y el reemplazo entero hay que planificarlo.

La anomalía documentada. NVIDIA documenta hasta 512 páginas de spare por banco HBM en H100; el contador RETIRED_DBE indica cuántas se han usado. Operadores en foros NVIDIA reportan que por encima de 4–8 páginas retiradas en una GPU concreta, la frecuencia de XID 48 sube. Patrón: GPU con 6 páginas retiradas hoy → 12 en un mes → primer XID 48 dos meses después → drain forzoso.

Implicación operacional. Métrica de tendencia, no de alerta inmediata. Documentar valor por GPU y revisar mensualmente; las GPUs con valores crecientes entran al plan de reemplazo proactivo antes del fallo catastrófico.

Las cinco métricas del motor vLLM

`vllm:num_requests_running` — ¿cuántas requests caben en el batch?

La analogía. El número de coches que un peaje deja pasar simultáneamente. Si la barrera abre N a la vez, las N+1 esperan en cola. La saturación se nota porque la fila no se acorta.

La anomalía documentada. Llegar al --max-num-seqs configurado y mantenerse ahí es síntoma típico de cluster por debajo del sizing; el motor admite hasta el techo y no más. La query vllm:num_requests_running == max_num_seqs durante > 5 minutos indica saturación firme.

Implicación operacional. Combinar con num_requests_waiting: si running está al techo Y waiting > 0, hay que escalar. Si running está al techo y waiting es 0, estás en el régimen óptimo (cluster usado al máximo sin cola).

`vllm:num_requests_waiting` — el indicador primario de saturación

La analogía. La cola visible delante del peaje. Mientras esté vacía, el sistema fluye; en cuanto se forma cola sostenida, los conductores empiezan a llegar tarde a destino — el TTFT se va al techo.

La anomalía documentada. Caso público en “11-Second Time to First Token on a Healthy vLLM Server” (Medium, Ingero, 2026): servidor sin XIDs, sin preemption, métricas DCGM en verde, pero num_requests_waiting sostenido > 0 y TTFT de 11 segundos. El issue vllm#16985 documenta degradación progresiva en sesiones largas: la queue crece lentamente durante horas sin que ningún otro indicador se mueva. La causa raíz no es de hardware — es de admission control: la tasa de entrada supera la de finalización y el sistema no encola más, deja en WAITING. Red Hat la designa como la métrica primaria de saturación en su tutorial “5 steps to triage vLLM performance”.

Implicación operacional. Métrica primaria del HPA en KEDA —ver Autoscaling LLM en Kubernetes—. Umbral típico: alertar si avg_over_time(vllm:num_requests_waiting[5m]) > 5. Para canary: si la cola se forma solo en el pool v2, es regresión del nuevo modelo, no carga del cluster.

`vllm:gpu_cache_usage_perc` — el pool de KV cache

La analogía. La capacidad de una sala de eventos donde cada invitado ocupa un espacio variable. El maître admite hasta el aforo; cuando llega un invitado nuevo y no hay sitio, echa al invitado que lleva más tiempo para hacerle hueco al recién llegado. Eso es el preempt-on-OOM de vLLM.

La anomalía documentada. El issue vllm#5051 “Add num_requests_preempted metric” nació exactamente de operadores observando degradación pero sin métrica directa que les dijese cuántas requests se estaban echando. Documentación oficial vLLM confirma: “sustained gpu_cache_usage_perc above 90 % indicates the server is approaching its KV cache limit and will begin preempting sequences” (oldest-first). El patrón visual distintivo: sierra (sawtooth) cerca del 100 % con picos de preemption. En modo swap, la latencia de la request preempted explota porque hay copia PCIe host↔device; en modo recompute (default en V1), la request preempted rehace su prefill desde cero, lo que dispara su TTFT al doble o triple.

Implicación operacional. Si gpu_cache_usage_perc > 92 % sostenido, dos palancas: bajar max_num_seqs (admite menos concurrencia pero ninguna se preempta) o subir gpu_memory_utilization (más pool, menos VRAM para activations transitorias — riesgo distinto). La elección depende del workload. La métrica que falta directamente —contador de preempted— se exporta a partir de vLLM v1.0 en vllm:num_preemptions_total (ver issue #5051).

`vllm:time_to_first_token_seconds` — la latencia visible al cliente

La analogía. El tiempo desde que un cliente entra a un restaurante hasta que recibe el primer trozo de pan en la mesa. Demasiado largo y el cliente piensa que se han olvidado de él, aunque la comida principal vaya a llegar perfecta.

La anomalía documentada. Tres patrones documentados de spike de TTFT recurrentes:

Chunked prefill mal calibrado. Issue vllm#25677 (Qwen3-30B-A3B) reportó prefill 10–11× más lento con chunked prefill activado que sin él. Causa: max_num_batched_tokens muy bajo fuerza chunks pequeños que no llenan los kernels. Issue vllm#7604 documenta regresión equivalente en Llama-3-70B v0.5.4. La palanca: subir max_num_batched_tokens a 4096–8192 para prompts típicos > 2k.
Regresión entre versiones del motor. Issue vllm#8819 documenta regresión de vllm:time_to_first_token_seconds_sum entre versiones minor. Issue vllm#11912 reporta que con prompt ~8000 tokens, TPOT subió de 15.7 ms → 25.7 ms desde v0.6.4.post1 sin cambio de config — regresión confirmada y trackable solo con la métrica.
Long-context prefill bloqueando decodes. El caso “11s TTFT on healthy server” citado arriba: un prefill de 30k tokens monopoliza la GPU durante varios segundos y los decodes activos congelan. Solución: chunked prefill bien calibrado, o disaggregated serving (ver Disaggregated serving).

Implicación operacional. No alertar solo sobre P95 absoluto; alertar también sobre ratio v2/v1 cuando hay canary (histogram_quantile(0.95, ..., version="v2") / histogram_quantile(0.95, ..., version="v1") > 1.10). Si TTFT crece y la queue está estable, el bottleneck es prefill — no resoluble subiendo réplicas, sí palanca de quantization o chunked prefill.

`vllm:time_per_output_token_seconds` — la fluidez del streaming

La analogía. La velocidad a la que el camarero trae los platos uno detrás de otro después del primero. Si tarda en venir el siguiente, el comensal nota que algo no va bien aunque el primer plato haya llegado a tiempo.

La anomalía documentada. El patrón distintivo es el escalón abrupto cuando gpu_cache_usage_perc cruza ~85 %: el TPOT pasa de 35 ms a 80 ms en pocos segundos porque el motor empieza a competir por la HBM con sus propias evicciones. Issue vllm#35387 documenta otro caso anómalo: MTP (speculative decoding) causando 76 % de regresión de latencia en Qwen3-Next-80B-A3B-Instruct-FP8 — la métrica TPOT lo capturó antes de que se reportasen quejas de clientes.

Implicación operacional. Diferencia con TTFT: si TTFT crece y Queue Time estable → prefill bound; si TPOT crece a tasa estable → presión sobre HBM (KV cache pool o swap activado). Alerta secundaria sobre el SLO de TPOT, pero también vigilar la derivada: TPOT subiendo 1 ms cada 10 minutos es regresión latente que aún no rompe SLO pero lo hará.

La regla operativa: leer las métricas por familia, no aisladas

Tres anti-patterns del operador novato

Anti-pattern 1 — alertar solo sobre umbrales absolutos. Una H100 al 87 % de FB no es necesariamente alarma; la H100 con 87 % subiendo 2 %/min sí lo es. Las alertas que disparan por umbral fijo sin mirar derivada producen el doble de ruido y la mitad de la utilidad. Regla: para métricas con dinámica conocida (KV cache, FB, queue), alertar sobre delta sostenido, no solo nivel.

Anti-pattern 2 — confundir SBE con DBE. El contador DCGM_FI_DEV_ECC_SBE_VOL_TOTAL (single-bit, corregibles) crece continuamente en cualquier HBM bajo carga; no es alarma, es física. El que importa es DCGM_FI_DEV_ECC_DBE_VOL_TOTAL (double-bit, no corregibles). Confundirlos = falsos negativos (no alertar sobre DBE real) o falsos positivos (alertar sobre SBE inofensivo).

Anti-pattern 3 — tratar SM_OCCUPANCY 99 % como “saturada”. El régimen LLM en decode es memory-bound, no compute-bound; SM occupancy alto con TENSOR_ACTIVE bajo y DRAM_ACTIVE alto es lo normal. Dimensionar para “GPU al 60 %” pidiendo más hardware cuando el cluster está saturado en HBM (no en SM) es comprar el doble de GPU sin ganar throughput. Regla: leer SM_OCCUPANCY siempre con TENSOR_ACTIVE y DRAM_ACTIVE; aislada no significa nada.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4 nodos × 4×H100 SXM 80 GB con NVLink intra-nodo:

DCGM Exporter por nodo (DaemonSet del GPU Operator) emitiendo cada 15 s; cardinalidad por GPU = ~80 series. Cluster 16 GPUs ≈ 1.3k series base, ~85k samples/min con scrape de 15 s.
vLLM /metrics por pod inferencia; cada réplica emite ~50 series base. Para 16 réplicas, ~800 series adicionales, ~3k samples/min.
Prometheus retention: 30 días alta resolución + 1 año downsampled vía Thanos sidecar o Mimir. Volumen estimado: 25–35 GB/día.
Alertmanager: las 6 alertas críticas del post anterior + alertas derivadas (delta, ratio v2/v1, throttle bitmap decodificado).

Cada métrica conviene exponer también como atributo OTel en los spans del tracing GenAI: gpu.fb_used_pct, gpu.dram_active, gpu.throttle_reasons.decoded. Eso permite correlacionar una request lenta con el estado de la GPU en ese instante, sin saltar entre dashboards.

Lo que no hemos cubierto (próximos posts)

Runbooks por alerta — la traducción de cada métrica anómala a acción concreta (drain, reset, RMA, escalado, rollback) en el siguiente post: Runbooks de incident response.
Tail-sampling para correlación métrica ↔ traza — qué se preserva cuando una alerta dispara para investigación post-mortem.
Showback por tenant combinando vllm:request_success_total × gen_ai.usage.* × DCGM_FI_DEV_POWER_USAGE para facturar coste energético real.
Métricas de fairness multi-tenant — cuándo un tenant acapara el KV cache pool y cómo detectarlo.

Ver también

Observabilidad GPU para inferencia LLM — la lista compacta que este post profundiza.
Runbooks de incident response para LLM con Keep + Kafka — la traducción de cada anomalía a acción.
Tracing LLM con OpenTelemetry GenAI — la otra mitad de la observabilidad.
Autoscaling LLM en Kubernetes — num_requests_waiting y gpu_cache_usage_perc como métricas primarias de HPA.
Capacity planning para inferencia LLM on-premise — cómo se relacionan los umbrales con el sizing.
Canary, blue-green y shadow — el ratio TTFT v2/v1 como gate.
Continuous batching — explica el preempt-on-OOM y la sierra del KV pool.
KV cache — fundamenta el cálculo de gpu_cache_usage_perc.

Referencias

Meta — Faulty Nvidia H100 GPUs and HBM3 memory caused half of failures during Llama 3 training (Tom’s Hardware, 2024). tomshardware.com
Story of Two GPUs: Characterizing the Resilience of Hopper H100 and Ampere A100. arXiv 2503.11901. https://arxiv.org/html/2503.11901v3
ByteDance — Robust LLM Training Infrastructure at ByteDance. arXiv 2509.16293. https://arxiv.org/pdf/2509.16293
Mind the Memory Gap: Unveiling GPU Bottlenecks in Large-Batch LLM Inference. arXiv 2503.08311.
Capacity-Aware Inference: Mitigating the Straggler Effect in Mixture of Experts. arXiv 2503.05066.
NVIDIA — Analyzing Xid Errors with the Xid Catalog y Memory Error Management (docs.nvidia.com/deploy).
Dell — PowerEdge XE8640 with H100 - GPU Performance Issue HW Power Brake Slowdown - Active (KB 000220508).
Lenovo — Power brake reporting on H100 GPU (HT514380).
vLLM project — issues #5051 (preempted metric), #7604 y #25677 (chunked prefill regression), #11912 (long-prompt regression), #16300 (TP=8 worse than TP=4), #16985 (long-running degradation), #20783 (compressed-tensors no speedup), #35387 (MTP regression).
Red Hat — 5 steps to triage vLLM performance. https://developers.redhat.com/articles/2026/03/09/5-steps-triage-vllm-performance
AI21 — Go big or go OOM: the art of scaling vLLM. https://www.ai21.com/blog/scaling-vllm-without-oom/
11-Second Time to First Token on a Healthy vLLM Server (Medium, Ingero, 2026).
NVIDIA — DGX SuperPOD Electrical Specifications (docs.nvidia.com/dgx-superpod).

Sources: las URLs completas están enlazadas en línea sobre cada referencia.

El router de inferencia LLM: la centralita L7 que en el post de canary llamábamos LoadBalancer

Tue, 02 Jun 2026 03:00:00 +0200

Este post es la continuación natural de Canary, blue-green y shadow para modelos LLM. Allí la mecánica de promoción depositó toda la complejidad de reparto de tráfico en una caja a la que llamamos “LoadBalancer”. La descripción era operacional —servía para entender la coreografía— pero estructuralmente vaga: lo que de verdad hace ese reparto es un router de inferencia L7 con awareness LLM, una pieza de pleno derecho del stack (capa 1 de las siete capas) que merece su propio post.

TL;DR

En el post anterior sobre canary llamamos LoadBalancer a la pieza que reparte tráfico entre los pools v1 estable y v2 candidato. La descripción servía para entender el flujo, pero técnicamente era borrosa: ni un LoadBalancer L4 (kube-proxy, MetalLB, IPVS) ni un LoadBalancer L7 HTTP genérico (NGINX o HAProxy sin extensión) saben qué es un modelo, qué es una versión, cuántos tokens cuesta una request, qué prefijo tiene el prompt o qué KV cache tiene caliente cada réplica. La pieza correcta es un router de inferencia LLM: un proxy L7 con conocimiento explícito del dominio. Combina cuatro funciones: catálogo de modelos (resolver model=llama-70b@v2 → service.namespace:port), traffic splitting (aplicar el weight de canary con hash determinista o sticky deliberado para A/B), política transversal (auth OIDC, rate limit y quota por tenant, redact PII pre-prompt, guardrails ligeros inline, propagación de tracing gen_ai.*) y failover/degradación (si v2 cae, redirigir a v1; si todo el cluster está saturado, devolver 503 con Retry-After en vez de encolar para siempre). La pieza no obvia que justifica su existencia técnica más allá de la operacional es el prefix-aware routing: el router decide a qué réplica de la flota va cada request en función del prefijo del prompt, para que un sistema RAG con el mismo system prompt + el mismo bloque de documentos recuperados acierte sistemáticamente en el prefix cache (RadixAttention en SGLang, PrefixCaching en vLLM, KV reuse en TensorRT-LLM) de la misma réplica, multiplicando el hit rate del 5–15 % (round-robin ciego) al 60–85 % (afinidad por prefix). Las piezas concretas en mayo 2026 son LiteLLM Proxy (la opción más simple, OpenAI-compatible, catálogo declarativo YAML), vLLM Production Stack router (específico para flotas vLLM, aware del KV cache y del prefix), Envoy AI Gateway (filtros Envoy LLM-aware, integrable con Istio), Kong AI Gateway (alternativa empresarial con plugin ecosystem), KGateway (CNCF en gestación) y NVIDIA Dynamo router (production-grade, aware de disaggregated serving prefill/decode). En el stack de siete capas vive en la capa 1 (gateway); en el de cinco niveles de madurez aparece a partir del nivel 3; en el ciclo de siete fases de despliegue es la última pieza que F6 cierra. Este post incluye un manifest mínimo aplicable a un cluster genérico de 4×H100 SXM.

Estás aquí: DEPLOY (capa 1 del stack)

El antecedente: lo que el post de canary llamaba “LoadBalancer”

En Canary, blue-green y shadow para modelos LLM describimos el flujo así: “el LoadBalancer reparte progresivamente el tráfico siguiendo un cronograma: 1 % → 5 % → 25 % → 100 %”. Era una descripción operacional correcta — el lector entendía la coreografía sin necesitar más. Pero técnicamente dejaba sin nombre a una pieza que merece tratamiento explícito, porque ninguno de los dos sentidos habituales de “LoadBalancer” hace lo que ese párrafo asumía:

Un LoadBalancer L4 —kube-proxy con iptables/IPVS, MetalLB, F5 BIG-IP en modo TCP— reparte paquetes IP sin mirar dentro del payload. No sabe qué modelo se pide, ni qué versión, ni cuántos tokens lleva, ni si el cliente tiene quota. No puede aplicar el weight del canary “para el modelo X versión 2”: para él todos los paquetes hacia el VIP vllm-llama70b son indistinguibles.
Un LoadBalancer L7 HTTP genérico —NGINX o HAProxy en modo HTTP sin extensión, una Service de tipo ClusterIP con backend múltiple— sí reparte por URL y puede hacer routing por header, pero no entiende el cuerpo OpenAI-compatible de la request. No sabe que {"model": "llama-70b", "messages": [...]} lleva en el campo model la clave de routing; no cuenta tokens; no aplica políticas sobre estructuras LLM; no hace prefix-aware routing porque eso exige parsear el messages y hashear el prefijo común.

La pieza que el post de canary asumía haciendo este trabajo es un router de inferencia L7 con awareness LLM. Una capa de pleno derecho, con su propia configuración, su propio CI/CD, sus propias métricas y sus propios pitfalls. Este post la nombra y la desmonta.

La analogía: la centralita y triage de un hospital con múltiples especialidades

Un hospital grande recibe pacientes que llegan a urgencias por puertas distintas y que necesitan especialidades distintas: traumatología, cardiología, pediatría, oncología. Hay tres modelos posibles de “puerta de entrada”.

Puerta única sin triage. Todos los pacientes esperan en la misma sala y los van pasando por orden de llegada al primer médico libre, sea su especialidad la que sea. Funciona en un consultorio de aldea con un único médico generalista. Cuando hay 200 pacientes al día y 12 especialidades, cae rápido en disfunción: el cardiólogo atiende esguinces, el pediatra atiende infartos, los recursos especializados se desperdician. Es el equivalente del LoadBalancer L4 — reparte cuerpos sin entender qué traen.

Puerta con receptionist que pregunta el síntoma. Una persona en mesa de entrada pregunta “¿qué le pasa?” y dirige al paciente al pasillo correcto. El cardiólogo ve solo cardiología, el pediatra solo niños. Mejor, pero el receptionist es lento, no calibra urgencias y no conoce el estado de las salas: puede mandar al cardiólogo del pasillo A cuando el del B está libre. Es el equivalente de un L7 HTTP genérico con path-based routing — reparte por categoría pero sin información del estado interno.

Triage profesional con awareness completo. Una enfermera de triage formada que conoce el catálogo de especialidades, sabe qué box está ocupado y cuál libre, recuerda al paciente recurrente cuyo expediente ya está abierto en el sistema (manda al mismo médico para continuidad), aplica política transversal (verifica cobertura del seguro, registra alérgenos, redirige a urgencias pediátricas si el paciente es menor) y, si la sala de cardiología cae por una avería del electrocardiograma, redirige al hospital del otro lado de la ciudad. Esta es la pieza que un hospital grande necesita. En LLM se llama router de inferencia.

La analogía sostiene hasta el último detalle, incluido el del “expediente ya abierto”: el paciente que vuelve al mismo médico es exactamente el cliente cuyo prompt comparte prefijo con el de hace 5 minutos. Si el router lo manda a la misma réplica, esa réplica todavía tiene el KV cache caliente y la request acierta el prefix cache. Si lo manda a una réplica distinta porque iba “la siguiente en round-robin”, el KV cache hay que reconstruirlo desde cero y la TTFT se va al doble. La enfermera de triage sabe esto. El LoadBalancer ciego no.

Las cuatro funciones del router de inferencia

Función 1 — Catálogo de modelos

El router mantiene un catálogo declarativo que mapea identidad de modelo a deployment concreto:

models:
 - name: "llama-70b" # alias estable
 version: "v2" # versión canary
 weight: 5 # 5% del tráfico
 endpoint: "vllm-llama70b-v2.inference.svc.cluster.local:8000"
 capabilities: [chat, tool_use]
 lifecycle: canary
 - name: "llama-70b"
 version: "v1"
 weight: 95
 endpoint: "vllm-llama70b-v1.inference.svc.cluster.local:8000"
 capabilities: [chat, tool_use]
 lifecycle: stable
 - name: "embedding-multilingual"
 version: "v1"
 weight: 100
 endpoint: "tei-bge-m3.inference.svc.cluster.local:8080"
 capabilities: [embeddings]
 lifecycle: stable

El cliente envía {"model": "llama-70b", "messages": [...]} sin saber que detrás hay dos pools de réplicas. El router resuelve. Si mañana migras de vLLM a SGLang para una versión concreta, el cliente no se entera; cambias el endpoint en el catálogo y listo.

Lo que se gana con este desacoplamiento es la libertad de mover topología sin romper clientes. Lo que cuesta es mantener disciplinada la convención de nombres (llama-70b siempre es el alias estable; llama-70b@v2 es la versión específica para canary). Sin esa disciplina, los aliases se ensucian con llama-70b-prod-fixed-real-final-v3 y el catálogo deja de ser navegable a las pocas semanas.

Función 2 — Traffic splitting

Las particiones del post de canary (1 % → 5 % → 25 % → 100 %) se materializan aquí, no en el motor de inferencia. El router calcula un hash determinista del request_id (o del user_id, si se quiere sticky) y lo mapea al rango de weights del catálogo. Para un weight [v1: 95, v2: 5], el 5 % del espacio hash cae en v2 y el 95 % en v1.

Tres decisiones de diseño que importan:

Hash por request_id aleatorio = muestreo independiente. Cada request es una observación independiente de la distribución v1 vs v2. Es el setting correcto para canary estadísticamente comparables.
Hash por user_id = sticky por usuario. El mismo cliente ve siempre el mismo pool. Útil para A/B testing con memoria conversacional persistida, pero rompe la comparabilidad estadística del canary porque las poblaciones de usuarios no son simétricas — pitfall explicado en el post anterior.
Hash por tenant_id = particionado fuerte. Tenant A va a v1, tenant B a v2. Es el patrón para clientes con SLA distintos o para validar v2 en un tenant interno antes de exponerlo a clientes externos.

Función 3 — Política transversal

Una vez por encima de todos los modelos, el router aplica:

Auth: OIDC con tokens JWT validados contra Keycloak / Authentik. Headers Authorization: Bearer ... traducidos a tenant_id y roles.
Rate limit: token bucket por tenant (X req/min) o por modelo (Y req/min para llama-70b porque es caro).
Quota: cuota mensual de tokens consumidos por tenant. El router cuenta gen_ai.usage.input_tokens + gen_ai.usage.output_tokens y rechaza con 429 Quota exceeded cuando se agota.
Redact PII pre-prompt: Presidio o Llama Guard en línea antes de que el prompt toque el modelo. Lo que el modelo no ve, no se entrena con ello, no se loguea, no se filtra.
Guardrails ligeros inline: PromptGuard 2, Llama Guard 4, Granite Guardian — los que aparecen en Guardrails y safety en LLMs— se ejecutan en el router porque su latencia (30–150 ms) cabe en el presupuesto de TTFT.
Propagación de tracing gen_ai.*: el router inicia el span padre, propaga traceparent al motor y emite los atributos gen_ai.system, gen_ai.request.model, gen_ai.request.version que el tracing OTel GenAI consume.
Semantic cache: para prompts repetidos exactos o con similitud semántica alta (embedding cosine > 0.97 contra cache previa), devuelve la respuesta cacheada sin tocar el motor. Ahorro típico en RAG con preguntas frecuentes: 20–40 % de las requests.

Función 4 — Failover y degradación

El router conoce el estado de salud de cada endpoint (health probes activos cada 5–15 s, latencia de TTFT recientes) y decide:

Si v2 devuelve 5xx persistente o no responde, circuit breaker abierto: el router redirige el tráfico que iba a v2 hacia v1 hasta que las probes vuelvan a verde. Esto es el rollback automático del canary en su forma más simple.
Si todo el cluster está saturado (todas las réplicas reportan num_requests_waiting > N durante T segundos), el router devuelve 503 Service Unavailable con Retry-After: 30 en vez de encolar para siempre. Mejor decirle al cliente “vuelve en 30 segundos” que tenerlo esperando 4 minutos y luego dar timeout.
Si hay multi-region o multi-cluster, failover cross-cluster vía DNS o L7: la región primaria cae, el router de la secundaria asume.

La pieza no obvia: prefix-aware routing

Esta es la función que un LoadBalancer convencional no puede hacer y que justifica un router específico de LLM más allá de las cuatro genéricas.

El KV cache de vLLM, SGLang y TensorRT-LLM puede reusar prefijos comunes entre requests —ver KV cache—. Concretamente:

vLLM con --enable-prefix-caching: detecta que la request actual comparte un prefijo (longitud múltiplo del block size, default 16 tokens) con una request anterior cuyas páginas todavía están en HBM, y reutiliza esas páginas en vez de reprocesarlas.
SGLang con RadixAttention: estructura el cache como un árbol radix indexado por tokens; cada request acierta el camino común del árbol y solo computa la cola.
TensorRT-LLM: feature similar, llamado KV cache reuse.

El hit rate del prefix cache es la métrica clave: cada token acertado es un token que no se procesa en prefill, reduciendo TTFT en proporción directa. Para un sistema RAG típico —system prompt de 400 tokens + documentos retrieved de 2 000 tokens + pregunta del usuario de 50 tokens— el prefijo común (system_prompt + docs) son 2 400 de los 2 450 tokens totales. Si el cache acierta, el prefill solo procesa 50 tokens en vez de 2 450: TTFT cae aproximadamente a la vigésima parte.

Pero el cache vive por réplica, no globalmente. Si dos requests con el mismo prefix de 2 400 tokens caen en réplicas distintas, ambas hacen el prefill completo: el cache de la primera no sirve a la segunda. La segunda paga el coste íntegro.

Con round-robin ciego (cualquier LB convencional), las requests se reparten uniformemente entre N réplicas. Para un cluster de 4 réplicas y 1 000 requests con el mismo system_prompt + docs, cada réplica recibe ~250 requests, pero las 4 hacen su propio “primer prefill” y los siguientes 249 se benefician dentro de su réplica. El hit rate global es decente pero no óptimo. Para tráfico con muchos sistemas prompts distintos y poca repetición intra-prefix, el hit rate ronda el 5–15 %.

Con prefix-aware routing, el router calcula un hash del prefijo del prompt (los primeros N tokens, o el system_prompt declarado en messages[0]) y mantiene una tabla de afinidad hash → réplica. Todas las requests con el mismo prefijo caen en la misma réplica. La primera paga el prefill completo; las 999 siguientes aciertan el cache. Hit rate global: 60–85 %.

El coste de implementarlo: el router debe parsear el body de la request (no solo el header HTTP), aplicar un tokenizer ligero o un hash basado en bytes, y mantener una tabla LRU/consistent-hash de afinidad que se rebalancea cuando una réplica entra o sale. Es trabajo de servidor, no de proxy genérico. vLLM Production Stack router lo implementa nativamente. NVIDIA Dynamo también. LiteLLM en su versión enterprise tiene un beta. Envoy AI Gateway lo está incorporando como filtro experimental.

La diferencia operativa para un RAG productivo: con prefix-aware routing, el mismo cluster sirve 2–4× más requests sin añadir GPUs, simplemente porque el prefill desaparece en la mayoría de los casos.

Token-aware load balancing

La segunda pieza no obvia. El round-robin clásico reparte por número de requests; pero un prompt de 50 tokens y otro de 8 000 tokens cuestan radicalmente distinto (factor ~160× en prefill). Repartir igualmente por count desequilibra severamente la carga real.

Token-aware load balancing suma tokens de prefill esperados (longitud del prompt) y decode esperados (max_tokens del cliente) por réplica activa, y manda la nueva request a la réplica con menor carga acumulada. Es lo que tanto vLLM Production Stack como NVIDIA Dynamo implementan como estrategia por defecto cuando se activa.

La métrica que alimenta el cálculo es —otra vez— vllm:num_requests_running y vllm:gpu_cache_usage_perc —ver Observabilidad GPU para inferencia LLM—, idealmente complementadas con un estimador de tokens del prompt entrante. Los routers maduros usan tiktoken o el tokenizer real del modelo para contar tokens del prompt antes de elegir réplica.

Comparativa de piezas concretas (mayo 2026)

Pieza	Awareness LLM	Prefix-aware	Token-aware LB	Multi-modelo	Semantic cache	Plug & play
LiteLLM Proxy	Alta	Beta (enterprise)	Sí	Excelente	Sí (Redis)	Muy alto
vLLM Production Stack router	Específico vLLM	Sí, nativo	Sí	Solo vLLM	No (externa)	Medio
NVIDIA Dynamo router	Alta + disagg-aware	Sí	Sí	vLLM/SGLang/TRT-LLM	No (externa)	Bajo
Envoy AI Gateway	Media (filtros)	Experimental	Sí	Sí	Vía filtro	Medio
Kong AI Gateway	Media (plugins)	No	Sí	Sí	Sí (plugin)	Medio
KGateway	Media	Roadmap	Sí	Sí	Roadmap	Bajo (CNCF gestación)
NGINX + custom Lua	Manual	No	Manual	Manual	No	Bajo (build it yourself)

LiteLLM Proxy es la opción por defecto para empezar. OpenAI-compatible, YAML simple, soporta los providers comerciales + cualquier OpenAI-compatible self-hosted. La versión OSS cubre las cuatro funciones básicas y semantic cache; el prefix-aware y la versión enterprise añaden multi-tenancy avanzado.

vLLM Production Stack router es la opción correcta si la flota es 100 % vLLM. Aware del KV cache, del prefix, del LoRA loaded por réplica. Integra mejor con métricas vLLM nativas.

NVIDIA Dynamo router es la opción production-grade más completa, especialmente si se opera disaggregated serving (prefill workers vs decode workers separados). Requiere stack NVIDIA-aligned.

Envoy AI Gateway y Kong AI Gateway son las opciones si la organización ya tiene Envoy/Kong como gateway corporativo y quiere extenderlo con LLM-awareness sin introducir otra pieza nueva.

Manifest mínimo: LiteLLM Proxy sobre cluster genérico

apiVersion: v1
kind: ConfigMap
metadata: { name: litellm-config, namespace: inference }
data:
 config.yaml: |
 model_list:
 - model_name: llama-70b
 litellm_params:
 model: openai/llama-70b
 api_base: http://vllm-llama70b-v1.inference.svc:8000/v1
 weight: 95
 model_info:
 version: v1
 lifecycle: stable
 - model_name: llama-70b
 litellm_params:
 model: openai/llama-70b
 api_base: http://vllm-llama70b-v2.inference.svc:8000/v1
 weight: 5
 model_info:
 version: v2
 lifecycle: canary
 - model_name: embedding-multilingual
 litellm_params:
 model: openai/bge-m3
 api_base: http://tei-bge-m3.inference.svc:8080
 router_settings:
 routing_strategy: least-busy # token-aware basic
 num_retries: 1
 timeout: 60
 general_settings:
 master_key: "os.environ/LITELLM_MASTER_KEY"
 database_url: "os.environ/DATABASE_URL"
 litellm_settings:
 cache: true
 cache_params:
 type: redis
 host: redis.inference.svc
 port: 6379
 similarity_threshold: 0.97
 success_callback: ["langfuse"]
 failure_callback: ["langfuse"]
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: litellm-router, namespace: inference }
spec:
 replicas: 3
 selector: { matchLabels: { app: litellm } }
 template:
 metadata: { labels: { app: litellm } }
 spec:
 containers:
 - name: litellm
 image: ghcr.io/berriai/litellm:v1.55.0
 args: ["--config=/config/config.yaml", "--port=4000", "--num_workers=4"]
 ports: [{ containerPort: 4000, name: http }, { containerPort: 4000, name: metrics }]
 env:
 - { name: LITELLM_MASTER_KEY, valueFrom: { secretKeyRef: { name: litellm-secret, key: master_key } } }
 - { name: DATABASE_URL, valueFrom: { secretKeyRef: { name: litellm-secret, key: db_url } } }
 - { name: LANGFUSE_PUBLIC_KEY, valueFrom: { secretKeyRef: { name: langfuse-keys, key: public } } }
 - { name: LANGFUSE_SECRET_KEY, valueFrom: { secretKeyRef: { name: langfuse-keys, key: secret } } }
 volumeMounts: [{ name: config, mountPath: /config }]
 readinessProbe: { httpGet: { path: /health, port: 4000 } }
 volumes: [{ name: config, configMap: { name: litellm-config } }]
---
apiVersion: v1
kind: Service
metadata: { name: litellm-router, namespace: inference }
spec:
 selector: { app: litellm }
 ports: [{ name: http, port: 80, targetPort: 4000 }]
---
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata: { name: litellm-metrics, namespace: inference }
spec:
 selector: { matchLabels: { app: litellm } }
 podMetricsEndpoints:
 - port: metrics
 path: /metrics
 interval: 15s

El cliente final apunta a litellm-router.inference.svc:80/v1/chat/completions, pone model=llama-70b, y el router decide en cada request si va a v1 (95 %) o v2 (5 %), aplica el rate limit, busca en semantic cache, propaga tracing a Langfuse, y traduce de OpenAI-compatible a OpenAI-compatible del vLLM de destino. Tres réplicas del router para HA y para que el propio gateway escale horizontalmente con KEDA si hace falta —ver Autoscaling LLM en Kubernetes—.

Cuatro pitfalls operacionales

Pitfall 1 — el router se convierte en SPoF si no se replica. Tres o más réplicas del propio router, detrás de un Service LoadBalancer (este sí, L4) con healthchecks. Una sola réplica del router significa que cada deploy de la configuración cierra el servicio entero unos segundos.

Pitfall 2 — la latencia del router se suma a la del modelo. Cada función añade milisegundos: parsing del body (5–10 ms), auth JWT (2–5 ms), rate limit (1–2 ms), redact PII con Presidio (20–80 ms), guardrails con Llama Guard inline (50–150 ms), prefix hash (5–10 ms), token counting con tokenizer (10–30 ms). En total 100–300 ms de overhead antes de tocar el motor. Si el TTFT del modelo es 400 ms y el del router 200 ms, el cliente ve 600 ms — vale la pena medir cuánto cuesta cada función y desactivar las no críticas en el path de baja latencia.

Pitfall 3 — el catálogo deriva del estado real del cluster. El router cree que vllm-llama70b-v2 existe porque está en su YAML, pero el deployment fue retirado hace tres días y nadie actualizó el config. El router devuelve 502 en el 5 % del tráfico. Solución: validar el catálogo contra kubectl get svc en CI; ningún endpoint del catálogo puede apuntar a un Service inexistente. O mejor: el router descubre dinámicamente los endpoints disponibles vía label selector (app=vllm,model=llama-70b) y aplica weights del catálogo sobre los que están vivos.

Pitfall 4 — semantic cache con embedding outdated. El semantic cache compara embedding del prompt nuevo contra embeddings de prompts cacheados. Si actualizas el modelo de embeddings (ver RAG corpus curation), las distancias se calculan en un espacio distinto y el cache deja de funcionar correctamente (falsos hits o falsos misses). Política: el cache se invalida al cambiar el modelo de embeddings; nunca se mezclan generaciones.

Encaje en el stack y la madurez

En el stack de siete capas, el router es la capa 1: la puerta de entrada que precede al motor de inferencia (capa 2), al KV cache + PagedAttention (capa 3) y al resto. Es la única pieza que ve todo el tráfico desde fuera; cualquier política que no se aplique aquí, se duplica N veces en los motores.

En los cinco niveles de madurez, el router aparece a partir del nivel 3 (GESTIONADO): sin OIDC + RBAC + cert-manager + NetworkPolicy default deny, el router no tiene a quien autenticar ni a quien aplicar quotas; antes del nivel 3 lo que toca es montar un proxy mínimo sin pretensión de catálogo. Plataformas que intentan tener router pulido en nivel 1 acaban con un yaml grande que nadie mantiene.

En las siete fases de despliegue, el router es lo que cierra F6: el último paso atómico que pone al cluster en producción. Sin router, F6 no termina — el catálogo, las quotas, los canaries y los failovers son condición necesaria para abrir tráfico productivo.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4 nodos × 4×H100 SXM 80 GB, el router de inferencia consume recursos modestos: 3 réplicas del router-pod (CPU 2 cores, memoria 4 GiB cada una) bastan para soportar miles de RPS porque su trabajo es ligero (parsing, hashing, routing, no inferencia). El router vive en nodos no-GPU del cluster (nodos de control plane o de workload general), nunca consume nvidia.com/gpu.

Volumen de tráfico que un LiteLLM con 3 réplicas y 4 workers cada una sostiene: 2 000–5 000 RPS routing a backend vLLM, con overhead de 80–150 ms en path completo (auth + rate limit + cache check + propagación). Si se necesita más, escalar el router con KEDA sobre litellm:requests_per_second es trivial.

Para clusters más grandes (16+ nodos GPU), considerar vLLM Production Stack router o NVIDIA Dynamo router que son más complejos pero exprimen el prefix-aware routing y el token-aware LB que LiteLLM OSS no cubre. Para clusters multi-region, Envoy AI Gateway con Istio Service Mesh es la elección estándar.

Lo que no hemos cubierto (próximos artículos)

Comparativa profunda LiteLLM vs vLLM PStack vs Dynamo con benchmarks de prefix-aware sobre cluster on-premise real.
Semantic cache con Redis Stack + RedisVL: hit rate, falsos positivos, política de TTL.
Multi-region routing: cómo el router decide entre clúster DC1 y DC2 según latencia, salud y carga.
AI Gateway specific features: token-bucket cost-based rate limiting (penaliza prompts largos), guardrails policy engine en el router.
Migration path: cómo introducir un router en un cluster que ya tiene clientes apuntando directo al servicio vLLM, sin downtime.

Ver también

Canary, blue-green y shadow para modelos LLM — el post anterior donde llamamos “LoadBalancer” a esta pieza; este post la nombra y la desmonta.
Siete capas del stack de inferencia LLM on-premise — el router es la capa 1 del stack.
Cinco niveles de madurez — el router aparece a partir del nivel 3.
Siete fases de despliegue — el router es lo que cierra F6.
Autoscaling LLM en Kubernetes — el router puede escalar con KEDA sobre sus propias métricas; convive con el autoscaling de los motores.
Observabilidad GPU para inferencia LLM — el token-aware LB consume vllm:num_requests_running y vllm:gpu_cache_usage_perc para decidir réplica.
KV cache — qué cachea el prefix-aware routing y por qué multiplica el hit rate.
Disaggregated serving prefill/decode — los routers production-grade (Dynamo) son aware de la disaggregation y rutean prefill y decode a pools distintos.
Tracing LLM con OpenTelemetry GenAI — el router emite los spans padre gen_ai.* y propaga traceparent a los motores.
Guardrails y safety en LLMs — los guardrails ligeros inline se ejecutan típicamente en el router.
Entornos mixtos NVIDIA + Intel para inferencia LLM — el router por capability cobra todo su sentido cuando hay backends heterogéneos (NVIDIA para LLM grande, Intel para embeddings/reranker, NUC para edge); el catálogo se extiende con backend y region.

Referencias

LiteLLM project — litellm.ai (documentación de Proxy, routing strategies, semantic cache).
vLLM Production Stack — github.com/vllm-project/production-stack (router con prefix-aware nativo).
NVIDIA Dynamo — developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/ (router production-grade con disaggregated-aware).
Envoy AI Gateway — gateway.envoyproxy.io/docs/tasks/ai-gateway/ (proyecto en gestación dentro de Envoy).
Kong AI Gateway — konghq.com/products/kong-ai-gateway (proxy enterprise con plugin LLM).
KGateway — kgateway.dev (alternativa CNCF en gestación).
Zheng et al. — SGLang: Efficient Execution of Structured Language Model Programs (NeurIPS 2024) — RadixAttention y prefix caching.
vLLM project — Automatic Prefix Caching (docs.vllm.ai/en/latest/features/automatic_prefix_caching.html).
Patel et al. — SplitWise: Efficient Generative LLM Inference Using Phase Splitting (ISCA 2024) — base teórica del routing prefill/decode aware.

Canary, blue-green y shadow para modelos LLM: cómo desplegar una versión nueva sin tirar el SLO

Mon, 01 Jun 2026 16:30:00 +0200

Este post complementa los de Autoscaling LLM en Kubernetes (el autoscaler convive con el rollout y debe respetarlo), Observabilidad GPU para inferencia LLM (las métricas que actúan como gate vienen de ahí), Evals para LLMs (la eval que decide si el nuevo modelo está listo), LLM-as-judge (la técnica que pone el “quality” en el gate de canary) y Retrain: cerrar el bucle (el step previo del que sale el modelo nuevo).

TL;DR

Promocionar una versión nueva de un modelo LLM al cluster productivo sin cortar tráfico ni romper SLO exige despliegue progresivo. Las tres estrategias canónicas —blue-green, canary, shadow— responden a preguntas distintas y tienen costes distintos. Blue-green: pool completo nuevo levantado en paralelo, conmutación atómica del load balancer. Rollback instantáneo (volver a apuntar al pool viejo); exige el doble de GPUs durante la ventana. Canary: el tráfico se reparte progresivamente entre la versión vieja y la nueva (1 % → 5 % → 25 % → 100 %), midiendo en cada salto gates de regresión; consume incrementalmente menos hardware pero expone usuarios reales al modelo nuevo desde el primer porcentaje. Shadow / mirror: el viejo modelo sirve el 100 % del tráfico real al cliente y, en paralelo, una copia de cada request va al nuevo modelo sin devolver su respuesta al usuario; aísla del riesgo de calidad pero gasta GPU del nuevo en respuestas que nadie consume, y no funciona bien con streaming SSE largo. La elección depende de tres factores: presupuesto GPU disponible, criticidad del servicio y disponibilidad de eval automática rápida. Las cinco métricas de regresión que cualquier canary LLM gatear son: TTFT P95, error rate (HTTP 5xx + finish_reason="length" prematuro), quality score con LLM-as-judge sobre golden set, drift estadístico de embeddings de output (Wasserstein o KL contra distribución del baseline) y coste por request (tokens/s y kW/request). En Kubernetes, Argo Rollouts gestiona el tráfico y los AnalysisTemplate como gates automáticos; Flagger es la alternativa más opinionada. vLLM v1 no soporta hot model swap robusto a mayo 2026, así que la unidad de rollout es la réplica entera (deployment v2 al lado de deployment v1). Los tres pitfalls específicos: sticky sessions del LB rompen la comparabilidad estadística del canary (un cliente A siempre cae al nuevo, B al viejo — las poblaciones no son equivalentes); eval semántica con LLM-as-judge tarda 2–8 segundos por sample y no sirve como gate en tiempo real (se usa en post-análisis o offline pre-promoción); el streaming SSE complica el shadow porque hay que descartar la respuesta del nuevo modelo sin afectar a la del viejo. Este post incluye un manifest Argo Rollouts mínimo aplicable a un cluster genérico con NVIDIA GPU Operator.

Estás aquí: DEPLOY (y la transición a RETRAIN)

Un modelo nuevo no aparece por arte de magia en el cluster: viene del bucle de retrain o de una actualización del proveedor de pesos. El paso entre “tengo un artefacto que pasó eval offline” y “está sirviendo el 100 % del tráfico” es exactamente este post.

La analogía: el estreno de una obra en teatro

Una compañía de teatro va a estrenar una nueva versión de una obra que lleva un año en cartel con éxito. La compañía sabe varias cosas duras: el público actual paga por una experiencia consistente; un mal estreno daña el negocio durante meses; pero no estrenar nada deja a la compañía obsoleta frente a la competencia.

Las tres rutas de estreno que la dirección puede elegir son las mismas tres del rollout LLM.

Ensayo general a puerta cerrada (shadow / mirror). Los actores nuevos representan la obra entera ante un teatro vacío. No hay público; nadie compra entrada. Tres pases enteros sirven para comprobar continuidad, tiempos y química del reparto. Es caro porque hay sueldos y alquiler del teatro, pero no expone al público al riesgo. Útil cuando el reparto nuevo está sin probar y el director quiere ver cómo aguanta una función completa antes de venderla. En LLM: el modelo nuevo procesa cada request real en paralelo al viejo pero sus respuestas se descartan; gastas GPU del nuevo en respuestas que nadie ve.

Reparto por funciones, alternando (canary). En lugar de cambiar todo el reparto de golpe, las funciones de jueves son del reparto nuevo, las del viernes del viejo, las de sábado mitad y mitad. La dirección lee los comentarios del libro de visitas y la afluencia de público función a función, decidiendo al cabo de dos semanas si promociona el reparto nuevo a titular o lo retira. Más barato que el ensayo general porque las funciones venden entrada igual, pero expone público real al riesgo desde el primer jueves. En LLM: el tráfico se reparte progresivamente entre la versión vieja y la nueva, midiendo gates en cada salto.

Doble compañía con cambio atómico (blue-green). La compañía contrata el reparto nuevo, lo prepara durante un mes a puerta cerrada, y un sábado anuncia: “a partir del próximo estreno todas las funciones son con el reparto nuevo”. Si la primera función va mal, se vuelve al reparto viejo en 24 horas — pero durante ese mes de preparación se paga doble sueldo a las dos compañías. En LLM: dos pools completos del mismo tamaño, conmutación instantánea del LB de uno a otro, rollback en segundos si las métricas se rompen.

La analogía sostiene también la decisión: la elección depende de cuán crítica sea la obra para el negocio (criticidad del servicio LLM), cuánto presupuesto hay para sostener dos repartos a la vez (presupuesto GPU), y cuánta confianza se tiene en el nuevo reparto a partir de los ensayos de cámara (eval offline previa al canary).

Las tres estrategias en detalle

Blue-green

El operador mantiene dos pools de réplicas idénticos en tamaño: el azul (versión productiva v1) y el verde (versión candidata v2). Cuando v2 está validado offline (eval pasada, smoke tests), el switch del LoadBalancer redirige el 100 % del tráfico de azul a verde en un solo paso. Si las métricas del SLO se rompen, el switch vuelve atrás en segundos.

Coste: 2× GPUs durante toda la ventana (preparación de v2 + ventana de observación post-switch). Para un cluster de 16 GPUs sirviendo Llama 70B con TP=4 (4 réplicas), preparar el blue-green requiere 16 GPUs adicionales durante 1–3 días.

Riesgo: el switch es atómico — si v2 tiene un problema que no apareció en eval offline pero sí aparece a escala (por ejemplo, edge cases que solo se ven a 200 RPS), el 100 % de usuarios lo nota a la vez. El rollback es instantáneo, pero las requests del primer minuto post-switch ya se vieron afectadas. Por tanto blue-green es preferible cuando se tiene alta confianza en v2 (cambio menor: misma arquitectura, mismo formato, solo nueva versión de pesos) y se prioriza rollback inmediato sobre exposición gradual.

Canary

El operador despliega v2 con un número pequeño de réplicas (típicamente 1) junto al pool de v1. El LoadBalancer reparte progresivamente el tráfico siguiendo un cronograma: 1 % durante 30 minutos → 5 % durante 1 hora → 25 % durante 2 horas → 50 % durante 4 horas → 100 %. Entre cada salto, un gate de análisis evalúa métricas de regresión sobre el tráfico que ya está cayendo en v2. Si el gate falla, el rollback retira el tráfico de v2 automáticamente y deja v1 sirviendo todo.

Coste: incremental. Al inicio (1 % de tráfico) basta una réplica v2; al 50 % se necesita la mitad de réplicas v2 que el total de v1. Pico de GPU adicional durante el canary: ~30–50 % por encima del baseline.

Riesgo: usuarios reales están viendo v2 desde el primer 1 %. Si v2 produce respuestas con calidad degradada pero TTFT y error rate normales, los usuarios afectados perciben la degradación sin que el gate la detecte (a menos que el gate incluya quality drift, que tarda). Por tanto canary es preferible cuando se tiene confianza media en v2 (cambio significativo: arquitectura o entrenamiento distinto) y se acepta que un % bajo de usuarios sea conejillo.

Shadow / mirror

El LoadBalancer envía el 100 % del tráfico real a v1 (que responde al cliente) y duplica cada request hacia v2 (cuya respuesta se descarta o se guarda para análisis offline). El cliente nunca ve v2; nunca está expuesto al riesgo.

Coste: 100 % adicional del compute de v2 sin valor de usuario directo durante toda la ventana de shadow. Para un cluster de 16 GPUs sirviendo Llama 70B con TP=4 (4 réplicas), un shadow del mismo tamaño consume 16 GPUs adicionales a tiempo completo.

Riesgo: el shadow es el más seguro para el usuario. Pero tiene dos limitaciones serias: (a) si v2 tiene un cuello de botella que causa que la copia de request al shadow tarde mucho, el proxy de shadowing puede consumir conexiones del LB; debe estar out-of-band (asíncrono); (b) el streaming SSE largo complica la mirroring porque hay que mantener dos streams paralelos y descartar uno mientras el otro fluye al cliente. Patrón habitual: shadow solo de requests no-streaming (completiones cortas, classification), eval offline manual de las requests con streaming.

Las cinco métricas de regresión que actúan como gate

Sin gates automáticos, el “canary” es solo un nombre bonito para “rollout manual con un porcentaje variable”. Los gates son la pieza que convierte el canary en una operación defendible.

Métrica 1 — TTFT P95. Comparación P95 del nuevo modelo contra P95 del baseline (v1) en ventanas de 5 minutos. Gate: ttft_p95(v2) / ttft_p95(v1) < 1.10. Detecta regresiones de latencia de prefill (modelo nuevo más lento) o problemas de motor (config subóptima). Fuente: vllm:time_to_first_token_seconds_bucket —ver Observabilidad GPU para inferencia LLM—.

Métrica 2 — Error rate. Suma de HTTP 5xx + 4xx no esperados + tasa de finish_reason="length" prematuro (respuestas cortadas porque el modelo nuevo no genera EOS). Gate: error_rate(v2) - error_rate(v1) < 0.01 (1 punto porcentual). Detecta crashes del motor, tokenizer roto, problemas de generación. Fuente: vllm:request_success_total{status=...}.

Métrica 3 — Quality score (LLM-as-judge). Sobre un golden set de 200–1 000 prompts representativos, se ejecutan v1 y v2 offline y un modelo juez (típicamente más grande: GPT-4 class, Claude, Llama 405B local) puntúa cada par. Gate típico: mean_score(v2) >= mean_score(v1) - 0.05. Esta métrica no se mide en tiempo real durante el canary — la inferencia del juez tarda 2–8 segundos por sample y no escala como gate inline. Se usa como gate offline pre-promoción (antes de empezar el canary) y como post-mortem sobre muestra de tráfico real capturado durante el canary. Ver LLM-as-judge para la mecánica.

Métrica 4 — Drift estadístico de output. Para cada request que cae en v2 durante el canary, embeber la respuesta con un modelo de embedding ligero (e5, BGE) y comparar la distribución de embeddings de v2 contra la distribución del baseline v1 sobre la misma ventana. Métricas usables: Wasserstein distance, divergencia KL, o más simple, comparar medias y varianzas por dimensión. Gate: distancia normalizada < umbral calibrado (típicamente Wasserstein < 0.15). Detecta cambios sutiles en estilo, longitud, vocabulario que LLM-as-judge no captura sin pasar también por él. Es rápida: el embedding ligero tarda ~50 ms por respuesta.

Métrica 5 — Coste por request. Tokens out / request y kW / request. Gate: cost_per_request(v2) / cost_per_request(v1) < 1.20. Detecta modelos nuevos que generan respuestas significativamente más largas o que consumen más energía por la misma carga (degradación de quantization, fallo de optimizations). Sin este gate, una “actualización” puede duplicar la factura silenciosamente.

Métrica	Tipo	Latencia de medida	Gate típico	Detección
TTFT P95	Cuantitativa	5 min	`< 110% baseline`	Regresión de latencia
Error rate	Cuantitativa	1 min	`< 1pp sobre baseline`	Crashes, generation broken
Quality (LLM-judge)	Semántica offline	horas, sobre golden	`> baseline − 0.05`	Calidad funcional
Drift estadístico	Estadística	~5 min	Wasserstein < 0.15	Estilo, longitud, vocabulario
Coste por request	Cuantitativa	5 min	`< 120% baseline`	Eficiencia económica/energética

La mecánica en Kubernetes: Argo Rollouts

Argo Rollouts extiende el Deployment estándar de Kubernetes con un nuevo recurso Rollout que orquesta la progresión del tráfico y los análisis automáticos. Se integra con cualquier service mesh (Istio, Linkerd) o controlador de ingress que soporte traffic splitting (NGINX, Traefik, Gateway API).

Ejemplo mínimo de canary 1 → 5 → 25 → 100 % con gates de TTFT y error rate:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: { name: vllm-llama70b }
spec:
 replicas: 4
 strategy:
 canary:
 canaryService: vllm-llama70b-canary
 stableService: vllm-llama70b-stable
 trafficRouting:
 nginx:
 stableIngress: vllm-llama70b-ingress
 steps:
 - setWeight: 1
 - pause: { duration: 30m }
 - analysis: { templates: [{ templateName: ttft-error-gate }] }
 - setWeight: 5
 - pause: { duration: 1h }
 - analysis: { templates: [{ templateName: ttft-error-gate }] }
 - setWeight: 25
 - pause: { duration: 2h }
 - analysis: { templates: [{ templateName: ttft-error-gate }, { templateName: drift-gate }] }
 - setWeight: 50
 - pause: { duration: 4h }
 - analysis: { templates: [{ templateName: ttft-error-gate }, { templateName: drift-gate }] }
 - setWeight: 100
 selector: { matchLabels: { app: vllm-llama70b } }
 template:
 metadata: { labels: { app: vllm-llama70b } }
 spec:
 containers:
 - name: vllm
 image: vllm/vllm-openai:v0.10.0
 args: [ --model=/models/llama-70b-fp8-v2 ]  # versión nueva
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata: { name: ttft-error-gate }
spec:
 metrics:
 - name: ttft-p95-ratio
 interval: 1m
 count: 5
 failureLimit: 1
 successCondition: result < 1.10
 provider:
 prometheus:
 address: http://prometheus.observability.svc:9090
 query: |
 histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{version="v2"}[5m])))
 /
 histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{version="v1"}[5m])))
 - name: error-rate-diff
 interval: 1m
 count: 5
 failureLimit: 1
 successCondition: result < 0.01
 provider:
 prometheus:
 address: http://prometheus.observability.svc:9090
 query: |
 sum(rate(vllm:request_total{version="v2",status=~"5.."}[5m])) / sum(rate(vllm:request_total{version="v2"}[5m]))
 -
 sum(rate(vllm:request_total{version="v1",status=~"5.."}[5m])) / sum(rate(vllm:request_total{version="v1"}[5m]))

Si cualquiera de los AnalysisTemplate falla, Argo Rollouts retrocede automáticamente: pone weight=0 en el canary, alerta al operador, mantiene v1 sirviendo el 100 %. La operación humana se reduce a investigar el fallo y decidir si re-lanzar o abortar.

Flagger ofrece una alternativa más opinionada: la progresión del weight es automática en función del éxito de las métricas en vez de pausa fija; el operador define un objetivo (maxWeight: 100, stepWeight: 10, metrics: [...]) y Flagger sube o baja según comportamiento. Ambas son maduras en mayo 2026; la elección suele venir dictada por qué service mesh ya está en el cluster.

El detalle de vLLM: por qué no se hace “hot swap” del modelo

A mayo 2026, vLLM v1 no soporta cambio caliente del modelo dentro de la misma réplica sin reiniciar el motor. El comando --model se evalúa al arranque; cambiarlo requiere re-instanciar el LLMEngine, lo que reinicia conexiones y descarta el KV cache. Por tanto la unidad de rollout es la réplica entera: no se hace “v1 carga el modelo nuevo en una de sus GPUs” sino “se levanta una réplica v2 al lado de una réplica v1 y se reparte tráfico vía LB”.

TensorRT-LLM con Triton tiene un mecanismo similar: cambiar el modelo exige reload del backend Triton. SGLang tampoco soporta hot swap robusto. La consecuencia operativa: el rollout LLM siempre va a costar GPUs adicionales durante la ventana, y la elección entre blue-green, canary y shadow es exactamente la pregunta de cuántas adicionales y cuánto tiempo.

Los tres pitfalls específicos del rollout LLM

Pitfall 1 — sticky sessions rompen la comparabilidad del canary. Si el LoadBalancer hace session affinity por IP del cliente (común en NGINX, Traefik con loadbalancer.kubernetes.io/session-affinity: ClientIP), un usuario A siempre cae en v2 mientras B siempre cae en v1. Las distribuciones de carga, perfiles de prompt y comportamiento de cliente no son aleatorias entre los dos pools, lo que invalida estadísticamente cualquier comparación de gates. Solución: para canary, desactivar session affinity (sessionAffinity: None) o usar affinity por request-id aleatorio. Si la app cliente exige sticky por funcionalidad (memoria conversacional persistida en cache), el canary no es la estrategia adecuada — usar blue-green o shadow.

Pitfall 2 — LLM-as-judge no es gate inline en tiempo real. La tentación de usar quality score como gate live es alta, pero la latencia del juez (2–8 s por sample) hace inviable evaluar más que un sampling del 1–2 % del tráfico, y los resultados llegan con minutos de retraso. Soluciones operativas: (a) eval offline pre-canary sobre golden set como pre-requisito para arrancar (si falla, ni se inicia el canary); (b) durante el canary, capturar requests + responses de v2 a tiempo real y correr el juez asíncrono en un job batch que termina antes del siguiente salto; (c) usar drift estadístico de embeddings como proxy rápido de calidad inline, y reservar el juez para gates intermedios entre saltos.

Pitfall 3 — streaming SSE complica el shadow. El mirror de tráfico clásico (NGINX mirror, Istio MirrorPolicy) está pensado para HTTP de request/response — copia la request, deja al servidor primario responder al cliente, y duplica la request al secundario descartando la respuesta. Con SSE, la respuesta del secundario es un stream continuo de varios segundos, y mantener dos streams en paralelo carga doblemente al proxy. Soluciones: (a) shadow solo de requests no-streaming (chat sin stream, embeddings, classification, batch eval), (b) shadow del tráfico streaming pero con timeout corto en el secundario (descartar el shadow si tarda más de 30 s), (c) reemplazar el shadow por canary con weight pequeño (1 %) que sí soporta streaming bien.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4 nodos × 4×H100 SXM 80 GB = 16 GPUs, sirviendo Llama 70B FP8 con TP=4 (4 réplicas posibles, una por nodo):

Blue-green: imposible mantener dos pools completos de 4 réplicas sin GPUs adicionales. Solución práctica: blue-green con pools reducidos (2 réplicas v1 + 2 réplicas v2) durante la ventana, degradación de capacidad aceptada (mitad del SLO de RPS sostenido), o disponer de un cluster paralelo (otro nodo) reservado para rollouts.
Canary: factible. Empezar con 3 réplicas v1 + 1 réplica v2 (25 % weight nominal pero también peso variable de tráfico). Avanzar a 2 v1 + 2 v2 al 50 %, luego 1 v1 + 3 v2, finalmente 0 v1 + 4 v2.
Shadow: complicado por el coste de GPU. Reservar para validación pre-canary de cambios mayores, durante una ventana corta (4–8 horas) con tráfico shadowed limitado a una muestra (10–20 % de requests, no 100 %).

Para clusters de 8 nodos GPU, los tres patrones son sostenibles. La regla operativa: el presupuesto de rollout es típicamente el 25–30 % de la capacidad sostenida del cluster — comprar para el pico + ese head-room cuadra los números del capacity planning.

Lo que no hemos cubierto (próximos artículos)

Rollouts multi-region: cómo coordinar canary cuando el cluster está distribuido geográficamente.
A/B testing de prompts (no de modelos): el mismo modelo con dos system prompts distintos, medir conversion.
Rollback de embeddings: cambiar el modelo de embeddings de un sistema RAG implica re-embedir todo el corpus — la mecánica de canary es distinta. Ver RAG corpus curation.
Feature flags para LLM: granularidad por tenant o por feature dentro del mismo modelo.
Continuous deployment end-to-end: integración con el retrain pipeline para que un nuevo adapter se promocione automáticamente tras pasar evals.

Ver también

Autoscaling LLM en Kubernetes — el autoscaler convive con el canary y debe respetar las particiones de tráfico.
Observabilidad GPU para inferencia LLM — las métricas que actúan como gate vienen de aquí.
Capacity planning — define el head-room necesario para rollouts.
Evals para LLMs — la eval offline que valida v2 antes de empezar el canary.
LLM-as-judge — la técnica de quality score como gate offline.
Retrain: cerrar el bucle — de donde sale el modelo nuevo que entra al canary.
Cinco niveles de madurez — Argo Rollouts es pieza del nivel 4–5.
El router de inferencia LLM — la pieza que en este post llamamos “LoadBalancer” desmontada como capa de pleno derecho: catálogo de modelos, traffic splitting L7, política transversal, failover y prefix-aware routing. El reparto 1 % → 5 % → 25 % → 100 % se materializa allí.
Runbooks de incident response para LLM con Keep + Kafka — el rollback automático del canary cuando ttft_p95(v2)/ttft_p95(v1) > 1.30 es el runbook RB-06; allí está el workflow Keep YAML completo y el encaje en compliance.

Referencias

Argo Rollouts project — argoproj.io/argo-rollouts (CRD Rollout y AnalysisTemplate).
Flagger project — fluxcd.io/flagger (alternativa con progresión automática).
Istio — Traffic Mirroring (mirror configurable a nivel VirtualService).
NGINX Ingress — Canary annotations (nginx.ingress.kubernetes.io/canary-*).
vLLM project — issue tracker sobre hot model swap (estado a mayo 2026: en diseño, no production-ready).
Hou et al. — DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving (OSDI 2024) — referencia sobre métricas de goodput aplicables a gates de canary.
Bürkner et al. — Statistical methods for detecting model drift in production (artículos varios sobre Wasserstein y KL en monitoring ML).

Autoscaling de inferencia LLM en Kubernetes: HPA con custom metrics y KEDA para vLLM

Mon, 01 Jun 2026 16:00:00 +0200

Este post complementa los de Observabilidad GPU para inferencia LLM (de donde vienen las métricas que alimentan al HPA), Capacity planning (qué techo y qué head-room presupone el autoscaler) y Continuous batching (lo que explica por qué num_requests_waiting es la métrica primaria).

TL;DR

El autoscaling clásico de Kubernetes —HPA sobre cpu o memory— no sirve para inferencia LLM. Razón: el pod vLLM consume poco CPU (el trabajo lo hace la GPU) y la memoria RSS del proceso es plana; ambas métricas pueden quedarse al 30 % mientras la GPU está saturada y la cola de requests crece sin freno. Las cuatro señales viables que sí responden a la carga real son: vllm:num_requests_waiting (la cola, la métrica primaria), vllm:gpu_cache_usage_perc (presión sobre el KV cache pool), TTFT P95 vía histogram de vllm:time_to_first_token_seconds_bucket (la garantía del SLO) y el batch fill ratio num_requests_running / max_num_seqs (utilización del techo de concurrencia). Para que un HPA pueda consumir métricas Prometheus hace falta un adaptador; en mayo 2026 hay dos opciones maduras: prometheus-adapter (sigma de cluster, configuración estática, output external.metrics.k8s.io) y KEDA (ScaledObject con trigger Prometheus, polling configurable, escalado a cero opcional, integración con cron). KEDA es la opción dominante para LLM en cluster genérico porque resuelve el patrón “warm pool + cron + métrica del motor” en un solo CRD. El reto operacional dominante no es la lógica de escalado sino el cold start: un pod vLLM con Llama 70B BF16 (140 GB) tarda entre 90 segundos (modelo precacheado en PV local) y 6 minutos (image pull + descarga del modelo desde object store) hasta servir el primer token. Las cinco palancas que lo recortan son imagen pre-pulled vía DaemonSet, modelo cacheado en PV o tmpfs regional, warm pool con minReplicaCount > 0, predictive scaling vía KEDA cron cuando el patrón de tráfico es predecible (oficinas 9–18 h), y descarga paralela del modelo. Los tres pitfalls específicos del scale-down LLM: cortar conexiones SSE de streaming a media respuesta (drain elegante con terminationGracePeriodSeconds ≥ 60 s), oscilación de scale-out/in por stabilization window mal calibrada, y olvidar que el HPA solo escala pods — los nodos GPU se escalan con cluster-autoscaler sobre nodepools etiquetados. Este post incluye los manifests YAML mínimos.

Estás aquí: DEPLOY

La analogía: la panadería con hornos de leña

Una panadería artesanal tiene tres hornos de leña. Cada horno tarda 25 minutos en alcanzar temperatura desde frío. Una vez caliente, hornea pan continuamente con una tirada de 18 minutos por hornada. La encargada quiere maximizar pan vendido por día sin gastar leña inútil, y sabe tres cosas: que hay un pico de demanda a las 7:30 cada mañana, que los lunes no se vende casi nada, y que cuando se acaba el pan en mostrador los clientes se van al supermercado de al lado.

La estrategia barata —encender hornos cuando hay cola en la tienda— no funciona. Para cuando la cola crece y la encargada enciende el segundo horno, ese horno no estará listo hasta 25 minutos después; los clientes de esa ventana se perdieron. La señal “cola en mostrador” llega tarde.

La estrategia inteligente: encender el segundo horno a las 6:55, antes del pico previsible de las 7:30, y dejarlo activo hasta las 10:00 aunque la cola baje a las 8:15. Mantener el tercer horno apagado entre lunes y miércoles porque la demanda no llega; encenderlo proactivamente los jueves a las 12:00 porque históricamente sube. Tener una bolsa de masa cruda pre-fermentada en cámara para que cuando el horno esté listo, el pan entre en 30 segundos y no haya que esperar dos horas de fermentación.

El autoscaling de un cluster de inferencia LLM funciona igual:

Encender hornos en frío = scale-out reactivo cuando la cola crece (lento, pierde clientes).
Cron proactivo = predictive scaling cuando el patrón es conocido (horario laboral, picos previstos).
Masa pre-fermentada = warm pool de réplicas con modelo cargado pero a 0 carga.
Apagar hornos sin pan en curso = scale-down respetando las streamings activas (no se cierra el horno con pan dentro).

La métrica clave —“cuántos clientes hay en cola”— se llama num_requests_waiting. La métrica que dice “el horno se va a quedar sin masa para nuevos panes” se llama gpu_cache_usage_perc. Y la métrica de calidad de servicio —“cuánto tarda el primer pan en salir cuando un cliente nuevo entra”— se llama TTFT.

Por qué HPA sobre CPU no sirve

El HPA clásico de Kubernetes mira resource.cpu del pod. Para un servicio HTTP convencional —Node.js, una API REST— la CPU se mueve linealmente con el tráfico y el HPA escala con razonable acierto. Para un pod vLLM o SGLang sobre GPU, la CPU del pod típicamente vive entre 5 % y 15 % independientemente de si la GPU está al 30 % o al 99 % de carga: el trabajo real lo hace el dispositivo, no el proceso. Resultado: el HPA basado en CPU nunca dispara scale-out aunque la GPU esté reventando, y los clientes acumulan en la cola hasta que TTFT P95 cruza el SLO. El operador descubre el problema por la alerta de TTFT, no por el HPA.

memory tampoco sirve: la RSS del proceso vLLM es plana después del arranque (modelo + buffers cargados de una vez); no refleja la presión real sobre la GPU. Lo único que crece y baja con la carga útil de inferencia son métricas que el motor publica explícitamente: cola de requests, KV cache pool, latencias del SLO. Sin un adaptador que las haga visibles al HPA, el autoscaling es ciego.

Las cuatro señales viables

Señal 1 — vllm:num_requests_waiting (cola). Es la métrica más directa: cuántas requests esperan entrar al batch. Reacciona en el instante en que la concurrencia objetivo se satura. Es robusta frente a cambios de modelo (el número de requests es el mismo concepto sea Llama 7B o 70B). Es la métrica primaria del HPA LLM. Umbral típico: target = 5 requests waiting de media; si la cola crece por encima de 5 sostenido durante 2 minutos, scale-out.

Señal 2 — vllm:gpu_cache_usage_perc (KV pool). Se mueve antes que la cola: el KV pool se va llenando mientras los slots del batch aún están libres, hasta que el motor empieza a rechazar nuevas requests por OOM-prevention y se forma la cola. Por tanto es predictiva: dispara scale-out antes de que el cliente note degradación. Umbral típico: target = 0.85 (85 % de pool usado).

Señal 3 — TTFT P95. La garantía contractual. Si TTFT P95 sale del SLO, scale-out aunque cola y KV pool parezcan razonables (puede haber un pico de prompts largos). Es reactiva —sale del SLO antes de que tu HPA reaccione— pero sirve de guardrail final.

Señal 4 — batch fill ratio. El cociente num_requests_running / max_num_seqs (este último es config del motor, no métrica). Útil para scale-down: si el ratio queda por debajo de 0.4 durante 10 minutos, sobra capacidad y se puede reducir réplicas con seguridad.

La política recomendada combina las cuatro: la cola y el KV pool disparan scale-out (lo que llegue antes), TTFT lo confirma como guardrail, y el batch fill ratio gestiona scale-down. Implementarlo en un único HPA exige métricas externas; KEDA hace esto manejable.

El cableado: KEDA como adaptador Prometheus

KEDA introduce dos CRDs principales: TriggerAuthentication (cómo autenticarse contra la fuente) y ScaledObject (qué deployment escalar con qué triggers). Para un deployment vLLM con Prometheus como fuente:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: vllm-llama70b-scaler
 namespace: inference
spec:
 scaleTargetRef:
 name: vllm-llama70b
 minReplicaCount: 2 # warm pool
 maxReplicaCount: 20
 pollingInterval: 15
 cooldownPeriod: 300 # 5 min antes de scale-down
 advanced:
 horizontalPodAutoscalerConfig:
 behavior:
 scaleDown:
 stabilizationWindowSeconds: 600 # ventana grande para evitar oscilación
 policies:
 - type: Pods
 value: 1
 periodSeconds: 120
 scaleUp:
 stabilizationWindowSeconds: 30
 policies:
 - type: Pods
 value: 2
 periodSeconds: 60
 triggers:
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.observability.svc:9090
 metricName: vllm_queue_depth
 threshold: "5"
 query: |
 avg(vllm:num_requests_waiting{deployment="vllm-llama70b"})
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.observability.svc:9090
 metricName: vllm_kv_cache
 threshold: "0.85"
 query: |
 avg(vllm:gpu_cache_usage_perc{deployment="vllm-llama70b"})
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.observability.svc:9090
 metricName: vllm_ttft_p95
 threshold: "1.5"
 query: |
 histogram_quantile(0.95,
 sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{deployment="vllm-llama70b"}[5m])))

Tres detalles operativos no obvios:

minReplicaCount: 2. Es el warm pool. Mantener al menos dos réplicas garantiza disponibilidad ante pérdida de un nodo y absorbe spikes sin esperar al cold start del primer escalado. Bajarlo a 0 ahorra GPU en off-peak pero introduce 90 s–6 min de latencia al primer cliente nuevo.

stabilizationWindowSeconds: 600 en scale-down. Diez minutos. Los modelos no son nginx: si una réplica se cierra prematuramente y a los dos minutos hay otro pico, el cold start de un nuevo pod tarda lo que el cliente espera. Mejor mantener réplicas extra el doble de lo que mantendrías para un servicio web normal.

scaleUp: stabilizationWindowSeconds: 30. Treinta segundos. El scale-out tiene que ser rápido — el cold start del nuevo pod añade su propio retraso, y si encima el HPA espera otros minutos antes de disparar, el SLO ya está roto.

El gran problema operativo: cold start

Un pod vLLM cargando Llama 70B pasa por estas fases antes de servir el primer token:

Fase	Tiempo típico	Acelerable con
Image pull (4–6 GB)	30–90 s	DaemonSet pre-pull
Descarga del modelo (140 GB BF16)	60–300 s	PV regional cacheado, S3 + multi-thread
Carga del modelo a HBM	30–90 s	tmpfs o NVMe local
Capture de CUDA graphs	20–60 s	`--enforce-eager` (más lento en runtime pero arranque rápido)
Warmup de PagedAttention	5–15 s	—
Health check ready	10–30 s	tuning de probe

Total sin optimización: 4–10 minutos. Una réplica nueva tarda eso en absorber tráfico. Con todas las palancas combinadas: 45–90 segundos. La diferencia entre los dos números es el principal trabajo de plataforma para autoscaling LLM.

Las cinco palancas

Palanca 1 — imagen pre-pulled. Un DaemonSet trivial corre ctr image pull (o crictl pull) sobre los nodos GPU en cuanto se incorporan al cluster. La imagen del motor de inferencia queda en disco; los nuevos pods saltan los 30–90 s de pull. Coste: ~6 GB de disco por nodo.

apiVersion: apps/v1
kind: DaemonSet
metadata: { name: vllm-image-warmer }
spec:
 selector: { matchLabels: { app: vllm-warmer } }
 template:
 metadata: { labels: { app: vllm-warmer } }
 spec:
 nodeSelector: { workload: gpu }
 initContainers:
 - name: pull
 image: vllm/vllm-openai:v0.10.0
 command: ["/bin/true"]
 containers:
 - name: pause
 image: registry.k8s.io/pause:3.10

Palanca 2 — modelo en PV regional. El download del modelo (140 GB BF16 o 35 GB FP8) desde object storage central es el componente dominante del cold start. Cachear el modelo en un PV de zona/rack —Rook-Ceph RBD, o NVMe local provisionado por el operador— recorta 60–300 s a 5–15 s. El antipatrón: descargar el modelo en cada arranque desde S3 externo.

volumeMounts:
 - name: model-cache
 mountPath: /models
 readOnly: true
volumes:
 - name: model-cache
 persistentVolumeClaim:
 claimName: llama70b-fp8-pvc  # RWX shared, llenado offline

Palanca 3 — warm pool. minReplicaCount > 0 mantiene réplicas pre-cargadas en idle. El coste es GPU ociosa; el beneficio es 0 s de cold start para el primer cliente de un pico. Para clusters productivos con tráfico continuo: warm pool de 2–3 réplicas. Para clusters batch nocturnos con tráfico 0: warm pool 0 y aceptar el cold start, o KEDA con cron que pre-encienda 10 minutos antes.

Palanca 4 — predictive scaling con cron. Cuando el patrón es predecible (oficinas 9–18 h):

triggers:
 - type: cron
 metadata:
 timezone: Europe/Madrid
 start: "30 8 * * 1-5" # 8:30 lunes–viernes
 end: "0 19 * * 1-5" # 19:00
 desiredReplicas: "6"

Combinado con triggers reactivos. El HPA escala según el máximo de las señales: si la cron pide 6 y la cola pide 10, el resultado es 10.

Palanca 5 — descarga paralela y formato eficiente. Para PVs no pre-cargados, herramientas como nvidia-modelmanager, s5cmd o aria2c paralelizan la descarga del modelo. Pasar de descarga serial (~150 MB/s) a paralela 8 threads (~1.2 GB/s) divide entre 8 el tiempo. Y formatos como safetensors se cargan en HBM más rápido que PyTorch pickle original.

Cuándo escalar nodos, no solo pods

El HPA escala pods. Si el cluster no tiene nodos GPU libres, el nuevo pod se queda en Pending por falta de recursos. Para escalar nodos, hace falta cluster-autoscaler con un nodepool GPU específico, etiquetado:

# nodepool config (Karpenter o cluster-autoscaler equivalent)
labels:
 workload: gpu
 gpu-model: h100-sxm-80gb
taints:
 - key: nvidia.com/gpu
 effect: NoSchedule
limits:
 min: 2 nodes
 max: 8 nodes

Sin esto, el HPA puede pedir 10 réplicas pero el cluster solo entrega las que caben en nodos ya levantados. El cold start de un nodo nuevo (provisioning bare metal o cloud, PXE, OS boot, drivers NVIDIA, join del cluster) es mucho mayor que el cold start de un pod: típicamente 5–15 minutos en bare metal preconfigurado, 30–60 minutos en provisioning real. Para clusters on-premise, el nodepool debe estar siempre dimensionado al máximo previsto, y el “scaling” es solo del lado de pods. El concepto de scale-out reactivo de nodos solo aplica a clouds; en on-premise hay que comprar para el pico.

Tres pitfalls específicos del scale-down LLM

Pitfall 1 — cortar conexiones SSE de streaming. Cuando una réplica entra en Terminating, Kubernetes envía SIGTERM al pod y, por defecto, lo mata 30 segundos después. Para vLLM eso significa cortar conexiones SSE de streaming a la mitad de la respuesta. El cliente recibe un error 502 con el output parcial perdido. Solución: terminationGracePeriodSeconds: 120 + un preStop hook que avise al motor de no aceptar nuevas requests pero terminar las en curso:

spec:
 terminationGracePeriodSeconds: 120
 containers:
 - name: vllm
 lifecycle:
 preStop:
 httpGet:
 path: /shutdown
 port: 8000

Esto requiere que el motor exponga un endpoint de shutdown elegante; vLLM v1 lo soporta vía --enable-graceful-shutdown. Sin esto, el scale-down rompe SLO aunque las métricas no lo capturen (las requests cortadas no entran al histograma de TTFT).

Pitfall 2 — oscilación scale-up/scale-down. Si la stabilizationWindowSeconds del scale-down es corta (~60 s default), la siguiente bajada de cola dispara scale-down, y dos minutos después el siguiente pico dispara scale-up. El sistema oscila, paga cold starts repetidos, y nunca alcanza un régimen estable. Solución: scale-down con ventana de 10 minutos como mínimo y políticas conservadoras (type: Pods, value: 1, periodSeconds: 120 — máximo una réplica menos cada 2 minutos).

Pitfall 3 — vllm:num_requests_waiting con avg cuando hay rebalanceo. Si dos réplicas están desbalanceadas (una con cola 20, otra con cola 0), avg da 10 — el HPA dispara scale-out cuando lo correcto sería rebalancear vía el load balancer. Para detectarlo: añadir una alerta sobre stddev(vllm:num_requests_waiting) por deployment. Si la dispersión es alta, el problema no es de capacidad sino de routing.

Manifest completo de ejemplo

Para un deployment vLLM con Llama 70B FP8 en 4×H100 SXM por réplica, KEDA con warm pool 2:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: vllm-llama70b
 namespace: inference
spec:
 replicas: 2 # gestionado por KEDA después
 selector: { matchLabels: { app: vllm-llama70b } }
 template:
 metadata:
 labels: { app: vllm-llama70b, deployment: vllm-llama70b }
 spec:
 terminationGracePeriodSeconds: 120
 nodeSelector: { workload: gpu, gpu-model: h100-sxm-80gb }
 tolerations:
 - key: nvidia.com/gpu
 operator: Exists
 effect: NoSchedule
 containers:
 - name: vllm
 image: vllm/vllm-openai:v0.10.0
 args:
 - --model=/models/llama-3.3-70b-fp8
 - --tensor-parallel-size=4
 - --max-num-seqs=64
 - --enable-prefix-caching
 - --enable-graceful-shutdown
 ports:
 - { name: http, containerPort: 8000 }
 - { name: metrics, containerPort: 8000 }
 resources:
 limits:
 nvidia.com/gpu: "4"
 memory: 200Gi
 readinessProbe:
 httpGet: { path: /health, port: 8000 }
 initialDelaySeconds: 60
 periodSeconds: 10
 failureThreshold: 30 # tolera el warmup
 lifecycle:
 preStop:
 httpGet: { path: /shutdown, port: 8000 }
 volumeMounts:
 - { name: model-cache, mountPath: /models, readOnly: true }
 - { name: dshm, mountPath: /dev/shm }
 volumes:
 - name: model-cache
 persistentVolumeClaim: { claimName: llama70b-fp8-pvc }
 - name: dshm
 emptyDir: { medium: Memory, sizeLimit: 16Gi }
---
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata: { name: vllm-llama70b-metrics, namespace: inference }
spec:
 selector: { matchLabels: { app: vllm-llama70b } }
 podMetricsEndpoints:
 - port: metrics
 path: /metrics
 interval: 15s
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: vllm-llama70b-scaler, namespace: inference }
spec:
 scaleTargetRef: { name: vllm-llama70b }
 minReplicaCount: 2
 maxReplicaCount: 20
 pollingInterval: 15
 cooldownPeriod: 300
 advanced:
 horizontalPodAutoscalerConfig:
 behavior:
 scaleDown:
 stabilizationWindowSeconds: 600
 policies:
 - { type: Pods, value: 1, periodSeconds: 120 }
 scaleUp:
 stabilizationWindowSeconds: 30
 policies:
 - { type: Pods, value: 2, periodSeconds: 60 }
 triggers:
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.observability.svc:9090
 metricName: vllm_queue
 threshold: "5"
 query: avg(vllm:num_requests_waiting{deployment="vllm-llama70b"})
 - type: prometheus
 metadata:
 serverAddress: http://prometheus.observability.svc:9090
 metricName: vllm_kv
 threshold: "0.85"
 query: avg(vllm:gpu_cache_usage_perc{deployment="vllm-llama70b"})
 - type: cron
 metadata:
 timezone: Europe/Madrid
 start: "30 8 * * 1-5"
 end: "0 19 * * 1-5"
 desiredReplicas: "6"

Este conjunto es el mínimo viable para autoscaling LLM en cluster genérico con NVIDIA GPU Operator. Cada equipo lo adapta a su SLO concreto.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4×H100 SXM 80 GB por nodo, 4 nodos GPU:

Cada nodo aloja una réplica vLLM TP=4 con Llama 70B FP8 (un modelo por nodo, no se comparten).
Warm pool de 2 réplicas en off-peak; KEDA cron eleva a 4 en horario laboral.
Cluster-autoscaler no aplica (4 nodos físicos comprados; el escalado es solo de pods). El número de réplicas concurrentes es como máximo el número de nodos disponibles (si cada réplica usa los 4 GPUs del nodo entero).
Si el dimensionamiento requiere más réplicas simultáneas que nodos, hay dos vías: (a) bajar el TP de cada réplica para que entren dos por nodo, (b) ampliar el nodepool físico. La decisión la dicta el capacity planning —ver Capacity planning para inferencia LLM on-premise—.

Volumen de eventos KEDA: ~5 evaluations/min por ScaledObject. Para 10 modelos servidos en paralelo, 3 000 evaluations/h. Manejable con un KEDA operator por cluster.

Lo que no hemos cubierto (próximos artículos)

Cluster-autoscaler para nodos GPU on-premise: cómo orquestar provisioning bare metal (Tinkerbell, Metal³) en función de demanda.
Multi-cluster autoscaling: escalar entre clusters de DCs distintos para resiliencia geográfica.
Cost-aware autoscaling: priorizar nodos según coste energético horario (en clusters con tarifa indexada).
Predictive ML-based scaling: en lugar de cron estático, entrenar un modelo que prediga demanda con 30 minutos de antelación.
Quotas y fairness multi-tenant: KEDA con namespace quotas para que un tenant no acapare el HPA.

Ver también

Observabilidad GPU para inferencia LLM — fuente de las métricas que alimentan al HPA.
Capacity planning para inferencia LLM on-premise — qué techo y qué head-room presupone el autoscaler.
Continuous batching — explica num_requests_running, num_requests_waiting y gpu_cache_usage_perc.
KV cache — domina el KV pool y por tanto los thresholds.
Cinco niveles de madurez — KEDA es pieza del nivel 4.
Canary, blue-green y shadow — el autoscaler convive con la estrategia de despliegue.
El router de inferencia LLM — el router consume vllm:num_requests_running y vllm:gpu_cache_usage_perc (mismas métricas que el autoscaler) para decidir réplica con token-aware LB y prefix-aware routing; los dos componentes comparten cabina pero deciden cosas distintas.
Runbooks de incident response para LLM con Keep + Kafka — los runbooks RB-01 (GpuHbmNearOom) y RB-05 (VllmKvCachePoolNearFull) usan el autoscaler como palanca de mitigación inmediata.

Referencias

KEDA project — keda.sh (documentación oficial de triggers Prometheus y cron).
Kubernetes — Horizontal Pod Autoscaler walkthrough (kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale).
NVIDIA — GPU Operator on Kubernetes (Helm chart oficial con DaemonSet de drivers y DCGM).
vLLM project — production_monitoring/ (métricas Prometheus expuestas por el servidor).
Karpenter — NodePool spec (etiquetado y taints para nodepools GPU).
Cluster Autoscaler — Scaling GPU nodes (caveats de descubrimiento de recursos GPU).
Kubernetes — Pod lifecycle and termination (preStop, terminationGracePeriodSeconds).

Observabilidad GPU para inferencia LLM: las doce métricas DCGM y vLLM que dictan la salud de tu producción

Mon, 01 Jun 2026 15:30:00 +0200

Este post complementa los de Tracing LLM con OpenTelemetry GenAI (la capa de tracing por encima de las métricas), Capacity planning (qué se dimensionó y qué se debe vigilar) y Continuous batching (el mecanismo que explica varias de las métricas del motor).

TL;DR

La observabilidad de un cluster de inferencia LLM se construye sobre dos fuentes complementarias: las métricas del hardware GPU expuestas por DCGM (Data Center GPU Manager) Exporter —parte del NVIDIA GPU Operator— y las métricas del motor de inferencia (vLLM, SGLang, TensorRT-LLM) expuestas en /metrics Prometheus-compatibles. Ninguna de las dos basta sola. La métrica clásica de nvidia-smi llamada GPU utilization es engañosa para LLMs: marca alto cuando hay cualquier kernel ejecutándose, sin distinguir tensor cores ardiendo de SMs esperando por HBM. La cabina de pilotaje completa tiene doce métricas DCGM en cuatro familias (compute: DCGM_FI_PROF_SM_OCCUPANCY, DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, DCGM_FI_PROF_DRAM_ACTIVE; memoria: DCGM_FI_DEV_FB_USED, DCGM_FI_DEV_FB_FREE, DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL; térmico-energético: DCGM_FI_DEV_GPU_TEMP, DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_CLOCK_THROTTLE_REASONS; salud: DCGM_FI_DEV_XID_ERRORS, DCGM_FI_DEV_ECC_DBE_VOL_TOTAL, DCGM_FI_DEV_RETIRED_DBE) y cinco métricas del motor vLLM (vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds). Cada una tiene un umbral verde/ámbar/rojo defendible, una PromQL para alerta, y al menos una falsa lectura habitual que confunde al operador junior. Las seis alertas críticas que cualquier cluster productivo debe disparar son: HBM > 92 %, throttle por térmico o por power, XID error, ECC double-bit, KV cache pool > 95 %, y TTFT P95 fuera de SLO durante 5 minutos. El objetivo de tener este panel: que el operador de turno diagnostique el origen de una degradación en menos de cinco minutos, sin abrir consola SSH a las GPUs. Cuando esto se cumple, el cluster ha pasado a operación profesional; mientras no, se opera por intuición.

Estás aquí: OBSERVE (la otra mitad del tracing)

El tracing —ya cubierto en Tracing LLM con OpenTelemetry GenAI— responde qué pasó en esta request concreta. Las métricas responden qué está pasando en el cluster en agregado. Son complementarias: una alerta del lado de métricas te dice “el clúster está degradando”, el tracing te dice “y esta es la traza concreta que te lo demuestra”. Un cluster sin tracing pero con métricas opera; un cluster sin métricas pero con tracing no opera, debuggea.

La analogía: la cabina de un avión moderno

En un avión comercial moderno, el panel de instrumentos del piloto tiene más de 70 indicadores activos. Si solo hubiese uno —el altímetro, por ejemplo— el avión volaría hacia el suelo en el primer momento de baja visibilidad. Hace falta el altímetro y el indicador de actitud, y el de velocidad, y el de viraje, y el de combustible, y los de presión de aceite de cada motor, y las temperaturas de salida de turbina. Cada uno responde una pregunta distinta. Y todos juntos cubren la pregunta operacional: ¿está el avión sano, está donde debe, y va donde queremos?

La observabilidad de un cluster de inferencia LLM funciona igual. Una sola métrica —“GPU utilization 99 %"— no responde nada útil. Es como mirar solo el cuentakilómetros del coche para diagnosticar por qué hace ruido el motor. La cabina completa es doce instrumentos del lado de hardware más cinco del lado del motor de inferencia, organizados en familias que responden preguntas distintas:

Compute y eficiencia: ¿están los tensor cores haciendo el trabajo que esperamos o están esperando?
Memoria: ¿queda VRAM para nuevas requests o estamos al borde del OOM?
Térmico y energético: ¿el hardware está sano o está limitando el throughput silenciosamente?
Salud y errores: ¿hay degradación del hardware en curso (ECC, XID, NVLink)?
Motor de inferencia: ¿la cola crece, el KV pool está saturado, el SLO se está cumpliendo?

Las cuatro primeras responden a “¿la GPU está bien?”. La quinta responde a “¿está dando el servicio que prometimos?”. Las dos preguntas son distintas y ambas deben tener respuesta a un golpe de vista.

Por qué `nvidia-smi` `GPU-Util` engaña en LLMs

La métrica clásica que aparece en nvidia-smi como GPU-Util corresponde a DCGM_FI_DEV_GPU_UTIL. Su definición oficial: “porcentaje del tiempo durante el cual uno o más kernels estuvieron ejecutándose en la GPU”. El problema en LLMs: la fase de decode es memory-bound, no compute-bound. Cuando el motor de inferencia hace decode token a token, la GPU pasa el 90 % del tiempo esperando que la HBM termine de entregar los pesos del modelo y el KV cache. Hay un kernel corriendo (lectura de HBM); por tanto GPU-Util reporta valores cercanos al 100 %. Pero los tensor cores están parados — el cuello de botella es la memoria, no el compute.

Resultado práctico: el operador ve “GPU-Util 99 %” en Grafana y asume “GPU saturada, no se puede meter más carga”. Pero la realidad puede ser “compute al 25 %, HBM saturada al 95 %”, lo que cambia las decisiones operativas (quantization, batch size, paralelismo). La métrica clásica miente por simplificación.

Lo correcto es mirar las tres métricas de profiling DCGM del subsistema _FI_PROF_*:

DCGM_FI_PROF_SM_OCCUPANCY — ratio de warps activos sobre máximos por SM. ¿Hay trabajo paralelo?
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — % de ciclos con tensor cores efectivamente activos. ¿Está el compute trabajando?
DCGM_FI_PROF_DRAM_ACTIVE — % de ciclos con la HBM transfiriendo. ¿Está la memoria saturada?

Una decode-bound GPU típica de Llama 70B en H100 muestra: SM occupancy 35–55 %, tensor active 15–30 %, DRAM active 80–95 %. Esa es la “GPU saturada” real para LLMs. Las tres juntas distinguen los regímenes; cada una sola no dice nada accionable.

Cómo se montan en producción

La parte de plataforma se cubre en Cinco niveles de madurez (nivel 4 — GPU plane) y Siete fases de despliegue (fase F5). Para el observador, las piezas clave son:

NVIDIA GPU Operator. Manifiestos Helm que despliegan en cada nodo GPU: drivers, container toolkit, MIG manager y DCGM Exporter. Este último expone /metrics en formato Prometheus con todos los DCGM_FI_* listados arriba. Se scrapea desde el Prometheus interno del cluster.

Motor de inferencia. vLLM expone /metrics en el puerto 8000 (default) con métricas vllm:*. SGLang lo expone también con prefijo sglang:. TensorRT-LLM lo expone vía Triton Inference Server con prefijo nv_inference:. La convención básica de nombres es similar entre los tres motores; los umbrales y queries de este post asumen vLLM, pero se traducen.

ServiceMonitor / PodMonitor. Recurso del operador de Prometheus que indica qué scrapear. Ejemplo mínimo:

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
 name: vllm-inference
spec:
 selector:
 matchLabels: { app: vllm }
 podMetricsEndpoints:
 - port: metrics
 interval: 15s

Dashboards. El operador de NVIDIA publica dashboards Grafana de referencia para DCGM en nvidia/dcgm-exporter (repo oficial). vLLM publica uno en vllm-project/vllm (carpeta examples/). Ambos sirven como base; cada equipo añade los paneles propios de su SLO.

Las doce métricas DCGM organizadas por familia

Familia 1 — Compute

DCGM_FI_PROF_SM_OCCUPANCY — Ratio de warps activos por SM sobre el máximo posible. Valor entre 0 y 1.

Verde: 0.30–0.70 (régimen típico LLM en decode).
Ámbar: < 0.20 sostenido (batch demasiado pequeño, GPU infrautilizada en paralelismo).
Rojo: 0.95 sostenido con DRAM_ACTIVE bajo (kernel patológico saturando SMs).

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — % de ciclos con tensor cores ejecutando. La métrica clave de “¿el compute está produciendo?”.

Verde en prefill: 50–80 %.
Verde en decode: 15–30 % (decode es memory-bound, no es síntoma de problema).
Rojo: < 5 % sostenido en prefill o el motor no usa los tensor cores (mala config, formato incompatible).

DCGM_FI_PROF_DRAM_ACTIVE — % de ciclos con HBM transfiriendo datos. Métrica clave para detectar saturación de memoria.

Verde en decode: 60–85 %.
Ámbar: > 90 % sostenido (HBM cuello de botella firme — explica la TPOT alta).
Rojo: > 95 % sostenido con KV cache pool < 70 % (algo está pidiendo HBM que no es el motor; investigar leaks).

Familia 2 — Memoria

DCGM_FI_DEV_FB_USED — Frame Buffer (HBM) usado en MiB.

Verde: 70–85 % del total.
Ámbar: 86–92 %.
Rojo: > 92 % (riesgo de OOM en el siguiente paged-attention allocation).

PromQL para porcentaje sobre cluster: 100 * sum(DCGM_FI_DEV_FB_USED) / sum(DCGM_FI_DEV_FB_TOTAL).

DCGM_FI_DEV_FB_FREE — Frame Buffer libre. Complementaria de la anterior; útil para alertas absolutas (< 4096 MiB libres).

DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL — Bandwidth NVLink agregado en MB/s. Para topologías TP (tensor parallel) que cruzan GPUs vía NVLink, esta métrica revela si el reparto de paralelismo está saturando el bus.

Verde: variable según topología. En 4×H100 SXM con NVLink 4.0, capacidad teórica 450 GB/s por GPU. Régimen TP=4 típico: 50–150 GB/s sostenido.
Rojo: > 90 % capacidad sostenido (revisar si el modelo cabría con TP menor o pipeline parallel).

Familia 3 — Térmico y energético

DCGM_FI_DEV_GPU_TEMP — Temperatura del die en °C.

Verde: < 75 °C.
Ámbar: 75–82 °C.
Rojo: > 83 °C (cerca del thermal throttle automático de H100; revisar ventilación, caudal de aire, temperatura de entrada al rack).

DCGM_FI_DEV_POWER_USAGE — Consumo en watts. Para H100 SXM, TDP nominal 700 W. Útil para tres cosas: detectar workload inusualmente bajo (sospechar idle o stall), facturar coste energético real, y disparar alertas si el draw se acerca al límite de la PDU.

DCGM_FI_DEV_CLOCK_THROTTLE_REASONS — Bitmap codificado con las razones de throttle activas. Es la métrica que silenciosamente explica las degradaciones de TPOT.

Bits relevantes:

0x0000000000000001 — Idle (no es problema).
0x0000000000000002 — App clocks setting.
0x0000000000000004 — SW Power Cap (límite de software, p. ej. por nvidia-smi -pl).
0x0000000000000008 — HW Slowdown.
0x0000000000000010 — Sync Boost (NVIDIA Sync).
0x0000000000000020 — SW Thermal Slowdown (límite térmico de software).
0x0000000000000040 — HW Thermal Slowdown (límite térmico de hardware — emergencia).
0x0000000000000080 — HW Power Brake Slowdown (caída de tensión PSU).
0x0000000000000100 — Display Clock Setting.

Cualquier throttle salvo Idle con valor > 0 sostenido es alerta. La degradación de TPOT con DRAM_ACTIVE ya alto y throttle térmico activo es el clásico “el rack está mal ventilado, no es problema del motor”.

Familia 4 — Salud

DCGM_FI_DEV_XID_ERRORS — Contador acumulado de XID errors del driver. Los XID son códigos de evento crítico que NVIDIA documenta exhaustivamente (XID 13: graphics engine exception; XID 31: GPU memory page fault; XID 43: reset channel verif error; XID 79: GPU has fallen off the bus; XID 95: uncontained ECC error; etc.). Cualquier incremento es alerta inmediata: muchos XID requieren reset del nodo o RMA de la GPU.

DCGM_FI_DEV_ECC_DBE_VOL_TOTAL — Errores ECC double-bit volátiles (no corregibles). A diferencia de los single-bit (que ECC corrige silenciosamente y se contabilizan en DCGM_FI_DEV_ECC_SBE_*), los double-bit corrompen datos. Cualquier valor > 0 es alerta crítica: la GPU debe ser drenada y revisada.

DCGM_FI_DEV_RETIRED_DBE — Páginas físicas de HBM retiradas por double-bit errors acumulados. NVIDIA retira páginas defectuosas automáticamente para prevenir corrupción futura. Más de 4–8 páginas retiradas en una GPU sugiere degradación del silicio: documentar y planificar reemplazo en próxima ventana de mantenimiento.

Las cinco métricas del motor de inferencia (vLLM)

Las métricas DCGM responden “¿está sana la GPU?”. Las del motor responden “¿está el servicio cumpliendo el SLO?”. Sin ellas, sabes que el hardware funciona pero no sabes si los clientes están contentos.

vllm:num_requests_running — Requests actualmente en el batch. Si llega al --max-num-seqs configurado y no baja, el motor está saturado en concurrencia (revisar VRAM y rebalancear vía autoscaler — ver Autoscaling LLM en Kubernetes).

vllm:num_requests_waiting — Requests en cola, sin entrar al batch. Cualquier valor > 0 sostenido durante minutos indica que el cluster no escala con la carga. Esta es la métrica primaria para HPA.

vllm:gpu_cache_usage_perc — % del KV cache pool usado.

Verde: 50–80 %.
Ámbar: 80–92 %.
Rojo: > 92 % (riesgo de preempt-on-OOM: vLLM tirará requests para liberar memoria, lo que aumenta TTFT visiblemente).

vllm:time_to_first_token_seconds — Histograma de TTFT por request. Se consume como histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket[5m]))). Comparado contra el SLO de TTFT P95 dispara la alerta primaria de servicio.

vllm:time_per_output_token_seconds — Histograma de TPOT. Equivalente al anterior pero para fluidez de streaming. Comparado contra el SLO de TPOT P95 dispara la alerta secundaria.

Las seis alertas que deben pagear en producción

Cualquier cluster productivo serio dispara estas seis alertas a un canal con rotación de guardia. Sin estas, el SLO se cumple por suerte, no por proceso.

groups:
 - name: gpu-llm-critical
 rules:
 - alert: GpuHbmNearOom
 expr: 100 * (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL) > 92
 for: 2m
 labels: { severity: critical }
 annotations:
 summary: "HBM de {{ $labels.gpu }} en {{ $value }}% — riesgo OOM"

 - alert: GpuThermalOrPowerThrottle
 expr: (DCGM_FI_DEV_CLOCK_THROTTLE_REASONS != 0) and ignoring(reason) (DCGM_FI_DEV_CLOCK_THROTTLE_REASONS != 1)
 for: 1m
 labels: { severity: warning }
 annotations:
 summary: "GPU {{ $labels.gpu }} en throttle (reasons={{ $value }})"

 - alert: GpuXidErrorDetected
 expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
 labels: { severity: critical }
 annotations:
 summary: "XID error en GPU {{ $labels.gpu }} — investigar inmediatamente"

 - alert: GpuEccDoubleBit
 expr: DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0
 labels: { severity: critical }
 annotations:
 summary: "ECC double-bit en GPU {{ $labels.gpu }} — drenar nodo"

 - alert: VllmKvCachePoolNearFull
 expr: vllm:gpu_cache_usage_perc > 0.95
 for: 3m
 labels: { severity: warning }
 annotations:
 summary: "KV cache pool > 95% en {{ $labels.instance }}"

 - alert: VllmTtftP95OutOfSlo
 expr: histogram_quantile(0.95, sum by(le, instance)(rate(vllm:time_to_first_token_seconds_bucket[5m]))) > 1.5
 for: 5m
 labels: { severity: warning }
 annotations:
 summary: "TTFT P95 sobre SLO ({{ $value }}s > 1.5s)"

Estas seis cubren el 80 % de los incidentes que afectan a SLO. El 20 % restante exige investigación con tracing (ver Tracing LLM con OpenTelemetry GenAI).

Tabla maestra: umbrales y queries

Métrica	Verde	Ámbar	Rojo	Query base (PromQL)
SM occupancy	0.30–0.70	0.15–0.30	< 0.10 sostenido	`DCGM_FI_PROF_SM_OCCUPANCY`
Tensor active (decode)	15–30 %	< 10 %	< 3 %	`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE`
DRAM active	60–85 %	85–95 %	> 95 % con KV bajo	`DCGM_FI_PROF_DRAM_ACTIVE`
FB used	70–85 %	86–92 %	> 92 %	`100 * DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL`
NVLink BW	< 70 % cap	70–90 % cap	> 90 % cap	`DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL`
GPU temp	< 75 °C	75–82 °C	> 83 °C	`DCGM_FI_DEV_GPU_TEMP`
Power usage	< 90% TDP	90–98 % TDP	> 98 % TDP	`DCGM_FI_DEV_POWER_USAGE`
Throttle reasons	0 o Idle	App/SW	HW Therm/Power	`DCGM_FI_DEV_CLOCK_THROTTLE_REASONS`
XID errors	sin cambio	—	cualquier delta	`increase(DCGM_FI_DEV_XID_ERRORS[5m])`
ECC DBE	0	—	> 0	`DCGM_FI_DEV_ECC_DBE_VOL_TOTAL`
Retired pages	< 4	4–8	> 8	`DCGM_FI_DEV_RETIRED_DBE`
KV cache used	50–80 %	80–92 %	> 92 %	`vllm:gpu_cache_usage_perc`
Requests waiting	0	1–5 sostenido	> 10 sostenido	`vllm:num_requests_waiting`
TTFT P95	< SLO	80–100 % SLO	> SLO	ver query alerta arriba
TPOT P95	< SLO	80–100 % SLO	> SLO	`histogram_quantile(0.95, sum by(le)(rate(vllm:time_per_output_token_seconds_bucket[5m])))`

Tres pitfalls que confunden al operador junior

Pitfall 1 — “GPU-Util al 99 % = saturada”. Como se explicó al inicio: DCGM_FI_DEV_GPU_UTIL se enciende con cualquier kernel. Lo correcto es mirar las tres _PROF_* (SM occupancy, tensor active, DRAM active) juntas. GPU util 99 % + tensor active 8 % + DRAM active 92 % = “saturada por memoria, no compute”; GPU util 99 % + tensor active 75 % + DRAM active 50 % = “saturada por compute, prefill heavy”. Las dos situaciones piden palancas distintas.

Pitfall 2 — confundir ECC single-bit (SBE) con double-bit (DBE). Los single-bit se corrigen silenciosamente y son inevitables en cualquier HBM bajo carga (radiación cósmica, fluctuaciones de tensión). Un contador SBE creciendo lentamente no es alerta — es física. El DBE sí: corrompe datos. Distinguir las dos métricas evita falsas alarmas y falsos negativos a partes iguales.

Pitfall 3 — alertar sobre num_requests_waiting > 0 sin contexto. Un valor instantáneo de 1 o 2 durante un pico es normal. Lo que importa es la cola sostenida: usar for: 5m con umbral 3–5. Sin esa ventana, el sistema satura el canal de alertas con ruido.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4×H100 SXM 80 GB con NVLink intra-nodo:

DCGM Exporter desplegado vía NVIDIA GPU Operator, un DaemonSet por nodo GPU.
Prometheus interno con retención 30 días para métricas de alta frecuencia, 1 año para downsampled (Thanos/Mimir si el volumen lo justifica).
Grafana con tres dashboards estándar: hardware GPU (DCGM), motor (vLLM), SLO (TTFT/TPOT/RPS contra objetivos escritos).
Alertmanager con rotación de guardia y rate-limiting por silencio agrupado por nodo.
Cardinalidad controlada: gpu (id local), node, pod, model — no añadir request_id ni labels de alta cardinalidad a métricas (eso es trabajo del tracing).

Volumen estimado para un cluster de 16 GPUs con scraping cada 15 s: ~2 millones de samples/min, ~25 GB/día de Prometheus crudo. Manejable con un Prometheus por cluster + retention; si el equipo escala a > 64 GPUs, considerar Thanos sidecar o VictoriaMetrics. Ver Catálogo de herramientas OSS LLMOps para alternativas equivalentes.

Lo que no hemos cubierto (próximos artículos)

Tracing de cargas LLM: ya cubierto en Tracing LLM con OpenTelemetry GenAI.
Autoscaling basado en estas métricas: ver Autoscaling LLM en Kubernetes.
Runbooks de incident response: cómo cada una de estas alertas se traduce a acción concreta (drain, restart, RMA, escalado, rollback).
Cost accounting: usar DCGM_FI_DEV_POWER_USAGE y vllm:request_success_total para showback de coste por tenant.
Monitorización de fairness multi-tenant: cuando varios tenants comparten cluster, qué métricas detectan que uno está acaparando el KV cache.

Ver también

Tracing LLM con OpenTelemetry GenAI — la otra mitad de la observabilidad.
Capacity planning para inferencia LLM on-premise — qué se dimensionó y, por tanto, qué umbrales son defendibles aquí.
Continuous batching — explica por qué num_requests_running, num_requests_waiting y gpu_cache_usage_perc son las métricas operativas del motor.
Cinco niveles de madurez — la observabilidad LLM-aware vive en el nivel 4.
Siete capas del stack de inferencia LLM on-premise — DCGM Exporter es pieza de la capa de plataforma.
Autoscaling LLM en Kubernetes — usa estas métricas como input.
Anatomía de las doce métricas DCGM y cinco vLLM — profundización con analogía y anomalía documentada en producción para cada métrica, con cifras de incidentes públicos (Meta Llama 3, Story of Two GPUs, issues vLLM, KBs Dell/Lenovo).
Runbooks de incident response para LLM con Keep + Kafka — la traducción de cada alerta crítica a acción concreta (drain, reset, RMA, rollback) con workflow YAML, schema Kafka WORM y encaje en ISO 27035, ENS, NIS2, EU AI Act art. 73.

Referencias

NVIDIA — DCGM Exporter (repo nvidia/dcgm-exporter, métricas y unidades documentadas).
NVIDIA — DCGM Field Identifiers reference (lista completa de DCGM_FI_*).
NVIDIA — XID Errors documentation (catálogo de códigos XID y procedimientos de remediación).
NVIDIA — NVIDIA GPU Operator (Helm chart oficial).
vLLM project — examples/production_monitoring/ (PromQL y dashboards Grafana de referencia).
Prometheus — Histogram and summary best practices (para construir queries de percentiles defendibles).
NVIDIA — H100 Tensor Core GPU datasheet (TDP, HBM bandwidth, NVLink capacities).

Capacity planning para inferencia LLM on-premise: cómo dimensionar GPUs a partir de un SLO

Mon, 01 Jun 2026 15:00:00 +0200

Este post complementa los de KV cache (la pieza que domina el presupuesto de VRAM), Continuous batching (lo que define la utilización efectiva del compute) y Siete capas del stack (las piezas que el sizing presupone). Antes de leer este, asegúrate de que tu equipo tiene escritos los SLOs que va a perseguir; sin esa entrada el cálculo no es defendible.

TL;DR

El capacity planning de inferencia LLM no responde a “cuántos tokens/segundo da una GPU” — esa pregunta carece de respuesta universal porque el throughput depende de la concurrencia, el reparto prefill/decode, la longitud de contexto, el motor de inferencia y la quantization. La pregunta correcta tiene tres entradas (SLO: TTFT P95, TPOT P95, RPS sostenidos), una referencia de hardware (modelo de GPU, VRAM, ancho HBM, FLOPs efectivos) y un modelo (parámetros, arquitectura GQA/MHA/MoE, formato de pesos). El cálculo se resuelve en dos presupuestos acoplados que se cruzan. Presupuesto de VRAM: del total de la GPU restas pesos del modelo y activaciones, lo que queda es KV cache budget, y de ahí derivas la concurrencia máxima posible al contexto promedio que esperas. Presupuesto de tiempo: el motor (vLLM, SGLang, TensorRT-LLM) tiene un techo de tokens/s en decode dado por el ancho de HBM y otro en prefill dado por el FLOP útil; de ahí derivas la TPOT esperada y, dividiendo prefill_tokens entre el throughput de prefill, la TTFT esperada. Ambos presupuestos deben cumplir el SLO simultáneamente: el que esté más ajustado dicta el dimensionamiento. Sobre el ejemplo Llama 70B BF16 con tensor parallel 4 en 4×H100 SXM, una sola réplica satura a ~28 requests concurrentes y entrega ~3 200 tokens/s de decode agregado con TPOT mediano de 35 ms; para 200 RPS sostenidos a un perfil de 800 tokens de prompt + 250 de output, hacen falta entre 4 y 5 réplicas con un colchón del 25 % sobre el pico observado. La quantization (FP8 → INT4) divide entre 1.5 y 4× el coste de VRAM y de tiempo de decode, pero degrada calidad de forma medible — no se asume gratis, se valida con evals. Las cinco trampas habituales: confundir media con P95, ignorar el reparto prefill/decode del workload real, dimensionar sin head-room para retrain ni rollback, olvidar que la GPU al 100 % de SM util no significa nada si la HBM está saturada, y no documentar los supuestos del cálculo (un sizing sin supuestos escritos es un cálculo desechable).

Estás aquí: DEPLOY (con un pie en OBSERVE)

El capacity planning es una pieza con doble residencia. Vive en DEPLOY porque sin un sizing válido no se compra hardware ni se configura el motor de inferencia. Pero su input son las observaciones reales: distribución de longitudes de prompt y output, mezcla prefill/decode del workload, P95 reales que ya se están viendo en preproducción. Sin esos datos el cálculo es una servilleta — defendible solo hasta que llegue el primer cliente que no encaja en la media asumida.

La analogía: el hotel con habitaciones de tamaño variable

Imagina un hotel donde las habitaciones no tienen tamaño fijo: cada huésped paga por los metros cuadrados que necesita, y la planta del edificio se reorganiza dinámicamente para acomodar a quien llega. La dirección quiere maximizar ocupación, pero tiene dos restricciones reales y una métrica de calidad.

Restricción 1 — espacio físico. La planta tiene 1 000 m² totales. Si entra una familia que necesita 200 m², esa familia ocupa esa superficie y no se puede entregar al siguiente huésped. La habitación más grande limita cuántos huéspedes simultáneos caben.

Restricción 2 — personal de servicio. Hay 10 recepcionistas. Cada uno puede gestionar el check-in de un huésped cada dos minutos. Cuando llegan 60 huéspedes en una hora, los últimos esperan en cola; el tiempo desde que entran a recepción hasta que reciben su llave depende de cuántos hay delante.

Métrica de calidad — promesa de tiempo. La carta dice “check-in en menos de 15 minutos”. Si llegan demasiados huéspedes a la vez, esa promesa se rompe aunque haya espacio físico libre.

El espacio físico es la VRAM de la GPU. Cada habitación es una request con su KV cache (más grande cuanto más larga la conversación). Los recepcionistas son los compute units (Streaming Multiprocessors + Tensor Cores). El check-in es la fase de prefill; las noches que el huésped pasa después son los pasos de decode. La promesa de 15 minutos es el SLO de TTFT P95.

El capacity planning del hotel es exactamente este: dado el perfil esperado de huéspedes (cuántos llegan por hora, cuánto espacio piden de media, cuántos minutos toleran de espera), calcular cuántas plantas y cuántos recepcionistas hace falta. No se hace estimando “habitaciones por hora” en abstracto — se hace cruzando los dos presupuestos con la promesa de tiempo. La analogía sostiene el cálculo hasta el final.

Las tres entradas del SLO

Antes de poner un solo número en la hoja, hay que escribir las tres dimensiones del SLO. Sin esto el cálculo es estética, no ingeniería.

TTFT P95 (Time-To-First-Token). El tiempo desde que el cliente envía la request hasta que recibe el primer token. Está dominado por la fase de prefill (procesar el prompt entero de una vez) más la cola del scheduler. Para chat conversacional, un objetivo razonable está entre 0.5 y 2 segundos P95. Para asistentes de programación con prompts grandes (5–10 K tokens de contexto), entre 2 y 4 s P95. Por debajo de 500 ms entra en regla de UX para conversaciones tipo voz, pero exige compromisos serios de arquitectura.

TPOT P95 (Time-Per-Output-Token). El tiempo entre tokens consecutivos durante decode. Domina la “fluidez percibida” del streaming. Por encima de 80 ms/token el lector humano percibe pausas; por debajo de 30 ms/token la salida fluye más rápido de lo que se lee. Objetivo industrial habitual: 40–60 ms P95.

RPS sostenidos cumpliendo SLO. El throughput que el sistema debe soportar sin violar TTFT ni TPOT. Esto es la métrica clave de DistServe llamada goodput —ver Continuous batching—. “200 RPS pico” no es lo mismo que “200 RPS con TTFT P95 ≤ 1.5 s”. Sin la condición de SLO, el número de RPS no significa nada.

Estas tres dimensiones se acompañan de un perfil de workload: distribución de longitudes de prompt y de output. Las medianas no bastan; hace falta P50, P95, P99. Un perfil mal medido es el principal motivo de sizing fallido.

La fórmula central: dos presupuestos que se cruzan

El cálculo se resuelve en dos cuentas independientes que después se cruzan. La menor de las dos manda.

Presupuesto de VRAM

Para una GPU con VRAM total $V$, el espacio disponible para KV cache es:

$$V_{\text{kv}} = V - V_{\text{model}} - V_{\text{activations}} - V_{\text{overhead}}$$

donde:

$V_{\text{model}}$ es el tamaño de los pesos: para un modelo de $P$ parámetros en formato $b$ bytes/parámetro, $V_{\text{model}} = P \cdot b$. Llama 70B BF16 = $70 \times 10^9 \times 2 = 140$ GB. En tensor parallel TP=4, cada GPU lleva $140 / 4 = 35$ GB.
$V_{\text{activations}}$ son los buffers intermedios del forward pass. Para vLLM con batch razonable, entre 2 y 6 GB por GPU dependiendo de batch size y longitud máxima.
$V_{\text{overhead}}$ son CUDA context, NCCL buffers, pool de PagedAttention, paged blocks reservados. 2–4 GB típicos.

El KV cache budget por GPU queda como el residuo. Para H100 SXM 80 GB con Llama 70B TP=4 BF16:

$$V_{\text{kv}} = 80 - 35 - 4 - 3 = 38 \text{ GB por GPU} = 152 \text{ GB agregados sobre TP=4}$$

El coste por token de KV cache para un modelo con $L$ capas, $H_{\text{kv}}$ heads KV (GQA), dimensión por head $d_h$, en formato $b$ bytes:

$$\text{kv_per_token} = 2 \cdot L \cdot H_{\text{kv}} \cdot d_h \cdot b$$

El factor 2 es porque se guardan K y V. Para Llama 70B (L=80, $H_{\text{kv}}$=8 con GQA, $d_h$=128, BF16 = 2 bytes):

$$\text{kv_per_token} = 2 \cdot 80 \cdot 8 \cdot 128 \cdot 2 = 327,680 \text{ bytes} = 320 \text{ KB/token}$$

Y la concurrencia máxima al contexto promedio $C$:

$$N_{\text{max}} = \frac{V_{\text{kv}}}{C \cdot \text{kv_per_token}}$$

Con $V_{\text{kv}}$ agregado de 152 GB y un contexto promedio de 1 500 tokens (800 prompt + 700 generados en el peor instante de la conversación):

$$N_{\text{max}} = \frac{152 \times 10^9}{1,500 \cdot 320 \times 10^3} \approx 316 \text{ requests concurrentes}$$

Este es el techo físico de concurrencia para esa réplica. No es lo que vas a usar — es lo que no puedes superar sin OOM. El número operativo está bastante por debajo (head-room para spikes).

Presupuesto de tiempo

Aquí entran dos sub-cálculos: el de decode (memory-bound) y el de prefill (compute-bound).

Decode TPOT. Por cada token que se genera, hay que pasear los pesos del modelo (relevantes para esa request) y leer el KV cache acumulado. El cuello de botella es el ancho de banda HBM. Para una GPU con ancho $B$ GB/s y un modelo de $V_{\text{model_per_gpu}}$ GB de pesos:

$$\text{tpot}{\text{teórico}} \approx \frac{V{\text{model_per_gpu}}}{B}$$

Para H100 SXM con HBM3 a 3.35 TB/s y Llama 70B TP=4 BF16 (35 GB/GPU):

$$\text{tpot}_{\text{teórico}} \approx \frac{35}{3,350} \approx 10.4 \text{ ms/token}$$

Este es el mejor caso teórico con batch=1 y eficiencia HBM al 100 %. En la práctica vLLM en H100 con Llama 70B TP=4 alcanza 12–18 ms/token a batch bajo y 30–45 ms/token a batch alto (con concurrencia 32, los tokens compiten por la HBM compartida). El número operacional defendible: 35 ms/token en concurrencia 24–32.

Prefill throughput. El prefill procesa N tokens de prompt en un único forward pass. Es compute-bound: cuello en FLOPs. Para H100 SXM con 989 TFLOPs BF16 sostenidos y Llama 70B (cada forward pass cuesta aproximadamente $2 \cdot P \cdot N$ FLOPs por sequence de longitud N):

$$\text{prefill_tps} = \frac{4 \cdot \text{TFLOPs} \cdot \eta}{2 \cdot P} = \frac{4 \cdot 989 \times 10^{12} \cdot 0.5}{2 \cdot 70 \times 10^9} \approx 14,000 \text{ tokens/s}$$

(el factor 4 son las GPUs en TP, $\eta$ es eficiencia real entre 0.4 y 0.6 en H100). Un prompt de 800 tokens tarda en prefill:

$$\text{prefill_time} = \frac{800}{14,000} \approx 57 \text{ ms}$$

Sumando una cola típica de 100–300 ms a concurrencia alta, TTFT P95 ≈ 350–500 ms para ese perfil. Muy por debajo del objetivo de 1.5 s — hay margen.

El cruce

La concurrencia operativa real $N_{\text{op}}$ es el mínimo entre el techo de VRAM, la concurrencia a la que el TPOT empieza a degradar por encima del SLO, y la concurrencia a la que el TTFT empieza a degradar por encima del SLO (cola de prefill). Para el ejemplo:

VRAM techo: 316.
TPOT degrada a 80 ms (SLO) alrededor de concurrencia ~80–100 (medido empíricamente con benchmark, no fórmula cerrada).
TTFT degrada a 1.5 s alrededor de concurrencia ~40–60 por cola de prefill.

La concurrencia operativa de la réplica es ~50. Aplicando un 25 % de head-room para spikes y rebalanceos, concurrencia objetivo por réplica ≈ 35–40.

Hoja de cálculo paso a paso: Llama 70B BF16 en 4×H100 SXM

Entrada del ejercicio:

SLO: TTFT P95 ≤ 1.5 s; TPOT P95 ≤ 60 ms; 200 RPS sostenidos.
Workload: prompt P50=600, P95=1 200, P99=2 500; output P50=180, P95=500, P99=900. Promedio prompt 800, output 250.
Hardware genérico: 4×H100 SXM 80 GB con NVLink, motor vLLM v1, tensor parallel 4, BF16.

Paso 1 — VRAM por GPU. Pesos 35 GB, activaciones 4 GB, overhead 3 GB → KV budget 38 GB/GPU = 152 GB agregados. KV/token a Llama 70B GQA = 320 KB. Techo de tokens vivos en cache: $152 \times 10^9 / 320 \times 10^3 \approx 475,000$ tokens. Al contexto promedio operacional (800 prompt + 200 ya generados = 1 000 tokens vivos por request), techo de concurrencia $\approx 475$.

Paso 2 — duración media de una request. Prefill 800 tokens / 14 000 tps = 57 ms. Decode 250 tokens × 35 ms/token = 8 750 ms. Total $\approx 8.8$ s por request.

Paso 3 — throughput de la réplica. Si la réplica sostiene concurrencia operativa 40 y cada request dura 8.8 s, la réplica entrega aproximadamente $40 / 8.8 \approx 4.5$ requests/s en régimen estacionario.

Paso 4 — número de réplicas. Para 200 RPS objetivo: $200 / 4.5 \approx 45$ réplicas. Eso son 45 × 4 = 180 GPUs. Demasiado: este sizing no funciona porque el coste por request es alto.

Paso 5 — revisar palancas. Antes de comprar más hardware, hay tres palancas que se exploran en este orden:

Quantization. Bajar a FP8 reduce pesos a 17.5 GB/GPU (queda más VRAM para KV cache → más concurrencia), aproximadamente duplica tokens/s en decode (HBM saturada por la mitad), y degrada calidad MMLU típicamente 0.5–1.5 puntos en modelos como Llama 70B. Reescribiendo el cálculo en FP8: TPOT baja a ~18 ms, tiempo total por request a 4.7 s, RPS por réplica sube a ~8.5, réplicas necesarias ≈ 24, equivalente a 96 GPUs.
Speculative decoding. Con un drafter pequeño y aceptación del 60–70 %, TPOT efectivo cae 30–40 %. RPS por réplica sube a ~12, réplicas ≈ 17 = 68 GPUs.
Disaggregated serving. Separar prefill workers y decode workers permite escalar cada uno a la mezcla real del workload —ver Disaggregated serving—. Suele recortar otro 20–40 % bajo workloads asimétricos.

Paso 6 — sizing recomendado. Para el ejemplo, con FP8 + speculative decoding y un head-room del 25 %: 20 réplicas vLLM TP=4 sobre 80 H100 SXM. Si el equipo no quiere depender de quantization agresiva (BF16 puro para máxima fidelidad), el cálculo sube a 30 réplicas = 120 GPUs y obliga a renegociar SLO o presupuesto.

Paso 7 — escribir los supuestos. Esta es la parte que ningún sizing válido se salta. En el repo del equipo, junto al cálculo:

# sizing/llama70b-prod.yaml
fecha: 2026-06-01
slo:
 ttft_p95_ms: 1500
 tpot_p95_ms: 60
 rps_target: 200
workload:
 prompt_tokens_p50: 600
 prompt_tokens_p95: 1200
 output_tokens_p50: 180
 output_tokens_p95: 500
 asunto: chat productivo con RAG ligero
modelo:
 arquitectura: llama-70b-instruct
 formato_pesos: fp8
 motor: vllm-v1
hardware:
 gpu: H100-SXM-80GB
 topologia: TP=4 con NVLink intra-nodo
 red_inter_replica: 25 GbE
optimizaciones:
 - paged_attention
 - chunked_prefill
 - speculative_decoding (drafter llama-1.1b, aceptación esperada 65%)
asunciones_criticas:
 - utilizacion_hbm_eficiente: 0.55
 - head_room_pico_sobre_p95: 0.25
 - aceptacion_speculative_min: 0.55
plan_validacion:
 - benchmark vllm bench serve antes de procurement
 - canary 10% durante 7 días post-deploy

Sin este YAML, el cálculo no es reproducible un mes después.

Caso MoE: Mixtral 8×22B (~141 B totales, 39 B activos)

Los MoE cambian el cálculo en una dimensión clave: los pesos totales son grandes pero los pesos activos por token son pequeños. Para Mixtral 8×22B con top-2 routing:

VRAM de pesos: $141 \times 2 = 282$ GB BF16. Con TP=4 → 70 GB/GPU. No cabe en H100 80 GB con KV cache + activaciones. Hace falta TP=8 (~35 GB/GPU) o FP8 con TP=4 (~35 GB/GPU).
Decode TPOT: dominado por los pesos leídos por token, que son $\sim 39 / 8 \cdot 2 \approx 9.75$ GB/GPU con TP=4 (un experto top-2 por token, dividido entre 4 GPUs). En H100 con HBM 3.35 TB/s, TPOT teórico ≈ 3 ms/token. En la práctica, 10–20 ms a concurrencia razonable.
Prefill: similar al modelo denso de los pesos activos, ~39 B FLOPs/token.

El sizing MoE suele entregar más RPS por GPU que un denso equivalente — el coste por token bajo compensa el extra de VRAM. Ver MoE inference para el detalle del routing y por qué el batch alto es decisivo para que cada experto vea suficientes tokens.

Tabla de sensibilidad: contexto y quantization

Para Llama 70B sobre 4×H100 SXM (TP=4), concurrencia operativa por réplica con SLO TTFT 1.5 s / TPOT 60 ms:

Contexto promedio	BF16	FP8	INT4 (AWQ)
500 tokens	55	110	180
1 000 tokens	40	80	130
2 000 tokens	24	50	85
4 000 tokens	12	26	48
8 000 tokens	6	13	25

Números aproximados de benchmark vLLM público a junio 2026, con variación ±20 % según versión del motor y headroom adoptado. Para validar en tu hardware: vllm bench serve con tu perfil de prompts reales.

Las cinco trampas habituales

Trampa 1 — confundir media con P95. El throughput medio de una hora puede ser 50 RPS pero el pico de 5 minutos llegar a 180 RPS. Dimensionar contra la media garantiza romper SLO en cada pico. Regla: dimensionar contra P95 horario, con head-room del 20–30 % sobre P95.

Trampa 2 — no medir el reparto prefill/decode real. Un workload de “RAG con respuestas cortas” tiene 70–80 % del tiempo de GPU en prefill; un “writing assistant que genera ensayos” tiene 80 % en decode. Las optimizaciones útiles (chunked prefill vs speculative decoding) cambian radicalmente. Sin medirlo, se compra hardware mal balanceado.

Trampa 3 — dimensionar sin head-room para retrain ni rollback. El cluster productivo no es solo el motor de inferencia: hay batch de re-embeddings cuando cambia el modelo de embeddings, eval continuo de canary —ver Canary, blue-green y shadow—, fine-tune ligero, hot stand-by para rollback. Reservar 15–25 % de capacidad para esos workloads no negociables.

Trampa 4 — “GPU al 100 % de SM utilization” como objetivo. SM occupancy del 95 % con HBM saturada produce el mismo throughput que SM al 60 % con HBM saturada. El cuello de botella en decode es la HBM. Optimizar para “GPU usage 100 %” sin mirar HBM utilization y arithmetic intensity hace gastar más en GPU sin ganar throughput. Ver Observabilidad GPU para inferencia LLM para qué métricas mirar realmente.

Trampa 5 — no documentar los supuestos. Un sizing sin YAML reproducible (workload, modelo, motor, head-room, asunciones críticas) deja al equipo sin manera de saber qué cambió cuando el cluster ya no llega a SLO seis meses después. Documentar es barato; perder un trimestre depurando, no.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4×H100 SXM 80 GB con NVLink intra-nodo y 25 GbE entre nodos, las configuraciones recurrentes en mayo 2026 son:

Modelo	Formato	TP	Réplicas que caben	RPS típico por nodo (ctx 1K)
Llama 8B	BF16	1	4 (una por GPU)	240–320
Llama 8B	FP8	1	4	450–600
Llama 70B	BF16	4	1	30–45
Llama 70B	FP8	4	1	60–90
Llama 70B	INT4 AWQ	2	2	90–130
Mixtral 8×22B	FP8	4	1	90–140
Qwen 72B	BF16	4	1	28–42

Estos números son órdenes de magnitud para empezar la conversación, no compromisos. El sizing definitivo se valida con vllm bench serve o genai-perf (NVIDIA) usando el perfil de prompts/outputs reales del cliente. La asimetría prefill/decode del workload de cada caso puede mover estos números un 30–50 % arriba o abajo.

Para clusters de 8×H100 SXM (típico de servidores DGX o réplicas equivalentes), las opciones se abren a TP=8 para modelos clase 405B o multi-réplica TP=2 para modelos 70B con mayor densidad. La métrica que decide es siempre la misma: tokens cumpliendo SLO por kW y por euro de hardware amortizado.

Cómo se valida el sizing antes de comprar

El sizing en hoja de cálculo es la primera mitad. La segunda es el benchmark de validación.

Stage 1 — sizing servilleta. Las fórmulas de este post sobre el SLO y el workload esperado. Salida: número aproximado de réplicas y topología.

Stage 2 — micro-benchmark sintético. En una GPU prestada o alquilada por días, levantar el motor con el modelo elegido y correr vllm bench serve con prompts de longitudes representativas. Validar TPOT, prefill TPS y techo de concurrencia. Calibrar el factor de eficiencia HBM ($\eta$) usado en las fórmulas.

Stage 3 — load test con tráfico realista. Generar tráfico siguiendo la distribución real del workload del cliente (no Poisson, no constante: la traza real). Medir P50/P95/P99 de TTFT, TPOT, throughput. Confirmar el head-room.

Stage 4 — canary en producción. Con el cluster dimensionado, encaminar el 5–10 % del tráfico real durante 7–14 días antes de cerrar el procurement de hardware adicional. Ver Canary, blue-green y shadow para la mecánica.

Saltar de Stage 1 a procurement total es la causa más frecuente de cluster sobredimensionado en el 40 % y subdimensionado en el 60 % al mismo tiempo, en regiones distintas del workload. Cuatro semanas de validación bien hechas ahorran cuatro meses de refactor.

Lo que no hemos cubierto (próximos artículos)

Las métricas de observabilidad que cierran el bucle del sizing en producción — ver Observabilidad GPU para inferencia LLM.
El autoscaling que ajusta réplicas a la curva real de tráfico — ver Autoscaling LLM en Kubernetes.
El cost accounting detallado por tenant (showback / chargeback) sobre el hardware dimensionado.
El sizing para fine-tuning continuo (PEFT y entrenamiento ligero) que comparte cluster con la inferencia.

Ver también

KV cache: la memoria de trabajo que sostiene la inferencia LLM — el componente que domina el presupuesto de VRAM.
Continuous batching — qué define la utilización efectiva del compute y la métrica goodput.
Disaggregated serving prefill/decode — palanca avanzada para workloads asimétricos.
MoE inference — cómo cambian las cuentas con modelos MoE.
Quantization para inferencia — qué cuesta y qué ahorra cada formato.
Siete capas del stack de inferencia LLM on-premise — las piezas que el sizing presupone.
Entornos mixtos NVIDIA + Intel para inferencia LLM — el sizing cierra mejor cuando se acepta heterogeneidad: embeddings y reranker en Intel Xeon AMX liberan H100 para el LLM grande, sin comprar más GPU.

Referencias

Kwon et al. — vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention (SOSP 2023).
Zhong et al. — DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving (OSDI 2024).
Agrawal et al. — Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve (OSDI 2024).
NVIDIA — H100 Tensor Core GPU Architecture Whitepaper (memoria HBM3, bandwidth, FLOPs sostenidos).
vLLM project — vllm bench serve reference (CLI de benchmarking incluida en el repo).
NVIDIA — genai-perf (herramienta oficial para benchmark de servicios LLM).

Operaciones on lo0 — Blog Técnico

Entornos mixtos NVIDIA + Intel para inferencia LLM: del cluster H100 central al NUC en la sucursal

TL;DR

Estás aquí: DEPLOY (con heterogeneidad como decisión)

La analogía: la fábrica con varias máquinas distintas

Tres razones operativas para la heterogeneidad

Razón 1 — coste

Razón 2 — soberanía y diversificación de la cadena de suministro

Razón 3 — edge

Hardware Intel relevante (junio 2026)

Intel Gaudi 3 — la nota crítica sobre el marketing

Intel Xeon 6 con AMX — el caballo de batalla CPU

Intel Arc Pro B60 y Battlematrix

Intel NUC con NPU — el edge node

Software Intel — la pila relevante

Los cuatro patrones canónicos

Patrón 1 — embeddings + reranker en Intel

Patrón 2 — guardrails + PII redact en NUC near edge

Patrón 3 — speculative decoding drafter en NUC

Patrón 4 — dev workstations NUC

Observabilidad unificada en cluster heterogéneo

Routing por capability — del router L7 al heterogéneo

Pitfalls específicos

Aplicado a un cluster on-premise genérico

Lo que no hemos cubierto (próximos posts)

Ver también

Referencias

Runbooks de incident response para inferencia LLM: cada alerta a una acción concreta con Kafka y Keep

TL;DR

Estás aquí: OBSERVE → DEPLOY (incident response cierra el bucle)

La analogía: la sala de control de un reactor nuclear

La arquitectura del incident pipeline

Las seis alertas críticas y sus runbooks

RB-01 · GpuHbmNearOom — HBM > 92 % sostenido

RB-02 · GpuThermalOrPowerThrottle — bit ≠ 0 ni Idle en CLOCK_THROTTLE_REASONS

RB-03 · GpuXidErrorDetected — increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0

RB-04 · GpuEccDoubleBit — DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0

RB-05 · VllmKvCachePoolNearFull — gpu_cache_usage_perc > 95 % sostenido 3 min

RB-06 · VllmTtftP95OutOfSlo — TTFT P95 > 1.5 s durante 5 min

Workflows Keep YAML — tres ejemplos completos

Workflow 1 — xid-detected.yaml

Workflow 2 — ecc-dbe.yaml — paginación inmediata

Workflow 3 — canary-rollback.yaml — TTFT P95 fuera de SLO

El schema canónico de eventos Kafka

Encaje formal en gestión de incidentes

ISO/IEC 27035 — gestión de incidentes de seguridad de la información

ENS (Esquema Nacional de Seguridad) — controles op.exp

NIS2 — notificación a autoridad competente

EU AI Act — art. 73 (serious incident reporting)

ISO/IEC 42001 — AIMS cláusula 10 mejora continua

Cuatro anti-patrones

Aplicado a hardware on-premise típico

Lo que no hemos cubierto (próximos posts)

Ver también

Referencias

Anatomía de las doce métricas DCGM y cinco vLLM: analogías, anomalías documentadas y casos reales 2024-2026

TL;DR

Estás aquí: OBSERVE — la capa de diagnóstico

Familia 1 — Compute

DCGM_FI_PROF_SM_OCCUPANCY — ¿hay trabajo paralelo en los motores?

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — ¿los tensor cores producen?

DCGM_FI_PROF_DRAM_ACTIVE — ¿está la HBM saturada?

Familia 2 — Memoria

DCGM_FI_DEV_FB_USED — ¿cuánta VRAM lleva consumida?

DCGM_FI_DEV_FB_FREE — el complemento absoluto

DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL — ¿el bus interno aguanta?

Familia 3 — Térmico y energético

DCGM_FI_DEV_GPU_TEMP — ¿la GPU respira?

DCGM_FI_DEV_POWER_USAGE — ¿cuánto pide al enchufe?

DCGM_FI_DEV_CLOCK_THROTTLE_REASONS — ¿quién pisa el freno?

Familia 4 — Salud (los reportes catastróficos)

DCGM_FI_DEV_XID_ERRORS — los códigos rojos del driver

DCGM_FI_DEV_ECC_DBE_VOL_TOTAL — los errores que corrompen datos

DCGM_FI_DEV_RETIRED_DBE — las páginas marcadas para retirar

Las cinco métricas del motor vLLM

vllm:num_requests_running — ¿cuántas requests caben en el batch?

vllm:num_requests_waiting — el indicador primario de saturación

vllm:gpu_cache_usage_perc — el pool de KV cache

vllm:time_to_first_token_seconds — la latencia visible al cliente

vllm:time_per_output_token_seconds — la fluidez del streaming

RB-01 · `GpuHbmNearOom` — HBM > 92 % sostenido

RB-02 · `GpuThermalOrPowerThrottle` — bit ≠ 0 ni Idle en CLOCK_THROTTLE_REASONS

RB-03 · `GpuXidErrorDetected` — `increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0`

RB-04 · `GpuEccDoubleBit` — `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0`

RB-05 · `VllmKvCachePoolNearFull` — `gpu_cache_usage_perc > 95 %` sostenido 3 min

RB-06 · `VllmTtftP95OutOfSlo` — TTFT P95 > 1.5 s durante 5 min

Workflow 1 — `xid-detected.yaml`

Workflow 2 — `ecc-dbe.yaml` — paginación inmediata

Workflow 3 — `canary-rollback.yaml` — TTFT P95 fuera de SLO

`DCGM_FI_PROF_SM_OCCUPANCY` — ¿hay trabajo paralelo en los motores?

`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE` — ¿los tensor cores producen?

`DCGM_FI_PROF_DRAM_ACTIVE` — ¿está la HBM saturada?

`DCGM_FI_DEV_FB_USED` — ¿cuánta VRAM lleva consumida?

`DCGM_FI_DEV_FB_FREE` — el complemento absoluto

`DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL` — ¿el bus interno aguanta?

`DCGM_FI_DEV_GPU_TEMP` — ¿la GPU respira?

`DCGM_FI_DEV_POWER_USAGE` — ¿cuánto pide al enchufe?

`DCGM_FI_DEV_CLOCK_THROTTLE_REASONS` — ¿quién pisa el freno?

`DCGM_FI_DEV_XID_ERRORS` — los códigos rojos del driver

`DCGM_FI_DEV_ECC_DBE_VOL_TOTAL` — los errores que corrompen datos

`DCGM_FI_DEV_RETIRED_DBE` — las páginas marcadas para retirar

`vllm:num_requests_running` — ¿cuántas requests caben en el batch?

`vllm:num_requests_waiting` — el indicador primario de saturación

`vllm:gpu_cache_usage_perc` — el pool de KV cache

`vllm:time_to_first_token_seconds` — la latencia visible al cliente

`vllm:time_per_output_token_seconds` — la fluidez del streaming

Por qué `nvidia-smi` `GPU-Util` engaña en LLMs