8GB 顯存跑 Gemma 4 12B：llama-cli 混合卸載參數怎麼配

8GB 顯存想跑 Gemma 4 12B，最大的問題不是硬碟空間，而是執行時顯存。

以 Q4_K_M 這類 GGUF 量化版為例，模型檔案本身可能已經接近 8GB。真正跑起來時，還要額外放 KV cache、臨時計算緩衝、系統桌面占用和驅動開銷。結果就是：模型看起來「差一點能塞下」，實際一開長上下文就 OOM。

如果機器只有 8GB 顯存，更合理的思路不是硬塞全 GPU，而是走顯存和系統記憶體混合卸載：把盡量多的層放進 GPU，剩下的層留在記憶體裡由 CPU 參與計算。

推薦腳本

假設模型路徑是：

1

./models/gemma-4-12b-it-Q4_K_M.gguf

Linux / macOS 可以建立 run_gemma4.sh：

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

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 26 \
  -c 8192 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n -1 \
  --color \
  -i

賦予執行權限：

1

chmod +x run_gemma4.sh

執行：

1

./run_gemma4.sh

Windows 可以建立 run_gemma4.bat：

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

@echo off
set MODEL_PATH=.\models\gemma-4-12b-it-Q4_K_M.gguf

llama-cli.exe ^
  -m "%MODEL_PATH%" ^
  -ngl 26 ^
  -c 8192 ^
  -t 8 ^
  --flash-attn ^
  -n -1 ^
  --color ^
  -i

Windows 下通常不建議預設寫 --mlock。不同版本、權限和系統配置下表現不完全一致，先跑通更重要。Linux 上如果記憶體很足，再優先使用 --mlock。

為什麼要混合卸載

-ngl 是這套配置裡最關鍵的參數。它控制有多少層卸載到 GPU。

1

-ngl 26

對於 8GB 顯存，目標不是把模型全部塞進顯卡，而是留出足夠餘量給 KV cache 和執行時緩衝。-ngl 26 可以作為一個起步值：顯存放一部分模型層，記憶體接住剩餘層。

調參方法很簡單：

8GB 顯存的機器不要只盯著模型大小。真正要看的，是模型層、KV cache、顯存碎片和桌面占用加起來是否還有餘量。

--flash-attn：8GB 顯存建議開啟

1

--flash-attn

這個參數對小顯存很有幫助。它可以降低注意力計算的顯存壓力，並改善長上下文推理效率。

如果你的 llama.cpp 建構版本、GPU 後端或顯卡架構不支援 Flash Attention，啟動時可能會報錯。遇到這種情況可以先去掉 --flash-attn 跑通，再更新 llama.cpp 或檢查 CUDA / Metal / Vulkan 後端支援。

對 8GB 顯存來說，能開就開；開不了，就先降上下文。

-c 8192：先把上下文壓到 8K

1

-c 8192

上下文越長，KV cache 越大。很多模型標稱支援很長的上下文，但小顯存機器不能直接按上限開。

8GB 顯存上，8192 是比較穩的起點。它足夠日常聊天、程式碼片段分析和中短文處理，又不會像 32K、64K 那樣迅速吃光顯存。

如果仍然 OOM，可以繼續降：

1

-c 4096

如果你換成更小體積的量化版，並且顯存還有明顯富餘，再嘗試：

1

-c 12288

不要一開始就追求最大上下文。先穩定，再擴容。

--mlock：減少記憶體換出

1

--mlock

如果系統記憶體比較充裕，這個參數的作用是盡量把模型駐留在實體記憶體中，避免被作業系統換到慢速 swap 或頁面檔裡。

在混合卸載模式下，部分層會留在記憶體中。如果這些記憶體頁被換出，響應會明顯變慢，甚至出現卡頓。--mlock 能減少這種情況。

注意兩點：

• Linux 上可能需要調整 ulimit -l 或相關權限。
• Windows 下不一定需要預設開啟，先跑通模型更重要。

如果開啟 --mlock 後啟動失敗，可以先刪掉它。它是穩定性和速度優化項，不是必要項。

-t 8：CPU 執行緒數別盲目拉滿

1

-t 8

-t 控制 CPU 執行緒數。混合卸載時，沒放進顯存的層需要 CPU 參與計算，所以執行緒數會影響速度。

建議設定為 CPU 實體核心數，而不是邏輯執行緒數。比如：

執行緒數不是越高越好。拉太滿可能導致系統調度、記憶體頻寬和桌面響應都變差。可以從實體核心數開始，再用實際 tokens/s 微調。

關於 -p "<|think|>\n"

原始腳本裡有這一段：

1

-i -p "<|think|>\n"

這裡建議謹慎使用。不同模型、不同 GGUF 轉換、不同模板，對思考標記的支援並不一樣。把 <|think|> 強行塞進 prompt，不一定會穩定開啟所謂「深度思考」，還可能污染輸出格式。

更穩妥的做法是先只開互動模式：

1

-i

如果你確認目前 Gemma 4 GGUF 的聊天模板需要特定系統提示或特殊 token，再按模型卡說明添加。不要把某個標記當成通用開關。

第一次執行建議用保守版

如果擔心 8GB 顯存不穩，可以先用更保守的腳本：

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

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 20 \
  -c 4096 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n 512 \
  --color \
  -i

這個版本犧牲了上下文和 GPU 卸載層數，但更容易跑起來。確認穩定後，再調回：

1

-ngl 26

以及：

1

-c 8192

想提速，優先換量化

如果 Q4_K_M 在 8GB 顯存上只能卸載二十多層，速度會受 CPU 和記憶體頻寬影響。想明顯提速，最直接的方法是換更小的量化版本。

可以嘗試：

換到 Q3_K_M 或 Q3_K_L 後，可以嘗試：

1

-ngl 34

甚至：

1

-ngl 38

如果模型大部分層都能進 GPU，速度會明顯改善。但量化越低，輸出品質越可能下降。建議同一組 prompt 對比，不要只看 tokens/s。

記憶體頻寬也很關鍵

混合卸載不是免費午餐。沒進顯存的層會走 CPU 和系統記憶體，速度受記憶體頻寬影響很大。

建議檢查：

• 系統記憶體是否雙通道。
• DDR5 是否開啟 XMP / EXPO。
• 後台是否有大量占用記憶體頻寬的程序。
• 筆電是否處於高效能電源模式。

如果記憶體是單通道，混合卸載速度會明顯差。對於 8GB 顯存 這種配置，系統記憶體容量夠用只是第一步，頻寬也要跟上。

排障順序

遇到 OOM，不要一次改一堆參數。按這個順序排：

1. 降低上下文：

1

-c 4096

2. 降低 GPU 卸載層數：

1

-ngl 22

再不行：

1

-ngl 20

3. 去掉 --mlock：

1

# 刪除 --mlock

4. 如果 --flash-attn 報錯，先去掉它確認是否是後端支援問題：

1

# 刪除 --flash-attn

5. 換更低 bit 量化模型。

每次只改一個參數，記錄 tokens/s、顯存占用和是否 OOM。這樣才知道真正的瓶頸在哪裡。

一個調參表

8GB 顯存最忌諱一步到位。更好的方式是先用保守參數跑通，再把 -ngl 和 -c 一點點往上推。

小結

8GB 顯存 跑 Gemma 4 12B Q4_K_M，重點是混合卸載。推薦從 -ngl 26、-c 8192、--flash-attn、--mlock、-t 8 開始；如果 OOM，就先降上下文，再降 GPU 層數。

如果追求速度，換 Q3_K_M 或 Q3_K_L 往往比死磕 Q4_K_M 更有效。系統記憶體能兜住混合卸載的一部分壓力，但真正決定體感速度的，還是 GPU 卸載層數、KV cache 大小和記憶體頻寬。