AI Infrastructure

Leaders with working knowledge of hardware infrastructure and security make better AI decisions, negotiate better contracts, and carry more credibility with the teams they lead. NVIDIA's MRC announcement is a good test case for why that knowledge gap has a real cost.

By Shashi Bellamkonda · May 7, 2026

Leaders who understand their hardware infrastructure and security posture make materially better technology decisions than those who delegate that understanding entirely to their technical teams. Not because they need to configure switches or read packet traces, but because infrastructure choices set the ceiling on what a business can do with AI, how exposed it is when something fails, and how much leverage it actually holds in a vendor negotiation. A CIO who cannot ask the right question about what sits beneath a cloud contract is signing terms they cannot evaluate. This post is structured around exactly those questions, applied to a networking announcement that will shape AI infrastructure procurement for the next several years.

Training a large AI model is not a continuous process. It is thousands of graphics processing units (GPUs) synchronizing constantly, each one waiting on the others to exchange results before the next step begins. When the network carrying that data stumbles, everything stalls. At the scale of 100,000 GPUs, even a brief disruption does not slow a training run. It can stop it entirely.

What NVIDIA actually announced, and why the timing matters

At the NVIDIA GTC event in Washington DC in October 2025, Jensen Huang made a point of separating Spectrum-X from commodity networking. His framing at the time: "Everybody will say ethernet — Spectrum-X ethernet is hardly ethernet. Spectrum-X ethernet is designed for AI performance." The claim was directional. The proof was still coming.

Six months later, MRC is the proof. NVIDIA, together with AMD, Broadcom, Intel, Microsoft, and OpenAI, released Multipath Reliable Connection (MRC) as a version 1.0 open specification through the Open Compute Project. MRC is a networking protocol, a set of rules governing how data moves between GPUs inside a large AI training cluster. It has already been deployed in production at OpenAI's largest supercomputers, including its Oracle Cloud Infrastructure site in Abilene, Texas, and Microsoft's Fairwater facility. The announcement makes the specification available to the broader industry so that other hardware and software vendors can build compatible products.

The shift from October 2025 to today is worth stating plainly. At GTC DC, Spectrum-X was a positioning claim, one option among several in a multi-tier networking stack. Today it is a production-validated platform with an open protocol co-developed by the companies running the world's largest AI training clusters. That is not an incremental product update. It is a change in the strategic weight of the argument.

In plain terms, what problem does MRC solve

Standard internet networking was not designed for what AI training demands. When thousands of GPUs all need to send data at once, they compete for the same network paths. Paths get overloaded, data queues up, and GPUs sit idle waiting. One failed network link can cascade across an entire cluster.

MRC solves this by treating the entire network as a pool of paths rather than a fixed route. A single data transfer spreads across hundreds of paths simultaneously, like spreading traffic across every lane of a highway rather than queuing in one. If a path gets congested or a switch fails, MRC reroutes in microseconds, before the GPU cluster even notices the disruption.

What it replaces, and what it builds on

At GTC DC, Huang described NVIDIA's networking stack in three tiers: NVLink for scale-up communication within a rack of 72 GPUs, Spectrum-X Ethernet for scale-out communication between racks, and Quantum InfiniBand as an alternative for operators who preferred it. The framing was deliberately flexible — "we don't care what language you would like to use, whether it's InfiniBand or Spectrum." MRC changes that posture. It is an explicit move to make Spectrum-X Ethernet competitive with InfiniBand on the reliability dimension that has historically been InfiniBand's strongest argument: deterministic, low-latency behavior under load.

MRC does not replace Ethernet. It extends a transport standard called Remote Direct Memory Access over Converged Ethernet (RoCEv2) that has been used in data centers for years. Think of RoCEv2 as the existing highway system. MRC adds real-time traffic intelligence and multiple independent lanes, so traffic distributes dynamically rather than piling into single corridors. It also borrows techniques from the Ultra Ethernet Consortium's earlier work on high-performance networking, incorporating path-control technology called Segment Routing over IPv6, or SRv6. The result is not a ground-up replacement but a meaningful evolution of what enterprises and cloud providers already run — and a direct challenge to the reliability case for InfiniBand at gigascale.

Who actually needs to invest in this infrastructure

Three categories of organizations will feel this announcement directly. The first is cloud infrastructure providers. Companies like Oracle, Microsoft, and others building AI cloud capacity are already deploying Spectrum-X and MRC. Their investment decisions are made. The second is enterprises building or expanding private AI infrastructure, the organizations training large models on owned hardware. If that is your trajectory, MRC-capable networking is now the benchmark to evaluate against, not just a premium option. The third category is the companies that have no intention of owning GPU infrastructure but rely on AI services built on top of it. That is most enterprises. Their exposure to this announcement runs through their cloud providers and the AI vendors they depend on.

The distinction that matters for the third group is this: a company renting compute capacity from a cloud provider does not configure its own network. It inherits whatever transport layer the provider has deployed. If that provider is running MRC on purpose-built hardware, the training runs that feed the AI products that company uses are more reliable and efficient. If the provider is running older Ethernet infrastructure, there is a performance gap that the tenant cannot close on their own.

The action for CIOs, CTOs, and the companies this will affect

For organizations building private AI infrastructure, the immediate action is to include MRC support in every networking RFP issued from this point forward, and to ask vendors specifically whether their implementation runs failure recovery in hardware or in software. The performance difference is real: hardware-level rerouting at microsecond speed is not the same outcome as software-based rerouting even if both vendors claim MRC compliance.

For organizations running AI workloads on cloud infrastructure, the action is a procurement conversation, not a technical one. Ask your cloud provider directly whether their AI training fabric runs MRC, on what hardware generation, and whether dedicated capacity gives you access to full protocol performance or whether you are sharing infrastructure where the tuning benefits don't reach tenant workloads. The answer should inform renewal and expansion decisions.

For companies whose AI exposure is entirely through SaaS products and AI-native applications, this announcement is background. What it means in practice is that the reliability and speed of the AI services you depend on is increasingly tied to the network infrastructure beneath the model, not just the model itself. Vendor stability questions should now include infrastructure depth, not just model capability.

The open standard matters. It prevents MRC from becoming a single-vendor proprietary layer. What does not automatically follow from an open specification is implementation equivalence across hardware. That gap is where infrastructure decisions over the next 18 months will be won or lost.