Anatomía de un clúster de GPU

1.1GPU

Una CPU dedica sus transistores a que un hilo vaya rápido: cachés profundas, predicción de saltos, ejecución fuera de orden. Una GPU los dedica a muchos carriles de aritmética. Oculta la latencia de memoria manteniendo miles de hilos en vuelo y cambiando entre ellos sin costo.

Para ML y HPC ese intercambio es ideal. El trabajo es sobre todo álgebra lineal densa: la misma operación sobre arreglos enormes. Una GPU de centro de datos como la H100 combina ~130 streaming multiprocessors con tensor cores y 80 GB de HBM a varios TB/s.

Qué hace rápida a una GPU en la práctica

• Suficiente trabajo paralelo para llenar todos los SM (ver ocupación).
• Intensidad aritmética lo bastante alta para estar limitado por cómputo y no por memoria (ver Modelo roofline).
• Datos que se quedan en el dispositivo. Las transferencias por PCIe son ~50× más lentas que HBM.

En un clúster, la GPU es un nodo de una jerarquía: GPU → NVLink dentro del servidor → InfiniBand y RoCE entre servidores. Casi toda la ingeniería de clústeres consiste en mantener ocupada esa jerarquía.

1.2Streaming Multiprocessor (SM)

Un SM es más o menos lo que un "núcleo" es en una CPU, pero diseñado para rendimiento. Cada SM tiene planificadores de warps, un banco de registros grande, memoria compartida / L1 configurable y unidades de ejecución: "CUDA cores" FP32/INT, unidades de funciones especiales y tensor cores.

Un lanzamiento de kernel se divide en thread blocks. Cada bloque cae en un SM y se queda ahí. El SM intercala los warps de todos los bloques residentes en cada ciclo, así que cuando un warp espera a la memoria otro emite instrucciones.

Por qué te importa como operador

• Número de SM × reloj fija los FLOP/s máximos. Una GPU limitada al 55% del reloj (por temperatura o potencia) entrega ~55% del cómputo. Ver potencia y temperatura.
• DCGM_FI_PROF_SM_ACTIVE y SM_OCCUPANCY (de DCGM) te dicen si los SM están realmente ocupados. La "GPU utilization" de nvidia-smi solo significa que algún kernel estaba corriendo, no que todos los SM trabajaran.

1.3HBM y la jerarquía de memoria

La High Bandwidth Memory apila chips de DRAM junto a la GPU sobre un interposer de silicio. Una H100 SXM tiene 80 GB a ~3.35 TB/s. Debajo están la L2 (decenas de MB), la memoria compartida/L1 de cada SM y los registros, cada uno más pequeño y más rápido.

La capacidad es el primer muro en el entrenamiento de modelos grandes. Adam en precisión mixta necesita ~16 bytes por parámetro (pesos, gradientes, copia maestra FP32 y dos momentos), antes de las activaciones. Un modelo de 7B necesita ~107 GB solo de estado, más de lo que cabe en una GPU. Por eso existen ZeRO/FSDP, el paralelismo tensorial y el checkpointing de activaciones.

El ancho de banda es el segundo muro. Cualquier kernel con baja intensidad aritmética (operaciones elemento a elemento, normalizaciones, matrices pequeñas) está limitado por el ancho de banda de HBM, no por los FLOPs. Ver Modelo roofline.

Prueba la calculadora de abajo: cambia el modelo, la etapa de ZeRO y el paralelismo, y mira la memoria por GPU frente a la línea de 80 GB.

1.4PCIe

PCI Express conecta las GPUs con la CPU del host, las NIC y el almacenamiento. Un enlace Gen5 x16 mueve ~64 GB/s por dirección; Gen4 x16, ~32 GB/s. Es suficiente para cargar datos, pero lento para el tráfico GPU a GPU durante el entrenamiento.

Por qué importa

• Las GPUs sin NVLink (p. ej. L40S) deben hacer todo el tráfico entre pares por PCIe, a menudo pasando por el root complex de la CPU. El paralelismo tensorial sufre mucho.
• GPUDirect RDMA permite que una NIC lea y escriba la memoria de la GPU directamente por PCIe, sin pasar por la memoria del host. Los buenos servidores ponen cada GPU con una NIC bajo el mismo switch PCIe. Compruébalo con nvidia-smi topo -m.
• "Fallen off the bus" (Xid 79) significa literalmente que la GPU desapareció de PCIe.

1.5NVLink

NVLink es una interconexión punto a punto entre GPUs. Una H100 SXM tiene 18 enlaces NVLink 4 que suman ~900 GB/s bidireccionales (~450 GB/s por sentido). A través de NVSwitch, las 8 GPUs de un servidor HGX hablan entre sí a máxima velocidad.

Regla de diseño: pon el paralelismo más conversador en el enlace más rápido. El paralelismo tensorial hace varios all-reduce por capa, así que vive dentro del dominio NVLink. El paralelismo de datos, que sincroniza una vez por paso y se solapa con el cómputo, puede cruzar InfiniBand y RoCE.

Modo de falla: los errores de NVLink aparecen como Xid 74. Un enlace degradado obliga a que el tráfico vaya por PCIe y ralentiza las colectivas en silencio. nvidia-smi nvlink -s muestra el estado de cada enlace, y all_reduce_perf (nccl-tests) en un nodo libre muestra la caída de ancho de banda.

$ nvidia-smi nvlink -s -i 2
GPU 2: NVIDIA H100 80GB HBM3
	 Link 3: 26.562 GB/s
	 Link 4: <inactive>
	 Link 5: 26.562 GB/s

1.6NVSwitch

Sin un switch, NVLink es punto a punto, así que cada GPU solo se conecta con unas pocas vecinas. NVSwitch construye un crossbar sin bloqueo: en un servidor HGX H100, cuatro chips NVSwitch conectan las 8 GPUs todas con todas a pleno ancho de banda NVLink.

Los sistemas más nuevos extienden el dominio NVLink más allá del servidor (p. ej. racks NVL72), de modo que 72 GPUs funcionan como una gran isla de paralelismo tensorial. La regla de NVLink sigue valiendo: cuanto mayor el dominio NVLink, mayores grupos de paralelismo tensorial o de expertos puedes usar sin tocar la red de escalado, más lenta.

nvidia-smi topo -m muestra NV18 (18 enlaces agrupados) entre cada par de GPUs en un sistema con NVSwitch.

1.7InfiniBand y RoCE

Entre servidores, las GPUs se comunican por una red de escalado (scale-out). Dominan dos familias:

• InfiniBand (IB): una red RDMA diseñada para esto. NDR funciona a 400 Gb/s por puerto con latencia muy baja y control de flujo sin pérdidas basado en créditos.
• RoCE v2: RDMA sobre Ethernet convergente. La misma API de verbs sobre Ethernet. Requiere configuración cuidadosa (PFC/ECN) para no perder paquetes, pero es más barata y conocida por los equipos de redes.

Los servidores de entrenamiento modernos conectan una NIC de 400G por GPU (diseño rail-optimized), así que cada GPU obtiene ~50 GB/s de ancho de banda de escalado vía GPUDirect RDMA.

Lista de verificación

• ibstat debe mostrar cada puerto Active / LinkUp a la velocidad esperada.
• NCCL registra NET/IB cuando usa RDMA y NET/Socket cuando recurrió a TCP, una clásica ralentización silenciosa de 10× (a menudo por NCCL_IB_DISABLE=1 o una mala configuración de HCA).
• Si un puerto se cae a mitad de un trabajo, las colectivas se cuelgan hasta que expira el watchdog de NCCL.

NCCL INFO NET/Socket : Using [0]eth0:10.0.1.12<0>
NCCL INFO NCCL_IB_DISABLE set by environment to 1.

1.8Topología del clúster

La red de un clúster de GPU suele ser un fat tree. Los switches leaf conectan servidores y los switches spine conectan los leaf. Si la capacidad hacia arriba iguala a la de hacia abajo, la red es sin bloqueo (1:1). Los diseños más baratos sobresuscriben (p. ej. 2:1), lo que está bien para tráfico web y es doloroso para all-reduce, donde todos transmiten a la vez.

Los diseños rail-optimized conectan la NIC i de cada servidor al mismo switch leaf ("rail i"). Así, los algoritmos de anillo y árbol de NCCL mantienen la mayor parte del tráfico en un solo rail, a un salto de distancia.

Reglas prácticas

• La jerarquía de ancho de banda (HBM ≫ NVLink ≫ IB ≫ almacenamiento) debe corresponder a la jerarquía de paralelismo. Ver paralelismo tensorial, paralelismo de pipeline y paralelismo de datos.
• Ten capacidad de sobra. Un nodo de repuesto encendido convierte una falla de hardware en un requeue en lugar de una caída. Ver Checkpointing y tolerancia a fallas.
• La potencia y la refrigeración también son topología. Los racks tienen presupuestos de kW, y la refrigeración líquida cambia lo que cabe. Ver energía y carbono.