Cuando entrenas un modelo de IA con miles de GPUs, el límite deja de ser el cálculo y pasa a ser la red que las conecta. Aquí verás por qué el All-Reduce hace que todo el clúster vaya al ritmo del enlace más lento, y qué hacen RDMA, el control de flujo por créditos de InfiniBand, SHARP y RoCEv2 para evitarlo.
Por qué la red limita el entrenamiento con miles de GPUs
En el entrenamiento de modelos de IA a gran escala, la potencia de una GPU individual es solo una parte del problema. Cuando pasas de un solo nodo a clústeres de miles de aceleradores, el reto ya no es el cálculo, sino el fabric, que es la red que interconecta todas esas GPUs.
No es una red convencional. Es una infraestructura diseñada para que miles de GPUs trabajen de forma estrictamente síncrona, como si fueran un solo bus de memoria gigante.
A esta escala, la eficiencia no se mide solo en ancho de banda. Se mide en la capacidad de mantener esa coordinación sin fallos durante semanas. Si la red introduce latencia irregular, el rendimiento de todo el clúster se hunde.
Vamos a ver la ingeniería que hay detrás del backend de IA, desde los protocolos de comunicación hasta cómo se mueven los datos a nivel de chip.
All-Reduce: todas las GPUs esperan a la más lenta
Entrenar un modelo grande es un proceso iterativo y sincronizado de forma rígida. En cada paso (step) del entrenamiento, cada GPU calcula sus gradientes. Pero para que el aprendizaje sea coherente, todas las GPUs tienen que promediar sus resultados antes de actualizar los pesos del modelo.
Ese promedio sigue siempre el mismo orden: cada GPU hace su cálculo local, luego intercambia sus resultados con las demás y al final se agregan todos. Esta primitiva de comunicación se llama All-Reduce.
Y aquí aparece la latencia de cola (tail latency). En un sistema síncrono, lo que tarda cada paso lo marca el flujo más lento. No importa que el 99 % de tus enlaces sean muy rápidos: si un solo paquete se retrasa por congestión, miles de GPUs se quedan paradas esperando.
En el dashboard verás las GPUs al 100 %, pero en realidad están gastando ciclos en esperar a que el último nodo termine de enviar sus datos. Por eso en IA la latencia media no importa. Lo que importa es el peor caso.
RDMA y GPUDirect RDMA: sacar a la CPU del camino
Para reducir ese impacto hay que quitar intermediarios. En una red tradicional, cada dato tiene que pasar por el sistema operativo, y eso añade latencia y, sobre todo, variabilidad. La CPU tiene que parar, copiar los datos de una zona de la memoria a otra y gestionar el envío.
El problema no es solo que esto sea lento, sino que es impredecible. Cada vez que la CPU se ocupa de preparar esos paquetes, se pierde la sincronía de todo el clúster.
Para resolverlo se usa RDMA (Remote Direct Memory Access). RDMA permite mover datos de la memoria de un servidor a la de otro con una intervención mínima de la CPU.
En los clústeres de IA se va un paso más allá con GPUDirect RDMA. Los datos van directamente de la memoria de la GPU, la VRAM, a la tarjeta de red (la NIC), sin pasar por la RAM del sistema ni por la CPU. Como la NIC accede directamente a la memoria de la GPU, desaparecen las copias intermedias. El resultado es un camino físico libre, con una latencia mínima, que permite que librerías como NCCL funcionen a su máximo rendimiento.
Incast: cuando todos los nodos envían a la vez
Con GPUDirect RDMA, el camino desde la GPU hasta el cable queda libre. Pero eso crea un problema nuevo. Al quitar los retrasos del software, ahora se inyectan datos a la velocidad máxima del hardware. Y lo más importante es que todos los nodos lo hacen exactamente al mismo tiempo.
Esto provoca un fenómeno que se llama Incast: muchas entradas convergen en una sola salida (N:1). Por ejemplo, 7 entradas de 400 Gbps de un switch intentan salir por un único puerto de 400 Gbps. Los datos no caben físicamente por ese puerto.
En una red convencional, cuando el buffer del switch se llena, el switch descarta los paquetes que sobran. En IA eso es un desastre, porque un solo paquete perdido obliga a retransmitir y detiene a todo el clúster.
Control de flujo por créditos en InfiniBand
Aquí es donde la red tradicional de internet no sirve. No se puede dejar que el azar decida qué paquetes llegan y cuáles no. Hace falta una red sin pérdidas (lossless) por diseño. Para conseguirlo de forma determinista, infraestructuras como InfiniBand usan un control de flujo basado en créditos.
Funciona así. El receptor le envía al emisor un mensaje con sus créditos, por ejemplo: «tengo espacio para 8 paquetes». El emisor descuenta un crédito con cada paquete que envía y, cuando llega a 0, se detiene.
A diferencia de Ethernet clásico, donde el emisor envía los datos y espera que haya sitio, en InfiniBand el emisor lleva la cuenta exacta del espacio disponible en el receptor. Se detiene justo antes de desbordar el buffer del switch, porque sabe que no le quedan créditos.
Solo cuando el receptor libera memoria envía créditos nuevos. Como este mecanismo lo hace el hardware, la red no pierde paquetes y el flujo se mantiene constante y predecible.
Pero incluso con una red perfecta, seguimos moviendo demasiados datos. El siguiente paso no es moverlos más rápido, sino dejar de moverlos.
SHARP: hacer la suma del All-Reduce dentro del switch
Si el problema es que se mueven demasiados datos, la solución es procesarlos mientras pasan por la red. Para eso está SHARP.
Normalmente la red solo transporta datos. Con SHARP, la parte matemática del All-Reduce, como las sumas de gradientes, se hace en el propio switch. A esto se le llama cómputo en la red (in-network computing).
El switch recibe los paquetes de varios nodos, hace la suma dentro y envía solo el resultado final. Esto reduce a la mitad el tráfico en los enlaces más cargados y libera a las GPUs de tareas de comunicación, así que el sistema escala de forma mucho más lineal.
Toda esta ingeniería, es decir, los créditos, el bypass del kernel y el cálculo en el switch, deja una pregunta: ¿cómo se implementa esto en el mundo real?
InfiniBand o Ethernet con RoCEv2
Aquí la decisión suele dividirse en dos enfoques muy distintos.
Por un lado está InfiniBand, que es la solución nativa. Todo su diseño está pensado para este tipo de tráfico, y es predecible y eficiente desde que la sacas de la caja (out of the box). A cambio, necesita infraestructura dedicada.
¿Y si quieres usar la red que ya tienes? Para eso está la otra opción: Ethernet con RoCEv2, que se pronuncia «rocky». Aquí se intenta conseguir esa misma velocidad sobre la red Ethernet tradicional. Es una opción muy potente, pero tiene un coste. Para lograr que no se pierdan paquetes y evitar el jitter, que es la variación de la latencia, exige una configuración muy compleja. No es conectar y listo: hay que pelear con la congestión todo el tiempo.
Por qué la red importa tanto como las GPUs
Después de ver toda esta ingeniería queda claro que, en un clúster de IA, la red no es un simple añadido. A esta escala, la red es lo que permite que miles de GPUs funcionen como si tuvieran una única memoria gigante.
Puedes tener las mejores GPUs del mundo, pero si el fabric no es capaz de mantener la sincronía, tu clúster irá tan lento como el enlace más congestionado. Por eso entender cómo se mueven los datos, cómo funcionan los créditos y cómo fluye la información por el hardware es tan importante como el código del propio modelo.
Lo que hemos visto
- En el entrenamiento distribuido, el All-Reduce obliga a todas las GPUs a esperar a la más lenta, así que lo que cuenta es la latencia de cola y no la media.
- RDMA y GPUDirect RDMA mueven los datos de la GPU a la tarjeta de red sin pasar por la CPU ni por copias intermedias.
- Cuando todos los nodos envían a la vez aparece el Incast, e InfiniBand lo controla con créditos para no perder paquetes.
- SHARP hace las sumas del All-Reduce dentro del switch y reduce el tráfico en los enlaces más cargados.
- InfiniBand funciona bien desde el principio pero necesita infraestructura dedicada, y RoCEv2 usa Ethernet pero exige una configuración muy compleja.