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.

Xid 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?