Dcgm on lo0 — Blog Técnico

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.

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).

Dcgm on lo0 — Blog Técnico

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

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

Tres anti-patterns del operador novato

Aplicado a hardware on-premise típico

Lo que no hemos cubierto (próximos posts)

Ver también

Referencias

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

TL;DR

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

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

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

Cómo se montan en producción

Las doce métricas DCGM organizadas por familia

Familia 1 — Compute

Familia 2 — Memoria

Familia 3 — Térmico y energético

Familia 4 — Salud

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

Las seis alertas que deben pagear en producción

Tabla maestra: umbrales y queries

Tres pitfalls que confunden al operador junior

Aplicado a hardware on-premise típico

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

Ver también

Referencias

`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