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

公眾號(hào)記得加星標(biāo)??，第一時(shí)間看推送不會(huì)錯(cuò)過(guò)。

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

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

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

為什么網(wǎng)絡(luò)需要新的設(shè)計(jì)

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

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

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

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

我們的答案：MRC

我們的目標(biāo)不僅是構(gòu)建一個(gè)快速的網(wǎng)絡(luò)，而且還要構(gòu)建一個(gè)即使在出現(xiàn)故障的情況下也能提供非常可預(yù)測(cè)的性能的網(wǎng)絡(luò)，以保持訓(xùn)練任務(wù)的進(jìn)行。

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

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

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

基礎(chǔ)：多層網(wǎng)絡(luò)

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

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

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

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

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

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

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

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

故障并非丟包的唯一原因；另一個(gè)常見(jiàn)的丟包原因是目的地?fù)砣RC 通過(guò)數(shù)據(jù)包修剪來(lái)解決這個(gè)問(wèn)題。如果交換機(jī)因擁塞而丟棄數(shù)據(jù)包，它會(huì)修剪掉有效載荷，只將數(shù)據(jù)包頭部轉(zhuǎn)發(fā)到目的地，從而觸發(fā)顯式重傳請(qǐng)求。數(shù)據(jù)包修剪可以減少誤報(bào)，避免我們錯(cuò)誤地認(rèn)為丟包意味著路徑故障。

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

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

MRC 使我們能夠進(jìn)一步簡(jiǎn)化網(wǎng)絡(luò)。

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

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

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

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

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

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

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

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

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

因 GPU 接口連接丟失而導(dǎo)致的運(yùn)行速度下降，在不同的訓(xùn)練任務(wù)中有所不同，但在實(shí)踐中，這種下降往往遠(yuǎn)小于物理容量的損失。

主要改進(jìn)

MRC最終為我們擴(kuò)展超級(jí)計(jì)算機(jī)帶來(lái)了三個(gè)關(guān)鍵優(yōu)勢(shì)。

首先，它允許我們僅使用兩層以太網(wǎng)交換機(jī)，為擁有超過(guò) 10 萬(wàn)個(gè) GPU 的超級(jí)計(jì)算機(jī)構(gòu)建多層高速網(wǎng)絡(luò)。這為我們提供了足夠的冗余來(lái)應(yīng)對(duì)網(wǎng)絡(luò)故障，同時(shí)比同等的三層或四層單層網(wǎng)絡(luò)消耗更少的電力。

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

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

打開(kāi)協(xié)議

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

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

（來(lái)源：openAI）

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

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

加星標(biāo)??第一時(shí)間看推送

求推薦