<mark id="oztn4"></mark>
0
作者丨高允毅
編輯丨馬曉寧
上個月，一位做推薦系統的朋友找我大吐苦水。團隊花了大幾百萬，剛咬牙把模型搬上了 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 條按“對吞吐量影響大小”排序的硬件友好設計準則。這簡直就是大模型時代的“設計施工規范”：
▎準則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
大會報告全文
熱門論文解讀
學術新星訪談
掃描上方二維碼
或點擊「閱讀原文」關注專區。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
