La red se ha convertido en una de las partes más críticas de la infraestructura de inteligencia artificial. Durante años, muchos equipos trataron Ethernet como una capa generalista: estable, conocida, relativamente barata y suficientemente flexible para casi cualquier carga empresarial. En un cluster de IA moderno, esa visión se queda corta. Cuando miles de GPUs entrenan un modelo distribuido, la red deja de ser «transporte» y pasa a formar parte del sistema de cómputo.
RoCE, RDMA over Converged Ethernet, permite usar RDMA sobre Ethernet para mover datos entre servidores con menos intervención de CPU y sistema operativo. Su atractivo es claro: baja latencia, alto ancho de banda y mejor eficiencia en comunicaciones GPU-to-GPU. Su dificultad también lo es: para funcionar bien en IA, la fabric Ethernet debe comportarse de forma casi lossless, con congestión controlada, colas bien diseñadas, buffers ajustados y telemetría suficiente para detectar problemas antes de que degraden el entrenamiento.
Qué problema resuelve RoCE en cargas de IA
En entrenamiento distribuido, las GPUs no trabajan aisladas. Intercambian gradientes, sincronizan estados, ejecutan operaciones colectivas como AllReduce y dependen de que todos los nodos avancen con un ritmo parecido. Si una parte del cluster se retrasa por congestión, pérdidas o latencia variable, el rendimiento global cae. Una GPU cara esperando datos es capacidad desperdiciada.
RDMA reduce copias de memoria y evita parte del recorrido tradicional por kernel y CPU. En lugar de tratar cada transferencia como tráfico convencional, permite que las NICs participen de forma mucho más directa en el movimiento de datos entre memorias. RoCEv2 extiende esa lógica sobre redes IP/Ethernet, lo que permite llevar semánticas RDMA a entornos basados en Ethernet.
Google Cloud usa RoCEv2 en máquinas A3 Ultra y A4 para comunicación entre nodos y tráfico GPU-to-GPU, con hasta 3,2 Tbps de tráfico inter-nodo GPU-to-GPU en A3 Ultra. Meta también ha documentado redes RoCE para entrenamiento distribuido a gran escala y ha detallado clusters de 24.576 GPUs H100 usados para Llama 3, uno basado en RoCE y otro en InfiniBand. NVIDIA, por su parte, ha desarrollado Spectrum-X como plataforma Ethernet optimizada para IA con conectividad RoCE, control de congestión, telemetría y aislamiento de rendimiento.
| Opción de red | Uso típico | Ventajas | Retos |
|---|---|---|---|
| Ethernet tradicional con TCP | Aplicaciones generales, tráfico cloud, servicios empresariales | Madurez, interoperabilidad, coste, operación conocida | Latencia variable, retransmisiones, pérdida tolerada por diseño |
| RoCEv2 sobre Ethernet | Clusters GPU, IA distribuida, HPC sobre Ethernet | RDMA sobre IP/Ethernet, menor overhead de CPU, buen encaje multivendor | Exige PFC, ECN, tuning de buffers, QoS y telemetría fina |
| InfiniBand | HPC, entrenamiento de IA de alto rendimiento, clusters cerrados | Baja latencia, RDMA maduro, stack integrado | Menor ubicuidad que Ethernet, más dependencia de proveedor |
| Ultra Ethernet | Próxima generación para IA/HPC a gran escala | Busca mejorar multipath, escalabilidad y transporte extremo | Todavía en maduración frente a despliegues RoCE actuales |
Componentes técnicos: PFC, ECN, DCQCN y QoS
RoCE no convierte Ethernet en lossless por sí solo. La red debe configurarse para proteger las clases de tráfico RDMA y evitar descartes en puntos de congestión. Ahí entran varios mecanismos que hay que entender como un sistema, no como opciones independientes del switch.
PFC, Priority Flow Control, pausa una prioridad concreta cuando la cola asociada alcanza un umbral. Su ventaja es que evita pérdidas en la clase de tráfico RDMA. Su riesgo es que, si se configura mal, puede propagar congestión, generar head-of-line blocking y afectar a tráfico que no debería estar bloqueado. Por eso se recomienda aplicarlo solo a las colas estrictamente necesarias, no a toda la red.
ECN, Explicit Congestion Notification, marca paquetes antes de que se descarten. El receptor o el endpoint interpreta esa señal y el emisor reduce la tasa. En RoCEv2, ECN suele trabajar junto con algoritmos de control de congestión como DCQCN, Data Center Quantized Congestion Notification, usado para adaptar el ritmo de envío en función de las marcas de congestión. La clave está en marcar pronto, pero no demasiado pronto; si los umbrales son demasiado agresivos, se desperdicia capacidad, y si son demasiado laxos, aparecen colas y pausas.
La separación de colas también es crítica. El tráfico RDMA debe tener su clase, sus colas y su política. Los paquetes de notificación de congestión, como CNP, deben llegar con rapidez, porque si la señal de congestión se retrasa, el emisor seguirá inyectando tráfico cuando la fabric ya está saturada. Cisco recomienda en sus guías para AI/ML diferenciar el tráfico RoCEv2, aplicar ECN y PFC en la cola correspondiente, y tratar el tráfico de control de congestión con prioridad adecuada.
| Elemento | Función | Riesgo si se configura mal |
|---|---|---|
| PFC | Evita pérdidas pausando una prioridad concreta | Congestión propagada, bloqueos, pausas excesivas |
| ECN | Marca congestión antes del descarte | Marcado tardío provoca colas; marcado temprano reduce rendimiento |
| DCQCN | Ajusta la tasa de envío en endpoints RoCE | Oscilaciones, underutilization o congestión persistente |
| QoS / colas | Separa RDMA, control, storage y tráfico general | Mezcla de tráfico crítico y no crítico, jitter y drops |
| Buffers | Absorben microbursts e incast | Drops, latencia de cola o consumo innecesario de memoria del switch |
| Telemetría | Permite ver PFC, ECN, colas, drops y microbursts | Fallos intermitentes sin causa aparente |
Diseño de fabric: topología, rails y aislamiento
En IA no basta con una red leaf-spine genérica. Hay que diseñar pensando en el patrón de comunicación de las cargas. Entrenamiento distribuido, inferencia paralela, almacenamiento, checkpoints y tráfico de control no se comportan igual. La red debe evitar oversubscription donde afecte al tráfico crítico y debe ofrecer caminos consistentes entre nodos GPU.
Los despliegues más avanzados usan diseños rail-aligned o multi-rail, donde las NICs de cada servidor GPU se conectan a fabrics paralelas o a dominios de red diseñados para equilibrar tráfico de forma predecible. Google, por ejemplo, habla de una red 4-way rail-aligned en A3 Ultra para entregar tráfico GPU-to-GPU no bloqueante. En entornos propios, esto obliga a cuidar la simetría de cableado, la distribución de NICs, el hashing ECMP, el número de saltos y la ubicación física de nodos.
El aislamiento también importa. Una fabric RoCE para GPUs no debería compartir sin control el mismo plano que tráfico de gestión, backups, almacenamiento general, servicios corporativos o monitorización ruidosa. En algunos diseños tiene sentido separar físicamente la red de IA. En otros, basta con separación lógica, colas dedicadas y políticas estrictas. La decisión depende de escala, presupuesto, riesgo y nivel de utilización esperado.
| Capa de diseño | Recomendación técnica | Motivo |
|---|---|---|
| Topología | Leaf-spine simétrica o rail-aligned | Reduce caminos desiguales y mejora previsibilidad |
| Oversubscription | Evitarla en tráfico GPU-to-GPU crítico | Las GPUs degradan rápido si esperan comunicaciones |
| Separación de tráfico | RDMA en colas y prioridades propias | Evita que tráfico general contamine latencia y buffers |
| ECMP / hashing | Validar distribución real por flujos RoCE | Un mal hash puede concentrar tráfico en enlaces concretos |
| Cableado | Documentar rails, NICs, leafs y dominios | Los errores físicos generan problemas difíciles de diagnosticar |
| Fallos | Probar pérdida de enlace, leaf y spine | La red debe degradarse de forma predecible, no caótica |
Checklist práctica antes de poner RoCE en producción
El error más común es tratar RoCE como una función que se activa. En realidad, es una arquitectura que se valida. Antes de producción conviene construir un laboratorio con la misma NIC, firmware, sistema operativo, driver, switch, versión de NOS, óptica y patrón de tráfico que se usará en el cluster real. La diferencia entre «funciona en una prueba simple» y «sostiene entrenamiento durante semanas» es enorme.
Un buen plan de validación debería incluir pruebas de throughput sostenido, incast, microbursts, tráfico mixto, pérdida de enlace, reinicio de switch, congestión localizada, cambios de ruta, actualización de firmware y cargas NCCL reales. No basta con ib_write_bw o pruebas sintéticas de RDMA. Hay que medir con la aplicación o, al menos, con un patrón que se le parezca.
También hay que cerrar el gobierno operativo. Quién puede cambiar umbrales ECN. Qué versión de firmware se considera aprobada. Cómo se monitorizan eventos PFC. Qué alertas se disparan ante drops por prioridad. Qué se considera degradación de entrenamiento atribuible a red. Cómo se correlacionan métricas de GPU, NCCL y switches. Sin ese marco, cada incidencia acabará en una guerra entre equipos de red, sistemas, plataforma e IA.
| Fase | Validación mínima | Resultado esperado |
|---|---|---|
| Laboratorio | NIC, switch, firmware y NOS iguales a producción | Configuración reproducible |
| Baseline | Throughput, latencia, PFC, ECN, drops y colas sin carga real | Punto de comparación estable |
| Carga sintética | RDMA, incast, microbursts y tráfico mixto | Ver umbrales de congestión |
| Carga de IA | NCCL, AllReduce, entrenamiento distribuido | Medir impacto real en GPUs |
| Fallos | Cortes de enlace, reinicios, rutas alternativas | Degradación controlada |
| Operación | Alertas, dashboards, runbooks y responsables | Diagnóstico rápido y repetible |
Métricas que conviene monitorizar
Una fabric RoCE puede parecer sana con métricas tradicionales y estar degradando el entrenamiento. La utilización de enlaces no basta. Hay que mirar colas, pausas, marcas y comportamiento de los endpoints.
Las métricas clave incluyen eventos PFC por puerto y prioridad, duración de pausas, paquetes ECN marcados, CNP enviados y recibidos, drops por cola, occupancy de buffers, latencia de cola, retransmisiones si las hubiera, utilización por rail, distribución ECMP, errores físicos, CRC, flaps, temperatura de ópticas y rendimiento de NCCL. En la capa de GPU, interesa correlacionar utilización de aceleradores, tiempo de espera en comunicaciones colectivas y duración de pasos de entrenamiento.
NVIDIA está empujando esta idea con Spectrum-X y su telemetría para AI factories, donde la red se observa como una parte del rendimiento del cluster, no como un elemento aislado. La clave es que el equipo de IA vea cuándo una pérdida de eficiencia viene de red y el equipo de red vea cuándo una cola afecta a una carga concreta.
Errores habituales en despliegues RoCE
El primer error es activar PFC en demasiadas prioridades. Esto puede convertir una protección localizada en un problema global. El segundo es copiar valores de ECN sin adaptarlos al switch, al tamaño de buffers y al patrón de tráfico. El tercero es mezclar tráfico RDMA con tráfico general sin separación suficiente. El cuarto es validar con tráfico sintético y asumir que el entrenamiento real se comportará igual.
También es frecuente subestimar la importancia del firmware. NICs, drivers, switches y sistemas operativos deben tratarse como una pila conjunta. Una versión incompatible puede introducir latencias, drops o comportamientos de congestión difíciles de reproducir. En clusters grandes, la homogeneidad operativa vale tanto como la configuración.
Otro error es no diseñar para fallos. Una fabric que solo funciona en estado perfecto no sirve. Hay que probar qué ocurre cuando cae un enlace, se satura una cola, se reinicia un leaf o una ruta ECMP cambia. En IA, un fallo parcial puede no tumbar el servicio, pero sí reducir tanto la eficiencia que el coste del entrenamiento se dispare.
RoCE no es una moda, es una competencia nueva
El crecimiento de RoCE en IA refleja una tendencia de fondo: los hiperescalares y grandes clouds quieren redes de alto rendimiento sobre Ethernet porque les da escala, diversidad de proveedores y una base operativa más amplia. InfiniBand seguirá teniendo un papel fuerte en HPC e IA, pero Ethernet está entrando en territorios que antes parecían reservados a fabrics especializadas.
Para un equipo técnico, esto implica una actualización de habilidades. Ya no basta con saber configurar VLANs, BGP EVPN, MLAG o QoS general. En redes de IA hay que entender RDMA, patrones de comunicación de entrenamiento, NCCL, congestión, PFC, ECN, DCQCN, telemetría y validación de cargas reales. Es una disciplina entre redes, sistemas y plataforma de IA.
La buena noticia es que Ethernet conserva su mayor ventaja: es conocida, abierta y ampliamente soportada. La mala noticia es que, con RoCE, deja de perdonar configuraciones aproximadas. Una red Ethernet tradicional puede funcionar razonablemente bien aunque no esté afinada al milímetro. Una fabric RoCE para IA necesita precisión.
La conclusión para guías y recursos es sencilla: antes de comprar más GPUs, hay que diseñar la red que las mantendrá ocupadas. La IA no escala solo con aceleradores. Escala con una fabric capaz de mover memoria, evitar pérdidas y controlar congestión durante días o semanas de entrenamiento continuo. RoCE es una de las tecnologías que está haciendo posible esa transición, pero exige ingeniería real, no una casilla marcada en el switch.
Preguntas frecuentes
¿RoCE sustituye a TCP en todo el centro de datos?
No. RoCE se usa para tráfico RDMA de baja latencia y alto rendimiento, especialmente entre nodos GPU o cargas HPC. El resto de aplicaciones puede seguir usando TCP/IP tradicional.
¿Es obligatorio usar PFC con RoCE?
En la práctica, muchas arquitecturas RoCEv2 para IA usan PFC en la cola RDMA para evitar pérdidas. También se combina con ECN y control de congestión. La clave es aplicarlo con precisión, no de forma global.
¿Qué diferencia hay entre RoCE e InfiniBand?
RoCE lleva RDMA sobre Ethernet/IP, aprovechando el ecosistema Ethernet. InfiniBand es una fabric especializada con RDMA nativo y un stack muy integrado. Ambas pueden ser válidas según escala, coste, equipo y objetivos.
¿Qué debería probar antes de producción?
Throughput, latencia, microbursts, incast, eventos PFC, marcas ECN, distribución ECMP, fallos de enlace, comportamiento NCCL y rendimiento real de entrenamiento distribuido.
vía: RoCE AI
