先算顯示記憶體，再挑硬體——順序反了就會買錯
很多團隊做本地大模型硬體規劃時，第一反應是「買哪張卡」。這個問題問得太早。卡只是顯示記憶體的載體，真正決定方案的是三個容量指標：
先把這三個數算出來，再去挑硬體，順序反了就會買錯。下面按三步走。
權重的占用最好算，也最常被忽略：
權重顯示記憶體 ≈ 參數量 × 每參數位元組數 × 1.1（量化中繼資料與對齊開銷）「每參數位元組數」由精度決定：FP16/BF16 是 2 位元組，INT8 是 1 位元組，INT4 是 0.5 位元組。乘 1.1 是替量化比例因子與分組資訊預留餘量。
| 模型規模 | FP16 / BF16 | INT8 | INT4 |
|---|---|---|---|
| 1.5B – 3B | 約 3.3GB – 6.6GB | 約 1.7GB – 3.3GB | 約 0.9GB – 1.7GB |
| 7B – 8B | 約 15.4GB – 17.6GB | 約 7.7GB – 8.8GB | 約 3.9GB – 4.4GB |
| 13B – 14B | 約 28.6GB – 30.8GB | 約 14.3GB – 15.4GB | 約 7.2GB – 7.7GB |
| 30B – 32B | 約 66GB – 70.4GB | 約 33GB – 35.2GB | 約 16.5GB – 17.6GB |
| 70B – 72B | 約 154GB – 158.4GB | 約 77GB – 79.2GB | 約 38.5GB – 39.6GB |
這張表能解釋一個常見現象：為什麼「7B 模型很輕量」和「7B 模型跑不動」同時成立。前者講的是權重，後者講的是權重加上 32K 上下文、多路併發與推論框架本身的花費。
權重是固定成本，KV cache 是隨上下文長度線性成長的變動成本：
KV cache ≈ 2（K 與 V）× 層數 × 注意力頭數 × 頭維度 × 上下文長度 × 每元素位元組數 × 併發數以主流稠密架構做量級估算：把上下文從 4K 拉到 32K，KV cache 會漲到 8 倍；再疊加多路併發，顯示記憶體占用可能直接翻數倍。這就是為什麼「換個大上下文試試」經常是顯示記憶體事故的起點。
實務上有三個降記憶體的手段可以疊加使用：
實際部署時，權重 + KV cache 之外還有三塊常被低估的開銷：
穩妥做法是把目標占用控制在實體顯示記憶體的 85% 以內。把 24GB 的卡塞到 23GB 的方案，壓測時往往能跑，真實併發下會 OOM。
把上面的估算套到實際採購上，可以分成三檔。價格與具體型號隨市場變動，這裡只給容量口徑。
| 檔位 | 典型場景 | 顯示記憶體 | 系統記憶體 | 可跑的模型級別 |
|---|---|---|---|---|
| 驗證試用 | 內測、提示詞除錯、單人試用 | 16–24GB | 32–64GB | 7B–8B 的 INT4 / INT8，短上下文 |
| 部門落地 | 一個部門日常使用，數十人併發 | 48–80GB（或 2×24GB） | 128GB 起 | 13B–32B 的 INT4/INT8，中等上下文 |
| 生產級 | 跨部門服務，需要高可用與稽核 | 80GB × 2 起（多卡） | 256GB 起 | 70B 級 INT4，或 32B 的多執行個體高併發 |
選型邏輯是倒著推：先確定業務能接受的模型規模與上下文長度 → 用上面的公式算出顯示記憶體 → 再選卡，而不是先選卡再想能跑什麼。
私有化部署的整體路線（資料邊界、網路隔離、驗收標準）見《AI 私有化部署方案怎麼選》。
| 做法 | 怎麼做到的 | 代價 |
|---|---|---|
| 量化 | 權重壓到 INT8 / INT4，必要時 KV cache 也量化 | 精度損失，長文本與複雜推理任務下降更明顯 |
| 多卡切分 | 模型按層切到多張卡，或用張量並行 | 卡間通訊開銷上升，對互連頻寬敏感，延遲增加 |
| CPU 卸載 | 放不下的層放到系統記憶體，依需求換入 | PCIe 頻寬遠低於顯示記憶體頻寬，速度可能掉一個數量級 |
順序建議是：先量化，再加卡，最後才考慮卸載。卸載的定位是「讓小模型能啟動」的兜底手段，不是生產環境的吞吐量方案——系統記憶體到顯示記憶體的 PCIe 傳輸通常是 10–30GB/s 量級，與顯示記憶體內部數百 GB/s 的頻寬差著一到兩個數量級。
推論服務本身的部署方式（服務化介面、併發控制、驗證授權）可參考《AI Agent 與 IM 平台打通：接入架構》。
參數量只決定權重占用。實際需求還要加 KV cache、框架開銷與激活值，尤其長上下文場景，這兩項可能和權重同一量級。先算權重，再加餘量，別拿參數量直接當顯示記憶體需求。
量化損失是任務相關的。簡單問答、分類、摘要類任務上差異往往不明顯；但多步推理、程式碼生成、長鏈條工具呼叫上會明顯退化。降配前用自己的真實任務集做一輪比較，而不是看公開排行榜。
跨卡通訊是真實成本。層切分對互連頻寬敏感，PCIe 直連的多卡方案在小模型場景往往不如單張大顯示記憶體卡簡單可靠。判斷標準是「單次請求的瓶頸在算還是在搬資料」，不是卡的數量。
| # | 驗收項 | 判據 |
|---|---|---|
| 1 | 目標模型與精度已確定 | 明確到具體模型與量化等級，不留「先跑起來再說」 |
| 2 | 權重占用已計算 | 參數量 × 精度位元組 × 1.1 有書面數字 |
| 3 | KV cache 已按真實上下文長度估算 | 用目標上下文上限算，不是預設值 |
| 4 | 併發數已確認 | 同時在線人數 ÷ 平均處理時長 = 需要的併發執行個體數 |
| 5 | 顯示記憶體占用率留有餘量 | 峰值占用 ≤ 實體顯示記憶體的 85% |
| 6 | 系統記憶體與磁碟按峰值規劃 | 含模型切換、量化轉換、暫存檔案的餘量 |
| 7 | 做過真實任務集比較 | 量化前後在自有任務上跑過一輪，差異可接受 |
清單裡第 4 條最容易被跳過，但它才是決定「要不要多買一張卡」的關鍵：併發不是人數，是同時請求數。10 個人輪流問問題和 10 個人同時問問題，對顯示記憶體的要求完全不同。
本地大模型的硬體規劃不需要複雜，但它有明確的推導鏈：業務規模 → 模型規模 → 精度選擇 → 權重占用 → 加 KV cache → 加執行階段餘量 → 選卡。鏈條上任何一環跳過，都會變成「買回來發現裝不下」或者「裝得下但一上併發就崩」。
把參數估算了再採購，把真實任務集驗證過再上線，這兩件事做完，硬體選型的絕大部分風險就消掉了。剩下的才是具體型號與價格層面的選擇。