簡介這份PDF是阿里云資深網(wǎng)絡(luò)架構(gòu)師席永青在AICon北京2024上的演講材料系統(tǒng)梳理了AI大規(guī)模訓(xùn)練場景下數(shù)據(jù)中心網(wǎng)絡(luò)從CPU中心向GPU中心演進(jìn)的必然趨勢并重點(diǎn)解析HPN 7.0架構(gòu)如何滿足GPU集群對帶寬、時延、可擴(kuò)展性的嚴(yán)苛要求。內(nèi)容覆蓋GPU集群網(wǎng)絡(luò)關(guān)鍵訴求、HPN 7.0的多軌雙平面拓?fù)渑c51.2T交換芯片應(yīng)用、端網(wǎng)融合與自研HPCC流控、SONiC開源生態(tài)帶來的白盒化運(yùn)維等同時探討了網(wǎng)絡(luò)性能從Best-effort走向可預(yù)期、從SDN到計算定義網(wǎng)絡(luò)的演進(jìn)路徑并展望了未來AI Infra在液冷、1.6T端口等方向的發(fā)展。適合數(shù)據(jù)中心網(wǎng)絡(luò)工程師、AI基礎(chǔ)設(shè)施架構(gòu)師及大模型訓(xùn)練平臺開發(fā)者參考可幫助理解萬卡級GPU集群的網(wǎng)絡(luò)設(shè)計邏輯與關(guān)鍵技術(shù)取舍。資源為單個PDF文件大小5.76MB目前已有101人學(xué)習(xí)下載便于快速獲取這場頂會級架構(gòu)分享的核心技術(shù)要點(diǎn)。 最近在幫團(tuán)隊(duì)調(diào)一個大模型分布式訓(xùn)練的性能發(fā)現(xiàn)一個特別扎心的事實(shí)當(dāng)我們把GPU從128塊加到1024塊理論算力翻了8倍但訓(xùn)練吞吐只漲了不到4倍。排查到最后瓶頸不在GPU算力也不在顯存而是卡在節(jié)點(diǎn)間的網(wǎng)絡(luò)上。分布式訓(xùn)練里的梯度同步、參數(shù)交換、并行策略拆分全都依賴網(wǎng)絡(luò)互聯(lián)完成。也正是這個背景讓我對阿里云的《網(wǎng)絡(luò)驅(qū)動大規(guī)模 AI 訓(xùn)練 - 阿里云可預(yù)期網(wǎng)絡(luò) HPN 7.0 架構(gòu)》這份文檔特別感興趣。這份架構(gòu)文檔講的是一個很核心的問題傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡(luò)是“盡力而為”的模型偶發(fā)擁塞和丟包在普通業(yè)務(wù)里可以忍但放在大規(guī)模AI訓(xùn)練里就是致命的——一次重傳就可能讓上千塊GPU同時空轉(zhuǎn)。HPN 7.0想做的事情是把網(wǎng)絡(luò)做成“可預(yù)期”的基礎(chǔ)設(shè)施讓時延、帶寬、丟包行為都變得穩(wěn)定可控。如果你在關(guān)心超大規(guī)模AI訓(xùn)練為什么需要網(wǎng)絡(luò)驅(qū)動或者正在規(guī)劃智算集群、做網(wǎng)絡(luò)選型和調(diào)優(yōu)這文章值得仔細(xì)讀一遍。我也會結(jié)合平時調(diào)參和排查性能問題時的實(shí)際經(jīng)驗(yàn)把里面偏工程化的概念講得更直白一些。1. 可預(yù)期網(wǎng)絡(luò)是什么以及為什么AI訓(xùn)練離不開它1.1 當(dāng)算力集群變大網(wǎng)絡(luò)就變成了“隱形天花板”先從一個最基本的觀察說起。單機(jī)8卡的訓(xùn)練GPU之間通過NVLink/NVSwitch互聯(lián)帶寬能做到900GB/s級別延遲微秒級幾乎感覺不到通信瓶頸。但大模型訓(xùn)練幾乎不可能停留在單機(jī)8卡千億參數(shù)模型光參數(shù)就要幾百GB單卡顯存根本放不下所以要把模型切到幾十甚至上百個節(jié)點(diǎn)上用張量并行、流水線并行、數(shù)據(jù)并行、序列并行這些方式協(xié)同訓(xùn)練?？绻?jié)點(diǎn)的通信依賴什么以太網(wǎng)。每步迭代里數(shù)據(jù)并行要做梯度AllReduce張量并行要做AllToAll和AllGatherMoE模型的專家路由更是全集群范圍的消息洪流。這些通信不是“某個瞬間來一下”而是每一步訓(xùn)練都來一遍。假如網(wǎng)絡(luò)延遲從50微秒抖動到500微秒或者某條鏈路出現(xiàn)一次丟包訓(xùn)練框架就要等通信完成才能進(jìn)入下一步整個集群的GPU都在原地等待。這也是“網(wǎng)絡(luò)驅(qū)動”這四個字的由來網(wǎng)絡(luò)性能直接決定你能把算力利用率推到多高。網(wǎng)絡(luò)層面節(jié)省10%的通信時間可能就是每天多跑若干訓(xùn)練步折算成GPU資源費(fèi)用是極其可觀的數(shù)字。所以把網(wǎng)絡(luò)看作和GPU同樣重要的資源一點(diǎn)也不夸張。1.2 “可預(yù)期”三個字到底承諾了什么我理解的可預(yù)期網(wǎng)絡(luò)核心不是“帶寬大”而是“表現(xiàn)穩(wěn)定”。它通常包含幾個層面時延可預(yù)期無論網(wǎng)絡(luò)負(fù)載怎么變化關(guān)鍵路徑的延遲不會劇烈抖動。帶寬可預(yù)期每條流能拿到的帶寬是可計算的而不是靠哈希碰撞碰運(yùn)氣。丟包可預(yù)期無損或接近無損避免重傳導(dǎo)致的尾部延遲放大。普通互聯(lián)網(wǎng)應(yīng)用網(wǎng)頁、視頻、消息對這類要求不敏感偶爾來一次重傳用戶感知不到。但AI訓(xùn)練是典型的“同步后備”模型集群里最快的卡也要等最慢的那張算完網(wǎng)絡(luò)里任何一條慢流都可能導(dǎo)致整輪迭代變慢。這就是所謂的“長尾效應(yīng)”?？深A(yù)期網(wǎng)絡(luò)本質(zhì)上就是在跟長尾延遲作斗爭?？梢宰鰝€粗糙的類比傳統(tǒng)網(wǎng)絡(luò)像高峰期自駕通暢還是堵車全看運(yùn)氣可預(yù)期網(wǎng)絡(luò)更像地鐵運(yùn)行圖雖然秒級延遲未必最低但你知道它什么時候到班次穩(wěn)定。對AI訓(xùn)練這種依賴嚴(yán)格時序的應(yīng)用來說這種確定性價值極大。2. 核心細(xì)節(jié)解析負(fù)載均衡、擁塞控制和拓?fù)湟粋€都不能少2.1 負(fù)載均衡從“五元組哈?！钡礁?xì)的調(diào)度傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡(luò)做負(fù)載均衡主要靠ECMP把一條流按照五元組哈希到不同鏈路上。問題在于AI訓(xùn)練里的流量往往是幾十GB級別的“大象流”幾個大流一旦哈希到同一條鏈路立刻產(chǎn)生擁塞而其他鏈路可能還在空跑。HPN 7.0這類架構(gòu)的改進(jìn)思路是打破“一條流必須固定走一條路徑”的限制在包級別做更細(xì)粒度的調(diào)度。技術(shù)上可以是動態(tài)路由、包噴灑也可以用集中式控制器計算出更優(yōu)路徑。這樣做的難點(diǎn)在于亂序如果同一個流的不同包走了不同路徑到達(dá)順序就變了接收端必須要有足夠的重排序能力否則RDMA的性能優(yōu)勢會被直接抵消。我在實(shí)際測試中見過太多次因?yàn)楣２痪鶎?dǎo)致實(shí)際帶寬只有理論值一半的情況。所以看一個網(wǎng)絡(luò)架構(gòu)能不能支撐大規(guī)模AI訓(xùn)練先別急著看端口速率要重點(diǎn)看它的負(fù)載均衡是否做到了足夠細(xì)的粒度以及亂序處理是否成熟。這個點(diǎn)能解釋為什么很多聽起來“帶寬很高”的組網(wǎng)方案真正跑起NCCL來表現(xiàn)平平。2.2 擁塞控制無損網(wǎng)絡(luò)的關(guān)鍵命門AI訓(xùn)練流量有一個非常明顯的特征叫Incast也就是“多對一”。比如64張卡的梯度要同步到同一個目標(biāo)節(jié)點(diǎn)一瞬間所有源端同時灌流量目標(biāo)端交換機(jī)隊(duì)列立刻爆炸。傳統(tǒng)TCP面對Incast只能丟包、重傳、超時這在AI訓(xùn)練場景下屬于災(zāi)難。RDMA之所以能在AI集群里流行靠的是網(wǎng)絡(luò)無損不丟包、不重傳。但是無損網(wǎng)絡(luò)又依賴PFC優(yōu)先級流控這種逐跳反壓機(jī)制PFC本身有副作用比如可能引發(fā)隊(duì)頭阻塞甚至死鎖需要精細(xì)化調(diào)優(yōu)。阿里云在擁塞控制上一直走的是端網(wǎng)協(xié)同路線思路簡單說就是不再完全依賴交換機(jī)端的大緩存硬扛而是讓發(fā)送端更精準(zhǔn)地感知網(wǎng)絡(luò)擁塞狀況動態(tài)調(diào)整發(fā)送速率做到“在網(wǎng)絡(luò)真正擁堵之前就降速”。這種做法比單純依賴PFC更可控也比傳統(tǒng)TCP的“撞墻之后才退讓”更主動。我讀HPN 7.0文檔時這部分印象很深因?yàn)樗选翱深A(yù)期”從口號落到了算法層面。2.3 拓?fù)渑c無收斂設(shè)計物理基礎(chǔ)決定性能上限網(wǎng)絡(luò)架構(gòu)能做出多少文章很大程度上看底層拓?fù)洹鹘y(tǒng)數(shù)據(jù)中心三層架構(gòu)核心層、匯聚層、接入層為了控制成本會設(shè)置收斂比比如接入到匯聚收斂比1:4就意味著底層有4Gbps的流量擠到上層1Gbps的鏈路。普通業(yè)務(wù)可以靠“大部分時間流量不大”來稀釋問題但AI訓(xùn)練是所有端口時刻拉滿收斂比就是硬傷。一旦收斂帶寬可預(yù)期性直接歸零。所以面向AI訓(xùn)練的集群基本上都會采用無收斂的Clos/胖樹拓?fù)洳⒈M可能壓低網(wǎng)絡(luò)直徑。節(jié)點(diǎn)之間的跳數(shù)越少延遲越可控?fù)砣c(diǎn)也越少。配合高密度交換芯片和光互聯(lián)才能支撐萬卡級別的并行訓(xùn)練。HPN 7.0在拓?fù)渖系乃悸繁举|(zhì)上是在用物理層的確定性換取上層調(diào)度的簡單性。2.4 集合通信優(yōu)化網(wǎng)絡(luò)驅(qū)動訓(xùn)練的具體抓手可預(yù)期網(wǎng)絡(luò)最終要作用到具體訓(xùn)練模式上而AI訓(xùn)練里最典型的通信模式就是集合通信。AllReduce數(shù)據(jù)并行訓(xùn)練中每張卡先本地計算梯度再把所有卡上的梯度累加并分發(fā)回去。AllToAllMoE模型的Expert分發(fā)、序列并行中數(shù)據(jù)需要跨節(jié)點(diǎn)重排。AllGather張量并行中匯總切片張量。不同的通信模式對網(wǎng)絡(luò)的需求不一樣。AllReduce對帶寬和延遲都敏感AllToAll屬于流量模式非常均勻但總量巨大的通信對負(fù)載均衡要求更高。HPN 7.0這類架構(gòu)在設(shè)計時會針對這些模式做專門優(yōu)化比如調(diào)整隊(duì)列調(diào)度策略或者在控制器層面識別集合通信語義給不同模式分配不同的資源策略。這也是為什么說“網(wǎng)絡(luò)驅(qū)動”不只是底層硬件的活而是從芯片、交換機(jī)、協(xié)議到調(diào)度器的一整套協(xié)同。3. 實(shí)操視角從紙面架構(gòu)到真實(shí)訓(xùn)練的踩坑記錄3.1 怎么判斷你的瓶頸在GPU還是在網(wǎng)絡(luò)很多朋友上來就問“為什么我的分布式訓(xùn)練GPU利用率只有30%”。我的建議是不要猜直接做對照測試。第一步先用NCCL的all_reduce_perf工具跑一遍純通信測試把消息大小從128K一直測到幾百M(fèi)B記錄每個檔位的總線帶寬。第二步把這個數(shù)值和網(wǎng)卡規(guī)格、交換機(jī)端口速率做對比正常情況下應(yīng)該能跑到理論帶寬的80%以上。如果差距大網(wǎng)絡(luò)配置大概率有問題。第三步回到真實(shí)訓(xùn)練用nvidia-smi記錄GPU利用率曲線同時看訓(xùn)練日志里的時間統(tǒng)計。如果GPU利用率的低谷與通信階段高度重合說明計算和通信沒有重疊好要么改并行策略要么壓縮通信量。這種做法適用于自建集群也適用于云上大規(guī)模訓(xùn)練任務(wù)。我自己用這套方法排查過好幾個“集群性能上不去”的case基本上一個測一個準(zhǔn)比一群人圍著服務(wù)器瞎猜高效得多。3.2 估算一次同步要多少帶寬一個粗糙但有用的模型以數(shù)據(jù)并行的梯度同步為例參數(shù)規(guī)模為P混合精度下梯度用bf16保存那么一次AllReduce同步的數(shù)據(jù)量約等于2×P。因?yàn)镽ing AllReduce的通信量近似與卡數(shù)無關(guān)所以這個估算對不同規(guī)模集群都適用。假設(shè)P10B單次通信量約20GB。如果網(wǎng)絡(luò)單流能跑到200Gbps25GB/s理論上完成一次全量梯度同步至少需要0.8秒如果單流帶寬只有100Gbps就變成1.6秒。這只是純通信時間。實(shí)際訓(xùn)練中每步計算時間也就幾秒通信如果沒法與計算重疊那訓(xùn)練速度就會被這一下一下的同步直接拖住。這也是為什么我反復(fù)強(qiáng)調(diào)規(guī)劃集群時不要只看GPU型號一定要先根據(jù)你的模型大小和并行策略倒推需要的網(wǎng)絡(luò)帶寬和拓?fù)洹０涯Ｐ蛥?shù)、梯度精度、并行維度、單步計算時間代入這個粗略模型能很快判斷當(dāng)前組網(wǎng)方案到底夠不夠用。3.3 網(wǎng)絡(luò)可觀測性建設(shè)把問題扼殺在發(fā)生前我踩過最大的坑是網(wǎng)絡(luò)問題發(fā)生之后很難定位。AI訓(xùn)練的流量是瞬息萬變的等訓(xùn)練結(jié)束再去看監(jiān)控往往已經(jīng)找不到當(dāng)時的真實(shí)情況。所以建議在集群建設(shè)初期就要把網(wǎng)絡(luò)觀測做全。至少要看四類指標(biāo)網(wǎng)卡側(cè)發(fā)送/接收速率、丟包計數(shù)、重傳計數(shù)、暫停幀計數(shù)PFC觸發(fā)的次數(shù)。交換機(jī)側(cè)端口利用率、隊(duì)列深度、丟棄包計數(shù)、流采樣數(shù)據(jù)。訓(xùn)練側(cè)NCCL的timeline、各階段耗時占比。應(yīng)用側(cè)GPU利用率、迭代時間、端到端吞吐。其中暫停幀計數(shù)特別值得關(guān)注。如果PFC頻繁觸發(fā)說明流量已經(jīng)接近網(wǎng)絡(luò)極限或者擁塞控制參數(shù)不對這會直接拉低整體吞吐。把這些指標(biāo)配置好告警閾值訓(xùn)練出問題的時候就能快速判斷是網(wǎng)絡(luò)問題、并行策略問題還是代碼問題而不是一群人圍在機(jī)房干瞪眼。4. 常見問題與排查技巧實(shí)錄4.1 訓(xùn)練時NCCL報超時怎么排查NCCL超時算是最常見的故障了。我的排查順序基本固定先看日志是發(fā)生在初始化階段還是訓(xùn)練中段。初始化階段超時大概率是節(jié)點(diǎn)之間的路由不通或者防火墻規(guī)則沒放行直接ping和測試TCP端口就能定位。訓(xùn)練中段超時先看網(wǎng)卡是不是出現(xiàn)了大量丟包再看交換機(jī)的隊(duì)列深度和暫停幀計數(shù)如果這兩個指標(biāo)異常優(yōu)先懷疑擁塞控制參數(shù)和流調(diào)度。很多時候重啟能臨時解決但一定要找到根因否則過一陣還會復(fù)發(fā)。4.2 鏈路明明是400G跑起來卻只有200G這類問題的排查優(yōu)先級最高的是負(fù)載均衡是否生效。傳統(tǒng)ECMP按五元組哈希兩個大流撞到同一條鏈路太常見了。排查方法是登錄交換機(jī)看每條鏈路的流量分布如果某條鏈路利用率特別高而其他鏈路很低基本可以斷定是哈希不均。解決方案要么升級支持動態(tài)負(fù)載均衡的設(shè)備要么在組網(wǎng)時盡量讓每個大流單獨(dú)占用可用鏈路同時配合集群調(diào)度讓通信對盡量物理隔離。還有一個容易忽略的點(diǎn)確認(rèn)網(wǎng)卡的RDMA模式、MTU、PFC優(yōu)先級配置在鏈路兩端完全一致。這些細(xì)節(jié)不一致會導(dǎo)致降速協(xié)商實(shí)際帶寬直接砍半。4.3 給準(zhǔn)備自建小規(guī)模訓(xùn)練集群的幾條實(shí)在建議如果你只是幾十卡規(guī)模不一定需要復(fù)刻萬卡級的完整架構(gòu)但思路可以借鑒第一網(wǎng)絡(luò)不要省錢。交換機(jī)緩存、光模塊、網(wǎng)卡的預(yù)算寧可多花不要省因?yàn)楹笃谥刭I和排障的成本更高。第二務(wù)必選擇支持無損網(wǎng)絡(luò)和高質(zhì)量擁塞控制的設(shè)備這一點(diǎn)比端口速率更關(guān)鍵。第三動手之前先畫清楚通信拓?fù)鋱D把所有并行模式下的流量走向列一遍確保沒有明顯的單點(diǎn)瓶頸。第四有條件就先把NCCL通信測試跑透達(dá)到理論帶寬的70%以上再開始正式訓(xùn)練配置。最后說點(diǎn)個人體會。我拿到HPN 7.0這份文檔的時候最強(qiáng)烈的感受是它把“網(wǎng)絡(luò)”從配角變成了真正的主角。以前大家優(yōu)化訓(xùn)練性能想到的是模型結(jié)構(gòu)、并行度、顯存大小但網(wǎng)絡(luò)層的確定性往往被忽略。而事實(shí)上當(dāng)集群規(guī)模上千以后恰恰是網(wǎng)絡(luò)決定了你能不能把那么多昂貴的GPU真正用起來。如果你也正在被分布式訓(xùn)練性能問題困擾不妨先靜下心統(tǒng)計幾項(xiàng)網(wǎng)絡(luò)指標(biāo)再決定是否升級架構(gòu)。很多看似玄學(xué)的性能問題最后都會落到一條鏈路上。本文還有配套的精品資源點(diǎn)擊獲取