OpenAI ha presentado MRC, siglas de Multipath Reliable Connection, un nuevo protocolo de red diseñado para mejorar el rendimiento y la resistencia de los grandes superordenadores usados en el entrenamiento de modelos de Inteligencia Artificial. La compañía lo ha desarrollado junto a AMD, Broadcom, Intel, Microsoft y NVIDIA, y ha publicado la especificación a través del Open Compute Project para que pueda ser utilizada por el resto de la industria.
El anuncio puede parecer muy técnico, pero apunta a uno de los problemas más importantes de la IA a gran escala: no basta con tener miles o cientos de miles de GPU si la red que las conecta no consigue mover datos con rapidez y regularidad. En los entrenamientos síncronos, donde muchas GPU trabajan coordinadas en el mismo modelo, un retraso en una transferencia puede hacer que parte del clúster espere. Y cuando se habla de superordenadores con decenas o cientos de miles de aceleradores, cada segundo perdido se traduce en dinero, energía y tiempo de investigación.
Por qué la red se ha convertido en un cuello de botella
El entrenamiento de modelos frontera no consiste solo en encender muchas GPU y esperar. Cada paso puede implicar millones de transferencias de datos entre GPU y CPU. Si una llega tarde, si un enlace falla o si un switch introduce latencia, el trabajo completo puede ralentizarse. OpenAI describe estas cargas como un “amplificador de fallos”: cuanto mayor es el clúster, más impacto puede tener un pequeño problema de red.
Hasta ahora, muchos diseños de red dependían de rutas más rígidas y de protocolos dinámicos capaces de recalcular caminos cuando algo fallaba. Eso funciona en muchos entornos, pero se complica cuando la escala crece mucho. Una reparación de rutas puede tardar segundos o incluso decenas de segundos, una eternidad si un entrenamiento síncrono mantiene miles de GPU esperando.
MRC intenta atacar el problema desde varios ángulos. No busca solo más velocidad, sino rendimiento predecible incluso cuando hay congestión, pérdidas de paquetes, enlaces que fallan o switches que necesitan mantenimiento. Esa diferencia importa mucho en IA. En una aplicación web tradicional, una pequeña variación de latencia puede ser tolerable. En un entrenamiento distribuido, los peores casos pesan más que la media, porque las GPU deben avanzar juntas.
OpenAI afirma que MRC ya está desplegado en sus mayores superordenadores con NVIDIA GB200, incluidos sistemas en Oracle Cloud Infrastructure en Abilene, Texas, y en los superordenadores Fairwater de Microsoft. La compañía asegura que el protocolo se ha usado para entrenar varios modelos de OpenAI con hardware de NVIDIA y Broadcom.
Redes en varios planos y paquetes repartidos por cientos de caminos
Una de las ideas centrales de MRC es dividir una interfaz de red de 800 Gb/s en varios enlaces más pequeños. En lugar de tratarla como un único enlace de 800 Gb/s, puede separarse en ocho conexiones de 100 Gb/s hacia switches distintos. Esto permite crear varios planos de red paralelos.
El efecto en la arquitectura es notable. Según OpenAI, un switch que conectaría 64 puertos a 800 Gb/s puede conectar 512 puertos a 100 Gb/s. Con ese enfoque, se podría construir una red que conecte alrededor de 131.000 GPU usando solo dos niveles de switches. Un diseño convencional de 800 Gb/s necesitaría tres o cuatro niveles para alcanzar una escala similar.
Reducir niveles tiene varias consecuencias positivas: menos componentes, menor consumo, menos puntos susceptibles de fallo y más diversidad de caminos. Pero esa diversidad solo sirve si el tráfico puede aprovecharla. Ahí entra la parte más interesante de MRC: en lugar de enviar una transferencia por un único camino, el protocolo reparte los paquetes de una misma transferencia por cientos de rutas disponibles a través de los distintos planos.
Esto rompe con una limitación clásica. En muchas redes, los paquetes deben llegar en orden, lo que obliga a mantener cada flujo en una ruta. MRC permite que lleguen desordenados porque cada paquete incluye su dirección final de memoria. El destino puede colocarlo donde corresponde conforme llega. De esta manera, se reducen los puntos calientes de congestión y se reparte mejor la carga.
El protocolo también adapta sus rutas. Si detecta que un camino empieza a congestionarse, lo sustituye por otro. Si pierde un paquete, asume que puede haber un fallo y deja de usar esa ruta mientras retransmite lo necesario. Para distinguir mejor entre pérdida por fallo y congestión en destino, MRC usa una técnica de “packet trimming”: si un switch no puede reenviar el paquete completo por congestión, puede enviar solo la cabecera para provocar una retransmisión explícita, en lugar de dejar que el sistema interprete automáticamente que la ruta ha fallado.
Menos dependencia del enrutamiento dinámico
Otra decisión relevante es el uso de SRv6, o Segment Routing sobre IPv6. En vez de depender de protocolos dinámicos como BGP para recalcular rutas, MRC permite que el emisor especifique el camino que debe seguir cada paquete. Los switches solo siguen rutas estáticas configuradas previamente.
Esto simplifica el plano de control de la red. Si un camino falla, MRC deja de usarlo. Los switches no tienen que recomputar rutas ni coordinar cambios complejos. Para OpenAI, esa simplificación elimina clases enteras de fallos asociados al enrutamiento dinámico y permite reaccionar en microsegundos frente a problemas que antes podían ralentizar un entrenamiento durante mucho más tiempo.
La compañía pone ejemplos de producción. En redes con millones de enlaces, ha observado varios fallos transitorios por minuto entre switches de nivel 0 y nivel 1 sin impacto medible en entrenamientos síncronos. También asegura que, durante el entrenamiento de un modelo reciente para ChatGPT y Codex, fue necesario reiniciar cuatro switches de nivel 1 sin coordinarlo con los equipos que ejecutaban los trabajos de entrenamiento.
Antes de MRC, un fallo entre una interfaz de red de GPU y un switch podía tumbar el entrenamiento. Ahora, si una interfaz de ocho puertos pierde uno, el rendimiento máximo se reduce físicamente en una octava parte, pero el trabajo puede seguir. El protocolo detecta la pérdida, evita ese plano y avisa a los pares para que no lo usen en tráfico entrante hasta que se recupere.
Un estándar abierto para una carrera que ya no se gana solo con GPU
La publicación de MRC a través del Open Compute Project tiene una lectura estratégica. OpenAI no está guardando esta pieza como un secreto interno, sino que la abre como especificación para que otros actores puedan construir sobre ella. En una industria donde la demanda de cómputo crece más rápido que la capacidad disponible, los estándares compartidos pueden ayudar a reducir complejidad y acelerar despliegues.
También muestra que la carrera de la Inteligencia Artificial ya no se decide solo por quién compra más GPU. La red, la energía, el empaquetado, el software de entrenamiento, la memoria, el almacenamiento y la operación de centros de datos pesan cada vez más. Si una parte del clúster se queda esperando por congestión o por un fallo de enlace, el capital invertido en aceleradores no se aprovecha del todo.
MRC encaja en esa nueva etapa. Su promesa es permitir superordenadores con más de 100.000 GPU, menos niveles de switches, menor consumo que diseños equivalentes de más capas, menos congestión en el núcleo de la red y mayor resistencia frente a fallos. OpenAI lo presenta como una pieza de su estrategia para escalar Stargate y otros sistemas de entrenamiento de gran tamaño.
El anuncio también refuerza una realidad: incluso los laboratorios más avanzados dependen de una colaboración industrial amplia. OpenAI agradece en su publicación el trabajo con AMD, Broadcom, Intel, Microsoft y NVIDIA en el desarrollo del protocolo, y con Microsoft Azure, OCI, NVIDIA y Arista en su despliegue a escala. Ninguna empresa puede resolver sola todos los problemas de infraestructura que plantea la IA de frontera.
La consecuencia final puede notarse en modelos más capaces y en ciclos de entrenamiento más eficientes, aunque el usuario no vea nunca el protocolo. Cuando ChatGPT, Codex u otros sistemas mejoran, detrás suele haber avances invisibles en chips, redes, centros de datos y software de bajo nivel. MRC pertenece a esa capa poco visible, pero esencial: la que permite que miles de GPU trabajen juntas sin que un fallo pequeño detenga una máquina gigantesca.
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 resistencia de grandes clústeres de entrenamiento de IA.
¿Por qué es importante para entrenar modelos de Inteligencia Artificial?
Porque los entrenamientos distribuidos necesitan mover enormes cantidades de datos entre GPU. Si hay congestión o fallos de red, las GPU pueden quedarse esperando y el entrenamiento se vuelve más lento y caro.
¿Qué diferencia a MRC de otros enfoques de red?
MRC reparte los paquetes de una transferencia por cientos de caminos, usa redes en varios planos, reacciona a fallos en microsegundos y emplea SRv6 para que el emisor indique la ruta de cada paquete.
¿Quién podrá usar MRC?
OpenAI ha publicado la especificación a través del Open Compute Project, por lo que la industria podrá estudiarla, adoptarla y construir sobre ella.
vía: openai
