Meta OCP 2026 網絡讓開放設計在 AI 叢集中落地
Meta 已發布其 OCP 網絡簡報，詳述首個液冷網絡機架，以及連接日益分散的 AI 基礎設施的更廣泛部署方向。Meta OCP 2026 網絡結合了新的交換硬件、傳輸軟件及共享規格。核心挑戰在於，如何讓這些元件跨越不同供應商及營運環境協同運作。
公司於 10 月 26 日發布的回顧，跟進 10 月 12 至 15 日在加州聖荷西舉行的 Open Compute Project Global Summit。其 AI 網絡簡報介紹支援 Muse Wonder、Muse Spark 及 Prometheus 超級叢集的基礎設施。這些是公司對其架構的說明，而非對每項效能主張作出的獨立評估。
關鍵張力在於可重用的基礎設施，以及每次部署仍須因應具體情況完成的整合工作。NVIDIA 正好說明了這項分別的重要性。它供應技術並與 Meta 合作，同時身處供應商競逐完整 AI 系統的市場。開放介面不會消除這種競爭，只會改變供應商必須在哪些環節證明其價值。
Meta OCP 2026 網絡不止於交換器
Meta 的公告之所以重要，是因為它同時處理 AI 基礎設施的多個邊界，而非孤立地展示一款更快的交換器。
擴展內部網絡將加速器連接於一個高度協調的系統之中。擴展外部網絡則把這些系統連接成更大的叢集。跨地域網絡則延伸至不同地點分散的基礎設施之間。Meta 的產品組合涵蓋這三個範疇，不過各元件的部署及開發狀態並不相同。
IcePack 是 Meta 首個液冷網絡機架。其 IceCube 交換器刀鋒提供每秒 102.4 terabit 的交換容量，配備 128 個、每個以每秒 800 gigabit 運作的連接。Meta 指出，相關型號採用 Broadcom Tomahawk 6C 及 NVIDIA Spectrum-6 交換晶片。
兩個型號均運行 Meta 的開源網絡作業系統 FBOSS。網絡作業系統負責管理交換器如何轉送流量，以及提供營運控制功能。讓不同硬件型號共用軟件，為 Meta 營運不同供應商設備提供共同起點。
這個 開放網絡產品組合亦包括更新後的叢集架構，以及為 Meta 自家加速器而設的 Ethernet 連接。這些公告令討論由設備規格擴展至系統設計。
這項分別改變買家應如何解讀新聞。交換器標示的容量描述的是設備能力，並不能證明訓練工作可多快完成、基礎設施會有多常故障，或維護工作需要多少人手介入。
因此，有效的評估應把元件與其營運環境分開看待。相關問題包括流量如何到達交換器、壅塞如何形成，以及容量消失時應用程式如何反應。散熱及維護也應納入評估。
以營運商在交換器型號之間作選擇為例。共用作業系統是研究兩個選項的理由，但它不保證在每種工作負載、韌體版本或故障情況下都能呈現可互換的行為。是否能投產仍須由驗證決定。
相同道理亦適用於液冷。支援更高密度的設備，意味著對場地準備、監測及維修程序產生新的依賴。網絡團隊不能完全脫離負責建築物的人員來評估這個機架。
因此，Meta OCP 2026 網絡最適合被理解為一個協調一致的工程方向。公司正嘗試令網絡硬件、軟件及實體基礎設施同步演進。公開資料為評估這個方向提供技術起點。
不過，這並不代表每個機構都應複製 Meta 的架構。更有用的問題是：當周邊基礎設施改變時，哪些介面及營運做法仍然具有價值。
分散式 AI 容量令營運商及雲端合作夥伴承壓
最直接承壓的機構，是那些負責把可用加速器轉化為可靠訓練容量的人。
Meta 將 Prometheus 描述為一個橫跨俄亥俄州 New Albany 多幢相互連接建築物的超級叢集。其 10 月 19 日的說明指出，初始階段已完成。公司把已部署的基礎設施，與其擴展至約 100 萬個 GPU 的目標區分開來；GPU 是用於平行運算的處理器。
這項區分可避免常見誤讀。叢集最終的設計目標並不等於其現時設備數量。同樣地，公布擴建基礎設施，亦不能證明所有規劃中的資源何時可供訓練團隊使用。
Meta 的 Prometheus 基礎設施說明指出，其首個階段用於訓練 Muse 基礎模型。公司報告 Muse Wonder 預訓練的 goodput 超過 85%。Goodput 衡量的是有用的訓練進度，而不只是設備是否正在運行。
這些數字是 Meta 所報告的營運結果，不應視為對無關叢集的效能承諾。其更廣泛的意義在於所選用的衡量方式：有用工作比單靠已安裝硬件更重要。
對基礎設施營運商而言，這種框架改變了驗收標準。設備可用性固然必要，但它不能回答分散式工作負載能否穩定推進。團隊需要了解中斷、復原行為，以及令運算資源閒置等候的通訊延遲。
雲端服務供應商面對相關挑戰。帶來大型分散式工作負載的客戶，需要的不只是一些可租用的機器，而是連接這些機器的網絡能提供可預測的行為。
這會令雙方承受壓力。供應商必須說明其環境的限制；客戶則必須界定工作負載所需的通訊模式。任何一方都不應把小規模示範視為足以證明大型部署可行。
一個假設性的採購決定可令問題更具體。訓練團隊可能發現多個地點都有可用容量。在把協調式工作分配至這些地點之前，團隊必須評估通訊開銷是否抵銷增加加速器所帶來的好處。
答案取決於工作負載設計。有些工作可拆分成相對獨立的部分；另一些則需要反覆交換中間結果，並等待最慢的參與者。單靠更多可用硬件並不能解決這種依賴。
這亦解釋了為何基礎設施公告與 AI 產品團隊有關。模型路線圖最終取決於可用的運算容量，即使應用程式開發人員從不設定網絡交換器。驗證延誤可影響團隊能進行哪些實驗。
企業買家應避免把這種關係轉化為缺乏支持的產品預測。Meta 的網絡披露並不能證明未來應用程式回應時間、模型發布日期或客戶可用性。它們展示的是供應 AI 容量背後所需的工程工作。
實際壓力十分明確：營運商及供應商必須驗證他們打算交付的系統。元件數量及標稱頻寬，不能取代該系統必須支援的工作負載所需證據。
將流量決策移至端點改變工程負擔
Meta 的架構方向把更多責任移向發送流量的裝置，令傳輸行為成為網絡設計的核心。
MetaRoCE 是 Meta 用於遠端直接記憶體存取的傳輸協定，讓機器可以在較少處理器參與下交換資料。公司為 Ethernet 上的 AI 工作負載設計此協定；Ethernet 是廣泛使用的網絡技術系列。
根據 Meta 的 AI 傳輸設計，MetaRoCE 會把封包分散至多條路徑，並接受它們以不同次序到達。其端點會追蹤個別路徑，並對壅塞或故障作出反應。
這項設計之所以重要，是因為分散封包除了帶來路由機會，也會造成接收端問題。若流量經由延遲不同的路徑傳送，原本的傳送次序未必與到達次序相同。傳輸層必須有意識地處理這種行為。
Meta 所述的方法，讓發送及接收裝置掌握更多有關通訊進度的資訊。公司表示，其協定設計上可容忍封包遺失，而毋須要求網絡暫停流量以維持無損狀態。
這些是架構主張，並非對現有傳輸技術作出的普遍否定。某種方法的價值取決於其實作、工作負載及營運條件。協定說明確立預期行為；測試才可確立某個特定實作的實際行為。
更廣泛的機制是責任的重新分配。系統不再只期望網絡單獨維持應用程式所需的一切條件，而是由端點更積極參與管理通訊。當路徑呈現不同表現時，這可讓系統有更多回應方法。
但這也帶來新責任。端點軟件及硬件必須正確解讀訊號；營運商需要掌握這些端點所作決策的可觀測性；疑難排解必須連結網絡所觀察到的情況，以及傳輸層所作的決定。
一條假設性劣化連線可說明為何這種可觀測性重要。某個應用程式變慢，但沒有任何連結完全中斷。調查必須區分壅塞與設備問題，並確認流量是否已避開受影響的路徑。
架構可以提供更多選擇，但不代表這些選擇容易診斷。評估 Meta 式多路徑網絡的團隊，應問自己會如何在故障發生後重建事件經過。設計圖並不能回答這個營運問題。
還有一個採用次序需要考慮。已發布的規格、軟件實作及獲支援的硬件實作，是不同的里程碑。機構需要確認擬議部署實際依賴的是哪一個里程碑。
正因如此，供應商比較應保持中立。NVIDIA、Broadcom、AMD 及其他參與者，各自帶來不同組合的晶片、網絡軟件及系統整合能力。開放介面創造比較各種實作的空間，卻不會預先決定誰是贏家。
對買家而言，較有用的結果是更精確的評估流程。他們可以詢問哪些行為已標準化、哪些需要供應商擴充，以及哪些取決於客戶工程能力。這比在「開放」及「專有」等籠統標籤之間作選擇，更具參考價值。
以端點為中心的方向意義重大，因為它改變了由誰負責正確性與復原。其成效應透過可觀察的應用程式行為、獲支援的實作，以及清晰的診斷程序來評估。
開放介面仍留下平台整合問題
共用轉送介面並不會自動將交換器晶片周邊的設備標準化。
Open Switch Platform Architecture 計劃（OSPA）正處理這個尚餘的層面。Meta、Microsoft 及 Alibaba 發起了這項工作。OCP 將其規格描述為正在審核的進行中貢獻，討論其狀態時必須注意這項重要限定。
交換器平台架構涵蓋電源管理、設備庫存、環境監控、韌體維護及診斷等功能。路由協定及轉送管理則不在其所述範圍內。
這條界線是整個故事的核心。交換器不僅要正確地傳送封包；其軟件亦必須識別已連接的元件、監察溫度、管理更新，並在故障時提供有用資訊。
當這些介面因產品而異，採用另一供應商的設備便可能需要額外工程工作。OSPA 的建議是透過一套共同參考架構，令更多這類工作可以重用。
潛在好處很直接。若營運商能重用管理軟件與程序，評估替代設備時便較少需要重建基本整合。供應商可以在實作品質上競爭，同時提供更可預期的營運介面。
不過，這仍屬建議中的好處，而非已在整個市場獲驗證的結果。規格並不能說明有多少產品實作了它、實作是否忠實，或客戶實際節省了多少工程時間。
因此，最有力的質疑角度在於實作證據。設備可以聲稱相容，但重要行為仍可能未有記錄。具意義的評估需要在日常運作以外，同時檢視復原路徑、韌體變更及異常情況。
以一次中途失敗的韌體更新為例。相關問題包括：復原是否可行、哪些元件仍可連線，以及營運人員會收到甚麼資訊。介面規格有助界定這些問題，但硬件仍必須作出回答。
這對混合部署尤其重要。若每個平台在處理日常故障時都需要一套獨立的營運手冊，共同管理模型的價值便有限。可重用性應延伸至設備整個生命週期中的維護，而不應只限於初始啟動。
OSPA 亦令 Meta 的整體策略更具實務層面。該公司正處理一類通常較頻寬公告少受關注的工作。平台整合決定額外的硬件選擇能否成為可實際運用的選擇。
對追蹤這些變化的工程團隊而言，文件應保留預期行為與觀察結果之間的區別。將驗證結果保存在可搜尋知識庫，可令日後比較更容易。
當設備、韌體及規格按不同節奏演變時，這點尤其有用。較早設定所得的結果應能追溯至該設定，否則團隊可能將假設帶進已不再適用的部署。
其商業含意具條件性，但很具體。能減少整合及維護工作的供應商，會給予買家考慮的理由。買家仍需要證據，證明這種減省在真實營運條件下依然成立。
Ethernet Scale-Up 挑戰整合系統的界線
Meta 的 Ethernet scale-up 工作挑戰了一條設計界線，但並未證明每個加速器系統都能使用同一種互連方式。
Ethernet for Scale-Up Networking（ESUN）是 OCP 的一項工作流，專注於緊密連接的加速器系統所使用的 Ethernet 交換與封裝。其範圍涵蓋網絡行為，而非加速器周邊完整的軟硬件堆疊。
OCP 的 Ethernet scale-up 範圍明確將網絡功能與端點功能分開。後者包括與加速器架構密切相關的議題，例如工作負載分割及記憶體排序。
這項區分限制了讀者應從參與該計劃推論出的結論。支援 ESUN 的供應商，不一定承諾每一種加速器、通訊函式庫及機架設計都會變得可互換。
Meta 將 Tahan（一款用於其 MTIA 300 訓練系統、以 Ethernet 為基礎的交換器）列為其 scale-up 方向的一部分。MTIA 是 Meta 內部開發的加速器系列。該公司亦談及未來設計及持續的標準發展。
運作中的系統與未來架構之間的區別，在此同樣重要。現有設備為特定實作提供證據；預覽則描述預定的發展。兩者均不應被不加說明地互相替代。
NVIDIA 提供了一個有用的競爭參照，但不會令故事變成單純的競爭對立。Meta 的基礎設施採用 NVIDIA 技術，同時 Meta 亦開發自家加速器，並參與共享網絡工作。這些關係可以並存。
對買家而言，重要比較在於不同的整合模式。一個高度協調的系統提供一組既定且受支援的組合；較模組化的設計則提供更多元件選擇，同時亦帶來驗證這些組合的責任。
兩種模式都不能消除工程限制。整合系統仍需針對客戶的工作負載進行驗證；模組化系統在故障跨越供應商界線時，仍需要連貫的支援安排。
因此，財務問題應包括工程投入，而不只是設備選擇。若組織無法支援由此產生的組合，更廣泛的供應商池在實務上的價值便有限。反過來，即使未能即時更換供應商，標準化介面仍可能有價值。
它可為買家提供更清晰的遷移路徑、更具體的驗收測試，或比較競爭方案的方法。這些好處取決於介面能否完整涵蓋客戶所需的行為。
對開發者而言，影響會在堆疊較高層出現。通訊函式庫與工作負載配置決定應用程式能如何善用可用連線。網絡標準無法獨立為每個模型選擇最佳分割方式。
這正是 Ethernet scale-up 值得作為工程路線而非既定市場結果來關注的原因。其進展應透過受支援的系統、互通性結果及工作負載證據來衡量。單靠參與公告不足以解決這些問題。
Meta OCP 2026 networking 強化了評估這條路線的理由，但不足以支持所有既有系統界線已經消失的假設。
下一批訊號是規格、實作及營運證據
最有用的後續證據，將把公開設計連結到各機構可自行評估的設備與軟件。
第一個訊號是規格進展。未來數月，應留意 OSPA 的審核與 ESUN 的發展如何轉化為更清晰的實作要求。關鍵進展是對受支援行為與相符性的更高精確度。
當修訂文件解決實作者面對的模糊之處時，它便具意義。除非帶來相應的技術貢獻或受支援產品，否則更多參與者名單的意義較小。讀者應區分組織動能與實作進展。
更清晰的要求會強化 Meta 所提出、共享介面可減少重複工作的論點。持續的模糊性則會削弱這個論點，尤其是在供應商對同一要求作出不同解讀之處。
第二個訊號是實作可用性。Meta 的十月回顧指出，已有可用的使用者空間 MetaRoCE 實作，並稱更多軟件工作即將推出。使用者空間軟件在作業系統核心之外運行，因此屬於不同的實作類別。
應留意可用程式碼是否附有可用的文件、測試及清晰說明的限制。儲存庫的存在是進一步調查的邀請，並不等同廣泛的生產環境支援。
更多受支援的實作會令該架構更易於跨環境評估。不論底層設計多具吸引力，延誤或不清晰的支援界線都會收窄外部機構可合理採用的範圍。
第三個訊號是營運證據。應尋找解釋設定、故障條件及復原行為的工作負載量度。獨立評估可提供公司簡報本身無法提供的觀點。
有用的證據應回答一條具體問題。當連線效能下降時，系統能否維持應用程式進度？營運人員能否識別問題？更換元件是否需要在承諾的介面以外作出變更？
能回答這些問題的結果，會強化可重用基礎設施的實務理據。顯示需要大量部署專屬工作的結果，則會揭示標準化仍未完整之處。無論哪種結果，都比另一個峰值容量標題更有資訊價值。
對企業買家而言，當前行動是完善評估準則。要求供應商指出標準化介面、實作依賴項及其驗證所涵蓋的條件。要求清楚區分可用產品與未來計劃。
對開發者及 AI 產品團隊而言，教訓是追蹤可用基礎設施，而非只追蹤已公布的容量。當網絡進展能擴展團隊可可靠運行的實驗與工作負載時，才真正重要。
從已公布的架構開始，並沿着證據追蹤至實作、驗證報告及維護行為。以你實際需要運行的工作負載來比較系統。將目前部署與預覽分開，也將公司量度與獨立發現分開。Meta OCP 2026 networking 為開放 AI 基礎設施提供了詳細方向；下一個有用步驟，是檢視哪些部分能轉化為可重複的營運成果。審閱下一份供應商方案或技術更新時，請提出一條具體問題：哪一個已記錄的介面、受支援的實作或已量度的行為，令這個系統更易部署及持續運行？
