顯存 on KnightLi的博客

本地部署 Qwen3.6：27B 與 35B-A3B 各量化版本需要多少顯存

Fri, 01 May 2026 12:02:00 +0800

Qwen3.6 目前最適合本地部署討論的開放權重版本，主要是兩類：

Qwen3.6-27B：27B 稠密模型。
Qwen3.6-35B-A3B：35B total / 3B active 的 MoE 模型。

還有一些線上產品名或 API 模型名，例如 Qwen3.6-Plus、Qwen3.6-Max。這類模型如果沒有公開完整權重和穩定量化檔案，就不適合列入本地顯存表。本文只整理可以圍繞 Hugging Face 權重與 GGUF 量化檔案部署的版本。

和 /05/10 的 Gemma 4 表一樣，這裡也要先區分兩個概念：

GGUF 檔案體積：模型權重檔案本身有多大。
實際顯存占用：模型權重、KV cache、上下文長度、執行後端、多模態模組、批次大小共同決定。

Qwen3.6 的預設上下文很長，官方模型卡裡寫到原生支援 262,144 tokens，並可擴展到 1,010,000 tokens。所以表格裡的「最低顯存」只適合短上下文或中等上下文。如果你真的要跑 128K、256K 或更長上下文，必須額外給 KV cache 留大量空間。

先看結論

顯存	比較合適的選擇	不建議硬上
8GB	27B / 35B-A3B 的 2-bit 極限嘗試，品質風險較高	Q4 以上
12GB	27B Q2/Q3，35B-A3B Q2/Q3 短上下文	27B Q4 長上下文
16GB	27B Q3/Q4，35B-A3B Q3/IQ4_XS	35B-A3B Q4 長上下文
24GB	27B Q4/Q5/Q6，35B-A3B Q4	35B-A3B Q8、BF16
32GB	27B Q8，35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8，27B 長上下文更從容	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	沒有必要為普通本地聊天追 BF16

如果你是 24GB 顯卡，重點看：

Qwen3.6-27B Q4_K_M
Qwen3.6-27B Q5_K_M
Qwen3.6-35B-A3B UD-Q4_K_M

如果你只有 16GB 顯存，優先從低位寬版本開始，不要一上來就開超長上下文。

官方權重體積

以下是官方 Hugging Face 倉庫中 model.safetensors.index.json 統計到的 BF16 權重體積。它可以作為原始權重規模參考。

模型	架構	官方 BF16 權重體積	官方上下文
`Qwen3.6-27B`	27B dense	55.56GB	262K 原生，可擴展到 1,010K
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	262K 原生，可擴展到 1,010K

35B-A3B 雖然每次只啟用約 3B 參數，但它仍然需要載入完整 MoE 權重。所以它不能按 3B 小模型來估算顯存。

Qwen3.6-27B 顯存表

Qwen3.6-27B 是稠密模型，優點是能力穩定，缺點是推理成本更接近傳統 27B 模型。從本地部署角度看，它比 35B-A3B 更吃計算，但顯存需求更容易預估。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_XXS`	9.39GB	12GB	16GB	極限低顯存嘗試
`UD-IQ2_M`	10.85GB	12GB	16GB	低顯存可用性優先
`UD-Q2_K_XL`	11.85GB	14GB	18GB	低位寬折中
`UD-IQ3_XXS`	11.99GB	14GB	18GB	省顯存的 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit 入門
`Q3_K_M`	13.59GB	16GB	20GB	3-bit 常用折中
`IQ4_XS`	15.44GB	20GB	24GB	接近 Q4 的省顯存選擇
`IQ4_NL`	16.07GB	20GB	24GB	品質和體積折中
`Q4_K_M`	16.82GB	20GB	24GB	27B 常用推薦
`Q5_K_M`	19.51GB	24GB	32GB	更穩的高品質量化
`Q6_K`	22.52GB	28GB	32GB	品質優先
`Q8_0`	28.60GB	32GB	40GB	接近原始精度
`BF16`	53.80GB	64GB	80GB	研究、評測、精度對比

如果只是普通本地編碼和聊天，Q4_K_M 是最容易推薦的起點。 24GB 顯卡可以比較舒服地跑 Q4_K_M，但如果要長上下文，最好降低量化位寬或減少上下文長度。

Qwen3.6-35B-A3B 顯存表

Qwen3.6-35B-A3B 是 MoE 模型，35B total，但每次啟用約 3B 參數。它的優勢是速度和能力之間的平衡很好，尤其適合本地 Agent、工具呼叫、程式碼協作。

但要注意：MoE 的 3B active 主要影響計算量，不代表顯存只需要 3B 模型級別。完整執行仍要載入專家權重。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_XXS`	10.76GB	12GB	16GB	極限低顯存嘗試
`UD-IQ2_M`	11.52GB	14GB	16GB	低顯存可用性優先
`UD-Q2_K_XL`	12.29GB	14GB	18GB	低位寬折中
`UD-IQ3_XXS`	13.21GB	16GB	20GB	省顯存的 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit 入門
`UD-Q3_K_M`	16.60GB	20GB	24GB	3-bit 常用折中
`UD-IQ4_XS`	17.73GB	20GB	24GB	品質和體積折中
`UD-IQ4_NL`	18.04GB	20GB	24GB	接近 Q4 的推薦選擇
`UD-Q4_K_M`	22.13GB	24GB	32GB	35B-A3B 常用推薦
`UD-Q5_K_M`	26.46GB	32GB	40GB	更穩的高品質量化
`UD-Q6_K`	29.31GB	32GB	48GB	品質優先
`Q8_0`	36.90GB	48GB	64GB	接近原始精度
`BF16`	69.37GB	80GB	96GB	研究、評測、精度對比

24GB 顯存可以把 UD-Q4_K_M 作為重點選擇，但上下文不要開得太誇張。如果想給 128K 以上上下文留空間，UD-IQ4_XS、UD-IQ4_NL 或 3-bit 版本會更現實。

27B 和 35B-A3B 怎麼選

需求	更推薦
穩定稠密模型表現	`Qwen3.6-27B`
更快響應、Agent 和工具呼叫	`Qwen3.6-35B-A3B`
24GB 顯存日常本地用	`35B-A3B UD-Q4_K_M` 或 `27B Q4_K_M`
16GB 顯存嘗試	兩者都選 2-bit/3-bit，不建議長上下文
長上下文優先	降低量化位寬，留更多 KV cache 空間
品質優先且有 32GB+ 顯存	`27B Q5/Q6` 或 `35B-A3B Q5/Q6`

如果你主要寫程式碼、跑 Agent、做工具呼叫，35B-A3B 更值得先試。如果你更在意稠密模型的穩定性和一致性，27B 更直觀。

為什麼長上下文會吃掉大量顯存

Qwen3.6 的模型卡建議在複雜任務中保持較長上下文，甚至提到 128K 以上上下文對思考能力有幫助。但對本地部署來說，長上下文意味著更大的 KV cache。

影響實際顯存的因素包括：

KV cache：上下文越長，占用越高。
是否啟用視覺輸入：Qwen3.6 是帶視覺編碼器的模型，多模態場景會增加額外開銷。
是否使用 --language-model-only：在 vLLM 等執行時裡，跳過視覺部分可以釋放一部分記憶體給 KV cache。
批次大小和並發：並發越高，顯存需求越高。
KV cache 量化：q8_0、q4_0 等設定可以省顯存，但可能影響細節。
執行時差異：llama.cpp、vLLM、SGLang、KTransformers、LM Studio 的占用不完全一樣。

所以不要只看 GGUF 檔案大小。如果檔案已經接近顯存上限，模型即使能載入，也可能在生成長文字或長上下文時 OOM。

怎麼選

如果你只是想本地體驗 Qwen3.6：

12GB 顯存：嘗試 27B UD-IQ2_M 或 35B-A3B UD-IQ2_M，上下文要短。
16GB 顯存：嘗試 27B Q3_K_M 或 35B-A3B UD-IQ3_XXS。
24GB 顯存：優先看 27B Q4_K_M、35B-A3B UD-IQ4_NL、35B-A3B UD-Q4_K_M。
32GB 顯存：可以考慮 27B Q5/Q6 或 35B-A3B Q5/Q6。
48GB 以上：可以嘗試 Q8_0，或者給長上下文留更多空間。

一般使用者不需要追 BF16。 Qwen3.6 的本地部署重點不是「檔案越大越好」，而是在顯存、上下文長度、速度和輸出品質之間找到平衡。

參考來源

本地部署 DeepSeek V4：Pro、Flash 與 Base 版本顯存占用估算表

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 和 Gemma 4 的本地部署不是一個量級。 Gemma 4 的 26B、31B 還能討論 24GB、32GB 顯卡怎麼選量化版；DeepSeek V4 則是超大 MoE 模型，真正完整本地部署時，顯存需求會直接進入多卡工作站或伺服器級別。

官方發布的 DeepSeek V4 Preview 主要包含兩個推理版本：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face 官方 collection 裡還包含兩個 Base 版本：

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

這篇只討論完整載入模型權重時的大致顯存門檻。 MoE 的 active params 主要影響每個 token 的計算量，不等於只需要載入這部分參數。如果沒有專家按需載入、CPU/NVMe offload、分散式推理或專門執行時最佳化，顯存仍然要按完整權重來估。

先看結論

顯存規模	能比較現實地嘗試什麼	不建議期待什麼
24GB	不能完整跑 DeepSeek V4；只能跑小型蒸餾模型或 API	V4-Flash / V4-Pro 完整本地載入
48GB	仍不適合完整載入；可做小模型或遠端 API 用戶端	V4-Flash Q4 穩定執行
80GB	理論上可嘗試 V4-Flash Q2/Q3 或強 offload	V4-Pro
128GB	V4-Flash Q4 比較現實；Q5/Q6 仍緊	V4-Pro Q4
192GB	V4-Flash FP8/Q6 更從容；Pro Q2 勉強進入討論	V4-Pro Q4
256GB	V4-Flash FP8 比較穩；Pro Q2/Q3 可實驗	V4-Pro Q5 以上
512GB	V4-Pro Q4 開始進入可討論範圍	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base 低位寬更現實	單機低成本部署
2TB+	Pro-Base FP8 級別	普通工作站部署

如果你的目標是個人電腦本地執行，DeepSeek V4 並不是合適對象。更現實的路線是：

用 DeepSeek 官方 API 或相容服務；
等社群穩定的 GGUF/EXL2/MLX 量化和推理支援；
使用更小的 DeepSeek 蒸餾模型；
或者把本地模型換成 Qwen、Gemma、Llama 等 7B 到 70B 級別模型。

官方權重體積

以下是 Hugging Face 官方倉庫的 model.safetensors.index.json 中統計到的權重總量。它反映的是目前公開權重檔案大小，不等於長上下文執行時的完整顯存占用。

模型	參數規模	官方權重體積	說明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推理版，體積相對最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推理版，能力更強，體積巨大
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版，更接近全量 FP8 權重體積
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版，約 1.6TB 級別

可以看到，即使是最小的 V4-Flash，官方權重也已經接近 160GB。這就是為什麼它不能按「13B active params」理解成 13B 小模型。

DeepSeek V4 Flash 顯存估算

V4-Flash 是 DeepSeek V4 裡最適合本地嘗試的一檔。但「最適合」只是相對 Pro 而言，它仍然不是消費級單卡模型。

下面按官方 159.61GB 權重體積做折算。其中 Q4/Q3/Q2 是按位寬估算，不代表目前已經有穩定可用的官方 GGUF 版本。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	159.61GB	192GB	256GB	多卡伺服器、推理服務
`Q6`	120GB	160GB	192GB	品質優先的量化嘗試
`Q5`	100GB	128GB	160GB	品質和體積折中
`Q4`	80GB	96GB	128GB	Flash 本地化較現實的起點
`Q3`	60GB	80GB	96GB	大顯存單卡或多卡實驗
`Q2`	40GB	48GB	64GB	極限低位寬實驗，品質風險明顯

如果未來社群出現成熟的 V4-Flash Q4，它大機率也不是 24GB 顯卡的模型。更現實的硬體起點是 96GB 到 128GB 級別的總顯存，或者依賴 CPU 記憶體/offload 換速度。

DeepSeek V4 Pro 顯存估算

V4-Pro 是旗艦推理版，官方權重體積約 864.70GB。即使做 4-bit 量化，完整權重也仍然是數百 GB 級別。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	864.70GB	1TB	1.2TB+	多機多卡推理服務
`Q6`	648GB	768GB	1TB	高品質量化服務
`Q5`	540GB	640GB	768GB	高品質與成本折中
`Q4`	432GB	512GB	640GB	Pro 本地化較現實的最低品質線
`Q3`	324GB	384GB	512GB	低位寬實驗
`Q2`	216GB	256GB	320GB	極限實驗，品質和穩定性風險高

對個人使用者來說，V4-Pro 更適合透過 API 使用。如果目標是完整本地部署，至少要把它當成多卡伺服器模型，而不是 4090、5090、RTX PRO 單卡模型。

DeepSeek V4 Flash-Base 顯存估算

Base 版通常用於研究、微調或繼續訓練，不是普通聊天部署的首選。 V4-Flash-Base 官方權重體積約 294.67GB。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	294.67GB	384GB	512GB	研究、訓練前處理、評測
`Q6`	221GB	256GB	320GB	高品質量化研究
`Q5`	184GB	224GB	256GB	品質和體積折中
`Q4`	147GB	192GB	224GB	Base 版低成本實驗
`Q3`	111GB	128GB	160GB	低位寬實驗
`Q2`	74GB	96GB	128GB	極限實驗

如果只是要使用 DeepSeek V4 能力，不建議從 Base 版開始。 Base 版的部署和調優成本更高，普通應用更適合推理版或 API。

DeepSeek V4 Pro-Base 顯存估算

V4-Pro-Base 是最重的一檔，官方權重體積約 1606.03GB。這已經是 1.6TB 級別的模型檔案。

版本/量化	估算權重體積	最低顯存	更穩妥顯存	適合場景
`FP8 / 官方權重`	1606.03GB	2TB	2.4TB+	大規模研究叢集
`Q6`	1205GB	1.5TB	2TB	高品質量化研究
`Q5`	1004GB	1.2TB	1.5TB	研究與評測
`Q4`	803GB	1TB	1.2TB	低位寬研究
`Q3`	602GB	768GB	1TB	極限低位寬研究
`Q2`	402GB	512GB	640GB	極限實驗

這類模型不適合被放進「家用顯卡能不能跑」的框架裡討論。哪怕是 Q4，也已經超過絕大多數單機工作站的舒適範圍。

為什麼不能只看 active params

DeepSeek V4 是 MoE 模型。 MoE 的特點是每個 token 只啟用一部分專家，因此計算量會明顯低於總參數量。但這不等於顯存只需要放 active params。

完整本地推理通常還要考慮：

所有專家權重是否需要常駐 GPU；
是否支援按需專家載入；
CPU 記憶體與 GPU 顯存之間的資料搬運成本；
NVMe offload 的延遲；
KV cache 在長上下文下的增長；
1M context 場景下的額外執行時開銷；
多機多卡通訊成本。

所以，49B active 的 V4-Pro 不能當成 49B 模型來部署。 13B active 的 V4-Flash 也不能當成 13B 小模型來部署。

怎麼選

如果你只是普通個人使用者：

不建議完整本地部署 DeepSeek V4。
需要 DeepSeek V4 能力時，優先用官方 API。
需要本地私有化時，優先看是否有成熟推理服務商或內部多卡伺服器。
只有 24GB 到 48GB 顯存時，轉向 7B、14B、32B、70B 級別量化模型更實際。

如果你有 128GB 到 256GB 總顯存：

可以關注 V4-Flash Q4/Q5 是否有穩定社群實作。
不建議把 V4-Pro 當成主力本地模型。

如果你有 512GB 以上總顯存：

V4-Pro Q4 才開始進入工程驗證範圍。
仍然要關注推理框架、專家調度、KV cache、吞吐和並發。

DeepSeek V4 的本地部署重點不是「下載哪個量化檔案」，而是「有沒有足夠的系統級推理能力」。它更接近一個伺服器模型，而不是普通桌面模型。

參考來源

本地部署 Gemma 4：E2B、E4B、26B、31B 各量化版本需要多少顯存

Fri, 01 May 2026 11:42:34 +0800

Gemma 4 現在主要有四個本地部署尺寸：E2B、E4B、26B A4B 和 31B。其中 E2B、E4B 面向輕量和邊緣裝置，26B A4B 是 MoE 架構，31B 是更大的稠密模型。

本地執行時，最容易混淆的是兩個數字：

GGUF 檔案體積：模型權重檔案本身有多大。
實際顯存占用：模型權重、KV cache、執行時開銷、上下文長度、是否載入多模態投影檔共同決定。

下面的表格按 GGUF 檔案體積估算顯存需求。預設假設是 llama.cpp、LM Studio、Ollama 這類本地推理場景，主要跑文字，使用中短上下文。如果要開長上下文、視覺/音訊輸入、並發請求，顯存要繼續往上留餘量。

先看結論

顯存	比較合適的選擇	不建議硬上
4GB	E2B 的低位元量化	E4B 以上
6GB	E2B Q4/Q5，E4B 低位元量化	26B、31B
8GB	E2B Q8，E4B Q4/Q5	26B Q4、31B Q4
12GB	E4B Q8，26B/31B 的 2-bit/3-bit 低品質嘗試	26B Q4 長上下文、31B Q4
16GB	26B 低位元量化，31B 低位元量化	31B Q4 長上下文、26B Q5 以上
24GB	26B Q4/Q5，31B Q4	31B Q8、BF16
32GB	26B Q6/Q8，31B Q5/Q6	BF16
48GB	31B Q8 更從容，26B Q8 長上下文	31B BF16
80GB+	26B/31B BF16	普通消費卡單卡部署

如果只是想本地可用，優先從 E4B Q4_K_M 或 E2B Q4_K_M 開始。如果有 24GB 顯存，26B A4B Q4_K_M 和 31B Q4_K_M 才開始進入比較舒服的範圍。

Gemma 4 E2B 顯存表

E2B 是最輕量的版本，適合筆電、迷你主機、行動端和低顯存測試。它的優勢是容易跑，缺點是複雜推理、程式碼和長任務穩定性有限。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_M`	2.29GB	4GB	6GB	極限低顯存測試
`UD-Q2_K_XL`	2.40GB	4GB	6GB	低顯存可用性優先
`Q3_K_M`	2.54GB	4GB	6GB	輕量聊天、摘要
`IQ4_XS`	2.98GB	6GB	8GB	品質和體積折中
`Q4_K_M`	3.11GB	6GB	8GB	E2B 常用推薦
`Q5_K_M`	3.36GB	6GB	8GB	比 Q4 更穩一點
`Q6_K`	4.50GB	8GB	10GB	小模型高品質量化
`Q8_0`	5.05GB	8GB	10GB	接近原始精度的輕量部署
`BF16`	9.31GB	12GB	16GB	除錯、對比、研究

E2B 的 Q4_K_M 已經夠日常體驗。如果只有 4GB 顯存，可以嘗試 2-bit 或 3-bit，但輸出品質會更容易波動。

Gemma 4 E4B 顯存表

E4B 是更實用的輕量版本。它比 E2B 更適合日常寫作、資料總結、輕量程式碼輔助和本地助手。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_M`	3.53GB	6GB	8GB	低顯存嘗試
`UD-Q2_K_XL`	3.74GB	6GB	8GB	低顯存可用性優先
`Q3_K_M`	4.06GB	6GB	10GB	輕量本地助手
`IQ4_XS`	4.72GB	8GB	12GB	品質和速度折中
`Q4_K_M`	4.98GB	8GB	12GB	E4B 常用推薦
`Q5_K_M`	5.48GB	8GB	12GB	更穩的日常使用
`Q6_K`	7.07GB	10GB	16GB	品質優先
`Q8_0`	8.19GB	12GB	16GB	接近原始精度
`BF16`	15.05GB	20GB	24GB	研究、評測、精度對比

如果你的顯卡是 8GB，E4B Q4_K_M 是很現實的起點。如果是 12GB 或 16GB，E4B Q8_0 也可以考慮。

Gemma 4 26B A4B 顯存表

26B A4B 是 MoE 版本，參數規模更大，但每次推理只啟用其中一部分專家。它適合更複雜的問答、程式碼、工具呼叫和 Agent 工作流。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_M`	9.97GB	14GB	16GB	16GB 顯卡極限嘗試
`UD-Q2_K_XL`	10.55GB	14GB	16GB	低顯存跑 26B
`UD-Q3_K_M`	12.53GB	16GB	20GB	品質略好，仍偏省顯存
`UD-IQ4_XS`	13.42GB	16GB	24GB	品質和體積折中
`UD-Q4_K_M`	16.87GB	20GB	24GB	26B 常用推薦
`UD-Q5_K_M`	21.15GB	24GB	32GB	更穩的高品質量化
`UD-Q6_K`	23.17GB	28GB	32GB	品質優先
`Q8_0`	26.86GB	32GB	40GB	接近原始精度
`BF16`	50.51GB	64GB	80GB	單卡消費級不現實

24GB 顯存是 26B A4B 比較舒服的分界線。 16GB 顯卡可以嘗試低位元版本，但上下文長度、並發和多模態都要收斂。

Gemma 4 31B 顯存表

31B 是更大的稠密模型。它的優點是綜合能力更強，缺點是顯存壓力比 26B A4B 更直接。

量化版本	GGUF 檔案體積	最低顯存	更穩妥顯存	適合場景
`UD-IQ2_XXS`	8.53GB	12GB	16GB	極限低顯存嘗試，品質犧牲明顯
`UD-IQ2_M`	10.75GB	14GB	18GB	低顯存嘗試
`UD-Q2_K_XL`	11.77GB	16GB	20GB	16GB 顯卡可嘗試
`Q3_K_S`	13.21GB	16GB	24GB	更省顯存的 3-bit
`Q3_K_M`	14.74GB	20GB	24GB	3-bit 常用折中
`IQ4_XS`	16.37GB	20GB	24GB	接近 Q4 的折中
`Q4_K_M`	18.32GB	24GB	32GB	31B 常用推薦
`Q5_K_M`	21.66GB	28GB	32GB	更穩的高品質量化
`Q6_K`	25.20GB	32GB	40GB	品質優先
`Q8_0`	32.64GB	40GB	48GB	接近原始精度
`BF16`	61.41GB	80GB	96GB	伺服器或大顯存工作站

31B 的低位元版本可以在 16GB 顯卡上做實驗，但如果想日常使用，最好從 24GB 顯存起步。 Q4_K_M 是比較平衡的選擇，Q5_K_M 往上更適合 32GB 以上顯存。

為什麼實際占用會比檔案體積更高

GGUF 檔案體積只是權重大小。真正執行時還會增加這些開銷：

KV cache：上下文越長，占用越高。
批次大小和並發：一次處理更多 token 或多使用者並發，會增加顯存。
多模態組件：圖片、音訊、影片輸入通常還要載入 mmproj 或額外處理模組。
執行時後端：CUDA、Metal、ROCm、CPU/GPU 分層載入的占用不同。
KV cache 量化：開啟 q8_0、q4_0 等 KV cache 量化可以省顯存，但可能影響細節。

所以表格裡的「最低顯存」只能理解為「能啟動並短上下文執行」的門檻。如果你要 32K、64K、128K 甚至 256K 上下文，顯存需求會明顯增加。

怎麼選

如果只是想在本地體驗 Gemma 4：

4GB 到 6GB 顯存：選 E2B Q3_K_M 或 E2B Q4_K_M。
8GB 顯存：優先選 E4B Q4_K_M，也可以跑 E2B Q8_0。
12GB 顯存：選 E4B Q8_0，或者嘗試 26B/31B 的低位元版本。
16GB 顯存：可以嘗試 26B A4B UD-Q3_K_M 或 31B Q3_K_S，但不要期待長上下文很舒服。
24GB 顯存：26B A4B UD-Q4_K_M 和 31B Q4_K_M 是重點選擇。
32GB 以上：可以考慮 Q5_K_M、Q6_K，或者更長上下文。

一般使用者不需要追 BF16。本地部署的重點不是檔案越大越好，而是在顯存、速度、上下文和輸出品質之間找到平衡。