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