OpenAI ha publicado la especificación de MRC, un nuevo protocolo de red para superordenadores de Inteligencia Artificial desarrollado junto a AMD, Broadcom, Intel, Microsoft y NVIDIA. La compañía lo ha liberado a través del Open Compute Project con una intención clara: que la industria pueda usar y mejorar una pieza de infraestructura que ya está funcionando en sus mayores clústeres de entrenamiento.
La noticia no tiene el brillo comercial de un nuevo modelo, pero puede ser igual de importante para entender hacia dónde va la Inteligencia Artificial. Entrenar modelos frontera no depende solo de tener más GPU. También exige que esas GPU se comuniquen entre sí con una precisión enorme. Si una transferencia llega tarde, si un enlace falla o si un switch introduce latencia, miles de aceleradores pueden quedarse esperando. Y una GPU parada en un clúster de entrenamiento no es solo un problema técnico: es dinero, energía y tiempo perdido.
Por qué OpenAI necesitaba una red distinta
OpenAI explica que el entrenamiento de grandes modelos puede implicar millones de transferencias de datos en un solo paso. En un entrenamiento síncrono, muchas GPU trabajan de forma coordinada sobre el mismo modelo. Eso significa que el rendimiento no lo marca solo la media de la red, sino los peores casos: el paquete que llega tarde, la ruta congestionada o el enlace que se cae en el peor momento. La compañía describe estas cargas como una especie de “amplificador de fallos”, porque cuanto mayor es el sistema, más probable es que un problema pequeño acabe afectando al conjunto.
MRC, o Multipath Reliable Connection, intenta resolver ese cuello de botella. Es una extensión de RoCE, la tecnología de RDMA sobre Ethernet convergente usada para que CPU y GPU intercambien datos con acceso directo a memoria. La diferencia es que MRC reparte una misma transferencia entre cientos de rutas, puede esquivar fallos en microsegundos y simplifica el plano de control de la red mediante enrutamiento estático basado en SRv6.
OpenAI asegura que MRC ya está desplegado en todos sus mayores superordenadores con NVIDIA GB200 usados para entrenar modelos frontera, incluidos los sistemas de Oracle Cloud Infrastructure en Abilene, Texas, y los superordenadores Fairwater de Microsoft. La compañía también afirma que ya ha entrenado varios modelos con MRC usando hardware de NVIDIA y Broadcom.
El contexto es importante. OpenAI afirma que ChatGPT supera los 900 millones de usuarios semanales, una escala que obliga a repensar la infraestructura por debajo de los modelos. La compañía ya no trabaja solo con clústeres experimentales, sino con sistemas que forman parte de una cadena de producción global de modelos, productos y servicios de Inteligencia Artificial.
La idea clave: dividir, repartir y sobrevivir a fallos
Una de las partes más interesantes de MRC está en la topología. En vez de tratar una interfaz de red de 800 Gb/s como un único enlace, OpenAI propone dividirla en varios enlaces más pequeños. Por ejemplo, una interfaz puede conectarse a ocho switches distintos, creando ocho planos paralelos de 100 Gb/s. Esta decisión cambia la forma del clúster: un switch que conectaría 64 puertos a 800 Gb/s puede conectar 512 puertos a 100 Gb/s. Según OpenAI, eso permite construir una red capaz de conectar alrededor de 131.000 GPU con solo dos niveles de switches, frente a los tres o cuatro niveles que requeriría un diseño convencional.
La reducción de niveles no es un detalle menor. Menos switches implican menos consumo, menos componentes que puedan fallar y menos complejidad operativa. Pero dividir la red en varios planos solo sirve si el tráfico los aprovecha bien. Ahí entra el “packet spraying” adaptativo: MRC no envía una transferencia por una única ruta, sino que distribuye sus paquetes por muchos caminos a la vez.
| Problema en grandes clústeres de IA | Enfoque tradicional | Qué aporta MRC |
|---|---|---|
| Congestión en enlaces concretos | Cada flujo suele seguir una ruta | Reparte paquetes por cientos de caminos |
| Fallos de enlaces o switches | La red recalcula rutas y puede tardar segundos | Evita rutas fallidas en microsegundos |
| Escala de más de 100.000 GPU | Requiere más niveles de switches | Usa redes multipleno con solo dos niveles |
| Paquetes fuera de orden | Puede penalizar el rendimiento | Cada paquete lleva su dirección final de memoria |
| Complejidad del plano de control | Protocolos dinámicos como BGP | Rutas estáticas con SRv6 y control desde el origen |
| Mantenimiento de red | Puede requerir coordinación con entrenamiento | Permite reparar o reiniciar partes sin parar trabajos |
En una red clásica, enviar paquetes por rutas distintas puede provocar llegadas desordenadas. MRC lo permite porque cada paquete incluye su dirección final de memoria. El destino puede colocarlo en su sitio conforme llega, sin esperar a que toda la secuencia siga un único camino. Esta característica reduce los puntos calientes de congestión y evita que algunas transferencias se vuelvan mucho más lentas que el resto.
El protocolo también distingue mejor entre pérdida por fallo y pérdida por congestión. Si un switch no puede reenviar un paquete completo, puede recortar la carga útil y enviar solo la cabecera. Ese “packet trimming” sirve para pedir una retransmisión explícita sin interpretar automáticamente que todo el camino está roto. Es una forma de reducir falsos positivos y mantener rutas útiles cuando el problema no es un fallo físico.
SRv6 y el fin de algunas averías difíciles de diagnosticar
MRC introduce otra decisión relevante: sustituir parte del enrutamiento dinámico tradicional por source routing con SRv6. En lugar de que los switches calculen rutas de forma dinámica, el origen especifica el camino que debe seguir cada paquete. Los switches se limitan a leer identificadores y seguir tablas estáticas configuradas previamente.
Esto simplifica mucho la operación. Si una ruta falla, MRC deja de usarla. Los switches no tienen que renegociar caminos ni recomputar rutas. Para un clúster con millones de enlaces, reducir esa complejidad puede ser tan valioso como aumentar el ancho de banda.
OpenAI da ejemplos de producción que ayudan a entender el impacto. Durante entrenamientos reales ha observado varios fallos transitorios por minuto entre switches de nivel 0 y nivel 1 sin impacto medible en trabajos de preentrenamiento síncrono. En otro caso, durante el entrenamiento de un modelo reciente para ChatGPT y Codex, tuvo que reiniciar cuatro switches de nivel 1 sin coordinar la intervención con los equipos que ejecutaban el entrenamiento. Antes, una operación así podía obligar a extremar la planificación para no parar el trabajo.
La diferencia no es solo técnica; es operativa. Si una red tolera fallos sin tumbar entrenamientos, los equipos pueden hacer mantenimiento, reparar enlaces y operar clústeres enormes con menos miedo a interrumpir trabajos de varios millones de dólares. En supercomputación de IA, la resiliencia se convierte en productividad.
Un estándar abierto para una carrera de infraestructura
Que OpenAI libere MRC a través del Open Compute Project tiene una lectura estratégica. La compañía no se queda con el protocolo como una ventaja cerrada, sino que lo ofrece como especificación para que otros fabricantes, operadores de cloud y laboratorios puedan adoptarlo. Es una señal de que ciertas capas de la infraestructura de Inteligencia Artificial pueden necesitar estándares comunes para escalar de forma eficiente.
La carrera de la IA ya no se gana solo con mejores modelos o más aceleradores. También se gana con redes que aprovechen esas GPU, centros de datos que consuman menos energía, sistemas que sobrevivan a fallos y arquitecturas que puedan crecer sin disparar la complejidad. MRC encaja justo en esa capa invisible que el usuario final no ve, pero que determina si un laboratorio puede entrenar modelos más grandes, más rápido y con menos desperdicio de recursos.
También es significativo el grupo de socios. AMD, Broadcom, Intel, Microsoft y NVIDIA tienen intereses distintos en el mercado de IA, pero comparten un problema común: si los grandes clústeres no se comunican bien, el hardware no rinde como debería. OpenAI menciona además a Microsoft Azure, OCI, NVIDIA y Arista en el despliegue a escala. Es un recordatorio de que la infraestructura de Inteligencia Artificial es ya una construcción industrial de muchos actores, no una simple pila de software.
La publicación de MRC no significa que todos los centros de datos vayan a adoptarlo de inmediato. Requiere hardware compatible, integración, pruebas y una operación de red muy especializada. Pero marca una dirección clara: los clústeres de más de 100.000 GPU necesitan redes diseñadas para asumir fallos constantes, no redes que funcionen bien solo cuando todo está perfecto.
En la práctica, MRC busca que las GPU sigan trabajando aunque haya congestión, enlaces inestables, switches en mantenimiento o rutas degradadas. Esa capacidad puede parecer discreta frente a los titulares sobre nuevos modelos, pero es una de las razones por las que esos modelos pueden llegar a existir. La Inteligencia Artificial de frontera empieza en los algoritmos, pero se sostiene sobre cables, switches, protocolos y decisiones de arquitectura que deben funcionar sin descanso.
Preguntas frecuentes
¿Qué es MRC?
MRC, o Multipath Reliable Connection, es un protocolo de red desarrollado por OpenAI junto a AMD, Broadcom, Intel, Microsoft y NVIDIA para mejorar el rendimiento y la resiliencia de grandes clústeres de entrenamiento de Inteligencia Artificial.
¿Por qué es importante para entrenar modelos grandes?
Porque el entrenamiento distribuido necesita mover datos entre miles o cientos de miles de GPU. Si una transferencia se retrasa o falla, el entrenamiento puede ralentizarse o detenerse.
¿Qué aporta frente a una red tradicional?
MRC reparte paquetes por cientos de rutas, usa redes en varios planos, evita fallos en microsegundos y simplifica el enrutamiento con SRv6 y rutas estáticas.
¿Quién puede usar MRC?
OpenAI ha publicado la especificación a través del Open Compute Project para que la industria pueda estudiarla, adoptarla y construir sobre ella.
