Meta 在 8 月 24 日公開了 MetaRoCE 的設計細節。這是他們自行開發的一套 RDMA 傳輸協定，用來取代標準 RoCE。在 10 月的 OCP 全球峰會上，完整的協定規格、一個名為 libsoftmetaroce 的參考實作，以及一套量產合規測試集，將會一併公布。
標準 RoCE 在十萬卡規模撐不住
RoCE 的設計前提是網路會依序把每個訊框送達，靠交換機上的 PFC（優先權流量控制）來保證不遺失封包。這個前提在幾百張卡的叢集上運作得還不錯，但到了 Meta 現在的規模就開始出問題。
Meta 自己的說法是，標準 RoCE 期望網路依序傳遞每個訊框、依賴 PFC，而且不鼓勵封包灑送（packet spraying）——但封包灑送恰恰是多平面大規模網路提升效能的手段。衝突就出在這裡：把同一條流的封包同時送往多條路徑，跟「依序傳遞」直接對立。PFC 又是逐跳回壓機制，一個地方壅塞就會一路往回頂，規模一旦拉大很容易連鎖擴散。而且像 all-reduce 這類集體通訊要同步上千個加速器，速度最慢的那筆傳輸就決定了整個作業的節奏。
Meta 提到的目標情境是「分散在多個資料中心與地區的數十萬張 GPU」。到這種規模，光靠交換機維持無損網路，等於是在跟機率對賭。
把智慧搬到網路卡上
MetaRoCE 的設計原則濃縮成一句話：
“The fabric sees packets, but the NIC sees intent.”
中文翻譯：「交換網路只看得到封包，網路卡才知道意圖。」
落實成六項設計：原生無序傳遞，封包故意灑送到多條路徑，資料直接寫入目的地記憶體位址，不設重新排序緩衝區；原生多路徑，每條連線維護多條邏輯路徑，各自追蹤往返延遲與 ECN 狀態；容忍封包遺失，把封包遺失當成常態，用選擇性確認位元圖補齊，不需要 PFC；雙重壅塞控制，發送端 AIMD 加上接收端的公平配額速率提示；拓樸無關，只要求 ECN 標記與 ECMP，胖樹、多平面、淺緩衝交換機都能跑；統一連線，單一佇列同時承載多條有序訊息串流與多條路徑，共用一個壅塞控制器。
64 個節點上的數字
實測跑在一個 64 節點的 AMD GPU 叢集上。吞吐量持續高於 RoCEv2；在 1% 封包遺失率下仍能保住約 86% 的吞吐量，10% 遺失率下依然能運作；在 4 平面與 8 平面拓樸下吞吐量呈線性擴展，最多測到 4000 條並行連線；單一平面失效時，流量會自動重新分配，應用層不需要介入。
從 64 個節點到「數十萬張卡」還有很長一段路，Meta 自己把後續工作分成三塊：機架內的向上擴展（scale-up）要優化短記憶體操作的快速信令，去掉重新排序緩衝區與 PFC 帶來的延遲；跨越數千公里的擴展（scale-across）要在毫秒級往返延遲的長途鏈路上做逐路徑自適應與公平性；儲存與 KV 快取情境則打算用接收端速率提示，來處理一次讀取同時扇出到多台伺服器的 incast 問題。
開源這一步是做給網路卡廠看的
網路卡端目前只有 AMD Pensando 是已驗證的實作，其他幾家還在準備中。這一點會決定 MetaRoCE 能走多遠——協定設計得再漂亮，如果進不了主流網路卡的韌體，就只是 Meta 自己內部的方案。
拿到 OCP 上開源，還明確對齊 ESUN（乙太網路可擴展統一網路）倡議，意圖很清楚：讓網路卡廠照這個規格出貨，Meta 自己的採購選項才會變寬。乙太網路陣營以前就走過這條路——當年 RoCE 能從 InfiniBand 手中搶下市占，靠的就是乙太網路生態便宜、供應商多。現在 RoCE 自己變成了瓶頸，Meta 想用同一套手法再來一輪：先把規格擺上檯面，讓大家跟著做。
對中國大陸做智算中心的團隊來說，10 月那份規格公布之後值得對照看看，尤其是「不需要 PFC」這一點。省下 PFC 調校，維運上就少了一個最麻煩的問題源。
參考來源：Meta 工程部落格、CocoLoop、OCP ESUN 相關資料；1% 封包遺失下約 86% 吞吐量、10% 遺失下仍可運作、64 節點 AMD GPU 叢集與 4000 條並行連線等測試數據，均按 Meta 公開的實測描述核對。