Gemma 4 本地部署顯存：E2B、E4B、12B、26B 與 31B 怎麼選

Gemma 4 的本地部署型號不能只列 E2B、E4B、26B 和 31B。Google 官方資料還包含 12B。其中帶 E 或 A 的名稱涉及嵌入/活化參數列達，不能僅看名稱猜權重體積。

本文把三類資料分開：Google 官方給出的近似推理記憶體、社群 GGUF 檔案大小，以及你在具體後端上的峰值顯存。只有第三項能回答“我的電腦實測佔多少”。

型號定位

型號	更適合的用途	本地部署判斷
E2B	輕量、邊緣裝置	消費級裝置最容易嘗試
E4B	輕量通用任務	8–12GB 級顯示卡可重點評估
12B	中等規模任務	量化後適合 12–24GB 級裝置測試
26B A4B	MoE 效率實驗	看總權重，不要只按 A4B 估算
31B	更大稠密模型	24GB 單卡通常要選擇量化並控制上下文

具體架構、輸入模態和上下文上限以對應官方模型卡為準。

為什麼顯存表只能當起點

Google 文件中的近似記憶體表用於說明權重載入量級，但明確不包含所有執行開銷。本地 GGUF 還會受到以下因素影響：

Q4_K_M、Q5_K_M、Q6_K、Q8_0 等實際平均位寬；
KV cache 型別和上下文長度；
併發請求數與批大小；
GPU offload 層數；
影像編碼器或多模態投影檔案；
llama.cpp、Ollama 等後端版本。

因此，不能把“GGUF 檔案為 9GB”直接寫成“最低只需 9GB 顯存”。

消費級顯示卡選型起點

下表是保守的測試方向，預設量化、短上下文、單併發；不是官方保證或統一實測：

顯存	建議先試	說明
6–8GB	E2B、E4B 較低量化	給 KV cache 留空間
12GB	E4B、12B Q4	12B 是否全進 GPU 取決於檔案和上下文
16GB	12B Q4/Q5、26B 較低量化 + offload	關注系統記憶體和速度
24GB	12B 高量化、26B Q4、31B Q4 嘗試	長上下文仍可能 OOM
32GB+	26B/31B 更高量化	仍需按後端實測

如果型號的量化檔案尚未釋出，或後端尚未支援對應架構，就不能根據數學體積宣稱“可部署”。

下載時怎樣避免拿錯模型

從 Google 官方 Gemma 頁面進入對應模型卡；
核對 base 與 it（instruction-tuned）版本；
使用 GGUF 時追溯轉換倉庫的上游權重；
儲存檔名、量化、分片和 SHA256；
檢查 Gemma 許可證是否適合你的使用和分發方式。

Windows 計算雜湊：

1

Get-FileHash .\gemma-model.gguf -Algorithm SHA256

llama.cpp 實測流程

先確認當前 llama.cpp 版本支援目標 Gemma 架構，然後用 4K 上下文啟動：

1
2
3
4
5
6
7


.\llama-server.exe `
  -m .\gemma-model.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8080

另開視窗：

1

nvidia-smi -l 1

記錄啟動日誌裡的模型緩衝、KV cache、計算緩衝和 GPU offload。完成固定提示詞後，再把上下文改為 8192 重測；不要同時改變模型、量化和上下文，否則無法判斷顯存變化來自哪裡。

判斷結果

啟動即 OOM：先降上下文和併發，再換更低量化；
能載入但速度極慢：檢查是否大量 CPU offload；
輸出格式異常：核對 tokenizer 和 chat template；
影像輸入失敗：確認模型、投影檔案與後端都支援多模態；
同量化佔用不同：比較後端版本、KV 型別和 offload 參數。

部署前先盤點四類資源

只看顯示卡型號容易漏掉系統記憶體、磁碟和 CPU。下載模型前，先記錄：

1
2
3
4
5
6
7
8


Get-CimInstance Win32_VideoController |
  Select-Object Name, AdapterRAM, DriverVersion

Get-CimInstance Win32_ComputerSystem |
  Select-Object TotalPhysicalMemory

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, Free, Used

AdapterRAM 在部分 Windows 驅動中可能顯示不準確，最終以 nvidia-smi 或顯示卡控制工具為準。系統記憶體至少要能承接模型檔案、未 offload 的權重和作業系統本身；磁碟還要為下載分片、合併檔案和不同量化版本留空間。

CPU 也會影響部分 offload 的速度。相同顯示卡下，雙通道記憶體與單通道記憶體、DDR4 與 DDR5、不同 CPU 指令集都可能帶來明顯差異。

五個型號分別怎樣落地

E2B：優先驗證裝置相容性

E2B 適合先確認後端能否正確識別 Gemma 4、聊天模板是否正常，以及應用能否連通本地 API。它的目標通常是低延遲和低資源，而不是替代更大的模型完成複雜推理。

可從較高精度量化開始，再根據裝置容量向下調整。若 E2B 仍然只跑 CPU，問題多半在 GPU 後端或驅動，而不是模型太大。

E4B：8GB 與 12GB 顯示卡的常用起點

E4B 更適合聊天、摘要、分類和輕量程式碼任務。先用 Q4 或 Q5、4K 上下文測試，然後比較質量是否值得升級到 Q6/Q8。

如果要處理圖片，還要單獨記錄視覺投影檔案佔用。純文字測試結果不能直接外推到圖文輸入。

12B：先給 KV cache 留餘量

12B 量化權重可能接近 12GB 顯示卡的舒適上限。不要在模型檔案剛好能裝入顯存時就把上下文拉滿；應先預留約 1–2GB 給桌面程式和執行緩衝，再從 2K/4K 上下文開始。

如果 Q4 能全量放入 GPU，而 Q5 需要少量 CPU offload，實際體驗未必是 Q5 更好。應同時比較任務正確率和生成速度。

26B A4B：活化參數不是載入體積

A4B 容易被誤解成“只佔 4B 模型的顯存”。它描述的是啟用規模，不會自動消除其他專家權重。消費級單卡通常要依賴較低量化或 CPU offload。

評估時先確認後端明確支援該 MoE 結構，再觀察日誌是否正確載入專家，而不是隻看服務埠成功啟動。

31B：把速度門檻寫進驗收

31B 在 24GB 單卡上通常需要量化和嚴格的上下文控制。即使能透過 CPU offload 載入，也應設定最低可接受速度，例如首 token 不超過多少秒、生成至少多少 tokens/s。

沒有速度門檻，“成功執行”很容易變成只能用於截圖、無法日常工作的配置。

從 GGUF 檔名讀出關鍵資訊

常見檔名可能包含模型、指令版、量化和分片資訊，例如：

1
2


gemma-4-12b-it-q4_k_m.gguf
gemma-4-26b-a4b-it-q5_k_m-00001-of-00003.gguf

下載時逐項確認：

base 還是 it；
參數規模是否與目標型號一致；
量化是否為計劃測試的版本；
多分片檔案是否全部下載；
倉庫是否提供上游模型與轉換說明；
檔案總大小是否符合該參數規模的合理範圍。

如果某個所謂 26B 或 31B 檔案小得異常，不要直接執行。先檢查它是否只是視覺投影、LoRA、索引或第一段分片。

用後設資料確認模型沒有拿錯

llama.cpp 構建支援時，可讀取 GGUF 後設資料或觀察載入日誌。至少確認：

架構被識別為預期的 Gemma 版本；
tokenizer 與 chat template 存在；
上下文參數沒有被後端靜默改寫；
模型分片全部開啟；
沒有出現 unknown tensor、unsupported architecture 等錯誤。

出現模板問題時，先按官方模型卡和轉換倉庫說明修復，不要用不斷修改系統提示詞來掩蓋角色格式錯誤。

上下文要按階梯測試

建議固定模型與量化，只改變上下文：

輪次	上下文	併發	觀察重點
1	2048	1	是否能穩定載入
2	4096	1	日常短對話的顯存和速度
3	8192	1	KV cache 增量
4	8192	2	併發對快取和延遲的影響
5	更長上下文	1	只在業務確實需要時繼續

每一輪都重啟服務，確保上一次模型或快取已經釋放。若後端支援選擇 KV cache 型別，要把該參數寫進記錄，否則不同人的結果不可比較。

部分 GPU offload 怎麼調

當 -ngl 999 導致 OOM，可以逐步降低 GPU 層數，而不是立即換最低量化：

1
2
3
4
5
6
7


.\llama-server.exe `
  -m .\gemma-model.gguf `
  -ngl 40 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8080

具體層數由模型與後端決定。每次只減少一段，並記錄：

GPU 與系統記憶體峰值；
prompt processing 速度；
token generation 速度；
首 token 延遲；
是否發生系統換頁。

如果系統開始大量使用頁面檔案，即使沒有 OOM，體驗通常也會迅速惡化。此時應換小模型或低量化，而不是繼續增加虛擬記憶體。

多卡不能只看顯存相加

兩張顯示卡的總顯存看似足夠，但還要考慮後端是否支援張量分割、兩張卡的速度差異和 PCIe 拓撲。混用不同容量顯示卡時，平均分配可能讓小卡先 OOM。

多卡測試應記錄每張卡的顯存、利用率和功耗：

1

nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu,power.draw --format=csv -l 1

如果模型在卡間頻繁傳輸導致速度反而下降，單卡加 CPU offload 可能更簡單。最終應以端到端延遲判斷，而不是隻看兩張卡都亮起利用率。

驗證本地 API 而不只看網頁

服務啟動後先檢查模型列表：

1

curl.exe http://127.0.0.1:8080/v1/models

再傳送固定測試：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


$body = @{
  model = 'local-gemma'
  messages = @(
    @{ role = 'user'; content = '把 17×23 的计算过程写成两步。' }
  )
  temperature = 0
} | ConvertTo-Json -Depth 5

Invoke-RestMethod `
  -Uri 'http://127.0.0.1:8080/v1/chat/completions' `
  -Method Post `
  -ContentType 'application/json' `
  -Body $body

檢查 HTTP 狀態、模型欄位、回答內容和服務日誌。若網頁能聊天但 API 失敗，應優先排查端點與請求格式，不要重新下載模型。

常見選擇問題

12GB 顯示卡選 E4B 還是 12B

需要速度、長上下文或同時執行其他軟體時選 E4B；更重視回答質量且可以接受短上下文時，再測試 12B Q4。用同一組任務比較，而不是隻按參數量決定。

24GB 顯示卡能否直接選 31B

可以把 Q4、短上下文作為實驗起點，但不能保證所有權重與快取都留在 GPU。先看真實 GGUF 檔案、啟動日誌和峰值顯存。

為什麼同一個 Q4 有不同檔案大小

Q4 只是大類。不同量化方案、混合精度張量、分組方式和後設資料會改變平均位寬，必須寫完整量化名稱。

模型載入後顯存為何繼續增長

新對話 token 會進入 KV cache；併發、批大小和視覺輸入也會增加緩衝。應區分啟動後空載顯存與完成一次最長請求後的峰值。

儲存一份可複核的 Gemma 測試記錄

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


GPU / 显存：
驱动：
后端与版本：
Gemma 型号（base/it）：
GGUF 文件与 SHA256：
量化：
上下文 / 并发：
GPU offload：
空载与峰值显存：
首 token 延迟 / tokens/s：

只有這些條件齊全，顯存和效能結果才具有可比較性。

Google 與推理後端資料

讀懂 `Gemma-4-31B-it` 這類模型名稱

Gemma-4 表示家族與代際；31B 表示總參數約 310 億，不代表執行時固定占 31GB，也不表示每次推論都啟用全部參數；it 通常是 instruction-tuned，代表模型已針對指令、問答與對話調整。聊天、摘要、程式輔助與 Agent 優先選 -it，基礎模型主要用於後續訓練或研究。

下載名稱還可能包含 Q4_K_M、Q8_0、BF16、GGUF 等量化、精度與格式後綴，這些才直接影響檔案大小、後端相容性和記憶體。名稱若與官方型號表不一致，先核對模型卡、倉庫擁有者與中繼資料，不要只憑檔名認定為官方發布。

筆記型電腦配置與驗收

筆電還受共享記憶體、散熱與持續功耗限制。16GB 系統記憶體且沒有獨顯時，先用 E2B/E4B 低位元量化與 4K context；8GB 顯存適合驗證 E4B Q4，12–16GB 顯存才適合謹慎嘗試 12B Q4。Apple Silicon 是統一記憶體，必須給 macOS 與應用保留數 GB。

首次測試關閉占用 GPU 的瀏覽器與影音軟體、接上電源並觀察溫度。不要一開始使用 32K/128K context，KV cache 會隨上下文增加，能載入不代表長提示仍不溢位。

1
2


ollama ps
nvidia-smi

記錄完整模型標籤、量化、context、後端、首 token 延遲、生成速度與峰值記憶體。CPU-only 能回答只證明相容；若持續降頻、交換記憶體或速度不足，應降低模型、量化負擔或上下文。新配置通過相同驗收前，保留原模型或 Modelfile 以便回復。