Red fabric para GPU clusters: por qué InfiniBand sigue ganando y cuándo Ethernet 800G lo alcanza

Cuando tienes un cluster de entrenamiento con 8, 16 o 64 GPUs, la red entre GPUs se vuelve el cuello de botella inmediato. La elección entre InfiniBand y Ethernet 800G afecta latencia, throughput, costo y compatibilidad con frameworks como NCCL y RCCL. Esta es la decisión técnica que define el rendimiento real de tu cluster, después de elegir las GPUs mismas.

Por qué la red del cluster es el factor crítico

El entrenamiento distribuido de modelos grandes requiere comunicación constante entre GPUs. En cada step de entrenamiento, las GPUs intercambian gradientes — para un modelo de 70B parámetros, eso son decenas de GB por step que tienen que cruzar la red en milisegundos. Si la red tarda más, el step completo se ralentiza, los GPUs quedan idle esperando datos, y tu inversión en hardware se desperdicia. Una red mal dimensionada puede reducir 30-50% el throughput efectivo del cluster.

InfiniBand: el estándar de facto

InfiniBand, en sus versiones actuales HDR (200 Gbps por puerto), NDR (400 Gbps por puerto) y XDR (800 Gbps por puerto), es la red que usa la mayoría de los hyperscalers y centros de investigación para entrenamiento de IA. Tres razones:

1. Latencia sub-microsegundo. InfiniBand tiene latencia de switch de 100-200 nanosegundos por hop. Ethernet comparable tiene 500-800 nanosegundos. Para comunicaciones frecuentes entre GPUs, esa diferencia se acumula.
2. Remote Direct Memory Access (RDMA) nativo. InfiniBand permite que una GPU lea directamente la memoria de otra GPU sin pasar por la CPU intermediaria. Eso elimina un cuello de botella en operaciones all-reduce como las que usa NCCL.
3. Optimización con frameworks. NCCL de NVIDIA, RCCL de AMD, y la mayoría de los frameworks de distributed training están optimizados para InfiniBand. Cambiar de InfiniBand a Ethernet típicamente requiere re-tuning de los parámetros de comunicación.

Ethernet 800G: la alternativa que está alcanzando

Ethernet avanzó mucho en los últimos 3 años. Las versiones 400G y 800G, combinadas con RoCE (RDMA over Converged Ethernet), prometen cerrar la brecha con InfiniBand. Tres consideraciones:

1. Costo del ecosistema. Ethernet es commodity. Los switches, los transceivers ópticos (OSFP), y el cableado tienen más proveedores y más economías de escala. Para clusters grandes, el costo por puerto puede ser 30-50% menor que InfiniBand.
2. Latencia mejorada. Con Priority Flow Control (PFC), Explicit Congestion Notification (ECN), y Data Center Bridging (DCB), los switches Ethernet modernos pueden entregar latencias por hop de 400-600 nanosegundos — todavía más que InfiniBand pero en el orden de magnitud correcto para muchas cargas.
3. Maduración de RoCE. RoCE v2 sobre Ethernet permite RDMA con latencias cercanas a InfiniBand. Los principales frameworks (NCCL, RCCL) soportan RoCE, aunque con tuning más cuidadoso que para InfiniBand nativo.

Cuándo InfiniBand sigue siendo la respuesta correcta

InfiniBand es la decisión correcta en tres escenarios:

1. Cluster con 64+ GPUs entrenando un solo modelo. La comunicación all-reduce es constante y la latencia se acumula. InfiniBand NDR (400 Gbps) y XDR (800 Gbps) son las únicas opciones que entregan latencia consistente a esa escala; XDR además provee paridad de ancho de banda por puerto con Ethernet 800G, manteniendo la ventaja de latencia sub-microsegundo del ecosistema InfiniBand.
2. Cluster NVIDIA DGX o HGX. Estos sistemas están certificados y optimizados para InfiniBand. Mezclar con Ethernet requiere re-certificación del fabricante y puede invalidar soporte.
3. Workload multi-tenant. InfiniBand tiene mejor aislamiento entre tenants vía virtual lanes (VLs). En clusters donde múltiples equipos entrenan simultáneamente, InfiniBand evita que un tenant monopolice la red.

Cuándo Ethernet 800G ya es suficiente

Ethernet 800G es suficiente en tres escenarios:

1. Cluster pequeño (≤32 GPUs) entrenando modelos medianos. La brecha de rendimiento entre InfiniBand y Ethernet es pequeña a esta escala. El ahorro de costo compensa.
2. Inferencia distribuida con batching pequeño. La inferencia paraleliza diferente del entrenamiento; el tráfico es menos síncrono y tolera más latencia. Ethernet 800G se desempeña bien.
3. Integración con infraestructura Ethernet existente. Si ya tienes un DC con switching Ethernet de 100/400G, agregar Ethernet 800G para el cluster AI simplifica la operación y reduce el inventario de switches especiales.

Topología spine-leaf: lo que comparten ambas opciones

Más allá de la elección InfiniBand vs Ethernet, hay una topología de red que es estándar para ambos: spine-leaf. En esta arquitectura, los leaf switches conectan los racks de GPUs y los spine switches forman el backbone. Cada leaf está conectado a cada spine, dando una latencia uniforme entre cualquier par de GPUs en el cluster. La elección del número de spines (típicamente 2-8) depende del ancho de banda agregado que necesites. Para un cluster de 32 GPUs, 2 spines de 400G cada uno suelen ser suficientes; para 128 GPUs, necesitas 4-8 spines con uplinks de 800G.

Cómo evitar el over-engineering

El error más común en proyectos nuevos es sobredimensionar la red desde el día uno. Si tu cluster empieza con 16 GPUs y planeas crecer a 64, no compres switches de 128 puertos. Empieza con switches modulares que puedas escalar agregando leaves conforme agregas racks. El capex inicial baja 40-60% y la red escala con tu demanda real. La complejidad operativa es ligeramente mayor (más switches para gestionar) pero el ahorro financiero justifica el trade-off en la mayoría de los casos.

Recomendación práctica

Si tu cluster va a tener 64+ GPUs entrenando LLMs grandes con NVIDIA, ve con InfiniBand NDR (400 Gbps) o XDR (800 Gbps) — el overhead de tuning para Ethernet no se justifica a esa escala, y XDR te da paridad exacta en ancho de banda por puerto frente a Ethernet 800G con la ventaja de latencia. Si tienes 16-32 GPUs y presupuesto limitado, prueba Ethernet 800G con RoCE — los frameworks actuales lo soportan razonablemente bien. Si tu workload es inferencia o entrenamiento de modelos medianos (≤13B), Ethernet es la elección pragmática. La decisión se reduce al tamaño del cluster y al modelo de workload, no al vendor preference.

Fuentes

1. NVIDIA — homepage — https://www.nvidia.com/en-us/data-center/
2. Ethernet Alliance — 800G specification overview — https://www.ethernetalliance.org/technology/800g/
3. Uptime Institute — Tier Classification framework (data center network standards) — https://uptimeinstitute.com/tier-certification
4. Arista Networks — homepage — https://www.arista.com/