為了連接更多XPU，芯片巨頭罕見聯(lián)手

公眾號記得加星標??，第一時間看推送不會錯過。

Frontier 模型訓練依賴于可靠的超級計算機網(wǎng)絡，該網(wǎng)絡能夠快速地在 GPU 之間傳輸數(shù)據(jù)。為了提高速度和效率，OpenAI 與 AMD、博通、英特爾、微軟和英偉達合作開發(fā)了 MRC（多路徑可靠連接）：一種新型協(xié)議，可提升大型訓練集群中 GPU 網(wǎng)絡的性能和穩(wěn)定性。我們今天發(fā)布了 MRC（Multi-path Reliable Connections），通過開放計算項目（OCP）使更廣泛的行業(yè)能夠使用它。

每周有超過 9 億人使用 ChatGPT，我們的系統(tǒng)正成為人工智能的核心基礎設施，幫助世界各地的人們和企業(yè)構建功能日益強大的模型。在Stargate項目啟動之前，我們與合作伙伴密切合作，歷經(jīng)數(shù)年精心開發(fā)、部署和維護了前三代超級計算機。這段寶貴的經(jīng)驗讓我們堅信，為了高效利用 Stargate 規(guī)模的計算資源并成功完成使命，我們需要重新思考并大幅降低堆棧每一層的復雜性——包括網(wǎng)絡設計。

發(fā)布 MRC 規(guī)范是 OpenAI 整體計算戰(zhàn)略的一部分：關鍵基礎設施層的共享標準有助于更高效、更可靠地擴展 AI 系統(tǒng)，并覆蓋更廣泛的合作伙伴生態(tài)系統(tǒng)。本文將介紹 MRC 的設計，包括：i) 它如何幫助我們構建多平面高速網(wǎng)絡，從而創(chuàng)建冗余以應對網(wǎng)絡故障，同時減少組件數(shù)量和功耗；ii) MRC 的自適應數(shù)據(jù)包噴射技術如何幾乎消除核心網(wǎng)絡擁塞；以及 iii) 我們的部署如何利用靜態(tài)源路由來繞過故障并消除整類路由故障。這些優(yōu)勢共同作用，使我們能夠更快地為所有人提供更優(yōu)質的模型。

為什么網(wǎng)絡需要新的設計

在訓練大型人工智能模型時，單個步驟可能涉及數(shù)百萬次數(shù)據(jù)傳輸。一次傳輸延遲可能會影響整個訓練任務，甚至導致GPU閑置。網(wǎng)絡擁塞、鏈路故障和設備故障是造成數(shù)據(jù)傳輸延遲和抖動的最常見原因。

隨著集群規(guī)模的增大，這些問題會變得更加頻繁，也更難解決。因此，網(wǎng)絡技術成為星際之門設計中的關鍵組成部分。

為了實現(xiàn)星際之門超級計算機目前的規(guī)模，我們面臨著兩大關鍵的網(wǎng)絡挑戰(zhàn)。首先，我們應該盡可能減少網(wǎng)絡擁塞的可能性。當然，也存在一些不可避免的瓶頸，例如兩塊GPU同時向同一目的地發(fā)送數(shù)據(jù)。但除此之外，我們應該通過設計來避免擁塞。

其次，我們需要盡可能降低網(wǎng)絡故障對訓練任務本身的影響。在足夠大的規(guī)模下，即使是最好的網(wǎng)絡也會持續(xù)存在鏈路和交換機故障。以前，單個故障往往會導致訓練任務崩潰，迫使從保存的檢查點重新啟動，或者在網(wǎng)絡重新計算路徑期間停滯數(shù)秒。此類中斷會消耗大量的 GPU 周期和時間。對于同步預訓練（即多臺計算機上的多個 GPU 協(xié)同工作以同步方式訓練同一個 AI 模型）而言，這一點尤為突出。我們運行的任務規(guī)模越大，任何單個鏈路抖動或故障的影響就越大。這些工作負載就像一個“故障放大器”，因此防止這種情況發(fā)生至關重要。

我們的答案：MRC

我們的目標不僅是構建一個快速的網(wǎng)絡，而且還要構建一個即使在出現(xiàn)故障的情況下也能提供非?？深A測的性能的網(wǎng)絡，以保持訓練任務的進行。

為了實現(xiàn)這種可靠性，過去兩年，我們的擴展團隊與AMD、博通、英特爾、微軟以及英偉達合作，致力于開發(fā)一種構建和運營網(wǎng)絡的新方法。這項努力的成果是一種我們稱之為多路徑可靠連接（Multipath Reliable Connection，簡稱MRC ）的技術. 這是一種內置于最新 800Gb/s 網(wǎng)絡接口中的新型網(wǎng)絡協(xié)議，它允許我們將單個傳輸分散到數(shù)百條路徑上，在微秒內繞過故障，并運行更簡單的網(wǎng)絡控制平面。

MRC擴展了基于融合以太網(wǎng)的RDMA（RoCE）——一項InfiniBand貿(mào)易協(xié)會（IBTA）標準，該標準支持GPU和CPU之間硬件加速的遠程直接內存訪問。它借鑒了超以太網(wǎng)聯(lián)盟（UEC）開發(fā)的技術，并利用基于SRv6的源路由對其進行了擴展，以支持大規(guī)模AI網(wǎng)絡架構。

MRC 已部署在我們用于訓練前沿模型的所有 OpenAI 大型 NVIDIA GB200 超級計算機上，包括位于德克薩斯州阿比林的 Oracle 云基礎設施 (OCI) 站點以及微軟的 Fairwater 超級計算機。MRC 已用于訓練多個 OpenAI 模型，并利用了 NVIDIA 和 Broadcom 的硬件。如今，MRC 規(guī)范已作為開放計算項目 (OCP) 的貢獻提供給社區(qū)使用和開發(fā)。

基礎：多層網(wǎng)絡

構建高彈性網(wǎng)絡需要我們從具有足夠自然冗余性的網(wǎng)絡拓撲結構開始，這樣即使網(wǎng)絡中的鏈路或交換機發(fā)生故障，所有數(shù)據(jù)流也能獲得良好的性能。

我們不再將每個網(wǎng)絡接口視為一條 800Gb/s 的鏈路，而是將其拆分成多條較小的鏈路。例如，一個接口可以連接到八個不同的交換機。這樣，您就可以構建八個獨立的并行網(wǎng)絡（或稱平面），每個網(wǎng)絡運行速度為 100Gb/s，而不是構建一個單一的 800Gb/s 網(wǎng)絡。

這一改變對集群的結構影響巨大。一臺原本能以 800Gb/s 速率連接 64 個端口的交換機，現(xiàn)在可以以 100Gb/s 速率連接 512 個端口。這樣一來，只需兩層交換機，就能構建一個完全連接約 131,000 個 GPU 的網(wǎng)絡。而傳統(tǒng)的 800Gb/s 網(wǎng)絡則需要三到四層交換機。

最終得到的網(wǎng)絡成本更低、功耗更低，并且與傳統(tǒng)網(wǎng)絡設計相比，路徑多樣性更高。此外，它還允許更多流量在 Tier 0 交換機附近傳輸，從而提升網(wǎng)絡性能。

然而，所有這些路徑多樣性都難以充分利用。用于人工智能訓練的傳統(tǒng)網(wǎng)絡協(xié)議通常要求每次傳輸都遵循單一路徑，以確保數(shù)據(jù)包按順序到達。在大型多平面網(wǎng)絡中，這會產(chǎn)生兩個問題：不同的數(shù)據(jù)流可能在同一鏈路上發(fā)生沖突并造成擁塞，而且每個數(shù)據(jù)流只能使用一個可用平面。如果我們不做任何其他改變，多平面網(wǎng)絡將導致嚴重的擁塞和整體性能下降。

MRC 的轉變：在數(shù)百條路徑上Spraying packets

MRC 從根本上改變了這種模型。MRC 不再將傳輸分配給一條路徑，而是將來自單個傳輸?shù)臄?shù)據(jù)包分散到網(wǎng)絡中數(shù)百條路徑上，覆蓋所有不同的平面。數(shù)據(jù)包可能亂序到達，但所有 MRC 數(shù)據(jù)包都包含其最終內存地址，因此目標地址可以在數(shù)據(jù)包到達時將其送入內存。

每個 MRC 連接都會為其使用的眾多路徑維護少量狀態(tài)信息。如果檢測到某條路徑擁塞，它會將其替換為另一條路徑，從而平衡整個網(wǎng)絡的負載。如果丟包，它會采取安全措施：假定該路徑上的某些環(huán)節(jié)可能發(fā)生了故障，并立即停止使用該路徑，同時重新發(fā)送所有可能丟失的數(shù)據(jù)包。MRC 棄用某條路徑后，會發(fā)送探測數(shù)據(jù)包來檢查是否真的發(fā)生了故障，如果確實發(fā)生了故障，則檢查該路徑是否已恢復。

故障并非丟包的唯一原因；另一個常見的丟包原因是目的地擁塞。MRC 通過數(shù)據(jù)包修剪來解決這個問題。如果交換機因擁塞而丟棄數(shù)據(jù)包，它會修剪掉有效載荷，只將數(shù)據(jù)包頭部轉發(fā)到目的地，從而觸發(fā)顯式重傳請求。數(shù)據(jù)包修剪可以減少誤報，避免我們錯誤地認為丟包意味著路徑故障。

這種多平面拓撲、spraying、負載均衡和修剪等技術的結合，使得 MRC 連接能夠在微秒級的時間尺度上檢測到網(wǎng)絡故障并繞過故障路由，從而最大限度地減少對同步訓練作業(yè)的影響。相比之下，傳統(tǒng)的網(wǎng)絡架構可能需要數(shù)秒甚至數(shù)十秒才能穩(wěn)定下來并繞過故障路由。

用源路由替換動態(tài)路由

MRC 使我們能夠進一步簡化網(wǎng)絡。

傳統(tǒng)上，交換機運行動態(tài)路由協(xié)議，例如邊界網(wǎng)關協(xié)議 (BGP)，來計算可用路徑并繞過故障。但交換機是運行復雜軟件的復雜設備。當它們出現(xiàn)不易察覺的故障時，這些問題可能難以診斷，并且在修復之前會導致連接中斷。

有了 MRC，動態(tài)路由的必要性就降低了。如果數(shù)據(jù)包在某個路徑上丟失，MRC 會停止使用該路徑。我們采取了更為徹底的方法，禁用動態(tài)路由，轉而使用 IPv6 分段路由（SRv6）。SRv6 允許發(fā)送方直接指定每個數(shù)據(jù)包在網(wǎng)絡中的傳輸路徑。它通過將交換機標識符序列嵌入到每個數(shù)據(jù)包的目標地址中來實現(xiàn)這一點。

SRv6 允許發(fā)送方對每個數(shù)據(jù)包到達網(wǎng)絡的完整路徑進行編碼。由于路徑是確定性的，發(fā)送方可以獨立地應對特定路徑上的擁塞或丟包情況。

具體來說：轉發(fā)數(shù)據(jù)包時，交換機會檢查自身標識符是否存在。如果存在，它會通過移動目標地址來移除該標識符，從而顯示下一個交換機的標識符。然后，交換機會在靜態(tài)路由表中查找該標識符，以確定數(shù)據(jù)包的下一個轉發(fā)目標。與動態(tài)路由不同，靜態(tài)路由表在交換機首次配置時就已配置好，之后無需更改。

MRC 使用 SRv6 將數(shù)據(jù)包散布到所有網(wǎng)絡平面，以及每個平面上的多條路徑。如果某條路徑發(fā)生故障，MRC 會停止使用該路徑。交換機無需重新計算路由，只需盲目地遵循已配置的靜態(tài)路由即可。

這在生產(chǎn)中看起來是這樣的

我們的訓練網(wǎng)絡擁有數(shù)百萬條鏈路。雖然這些網(wǎng)絡質量很高，但在足夠大的規(guī)模下，鏈路抖動在所難免。在訓練過程中，我們觀察到零層交換機和一級交換機之間每分鐘都會發(fā)生多次鏈路抖動，但 MRC 確保這些抖動對我們的同步預訓練任務沒有造成任何可衡量的影響。事實上，它們的影響非常小，以至于我們甚至不需要優(yōu)先修復這些鏈路。

不僅僅是鏈路會發(fā)生故障。在最近一次針對 ChatGPT 和 Codex 的前沿模型訓練過程中，我們不得不重啟四臺一級交換機。以前，重啟交換機需要運維團隊非常小心，以免中斷訓練。而有了 MRC，我們甚至無需與集群中運行訓練任務的團隊協(xié)調。鏈路修復也是如此。過去，我們需要與運維團隊協(xié)調，在需要進行維護工作時禁用鏈路。現(xiàn)在，我們可以在鏈路仍在運行的情況下進行修復。如果鏈路運行良好，MRC 會使用它。如果鏈路運行不佳，MRC 會避免使用它，直到鏈路修復為止。

在 MRC 出現(xiàn)之前，如果 GPU 網(wǎng)絡接口與 0 層交換機之間的鏈路發(fā)生故障，訓練任務就會失敗。而有了 MRC，任務可以繼續(xù)運行并保持合理的性能。如果一個 8 端口網(wǎng)絡接口丟失一個端口，最大速率會降低八分之一。MRC 會檢測到這種情況，重新計算路徑以避開故障鏈路，并立即通知對等節(jié)點不要使用該鏈路傳輸入站流量。大多數(shù)故障鏈路會在一分鐘內恢復，此時 MRC 會重新啟用該鏈路。

因 GPU 接口連接丟失而導致的運行速度下降，在不同的訓練任務中有所不同，但在實踐中，這種下降往往遠小于物理容量的損失。

主要改進

MRC最終為我們擴展超級計算機帶來了三個關鍵優(yōu)勢。

首先，它允許我們僅使用兩層以太網(wǎng)交換機，為擁有超過 10 萬個 GPU 的超級計算機構建多層高速網(wǎng)絡。這為我們提供了足夠的冗余來應對網(wǎng)絡故障，同時比同等的三層或四層單層網(wǎng)絡消耗更少的電力。

其次，MRC的自適應數(shù)據(jù)包噴射機制實現(xiàn)了良好的負載均衡，使得網(wǎng)絡核心幾乎沒有擁塞現(xiàn)象。這大大降低了同步訓練期間不同數(shù)據(jù)流之間的吞吐量波動，而消除異常值對于提升性能至關重要。這也意味著，當多個作業(yè)共享集群時，它們不會相互影響性能。

最后，MRC 使用 SRv6 源路由快速繞過故障，僅通過正常工作的路徑發(fā)送數(shù)據(jù)包。這使我們能夠運行一個簡單的靜態(tài)網(wǎng)絡控制平面，并消除所有類型的動態(tài)路由故障行為。

打開協(xié)議

MRC顯著提升了我們訓練前沿模型的能力，并確保我們的網(wǎng)絡能夠跟上研究人員雄心勃勃的人工智能路線圖。它相比以往的方法有了顯著改進，并有助于我們加速實現(xiàn)讓所有人都能可靠地享受到通用人工智能（AGI）帶來的益處的目標。我們?yōu)榇俪蛇@一成果的跨行業(yè)合作感到自豪。

隨著訓練集群規(guī)模的不斷擴大，網(wǎng)絡設計越來越?jīng)Q定著可用計算資源的實際利用率。MRC 幫助我們在網(wǎng)絡擁塞、鏈路故障和維護事件等以往會中斷訓練的情況下，保持 GPU 的協(xié)同運行。在實際規(guī)模下，這種可靠性和效率并非錦上添花，而是同步前沿模型訓練得以實現(xiàn)的關鍵所在。

（來源：openAI）

*免責聲明：本文由作者原創(chuàng)。文章內容系作者個人觀點，半導體行業(yè)觀察轉載僅為了傳達一種不同的觀點，不代表半導體行業(yè)觀察對該觀點贊同或支持，如果有任何異議，歡迎聯(lián)系半導體行業(yè)觀察。

今天是《半導體行業(yè)觀察》為您分享的第4399內容，歡迎關注。

加星標??第一時間看推送

求推薦