Ejecutar trabajos

2.1La pila de software CUDA

De abajo hacia arriba:

1. Módulo del kernel (nvidia.ko y compañía). Controla el hardware, la gestión de memoria (incluida Unified Memory / UVM), las interrupciones y el reporte de errores. NVIDIA publica una versión de código abierto, open-gpu-kernel-modules, la predeterminada para Turing y posteriores. Los mensajes Xid que lees en dmesg vienen de aquí.
2. Driver de modo usuario (libcuda.so): la driver API de CUDA, incluida con el driver.
3. Runtime y toolkit de CUDA (libcudart, nvcc): contra lo que compilan las aplicaciones.
4. Bibliotecas: cuBLAS, cuDNN, NCCL, CUTLASS.
5. Frameworks: PyTorch, JAX y herramientas de más alto nivel.

Regla de compatibilidad: un driver más nuevo ejecuta runtimes de CUDA más viejos, pero no al revés. nvidia-smi muestra la versión del driver y la versión máxima de CUDA que soporta. Los contenedores traen su propio runtime pero deben usar el driver del host, inyectado por el NVIDIA Container Toolkit. Ver contenedores y GPUs.

2.2Slurm

Slurm convierte un montón de servidores en una máquina compartida. Conceptos clave:

• Particiones: grupos de nodos con nombre y límites (sinfo las lista).
• Trabajos: se envían con sbatch script.sh. Las líneas #SBATCH del script piden recursos: --nodes, --gpus-per-node, --time, --partition.
• Asignación: el planificador elige nodos (backfill, prioridad, Planificación fair-share) y ejecuta el script en el primero. srun lanza tareas en el resto.
• Estados de nodo: idle, alloc, drain (termina lo que corre, no acepta trabajo nuevo) y down.

Comandos diarios del operador

squeue --me                       # qué corre / qué espera y por qué
sacct                             # historial con códigos de salida
scontrol show job <id>            # todo sobre un trabajo
scontrol update NodeName=node-3 State=DRAIN Reason="gpu5 fan"
sinfo -R                          # por qué hay nodos en drain
scontrol requeue <id>             # reiniciar un trabajo (desde su checkpoint)

Hacer drain con un motivo claro es la forma educada de decir "este hardware es sospechoso" sin matar el trabajo de nadie.

$ sbatch train.sh
sbatch: error: Batch job submission failed: Requested node configuration is not available

2.3NCCL

NCCL ("nickel") implementa las colectivas de las que depende el entrenamiento distribuido: all-reduce, all-gather, reduce-scatter, broadcast y send/recv. Descubre la topología (NVLink, NVSwitch, PCIe, NIC) y construye anillos y árboles para aprovecharla. Ver All-reduce (anillo y árbol).

Variables de entorno que conviene conocer

• NCCL_DEBUG=INFO imprime el transporte y los canales elegidos. Léelo.
• NCCL_IB_DISABLE=1 fuerza sockets TCP en lugar de InfiniBand. Útil en una laptop y un desastre en producción.
• NCCL_SOCKET_IFNAME / NCCL_IB_HCA eligen las interfaces.

Diagnóstico

• all_reduce_perf de nccl-tests mide el bus bandwidth alcanzable. Córrelo en nodos libres para detectar enlaces malos antes que los usuarios.
• Las colectivas colgadas terminan con un watchdog timeout de PyTorch. La causa suele ser un rango malo: un enlace caído, una GPU perdida o un straggler que dejó de responder.

2.4Checkpointing y tolerancia a fallas

Con miles de GPUs, algo falla cada pocas horas. El checkpointing limita el daño: ante una falla, reinicias desde el último estado guardado y pierdes como máximo un intervalo.

Cómo elegir el intervalo: muy frecuente desperdicia tiempo de E/S; muy espaciado desperdicia cómputo cuando hay fallas. Una aproximación clásica (Young/Daly) es intervalo ≈ √(2 × costo_del_checkpoint × MTBF).

Cómo abaratarlo

• Checkpoints repartidos: cada rango escribe su parte en paralelo.
• Checkpointing asíncrono: copia a la memoria del host y escribe en segundo plano.
• Guarda varios checkpoints recientes. Los guardados corruptos o parciales ocurren.

Integración con la operación: scontrol requeue o un bucle de reintento del trabajo, más un pool de repuestos encendidos, convierten "se murió una GPU" en una pausa de 5 minutos. Ese es el ciclo que practicas en Fallen Off the Bus y The Slow Lane.

2.5Kubernetes y el GPU Operator

Kubernetes no sabe nada de GPUs por defecto. El device plugin de NVIDIA anuncia nvidia.com/gpu como recurso planificable. El GPU Operator instala y gestiona toda la pila como contenedores: driver, container toolkit, device plugin, DCGM exporter y MIG manager.

Diferencias con Slurm que importan para entrenar

• Kubernetes planifica pods de uno en uno. El entrenamiento distribuido necesita gang scheduling (todo o nada), que aportan complementos como Kueue o Volcano.
• La conciencia de topología (mismo rack, mismo dominio NVLink) requiere configuración extra.
• Brilla en flotas mixtas: servicios de inferencia, notebooks y CI junto a trabajos por lotes, a menudo en slices MIG.

Muchas organizaciones usan ambos: Slurm para el entrenamiento grande y Kubernetes para todo lo demás, a veces sobre el mismo hardware.

2.6Planificación fair-share

En un clúster compartido, "el primero que llega se sirve primero" permite que los 1,000 trabajos encolados de un equipo dejen sin recursos a todos los demás. La planificación fair-share (p. ej. la prioridad multifactor de Slurm) baja la prioridad de usuarios y cuentas que usaron recientemente más de lo que les toca, y ese uso decae con el tiempo.

Los ingredientes

• Shares: lo que le corresponde a cada cuenta, a menudo según financiamiento o tamaño del equipo.
• Decaimiento del uso: una vida media (p. ej. 7 días) para que el uso pasado se perdone gradualmente.
• Límites de QOS: topes de GPUs concurrentes, tiempo de pared o número de trabajos, para que ningún trabajo bloquee el clúster.
• Preemption: los trabajos de baja prioridad u oportunistas pueden guardar checkpoint y volver a la cola cuando llega trabajo prioritario. Solo funciona si los trabajos hacen Checkpointing y tolerancia a fallas bien.

La equidad también es transparencia: publica el uso por equipo, los tiempos de espera en cola y la energía, para que las discusiones de asignación usen datos en lugar de anécdotas.