OpenAI、AMD、Broadcom、Intel、Microsoft、NVIDIA 組成的財團,透過 Open Compute Project 於 5 月 5 日公開 MRC——Multipath Reliable Connection——配套論文(Araujo et al., arXiv:2605.04333)詳述其在 OpenAI 最大的 GB200 超算上的部署,包括與 Oracle Cloud Infrastructure 合作、位於德州 Abilene 的 Stargate 站點,以及 Microsoft 的 Fairwater。MRC 是最近 ChatGPT 與 Codex 前沿模型訓練 run 背後的網路層,Gokul Chandra Purnachandra Reddy 在 Towards Data Science 上的深讀把媒體覆蓋漏掉的承重觀察拎出來了:MRC 實際上把 Layer 3 控制平面從資料中心 fabric 中完全清除了。沒有 OSPF、沒有 BGP、沒有 IS-IS、沒有 FIB;交換器維護零動態轉發狀態。在 Reddy 知識範圍內,這是迄今為止任何已公開記錄的生產級 AI 訓練 fabric 中,對動態路由最激進的剔除。
五個反直覺的設計決策,每一個單獨看都不陌生,組合在一起卻是激進:(1) 把 800 Gb/s NIC 拆成 8 條 100 Gb/s 鏈路,每條接到不同交換器——形成 8 個獨立網路平面。兩層拓撲在全二分頻寬下支援 131,072 GPU,而常規三層拓撲大約只能撐 ~64K。最差路徑 3 跳 vs 5-7 跳。光元件用 2/3、交換器用 3/5,相對三層部署。(2) 沒有動態路由協定——只有靜態路由,零轉發狀態,控制平面簡單到一小隊人可以同時管理多個超算。(3) 封包噴灑(packet spraying):每次傳輸被分散到八個平面裡的數百條隨機路徑;鏈路失敗時,NIC 把那個 entropy 值退掉,把流量在微秒內重新分配到其餘七個平面。(4) 故意有損 Ethernet——刻意接受丟包,而不是搭起反壓力級聯,小部分丟包由選擇性重傳處理。(5) ECN 被重新用作負載平衡訊號,而不是壅塞控制訊號。800 Gb/s NIC 來自三家不同的矽廠商。
把問題框對了,工程上的取捨才能站得住腳。131,072 GPU 的同步預訓練是 lock-step——每一步都要等最慢的傳輸完成。論文的原話框架:「隨著算力 scale 上去,通訊變得越來越被 outliers 主導。」在 ~300,000 美元/小時的雲端價格、10 萬張 H100 級 GPU 這樣的規模下,每步 10 毫秒的尾延遲、跨數千步累加起來,變成實打實的錢。生產事故那個故事是最該掂量的一段:一個 T0 交換器上的光模組抽風,四條鏈路連續 flap,影響了三個正在跑的訓練節點;在常規網路下這會 crash 訓練 job,而 MRC 下訓練繼續。鏈路故障的彈性帳:800 Gb/s 單平面 NIC 一條壞鏈路損失 3% 頻寬;100 Gb/s 多平面下損失 0.4%,且繼續在剩下的七個平面上跑。這個架構買到的是可預測的頻寬,代價是網路監控複雜度上去(要看八倍數量的鏈路),以及 ops 團隊需要換一個不同於常規 L3 fabric 的心智模型。
對 builder 與基礎設施團隊:這是迄今為止關於「前沿實驗室訓練 fabric 長成什麼樣」最具體的資料點,而 OCP 公開版本意味著你可以直接研究協定設計,而不是靠職缺 JD 關鍵字反推。三條具體含義。第一,如果你在向接近前沿實驗室的雲端供應商買容量,預期到 Q3,MRC 風格的多平面 fabric 會成為預設基線——你那些基於 single-path RoCE 的 workload 調校假設需要重做。第二,每一家專門為 AI fabric 出 OSPF/BGP 最佳化的網路 OSS 廠商,現在面對的是正在縮小的市場;OpenAI 這個財團是有據可查最大規模的「動態路由剔除」部署,他們往哪走,NVIDIA/Microsoft/Oracle 的客戶就跟著往哪走。第三,這篇論文值得通讀——Reddy 在 TDS 那篇是個好嚮導,但 arXiv 上的原文(2605.04333)才是規範引用。「五個反直覺決策」這個框架是編輯式的;真正令人驚訝的是:每一項都在 131K GPU 部署裡同時通過了生產壓力測試,而 OpenAI 財團選擇公開「怎麼做」,而不是把這套工程當作私產留著。