前沿模型的訓練依賴於可靠的超級電腦網路,這些網路能夠快速地在 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 的自適應封包分散如何幾乎消除核心擁塞;以及 iii)我們的部署如何使用靜態源路由來繞過故障並消除一整類路由失敗。總之,這些優勢使我們能夠更快地為所有人提供更好的模型。
在訓練大型 AI 模型時,單一步驟可能涉及數百萬次數據傳輸。任何一次傳輸的延遲都可能影響整個任務,導致 GPU 空閒。網路擁塞、連結和設備故障是傳輸延遲和抖動最常見的來源。
隨著叢集規模的增加,這些問題變得更加頻繁且難以解決。這使得網路技術成為 Stargate 設計的關鍵部分。
為了實現 Stargate 超級電腦目前的規模,我們面臨兩項關鍵的網路挑戰。首先,在可能的情況下,我們應盡量減少網路擁塞的可能性。存在不可避免的瓶頸,例如兩個 GPU 同時發送數據到同一個目的地。但在這些情況之外,我們應透過設計來避免擁塞。
其次,我們需要盡量減少網路故障對訓練任務本身的影響。在足夠大的規模下,即使是最好的網路也會持續發生連結和交換機故障。先前,單一故障經常會導致訓練任務崩潰,迫使從檢查點重新啟動,或在網路重新計算路由時暫停數秒。這種中斷在 GPU 週期和時間上都成本高昂。對於同步預訓練——許多 GPU 在多台電腦上協同工作以訓練單一 AI 模型——這尤其如此。我們執行的任務越大,任何單一連結的波動或故障的影響就越大。這些工作負載會形成一種「故障放大器」,因此防止這種情況變得至關重要。
我們的目標不僅是建置一個快速的網路,還要建置一個即使在發生故障時也能提供非常可預測效能的網路,以保持訓練任務的進行。
為了實現這種可靠性,我們的擴展團隊在過去兩年中與 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作,開發了一種建置和操作我們網路的新方法。這項努力的成果是我們稱之為 Multipath Reliable Connection(MRC)的技術。這是一種內建於最新的 800Gb/s 網路介面中的新網路協定,它使我們能夠將單一傳輸分散到數百條路徑上,在微秒內繞過故障,並運行更簡單的網路控制平面。
MRC 擴展了 RoCE(RDMA over Converged Ethernet)——InfiniBand Trade Association(IBTA)的一項標準,該標準能夠實現 GPU 和 CPU 之間硬體加速的遠端直接記憶體存取。它借鑒了 Ultra Ethernet Consortium(UEC)開發的技術,並透過基於 SRv6 的源路由進行擴展,以支援大規模 AI 網路架構。
MRC 已部署於 OpenAI 所有用於訓練前沿模型的最大型 NVIDIA GB200 超級電腦中,包括我們在德州阿比林的 Oracle Cloud Infrastructure(OCI)網站以及 Microsoft 的 Fairwater 超級電腦。MRC 已用於訓練多個 OpenAI 模型,利用了 NVIDIA 和 Broadcom 的硬體。今天,MRC 規格已作為開放運算計畫(OCP)的貢獻提供給社群使用和建構。我們共同撰寫了一篇詳細介紹我們經驗的論文,「使用 MRC 和 SRv6 的彈性 AI 超級電腦網路」。
建置高度彈性的網路需要我們從一個具有足夠自然冗餘的網路拓撲開始,這樣即使網路中的連結或交換機發生故障,所有流量也能獲得良好的效能。
我們沒有將每個網路介面視為一個 800Gb/s 的連結,而是將其分割成多個較小的連結。例如,一個介面可以連接到八個不同的交換機。然後,您可以建置八個獨立的平行網路,或稱為平面,每個平面以 100Gb/s 的速度運行,而不是一個單一的 800Gb/s 網路。
這個改變對叢集的形狀有很大的影響。一個能夠以 800Gb/s 連接 64 個埠的交換機,現在可以連接 512 個埠,每個埠以 100Gb/s 的速度運行。這使得您能夠僅用兩層交換機就建置一個完全連接約 131,000 個 GPU 的網路。傳統的 800Gb/s 網路需要三到四層。
MRC 對多平面網路的支持意味著我們僅用兩層交換機就能連接超過十萬個 GPU。與傳統方法相比,這減少了所需的電力、可能發生故障的組件數量以及網路的總成本。
結果是一個成本更低、功耗更低、路徑多樣性比傳統網路設計更高的網路。它還允許更多流量保留在第 0 層交換機本地,從而提高效能。
然而,所有這些路徑多樣性可能難以充分利用。傳統用於 AI 訓練的網路協定通常要求每次傳輸遵循單一路徑,以便封包按順序到達。在大型多平面網路中,這會產生兩個問題:不同的流量會在同一連結上發生衝突並產生擁塞,而每次傳輸只能使用一個可用平面。如果我們不改變其他任何東西,多平面網路將導致嚴重的擁塞和整體效能不佳。
在單一路徑流量的情況下,就像在經典的 RoCE 部署中一樣,個別連結經常會發生擁塞。由於集體通訊對最壞情況延遲很敏感,這對 AI 訓練工作負載尤其具有破壞性。
封包流量衝突導致擁塞。由 Mark Handley 製作的動畫。
MRC 從根本上改變了這種模式。MRC 不再將傳輸分配給單一路徑,而是將單一傳輸的封包分散到我們網路中的數百條路徑上,遍及所有不同的平面。封包可能會亂序到達,但所有 MRC 封包都包含其最終記憶體地址,因此目的地可以在封包到達時將其傳輸到記憶體。
MRC 將流量分散到多條路徑上,減少了可能減慢同步 AI 訓練的擁塞。
透過將流量分散到多條路徑上,MRC 避免了網路中的熱點,防止某些交易花費的時間遠遠長於其他交易。這可以防止影響同步 AI 訓練的減速。
透過多條路徑分散封包。由 Mark Handley 製作的動畫。
每個 MRC 連接都會保留其使用的多條路徑的一小部分狀態。如果它偵測到某條路徑正在變得擁塞,它會將該路徑替換為另一條路徑,從而平衡網路負載。如果它丟失了一個封包,它會採取安全措施:假設該路徑上的某個東西可能已損壞,並立即停止使用它,重新傳輸任何可能已丟失的封包。在 MRC 停用一條路徑後,它會發送探測封包以檢查是否真的發生了故障,以及是否已恢復。
然而,故障並非封包丟失的唯一原因;另一個常見的丟失來源是目的地端的擁塞。MRC 透過封包修剪來處理這個問題。如果交換機因擁塞而丟棄封包,它會修剪掉負載,只將標頭轉發到目的地,觸發明確的重傳請求。封包修剪減少了我們錯誤地假設丟失意味著路徑已損壞的誤報。
這種多平面拓撲、分散、負載平衡和修剪的組合意味著 MRC 連接可以在微秒級別的時間尺度上偵測網路故障並繞過它們,從而最大限度地減少對同步訓練任務的影響。相比之下,傳統的網路架構可能需要數秒甚至數十秒才能穩定並繞過故障。
MRC 讓我們能夠進一步簡化我們的網路。
傳統上,交換機運行動態路由協定,如 BGP(邊界網關協定),來計算可用路徑並繞過故障。但交換機是運行複雜軟體的複雜設備。當它們以微妙的方式發生故障時,這些問題可能難以診斷,並可能導致連接失敗,直到修復為止。
有了 MRC,動態路由變得不那麼必要。如果某條路徑上的封包丟失,MRC 就會停止使用該路徑。我們採取了更激進的方法,禁用了動態路由,而是使用 IPv6 區段路由(SRv6)。SRv6 允許發送者直接指定每個封包通過網路的路徑。它透過將交換機識別符序列嵌入到每個封包的目的地地址來實現這一點。
SRv6 允許發送者將每個封包到達網路的完整路徑編碼。由於這是確定性的,發送者可以獨立地對給定路徑上的擁塞或丟失做出反應。
分解來看:在轉發時,交換機會檢查其自身的識別符是否存在。如果存在,它會移除該識別符,方法是移動目的地地址,以便下一個交換機的識別符被揭示。然後,交換機會在靜態路由表中查找此識別符,該表決定下一個封包的發送位置。與動態路由不同,此靜態路由表在交換機首次配置時就已配置,並且此後永不更改。
MRC 使用 SRv6 將封包分散到所有網路平面,以及每個平面上的多條路徑。如果某條路徑發生故障,MRC 只需停止使用它。交換機不需要重新計算路由,也不需要做任何事情,只需盲目遵循它們配置的靜態路由。
我們的訓練網路有數百萬個連結。雖然這些網路品質很高,但在足夠大的規模下,一些連結波動是不可避免的。在訓練期間,我們觀察到第 0 層和第 1 層交換機之間每分鐘發生多次連結波動的情況,但 MRC 確保了它們對我們的同步預訓練任務沒有可測量的影響。事實上,它們的影響足夠小,以至於我們甚至不需要優先處理這些連結的立即修復。
不僅連結會發生故障。在最近為 ChatGPT 和 Codex 訓練前沿模型期間,我們不得不重新啟動四個第 1 層交換機。先前,重新啟動交換機需要營運團隊非常小心,以免中斷訓練。有了 MRC,我們甚至不需要與叢集中運行訓練任務的團隊協調。許多連結的修復也是如此。以前,當需要進行維護工作時,我們會與營運團隊協調禁用連結。現在,我們可以在連結仍在服務時進行修復。如果連結工作良好,MRC 會使用它。如果不行,MRC 會避開它,直到修復為止。
訓練運行期間捕獲的真實數據顯示 MRC 對 T1 交換機的完全丟失做出反應。訓練任務經歷了暫時的減速,但很快恢復。
在 MRC 之前,如果 GPU 的網路介面和第 0 層交換機之間的連結發生故障,訓練任務就會失敗。有了 MRC,任務得以倖存,效能也尚可。如果一個 8 埠網路介面丟失了一個埠,最大速率將減少八分之一。MRC 會偵測到這一點,重新計算路徑以避開故障平面,並立即告知對等節點不要將該平面用於入站流量。大多數故障連結會在幾分鐘內恢復,屆時 MRC 會將該平面重新投入使用。
由丟失 GPU 介面連結引起的減速因訓練任務而異,但實際上往往遠小於物理容量損失的程度。
MRC 最終在擴展我們的超級電腦方面為我們帶來了三個關鍵優勢。
首先,它使我們能夠使用僅兩層乙太網路交換機來建置擁有超過 10 萬個 GPU 的超級電腦的多平面高速網路。這提供了足夠的冗餘來應對網路故障,同時比同等的श्三層或四層單平面網路消耗更少的電力。
其次,MRC 的自適應封包分散負載平衡效果極佳,以至於我們在網路核心幾乎看不到擁塞。這大大減少了同步訓練期間流量之間的吞吐量差異,而消除異常值是效能的關鍵。這也意味著當多個任務共享叢集時,它們不會相互影響效能。
最後,MRC 使用 SRv6 源路由來快速繞過故障,並僅將封包透過正常工作的路徑發送。這使我們能夠運行一個簡單的靜態網路控制平面,並消除一整類動態路由故障行為。
MRC 顯著提高了我們訓練新前沿模型的能力,並確保我們的網路能夠跟上研究人員雄心勃勃的 AI 路線圖。它比以前的方法有了顯著的改進,並有助於加速我們將 AGI 的好處可靠地帶給每個人的目標。我們為促成這一點的跨產業合作感到自豪。
隨著訓練叢集的持續增長,網路設計越來越決定了實際可用的運算能力有多少。MRC 幫助我們在先前會中斷訓練的擁塞、連結故障和維護事件中,讓 GPU 能夠協同工作。在有意義的規模上,這種可靠性和效率不是錦上添花;它是同步前沿模型訓練得以實現的基礎之一。
跨產業合作對於解決 AI 的許多難題將繼續至關重要。我們感謝與 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 的合作,共同開發 MRC,並感謝 Microsoft Azure、OCI、NVIDIA 和 Arista 的合作,將其大規模部署。我們都致力於推動生態系的發展,並對該行業未來將 MRC 帶向何方感到興奮。