VRAM 用量計算

每一個「我的卡跑不跑得動」的問題都是算術，不是玄學。VRAM 總量＝權重＋KV 快取＋一塊固定的啟動值與引擎開銷。只要你會把參數乘上位元數，就能在花任何錢之前算好機器。這一頁提供公式、現成表格，以及可以套用到任何顯示卡的 16 GB 試算。

公式

VRAM 總量   = 權重 + KV 快取 + 開銷
權重 (GB)   = 參數量 (B) × 每權重位元數 ÷ 8
KV 快取     = 每 token 位元組數 × 上下文長度   （見 [KV 快取](/guide/kv-cache)）
開銷        ≈ 1–2 GB（啟動值、驅動環境、緩衝區、碎片）

常見 GGUF 量化的每權重有效位元數：Q4_K_M ≈ 4.8、Q5_K_M ≈ 5.7、Q6_K ≈ 6.6、Q8_0 ≈ 8.5。參數量乘上它、除以 8，就與磁碟上的檔案大小相差幾個百分點內。

值得背下來的經驗法則，以每十億參數的 GB 計：

• Q4_K_M ≈ 0.6 GB——日常主力
• Q5_K_M ≈ 0.7 GB
• Q6_K ≈ 0.8 GB——對多數人近乎無損
• Q8_0 ≈ 1.1 GB——透明，成本約為 Q4 兩倍
• fp16/bf16 = 2.0 GB——訓練與認真微調的地盤

實例

KV 快取大小取決於架構。現代 GQA 模型在 8B–32B 級、fp16 KV 下，大約每 token 128–256 KB；70B 級約 320 KB。精確公式在 KV 快取；這裡直接加進來。開銷每列以 1.5 GB 預算。

Q4_K_M（每權重約 4.8 位元）：

Q6_K（每權重約 6.6 位元）：

兩個值得內化的模式。Q6_K 比 Q4_K_M 貴約 35–40%——常常就是一個 GPU 等級與下一個等級的差別。而 32k 上下文的 KV 不是捨入誤差：在小模型上它足以與權重本身匹敵。舊式 MHA 設計（Llama-2 時代）的 KV 快取大 4–8 倍，這就是為什麼 32k 上下文以前需要特殊硬體，而 GQA 模型不用。

載入時 OOM vs 生成中 OOM

• 載入時：光權重就超過可用 VRAM。引擎拒絕啟動，或把層換到 CPU 上龜行。誠實、立即、好診斷。
• 生成中：權重裝得下，但 KV 快取逐 token 增長。全新連線一切正常；四十輪之後、在一次 RAG 傾印或貼上檔案後，快取吃光你的餘裕、程序在回答到一半時死亡。這是陰險的那種——永遠按你實際會到達的上下文來估算，而不是第一個提示詞。

親眼看它發生：

watch -n1 nvidia-smi --query-gpu=memory.used,memory.total --format=csv

試算表：16 GB 示範

1. 可用預算：16 GB × 0.85 ≈ 13.6 GB。桌面、瀏覽器與驅動已占走 0.5–1 GB；10–20% 餘裕是規則，不是奢求。
2. 夢想：32B Q4_K_M——光權重就 19.2 GB。直接出局。
3. 現實：14B Q4_K_M、8k 上下文：8.4 + 1.6 + 1.5 = 11.5 GB。裝得下還有約 15% 餘裕。出貨。
4. 現在你想要 32k 上下文：8.4 + 6.4 + 1.5 = 16.3 GB。爆預算。
5. 三個解法——單選或併用：
   • 把 KV 快取量化到 q8_0：6.4 → 3.2 GB，總計 13.1 GB。過關。
   • 權重降到 Q4_K_S 或 IQ4_XS，再省約 0.5–1 GB。
   • 改用 8B Q6_K：6.6 + 4.2 + 1.5 = 12.3 GB，寬裕。

同樣五步適用於 8 GB 卡、24 GB 卡或 48 GB 雙卡機。編預算、做夢、相減、調整。

永遠保留餘裕

引擎會為每個批次插槽配置暫存緩衝區、長時間運作的伺服器會累積碎片、並行則讓每個活躍請求的 KV 倍增。在一次性基準測試中「剛好塞下」的設定，上了正式環境就會 OOM。留 10–20% 空閒是持續運轉的稅。各等級顯示卡實際裝得下什麼，見 GPU 等級；量化位元數為何是這些數字，見 量化。

相關章節：量化 · KV 快取 ·
GPU 等級