![]()
頂級 GPU 躺平,只因模型不懂硬件邏輯
作者丨高允毅
編輯丨馬曉寧
上個月,一位做推薦系統的朋友找我大吐苦水。團隊花了大幾百萬,剛咬牙把模型搬上了 8 張 H100,滿心以為能輕松扛住流量。結果監控面板一拉,心涼了半截,GPU 利用率常年躺平在 40% 上下。
他的第一反應是:“完了,老板咱們還得加卡。”
停!先捂緊錢包。
別總覺得是卡不夠。模型跑不快,問題很可能根本不在 GPU,而是你的模型在寫下第一行代碼的設計之初,就沒有設計成適配GPU的形狀。
就在最近,英偉達親自下場,發布了一篇名為《AI Model Co-Design: Hardware-Friendly LLM Design》的技術博客。整篇文章洋洋灑灑,其實就想點醒行業一件事:別光顧著堆算力了,來看看你們是怎么把頂級顯卡逼成“磨洋工”的吧。
![]()
![]()
01
為什么"大力士"在磨洋工
要看懂英偉達的這篇論文,得先認清 GPU 的真面目。
可以把GPU看作是個干活極快的“超級大力士”,它的計算能力極強,每秒能完成幾十萬億次浮點運算。理論上講,其算力天花板極高。
但另一方面,它必須等材料喂到嘴邊才能干活,對應的是所有的模型權重、輸入特征,都必須從顯存搬運到計算核心里。
當我們覺得GPU沒有跑滿的時候,未必是他自身的計算能力出了問題,還取決于能不能持續喂夠原料,而“喂的好不好”的唯一標準,就是論文里指出的核心概念“算術強度”。
這有一個公式,算術強度 = 顯卡完成的計算總次數 ÷ 顯卡搬運的內存總字節數這個公式解釋的是,每搬運1字節數據,能讓GPU干多少次算數活? 當算數強度低的時候,GPU花90%的時間在等數據讀寫,真正用來做計算的時間微乎其微。這個問題就叫“訪存受限”。你花重金買的高端算力,就是這么被閑置的。
論文中列舉的一個極具代表性的硬件低效反面案例FFN-2。FFN-2 指的是大模型中前饋神經網絡的第二層(降維映射層)。在標準的矩陣乘法計算中,該層涉及三個核心維度:
M是輸入的 Token總數、N是隱藏維度、K是中間維度。這三者決定了矩陣乘法的總計算量 其中N固定設為了 8192,K設為了512。
![]()
圖注:論文分析了 GB300 硬件下(15 PFLOPS FP4 算力/8 TB/s 帶寬)FFN-2 層在 N=8192、K=512 配置下的矩陣乘法理論耗時。結果表明,由于顯存數據傳輸耗時始終長于實際計算時間,該層不論在何種 Token 數量下均受限于顯存帶寬。 關鍵問題,就出在這個512上。因為K過小,導致總計算量非常小。換句話說,計算的數量遠遠少于GPU搬了的數據數量。
更要命的是,現在的大模型為了提速,喜歡用低精度格式,會加速GPU的處理速度,那數據搬運的速度徹底跟不上計算的速度,GPU根本跑不滿。 在實際測試中,這種浪費更加嚴重。論文在英偉達最新的 GB300 芯片上跑了實測,結果發現,在固定 M=8192 的情況下,K 維度必須大于 3072,吞吐量才能勉強摸到 80%;直到 6144 才能徹底喂飽顯卡。
對比一下 512 和 6144,差不多十倍的差距,算力浪費的原因自然顯現。
所以,英偉達在博客中下了一個結論,"有時存儲是比 GPU 更大的瓶頸",這個論斷在算術強度過低這個具體語境下是基本成立的,因為你的矩陣形狀把 GPU 餓成了內存受限。
![]()
02
模型-硬件要協同設計的關鍵細則
在真實的 AI 商業落地中,性能永遠被三個維度同時鎖死,分別是:準確性、吞吐量和交互性。
準確性指的模型回答的對不對、準不準,這是模型的生命底線;吞吐量指的是服務器每秒能吐出多少 Token,代表系統能同時接待多少人,直接決定了運營成本;而交互性則是用戶的直觀體感,它分為“首字延遲”和“字間延遲”,代表用著卡不卡。
一般來說,這三者緊密聯系。然而在實際落地中,吞吐量和交互性天生相克。為了省錢追求高吞吐,系統就得把大量請求打包一起處理,這會導致用戶排隊、延遲拉長;而為了交互流暢,就要來一個處理一個,又會導致GPU嚴重閑置、成本飆升。二者此消彼長,在坐標軸上形成了一條無法跨越的帕累托曲線。
![]()
圖注:吞吐量和交互性的帕累托曲線,提高其中一個指標通常會降低另一個指標 面對“既要、又要、還要”的終極商業訴求,業界的破局點在于“一起變強”:讓這條曲線向外整體遷移。
想要達到這個目的就要從第一天開始就做好“模型-硬件協同設計”。
那具體有哪些設計的要點要特別呢?可以從以下四個方面考慮。
1.算準顯卡的性能邊界,對齊屋頂線模型:
必須精確計算邊界,看什么情況下顯卡是真的“計算能力跑滿”了(算力受限)。在設計模型層數和維度時,堅決避開那些會把顯卡逼進“等數據”狀態的結構。
2.迎合底層硬件的計算規格,對齊 Tile 尺寸:
迎合底層計算網格 128/256/512 的打包規格,不搞諸如“333”這種讓機器卡殼湊整的奇葩維度。
3.適配低精度計算:
針對新一代顯卡(如 Blackwell)內置的極速低精度通道(NVFP4),讓數據格式天生無合。
4.對齊網絡拓撲:
順著顯卡集群真實的網線分布,提前切好數據塊,絕不在幾萬張卡的通信中造堵車。
總之,只有讓模型的每一個維度數字、每一層結構,從頭到尾都嚴絲合縫地貼合 GPU 的硬件運行邏輯,才能徹底打破性能上的死結。讓系統反應更快、服務器能承載的用戶更多,同時模型的智商依然絕對在線!
![]()
03
架構師 7 條核心設計準則
為了把這件事說透,英偉達直接甩出了 7 條按“對吞吐量影響大小”排序的硬件友好設計準則。這簡直就是大模型時代的“設計施工規范”:
▎準則1:拒絕“畸形瘦高個”,參數矩陣越“方”越好
在總參數不變的前提下,絕不能把中間維度捏得太窄,比如前面提到的 512。
因為矩陣一旦太窄,計算量就太小,單位計算對應的數據搬運量大幅提升。這會直接導致顯卡掉進“內存搬運受限”的陷阱。論文實測證明,這種“畸形扁矩陣”會讓極品算力全程都在磨洋工。
▎準則2:模型維度嚴格對齊 GPU Tile 尺寸,模型維度必須是 128/256/512 的倍數
所有線性層的維度別拍腦袋定,必須認準 128 的倍數,追求極致就用 256 或 512。GPU 是按固定大小的“包裝箱”(Tile)干活的,你弄個零頭,GPU 依然會分配一整個計算周期去處理“空箱子”,吞吐曲線直接跌出鋸齒狀。測試顯示,只有嚴格對齊,吞吐量才能摸到最高峰值。
▎準則3:擁抱極限低精度,天生適配 NVFP4
新一代模型在設計層結構時,應該從一開始就把“支持 NVFP4(4位浮點量化)”考慮進去。
因為 Blackwell 架構的 GB300 顯卡自帶 NVFP4 專用計算通道,它通過一套雙重縮放機制,把 4 位低精度計算的誤差壓到了極低水平。在 GB300 上,NVFP4 的峰值算力是 FP8 的 3 倍、FP16 的 6 倍!
DeepSeek-R1 已經驗證過這一點,用 NVFP4 量化后,絕大多數測試成績與高精度版本差距不到 1%,甚至在部分數學和代碼任務上還出現了反超。這說明,極致壓縮不僅可行,而且是提速降本的必殺技。
▎準則4:同等參數量下,寬模型優先于深模型
固定參數下,要少疊幾層、把每一層做寬。因為模型太“深”就像漫長的接力賽,延遲高;但變“寬”反而像拓寬高速公路,不僅算術強度飆升,吞吐大,還延遲低。
▎準則5:搞 MoE 別瞎切,改用“專家分發(EP)”
在追求大吞吐、海量并發的批量服務場景下,面對龐大的 MoE 模型,不應單純依賴傳統張量并行(TP)。因為并發越高,跨卡聚合通信越擁堵,反而拖累性能。
優先選用擴展式專家并行(Wide-EP),把不同“專家”完整分給不同 GPU,單卡顯存壓力大幅降低。超大模型也可采用 EP×TP 混合并行,兼顧顯存容量與吞吐效率。
▎準則6:模型結構像“搭積木”一樣規整,跑滿流水線
模型每一層的設計模式要盡量統一、規整,不要搞得奇形怪狀。
規整的結構能完美適配分塊流水線并行(CPP),把幾十萬字的長文本輸入瞬間拆解,徹底消滅“長文卡頓”,把首字響應速度壓到極限。
▎準則7:分而治之,解綁 Attention 與 FFN
在要求極低延遲的交互場景下,不要把“注意力機制(Attention)”和“前饋網絡(FFN)”強行綁在同一種并行策略上。
它們倆的脾氣完全不同。FFN 適合分攤權重降內存,而 Attention 瓶頸在 KV 緩存。
這時候,應該給注意力機制開小灶,用一種叫 Helix 的并行架構去切割序列維度,并利用顯卡間極高帶寬的 NVLink 專線來掩蓋通信時間的開銷,從而把系統的交互延遲壓到極致。
另外,如果你不想手搓這些高階并行策略,英偉達已經把它們打包進了 TensorRT Model Optimizer 和 TensorRT-LLM 工具里。
說到底,誰應該特別關注這些準則呢?
最顯而易見的是模型架構師,下次開訓練新模型,先對照這 7 條把維度過一遍。這樣改一行代碼調整形狀的成本,比上線后苦哈哈地加卡便宜一萬倍。
然后對推理優化工程師來說,這是一本省錢指南。以后看到模型上線但 GPU 利用率低,先查 GEMM 的算術強度,別急著向領導申請擴容。
至于對采購決策者而言,更加需要慎重。買卡的 ROI 并不只看算力參數,它深度取決于你們家模型的“矩陣形狀”。形狀不對,你花幾千萬加卡,也僅僅是把那堵冰冷的“內存墻”往后推了微不足道的一點點。
降本增效不只是在咬牙簽下巨額算力訂單的那一刻,能在這些設計細節上做對決定,團隊就能在不知不覺中省下一筆天文數字。
https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/
上車,雷峰網帶你看遍全球 AI 頂會精華
可獨家暢覽:
專家演講PPT
大會報告全文
熱門論文解讀
學術新星訪談
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.