
演講嘉賓 | 席永青
AI 訓練場景的算力 Scaling 核心是網路,依賴於大規模、高效能的資料中心網路叢集來實現算力的規模擴充套件,為此,阿里雲設計了 HPN7.0 架構系統,基於 Ethernet 來構建超大規模、極致效能的網路互聯。
本文整理自阿里巴巴資深網路架構師席永青在 AICon 2024 北京《大模型基礎設施構建》專題的演講“網路驅動大規模 AI 訓練 – 阿里雲可預期網路 HPN 7.0 架構”,內容經 InfoQ 進行不改變原意的編輯。
大家好,我是席永青,來自阿里雲。阿里雲的 PAI 靈駿想必大家都熟悉,已經是 AI 領域的標杆算力平臺,服務了眾多知名的 AI 大模型公司。我有幸負責靈駿智算叢集網路架構設計。今天非常高興有機會在 AICon 這個優秀的平臺上與大家交流,希望能夠與各位進行深入的探討。
我在阿里雲工作已經有近十年的時間,專注於資料中心網路架構和高效能系統的設計。從 2021 年開始,我專注於 AI 智算領域,負責智算叢集網路的規劃演進。在大模型還未如此火熱之前,阿里雲就開始設計 AI 計算的萬卡叢集。回顧整個過程,智算最初在自動駕駛領域應用較多,許多自動駕駛客戶希望透過 AI GPU 叢集進行視覺模型訓練,在 2021 年阿里雲就非常有遠見地構建了第一代萬卡叢集,當時我們稱為 HPN 6.0。
這幾年來,從網路到 GPU、機器、整個 IDC,再到平臺系統和上層 AI 模型框架,AI 基礎設施領域的發展速度非常快。我有兩點明顯的感受:第一,隨著 GPT 的爆發,我們幾乎每天都需要更新知識庫,雖然網路是底層技術,但也需要密切關注模型發展和框架變化帶來的對網路使用上的變化,也包括 GPU 硬體更新迭代對網路互聯和頻寬的影響等。第二,叢集規模的迅速變化,從一開始的千卡 GPU 到現在萬卡十萬卡規模,如果沒有前瞻性的技術儲備和規劃,基礎設施將面臨巨大的挑戰。
我今天要分享的內容主要分為四個部分,首先我會介紹高效能網路系統的發展歷程以及它目前所處的階段。接著,我會探討在構建大規模 GPU 叢集,比如萬卡甚至十萬卡叢集時,對於網路來講最關鍵的要素是什麼。接下來,我將重點介紹阿里雲 HPN 7.0 架構,它是阿里雲 PAI 靈駿智算叢集的核心網路技術。最後,我將展望以 GPU 為中心的基礎設施及其高效能網路系統的未來發展趨勢。
在座的可能有些是網路領域的專家,有些可能是更上層的系統、AI 平臺或演算法的專家,還有一些可能是 GPU 領域的專家,希望在今天的分享中,我能回答大家三個問題。第一個問題是網路對於 AI 計算意味著什麼,網路在整個 AI 計算系統中扮演的角色以及它的重要性。第二個問題,如果你的公司正在做 AI 模型相關工作,無論是在構建大模型平臺還是自行研發大模型,基礎設施網路的方向應該如何選擇。第三個問題是,一旦確定了網路方向,網路方案和一些關鍵技術點應該如何實施。
讓我們回顧一下網路的整個發展歷程。在 2000 年左右,網際網路剛剛興起時,網路主要是由裝置供應商提供的基礎設施,用於支撐 IT 業務系統。那時,資料中心開始起步,電商業務如淘寶,搜尋業務如百度、Google 等開始規模化使用資料,產生對資料中心大規模計算的需求。那時,資料中心內部主要使用 TCP 協議,那時的 TCP 能夠滿足算力連線服務的需求,隨著摩爾定律的持續推進,CPU 不斷升級,TCP 的能力也隨之提升,網路並沒有成為瓶頸。
隨著雲計算和大資料的興起,網路進入了第二個發展階段。在這個階段,因為叢集規模的擴大,網路的規模和穩定性要求以及頻寬需求都在增加。這時,網路進入了軟體定義網路(SDN)的時代,這是許多網路專業人士都熟悉的一個時代,誕生了許多新技術,也湧現了許多網路領域的創業公司。
隨著雲計算資料中心的進一步擴大,AI 智算時代逐漸到來。智算叢集與傳統雲計算資料中心有很大的不同,它對網路的要求也截然不同。這也是我接下來要分享的重點,希望帶大家瞭解為什麼在 AI 資料中心中,網路如此重要,網路在其中扮演了多麼關鍵的角色。我們目前正處於第三個階段,這個階段的網路技術架構的發展將決定 AI 計算規模化發展的趨勢,這是接下來討論的重點。
在討論叢集算力中網路所扮演的角色之前,我們首先需要明確 AI 基礎設施的關鍵要求。對於 AI 基礎設施來說,一個至關重要的要求是訓練時間。訓練時間對於業務創新至關重要,因為它直接關係到公司是否能高質量得到 AI 模型,是否能快速將產品推向市場,同時這個過程中訓練時間所帶來的創新迭代效應也將更加明顯。
訓練時間的關鍵因素包括模型的時間加上中斷時間。其中模型訓練的時間,與整體計算量有關,在模型、資料集確定的情況下,這是一個固定值,這個算力需求的總量,除以叢集的算力,就是模型訓練的時間。此外,還需要考慮中斷時間,這可能包括模型調整、資料調整或因為故障導致的訓練暫停從而從上一個 checkpoint 恢復。
叢集算力與通訊效率密切相關。組成 AI 訓練叢集的千卡、萬卡 GPU 是一個整體,所有人在協同完成同一個計算的任務。我們往往透過增加 GPU 的規模來增加叢集的總算力,比如從 1000 張 GPU 增加到 2000 張、4000 張,整個叢集所表現出的算力是否還能保持“單 GPU 乘以 GPU 數量”的算力,這是我們通常所說的線性比。這個線性比怎麼做到最優,核心是透過高效能的網路系統來實現的。如果網路出現問題,哪怕是影響到一塊 GPU 的網路問題,都會導致整個叢集的任務變慢或者停下來。因此,網路在“叢集算力”中扮演著至關重要的角色,它不僅關係到算力的線性擴充套件,還直接影響到訓練任務的穩定性和效率。

AI 計算中的通訊模型與傳統計算有著顯著的不同。AI 計算過程是迭代,包括計算、通訊、同步,然後再回到計算。以模型訓練過程為例,首先將模型所需的資料載入到 GPU 上,然後 GPU 進行前向計算、反向計算,在反向計算完成後,關鍵的一步是同步模型收斂的梯度引數到每一個 GPU。這樣,在下一輪的資料訓練開始時,所有的 GPU 都能夠從最新的模型引數開始迭代,這樣將整個引數收斂到我們期望的結果。
在這個過程中,網路要做的核心工作對梯度進行全域性同步。在每一輪的迭代計算中,都需要將梯度資料同步。而圖中藍色部分所表示的,正是網路所承擔的工作。網路負責在各個 GPU 之間傳輸和同步這些梯度資料,確保每個 GPU 都能夠接收到最新的模型引數,從而進行有效的平行計算。

網路在 AI 計算中的重要性體現在它對算力規模擴充套件的影響上。當算力規模擴大時,如果網路的線性比下降,實際體現出來的算力也會隨之下降。如果我們將 GPU 的數量從 128 張增加到 1024 張、4096 張,再到 1 萬張,理想情況下,只要擴充套件 GPU 規模,就能獲得相應的算力提升。但實際情況往往並非如此。網路在梯度同步過程中需要時間,這個時間的長短直接影響到 GPU 在計算過程中的等待時間,尤其隨著規模的擴充套件,梯度同步所需要的網路交換資料量也會變大,網路通訊的時間也會變長,相當於損失了 GPU 算力。好的網路架構設計,高效能的網路系統,可以做到隨著規模的增加仍然保持較好的線性比,充分發揮大規模 GPU 的算力,網路效能即規模化的算力。
在 AI 計算中,GPU 叢集對網路有著更高的效能要求,希望網路在算力擴充套件過程中能夠保持高效的通訊。這引出了一個問題:GPU 叢集對網路提出了哪些關鍵要求?
首先,我們可以得出一個結論,即傳統的網路叢集已不再適用於 AI 計算。過去 20 年左右,資料中心的核心算力主要來自 CPU。如果我們觀察 CPU 系統和網路系統的組成,可以發現幾個特點:CPU 系統通常是單張網絡卡的,從 CPU 透過 PCIe 到網絡卡出口,內部沒有特殊的網路互聯。CPU 系統的單機頻寬最大到 200G 就已經足夠,因為它們主要服務於 APP/Web 型別的應用,這些應用需要進行網際網路訪問和資料中心內機器的協同工作,處理各種流量。
GPU 網路的情況已經發生了很大變化。每個 GPU 都有自己的內部互聯,例如 NVIDIA 的 A100 或 H800,它們內部的 NVLink 互聯可以達到 600GB 甚至 900GB。這種內部互聯與外部乙太網網路叢集設計之間存在耦合關係。GPU 是單機多網絡卡的,單機內的多張網絡卡之間有高速互聯,單個伺服器的頻寬可以達到 3.2T,與通用 CPU 計算頻寬相比至少有 6 到 8 倍的關係。GPU 需要使用 GPU Direct RDMA 來實現視訊記憶體之間的資料遷移,並且需要超短的 RTT(往返時延)。
因此,在 AI 場景下,傳統的資料中心叢集設計很難發揮其作用。GPU 叢集需要網路能夠支援更高的頻寬、更低的延遲和更高效的通訊機制,以滿足 AI 計算的需求。

在傳統的資料中心叢集中,任務模式通常包括計算、儲存以及客戶端 / 伺服器服務。這些服務之間需要建立大量的會話連線來交換資料,而這些連線的數量通常取決於使用者量和負載等因素。因此,這些連線的數量很高,流量趨勢會隨著業務負載的變化而變化。例如,在淘寶上,網路流量的高低峰與交易高峰密切相關。
而在 AI 計算中,特別是在模型訓練過程中,網路表現出的是週期性的行為。計算、通訊和同步迴圈是連續不斷的過程。例如,一個 400G 的網絡卡在每一輪計算迭代的通訊部分可以在瞬間將網路頻寬用滿。
網路的任務是儘可能縮短計算的等待時間,這樣,GPU 就可以更充分地發揮其 Tensor Core 的能力來進行計算任務,而不是浪費在等待資料同步上。所以在 AI 模型訓練任務中,尤其是在大型 AI 模型的訓練中,網路表現出的特點是高併發和高突發流量。

在討論網路連線數量的特點時,我們可以看到通用計算和 AI 訓練叢集之間存在顯著差異。在通用計算中,採用的通常是客戶端 / 伺服器模式,連線數量與使用者的請求量和業務模型的設計緊密相關,可能會非常大。例如,一臺伺服器上可能有高達 10 萬級別的 HTTP 連線。
在 AI 訓練叢集中,一個網絡卡上的連線數量卻非常固定,通常只有百級別連線。從訓練任務開始的那一刻起,每一輪對網路的操作都是相同的。在每個迴圈中,活躍的連線數量以及所需的連線數量都非常少。連線數量少在網路上可能會引起 HASH 問題,這是我在後續討論 HPN 7.0 設計時會重點提到的一個關鍵問題。HASH 問題是目前網路領域在 AI 計算中需要解決的核心問題之一。簡單來說,連線越多,熵就越大,在選路徑時分散均衡的機率也更大。而當連線數量減少時,HASH 問題就會變得更加明顯。
當我們深入探討 AI 網路系統時,如果從端到端的角度審視 AI 系統的網路構成,我們可以發現在 AI 訓練過程中,有三個非常關鍵的元件。
-
叢集架構設計:叢集架構雖然看起來只是一張拓撲圖,但實際上它決定了物理頻寬的使用和路徑的簡化程度。這個架構直接影響到模型訓練過程中的網路 HASH、時延和頻寬。就像城市規劃中的道路規劃一樣,只有設計得當,交通(在這裡比喻為資料包)才能高效執行。
-
端到端傳輸協議:它決定了資料包在網路中的傳輸效率。就好像交通網路的效率,需要每輛車都足夠安全足夠快,同時也要避免交通擁堵的發生。傳輸協議需要考慮傳輸效率、重傳、流控等因素以確保高效傳輸。
-
監控運維和資源管理系統:雖然在今天的分享中不會詳細討論,但這個系統非常關鍵。整個系統依賴於監控運維的能力進行快速的問題發現,效能分析,和問題解決。

在 AI 計算網路設計中,如果我們將前述的三個部分進一步拆解,會發現在 AI 訓練過程中,網路有四個關鍵點。
-
叢集架構設計:合理的叢集架構設計是重中之重。這個設計決定了頻寬和規模能達到的程度,比如是連線千卡、萬卡還是 10 萬卡,頻寬是 3.2T、6.4T 還是更大,網路層級是一層、兩層還是三層,以及計算和儲存的佈局等。這些因素都會影響 AI 訓練中迭代時間或每秒樣本數。
-
點到點傳輸協議:在叢集設計的基礎上,點到點之間需要使用最快的協議來實現梯度傳輸。這要求協議能夠實現直接記憶體訪問(DMA),減少複製操作,實現大頻寬和低延遲。目前,無論是 RoCEv2 還是 IB,DMA 技術已經實現了這些能力,協議棧已經寫入硬體,實現了零複製操作。
-
incast 問題:在訓練通訊過程中,會出多對 1 的資料互動場景,這會導致尾跳網路出口成為瓶頸。如果沒有有效的流控方法,這會在網路出口形成佇列堆積,導致緩衝區溢位發生丟包,嚴重影響通訊效率。流控的目標是保持緩衝區的能力足夠不會溢位,同時確保流量頻寬始終 100% 輸出。
-
網路 HASH 問題:由於 AI 計算流量波動大,頻寬高,瞬間可以打滿一個 400G 埠,但流的數量又非常少,這使得網路路徑上的 HASH 不均勻的機率很大,這導致中間路徑的不均衡,產生丟包、長尾,影響整體通訊效率。
在 AI 訓練中,長尾問題是非常明顯的,它具有木桶效應。如果在一個迭代中有 1000 張卡,其中 999 張已經傳輸完畢,但有 1 張卡的梯度傳輸慢了,那麼整個訓練過程都要等待這張卡。因此,無論是 HASH 還是流控,目標都是補齊木桶的短板,充分利用頻寬的同時降低長尾,確保整個網路能夠實現高頻寬、低時延和高利用率的統一狀態。

在審視了 GPU 叢集對網路的關鍵要求之後,讓我們來探討阿里雲的 HPN 7.0 架構是如何解決這些問題的,以及它是如何提高模型訓練的效率,達到更極致的效能。
阿里雲從去年年初開始設計研發 HPN7.0,在去年 9 月份上線規模化,是專為 AI 設計的高效能計算叢集架構。這個架構的特點是單層千卡、兩層萬卡,存算分離。

-
千卡 Segment 設計:我們實現了一個設計,允許 1000 張 GPU 卡透過單層網路交換完成互聯。在單層網路交換中,由於是點到點連線,因此不存在 HASH 問題。在這樣一個千卡範圍內,網路可以發揮出極致的效能,測試結果表明,這種設計下的計算效率是業界最優的。
-
兩層網路實現萬卡規模:透過兩層網路結構,我們能夠支援多達十幾個千卡 segment,從而實現萬卡規模的網路互動。兩層網路不僅減少了時延,還簡化了網路連線的數量和拓撲。在三層網路結構中,端到端的網路路徑數量是乘數關係,而兩層網路只有兩跳,簡化了路徑選擇,提高了雜湊效果。
-
存算分離。計算流量具有明顯的規律性,表現為週期性的波動,我們的目標是縮短每個波峰的持續時間,而儲存流量是間歇性的資料寫入和讀取。為了避免儲存流量對計算引數同步流量的干擾,我們在設計中將計算和儲存流量分配在兩個獨立的網路中執行。在最近的 GTC 大會上,有關網路設計是採用一張網還是兩張網的問題進行了深入探討。北美幾家主要公司的 AI 基礎設施網路負責人都參與了討論,並得出了一致的結論,即分開兩張網是最佳選擇,這與我們的設計原則相符合。
值得一提的是,HPN 7.0 架構,在兩週前被選為國際網路頂會 SIGCOMM 的論文。SIGCOMM 是網路領域內最頂級的會議之一,每年僅收錄大約 50 篇論文,這些論文都是由網路領域的全球頂尖專家的創新和實踐成果。阿里雲的 HPN 7.0 架構論文被選中,這具有重大意義。在 SIGCOMM 上發表關於網路架構設計的論文是相當罕見的。上一篇與網路架構相關的論文是 Google 的 Jupiter 網路,第一代 Jupiter 網路在 2015 年釋出,第二代則是在 2022 年發表。而 HPN 7.0 的釋出標誌著 AI 領域內第一篇網路架構的國際頂會論文的誕生,會成為 AI 領域網架構設計的標杆。

在 HPN7.0 架構下,我們可以透過流量排布,來最佳化模型訓練過程。從 GPU 的視角來看,在整個網路對映過程中,我們可以看到在 1 千卡的範圍內,DP 過程可以在千卡範圍內完成,無任何網路 HASH 導致的問題。PP 流量較少,可以讓其跨越不同的 segment 進行傳輸。這樣的設計使得頻寬的利用率能夠與模型訓練過程緊密結合,從而實現更優的效能。

HPN 7.0 在端到端的模型訓練效能上取得了顯著提升,測試資料顯示效能,模型端到端的效能提升超過 10%。除了軟體架構的最佳化,HPN 7.0 的硬體和光互聯絡統也是其成功的關鍵因素。我們採用了基於阿里雲自研的 51.2T 交換機,和 400G 光互聯。
展望未來,高效能網路系統的發展將指向一些明確的方向,這些方向已經隨著 AI 基礎設施的變革而逐漸顯現。從最近 GTC 的釋出中,我們可以感知到這一變革的脈動。變革將涵蓋從資料中心的電力設計、製冷設計,到網路互聯的 scale out 和 scale up 設計等多個方面。
從物理層面來看,未來的資料中心將面臨更高的功率密度。例如,以前一個機架(Rack)可能只有 20 千瓦的功率,但未來的機架可能達到 50 千瓦甚至 100 千瓦。這樣的高功率密度將帶來散熱方面的挑戰,因此,液冷技術將成為必須採用的解決方案,包括交換機在內的裝置都將採用液冷技術。
GPU 之間的內部互聯,如 NVLink 也將在機架內部甚至更大範圍內進行擴充套件,以支援 scale up 的擴充套件需求。這種 scale up 的擴充套件需要與網路的 scale out 擴充套件緊密結合,以確保整個系統的高效性和可擴充套件性,這也是業界最熱門的互聯創新話題。

面向未來,我們面臨的規模挑戰將更大。隨著 scale up 網路的發展,我們可能會看到從當前的 8 卡配置擴充套件到 72 卡或更多,這樣的擴充套件會對網路拓撲帶來變化,從而影響 scale out 群網路架構的設計。包括通訊框架、容災設計,以及電力和物理佈局等方面都將發生顯著變化。這些變化指向了一個以 GPU-centric 的資料中心設計理念。

此外,網路技術的發展正朝著更高的單晶片交換能力邁進,未來一年內,我們有望看到阿里雲的 HPN 8.0,它將是基於 100T 晶片的下一代架構。從 SCALE up 與 SCALE out 結合的架構設計、硬體設計,到液冷系統、IDC 設計的結合,端到端的 AI 基礎設施發生變化,以網路設計為中心的 GPU-centric 基礎設施時代已經到來。
高效能網路協議也將針對 AI 計算持續演進。為了推動這一程序,業界已經成立了超級乙太網聯盟(UEC),近期阿里巴巴入選該聯盟決策委員會,是決策委員會中唯一的一家中國公司,接下來阿里雲將在 AI 基礎設施網路的高效能方向上重點投入,與各主要公司一起,共同致力於下一代更高效能網路系統的設計和開發。

ArchSummit深圳開幕倒計時6天,6 月 14 日 -15 日,一起探索大模型時代的軟體架構最佳正規化。如您感興趣,可點選「閱讀原文」檢視更多詳情。購買票數越多,享受的優惠也就越豐厚,可以聯絡票務經理 17310043226 , 鎖定最新優惠,期待與你的現場交流~

你也「在看」嗎?👇