在進入正文之前做AI Infra的兄弟估計都經(jīng)歷過這種尷尬別人嘴里蹦出SM、Tensor Core、HBM、NVLink自己只能微笑點頭然后回來偷偷查資料。尤其是看GPU規(guī)格表的時候只看顯存大小和CUDA核心數(shù)別的參數(shù)一律劃過。這不怪你因為網(wǎng)上講GPU架構(gòu)的教程不是照搬NVIDIA官方白皮書翻譯就是堆術(shù)語讓人越看越懵。但這個坎過不去AI Infra就干不深。做訓(xùn)練的人要知道為什么數(shù)據(jù)并行到32卡擴展比上不去做推理的人要知道為什么A100跑小模型比4090還慢做K8s調(diào)度的人要知道為什么有些Pod必須綁定在特定節(jié)點上——這些問題的根源全都在GPU架構(gòu)里。這篇就是入門第二篇我打算把GPU架構(gòu)里跟AI Infra最相關(guān)的幾個核心概念掰開揉碎講透從SM到顯存再到卡間互聯(lián)把每個為什么都解釋到位。不搞那種讀起來跟天書一樣的架構(gòu)圖就當作一個懂硬件的同事在給你講內(nèi)部知識。1. GPU架構(gòu)到底在解決什么問題1.1 從一個矩陣乘法說起CPU為什么跑不動先做一個思想實驗。假設(shè)我們要算兩個4096乘4096的矩陣相乘這是大模型里注意力機制的最基礎(chǔ)操作。直接算的話要做大概690億次乘加運算4096的三次方乘以2大約700億次浮點操作。如果用一顆很強的CPU比如雙路64核的服務(wù)器理論浮點算力大概在2到4 TFLOPS左右也就是每秒2到4萬億次浮點運算。跑一次這個矩陣乘法需要大約2到3秒。聽起來好像也不慢對吧但問題在于大模型訓(xùn)練可不止做一次矩陣乘法。一個70B參數(shù)的大模型一次訓(xùn)練step要在每個token上跑幾百次這樣的矩陣運算一次step要處理幾萬到幾百萬個token。算下來一個step需要的總浮點操作數(shù)動輒幾十PFLOPs1 PFLOPs 1000萬億次。用CPU一天24小時跑可能幾個月都訓(xùn)不了一個像樣的模型。那GPU是怎么解決這個問題的思路特別樸既然一個核跑不快那我就堆幾千個核一起跑。一個A100有6912個CUDA核心每個核心頻率只有1.4GHz左右單核算力遠不如CPU但6912個核同時開工疊加Tensor Core的特殊設(shè)計峰值算力可以到312 TFLOPSFP16稠密比雙路CPU高兩個數(shù)量級。這就是GPU的基本哲學(xué)用海量簡單計算單元并行替代少量復(fù)雜計算單元串行。1.2 AI Infra視角GPU是臺偏科的計算機做AI Infra的人腦子里必須有一個概念GPU不是一臺通用的計算機它是一臺為了吞吐而優(yōu)化的偏科機器。它擅長的是大批量、高并行、計算密集型的任務(wù)而一旦遇到分支多、串行依賴強、訪存隨機的任務(wù)表現(xiàn)就很拉胯。在AI Infra的語境里我們關(guān)心GPU的無非就四個指標算力FLOPS每秒能做多少次浮點運算決定算得快不快。顯存帶寬Memory Bandwidth每秒能從顯存里讀多少數(shù)據(jù)決定數(shù)據(jù)喂得上喂不上。顯存容量Memory Capacity能裝下多大的模型、多大的batch決定單卡能干什么活?；ヂ?lián)帶寬Interconnect Bandwidth卡與卡之間數(shù)據(jù)交換的速度決定多卡能不能scale。這四個指標共同決定了一個GPU在AI鏈路里的實際價值缺一個都會變成瓶頸。而且這四個指標之間還經(jīng)常打架顯存容量大了帶寬不一定高算力高了可能功耗也上去了機房散熱和電費都是真金白銀。這就是為什么AI Infra需要懂架構(gòu)——因為選型、規(guī)劃、排查故障的每一步都建立在理解這些參數(shù)之間關(guān)系的基礎(chǔ)上。2. 拆解GPU核心從SM到Tensor Core2.1 SM一切并行度的起點GPU的最小并行計算單元叫SMStreaming Multiprocessor流式多處理器。以Ampere架構(gòu)的A100為例一顆芯片上總共有108個SM。每個SM內(nèi)部又包含若干個CUDA CoreA100的每個SM里有64個FP32 CUDA Core這樣一算就是108乘以64約等于6912個CUDA核心。但這里有個關(guān)鍵細節(jié)GPU不是以單個線程為單位調(diào)度計算的而是以warp為單位。一個warp是32個線程GPU的調(diào)度器每次把一個warp里的32個線程同時分發(fā)到SM上執(zhí)行。如果這32個線程走的指令是一致的也就是SIMT模式單指令多線程就一起執(zhí)行一旦出現(xiàn)分支比如if elsewarp里的線程走了不同的路徑就會分叉執(zhí)行性能就會下降。這是我們排查GPU利用率上不去時經(jīng)常忽略的一個原因。每個SM里還有圍繞執(zhí)行單元配套的東西寄存器堆Register File、共享內(nèi)存Shared Memory、L1緩存、線程調(diào)度器Scheduler等。做AI Infra不一定要摳到每個細節(jié)但必須明白一件事SM的數(shù)量決定了并行度的上限而每個SM內(nèi)部資源寄存器、共享內(nèi)存充足與否決定了這個并行度能不能真正跑滿。比如你啟動的CUDA核函數(shù)里用了太多寄存器導(dǎo)致每個SM能同時駐留的線程塊變少occupancy占用率就掉下來了算力自然會打折。這就像一家餐廳本來有100張桌子但每張桌子要占80平米的面積實際只能擺下30張接待量自然上不去。2.2 Tensor CoreAI時代的勝負手如果說CUDA Core是為了通用并行計算準備的那Tensor Core就是NVIDIA專門給深度學(xué)習(xí)埋的外掛。Tensor Core的本質(zhì)是在硬件層面實現(xiàn)了一次指令完成一個4x4x4的小矩陣乘加的操作。GPU的通用核心需要一條指令做一次乘加而Tensor Core可以在一個時鐘周期內(nèi)完成一個4x4矩陣乘以4x4矩陣再加一個4x4矩陣的累積操作。這個效率提升是非常明顯的。拿A100舉例FP32 CUDA Core的算力是19.5 TFLOPS而加上Tensor Core之后FP16算力是312 TFLOPS差距超過16倍。Tensor Core支持的數(shù)據(jù)精度也很有講究。AI訓(xùn)練里最常用的是FP16和BF16。FP16的好處是顯存占用減半、計算速度翻倍但它的表示范圍有限大數(shù)容易溢出所以訓(xùn)練時經(jīng)常配合混合精度策略——梯度用FP32保存計算用FP16。BF16是Google后來推的指數(shù)部分和FP32一樣范圍夠大但尾數(shù)精度低所以現(xiàn)在大模型訓(xùn)練更偏好BF16。到了H100還有一個FP8格式進一步壓縮精度、提速主要用于推理場景。做AI Infra的在實際部署模型時一定要弄清楚你的推理框架到底用沒用上Tensor Core。如果所有算子都跑在CUDA Core上GPU算力利用率可能連20%都不到但你以為卡已經(jīng)滿負荷了。很多GPU利用率高但速度慢的詭異現(xiàn)象往深了查都是Tensor Core沒用上——算子沒有融合或者是舊版本框架不支持某些精度導(dǎo)致的。2.3 三代架構(gòu)變化的啟示從Volta到Ampere再到HopperGPU架構(gòu)并不是簡單的堆核心數(shù)。以NVIDIA三代數(shù)據(jù)中心卡的演進為例幾個關(guān)鍵變化很能說明架構(gòu)設(shè)計的思路第一代VoltaV100首次引入了Tensor Core概念把FP16算力拉到125 TFLOPS直接改變了深度學(xué)習(xí)訓(xùn)練的游戲規(guī)則。AmpereA100則做了兩個重大決策引入TF32格式讓Tensor Core可以利用FP32的輸入數(shù)據(jù)不用轉(zhuǎn)FP16就能享受Tensor Core加速顯著改善訓(xùn)練精度問題同時大幅加強了NVLink互聯(lián)為多卡訓(xùn)練鋪路。到了HopperH100更是推出了Transformer Engine可以根據(jù)不同層自動切換FP8和FP16把Transformer模型訓(xùn)練再提一個檔次。從AI Infra角度看每次架構(gòu)迭代帶來的不光是算力提升還伴隨著功耗的急劇上漲。V100單卡功耗300WA100到了400WH100直接到了700W一臺8卡的H100服務(wù)器滿載功耗接近6kW相當于一個家用小鍋爐。這直接影響了IDC建設(shè)機柜散熱、配電容量、制冷方案全部要重新設(shè)計。很多公司不是買不起H100而是機房的柜子撐不住——單機柜功率上限5kW的傳統(tǒng)數(shù)據(jù)中心根本塞不下8卡H100服務(wù)器。做AI Infra的如果不懂這點規(guī)劃時準會踩坑。3. 顯存層次帶寬比算力更值錢3.1 為什么HBM是AI的命根子把GPU的算力和訪存分開看就能發(fā)現(xiàn)AI里一個很扎心的事實算力增長的速度遠快于帶寬增長的速度。A100相比V100FP16算力翻了2.5倍但HBM2的帶寬只從900GB/s漲到1.6TB/s左右沒跟上。到了H100帶寬到3.35TB/s但FP8算力已經(jīng)飆到近2000 TFLOPS差距依然在拉大。這意味著什么意味著一個計算強度不高的算子比如逐元素操作element-wise或者簡單的歸約數(shù)據(jù)從顯存搬到計算單元的時間比實際計算的時間還要長——這就是所謂的訪存密集型任務(wù)。這種情況下GPU算力再高也只是個等飯吃的廚子鍋熱到飛起但菜就是送不上來。HBMHigh Bandwidth Memory高帶寬內(nèi)存就是為了解決這個問題而生的。它跟普通顯卡用的GDDR顯存不一樣不是平鋪在PCB上而是通過2.5D封裝技術(shù)垂直堆疊在GPU核心旁邊用密密麻麻的硅通孔TSV做數(shù)據(jù)通道。類比一下GDDR像是城市外環(huán)的快速路路面寬但路程遠HBM像是直接在地底下挖了幾百條隧道通到市中心路程極短但出口極多。HBM的位寬可以做到4096位甚至更大GDDR通常只有32位到64位所以HBM的帶寬能輕松到幾個TB/s。3.2 算算賬roofline模型與計算訪存比既然帶寬和算力是兩種不同的資源那么我們怎么判斷一個模型跑在GPU上到底是算力瓶頸還是帶寬瓶頸業(yè)界通常用Roofline模型來定性地回答這個問題。核心就一個公式計算強度Arithmetic Intensity 總浮點操作數(shù) / 總字節(jié)訪存量單位是FLOP/byte。GPU平臺的屋頂是一條斜線和一條水平線拼成的斜線是帶寬上限水平線是算力上限。如果計算強度低于某個臨界點性能就會被帶寬卡住高于臨界點才會觸及算力天花板。打個具體點的比方。一個reshape操作讀1GB數(shù)據(jù)做1億次運算計算強度極低純粹是帶寬游戲換再貴的卡都差不多而一個大的矩陣乘法讀入400GB的數(shù)據(jù)做幾十PFLOPS的計算屬于典型算力敏感型操作必須上Tensor Core才能跑得快。這就是為什么大模型訓(xùn)練要用高帶寬的HBM而一些數(shù)據(jù)預(yù)處理任務(wù)用普通卡就夠了。3.3 顯存容量為什么H200往141GB走做AI Infra的同學(xué)還關(guān)心另一個參數(shù)顯存容量。這個模型要70GB顯存80GB的卡夠不夠要不要買H200的141GB版本這類問題是日常。顯存容量直接影響的是單卡能容納的模型規(guī)模。大模型推理時要加載模型權(quán)重還要預(yù)留KV Cache推理過程中緩存每個token的Key和Value加快生成速度上下文窗口越長、并發(fā)越高KV Cache越占顯存。也正因如此H100從80GB升級到H200的141GB看起來只是容量多了76%但在大模型推理場景里它能支持的上下文長度和并發(fā)度能翻好幾倍。這不只是裝得下的問題更是跑得久、跑得多的問題。但容量大不等于萬事大吉。有些推理框架為了把更多請求塞進同一張卡把KV Cache量化壓縮省下顯存卻損失了精度、增加了延遲。有些場景里顯存大但帶寬不夠推理速度反而不理想。正確理解顯存容量和帶寬的關(guān)系是AI Infra做容量規(guī)劃的基本功——別只看表面容量要順著模型推理鏈路把每部分顯存開銷都算一遍。4. 卡間互聯(lián)單卡強不算強集群才算數(shù)4.1 多卡訓(xùn)練的通信賬單單張GPU再強總有裝不下的一刻。大模型動輒幾百GB的參數(shù)單卡肯定放不下于是就有了多卡訓(xùn)練。但多卡訓(xùn)練不是簡單地把模型切幾塊丟到幾張卡上跑而是要處理卡與卡之間的數(shù)據(jù)同步。以最基礎(chǔ)的數(shù)據(jù)并行Data ParallelismDP為例。每張卡上有模型的完整副本各自處理不同的batch數(shù)據(jù)算完梯度以后需要把梯度在所有卡之間做一次全量同步AllReduce保證每張卡拿到的梯度平均值一樣才能更新出同一個模型參數(shù)。這個過程就是通信開銷的來源。算一下這個賬單。假設(shè)模型70B參數(shù)用BF16訓(xùn)練每個參數(shù)占2字節(jié)那么一次梯度同步要傳輸大約140GB的數(shù)據(jù)。在8卡A100上用NVLink互聯(lián)拓撲好的話可以做到600GB/s左右的有效帶寬同步一次需要約0.23秒但如果你用的是普通千兆以太網(wǎng)按1GB/s算要140秒——訓(xùn)練完全無法進行。這就是為什么做AI Infra的人看到有人用普通網(wǎng)卡組多卡訓(xùn)練會血壓飆升的原因。4.2 NVLink和NVSwitch把GPU變成一臺大GPU解決卡間通信的NVIDIA方案最早是PCIe后來是NVLink再到現(xiàn)在的高端服務(wù)器里加上NVSwitch。PCIe 4.0 x16的帶寬大約32GB/s雙向聽著還行但跟NVLink一比就是天壤之別。A100時代NVLink 3.0單條鏈路提供600GB/s雙向帶寬H100的NVLink 4.0更是做到900GB/s。這比PCIe快了接近30倍。但是有個問題如果8張卡兩兩之間都要高速互聯(lián)怎么連連線數(shù)量會爆炸。于是出現(xiàn)了NVSwitch——你可以理解成一個超級交換機讓8張卡之間的通信全部通過這個中心節(jié)點轉(zhuǎn)發(fā)任何兩張卡之間都有高帶寬通道。在8卡A100/H100服務(wù)器里靠的正是這一整套 NVLink NVSwitch 機制讓8卡集群在通信層面看起來像一臺擁有8倍顯存和8倍算力的巨型GPU。做AI Infra的配置多卡訓(xùn)練時一定要去看GPU拓撲nvidia-smi topo -m確認卡間的NVLink連接是否完整。我曾經(jīng)踩過坑服務(wù)器某個NVLink橋接壞了系統(tǒng)自動降級走PCIe通信訓(xùn)練速度直接掉一半查了很久才通過nvidia-smi -q -d nvlink發(fā)現(xiàn)鏈路編號全是ERR。4.3 三種互聯(lián)層次的正確認知在多卡和跨節(jié)點訓(xùn)練里信息其實是在三個不同層次的交通系統(tǒng)里流動的片內(nèi)GPU內(nèi)部SM之間通過L2和共享內(nèi)存交換數(shù)據(jù)速度最快。片間同一臺機器內(nèi)的多卡走NVLink/NVSwitch速度次之但仍然很快。節(jié)點間不同服務(wù)器之間通常走InfiniBand或RoCERDMA over Converged Ethernet速度受限于網(wǎng)絡(luò)架構(gòu)和交換機的帶寬最慢。訓(xùn)練時通信的帶寬需求從片內(nèi)到節(jié)點間依次遞減但延遲開銷依次遞增。所以模型并行策略的制定原則簡單說就一句話把最頻繁的通信放在最快的那層上比如張量并行盡量放在單機8卡內(nèi)流水線并行再考慮跨節(jié)點。還有一個實際經(jīng)驗跨節(jié)點訓(xùn)練時如果用的是RoCE網(wǎng)絡(luò)需要特別關(guān)注交換機的流控和擁塞控制配置否則一旦多任務(wù)并發(fā)網(wǎng)絡(luò)延遲抖動就會直接體現(xiàn)在訓(xùn)練迭代時間上。這些都是純軟件層面排查不出來、非得到架構(gòu)層面才能理解的問題。5. 實操視角看懂GPU規(guī)格表與選型5.1 一張規(guī)格表應(yīng)該怎么看做AI Infra日常少不了的活兒就是對比GPU規(guī)格表。很多人只看顯存大小和價格這很容易吃虧。這里我整理了一張以NVIDIA主流數(shù)據(jù)中心卡為參照的對比表重點標出做選型時真正應(yīng)該關(guān)注的信息參數(shù)A100 80GBH100 80GBH200 141GBL40SRTX 4090架構(gòu)AmpereHopperHopperAda LovelaceAda LovelaceFP16 Tensor Core算力稠密312 TFLOPS756 TFLOPS756 TFLOPS362 TFLOPS330 TFLOPS*FP8 Tensor Core算力不支持1513 TFLOPS1513 TFLOPS725 TFLOPS661 TFLOPS*顯存容量80GB HBM2e80GB HBM3141GB HBM3e48GB GDDR624GB GDDR6X顯存帶寬1.6 TB/s3.35 TB/s4.8 TB/s864 GB/s1008 GB/s互聯(lián)NVLink 600GB/sNVLink 900GB/sNVLink 900GB/sPCIe 5.0PCIe 4.0TDP400W700W700W300W450W*4090的Tensor Core算力在單精度浮點上表現(xiàn)不錯但整體架構(gòu)和驅(qū)動對多卡并行、虛擬化、企業(yè)級功能的支持和真正的數(shù)據(jù)中心卡有本質(zhì)差異看規(guī)格表有個核心心法先想清楚你的工作負載類型再往表里套參數(shù)。如果是做7x24小時在線推理服務(wù)你要重點看顯存容量、帶寬和功耗如果是做離線大規(guī)模訓(xùn)練算力和互聯(lián)更重要如果是做實驗性質(zhì)的微調(diào)性價比和上手難度反而要考慮。很多人拿著H100跑小模型發(fā)現(xiàn)速度不一定比4090快多少就是因為小模型吃不滿H100的高算力反而是4090的性價比更香。5.2 訓(xùn)練、推理、微調(diào)分別怎么選不同場景下的選型邏輯差別很大說幾個標配思路大模型預(yù)訓(xùn)練首選H100/H200這類Hopper架構(gòu)卡最好配滿8卡NVLink。訓(xùn)練的核心瓶頸在于算力和卡間通信Hopper架構(gòu)不僅有強大的Tensor Core還有NVLink高帶寬能有效支撐張量并行。另外要注意供電和散熱機房的單機柜功率預(yù)算必須按照滿載設(shè)計別買完卡發(fā)現(xiàn)機房插不上電。大模型推理顯存容量和帶寬雙重要。如果追求極致吞吐H200的141GB HBM3e就是為這個場景準備的——單位卡能塞下更多KV Cache、服務(wù)更多并發(fā)請求。但如果是中小模型的推理比如7B、13B參數(shù)一張4090或L40S可能就夠用了成本差距卻是十倍量級。微調(diào)/實驗數(shù)據(jù)量不大、訓(xùn)練時間短、迭代頻繁這種情況下先別急著上H100。4090雖然多卡通信幾乎沒有沒有NVLink但單卡算力足夠跑LoRA顯存24GB也夠處理一些中小模型。很多研究團隊的踩坑經(jīng)驗都是微調(diào)場景上H100算力嚴重過?；舜髢r錢卻跟4090速度差不多。5.3 成本視角算算單位算力的價格選型除了看技術(shù)參數(shù)還得看錢。這里引入一個做AI Infra經(jīng)常用的簡單指標每TFLOPS每秒的價格。假設(shè)云上租用H100大約每小時2.5美元A100大約1.5美元4090大約0.4美元。用FP16 Tensor Core峰值算力一除卡型每小時價格FP16算力每TFLOPS每小時成本H100$2.5756 TFLOPS約$0.0033A100$1.5312 TFLOPS約$0.00484090$0.4330 TFLOPS*約$0.0012光看這個數(shù)字4090的性價比似乎一騎絕塵但別忘了算力利用率差別巨大。4090的330 TFLOPS是FP16 Tensor Core算力實際跑分布式訓(xùn)練時因為沒有NVLink多卡擴展性差可能只能發(fā)揮20%~30%的算力。而H100在成熟框架上跑Transformer模型算力利用率經(jīng)常能到50%以上。再算上顯存容量限制24GB放不下大模型、可靠性問題消費級卡長時間滿載容易降頻或故障成本賬就得重新算了。核心結(jié)論是省錢不是只看單價而是看單位有效算力的成本而有效算力恰恰和架構(gòu)特性強相關(guān)。這也是我不厭其煩勸人先學(xué)架構(gòu)再學(xué)部署的原因。6. 常見問題與排查實錄6.1 顯存沒滿Training卻OOM了做訓(xùn)練的經(jīng)常遇到一個詭異現(xiàn)象nvidia-smi看顯存占用才50多GB卡是80GB的你明明還有接近30GB的余量但跑訓(xùn)練時直接OOM連下個step都進不去。這個問題的根源在于PyTorch的顯存管理機制。PyTorch為了提高效率會預(yù)申請大塊顯存作為緩存caching allocator即使某個張量釋放了顯存也不馬上還給驅(qū)動而是留在緩存里供后續(xù)復(fù)用。所以nvidia-smi看到的顯存占用是已經(jīng)分配緩存的總和而實際可用空間零碎得很。加上訓(xùn)練過程中有大量臨時張量比如loss、中間激活值、梯度大小不一申請大塊連續(xù)顯存時如果碎片化嚴重就會OOM。排查思路不要只看nvidia-smi的已用顯存要看torch.cuda.memory_summary()里的allocated和reserved兩個值——如果兩者差距很大說明緩存碎片化然后檢查是否有顯存泄漏每step結(jié)束內(nèi)存持續(xù)上漲最后再考慮調(diào)整PYTORCH_CUDA_ALLOC_CONF環(huán)境變量比如設(shè)置expandable_segments:True來改善碎片問題。這些方案的前提是理解底層顯存分配邏輯不然就會瞎清緩存、白重啟進程。6.2 小模型在高端卡上跑不快有朋友拿H100跑一個幾百MB的小模型發(fā)現(xiàn)每token生成速度和4090差不多甚至還不如非常困惑。這就是典型的算力吃不飽——小模型的算子小每次計算的數(shù)據(jù)量小卡上幾千個核心大部分都在等數(shù)據(jù)等待顯存把下一塊數(shù)據(jù)送上來算力利用率極低。這種場景里問題不在GPU的峰值算力而在于帶寬和延遲。推理時的batch size不夠大無法有效隱藏訪存延遲框架也沒有把算子融合到一起每個小算子都觸發(fā)一次kernel launch和一次顯存訪問開銷巨大。解決辦法是換用TensorRT或vLLM這類經(jīng)過深度優(yōu)化、算子融合更充分的推理引擎或者想辦法增大并發(fā)batch讓顯存帶寬被充分壓榨。這是選型之外更重要的優(yōu)化點——有時候瓶頸不在硬件而在軟件沒有利用好硬件架構(gòu)的特性。6.3 多卡訓(xùn)練擴展比上不去32卡訓(xùn)練出來的吞吐只有8卡的三四倍擴展比0.8都不到這種問題幾乎每個做分布式訓(xùn)練的人都遇到過。核心瓶頸幾乎都在通信上。首先查卡間通信拓撲nvidia-smi topo -m確認同一臺機器內(nèi)NVLink是否全部打通跨節(jié)點查網(wǎng)絡(luò)ibstat或ibstatus看InfiniBand鏈路是否處于Active狀態(tài)。再往前查軟件層通信后端是不是NCCLNCCL的環(huán)境變量比如NCCL_DEBUGINFO能不能打出通信耗時的分布還要看網(wǎng)絡(luò)配置比如RoCE的PFC流控是否生效交換機的MTU是否一致。通信優(yōu)化的順序永遠是硬件鏈路先查再查協(xié)議棧最后才去調(diào)框架參數(shù)。這類問題的排查需要一點耐心本質(zhì)上是對GPU架構(gòu)決定通信鏈路通信鏈路決定擴展性這個認知的印證——你不懂硬件就永遠不知道瓶頸出在哪一層。6.4 判斷GPU利用率的正確姿勢最后聊一個日常天天見但經(jīng)常被誤讀的指標GPU利用率。nvidia-smi最頂上顯示的Utilization是過去采樣周期內(nèi)GPU上有一個或多個kernel正在執(zhí)行的時間百分比。注意它的粒度哪怕GPU上只跑了一個很小的算子占用1%的算力只要它一直在跑利用率也能顯示99%。所以“利用率99%”完全不代表算力用滿了。真正判斷GPU有沒有吃滿要看這幾個指標nvidia-smi -q -d UTILIZATION里的計算和內(nèi)存利用率分開看訓(xùn)練場景結(jié)合nsysNVIDIA Nsight Systems看kernel時間和空閑時間比例如果大量時間在wait那多半是訓(xùn)練代碼IO瓶頸或通信瓶頸推理場景用DCGMData Center GPU Manager的指標比如sm_occupancy、tensor_active看SM占用和Tensor Core利用率比單純看利用率準得多。順便科普一個冷知識NVIDIA有個nvidia-smi -q -d CLOCK可以看當前實際運行頻率。如果GPU顯示跑在低頻率比如500MHz往往說明任務(wù)不夠密集、功耗管理降頻了——這也是判斷是否真滿載的一個好信號。7. 寫在最后的實在話做AI Infra這幾年我最大的感受是GPU架構(gòu)不是一門孤立的知識它是整個AI系統(tǒng)性能邏輯的地基。你搞不清楚SM和Tensor Core就理解不了為什么一個算子是帶寬瓶頸搞不清NVLink和網(wǎng)絡(luò)拓撲就扎不透分布式訓(xùn)練的性能調(diào)優(yōu)搞不清顯存分配機制就躲不開線上不時冒出來的OOM。這一篇是入門第二篇其實還只聊了最底層的幾個概念后面的CUDA編程模型、通信庫原理、訓(xùn)推引擎優(yōu)化全都要在這個地基上繼續(xù)蓋樓。最后送一個實操小技巧拿到一臺新GPU服務(wù)器先別急著部署模型花十分鐘把這幾件事做了——nvidia-smi -q -d COMPUTE確認驅(qū)動和卡狀態(tài)nvidia-smi topo -m確認NVLink拓撲用NCCL的all_reduce_perf工具實測一下卡間通信帶寬hbm的帶寬可以用bandwidthTest簡單評估。這些操作都不復(fù)雜但能讓你在真正跑任務(wù)前就對這臺機器的體力心里有數(shù)。以后排查問題的時候一想到這張底盤圖心里就踏實很多。