如果你跑過(guò)多機(jī)多卡訓(xùn)練多半被NCCL默認(rèn)的Ring LL算法“慣壞”過(guò)——小消息延遲低代碼零改動(dòng)性能看起來(lái)也夠用。但當(dāng)我真正把訓(xùn)練規(guī)模推大到需要跨PCIe Switch和跨NUMA節(jié)點(diǎn)做AllReduce時(shí)Ring LL的弱點(diǎn)一下暴露了聚合帶寬卡在一個(gè)尷尬的區(qū)間上不去而NCCL自帶的Tree算法又沒(méi)法覆蓋所有消息尺寸。這篇文章記錄了我從NCCL Ring LL出發(fā)逐步拆解通信瓶頸最終落地一個(gè)基于PCIe IPC的AllReduce實(shí)現(xiàn)的完整過(guò)程包括算法選型、CUDA IPC句柄分發(fā)、流水線同步、實(shí)測(cè)數(shù)據(jù)和一路踩過(guò)的PCIe硬件穩(wěn)定性坑。內(nèi)容面向正在調(diào)多機(jī)多卡通信性能的工程師也適合想要理解NCCL、PCIe拓?fù)?、IPC底層機(jī)制的研究者。1. 基準(zhǔn)測(cè)試先撕開(kāi)口子Ring LL 并非 AllReduce 的萬(wàn)能解1.1 測(cè)試環(huán)境與方法兩臺(tái) 8 卡 A100 的具體配置先交代環(huán)境這套數(shù)據(jù)我后來(lái)復(fù)現(xiàn)了很多次結(jié)論是穩(wěn)定的。節(jié)點(diǎn)是兩臺(tái)配置完全相同的8卡A100 80GB服務(wù)器單機(jī)內(nèi)部8卡通過(guò)NVLink全互聯(lián)NVSwitch帶寬跑滿(mǎn)沒(méi)有問(wèn)題跨節(jié)點(diǎn)網(wǎng)卡是兩張ConnectX-6 IB卡分別掛在兩個(gè)PCIe Switch下面單卡P2P走PCIe 4.0 x16。NCCL版本用的2.18.3CUDA版本12.2驅(qū)動(dòng)版本535.104?；鶞?zhǔn)測(cè)試直接用nccl-tests里現(xiàn)成的all_reduce_perf消息大小從8字節(jié)一路掃到64MB測(cè)了busbw總線帶寬和延遲。我特意沒(méi)有改任何NCCL環(huán)境變量就想看看默認(rèn)配置在最常見(jiàn)場(chǎng)景下到底是什么水平。每個(gè)消息尺寸跑滿(mǎn)200輪取中位數(shù)避免冷啟動(dòng)和波動(dòng)干擾。說(shuō)實(shí)話第一輪結(jié)果出來(lái)我并沒(méi)有覺(jué)得太意外。8字節(jié)到64KB這個(gè)區(qū)間Ring LL的延遲表現(xiàn)確實(shí)漂亮多機(jī)跨IB的時(shí)延能從幾十微秒壓到十幾微秒。真正讓我皺眉的是1MB到16MB這個(gè)區(qū)間busbw只有理論峰值帶寬的60%到75%而且波動(dòng)明顯多跑幾輪有時(shí)候還能掉到一半以下。這個(gè)區(qū)間恰恰是大模型梯度同步最常見(jiàn)的消息大小——每個(gè)tensor的梯度allreduce合并之后基本就在這個(gè)范圍。1.2 現(xiàn)象與誤判為什么大消息時(shí) Ring LL 的帶寬上不去先用一個(gè)更直白的類(lèi)比說(shuō)明Ring Ring LL的問(wèn)題。環(huán)形AllReduce相當(dāng)于“擊鼓傳花”數(shù)據(jù)按GPU數(shù)量切成N份每個(gè)GPU只負(fù)責(zé)相鄰兩個(gè)GPU之間的收發(fā)一輪結(jié)束后每個(gè)GPU手里都有一片“最終值”的碎片再跑一輪把碎片廣播給所有人。好處是每張卡的帶寬壓力很均勻壞處是每一跳都有固定的協(xié)議開(kāi)銷(xiāo)跳數(shù)越多這個(gè)開(kāi)銷(xiāo)累積得越明顯。Ring LL中的LLLow Latency協(xié)議核心思路是把數(shù)據(jù)和標(biāo)志位打包在一起發(fā)送接收方靠標(biāo)志位判斷數(shù)據(jù)是否有效從而省去額外的同步握手。這個(gè)設(shè)計(jì)對(duì)延遲極其友好但它是拿帶寬換延遲為了讓標(biāo)志位緊跟數(shù)據(jù)每個(gè)小數(shù)據(jù)塊都要附帶額外的flag等于在PCIe總線上多傳一部分“快遞面單”。當(dāng)消息變大、數(shù)據(jù)塊增多這些flag會(huì)占掉可觀的帶寬而且多跳累積的延遲會(huì)直接壓住吞吐。我一開(kāi)始誤判成網(wǎng)絡(luò)卡頓還去查了IB交換機(jī)端口計(jì)數(shù)結(jié)果丟包和重傳都正常。后來(lái)用nsys拉了一輪profile才看明白瓶頸根本不在IB鏈路上而在GPU之間的數(shù)據(jù)搬運(yùn)路徑上Ring的每一跳都要經(jīng)過(guò)SM做一次reduce消息越大SM花在加載/存儲(chǔ)上的時(shí)間越長(zhǎng)流水線一旦沒(méi)法填滿(mǎn)總線帶寬自然掉下來(lái)。1.3 翻源碼找原因LL 協(xié)議的同步機(jī)制在高并發(fā)下的副作用理論分析只能幫我定位方向真正確認(rèn)問(wèn)題還是得翻源碼。NCCL的核心實(shí)現(xiàn)在src/collectives/device/all_reduce.cc而算法調(diào)度在src/algorithm/下面分成了ring.cc和tree.cc協(xié)議層則在src/include/device/下按LL、LL128、Simple分開(kāi)實(shí)現(xiàn)。我看到的關(guān)鍵點(diǎn)在LL協(xié)議的數(shù)據(jù)布局它會(huì)把一段連續(xù)顯存拆成“數(shù)據(jù)flag”交錯(cuò)的塊flag用一個(gè)額外字節(jié)標(biāo)記這個(gè)塊是否被消費(fèi)過(guò)。在GPU kernel里消費(fèi)方和生產(chǎn)者靠這些flag完成點(diǎn)對(duì)點(diǎn)同步。小消息場(chǎng)景flag開(kāi)銷(xiāo)占比低延遲收益大但數(shù)據(jù)量一上來(lái)flag本身就成了額外的PCIe流量更要命的是flag讀寫(xiě)還引入了額外的內(nèi)存屏障導(dǎo)致SM的指令流水線頻繁停頓。這就是為什么NCCL在消息偏大的時(shí)候會(huì)自動(dòng)切到Tree算法——Tree的帶寬模型是2*log(N)相比Ring的2*(N-1)/N在大規(guī)模場(chǎng)景更優(yōu)。但Tree的延遲更高因?yàn)樗繉佣加芯酆系却虚g段消息尺寸下兩頭不討好。這也正是我決定自己動(dòng)手的原因在1MB到64MB這個(gè)區(qū)間我需要一種能利用PCIe拓?fù)浜瓦M(jìn)程間直接共享內(nèi)存的AllReduce而不是讓數(shù)據(jù)在Ring上反復(fù)繞圈。2. 把 PCIe 拓?fù)浜?IPC 講透優(yōu)化才不會(huì)走彎路2.1 一張 topo 圖看懂卡間通路NVLink、PCIe Switch 與 CPU動(dòng)手寫(xiě)代碼之前我花了不少時(shí)間把物理拓?fù)鋸氐赘闱宄?。nvidia-smi topo -m的輸出看起來(lái)是一堆縮寫(xiě)但每個(gè)縮寫(xiě)背后都對(duì)應(yīng)一條真實(shí)的數(shù)據(jù)通路。我自己那臺(tái)機(jī)器的輸出簡(jiǎn)化一下大概長(zhǎng)這樣GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7 NIC0 NIC1 GPU0 X NV8 NV8 NV8 NV8 NV8 NV8 NV8 PIX PXB GPU1 NV8 X NV8 NV8 NV8 NV8 NV8 NV8 PIX PXB ... GPU6 NV8 NV8 NV8 NV8 NV8 X NV8 NV8 PXB PIX GPU7 NV8 NV8 NV8 NV8 NV8 NV8 X NV8 PXB PIX NIC0 PIX PIX PXB PXB PXB PXB PXB PXB X PIX NIC1 PXB PXB PIX PIX PIX PIX PIX PIX PIX X這里NV8表示兩塊GPU走NVLink同一個(gè)NVSwitch域內(nèi)而PIX表示經(jīng)過(guò)一個(gè)PCIe SwitchPXB表示經(jīng)過(guò)多個(gè)PCIe橋再連到CPU的Root Complex。同樣是P2PPIX和PXB的帶寬和延遲差距非常明顯PIX基本能跑滿(mǎn)PCIe 4.0 x16的單向帶寬PXB因?yàn)橐@CPU延遲高出一截帶寬也可能打折。這個(gè)圖的重要性在于不是所有GPU之間都有資格談“P2P直連”?？鏝UMA、跨PCIe域的組合CUDA的cudaDeviceCanAccessPeer會(huì)直接返回false這時(shí)候你就算用了IPC映射數(shù)據(jù)也要從源GPU搬到CPU內(nèi)存再搬到目標(biāo)GPU性能和普通cudaMemcpy沒(méi)什么區(qū)別。所以?xún)?yōu)化AllReduce的第一步是先給參與通信的GPU畫(huà)一張“能直連”的地圖而不是盲目把16張卡全部拉進(jìn)同一個(gè)通信域。2.2 IPC 是跨進(jìn)程的“望遠(yuǎn)鏡”cudaIpcMemHandle 的作用多進(jìn)程訓(xùn)練里有個(gè)經(jīng)典的坑每個(gè)MPI rank進(jìn)程各自調(diào)用cudaMalloc申請(qǐng)顯存得到的是本進(jìn)程地址空間里的指針。另一個(gè)進(jìn)程就算知道這個(gè)指針的值也無(wú)法直接訪問(wèn)——GPU顯存的虛擬地址是進(jìn)程隔離的。這時(shí)候就需要CUDA IPC機(jī)制出場(chǎng)。cudaIpcMemHandle_t本質(zhì)是一份指向某段GPU內(nèi)存的“全局引用”。進(jìn)程A調(diào)用cudaIpcGetMemHandle把申請(qǐng)到的顯存變成句柄通過(guò)MPI廣播給進(jìn)程B進(jìn)程B再調(diào)用cudaIpcOpenMemHandle拿到一個(gè)屬于自己的地址映射。之后進(jìn)程B就可以像操作本地指針一樣讀寫(xiě)進(jìn)程A的那塊顯存——前提是兩者能夠P2P訪問(wèn)。如果P2P不可用cudaIpcOpenMemHandle依然可能成功但后續(xù)cudaMemcpyPeer和kernel訪問(wèn)會(huì)退化成走CPU的路徑性能直線下滑。這也是為什么標(biāo)題里“PCIe IPC”是綁在一起說(shuō)的IPC解決的是“跨進(jìn)程怎么找到對(duì)方的顯存”P(pán)CIe解決的是“找到之后數(shù)據(jù)走哪條路到達(dá)”。兩者配合好才能做到真正意義上的零拷貝跨進(jìn)程通信。我在代碼里用cudaIpcOpenMemHandle映射對(duì)端rank的buffer之后再把指針傳給自定義CUDA kernel做reduce整個(gè)路徑?jīng)]有一次顯式cudaMemcpy。2.3 P2P 不生效時(shí)數(shù)據(jù)會(huì)繞到哪里去還有一個(gè)必須掌握的排查手段是看P2P到底有沒(méi)有生效。cudaDeviceCanAccessPeer(0, dev, peerDev)返回true只能說(shuō)明“硬件路徑理論上支持”不代表驅(qū)動(dòng)一定會(huì)給你最優(yōu)路徑。實(shí)踐里我見(jiàn)過(guò)兩種情況很坑第一種是UVA統(tǒng)一虛擬地址沒(méi)開(kāi)。雖然現(xiàn)代CUDA默認(rèn)開(kāi)但某些容器環(huán)境或老驅(qū)動(dòng)下IPC映射后的指針不在同一個(gè)地址空間里kernel訪問(wèn)會(huì)直接報(bào)錯(cuò)或極端降速。第二種是設(shè)備在/dev/nvidia*下的權(quán)限限制比如容器里只映射了部分設(shè)備cudaIpcOpenMemHandle返回CUDA_ERROR_PEER_ACCESS_UNSUPPORTED。排查P2P實(shí)際路徑最直接的辦法是用nvidia-smi -q -d P2P看每對(duì)GPU之間的P2P狀態(tài)再配合cudaMemcpyPeer做一次帶寬測(cè)試。我自己寫(xiě)了一個(gè)小工具對(duì)每對(duì)GPU跑1MB的peer copy測(cè)完自然知道哪些鏈路適合做IPC直通哪些鏈路要讓算法繞開(kāi)。數(shù)據(jù)說(shuō)話比盯著拓?fù)鋱D猜靠譜得多。3. PCIe IPC AllReduce 落地算法、句柄分發(fā)與流水線3.1 算法骨架本地 Reduce 跨進(jìn)程 Scatter/Gather具體設(shè)計(jì)時(shí)我沒(méi)有傻到把16張卡全部拉進(jìn)一個(gè)巨大的環(huán)——那樣等于把Ring LL的問(wèn)題用另一種形式重新犯一遍。我的做法是分兩層第一層單機(jī)內(nèi)部走“局部Reduce”。同一臺(tái)機(jī)器上的8張GPU通過(guò)NVLink先各自計(jì)算本地?cái)?shù)據(jù)的局部和把8份結(jié)果歸并成1份“單機(jī)全局值”。這一步通信量小、延遲低用NCCL自己的Ring LL跑都很快沒(méi)必要自己寫(xiě)。第二層跨進(jìn)程/跨節(jié)點(diǎn)用IPC直通。兩臺(tái)機(jī)器各有自己的“單機(jī)全局值”現(xiàn)在要做的是把這2份或多份值在兩臺(tái)機(jī)器之間同步。我把參與通信的rank兩兩配對(duì)每對(duì)rank通過(guò)IPC映射對(duì)方的buffer然后讓CUDA kernel同時(shí)讀自己和對(duì)方的地址做一次按元素相加再把結(jié)果寫(xiě)回雙方。整個(gè)過(guò)程等價(jià)于一個(gè)最小化的AllReduce樹(shù)但每一層都走PCIe P2P路徑不用SM繞圈也不用網(wǎng)絡(luò)協(xié)議棧。對(duì)于兩機(jī)八卡這個(gè)算法只需要一輪配對(duì)通信就結(jié)束數(shù)據(jù)從“單機(jī)值”變成“全局值”。擴(kuò)展到四機(jī)時(shí)先兩兩配對(duì)reduce一次再在兩組之間reduce一次就是一棵深度為log2(P)的樹(shù)。樹(shù)的每一跳都是IPC直通跳數(shù)比Ring少得多這是它在中等消息尺寸能勝過(guò)Ring LL的根本原因。3.2 句柄分發(fā)與 P2P 使能的代碼細(xì)節(jié)IPC句柄分發(fā)的代碼并不復(fù)雜但細(xì)節(jié)很多。核心流程是每個(gè)rank先把自己要共享的那塊顯存轉(zhuǎn)成cudaIpcMemHandle_t用MPI_Allgather把句柄廣播出去之后每個(gè)rank遍歷收到的句柄調(diào)用cudaIpcOpenMemHandle打開(kāi)“別人的顯存”。// 偽代碼示意 cudaIpcMemHandle_t myHandle; cudaIpcGetMemHandle(myHandle, myBuffer); MPI_Allgather(myHandle, sizeof(myHandle), MPI_BYTE, allHandles, sizeof(myHandle), MPI_BYTE, comm); void* peerPtrs[RANK_COUNT]; for (int i 0; i RANK_COUNT; i) { if (i myRank) { peerPtrs[i] myBuffer; } else { cudaIpcOpenMemHandle(peerPtrs[i], allHandles[i], cudaIpcMemLazyEnablePeerAccess); } }這里有個(gè)我一開(kāi)始沒(méi)注意的細(xì)節(jié)cudaIpcOpenMemHandle的最后一個(gè)參數(shù)。如果傳0表示“打開(kāi)句柄但不自動(dòng)使能P2P”主要用于只想訪問(wèn)數(shù)據(jù)不想開(kāi)P2P的場(chǎng)景如果傳cudaIpcMemLazyEnablePeerAccess打開(kāi)的同時(shí)嘗試使能P2P。強(qiáng)烈建議顯式傳這個(gè)flag否則后續(xù)kernel訪問(wèn)對(duì)方指針很可能落在慢速路徑上性能慘不忍睹。還有一個(gè)常見(jiàn)坑是句柄的字節(jié)序和對(duì)齊。cudaIpcMemHandle_t是一個(gè)64字節(jié)的不透明結(jié)構(gòu)跨平臺(tái)傳輸時(shí)不能把它當(dāng)簡(jiǎn)單字符串比較或打印直接通過(guò)MPI按字節(jié)廣播最穩(wěn)妥。另外打開(kāi)句柄之后一定要在通信結(jié)束時(shí)調(diào)用cudaIpcCloseMemHandle釋放映射否則長(zhǎng)時(shí)間跑訓(xùn)練進(jìn)程會(huì)積累大量虛擬映射最終導(dǎo)致地址空間碎片化。3.3 同步與流水線別讓 AllReduce 退化成串行拷貝代碼寫(xiě)完第一版性能慘到懷疑人生——比Ring LL還慢。后來(lái)一查問(wèn)題是同步方式寫(xiě)得太粗我在每輪kernel之間都調(diào)了cudaDeviceSynchronize等于每步都在等GPU干完活完全把流水線壓成了串行。正確做法是用CUDA event做流內(nèi)同步或者直接在kernel內(nèi)部用原子/flag做細(xì)粒度同步。把那版同步改掉之后我把通信拆成了三段流水第一段從對(duì)端buffer加載數(shù)據(jù)到寄存器第二段做元素相加第三段把結(jié)果寫(xiě)回對(duì)端buffer。這恰好對(duì)應(yīng)GPU kernel里的循環(huán)展開(kāi)結(jié)構(gòu)讓加載和計(jì)算重疊寫(xiě)回和下一輪的加載重疊。這里還有一個(gè)關(guān)鍵優(yōu)化不要開(kāi)cudaMemcpyPeerAsync而是直接在自定義kernel里讀寫(xiě)對(duì)端指針。因?yàn)閏udaMemcpyPeerAsync在內(nèi)部可能會(huì)觸發(fā)額外的驅(qū)動(dòng)狀態(tài)機(jī)處理而kernel直接訪問(wèn)IPC映射的peer指針走的是SM加載/存儲(chǔ)指令路徑最短。代碼上看就是普通指針dereference但物理上數(shù)據(jù)直接跨PCIe走了。3.4 第一個(gè)能跑的版本和它的問(wèn)題第一個(gè)能跑通的版本大概只有150行CUDA代碼功能上完全正確性能卻只在4MB附近有優(yōu)勢(shì)再小或再大都不如NCCL。問(wèn)題出在兩處一是小消息時(shí)IPC句柄分發(fā)和P2P使能的開(kāi)銷(xiāo)占比太高。2KB的消息通信本身的活不到一微秒開(kāi)句柄和同步的固定成本倒要十幾微秒自然比不過(guò)Ring LL。二是大消息時(shí)單個(gè)kernel內(nèi)大量元素循環(huán)導(dǎo)致寄存器溢出。A100一個(gè)SM的寄存器文件有限我讓每個(gè)線程處理太多元素編譯器只能把中間結(jié)果spill到local memory速度直接掉一個(gè)量級(jí)。解法是讓每個(gè)線程只處理8到16個(gè)元素剩下的交給更多的線程塊而不是把循環(huán)塞給單個(gè)線程。這兩個(gè)問(wèn)題倒逼我把算法設(shè)計(jì)成“分段自適應(yīng)”小于1MB走NCCL Ring LL1MB到64MB走我自定義的IPC AllReduce超過(guò)128MB干脆直接用NCCL的Tree。這個(gè)取舍讓整體曲線變得平滑也讓我的自定義實(shí)現(xiàn)真正聚焦在它的優(yōu)勢(shì)區(qū)間。4. 實(shí)測(cè)數(shù)據(jù)與參數(shù)調(diào)優(yōu)性能翻倍出現(xiàn)在哪個(gè)區(qū)間4.1 三種算法的橫向?qū)Ρ萊ing LL、Tree 與 IPC AllReduce兩機(jī)8卡場(chǎng)景下的實(shí)測(cè)數(shù)據(jù)我提取了一段有代表性的結(jié)果。下表是all_reduce_perf的busbw單位GB/s數(shù)據(jù)越大越好消息大小Ring LLTree AllReduce自定義 PCIe IPC AllReduce16KB32.422.128.7256KB88.674.391.21MB124.3138.2176.54MB118.7186.4204.816MB102.5218.3232.664MB86.4224.1218.9可以明顯看到三個(gè)區(qū)間小消息256KBRing LL還是王者畢竟它的延遲優(yōu)勢(shì)在中等消息1MB到16MB我的IPC實(shí)現(xiàn)收益最大相對(duì)Ring LL幾乎翻倍超大消息64MBTree追了上來(lái)和IPC實(shí)現(xiàn)打平甚至反超。這印證了NCCL內(nèi)部算法選擇器是有道理的——沒(méi)有哪個(gè)算法能統(tǒng)治全部尺寸工程上要按區(qū)間分而治之。延遲方面IPC AllReduce的優(yōu)勢(shì)只在多跳場(chǎng)景下體現(xiàn)。兩機(jī)通信只有一跳延遲和Ring LL差不多但如果擴(kuò)展到四機(jī)Ring需要繞三跳我的樹(shù)只需要兩跳延遲優(yōu)勢(shì)會(huì)拉大到百分之二十左右。4.2 NCCL_ALGO/NCCL_PROTO/通道數(shù)這些參數(shù)到底在控制什么如果你不想寫(xiě)自定義實(shí)現(xiàn)純粹靠調(diào)NCCL參數(shù)能提升多少我的經(jīng)驗(yàn)是能調(diào)但天花板有限。NCCL的參數(shù)體系核心是三個(gè)NCCL_ALGO控制算法取值有Ring、Tree、Collnet和Pat等。NCCL_PROTO控制協(xié)議取值有LL、LL128和Simple。LL和LL128都是低延遲協(xié)議LL128在128字節(jié)對(duì)齊的塊上做優(yōu)化帶寬比LL好一些Simple是沒(méi)有flag的純數(shù)據(jù)協(xié)議帶寬最高但需要額外的同步機(jī)制延遲也最高。實(shí)際調(diào)優(yōu)中中等消息區(qū)間可以嘗試NCCL_PROTOSimpleNCCL_ALGOTree的組合確實(shí)比默認(rèn)的Ring LL好不少。但我的自定義IPC路徑還是快了10%到15%差距主要來(lái)自少了一層協(xié)議封裝以及直接把數(shù)據(jù)通路壓在peer mapping上省掉了NCCL內(nèi)部的flag和同步原語(yǔ)。還有一個(gè)經(jīng)常被忽視的參數(shù)是NCCL_MAX_NCHANNELS。NCCL在處理大消息時(shí)會(huì)多開(kāi)幾個(gè)通道并行傳輸?shù)ǖ罃?shù)不是越多越好——PCIe Switch的總帶寬就那么多通道開(kāi)多了反而增加仲裁開(kāi)銷(xiāo)。實(shí)測(cè)我的環(huán)境里8個(gè)通道最優(yōu)調(diào)的太高反而降速。4.3 擴(kuò)展到 16 卡時(shí)要注意的 PCIe Switch 帶寬共享單機(jī)8卡測(cè)完效果不錯(cuò)我自然想擴(kuò)展到兩機(jī)16卡、四機(jī)32卡。結(jié)果第一輪就把我打醒16卡時(shí)IPC AllReduce相對(duì)Ring LL的增益從翻倍縮小到只有30%左右。原因不復(fù)雜我這兩臺(tái)機(jī)器的PCIe拓?fù)涫敲颗_(tái)機(jī)器有兩個(gè)PCIe Switch每個(gè)Switch下面掛了4張GPU加一張IB網(wǎng)卡。當(dāng)我用IPC讓跨節(jié)點(diǎn)GPU做P2P時(shí)數(shù)據(jù)要從GPU A的顯存出發(fā)經(jīng)PCIe Switch到IB網(wǎng)卡再到對(duì)端機(jī)器。這整個(gè)鏈條共享同一個(gè)PCIe Switch的帶寬一張卡跑的時(shí)候能獨(dú)占x16四張卡同時(shí)跑就變成四張卡分同一個(gè)Switch的帶寬單卡等效帶寬直接除以4。這個(gè)限制單純靠算法繞不過(guò)去除非換到NVLink跨機(jī)比如NVLink-C2C或者用更多網(wǎng)卡分擔(dān)流量。所以在設(shè)計(jì)大規(guī)模AllReduce時(shí)我會(huì)先跑一遍nvidia-smi topo -m數(shù)一數(shù)哪些GPU共享同一個(gè)Switch然后把配對(duì)的rank盡量分散到不同的Switch上讓流量在多個(gè)PCIe域之間分流。這個(gè)拓?fù)涓兄呐判虮热魏未a優(yōu)化帶來(lái)的收益都直接。5. 比算法更磨人的是 PCIe 硬件本身的坑5.1 AER 錯(cuò)誤與掉卡壓力測(cè)試暴露的信號(hào)完整性問(wèn)題性能調(diào)優(yōu)告一段落后我把自定義AllReduce接到真實(shí)訓(xùn)練腳本里跑了兩周長(zhǎng)穩(wěn)測(cè)試。大概跑到第三天第一張GPU開(kāi)始神秘掉線訓(xùn)練進(jìn)程還在跑但nvidia-smi里看不到這張卡了dmesg刷屏滿(mǎn)是對(duì)PCIe的報(bào)錯(cuò)日志。這類(lèi)問(wèn)題的關(guān)鍵詞是AERAdvanced Error Reporting。dmesg里會(huì)看到類(lèi)似PCIe Bus Error: severityCorrected的條目翻譯成人話就是PCIe鏈路在物理層檢測(cè)到了傳輸錯(cuò)誤但糾錯(cuò)機(jī)制成功修復(fù)了。一次兩次不用管但頻繁出現(xiàn)就說(shuō)明信號(hào)完整性在惡化——通常是PCIe鏈路訓(xùn)練不穩(wěn)定、供電波紋過(guò)大、或者卡沒(méi)插緊。我踩過(guò)的具體場(chǎng)景是機(jī)柜里的服務(wù)器長(zhǎng)時(shí)間高負(fù)載運(yùn)行后GPU溫度上升PCIe插槽附近的金屬結(jié)構(gòu)發(fā)生微小熱脹冷縮接觸電阻變大于是鏈路開(kāi)始出現(xiàn)corrected error。最詭異的是這類(lèi)問(wèn)題在低負(fù)載時(shí)很難復(fù)現(xiàn)只有AllReduce讓PCIe總線滿(mǎn)負(fù)荷持續(xù)跑很久才會(huì)暴露。處理思路分三步第一步把pcinoaer加進(jìn)內(nèi)核啟動(dòng)參數(shù)暫時(shí)屏蔽AER風(fēng)暴保證訓(xùn)練不斷第二步把出問(wèn)題卡和對(duì)應(yīng)槽位重新插拔、清潔金手指第三步在BIOS里關(guān)閉ASPM電源管理并把PCIe Gen鎖定在Gen4而不是Auto杜絕因電源狀態(tài)切換導(dǎo)致鏈路重訓(xùn)。5.2 鏈路降速的隱蔽影響與排查命令掉卡之前其實(shí)還有一個(gè)更隱蔽的信號(hào)鏈路降速。PCIe鏈路協(xié)商出來(lái)的速率會(huì)動(dòng)態(tài)變化如果信號(hào)質(zhì)量變差主板控制器會(huì)自動(dòng)把速率從16GT/s降到8GT/s甚至降到2.5GT/s。這個(gè)過(guò)程對(duì)操作系統(tǒng)和驅(qū)動(dòng)來(lái)說(shuō)都是“正常”的訓(xùn)練進(jìn)程也不會(huì)報(bào)錯(cuò)唯一表現(xiàn)是AllReduce帶寬悄悄折半。排查命令我在前面提到過(guò)再?gòu)?qiáng)調(diào)一遍lspci -vvv | grep -A5 -B5 LnkSta重點(diǎn)看每個(gè)PCIe設(shè)備當(dāng)前協(xié)商的速率和通道數(shù)正常應(yīng)該顯示LnkSta: Speed 16GT/s, Width x16。nvidia-smi -q -d PCI查看GPU自己的PCIe鏈路信息。dmesg | grep -i pcie確認(rèn)有沒(méi)有鏈路降速的重訓(xùn)記錄。那次排查我找到了一張卡的LnkSta降到了8GT/s但nvidia-smi里顯示一切正常。找到之后強(qiáng)制觸發(fā)鏈路重訓(xùn)在BIOS里把PCIe Gen明確設(shè)為Gen4帶寬?cǎi)R上回來(lái)了。這個(gè)坑之所以隱蔽是因?yàn)樗挥绊懝δ堋⒅挥绊懶阅芏阅軉?wèn)題排查起來(lái)最耗時(shí)間。5.3 上生產(chǎn)前的穩(wěn)定性檢查清單這些坑踩完我沉淀了一份檢查清單總結(jié)如下進(jìn)BIOS關(guān)閉ASPM和任何PCIe電源管理訓(xùn)練機(jī)器不需要省電它需要穩(wěn)定。把PCIe Gen固定在最支持的代數(shù)不要用Auto避免鏈路反復(fù)重訓(xùn)。確認(rèn)每張GPU的LnkSta都協(xié)商在預(yù)期速率記錄基線后續(xù)對(duì)比。跑至少24小時(shí)PCIe滿(mǎn)負(fù)荷壓力測(cè)試觀察dmesg里AER報(bào)錯(cuò)數(shù)量和類(lèi)型。定期檢查nvidia-smi topo -m和實(shí)際P2P帶寬固件或驅(qū)動(dòng)更新后拓?fù)淇赡茏兓?。不要在?xùn)練中途熱插拔任何PCIe設(shè)備——就算主板和驅(qū)動(dòng)支持集群調(diào)度器也不會(huì)優(yōu)雅處理。我在FDR環(huán)境里測(cè)試過(guò)插拔后驅(qū)動(dòng)要重新枚舉設(shè)備而GPU顯存里的訓(xùn)練狀態(tài)基本全部丟失最后只能重啟作業(yè)。關(guān)于“PCIe枚舉過(guò)程”還有一個(gè)容易被忽略的點(diǎn)如果機(jī)器在開(kāi)機(jī)時(shí)GPU沒(méi)有被正確枚舉比如POST階段某個(gè)槽位報(bào)錯(cuò)后面就算系統(tǒng)起來(lái)了這張卡也可能不在NUMA節(jié)點(diǎn)上影響所有P2P路徑。我習(xí)慣在裝完環(huán)境后立即做一次完整的枚舉狀態(tài)核對(duì)把每張卡和它在topo -m里的位置記錄下來(lái)省得后面踩了拓?fù)涞目舆€誤以為是算法問(wèn)題。這次從Ring LL切換到PCIe IPC AllReduce的經(jīng)歷說(shuō)到底是兩條線的交叉一條是算法層面理解NCCL為什么快、為什么慢另一條是硬件層面搞清PCIe鏈路、拓?fù)洹PC映射背后的物理限制。如果讓我給后來(lái)者一句最實(shí)在的建議先用nvidia-smi topo -m和數(shù)據(jù)通路的帶寬測(cè)試搞清楚你的卡和卡之間到底有幾條路、路況如何再?zèng)Q定要不要自己寫(xiě)AllReduce實(shí)現(xiàn)。很多情況下調(diào)整NCCL_ALGO和NCCL_PROTO、強(qiáng)制固定PCIe Gen、關(guān)掉ASPM就能解決80%的性能和穩(wěn)定性問(wèn)題剩下那20%才需要你深入IPC映射和kernel級(jí)別的通信優(yōu)化。這次的自定義實(shí)現(xiàn)雖然只在1MB到64MB的區(qū)間里發(fā)揮了最大價(jià)值但它讓我徹底弄清了從Ring LL到PCIe IPC中間每一層數(shù)據(jù)是怎么流動(dòng)的這份理解比跑分提升本身更值錢(qián)。