Vigilar la flota

3.1nvidia-smi

nvidia-smi habla con el driver a través de NVML. La tabla predeterminada muestra para cada GPU la temperatura, el consumo frente al límite, el uso de memoria, la utilización y los procesos que la usan.

Las vistas que responden preguntas reales

nvidia-smi                                   # resumen + procesos
nvidia-smi -q -d PERFORMANCE                 # ¿por qué están bajos los relojes? (event reasons)
nvidia-smi -q -d TEMPERATURE,POWER,ECC       # temperatura, límites de potencia, errores de memoria
nvidia-smi --query-gpu=index,temperature.gpu,clocks.sm,power.draw --format=csv
nvidia-smi topo -m                           # matriz de topología NVLink/PCIe/NIC
nvidia-smi nvlink -s                         # estado de cada enlace NVLink
sudo nvidia-smi -pl 500                      # fijar un límite de potencia

Advertencia: "GPU-Util" significa que había un kernel corriendo durante la ventana de muestreo. No significa que la GPU estuviera ocupada. Una GPU esperando en una barrera a un straggler sigue girando. Para métricas reales de saturación usa los campos de profiling de DCGM, como actividad de SM y de tensor pipes.

| N/A   85C    P0             437W / 700W |  70471MiB / 81560MiB |   98%      Default |

3.2Potencia y temperatura

Cada GPU tiene un límite de potencia (TDP; 700 W en la H100 SXM) y umbrales térmicos. Cuando superaría cualquiera de ellos, el firmware baja los relojes:

• SW Power Cap: está consumiendo el límite configurado; los relojes bajan un poco. Suele ser intencional. Ver limitación de potencia.
• HW Slowdown / HW Thermal Slowdown: un freno de emergencia, normalmente por sobrecalentamiento (ventilador fallido, flujo de aire bloqueado, aire de entrada caliente). Los relojes pueden bajar a la mitad.

En el entrenamiento síncrono, una sola GPU limitada se convierte en una ralentización de todo el clúster. Cada colectiva la espera. Eso es un straggler.

Dónde mirar

• nvidia-smi -q -d PERFORMANCE muestra las "Clocks Event Reasons" (antes throttle reasons).
• nvidia-smi -q -d TEMPERATURE muestra la temperatura actual, la de slowdown y la de apagado.
• Campos de DCGM como DCGM_FI_DEV_GPU_TEMP, DCGM_FI_DEV_POWER_USAGE y la máscara de throttling de reloj alimentan las alertas.

    Clocks Event Reasons
        SW Power Cap                      : Not Active
        HW Slowdown                       : Active
            HW Thermal Slowdown           : Active

3.3Errores Xid

Un Xid es la forma del driver de decir "esta GPU tuvo un problema". Aparece en el log del kernel (dmesg, journalctl -k) como NVRM: Xid (PCI:0000:xx:00.0): <código>, .... Los mensajes los emite el driver del kernel, que puedes leer en open-gpu-kernel-modules de NVIDIA.

Códigos que todo operador de GPUs debería reconocer

Patrón de operación: alerta de Xid vía DCGM, drain del nodo en Slurm con el Xid en el motivo, requeue de los trabajos afectados desde sus checkpoints y luego diagnóstico fuera de línea.

NVRM: Xid (PCI:0000:9a:00.0): 79, pid='<unknown>', name=<unknown>, GPU has fallen off the bus.

3.4Errores ECC y row remapping

Las GPUs de centro de datos protegen la HBM (y la SRAM del chip) con ECC:

• Un bit (corregible): se corrige al vuelo y se cuenta. Un conteo que crece despacio es normal. Uno que crece rápido es una advertencia.
• Doble bit (no corregible, DBE): el dato se pierde. La aplicación recibe un error (Xid 48 / 94 / 95) y la GPU normalmente necesita un reset.

A100 y posteriores usan row remapping: una fila de DRAM mala se reemplaza por una de repuesto en el siguiente reset de la GPU. nvidia-smi -q -d ECC muestra "Remapped Rows → Pending: Yes" hasta que hagas el reset. Si el remapeo falla (se agotaron los repuestos), hay que reemplazar la GPU.

Procedimiento: drain → esperar a que salgan los trabajos → nvidia-smi -r -i <gpu> → dcgmi diag -r 2 → volver a servicio si sale limpia.

3.5DCGM

DCGM ejecuta un host engine (nv-hostengine) en cada nodo y expone:

• Campos de telemetría: temperatura, potencia, relojes, ECC, contadores NVLink, eventos Xid y métricas de profiling (SM_ACTIVE, SM_OCCUPANCY, PIPE_TENSOR_ACTIVE, DRAM_ACTIVE).
• Health watches que señalan problemas térmicos, de potencia, memoria, PCIe y NVLink.
• Diagnósticos: dcgmi diag -r 1|2|3, desde chequeos rápidos de despliegue hasta pruebas de estrés. Corre el nivel 1 antes de que un nodo vuelva al pool y el nivel 3 después de trabajo de hardware.
• dcgm-exporter para Prometheus, que alimenta paneles de Grafana y reglas de alerta.

Alertas que conviene tener desde el primer día

• Cualquier evento Xid (los críticos despiertan a alguien).
• HW thermal slowdown activo durante más de un minuto.
• ECC no corregible o row remap pendiente.
• GPU ocupada mientras el planificador no muestra ningún trabajo en ese nodo. Eso atrapa fugas y Cryptojacking en clústeres de GPU.

3.6Stragglers (rezagados)

Cada colectiva es una barrera. Si una de 1,024 GPUs va 40% más lenta (por throttling térmico, un enlace inestable, un vecino ruidoso o un disco lento en un nodo), las 1,024 van 40% más lentas.

Señales

• El rendimiento cae sin errores en los logs.
• La utilización por GPU parece invertida: el straggler muestra ~100% y las demás menos, porque esperan en la barrera.
• El reloj de SM del straggler está bajo. nvidia-smi -q -d PERFORMANCE muestra HW Thermal Slowdown o SW Power Cap.
• Los tiempos de NCCL o del framework muestran un rango que siempre llega tarde a las colectivas.

Respuesta: identificar, hacer drain, reiniciar desde un checkpoint en hardware sano y abrir un ticket de hardware. A escala, automatízalo: tiempos por rango continuos, relojes y temperaturas de DCGM y aislamiento automático.

index, utilization.gpu, clocks.sm
0, 61 %, 1980 MHz
1, 60 %, 1980 MHz
5, 99 %, 1089 MHz
6, 61 %, 1980 MHz