LLM VRAM 需求：2026 完整對照表（涵蓋所有模型與量化等級）

LLM VRAM 需求：2026 完整對照表（涵蓋所有模型與量化等級）

有一個數字總是讓人措手不及：DeepSeek-V3.2 擁有 6710 億個參數，但在處理任何給定 token 時，只有 370 億個參數會被激活。那麼，它實際上需要多少 VRAM？答案是全部 6710 億個參數對應的記憶體，在 Q4 量化下約為 382 GB。LLM 的 VRAM 需求很少符合直覺，而「活躍參數」與「必須載入的參數」之間的差距，正是導致硬體預算爆表的關鍵所在。本指南將提供一份完整對照表（涵蓋每個主要開源模型、每個量化等級、所需的 GB 數以及運行該模型所需的 GPU），並附上讓你在約十秒內自行估算任何模型需求的公式。

重點摘要

• 權重所需的 VRAM ≈ 參數量 × 每個參數的位元組數：FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57。在此基礎上加上 KV cache 以及約 15-20% 的額外開銷。
• 混合專家模型（MoE）（如 DeepSeek、GLM-5.2、Qwen3-235B）必須將所有專家載入 VRAM。「活躍參數」帶來的是速度優勢，而非記憶體節省。
• KV cache 是隱藏成本。Llama 3.3 70B 在 8K 上下文長度下需要約 2.6 GB 的 cache，而在 128K 下則需約 41 GB，這還是在權重之外的額外需求。
• Q4_K_M 是合理的預設選擇：它能提供接近完整的品質，而記憶體佔用僅約為 FP16 的四分之一。
• 像 Gemma 4 這樣的 12B 模型可以在 8 GB 顯卡的 Q4 模式下運行。70B 的密集模型需要約 40 GB。而擁有 6710 億參數的前沿 MoE 模型則需要小型伺服器級別的硬體。

各模型 LLM VRAM 需求：完整對照表

簡短的回答是：在 Q4_K_M 量化下，小型模型（低於 14B）適合消費級 8-12 GB 顯卡，中型模型（24-32B）需要 16-24 GB，70B 的密集模型需要約 40 GB，而前沿的 MoE 模型由於必須駐留所有專家，記憶體需求會躍升至數百 GB。以下是完整的概覽。所有數值僅針對權重記憶體，根據每個模型的參數量計算得出，並與 Meta AI、Qwen 和 Hugging Face 的官方模型卡片進行交叉驗證。

從這張表中可以讀出兩件事。首先，量化是你手中最大的槓桿：從 FP16 降到 Q4 可以將記憶體佔用減少約 4 倍，而品質損失幾乎難以察覺。其次，MoE 行的數據看起來很驚人，事實也確實如此。Qwen3-30B-A3B 每個 token 僅激活 30 億個參數，因此它的運行速度如同小型模型，但你仍然需要在記憶體中保留全部 300 億個參數，以便隨時調用所有專家。想要了解這些數字背後的詳細模型分析嗎？我們的 Gemma 4 12B 深度解析 和 2026 年最佳開源 LLM 汇总 涵蓋了基準測試和授權資訊。

VRAM 計算公式：自行估算任何模型

要估算任何模型的大小，只需將其參數量乘以你所選量化等級的「每個參數位元組數」，然後加上一些 KV cache 和運行時開銷即可。就是這麼簡單。權重是主導因素，其算術足夠簡單，甚至在餐巾紙背面就能完成計算。

權重的核心方程式：

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

你需要的每位權重位元數值（這些是 GGUF k-quant 檔案的有效比率，除了標稱位元深度外，還包含少量的區塊後設資料）：

實際範例，Gemma 4 12B 在 Q4_K_M 下：11.95 × 4.5 ÷ 8 = 約 6.7 GB 用於權重。這與官方模型卡片引用的約 6.6 GB 相符，也解釋了為什麼它能放入 8 GB 顯卡並留有適度上下文的空間。對 70B 模型在 Q4 下進行同樣的計算，你會得到 70 × 4.5 ÷ 8 = 39.4 GB，這就是為什麼「你需要兩張 24 GB 顯卡或一張 48 GB 顯卡來運行 70B 模型」成為人人重複經驗法則的原因。

完整的情況需要加上另外兩項：總 VRAM ≈ 權重 + KV cache + ~15-20% 開銷。開銷涵蓋激活緩衝區、CUDA 上下文和記憶體碎片，而且你的 GPU 也會為驅動程式保留約半 GB 的空間，所以永遠不要計劃使用標示 VRAM 的 100%。

為什麼 KV Cache 是讓你吃虧的關鍵數字

KV cache 儲存上下文中每個已存在 token 的注意力鍵（keys）和值（values），並且隨著上下文長度線性增長。在短提示中，它微不足道。但當推向長上下文時，它可能媲美甚至超過權重本身。這是導致一個「應該能裝下」的模型在生成中途拋出記憶體不足（OOM）錯誤的最常見原因。

每個 token 的公式：

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

以 Llama 3.3 70B 為例：80 層，8 個 KV 頭，頭維度 128，因此 kv_dim 為 1024。在 FP16 下，每個 token 為 80 × 2 × 1024 × 2 = 327,680 位元組，約 0.31 MB。乘以上下文長度，結果不言而喻：在 8K tokens 時，cache 約為 2.6 GB；在 32K 時約為 10 GB；而在 128K 時則膨脹至約 41 GB。最後這個數字是在 40 GB 權重之上的額外需求，所以一旦填滿視窗，一個「40 GB 模型」就會悄悄變成 80 GB 的問題。

兩個實用的解決方案。分組查詢注意力（Grouped-query attention，所有近期模型均採用）已經大幅削減了相比舊式多頭設計的 kv_dim，因此現代模型在這方面比 Llama 2 友善得多。此外，大多數推理引擎可以將 KV cache 量化為 8-bit 或 4-bit，以微小的品質代價將其大小減半或降至四分之一。如果你在生產環境中服務長上下文，vLLM 與 SGLang 比較 涵蓋了哪個後端透過分頁注意力最有效地管理此記憶體。

MoE 模型：為什麼「活躍參數」無法節省 VRAM

這是讓人花費最多金錢的陷阱。像 DeepSeek-V3.2（總計 6710 億，活躍 370 億，共享 V3 架構）或 GLM-5.2（總計 7440 億，活躍 400 億）這樣的混合專家模型，會將每個 token 路由通過其專家中的一小部分。行銷宣傳強調活躍數字，因為它描述了速度：每個 token 只需支付相當於 370 億參數的計算成本，因此對於該模型規模而言，推理速度很快。但是，每個專家都必須駐留在記憶體中，隨時準備被選中，這意味著你的 VRAM 預算是由總參數量決定的，而不是活躍參數量。

因此，對上述表格的誠實解讀是：GLM-5.2 以 400 億參數模型的速度運行，但佔用了 7440 億參數模型的記憶體。這就是為什麼這些前沿開源模型需要 8-GPU 伺服器或大型統一記憶體機器，即使單次前向傳遞的成本很低。Qwen3-235B-A22B 也是同樣的模式，只是規模較小，每個 token 速度快，但託管沉重。

MoE 的優勢體現在統一記憶體硬體上。配備 512 GB 統一記憶體的 Mac Studio 可以容納 Q4 量化的 6710 億參數模型，並仍以可用的速度運行，這正是因為只有 370 億參數被激活，所以每個 token 的記憶體頻寬需求保持合理。如果你剛開始在本地運行這些模型，在購買硬體之前，請先參考我們的 本地 LLM 設置指南。

你應該選擇哪種量化等級？

對幾乎所有人來說，Q4_K_M 是正確的預設選擇：它在保持接近完整品質的同時，將 FP16 的記憶體佔用減少約 4 倍。只有當你有多餘的 VRAM 且任務對品質敏感時，才升級到 Q5_K_M 或 Q8；只有當你進行微調或針對參考標準進行基準測試時，才使用 FP16。低於 Q4 時，品質下降會迅速變得明顯，因此 Q3 及更低等級僅作為將模型強行塞入確實過小的顯卡時的最後手段。

需要注意的一點：量化品質在不同模型間並不相同非常小的模型（低於 4B）比大型模型更明顯地感受到 Q4 的影響，因為它們沒有多餘的冗餘可供犧牲。在 70B 模型上，大多數任務很難分辨 Q4 與 Q8 的區別。但在 1.7B 模型上，差距是真實存在的。

你實際上需要什麼樣的 GPU？

將主表中的 Q4 欄位與留有少量 KV cache 餘裕的顯卡進行匹配。以下是從預算型消費級硬體到資料中心的實用映射，以及各類別在 Q4 下舒適運行的模型層級。

Apple Silicon 值得特別提及，因為統一記憶體改變了計算方式。Mac 不會將 VRAM 與系統 RAM 分開，因此一台 128 GB 的 M-series 機器可以載入需要多個獨立 GPU 才能運行的模型，以峰值吞吐量為代價，換取在單一桌面上容納巨大權重的能力。關於能從這些顯卡中擠出最多效能的後端，我們匯总了 最佳本地運行 LLM 工具，基準測試了實際的速度差異。

我們如何為客戶部署估算 VRAM

在 Techsy，我們經常為客戶部署開源模型，以至於 VRAM 估算是第一場對話，甚至在選擇模型、編寫提示或任何其他事情之前。我們的方法故意顯得枯燥，因為失敗模式（在真實上下文負載下的生產環境 OOM）代價高昂。以下是我們實際執行的流程。

我們從表格數學開始，然後進行測量。載入模型後，我們檢查實際的居民記憶體佔用，而不是依賴估計值：

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

不斷重複的教訓是：團隊只為權重進行估算而忘記了 KV cache，然後疑惑為什麼一個載入正常的模型在演示進行到第三個長請求時就崩潰了。我們根據應用程式實際會使用的最大上下文長度來估算權重加上 KV cache，並加上餘裕，同時限制 --ctx-size，以防止失控的請求導致機器 OOM。對於任何面向客戶的服務，我們寧願運行一個永遠不會崩潰的量化 32B 模型，也不願運行一個在負載下會 OOM 的 FP16 70B 模型。

如果你正在權衡是自託管開源模型還是继续使用託管 API，這種權衡（硬體成本和營運負擔 versus 每 token 定價和控制權）正是我們的團隊在 AI 整合專案 期間所評估的內容。如果有人能根據你的實際工作負載運行這些數字會對你有幫助，請 獲取免費諮詢，我們將與你一起進行估算。

關於作者

Mert Batur Gurbuz 是 Techsy.io 的聯合創始人，該團隊為 B2B 客戶交付 AI 代理、自動化系統以及語音/SDR 管道。他就讀於伯明翰大學，並撰寫有關 Techsy 團隊在生產環境中實際使用的 LLM 工具棧的文章。

資歷：Techsy.io 聯合創始人，伯明翰大學。在 LinkedIn 上聯繫。

常見問題

運行 70B 模型需要多少 VRAM？

像 Llama 3.3 70B 這樣的 70B 密集模型在 Q4_K_M 下需要約 40 GB 的 VRAM 用於權重，因此請計劃使用 48 GB 顯卡（RTX 6000 Ada）或兩張 24 GB 顯卡。如果你使用長上下文，請為 KV cache 額外增加幾 GB，這會將實際需求推高至 48 GB 或更多。

Llama、Qwen 或 DeepSeek 需要多少 VRAM？

這完全取決於變體。Llama 4 Scout 在 Q4 下需要約 62 GB，Qwen3-32B 約需 18 GB，而 Qwen3-8B 低於 5 GB。DeepSeek-V3.2 是一個 6710 億參數的 MoE，由於必須載入所有專家，因此需要約 382 GB。對於 MoE 模型，請始終檢查總參數量，而不是活躍參數量。

我可以在 8GB GPU 上運行 LLM 嗎？

可以，而且很舒適。像 RTX 4060 這樣的 8 GB 顯卡可以在 Q4_K_M 下運行高達約 120 億參數的模型。Gemma 4 12B 約佔用 6.8 GB，留有適度上下文的空間。對於更大的模型，你要么進一步量化，要么保持上下文简短，要么更換更大的顯卡。

像 RTX 4090 這樣的 24GB GPU 能運行什麼？

24 GB 顯卡可以在 Q4_K_M 下處理高達約 32B 的密集模型，並為合理的上下文留出餘裕，因此 Qwen3-32B 和 Mistral Small 3.2 24B 都能舒適運行。它也能運行 Qwen3-30B-A3B MoE，該模型載入 300 億權重，但得益於稀疏激活，其生成速度如同 30 億參數模型。

量化會損害模型品質嗎？

在 Q4_K_M 及以上等級，品質損失很小，在實際任務中往往難以察覺，特別是對於超過 130 億參數的模型。隨著等級降低和模型變小，差距會擴大，因此 70B 模型上的 Q4 幾乎是免費的午餐，而 1.7B 模型上的 Q4 則影響明顯。如果你有足夠的記憶體，Q8 實際上是无損的。

MoE 模型比密集模型需要更少的 VRAM 嗎？

不，這是最常見的誤解。混合專家模型必須將所有專家保存在 VRAM 中，因此其記憶體由總參數量決定。活躍參數數字僅描述推理速度。GLM-5.2 以 400 億參數模型的速度運行，但需要 7440 億參數模型的記憶體。

統一記憶體等同於 VRAM 嗎？

功能上，對於載入模型而言，是的。Apple Silicon 和其他一些系統在 CPU 和 GPU 之間共享一個記憶體池，因此一台 128 GB 的 Mac 可以載入否則需要多個獨立 GPU 才能運行的模型。代價是頻寬：統一記憶體通常提供的峰值吞吐量低於高端資料中心 GPU，因此每秒 token 數較低。

我可以將部分模型卸載到系統 RAM 或 CPU 嗎？

可以。像 llama.cpp 和 Ollama 這樣的引擎允許你透過 --n-gpu-layers 等標誌將一些層保留在 GPU 上，其餘部分放在系統 RAM 中。這讓你可以運行超出 VRAM 容量的模型，但 CPU 上的每一層都會顯著降低生成速度，因此請將其用作讓模型成為可能的手段，而非追求速度。

如何計算表中未列出的模型的 VRAM？

將數十億為單位的參數量乘以你所選量化等級的每位權重位元數，然後除以 8。對於 Q4_K_M，使用約 4.5 位，因此 40B 模型需要 40 × 4.5 ÷ 8 = 約 22.5 GB 用於權重。加上約 15-20% 的開銷以及你的 KV cache，即為實際需求。