OpenAI、大規模AI学習網を支えるMRC技術を発表 Unlocking large scale AI training networks with MRC (Multipath Reliable Connection)

OpenAI has disclosed details of a new networking technology it calls MRC, or Multipath Reliable Connection, designed to serve as the communication substrate for its large-scale AI training infrastructure. As GPU clusters grow from tens of thousands to hundreds of thousands of accelerators, network bottlenecks have become a decisive factor in both the economics and the wall-clock speed of frontier model training, making bespoke transport designs an increasingly strategic concern for AI labs.

MRC appears to be a transport that uses multiple physical paths simultaneously to deliver reliable, high-throughput communication that is resilient to congestion or failure on any single path. Conventional RDMA over Converged Ethernet (RoCEv2) deployments typically pin an entire flow to one path via ECMP hashing, which can create hotspots and leave the full bisection bandwidth of a fat-tree fabric underutilized. MRC reportedly incorporates retransmission and ordering mechanisms that assume packet-level multipathing from the outset, an approach that aligns well with the all-reduce and all-to-all collective patterns that dominate large language model training.

The broader industry has been moving in a similar direction. The Ultra Ethernet Consortium (UEC), backed by AMD, Broadcom, Cisco, Meta, Microsoft and others, is actively standardizing a new Ethernet-based transport for AI and HPC workloads that emphasizes packet spraying, out-of-order delivery and modern congestion control. NVIDIA is pursuing comparable goals through InfiniBand and its Spectrum-X Ethernet platform, while AWS has long deployed its Scalable Reliable Datagram (SRD) inside EFA, and Google has detailed its Falcon hardware transport. MRC can be read as OpenAI's own entry into this category, tailored to the specific traffic patterns of its training workloads rather than a general-purpose datacenter transport.

The motivation for OpenAI to invest in in-house network design is significant. Training runs for GPT-class models can stretch over weeks of nearly continuous collective communication, where even modest tail latency or transient link imbalance can erode aggregate step throughput across an entire cluster. A transport that spreads traffic across many paths and recovers quickly from packet loss can materially raise the effective utilization of expensive GPU fleets. In a co-designed environment with Microsoft Azure, where OpenAI's supercomputers are built, having tight control over the transport layer also enables closer integration with NIC firmware, switch buffering policies and collective communication libraries.

Technically, the key challenges for any such transport are well understood. Packet spraying across multiple paths breaks the in-order assumptions that traditional RDMA verbs rely on, so the receiver side must reassemble messages and signal completion only when an entire message is delivered. Congestion control must react to per-path signals rather than a single end-to-end RTT, and loss recovery has to avoid the head-of-line blocking that plagues TCP-style designs. Selective retransmission, fine-grained credit or window management, and hardware offload of these mechanisms to the NIC are common ingredients, and MRC is likely to follow a similar template, although OpenAI has not yet published a full specification.

There are also operational implications. Multipath transports tend to make fabrics more tolerant of link flaps and optical errors, which become statistically unavoidable at the scale of hundreds of thousands of 400G or 800G links. They can also simplify capacity planning, since traffic naturally rebalances rather than concentrating on the unlucky path chosen by a hash function. On the other hand, debugging performance anomalies in a sprayed, out-of-order fabric is harder than in a classic single-path RoCE deployment, and operators typically need new telemetry to make sense of per-packet path behavior.

It remains to be seen how much of MRC will be opened up. Key open questions include whether the protocol will converge with or diverge from the emerging UEC specifications, whether it will interoperate with third-party NICs and switches, and how its performance compares with NVIDIA's Spectrum-X and hyperscaler transports such as SRD and Falcon. If OpenAI chooses to publish wire-level details or contribute ideas back to standards bodies, MRC could influence the shape of AI networking well beyond its own clusters; if it remains proprietary, it will still serve as another data point that frontier AI training is pushing networking design in directions that general-purpose datacenter protocols were never built to handle.