OpenAI 推出 MRC（多路徑可靠連接），這是一項透過 OCP 發佈的新型超級電腦網路協定，旨在提升大規模 AI 訓練集群的韌性與效能。
2026 年 5 月 5 日
前沿模型的訓練依賴於可靠的超級電腦網路，以便在 GPU 之間快速移動數據。為了讓這一過程更快速且更高效，OpenAI 與 AMD、Broadcom、Intel、Microsoft 及 NVIDIA 合作開發了 MRC（多路徑可靠連接，Multipath Reliable Connection）：這是一種新型協定，可提升大型訓練集群中的 GPU 網路效能與韌性。我們今天透過開放運算專案 (OCP) 發布了 MRC（在新視窗中開啟），以供更廣泛的業界使用。
每週有超過 9 億人使用 ChatGPT，我們的系統正成為 AI 的核心基礎設施，幫助全球的人們與企業利用能力日益增強的模型進行開發。在 Stargate 計劃啟動之前，我們在幾年的時間裡，透過與合作夥伴的精心維護與密切協作，共同開發並啟動了前三代超級電腦。這些寶貴的經驗讓我們堅信：要有效利用 Stargate 規模的算力並實現我們的使命，我們需要重新思考並大幅降低堆疊中每一層的複雜性——包括網路設計。
發布 MRC 規範是 OpenAI 整體算力策略的一部分：關鍵基礎設施層的共享標準有助於更高效、更可靠地擴展 AI 系統，並跨越更廣泛的合作夥伴生態系統。在本文中，我們將介紹 MRC 的設計，包括：i) 它如何讓我們構建多平面高速網路以建立冗餘，從而在網路故障中生存，同時使用更少的組件和更低的功耗；ii) MRC 的自適應封包噴灑（packet spraying）如何虛擬消除核心擁塞；以及 iii) 我們的部署如何使用靜態來源路由（static source routing）來繞過故障並消除整類路由失效問題。這些優勢共同作用，讓我們能更快地為每個人提供更好的模型。
在訓練大型 AI 模型時，單個步驟可能涉及數百萬次數據傳輸。只要有一個傳輸延遲到達，就可能波及整個任務，導致 GPU 處於閒置狀態。網路擁塞、鏈路和設備故障是傳輸延遲和抖動（jitter）最常見的原因。
隨著集群規模的擴大，這些問題變得更加頻繁且難以解決。這使得網路技術成為 Stargate 設計的關鍵部分。
為了實現目前 Stargate 超級電腦的規模，我們面臨兩個關鍵的網路挑戰。首先，應盡可能減少網路擁塞的可能性。雖然存在不可避免的瓶頸（例如兩個 GPU 同時向同一個目的地發送數據），但在這些情況之外，我們應該透過設計來避免擁塞。
其次，我們需要將網路故障對訓練任務本身的影響降至最低。在足夠大的規模下，即使是最好的網路也會有持續的鏈路和交換機故障背景水平。以前，單個故障通常會導致訓練任務崩潰，迫使從儲存的檢查點（checkpoint）重新啟動，或者在網路重新計算路由時停滯數秒。這種中斷在 GPU 週期和時間上都代價高昂。對於同步預訓練（即多台電腦上的許多 GPU 步調一致地協作訓練一個 AI 模型）來說，情況尤其如此。運行的任務越大，任何單個鏈路抖動或故障的影響就越大。這些工作負載充當了一種「故障放大器」，因此防止這種情況變得至關重要。
我們的目標不僅是建立一個快速的網路，還要建立一個即使在存在故障的情況下也能提供極高可預測效能的網路，以保持訓練任務持續進行。
為了實現這種可靠性，我們的擴展（Scaling）團隊在過去兩年中與 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作開發了一種構建和運行網路的新方法。這項努力的成果是一種我們稱為「多路徑可靠連接」（Multipath Reliable Connection，簡稱 MRC）的技術。這是一種內建於最新 800Gb/s 網路介面中的新網路協定，它讓我們能將單次傳輸分散到數百條路徑上，在微秒內繞過故障，並運行更簡單的網路控制平面。
MRC 擴展了聚合乙太網路上的 RDMA (RoCE)——這是一項 InfiniBand 貿易協會 (IBTA) 標準，可實現 GPU 和 CPU 之間的硬體加速遠端直接記憶體存取。它借鑒了超乙太網路聯盟 (UEC) 開發的技術，並透過基於 SRv6 的來源路由進行擴展，以支援大規模 AI 網路架構。
MRC 已經部署在 OpenAI 所有用於訓練前沿模型的最大型 NVIDIA GB200 超級電腦上，包括我們位於德州阿比林（Abilene）的 Oracle 雲端基礎設施 (OCI) 站點，以及 Microsoft 的 Fairwater 超級電腦。MRC 已被用於訓練多個 OpenAI 模型，利用了來自 NVIDIA 和 Broadcom 的硬體。今天，MRC 規範已作為開放運算專案 (OCP) 的貢獻發布，供社群使用和開發。我們共同撰寫了一篇詳細介紹我們經驗的論文：《使用 MRC 和 SRv6 的韌性 AI 超級電腦網路》。
構建高韌性網路需要從網路拓撲開始，該拓撲必須具有足夠的自然冗餘，以便即使在網路中的鏈路或交換機發生故障時，所有流量仍能獲得良好效能。
我們不將每個網路介面視為單條 800Gb/s 鏈路，而是將其拆分為多條較小的鏈路。例如，一個介面可以連接到八個不同的交換機。然後，你可以構建八個獨立的平行網路（或稱為「平面」），每個平面以 100Gb/s 運行，而不是單個 800Gb/s 網路。
這種改變對集群的形態產生了巨大影響。一個可以連接 64 個 800Gb/s 埠的交換機，現在可以連接 512 個 100Gb/s 埠。這讓你只需兩層交換機即可構建一個完全連接約 131,000 個 GPU 的網路。傳統的 800Gb/s 網路則需要三到四層。
其結果是一個成本更低、功耗更低，且比傳統網路設計提供更多路徑多樣性的網路。它還允許更多流量保留在 Tier 0 交換機本地，從而提高效能。
然而，所有這些路徑多樣性可能難以充分利用。用於 AI 訓練的傳統網路協定通常要求每次傳輸遵循單一路徑，以便封包按順序到達。在大型多平面網路中，這會產生兩個問題：不同的流可能在同一鏈路上碰撞並產生擁塞，且每個流只能使用其中一個可用平面。如果我們不做其他改變，多平面網路將導致嚴重的擁塞和糟糕的整體效能。
MRC 從根本上改變了這種模式。MRC 不再將傳輸分配給單一路徑，而是將單次傳輸的封包「噴灑」到我們網路中跨越所有不同平面的數百條路徑上。封包可能會不按順序到達，但所有 MRC 封包都包含其最終記憶體位址，因此目的地可以在封包到達時直接將其交付至記憶體。
每個 MRC 連接都會為其使用的多條路徑保留少量狀態。如果偵測到某條路徑變得擁塞，它會將該路徑更換為另一條，從而平衡整個網路的負載。如果丟失了一個封包，它會採取安全的做法：假設該路徑上的某些設備可能已故障並立即停止使用該路徑，同時重新傳輸可能已丟失的任何封包。在 MRC 停用一條路徑後，它會發送探測封包來檢查是否真的發生了故障，如果是，則檢查是否已恢復。
故障並非丟包的唯一原因；另一個常見原因是目的地的擁塞。MRC 透過「封包修剪」（packet trimming）來處理這種情況。如果交換機因擁塞而不得不丟棄封包，它會修剪掉負載（payload），僅將標頭（header）轉發到目的地，從而觸發明確的重新傳輸請求。封包修剪減少了誤報，避免我們錯誤地將擁塞導致的丟包視為路徑故障。
這種多平面拓撲、噴灑、負載平衡和修剪的結合，意味著 MRC 連接可以在微秒級的時間尺度內偵測網路故障並繞過它們，從而將對同步訓練任務的影響降至最低。相比之下，傳統的網路架構可能需要數秒甚至數十秒才能穩定並繞過故障。
MRC 讓我們在簡化網路方面更進一步。
傳統上，交換機運行 BGP（邊界閘道協定）等動態路由協定來計算可用路徑並繞過故障。但交換機是運行複雜軟體的複雜設備。當它們以微妙的方式發生故障時，這些問題可能難以診斷，並在修復前導致連接失敗。
有了 MRC，動態路由變得不再那麼必要。如果路徑上丟失了封包，MRC 就停止使用該路徑。我們採取了更激進的方法：禁用動態路由，轉而使用 IPv6 分段路由（或稱 SRv6）。SRv6 讓發送者直接指定每個封包在網路中應遵循的路徑。它透過將交換機識別碼序列嵌入到每個封包的目的地位址中來實現這一點。
分解來看：在轉發時，交換機會檢查是否存在自己的識別碼。如果存在，它會透過移動目的地位址來移除該識別碼，從而顯露下一個交換機的識別碼。然後，交換機在靜態路由表中查找此識別碼，以確定下一個封包的發送位置。與動態路由不同，此靜態路由表在交換機首次配置時設定，之後永不更改。
MRC 使用 SRv6 將封包噴灑到所有網路平面，並同時噴灑到每個平面上的多條路徑。如果某條路徑故障，MRC 只需停止使用它即可。交換機不需要重新計算路由，除了盲目遵循配置好的靜態路由外，不需要做任何事情。
我們的訓練網路擁有數百萬條鏈路。雖然這些網路品質很高，但在足夠的規模下，某些鏈路抖動是不可避免的。在訓練期間，我們觀察到 Tier-0 和 Tier-1 交換機之間每分鐘發生多次鏈路抖動的情況，但 MRC 確保了這些抖動對我們的同步預訓練任務沒有可衡量的影響。事實上，其影響微小到我們甚至不需要優先立即修復那些鏈路。
不僅僅是鏈路會發生故障。在最近為 ChatGPT 和 Codex 訓練前沿模型期間，我們不得不重啟四台 Tier-1 交換機。以前，重啟交換機需要營運團隊非常小心，以免中斷訓練。有了 MRC，我們甚至不需要與集群中運行訓練任務的團隊進行協調。許多鏈路修復也是如此。我們以前在需要進行維護工作時，必須與營運團隊協調以禁用鏈路。現在我們可以在鏈路仍在服務時進行修復。如果鏈路運行良好，MRC 就會使用它；如果不行，MRC 會避開它直到修復為止。
在 MRC 出現之前，如果 GPU 網路介面與 Tier-0 交換機之間的鏈路故障，訓練任務就會失敗。有了 MRC，任務可以憑藉合理的效能繼續運行。如果一個 8 埠網路介面丟失了一個埠，最大速率會降低八分之一。MRC 會偵測到這一點，重新計算路徑以避開故障平面，並立即告知對等端不要將該平面用於入站流量。大多數故障鏈路會在幾分鐘內恢復，此時 MRC 會重新啟用該平面。
因丟失 GPU 介面鏈路而導致的減速在不同的訓練任務中有所不同，但在實踐中，減速程度往往顯著低於損失的物理容量比例。
MRC 最終在擴展超級電腦時為我們提供了三個關鍵優勢。
首先，它讓我們能僅使用兩層乙太網路交換機，為擁有超過 100,000 個 GPU 的超級電腦構建多平面高速網路。這提供了足夠的冗餘來應對網路故障，同時比同等的三層或四層單平面網路功耗更低。
其次，MRC 的自適應封包噴灑負載平衡效果極佳，我們在網路核心基本上看不到擁塞。這大大減少了同步訓練期間流與流之間的吞吐量差異，而在同步訓練中，消除離群值（outliers）對於效能至關重要。這也意味著當多個任務共享集群時，它們不會影響彼此的效能。
最後，MRC 使用 SRv6 來源路由快速繞過故障，並僅透過正常運作的路徑發送封包。這讓我們能運行簡單的靜態網路控制平面，並消除整類動態路由故障行為。
MRC 顯著提升了我們訓練新前沿模型的能力，並確保我們的網路能跟上研究人員雄心勃勃的 AI 路線圖。它比以前的方法有了顯著改進，並有助於加速實現我們將 AGI 的益處可靠地帶給每個人的目標。我們為促成這一切的跨行業協作感到自豪。
隨著訓練集群的不斷增長，網路設計日益決定了實際能使用多少可用算力。MRC 幫助我們在擁塞、鏈路故障和維護事件中保持 GPU 協同運作，而這些事件在以前會中斷訓練。在有意義的規模下，這種可靠性和效率並非可有可無；它是使同步前沿模型訓練成為可能的部分原因。
致謝
跨行業協作將繼續是解決許多 AI 最難問題的關鍵。我們感謝與 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作開發 MRC，以及與 Microsoft Azure、OCI、NVIDIA 和 Arista 合作進行大規模部署。我們都致力於推動生態系統的發展，並期待看到業界未來如何應用 MRC。
工程 2026 年 5 月 4 日
工程 2026 年 4 月 27 日
工程 2026 年 4 月 22 日
— OpenAI
相關文章
其他收藏 · 0
OpenAI 推出 MRC（多路徑可靠連接），這是一項透過 OCP 發佈的新型超級電腦網路協定，旨在提升大規模 AI 訓練集群的韌性與效能。
2026 年 5 月 5 日
前沿模型的訓練依賴於可靠的超級電腦網路，以便在 GPU 之間快速移動數據。為了讓這一過程更快速且更高效，OpenAI 與 AMD、Broadcom、Intel、Microsoft 及 NVIDIA 合作開發了 MRC（多路徑可靠連接，Multipath Reliable Connection）：這是一種新型協定，可提升大型訓練集群中的 GPU 網路效能與韌性。我們今天透過開放運算專案 (OCP) 發布了 MRC（在新視窗中開啟），以供更廣泛的業界使用。
每週有超過 9 億人使用 ChatGPT，我們的系統正成為 AI 的核心基礎設施，幫助全球的人們與企業利用能力日益增強的模型進行開發。在 Stargate 計劃啟動之前，我們在幾年的時間裡，透過與合作夥伴的精心維護與密切協作，共同開發並啟動了前三代超級電腦。這些寶貴的經驗讓我們堅信：要有效利用 Stargate 規模的算力並實現我們的使命，我們需要重新思考並大幅降低堆疊中每一層的複雜性——包括網路設計。
發布 MRC 規範是 OpenAI 整體算力策略的一部分：關鍵基礎設施層的共享標準有助於更高效、更可靠地擴展 AI 系統，並跨越更廣泛的合作夥伴生態系統。在本文中，我們將介紹 MRC 的設計，包括：i) 它如何讓我們構建多平面高速網路以建立冗餘，從而在網路故障中生存，同時使用更少的組件和更低的功耗；ii) MRC 的自適應封包噴灑（packet spraying）如何虛擬消除核心擁塞；以及 iii) 我們的部署如何使用靜態來源路由（static source routing）來繞過故障並消除整類路由失效問題。這些優勢共同作用，讓我們能更快地為每個人提供更好的模型。
在訓練大型 AI 模型時，單個步驟可能涉及數百萬次數據傳輸。只要有一個傳輸延遲到達，就可能波及整個任務，導致 GPU 處於閒置狀態。網路擁塞、鏈路和設備故障是傳輸延遲和抖動（jitter）最常見的原因。
隨著集群規模的擴大，這些問題變得更加頻繁且難以解決。這使得網路技術成為 Stargate 設計的關鍵部分。
為了實現目前 Stargate 超級電腦的規模，我們面臨兩個關鍵的網路挑戰。首先，應盡可能減少網路擁塞的可能性。雖然存在不可避免的瓶頸（例如兩個 GPU 同時向同一個目的地發送數據），但在這些情況之外，我們應該透過設計來避免擁塞。
其次，我們需要將網路故障對訓練任務本身的影響降至最低。在足夠大的規模下，即使是最好的網路也會有持續的鏈路和交換機故障背景水平。以前，單個故障通常會導致訓練任務崩潰，迫使從儲存的檢查點（checkpoint）重新啟動，或者在網路重新計算路由時停滯數秒。這種中斷在 GPU 週期和時間上都代價高昂。對於同步預訓練（即多台電腦上的許多 GPU 步調一致地協作訓練一個 AI 模型）來說，情況尤其如此。運行的任務越大，任何單個鏈路抖動或故障的影響就越大。這些工作負載充當了一種「故障放大器」，因此防止這種情況變得至關重要。
我們的目標不僅是建立一個快速的網路，還要建立一個即使在存在故障的情況下也能提供極高可預測效能的網路，以保持訓練任務持續進行。
為了實現這種可靠性，我們的擴展（Scaling）團隊在過去兩年中與 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作開發了一種構建和運行網路的新方法。這項努力的成果是一種我們稱為「多路徑可靠連接」（Multipath Reliable Connection，簡稱 MRC）的技術。這是一種內建於最新 800Gb/s 網路介面中的新網路協定，它讓我們能將單次傳輸分散到數百條路徑上，在微秒內繞過故障，並運行更簡單的網路控制平面。
MRC 擴展了聚合乙太網路上的 RDMA (RoCE)——這是一項 InfiniBand 貿易協會 (IBTA) 標準，可實現 GPU 和 CPU 之間的硬體加速遠端直接記憶體存取。它借鑒了超乙太網路聯盟 (UEC) 開發的技術，並透過基於 SRv6 的來源路由進行擴展，以支援大規模 AI 網路架構。
MRC 已經部署在 OpenAI 所有用於訓練前沿模型的最大型 NVIDIA GB200 超級電腦上，包括我們位於德州阿比林（Abilene）的 Oracle 雲端基礎設施 (OCI) 站點，以及 Microsoft 的 Fairwater 超級電腦。MRC 已被用於訓練多個 OpenAI 模型，利用了來自 NVIDIA 和 Broadcom 的硬體。今天，MRC 規範已作為開放運算專案 (OCP) 的貢獻發布，供社群使用和開發。我們共同撰寫了一篇詳細介紹我們經驗的論文：《使用 MRC 和 SRv6 的韌性 AI 超級電腦網路》。
構建高韌性網路需要從網路拓撲開始，該拓撲必須具有足夠的自然冗餘，以便即使在網路中的鏈路或交換機發生故障時，所有流量仍能獲得良好效能。
我們不將每個網路介面視為單條 800Gb/s 鏈路，而是將其拆分為多條較小的鏈路。例如，一個介面可以連接到八個不同的交換機。然後，你可以構建八個獨立的平行網路（或稱為「平面」），每個平面以 100Gb/s 運行，而不是單個 800Gb/s 網路。
這種改變對集群的形態產生了巨大影響。一個可以連接 64 個 800Gb/s 埠的交換機，現在可以連接 512 個 100Gb/s 埠。這讓你只需兩層交換機即可構建一個完全連接約 131,000 個 GPU 的網路。傳統的 800Gb/s 網路則需要三到四層。
其結果是一個成本更低、功耗更低，且比傳統網路設計提供更多路徑多樣性的網路。它還允許更多流量保留在 Tier 0 交換機本地，從而提高效能。
然而，所有這些路徑多樣性可能難以充分利用。用於 AI 訓練的傳統網路協定通常要求每次傳輸遵循單一路徑，以便封包按順序到達。在大型多平面網路中，這會產生兩個問題：不同的流可能在同一鏈路上碰撞並產生擁塞，且每個流只能使用其中一個可用平面。如果我們不做其他改變，多平面網路將導致嚴重的擁塞和糟糕的整體效能。
MRC 從根本上改變了這種模式。MRC 不再將傳輸分配給單一路徑，而是將單次傳輸的封包「噴灑」到我們網路中跨越所有不同平面的數百條路徑上。封包可能會不按順序到達，但所有 MRC 封包都包含其最終記憶體位址，因此目的地可以在封包到達時直接將其交付至記憶體。
每個 MRC 連接都會為其使用的多條路徑保留少量狀態。如果偵測到某條路徑變得擁塞，它會將該路徑更換為另一條，從而平衡整個網路的負載。如果丟失了一個封包，它會採取安全的做法：假設該路徑上的某些設備可能已故障並立即停止使用該路徑，同時重新傳輸可能已丟失的任何封包。在 MRC 停用一條路徑後，它會發送探測封包來檢查是否真的發生了故障，如果是，則檢查是否已恢復。
故障並非丟包的唯一原因；另一個常見原因是目的地的擁塞。MRC 透過「封包修剪」（packet trimming）來處理這種情況。如果交換機因擁塞而不得不丟棄封包，它會修剪掉負載（payload），僅將標頭（header）轉發到目的地，從而觸發明確的重新傳輸請求。封包修剪減少了誤報，避免我們錯誤地將擁塞導致的丟包視為路徑故障。
這種多平面拓撲、噴灑、負載平衡和修剪的結合，意味著 MRC 連接可以在微秒級的時間尺度內偵測網路故障並繞過它們，從而將對同步訓練任務的影響降至最低。相比之下，傳統的網路架構可能需要數秒甚至數十秒才能穩定並繞過故障。
MRC 讓我們在簡化網路方面更進一步。
傳統上，交換機運行 BGP（邊界閘道協定）等動態路由協定來計算可用路徑並繞過故障。但交換機是運行複雜軟體的複雜設備。當它們以微妙的方式發生故障時，這些問題可能難以診斷，並在修復前導致連接失敗。
有了 MRC，動態路由變得不再那麼必要。如果路徑上丟失了封包，MRC 就停止使用該路徑。我們採取了更激進的方法：禁用動態路由，轉而使用 IPv6 分段路由（或稱 SRv6）。SRv6 讓發送者直接指定每個封包在網路中應遵循的路徑。它透過將交換機識別碼序列嵌入到每個封包的目的地位址中來實現這一點。
分解來看：在轉發時，交換機會檢查是否存在自己的識別碼。如果存在，它會透過移動目的地位址來移除該識別碼，從而顯露下一個交換機的識別碼。然後，交換機在靜態路由表中查找此識別碼，以確定下一個封包的發送位置。與動態路由不同，此靜態路由表在交換機首次配置時設定，之後永不更改。
MRC 使用 SRv6 將封包噴灑到所有網路平面，並同時噴灑到每個平面上的多條路徑。如果某條路徑故障，MRC 只需停止使用它即可。交換機不需要重新計算路由，除了盲目遵循配置好的靜態路由外，不需要做任何事情。
我們的訓練網路擁有數百萬條鏈路。雖然這些網路品質很高，但在足夠的規模下，某些鏈路抖動是不可避免的。在訓練期間，我們觀察到 Tier-0 和 Tier-1 交換機之間每分鐘發生多次鏈路抖動的情況，但 MRC 確保了這些抖動對我們的同步預訓練任務沒有可衡量的影響。事實上，其影響微小到我們甚至不需要優先立即修復那些鏈路。
不僅僅是鏈路會發生故障。在最近為 ChatGPT 和 Codex 訓練前沿模型期間，我們不得不重啟四台 Tier-1 交換機。以前，重啟交換機需要營運團隊非常小心，以免中斷訓練。有了 MRC，我們甚至不需要與集群中運行訓練任務的團隊進行協調。許多鏈路修復也是如此。我們以前在需要進行維護工作時，必須與營運團隊協調以禁用鏈路。現在我們可以在鏈路仍在服務時進行修復。如果鏈路運行良好，MRC 就會使用它；如果不行，MRC 會避開它直到修復為止。
在 MRC 出現之前，如果 GPU 網路介面與 Tier-0 交換機之間的鏈路故障，訓練任務就會失敗。有了 MRC，任務可以憑藉合理的效能繼續運行。如果一個 8 埠網路介面丟失了一個埠，最大速率會降低八分之一。MRC 會偵測到這一點，重新計算路徑以避開故障平面，並立即告知對等端不要將該平面用於入站流量。大多數故障鏈路會在幾分鐘內恢復，此時 MRC 會重新啟用該平面。
因丟失 GPU 介面鏈路而導致的減速在不同的訓練任務中有所不同，但在實踐中，減速程度往往顯著低於損失的物理容量比例。
MRC 最終在擴展超級電腦時為我們提供了三個關鍵優勢。
首先，它讓我們能僅使用兩層乙太網路交換機，為擁有超過 100,000 個 GPU 的超級電腦構建多平面高速網路。這提供了足夠的冗餘來應對網路故障，同時比同等的三層或四層單平面網路功耗更低。
其次，MRC 的自適應封包噴灑負載平衡效果極佳，我們在網路核心基本上看不到擁塞。這大大減少了同步訓練期間流與流之間的吞吐量差異，而在同步訓練中，消除離群值（outliers）對於效能至關重要。這也意味著當多個任務共享集群時，它們不會影響彼此的效能。
最後，MRC 使用 SRv6 來源路由快速繞過故障，並僅透過正常運作的路徑發送封包。這讓我們能運行簡單的靜態網路控制平面，並消除整類動態路由故障行為。
MRC 顯著提升了我們訓練新前沿模型的能力，並確保我們的網路能跟上研究人員雄心勃勃的 AI 路線圖。它比以前的方法有了顯著改進，並有助於加速實現我們將 AGI 的益處可靠地帶給每個人的目標。我們為促成這一切的跨行業協作感到自豪。
隨著訓練集群的不斷增長，網路設計日益決定了實際能使用多少可用算力。MRC 幫助我們在擁塞、鏈路故障和維護事件中保持 GPU 協同運作，而這些事件在以前會中斷訓練。在有意義的規模下，這種可靠性和效率並非可有可無；它是使同步前沿模型訓練成為可能的部分原因。
致謝
跨行業協作將繼續是解決許多 AI 最難問題的關鍵。我們感謝與 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作開發 MRC，以及與 Microsoft Azure、OCI、NVIDIA 和 Arista 合作進行大規模部署。我們都致力於推動生態系統的發展，並期待看到業界未來如何應用 MRC。
工程 2026 年 5 月 4 日
工程 2026 年 4 月 27 日
工程 2026 年 4 月 22 日
— OpenAI
相關文章
其他收藏 · 0
