--- schemaVersion: 1 slug: gp-257-20260715-nvidia-hardware-friendly-llm-design ticketId: GP-257 lang: zh-tw title: LLM 不是參數塞滿就好：GPU 在等模型把磁磚鋪整齊 summary: 同樣的參數量，模型矩陣的長寬與層數會決定 GPU 是全速計算，還是忙著搬資料、浪費邊角磁磚。這篇用停車格解釋為何尺寸最好接近方形並對齊 128、256 或 512，以及為何較寬、較淺通常更合硬體胃口，但不能拿準確度祭天。 originalDate: 2026-07-10 translatedDate: 2026-07-15 source: NVIDIA Technical Blog sourceUrl: https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/ author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-257-20260715-nvidia-hardware-friendly-llm-design status: published replacementTicketId: null replacementUrl: null --- # LLM 不是參數塞滿就好：GPU 在等模型把磁磚鋪整齊 > **來源:** [NVIDIA Technical Blog](https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/) 兩個參數量差不多的模型站上同一台 GPU。照規格表看，速度應該也差不多；真正跑起來，一個順順吐出 token，另一個卻像下班時間卡在交流道。算力沒有少，工作也沒有變難，差別可能只藏在矩陣的長寬。 這就像一座只畫固定大小停車格的停車場。前一排剛好停滿，下一台車抵達時，管理員不能只補一格，而是得開放一整排；其餘空位照樣占地、照樣亮燈、照樣花錢。GPU 做大型矩陣乘法也有這種脾氣：模型只需要邊角的一小部分，硬體仍可能得啟動一整塊磁磚。 於是問題從「模型塞了多少參數」變成一場追查：**資料是不是搬太多、矩陣有沒有貼齊磁磚、工作又切成了多少份？** ![左右並排的 GPU 固定磁磚示意圖；左側資料完整填滿每塊綠色磁磚，右側最後一欄只有窄窄一條有效資料，其餘橘色區域仍需啟動運算](https://gu-log.vercel.app/_astro/gpu-tile-alignment.DJ2uuTSY_2qDUwt.webp) _左邊的矩陣尺寸剛好對齊固定磁磚；右邊只多出一小條有效資料，硬體卻仍得啟動整欄磁磚。橘色區域就是有成本、沒有有效結果的邊角空轉。_ ## 第一個嫌疑犯：閒著的算力、塞住的資料 追速度之前，得先看清楚哪一張成績單掉了。一個 AI 系統至少同時背著三項目標：回答準不準、整座資料中心每秒能產出多少 token，以及每位使用者感覺要等多久。第三項又可拆成第一個 token 多久出現，以及後續 token 之間隔多久。 在準確度固定時，吞吐量與互動速度彼此拉扯，工作負載還會偷偷更換瓶頸。長上下文、高吞吐量的服務可能把大部分時間花在注意力計算；低延遲服務則可能多付出跨卡通訊成本。假設注意力已占執行時間 77%，再怎麼精雕前饋網路，總體改善也很有限。安達爾定律在這裡像交通警察：先找到真正塞住的路口，別在隔壁空巷子拚命拓寬。 當塞車點落在線性層，才輪到矩陣形狀上場。Transformer 的線性層最後會落成矩陣乘法，也就是常見的 GEMM。矩陣的一邊來自同時處理的 token 數，另外兩邊主要受模型的隱藏維度與中間投影維度控制。這三邊共同決定 GPU 每搬一份資料，可以順手完成多少運算。 這個比例叫**算術強度**：每搬動一個位元組，能做多少次計算。比例低時，運算單元再強也只能等資料從記憶體送到門口，工作負載受記憶體頻寬限制；比例夠高，才輪到 GPU 的算力成為上限。 把矩陣想成鋪地的區域就容易理解。接近正方形時，橫向與直向都有足夠空間，搬進來的資料能反覆配對，產生更多結果。若矩陣又長又窄，其中一邊太短，資料才剛搬完，能做的配對就結束了，只好繼續搬下一批。即使一次處理很多 token，模型形狀仍可能限制資料重用。 GB300 的一組理論估算刻意把前饋層做成 `H′=512`、`H=8192`，輸入採 4 位元、輸出採 8 位元。即使 token 數增加，寫出結果仍比純數學運算更花時間；較小的 512 維讓整層卡在記憶體瓶頸。GB300 的 4 位元實測也呈現相同方向：投影或縮減維度太小，吞吐量會明顯下降。 第一個答案因此浮出來：在固定參數預算下，線性層的權重矩陣應盡量接近正方形，避免任一邊瘦到 GPU 還沒充分運算就得繼續搬資料。 ![相同資料量的兩種矩陣形狀；左側方正矩陣讓一份綠色資料沿橫向與縱向重複使用，右側狹長矩陣只有中央窄帶工作，其餘區域閒置並需要多次補送資料](https://gu-log.vercel.app/_astro/matrix-shape-data-reuse.DJPnUUsd_Zd9jGU.webp) _參數量可以相同，形狀卻改變資料的使用方式。左邊的方正矩陣讓搬進來的資料在更多方向重複參與運算；右邊的狹長矩陣很快用完其中一個方向，只好一批批繼續搬。_ > **Mogu 吐槽時間：** > > 「參數一樣多，速度應該差不多」就像「兩間倉庫坪數一樣，出貨速度應該差不多」。一間是方正賣場，另一間是狹長到像沒有盡頭的走廊；員工每天的運動量肯定很漂亮，包裹幾點出門就先別問了 (￣▽￣)／ --- ## 矩陣方正了，帳單卻從邊角冒出來 事情到這裡還沒結束。矩陣夠大、夠方正，尺寸若沒有對齊 GPU 真正執行工作的磁磚，停車場仍會為一台車點亮整排空位。 GPU 會把輸出矩陣切成小塊，交給串流多處理器計算。較新的硬體還能讓兩個相鄰處理器合作處理更大的磁磚，或讓一整群處理器組成叢集。合作提高了資料重用，卻也把有效磁磚放大了。 麻煩出在邊角。尺寸若不能整除磁磚，最後一塊即使只用到一小條，仍得啟動完整計算；補齊的空白不會產出有用結果，運算週期卻省不下來。GB300 的測量採用 256×128 基礎磁磚、雙處理器合作與 4×2 處理器叢集時，吞吐量會在相關維度對齊 256 或 512 的位置出現局部高點。 這次抓到的是邊角帳單。實用規則很直白：**模型維度至少用 128 的倍數；條件允許時，優先對齊 256 或 512。** 128 是較安全、可攜的底線，後兩者更容易吻合放大後的合作磁磚。 > **Mogu murmur：** > > GPU 不會因為邊角只用到一小部分，就把剩下的磁磚成本退回來。模型架構一旦定型，這些空白可能跟著每次推論一起重複出現；看似不起眼的尺寸選擇，最後會被部署規模放大。 --- ## 最誘人的捷徑：乾脆把模型做寬 既然又瘦又小的矩陣不討喜，一個很自然的念頭是：乾脆把模型做寬一點、層數減少一點。 在參數量固定時，較深的模型把工作分散到更多層，每層做較小的矩陣乘法，而且上一層完成後下一層才能接手。GPU 得反覆啟動許多較小的工作，資料重用較差，依序執行的路徑也更長。較寬的模型則把參數集中成較少、較大的矩陣乘法，更容易提高算術強度，也縮短必須一層一層走完的關鍵路徑。 從硬體這一側看，答案確實誘人：**較少次的大型運算，通常比許多次的小型運算更合 GPU 胃口**。這同時有利於整體吞吐量與單一請求的互動速度。 接著煞車立刻踩下來。深度也會影響模型的表達能力與準確度；把層數砍得太少，可能換到漂亮的硬體利用率，卻把模型能力一起丟掉。真正可用的不是「越寬越好」，而是一段寬深比例區間：先守住準確度，再在可行範圍內往較寬、較少層移動。 ![相同參數預算的寬淺與深窄模型對照；左側由少數大型綠色運算層組成短路徑，右側由許多小型橘色運算層堆成必須依序通過的長路徑](https://gu-log.vercel.app/_astro/wide-vs-deep-model.CimwjH0V_2nwGKe.webp) _固定參數預算下，左邊把工作集中成少數大型運算，路徑較短；右邊拆成許多小層，每一層都要等前一層完成。硬體偏愛左邊，但模型準確度仍決定能往寬淺方向走多遠。_ > **Mogu 歪樓一下：** > > 硬體友善不等於模型友善。為了讓 GPU 跑分漂亮就一路砍深度，像是為了提高餐廳翻桌率，最後只賣白開水：出餐確實快，客人也不必再來。準確度這條護欄不能省。 --- ## 形狀修好以後，部署才有資格放大它 寬深比例守住準確度後，還有一個槓桿可以減輕搬運：量化會減少記憶體流量，也讓矩陣核心一次處理更多數字。NVIDIA 的 4 位元格式為每 16 個值配置一個縮放係數，再做第二層校正；DeepSeek-R1 的七項基準測試中，多數結果與 8 位元版本相差約一分以內，部分項目持平或更高。 這也代表量化不能等到部署前才想。模型加入昂貴運算時，就要確認那些層能否有效使用低精度格式；否則磁磚鋪整齊了，貨車卻還是每趟超載。 然後才來到最容易讓人誤判的場面：把工作放上更多張 GPU。 高吞吐量的混合專家模型，可以把不同專家分散到多張 GPU。以 DeepSeek-R1 為例，每個 token 只啟動 256 個專家中的 8 個；卡數增加後，可用的記憶體頻寬與空間也增加，能容納更多注意力暫存資料和同時進來的請求。 卡數增加不會讓前面的問題蒸發，只會多出新的路口。token 必須在 GPU 之間搬動，熱門專家可能塞車。另一種做法是把長提示詞切成幾塊，依序送過不同 GPU 上的模型層；NVIDIA 的 256K 輸入案例縮短了第一個 token 的等待時間，但只要其中一站較慢，其他 GPU 就會排隊空等。 追查到這裡，最初幾個看似分散的線索終於接在一起：矩陣要讓資料值得搬、尺寸要貼齊磁磚，工作切到多張卡後還要分得平均。否則每增加一張 GPU，都可能只是替原本的浪費多開一條車道。 > **Mogu 溫馨提示：** > > [MP-296](https://gu-log.vercel.app/posts/mp-296-20260415-article-inferencex-v2-nvidia-blackwell-amd) 已整理過這套推論組合拳的效能與產業脈絡。[Mogu](https://gu-log.vercel.app/glossary#mogu) 的解讀是：平行化能把工作攤到更多 GPU，卻不會自動修好又瘦、又對不齊磁磚的矩陣；先把單次工作塑造成硬體容易消化的形狀，規模化才不會連浪費一起放大。 --- ## 結語 回頭看那兩個參數量差不多的模型，規格表其實只寫了倉庫的總坪數，沒寫貨架是不是狹長、邊角會浪費幾塊磁磚，也沒寫包裹得經過多少工作站。 **參數量回答模型裝了多少東西；形狀才回答 GPU 能不能準時把貨送出去。** 停車場最貴的，往往不是那台多出來的車，而是為它被迫點亮的一整排空位。