核心概念

MRC（Multipath Reliable Connection，多路徑可靠連接）是 OpenAI 聯合 AMD、Broadcom、Intel、Microsoft、NVIDIA 歷時兩年共同開發的超算網路協議，於 2026 年 5 月透過 OCP（Open Compute Project）開源發布。

大規模 AI 訓練的核心挑戰在於「同步預訓練」：數十萬顆 GPU 必須以完全同步的方式協作，任何一次網路延遲都會讓所有 GPU 空等，造成算力浪費。傳統問題有兩個根源：

  1. 網路擁塞：傳統協議（如 RoCE）強制每條資料流走單一路徑，多條流若選到相同連結就會互相擠塞。
  2. 故障恢復慢：傳統動態路由協議（如 BGP）在單一連結故障後需要數秒甚至數十秒重新計算路由，訓練任務因此崩潰。

MRC 透過三個核心機制解決這兩個問題：

① 多平面網路拓撲（Multi-plane Networks） 將 800Gb/s 網路介面拆分為八條 100Gb/s 連結，各連往不同交換機，構成八個獨立並行的網路「平面」。這讓整個叢集只需兩層交換機即可連通超過 131,000 顆 GPU（傳統需要三到四層），降低成本、耗電量，並大幅增加路徑多樣性。

② 封包噴射（Adaptive Packet Spraying） MRC 不再讓整條資料流走固定單路，而是把同一次傳輸的封包「噴灑」到數百條不同路徑。目的端可以亂序接收後直接寫入記憶體。這幾乎消除了網路核心的擁塞，故障反應速度為微秒級（傳統為秒級至十秒級）。若發生擁塞，交換機還會採用「封包裁切（Packet Trimming）」——只保留標頭轉發，觸發精確重傳，避免誤判為路徑故障。

③ SRv6 來源路由（Source Routing） 捨棄動態路由，改用 IPv6 Segment Routing（SRv6）——發送方把完整路徑直接嵌入封包標頭，交換機只需按靜態路由表轉發。這徹底消除了一整類動態路由故障行為，也大幅簡化網路控制平面複雜度。

關鍵要點

  • 開源生態：MRC 規範已透過 OCP 發布，論文《Resilient AI Supercomputer Networking using MRC and SRv6》同步公開
  • 生產驗證：已部署於所有 OpenAI NVIDIA GB200 超算（含 Texas Abilene OCI 站點及 Microsoft Fairwater），用於訓練 ChatGPT 與 Codex 等前沿模型
  • 維護彈性：可在不中斷訓練的情況下重啟多台 Tier-1 交換機或修復連結——過去這需要全叢集協調停機
  • 單連結容錯：GPU 介面埠故障時，MRC 立即重新計算路徑並通知所有對端迴避，訓練繼續進行，實際效能下降遠低於物理容量損失比例
  • 技術基礎：基於 RoCE（RDMA over Converged Ethernet）IBTA 標準擴展，融合 Ultra Ethernet Consortium（UEC）設計理念

實務應用

在 Stargate 規模的叢集上，MRC 展現出關鍵效益：每分鐘多次連結閃斷對同步預訓練零可量測影響，連結維修不再需要提前知會訓練團隊。工程師甚至不需要優先處理已閃斷的連結——只要 MRC 仍繞行，算力就不會損失。

這是 OpenAI 計算策略的重要一環：基礎設施關鍵層採用共享開放標準，能讓整個 AI 產業更有效率地擴展算力。MRC 開源意味著 AMD、Intel、Arista 等廠商都能基於相同協議建構下一代 AI 網路硬體，形成生態而非孤立方案。

相關頁面：Stargate 計畫：OpenAI 打造智能時代算力基礎設施 | OpenAI 語音 AI 低延遲架構：WebRTC 大規模部署實錄

延伸觀點

封包噴射已成 AI 網路主流方向。OpenAI 的 MRC 論文（arXiv 2605.04333）與阿里巴巴的 UCCL 研究（arXiv 2504.17307）都獨立得出相同結論：256 個以上的 QP（Queue Pair）多路噴射，搭配軟體或硬體的接收端亂序寫入，是消除 AI 訓練流量不均的根本解法。UCCL 以軟體實作同等效果，在單一 CPU Core 下讓 400Gbps 的集體通訊速度提升 3.3 倍，說明這個設計方向已具備可移植性。

百萬 GPU 規模下，網路架構差異攸關訓練效率。Meta 的 GenAI 基礎設施報告顯示，他們同時建立了 RoCE（Arista 7800）與 NVIDIA InfiniBand 兩個 24,576 GPU 叢集進行直接比較，初期多叢集使用率一度降至 10%-90%，必須透過拓撲感知排程才恢復到 90% 以上。這呼應了 MRC 把多平面拓撲視為前提的設計哲學——路徑多樣性不足，排程優化只是治標。

軟硬體控制平面分離是下一個戰場。MRC 以 SRv6 讓發送方主導路由，UCCL 則把傳輸決策從 NIC 硬體邏輯移回 CPU 軟體層，兩者殊途同歸：讓上層應用對網路路徑有更直接的控制權。這個趨勢預示超算網路標準化的下一步——不只是協議開源，而是整個控制平面的可程式化。

反向連結

以下頁面引用了本頁：