最近讀了一篇光看標(biāo)題就讓人有點(diǎn)興奮的論文標(biāo)題就叫《GPU-Initiated Communication: Dissecting Down to the Bone》。帶Down to the Bone這種字眼的文章通常不是寫給路人看的——作者是真的煩透了某個(gè)技術(shù)問題決定把它逐層拔皮拆到不能再拆為止。這篇論文拆的就是GPU通信這件事從一個(gè)分布式程序里最常見的ncclAllReduce調(diào)用開始一路往下追到GPU內(nèi)部某個(gè)執(zhí)行單元如何生成一個(gè)網(wǎng)絡(luò)傳輸請(qǐng)求整個(gè)過程基本等同于一次通信鏈路的手術(shù)直播。這篇博文我打算換個(gè)講法不按論文章節(jié)照本宣科而是把論文最核心的骨架抽出來用工程實(shí)踐的視角重新組裝一遍。重點(diǎn)回答幾個(gè)問題為什么GPU算力越來越強(qiáng)之后CPU負(fù)責(zé)協(xié)調(diào)通信這件事反而成了拖后腿的環(huán)節(jié)GPU直接發(fā)起通信之后控制面與數(shù)據(jù)面到底發(fā)生了什么變化同步語義又是怎么處理的以及實(shí)際工程項(xiàng)目里怎么驗(yàn)證這個(gè)機(jī)制生效、會(huì)踩哪些坑。適合正在做分布式訓(xùn)練、大模型推理加速或者對(duì)GPU驅(qū)動(dòng)、高性能網(wǎng)絡(luò)和RDMA棧有好奇心的朋友。1. 為什么GPU通信需要自己說了算1.1 傳統(tǒng)鏈路里那個(gè)被忽略的CPU中轉(zhuǎn)站先回到一個(gè)看似反常的現(xiàn)象。過去幾年GPU算力增長快得離譜網(wǎng)絡(luò)硬件也沒閑著——InfiniBand從100Gbps到400GbpsRoCE也越來越普遍。網(wǎng)卡本身轉(zhuǎn)發(fā)一個(gè)數(shù)據(jù)包的硬件延遲早就壓到亞微秒級(jí)別GPU內(nèi)核之間的調(diào)用開銷也在不斷降低?？墒悄惆岩粋€(gè)真實(shí)的分布式訓(xùn)練任務(wù)放到NSight時(shí)間線里看還是會(huì)發(fā)現(xiàn)GPU經(jīng)常處于呼嚕呼嚕的空等狀態(tài)。問題不出在算得多慢也不出在網(wǎng)絡(luò)多快而出在通信這件事的每一個(gè)節(jié)點(diǎn)都要被CPU過問一遍。傳統(tǒng)路徑大致是這樣GPU這邊某個(gè)kernel把梯度算完寫入顯存緩沖區(qū)CPU通過某種同步機(jī)制比如cudaDeviceSynchronize、事件查詢、或者stream上的回調(diào)察覺到GPU那邊的活兒干完了隨后CPU調(diào)用NCCL或MPI的接口把通信請(qǐng)求提交給通信庫通信庫在CPU側(cè)準(zhǔn)備好描述符、隊(duì)列條目再去推動(dòng)網(wǎng)卡執(zhí)行數(shù)據(jù)傳輸傳輸完成后CPU還要負(fù)責(zé)確認(rèn)狀態(tài)再通知GPU啟動(dòng)下一步的kernel。這條鏈路的每一步單獨(dú)看都很快但串成一條流水線就變得很長了。我在實(shí)際項(xiàng)目里做過一次粗測(cè)在普通PCIe拓?fù)涞臋C(jī)器上一個(gè)CPU介入的NCCL集合通信從GPU kernel結(jié)束到下一個(gè)kernel開始中間那個(gè)CPU喘氣窗口少說有幾微秒到十幾微秒。而現(xiàn)代網(wǎng)卡純硬件的傳輸延遲往往不到一微秒。換句話說真正干活的部分只花了不到十分之一的時(shí)間剩下的全在協(xié)調(diào)。這種浪費(fèi)在大模型訓(xùn)練里被放大得非常明顯——梯度AllReduce是每個(gè)step都要做的一次幾萬微秒幾千個(gè)step跑下來就是秒級(jí)別的純開銷。更麻煩的是分布式訓(xùn)練里通信常常是同步屏障一點(diǎn)點(diǎn)延遲都會(huì)卡住整個(gè)集群的步調(diào)。這就是CPU作為調(diào)度者這個(gè)傳統(tǒng)架構(gòu)的根上問題它太慢了而且它介入得太多。1.2 核心動(dòng)機(jī)把不斷匯報(bào)改成算完就發(fā)GPU發(fā)起通信的核心思路說白了就是一句話把通信請(qǐng)求的發(fā)起權(quán)從CPU手里搶過來交給GPU的SM流式多處理器直接生成。GPU kernel里不再只是寫數(shù)據(jù)、等著別人來取而是直接通過類似nvshmem_put、nvshmem_get這樣的原語或者通過網(wǎng)卡友好的memory store操作自己把數(shù)據(jù)推到對(duì)端。我更喜歡用做飯來類比。傳統(tǒng)模式像廚師做一道菜做完之后必須喊一聲傳菜然后站到一邊等傳菜員過來端走傳菜員還要確認(rèn)菜送到哪桌、反饋給廚房廚房才能開始做下一道。而GPU發(fā)起通信就像廚師做完菜自己伸手把盤子放到傳菜窗口的傳送帶上傳送帶自己會(huì)把菜送到指定桌臺(tái)做得快的時(shí)候甚至同時(shí)已經(jīng)在顛鍋準(zhǔn)備下一道了。這種變更帶來的收益不是省掉一次函數(shù)調(diào)用那么簡單它重排了整條流水線數(shù)據(jù)面數(shù)據(jù)不再需要先經(jīng)CPU拷貝一份或者等著CPU提交DMA描述符GPU的寫操作可以直接落到遠(yuǎn)端顯存路徑短了一大截?？刂泼嫱ㄐ诺挠|發(fā)、完成信號(hào)都留在GPU側(cè)延遲里的協(xié)調(diào)抖動(dòng)基本消失。并發(fā)性通信可以和后續(xù)kernel執(zhí)行重疊而不像傳統(tǒng)模式那樣必須計(jì)算-通信-計(jì)算串行交替給流水線并行、AllReduce重疊、MoE這類點(diǎn)對(duì)點(diǎn)密集范式帶來了新的優(yōu)化空間。但這里也要潑一盆冷水不是所有通信都適合GPU發(fā)起。通信量很小、又確實(shí)需要CPU參與復(fù)雜邏輯的時(shí)候強(qiáng)行從GPU側(cè)發(fā)起反而會(huì)引入更多麻煩。論文里真正有價(jià)值的分析恰恰是在說明哪些場(chǎng)景收益大、哪些場(chǎng)景收益有限以及同步語義在GPU端起之后會(huì)帶來什么新問題。這就是下一節(jié)要聊的骨頭所在。2. 論文視角把通信鏈路拆到骨頭2.1 三個(gè)層次語義、協(xié)議、物理執(zhí)行論文標(biāo)題里的Down to the Bone我認(rèn)為指的是把一次通信請(qǐng)求從最上層的編程模型一路拆到最底層的硬件事務(wù)。工程上可以把這條鏈路分成三個(gè)層次來理解這樣不容易被各種名詞繞暈。第一層是應(yīng)用語義層。解決的問題是誰發(fā)起、什么時(shí)候發(fā)起、以及通信完成意味著什么。在CPU發(fā)起年代通信完成的語義很直觀——CPU調(diào)用了APIAPI返回了任務(wù)就完了。到了GPU發(fā)起年代這個(gè)語義變得非常微妙一個(gè)kernel里的一個(gè)線程調(diào)了nvshmem_put之后它要如何知道數(shù)據(jù)真的到了對(duì)端是繼續(xù)執(zhí)行、還是等待一個(gè)全局barrier這直接影響編程模型的設(shè)計(jì)。第二層是協(xié)議與驅(qū)動(dòng)層。這里做的事情是把通信原語翻譯成網(wǎng)卡可以執(zhí)行的描述符。傳統(tǒng)方式下CPU側(cè)通信庫NCCL、MPI會(huì)組裝工作隊(duì)列元素WQE投遞到網(wǎng)卡的發(fā)送隊(duì)列。GPU發(fā)起模式下這些WQE要么由GPU側(cè)的指令直接生成要么由GPU寫一段特定格式的內(nèi)存由網(wǎng)卡主動(dòng)去解析。這個(gè)層次還要處理傳輸協(xié)議的選擇——InfiniBand、RoCEv2以及不同的傳輸服務(wù)類型可靠連接、不可靠數(shù)據(jù)報(bào)等等。第三層才是物理執(zhí)行層。一次GPU發(fā)起的通信請(qǐng)求在硬件上大概經(jīng)歷這樣的路徑某個(gè)SM執(zhí)行一條指令產(chǎn)生一個(gè)帶有地址和長度的內(nèi)存操作這個(gè)操作要穿過GPU內(nèi)部的GPC、L2緩存訪達(dá)顯存或者直接命中L2然后數(shù)據(jù)通過NVLink或者PCIe到達(dá)網(wǎng)卡網(wǎng)卡再做RDMA寫操作走網(wǎng)絡(luò)到對(duì)端。論文里花大力氣分析的就是這條路徑上每一個(gè)跳點(diǎn)會(huì)引入多少時(shí)延、多少個(gè)時(shí)鐘周期、以及哪些跳點(diǎn)是可以被優(yōu)化掉的。這三層里第二層和第三層是GPU廠商和網(wǎng)卡廠商的死磕點(diǎn)但對(duì)大多數(shù)應(yīng)用工程師來說真正需要好好理解的是第一層——同步語義。如果語義理解錯(cuò)了后面全都是白搭。2.2 同步語義是整套機(jī)制的靈魂傳統(tǒng)CPU發(fā)起通信能在實(shí)踐中活得這么好很大一個(gè)原因是同步模型簡單且可靠。你調(diào)用MPI_Allreduce等函數(shù)返回再讀結(jié)果數(shù)據(jù)的全局一致性有通信庫和內(nèi)存模型兜著不需要你自己去操心fence、memory ordering這些東西。但GPU發(fā)起通信把這塊遮羞布掀掉了。想象一個(gè)kernel內(nèi)部有幾個(gè)線程線程A往對(duì)端寫了一批數(shù)據(jù)線程B隨后馬上要讀同一塊本地內(nèi)存里的標(biāo)志位。在傳統(tǒng)CPU通信中線程A寫完到線程B讀取之間至少隔了一次API調(diào)用、一次內(nèi)存同步順序不會(huì)亂。但在GPU側(cè)直接put的場(chǎng)景里寫數(shù)據(jù)這個(gè)操作本身可能是異步的數(shù)據(jù)還在路上線程B已經(jīng)讀到標(biāo)志位為已完成了。這就產(chǎn)生了真正的亂序和競(jìng)態(tài)。所以論文里面一定繞不開幾個(gè)關(guān)鍵操作原語fence類操作保證之前的寫操作對(duì)當(dāng)前執(zhí)行單元可見或者保證本地內(nèi)存寫完成之后才發(fā)出通信請(qǐng)求。quiet類操作等待所有已發(fā)出的通信請(qǐng)求真正在遠(yuǎn)端完成。這是GPU發(fā)起通信里最昂貴的操作因?yàn)樗ǔＰ枰譅顟B(tài)同步。barrier類操作讓參與通信的所有GPU或線程組到達(dá)同一個(gè)執(zhí)行點(diǎn)然后一起推進(jìn)。我見過不少第一次遷移到NVSHMEM或者GPU發(fā)起通信風(fēng)格代碼的人第一個(gè)bug基本都出在這——用顯存里的標(biāo)志位去判斷一次GPUDirect RDMA寫是否完成結(jié)果是標(biāo)志位寫得太早對(duì)端還沒真正拿到數(shù)據(jù)后續(xù)計(jì)算就用了舊數(shù)據(jù)。這是一個(gè)很典型的看起來正常、跑起來數(shù)據(jù)錯(cuò)亂的場(chǎng)景。2.3 硬件層面到底發(fā)生了什么變化如果把前面講的三層對(duì)應(yīng)到硬件具體行為GPU發(fā)起通信真正的底氣來自兩個(gè)硬趨勢(shì)。第一個(gè)趨勢(shì)是GPUDirect RDMA成熟。這項(xiàng)技術(shù)讓網(wǎng)卡可以繞過CPU、繞過主機(jī)內(nèi)存直接讀寫GPU顯存。也就是說數(shù)據(jù)鏈路從GPU顯存→PCIe→主機(jī)內(nèi)存→CPU→網(wǎng)卡縮短為GPU顯存→PCIe→網(wǎng)卡。GPU發(fā)起通信在此基礎(chǔ)上更進(jìn)一步連通信請(qǐng)求從哪來這個(gè)控制問題都從CPU挪到了GPU理想情況下網(wǎng)卡收到的WQE可以直接由GPU寫出來。第二個(gè)趨勢(shì)是智能網(wǎng)卡和GPU L2的配合。新一代網(wǎng)卡比如BlueField這類DPU產(chǎn)品把一部分通信邏輯卸載到網(wǎng)卡側(cè)可以自己執(zhí)行簡單的聚合、重排、甚至AllReduce的歸約邏輯。GPU這邊則在L2緩存層級(jí)就提供了一些面向?qū)Φ仍L問的職責(zé)讓網(wǎng)卡可以直接從GPU L2側(cè)抓取數(shù)據(jù)而不必先把數(shù)據(jù)沖刷到顯存再搬運(yùn)。這兩個(gè)趨勢(shì)合在一起通信這件事的最后一公里就變成了GPU計(jì)算單元直接告訴網(wǎng)卡去干這個(gè)網(wǎng)卡執(zhí)行完后告訴GPU干完了CPU基本退位。整條鏈路依然復(fù)雜但復(fù)雜度已經(jīng)從CPU頻繁參與協(xié)調(diào)轉(zhuǎn)移到了硬件如何高效地理解GPU側(cè)的表達(dá)。這一點(diǎn)在后面聊調(diào)試和排查時(shí)會(huì)體現(xiàn)得非常明顯——你不能再指望在CPU側(cè)看到所有通信細(xì)節(jié)。3. 實(shí)操觀察把GPU發(fā)起通信跑起來并驗(yàn)證3.1 快速上手路徑用NVSHMEM寫第一段GPU通信理論說了半天不如直接上手跑一下看看。最容易體驗(yàn)GPU發(fā)起通信的方式是NVSHMEM——它是NVIDIA的對(duì)稱異構(gòu)內(nèi)存通信庫OpenSHMEM風(fēng)格API設(shè)計(jì)上就是給GPU kernel內(nèi)直接調(diào)用通信用。和NCCL相比NVSHMEM更底層一些也更貼合GPU發(fā)起這個(gè)主題。先安裝依賴。需要CUDA Toolkit、NVIDIA驅(qū)動(dòng)以及對(duì)應(yīng)版本的NVSHMEM庫一般隨HPC容器或者單獨(dú)deb包提供。安裝完成后寫一個(gè)最簡單的put示例。核心代碼大致是這樣#include nvshmem.h #include nvshmemx.h __global__ void send_kernel(int* dest, int value, int target_pe) { int tid blockIdx.x * blockDim.x threadIdx.x; if (tid 0) { nvshmem_int_put(dest, value, 1, target_pe); nvshmem_quiet(); } else { // 其他線程可以繼續(xù)干別的不用等通信 } } int main() { nvshmem_init(); int my_pe nvshmem_my_pe(); int n_pes nvshmem_n_pes(); int* buf (int*)nvshmem_malloc(1024 * sizeof(int)); // 每個(gè)PE有自己的一份buf通過PE號(hào)尋址 send_kernel1, 32(buf, 42, (my_pe 1) % n_pes); cudaDeviceSynchronize(); nvshmem_free(buf); nvshmem_finalize(); return 0; }注意這個(gè)示例里nvshmem_quiet()是由GPU里的線程執(zhí)行的這意味著等待通信完成這個(gè)動(dòng)作發(fā)生在GPU側(cè)CPU完全沒有參與。這才是真正的GPU發(fā)起通信。編譯時(shí)需要鏈接NVSHMEM庫并開啟多進(jìn)程支持通常通過mpirun啟動(dòng)多個(gè)進(jìn)程來模擬多節(jié)點(diǎn)。一個(gè)簡單的編譯命令類似nvcc -archsm_80 -rdctrue -lnvshmem -lnvshmemx -o shmem_demo demo.cu mpirun -np 2 ./shmem_demo跑起來之后預(yù)期看到進(jìn)程0往進(jìn)程1的顯存緩沖區(qū)寫入了值42并且進(jìn)程1可以通過自己的指針讀到這個(gè)數(shù)據(jù)。這個(gè)過程不需要顯式的CPU同步也沒有CUDA stream回調(diào)。第一次跑通這個(gè)例子的感覺挺奇妙的——通信發(fā)生在GPU kernel內(nèi)部而且你可以通過調(diào)試器看到整個(gè)通信期間CPU側(cè)幾乎沒有任何活躍操作。3.2 用Nsight實(shí)際去抓執(zhí)行時(shí)序驗(yàn)證通信是否真的重疊跑通示例只是第一步更關(guān)鍵的是驗(yàn)證這個(gè)機(jī)制有沒有真正把通信和計(jì)算重疊起來。我習(xí)慣用Nsight Systemsnsys來抓時(shí)間線因?yàn)樗腉PU進(jìn)程視圖比較直觀能看到kernel、CUDA API調(diào)用和NCCL/NVSHMEM這類通信事件之間的關(guān)系。操作步驟很簡單編譯時(shí)加上-lineinfo保留源代碼映射這樣時(shí)間線里能看到具體核函數(shù)名。用nsys profile -s none -t cuda,osrt,nvtx -o gpu_comms_profile ./shmem_demo抓取一次運(yùn)行。如果需要抓更細(xì)的GPU硬件計(jì)數(shù)器再用Nsight Computencu做單kernel級(jí)別的分析。打開生成的.nsys-rep時(shí)間線觀察兩個(gè)關(guān)鍵指標(biāo)第一個(gè)指標(biāo)是kernel與通信是否在時(shí)間上重疊。理想狀態(tài)下send_kernel執(zhí)行期間網(wǎng)絡(luò)傳輸事件應(yīng)該已經(jīng)開始并且可以和后續(xù)計(jì)算kernel并行。如果時(shí)間線上看到通信事件等到kernel結(jié)束才開始那說明你的代碼無意中把通信序列化到了kernel邊界之后還是退回了舊的CPU編排路徑。第二個(gè)指標(biāo)是CPU參與度的變化。在Nsight的活動(dòng)追蹤里如果看到大量CUDA API調(diào)用集中在CPU線程上說明CPU仍然在做通信編排這不是GPU發(fā)起只是把NCCL搬到了GPU附近而已。真正的GPU發(fā)起通信CPU側(cè)的活動(dòng)會(huì)非常稀薄大部分時(shí)間在等待MPI初始化或最終同步。我還遇到過一種情況看起來通信和計(jì)算是重疊了但整體性能沒有提升。這種時(shí)候不要急著懷疑GPU發(fā)起通信本身先去看是不是通信數(shù)據(jù)量太小、網(wǎng)絡(luò)延遲已經(jīng)低于kernel自身執(zhí)行時(shí)間或者是不是走了共享內(nèi)存交換路徑根本沒有使用RDMA。很多性能沒有提升的問題最后排查下來都是沒走對(duì)硬件路徑。4. 踩坑與排查GPU發(fā)起通信的幾處暗礁4.1 現(xiàn)象一通信根本沒走GPU發(fā)起路徑這是最常見也最隱蔽的問題。代碼寫的是NVSHMEM風(fēng)格但實(shí)際跑起來Nsight時(shí)間線卻顯示CPU在忙前忙后。排查思路從這幾個(gè)方向入手。第一檢查GPUDirect RDMA是否真的開啟?？梢酝ㄟ^nvidia-smi查看GPU和網(wǎng)卡的拓?fù)潢P(guān)系注意禮物度或者檢查nvshmem_info這類工具打印出來的傳輸后端。如果后端顯示走的是proxy或者h(yuǎn)ost路徑而不是gpu路徑那就說明數(shù)據(jù)經(jīng)過了一次CPU中轉(zhuǎn)機(jī)制沒有生效。第二檢查網(wǎng)絡(luò)類型。RoCE需要正確的擁塞控制配置InfiniBand需要正確的分區(qū)鍵這些配置錯(cuò)誤會(huì)導(dǎo)致網(wǎng)卡回退到TCP兼容模式延遲立刻升高。雖然功能還能跑但性能特征完全變了。第三檢查對(duì)稱內(nèi)存分配方式。NVSHMEM要求所有PE都分配相同大小的緩沖區(qū)并且地址映射是對(duì)稱的。如果分配方式不對(duì)庫會(huì)退回到逐元素拷貝的兼容路徑GPU發(fā)起直接退化為CPU模擬。我把這幾個(gè)原因整理成一個(gè)隨查隨用的表現(xiàn)象可能原因快速排查手段CPU占用異常高GPUDirect未開啟 / 走了host proxy查看nvshmem后端信息確認(rèn)傳輸為gpu-direct通信延遲異常高RoCE未走RDMA / 擁塞控制配置缺失用mlx5_*工具查看端口模式和活躍協(xié)議功能正常但執(zhí)行慢對(duì)稱內(nèi)存分配不對(duì)退化為拷貝檢查NVSHMEM緩沖分配API是否滿足對(duì)稱條件kernel內(nèi)通信沒有重疊quiet調(diào)用位置過于頻繁在Nsight時(shí)間線里找連續(xù)的quiet阻塞調(diào)整同步粒度4.2 現(xiàn)象二數(shù)據(jù)錯(cuò)亂和看起來沒完成的同步問題剛上手GPU發(fā)起通信時(shí)數(shù)據(jù)錯(cuò)亂幾乎是每個(gè)人都會(huì)撞上的問題。我在前面講過GPU側(cè)的寫操作是異步的你不能用顯存里的標(biāo)志位來判斷一次RDMA寫是否在遠(yuǎn)端可見。實(shí)際上即使你用nvshmem_quiet()在GPU里做了柵欄也還需要理解quiet只保證本地視角的通信完成不等于遠(yuǎn)端內(nèi)存立即對(duì)遠(yuǎn)端GPU可見這個(gè)細(xì)節(jié)。排查這類問題的思路不是去懷疑RDMA丟包而是去檢查你的程序是否在每次通信后有明確的同步邊界。我常用的鐵律是任何一次通信在發(fā)起方必須有一個(gè)明確的fence/quiet在接收方必須有一個(gè)明確的等待/barrier兩者缺一個(gè)就要做好亂序的準(zhǔn)備。舉一個(gè)實(shí)際踩過的例子。我在一個(gè)多GPU矩陣乘法測(cè)試?yán)镒屆總€(gè)GPU把自己的結(jié)果切片發(fā)送給下一個(gè)GPU。發(fā)送方在kernel末尾統(tǒng)一nvshmem_quiet()然后退出kernel。接收方在下一個(gè)kernel開頭直接讀數(shù)據(jù)。表面看起來沒問題但偶爾在特定數(shù)據(jù)規(guī)模下接收方讀到的還是舊數(shù)據(jù)。后來用cudaEvent記錄時(shí)間點(diǎn)才發(fā)現(xiàn)問題出在接收方的kernel啟動(dòng)得太早接收到數(shù)據(jù)在RDMA寫實(shí)際落地之前就已經(jīng)進(jìn)入了讀取階段。解決辦法是在接收方用NVSHMEM的nvshmemx_team_sync做一次團(tuán)隊(duì)級(jí)同步確保所有PE都到達(dá)了同一個(gè)執(zhí)行屏障再開始讀取。4.3 現(xiàn)象三調(diào)試時(shí)的黑盒感最后一個(gè)勸退很多人的點(diǎn)就是調(diào)試。CPU發(fā)起通信的年代你在CPU側(cè)一斷點(diǎn)下去消息隊(duì)列、緩沖區(qū)、狀態(tài)都能看得很清楚。GPU發(fā)起通信之后很多關(guān)鍵狀態(tài)在GPU內(nèi)部普通調(diào)試器很難直接觀察。我的建議分三步走。第一步開啟通信庫自己的診斷日志。NVSHMEM支持設(shè)置環(huán)境變量輸出內(nèi)部狀態(tài)NCCL也有NCCL_DEBUGINFO這些日志能幫你定位描述符是否被正常提交。第二步使用Nsight系列的硬件計(jì)數(shù)器來觀察SM到L2再到網(wǎng)卡的實(shí)際事務(wù)數(shù)量判斷通信請(qǐng)求到底有沒有從SM發(fā)出。第三步把問題逐步縮小——先在單機(jī)雙卡環(huán)境下驗(yàn)證再到雙機(jī)雙卡再到全拓?fù)?。這一步很笨但很有效能排除掉大量網(wǎng)絡(luò)基礎(chǔ)設(shè)施層面的變量。5. 在我實(shí)際項(xiàng)目里的體會(huì)與建議讀這篇論文、加上自己踩過的坑我想說的是GPU發(fā)起通信不是一次簡單的API改動(dòng)它本質(zhì)上是把分布式系統(tǒng)里誰主事的問題重新回答了一遍。CPU主導(dǎo)的時(shí)代專家們?cè)贑PU側(cè)調(diào)試工具鏈上堆了二十年而GPU主導(dǎo)通信后這套工具鏈的很多環(huán)節(jié)都失效了。這也解釋了為什么論文里花了那么多篇幅去分析一個(gè)簡單put操作在硬件里的完整旅行——因?yàn)闆]有這種基礎(chǔ)層級(jí)的理解后面談性能優(yōu)化和故障排查都是空中樓閣。如果讓我給一個(gè)學(xué)習(xí)路徑建議也別著急一步跨到NVSHMEM那么深。先把NCCL集合通信的運(yùn)作機(jī)制摸透搞清楚AllReduce的ring和tree兩種算法在延遲上有什么區(qū)別然后用Nsight抓幾次真實(shí)訓(xùn)練的通信時(shí)間線理解計(jì)算通信重疊的形態(tài)再試著用GPU發(fā)起通信改寫一個(gè)小的點(diǎn)對(duì)點(diǎn)傳輸程序。把這個(gè)鏈路走完你再看論文里關(guān)于控制面、數(shù)據(jù)面、同步語義的討論就能對(duì)得上號(hào)了。最后還有一個(gè)我們項(xiàng)目里一直沿用的小技巧在做通信機(jī)制遷移時(shí)不要只對(duì)比端到端時(shí)間還要固定住基準(zhǔn)任務(wù)規(guī)模分別記錄kernel執(zhí)行時(shí)間、通信時(shí)間、CPU等待時(shí)間三個(gè)分量。很多時(shí)候端到端時(shí)間沒變化但其實(shí)通信時(shí)間已經(jīng)降了只是新的計(jì)算重疊把GPU利用率提高了總時(shí)間被別處的瓶頸掩蓋了。把時(shí)間拆細(xì)才能看出GPU發(fā)起通信到底有沒有起到作用。