買 GPU 前先算 VRAM：2026 LLM 權重、KV Cache 與顯存需求完整指南

大多數人挑 GPU 時看的是 CUDA 核心數、TFLOPS、時脈。但對 LLM 部署來說， 這些都排不到第一順位。VRAM 不夠不會讓模型跑得慢，是根本載不進去。

麻煩的是這一年半模型架構變化很大，網路上多數教學用的公式已經失準， 有些情況會算出差好幾倍的數字。

本文分成兩半：上半部直接給結果——各容量級距能跑什麼、跑多快、 能服務幾個人、多少錢；下半部攤開估算方法，給想自行驗算的人。 能標出誤差範圍的地方我都會標。

各容量級距大致能做什麼

先看粗略的對照：

這張表只是起點，實際數字取決於模型多大、用什麼精度、context 開多長。 下面逐項展開。

先看結果：一張 96 GiB 卡在 256K context 下能跑什麼

從一個具體案例開始。把估算方法（下半部會完整展開）套用到 RTX PRO 6000 Blackwell（96 GiB）：

單位為 GiB。佔比 ≤ 85% 者在此估算下有正式部署的餘裕；超過 100% 需雙卡。

兩個地方值得看。

Llama-4-Scout 的 KV cache 高達 48 GiB，因為它用標準 GQA、對 KV 沒有壓縮。 同樣是百億級模型，注意力架構的差異讓 KV 開銷差了將近一個數量級 （各架構怎麼算，見下半部〈KV cache〉一節）。

再來是 96 GiB 主要買到的東西：精度空間。Qwen3.6-35B-A3B 在 Q4 下 32GB 卡 就跑得動；96 GiB 讓你直接用官方 BF16 權重，不必先回答「這個任務能不能承受量化」 （量化什麼時候會傷、傷多少，見下半部〈精度怎麼選〉）。

（RTX PRO 6000 有 Workstation 與 Max-Q 兩個版本，差異見 這篇比較； 與消費旗艦 RTX 5090 的取捨見 RTX PRO 6000 vs RTX 5090； 規格與參考價格見商城。）

跑多快：第二個維度是頻寬

生成每個 token 都必須把權重從顯存讀進計算單元，所以速度上限是：

理論最大 tok/s ≈ 記憶體頻寬 ÷ 權重大小

對 dense 模型，這個估算相當可用。兩個獨立來源驗算：

兩者都落在 60–70%，所以 dense 模型可粗估為 (頻寬 ÷ 權重) × 0.65。這條捷徑對 MoE 模型（Mixture of Experts， 每個 token 只動用部分參數）不適用——理論值與實測落差很大， 只能看實測，原因見下半部〈MoE〉一節。

DGX Spark：128GB，但頻寬只有六分之一

NVIDIA DGX Spark（及 ASUS Ascent GX10、MSI EdgeXpert 等同平台機種）有 128GB 統一記憶體，容量比 RTX PRO 6000 的 96GB 大，台灣售價 NT$175,900 起。

但它用 LPDDR5x，頻寬只有 273 GB/s，約為 GDDR7 顯卡的六分之一。

dense 大模型的差距更明顯：LMSYS 實測 Llama 3.1 70B（FP8）在 DGX Spark 上是 2.7 tok/s。這個速度拿來互動式聊天很痛苦，回答稍長就要等上一段時間， 但用來做模型驗證或批次工作仍然有價值。LMSYS 也提到該平台軟體支援還在早期， 數據可能隨更新改善。

幾個人同時用

96 GiB 案例表假設的是單一使用者。企業部署幾乎不會是這樣， 所以要把併發加進來。

關鍵在於 KV cache 是 context 長度 × 併發數的乘積。 vLLM 官方原始碼裡 就是這樣算的：

GPU KV cache size（tokens）= 最大併發數 × max_model_len

反過來就是：

最大併發數 ≈ KV cache 可用容量 ÷ 每個請求的 context 長度

vLLM 啟動時會印出 GPU KV cache size: X tokens 這行 log， 你可以直接拿它除以你的 context 設定來驗算。

依場景估算：一張 96 GiB 卡能服務多少人

單位 GiB。併發上限 = (96 × 85% − 權重) ÷ 每人 KV， 指的是同時在處理中的請求數，不是總使用者數（見下）。

併發數不等於使用者數

上表的「併發」指同一瞬間正在生成回應的請求數。實際使用者數會更多， 因為多數人多數時間在讀回應、在打字、在做別的事。

不過**「總人數 ÷ 併發數」的比例沒有可靠的公開統計**， 各家顧問文章給的經驗值差異很大。合理做法是先觀察自己的使用曲線， 或直接用尖峰併發數當規劃基準。

參考兩個有具體數字的部署案例：

（皆為供應商官方文件，非獨立第三方驗證。）

實測：併發之下實際跑多快

前面都是容量推算。實際吞吐量要看實測。

以下為第三方 benchmark， RTX PRO 6000 單卡、vLLM、50 個併發請求、 max-model-len=4096、輸入 100 / 輸出 600 tokens：

「每人平均」為總吞吐量 ÷ 50，原始資料未直接提供。同批測試的延遲數據： Llama-3.1-8B 的 TTFT 中位數 333ms、TPOT 17.66ms； DeepSeek-R1-Qwen-32B 的 TTFT 996ms、TPOT 58.71ms（換算約 17 tok/s／人）。

一個值得注意的第三方數據： 在 300 併發的壓力測試下，RTX PRO 6000 的總吞吐量勝過 A100-80GB 與 H100——

單位 tok/s，同框架同模型。這反映的是 Blackwell 世代的架構優勢與 96GB 帶來的 KV cache 空間，但僅限單卡工作負載——下一節說明多卡的狀況。

一張還是兩張：沒有 NVLink 是真的有差

如果單卡裝不下（例如 Qwen3.5-122B 官方 FP8 需要 122.5 GiB）， 兩張 RTX PRO 6000 是自然的下一步。但要先知道一個限制： RTX PRO 6000 沒有 NVLink，卡間通訊走 PCIe。

Tensor parallel 需要每一層都做 all-reduce 同步，對卡間頻寬很敏感。 PCIe Gen5 約 64 GB/s 單向，NVLink 則是數百 GB/s 等級。 NVIDIA 開發者論壇的雙卡實測 結論是「把 KV cache 資料搬過 PCIe，開銷遠大於留在同一張卡上」， 並建議多卡系統使用 NVLink 等高頻寬互連。 另一份第三方評測顯示 卡數越多差距越大：4 卡 TP 跑 Qwen3-480B 時，H100 的吞吐量高出約 31%； 8 卡 TP 跑 GLM-4.6-FP8 時，H100 約 3 倍、H200 約 4 倍。

每 GB VRAM 多少錢？

價格取自原價屋線上估價單（含稅），擷取日 2026-07-15，每級距取當日最低價：

那為什麼不買六張 5060 Ti 湊 96GB？

模型必須透過 tensor parallel、pipeline parallel 或 layer split 分散到多張卡， 卡與卡之間要傳遞 activation 或執行 collective communication。 沒有高速互連時，PCIe 拓撲與通訊成本可能成為瓶頸（上一節的問題， 卡數更多、更嚴重）。還要有六個可用 PCIe 插槽 （消費級主機板通常只有兩三個）、更大的電源與散熱。

倒也不是絕對不能用。對特定 MoE 或 pipeline 工作負載，多張小卡仍可能有成本優勢， 差別在部署複雜度、主機平台與框架限制都更高。

決策流程

flowchart TD
  Start([主要用途?]) --> A{Agent / 多步推理<br/>/ 程式碼?}
  A -->|是| B[優先用官方原生<br/>或官方量化版<br/>並做任務級評測]
  A -->|否，對話/摘要/RAG| C[可優先嘗試<br/>成熟 INT4 / GGUF]

  C --> C1{模型規模?}
  C1 -->|≦ 35B| C2[32 GiB 級]:::recommend
  C1 -->|35B 以上| C3[48–72 GiB 級]:::recommend

  B --> B1{模型規模?}
  B1 -->|26–36B| D{需要即時互動?}
  D -->|是| B2[96 GiB 單卡]:::recommend
  D -->|否，批次/驗證為主| E[可考慮 128 GiB<br/>統一記憶體]:::recommend
  B1 -->|80–122B| B3[96 GiB 單卡<br/>部分需量化版]:::recommend
  B1 -->|更大或高併發| B4[96 GiB × 2]:::recommend

  classDef recommend fill:#0D9488,stroke:#0F766E,color:#FFFFFF
  classDef warn fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D

在挑硬體之前：先回答這五題

前面算的每個數字，都建立在你已經知道自己要跑什麼、給誰用。實際上這幾題 才是規格的來源：

這幾題答不出來的時候，通常缺的是應用場景而非 GPU 知識。硬扛著先決定硬體， 最常見的下場是買了一張規格挑不出毛病的卡，半年後還在閒置。

實務上，把一張 GPU 變成「業務單位每天在用的東西」，採購通常是最快的一段。 花時間的是盤點哪些流程真的適合地端 LLM、判斷該用 RAG 還是微調、 接進現有系統與權限稽核、以及讓使用者真的願意用。

合理的順序是：

業務場景 → 模型與任務要求 → 精度與延遲門檻 → 最後才是硬體

多數團隊反過來做，因為硬體是最具體、最容易先動手的那一段。

如果你正在被要求「評估地端 AI」

荔枝智慧是企業 AI 導入團隊。 我們能幫上忙的是前面那幾步：盤點適合的應用場景、 評估 RAG／微調／Agent 各自的可行性與成本、估算導入後的效益， 然後才回推需要多大的硬體。

這樣算出來的規格，你在內部提案時也比較好解釋為什麼是這個數字。

聊聊你的場景

---

已經確定要買什麼？ 商城列有各卡的規格與參考價格， 可以先對照需求。顯示卡價格浮動大，實際報價與貨況請 來信確認。 還在 32GB 與 96GB 之間猶豫，見 RTX PRO 6000 vs RTX 5090； 版本選擇可參考 RTX PRO 6000 Workstation vs Max-Q 比較。

下半部：這些數字怎麼算出來的

前面每張表都來自同一套估算方法。想自行驗算、或要評估表上沒有的 模型與 context 組合，以下把方法完整攤開。總公式只有一條：

總需求 = 模型權重 + KV cache／狀態 + 執行期開銷

第一塊：權重

權重 = 參數量 × 每參數位元組數

「4-bit 權重」不代表整個模型剛好每參數 4 bits

llama.cpp 官方文件用 Llama-3.1-8B 實測 GGUF K-quants 的平均每權重位元數：

差異來自 scale 與分組資訊，以及部分層（常見於 embedding 與 output head） 保留較高精度。AWQ、GPTQ、MXFP4、NVFP4、NF4 各有各的封裝方式，數字不能互相套用， 但方向一致：整個 checkpoint 通常大於「參數量 ÷ 2」。

第二塊：KV cache（以及那條你可能算錯的公式）

Transformer 生成每個 token 時需要回顧前面所有 token 的 Key 與 Value 向量， 這些向量快取在 VRAM 裡，就是 KV cache。

流傳最廣的公式是：

KV cache = 2 × 層數 × KV head 數 × head 維度 × token 數 × 並發數 × 每元素 bytes

這條公式沒錯，但只對標準 GQA／MHA 架構成立。

逐項確認：開頭的 2 是 K 和 V 兩份；用 KV head 數而非 attention head 數 （GQA 讓多個 query head 共用一組 KV head）；其餘各項都與快取大小線性相關。

問題是 2025–2026 年發布的多個主流開放權重模型，已經不用標準 GQA 了。

公式的適用範圍：四種注意力架構

實際差距：

DeepSeek 系 MLA 的基礎估算式：

≈ (kv_lora_rank + qk_rope_head_dim) × token 數 × 2 bytes × 層數 × 並發數

因為 MLA 不是每個 head 各存 K/V，而是共用一組低秩壓縮向量。 此式假設 latent state 以 BF16／FP16 儲存；不同實作在 rope state、 量化 KV、對齊與 block 配置上可能有額外開銷，且不是所有標榜 MLA 的模型都完全相同。

Sliding window 要拆兩段算：滑窗層封頂在 window 大小不再成長， 只有 full attention 層隨 context 線性增加。以 gpt-oss-120b 為例，36 層中 18 層滑窗、18 層全域。

第三塊：執行期開銷（沒有固定值）

CUDA context、activation buffer、CUDA graph 捕獲、workspace 張量、記憶體碎片， 這些沒有一個固定數字可以套。實際差異取決於：

• 框架（vLLM／SGLang／Transformers／llama.cpp）
• CUDA Graph 捕獲的 batch size、chunked prefill 設定
• 多模態 encoder（Qwen3.6、Qwen3.5、Gemma 4 都含視覺編碼器）
• tensor parallel 切分、量化 kernel、最大同時序列數

與其加一個固定數字再加一層餘裕（容易重複計算），本文只用一條原則：

規劃用量 = 權重 + KV cache／固定狀態
建議規劃用量 ≤ 實體 VRAM 的 85%

多模態、長 context prefill、大 CUDA Graph 或多使用者情境，要留更多。 正式採購前用你指定的框架實際啟動驗證一次，這步不能省。

MoE：容量與運算量脫鉤

2026 年架構上最明顯的變化是 MoE 普及：

容量這邊有個前提要講清楚：只有在追求 GPU-only、低延遲推論時， MoE 的所有專家權重才通常都得在 GPU 記憶體中，容量由總參數決定。 部分框架（如 llama.cpp）可以把未使用的專家 offload 到系統記憶體， 架構層面沒有禁止，速度會掉。

精度怎麼選：量化到底傷害什麼

llama.cpp 官方 PR 的 wikitext perplexity 實測（LLaMA-1 7B）：

看起來 Q4_K_M 幾乎無損。但 perplexity 會低估特定任務上的傷害：

一篇針對量化與數學推理的研究（arXiv:2501.03035）發現，特定 Llama-3 模型在 AWQ／GPTQ 下跑 MATH benchmark，準確率平均下降 11.31%、最高 32.39%， 集中在數值計算與多步推理規劃。另一篇（arXiv:2504.04823）指出影響高度取決於 模型、量化方法與任務：部分模型在 4-bit 下相當穩健，8-bit 則平均只掉約 0.8%。

算太剛好的代價：offload 可能出現斷崖

llama.cpp 官方 README 有一組示範數據，用 LLaMA 7B（Q4_0，共 35 層） 測不同的 GPU 層數：

在這組硬體與版本下，只剩一層留在 CPU，速度就從 131.66 掉到 71.76 tok/s。 原因可能包含 CPU 端計算、CPU／GPU 同步與資料傳輸邊界。實際下降幅度會因 CPU、PCIe、模型與框架而異，這組數字是舊式 LLaMA 7B 的示範， 換個模型不會是同樣倍率。

VRAM 不足時效能不是線性下降，會出現斷崖。規劃時留餘裕，不要算到剛好。 這也是前面 96 GiB 案例表用「合計 ≤ 85%」當門檻的原因。

四個步驟總結

1. 定精度策略：Agent／推理／Coding → 優先官方原生或官方量化版，INT4 需任務驗證； 對話／RAG → 成熟 INT4 通常可行
2. 算容量：權重（實際 checkpoint 大小優先）＋ KV cache（依架構用對公式）
3. 留餘裕：合計 ≤ 實體 VRAM 的 85%，並用指定框架實際啟動驗證
4. 確認速度：dense 用 (頻寬 ÷ 權重) × 0.65；MoE 只看實測

需要對照實機規格？ 商城列有各卡的規格與參考價格； 顯示卡價格浮動大，實際報價與貨況請來信確認。32GB 消費旗艦與 96GB 工作站卡的取捨見 RTX PRO 6000 vs RTX 5090， RTX PRO 6000 兩個版本的差異見 Workstation vs Max-Q 比較。

想詢價、對估算方法有疑問、或想從應用場景開始盤點： 來信聊聊

資料來源：

• 模型 config 與參數量：HuggingFace 各模型 config.json 與 safetensors API， 擷取日 2026-07-21（Llama 系列官方 repo 需授權，架構欄位取自標註 base_model 的公開鏡像）
• 量化 bpw、perplexity、offload 示範數據：llama.cpp 官方文件 （quantize README、llama-bench README、k-quants PR #1684）
• 量化對推理能力的影響：arXiv:2501.03035、 arXiv:2504.04823
• KV cache 與併發的關係：vLLM 官方原始碼、 PagedAttention 論文（SOSP 2023）
• GPU 頻寬：NVIDIA 官方產品頁（消費卡頻寬未於官方頁列出，取自公開規格彙整）
• DGX Spark 與 RTX PRO 6000 實測：LMSYS〈NVIDIA DGX Spark In-Depth Review〉 （第三方評測，非 NVIDIA 官方 benchmark）
• RTX PRO 6000 併發吞吐量：Database Mart vLLM benchmark （第三方評測，測試條件見文中說明）
• 雙卡 tensor parallel：NVIDIA 開發者論壇、 CloudRift 多卡評測
• 延遲門檻與部署案例：VMware LLM Inference Sizing Guide、 Lenovo LLM Sizing Guide、 Baseten（供應商官方文件）
• 台灣售價：原價屋線上估價單（含稅），擷取日 2026-07-15

本文 VRAM 數字為依公式計算的估算值，實際用量會因框架、批次策略、量化實作與 版本差異而不同。正式採購前請以指定框架實測驗證。原價屋價格每日變動，請重新確認。