OpenAI, AMD, Broadcom, Intel, Microsoft और NVIDIA के consortium ने 5 मई को Open Compute Project के माध्यम से MRC — Multipath Reliable Connection — जारी किया, साथ में research paper (Araujo et al., arXiv:2605.04333) जो OpenAI के सबसे बड़े GB200 supercomputers पर इसके deployment का विवरण देता है, जिसमें Oracle Cloud Infrastructure के साथ Abilene, Texas में Stargate site और Microsoft का Fairwater शामिल हैं। MRC ChatGPT और Codex के नवीनतम frontier models के training runs के पीछे की networking layer है, और Towards Data Science में Gokul Chandra Purnachandra Reddy की गहन reading वह load-bearing observation सामने लाती है जिसे press coverage ने मिस किया: MRC प्रभावी रूप से data center fabric से पूरे Layer 3 control plane को समाप्त कर देता है। कोई OSPF नहीं, कोई BGP नहीं, कोई IS-IS नहीं, कोई FIB नहीं; switches शून्य dynamic forwarding state बनाए रखते हैं। Reddy के ज्ञान के अनुसार, यह आज तक सार्वजनिक रूप से documented किसी भी production AI training fabric में dynamic routing का सबसे आक्रामक उन्मूलन है।
पाँच counterintuitive design decisions, प्रत्येक व्यक्तिगत रूप से परिचित पर combination में radical: (1) 800 Gb/s NIC को आठ 100 Gb/s links में विभाजित करो, हर एक अपने switch पर — आठ independent network planes बनाता है। Two-tier topology पूर्ण bisection bandwidth पर 131,072 GPUs का समर्थन करती है बनाम पारंपरिक तीन tiers पर ~64K GPUs। सबसे ख़राब case path 3 hops vs 5-7 hops है। 3-tier deployment की तुलना में 2/3 optics और 3/5 switches का उपयोग करता है। (2) कोई dynamic routing protocols नहीं — केवल static routes, शून्य forwarding state, control plane इतना सरल कि एक छोटी team एक साथ कई supercomputers manage कर सके। (3) Packet spraying: हर transfer आठ planes में सैकड़ों random paths पर spray होता है; जब एक link fail होता है, NIC उस entropy value को retire करता है और microseconds में बाक़ी सात planes में traffic redistribute करता है। (4) Design से lossy Ethernet — backpressure cascades बनाने के बजाय जान-बूझकर packet loss स्वीकार करना, selective retransmission छोटी loss rate को संभालता है। (5) ECN को congestion-control signal के बजाय load-balancing signal के रूप में repurposed किया गया। 800 Gb/s NICs तीन अलग silicon vendors से आते हैं।
समस्या framing वही है जो engineering tradeoffs को बचाव योग्य बनाती है। 131,072 GPUs पर synchronous pretraining lock-step में चलता है — हर training step सबसे धीमे transfer पर निर्भर करता है। Paper का उद्धृत framing: "जैसे-जैसे computations scale करते हैं, communication तेज़ी से outlier-dominated हो जाता है।" 100K H100-class GPUs के लिए ~$300,000/घंटे की cloud दरों पर, हज़ारों steps में प्रति step 10ms tail-latency stall वास्तविक धन में compound होता है। Production-incident anecdote वज़न देने योग्य हिस्सा है: T0 switch पर एक optical transceiver में glitch हुआ और लगातार चारों links flap हुए, तीन active training nodes प्रभावित हुए; पारंपरिक network में यह training job crash कर देता, और MRC के साथ training जारी रही। Link failures पर resilience math: 800 Gb/s single-plane NIC एक ख़राब link पर 3% capacity खोता है; 100 Gb/s multi-plane 0.4% खोता है और बाक़ी सात planes पर operating जारी रखता है। Architecture network monitoring complexity (track करने के लिए 8× links) और पारंपरिक L3 fabrics पर बड़े हुए ops teams के लिए एक अलग mental model की लागत पर predictable bandwidth खरीदती है।
builders और infra teams के लिए: यह आज तक का सबसे ठोस data point है कि frontier-lab training-fabric architecture क्या बन गई है, और OCP release का मतलब है कि तुम protocol design का अध्ययन कर सकते हो बजाय job-listing keyword analysis से reverse-engineer करने के। तीन ठोस implications। पहला, अगर तुम frontier-lab-adjacent cloud से capacity ख़रीदते हो, Q3 तक MRC-style multi-plane fabrics को baseline मानने की अपेक्षा करो — single-path RoCE पर तुम्हारी workload tuning assumptions को फिर से देखने की ज़रूरत है। दूसरा, हर networking-OSS vendor जिसने AI fabrics के लिए विशेष रूप से OSPF/BGP optimizations भेजे, अब एक सिकुड़ता हुआ market देख रहा है; OpenAI consortium dynamic-routing elimination का अब तक documented सबसे बड़ा single deployment है, और जहाँ वे जाते हैं, NVIDIA/Microsoft/Oracle customers follow करते हैं। तीसरा, paper end-to-end पढ़ने योग्य है — Reddy की TDS deep-read उपयोगी guide है, पर arXiv reference (2605.04333) canonical स्रोत है। "पाँच counterintuitive decisions" framing editorial है; वास्तविक आश्चर्य यह है कि हर एक 131K-GPU deployment में एक साथ production-stress test पास कर गया, और OpenAI consortium ने इस engineering को proprietary रखने के बजाय "कैसे" प्रकाशित करने का चुनाव किया।