Gemma 4 下好了,跑起來了,但是……慢得要命。一秒兩三個 token,甚至更慢。先別急著怪模型,大部分情況下調幾個參數就能快 5-10 倍。這篇幫你一步步排查和解決。
第一步:找到慢的原因
Gemma 4 慢通常就這五個原因,挨個排查。
原因一:CPU 在跑,GPU 在看
這是最常見的速度殺手。模型跑在 CPU 上,GPU 完全沒用上,但你可能根本沒發現。
怎麼檢查:
# Mac:看 GPU 有沒有在工作
sudo powermetrics --samplers gpu_power -n 1
# NVIDIA:使用率應該 > 0%
nvidia-smi
# AMD:同理
rocm-smi如果推論時 GPU 使用率一直是 0%,那就是在用 CPU 跑。先解決這個,其他都是白搭。
原因二:量化選錯了
不同量化對速度的影響非常大:
| 量化格式 | 檔案大小 (12B) | 速度 | 品質 | 適合情境 |
|---|---|---|---|---|
| Q4_K_M | ~7 GB | 最快 | 不錯 | 日常使用 |
| Q5_K_M | ~8.5 GB | 快 | 更好 | 對品質有要求 |
| Q6_K | ~10 GB | 中等 | 很好 | 平衡選擇 |
| Q8_0 | ~13 GB | 慢 | 接近原始 | 對品質敏感的任務 |
| FP16 | ~24 GB | 最慢 | 原始品質 | 顯存充足才用 |
| IQ4_XS | ~6 GB | 最快 | 可接受 | 顯存緊張 |
如果你在跑 Q8 或 FP16 還嫌慢,換成 Q4_K_M 試試。品質差別在大部分任務上感知不到,但速度差別是真的大。各量化等級的詳細比較看 GGUF 量化指南。
原因三:上下文開太長了
Gemma 4 支援 256K 上下文,但上下文越長推論越慢,而且不是線性的:
| 上下文長度 | 相對速度 | 顯存佔用 (12B Q4) |
|---|---|---|
| 2K | 1.0x(基準) | ~7 GB |
| 8K | ~0.9x | ~8 GB |
| 32K | ~0.7x | ~12 GB |
| 128K | ~0.4x | ~20 GB |
| 256K | ~0.25x | ~30 GB+ |
解決方法: 根據實際需要設上下文長度:
# Ollama:限制上下文
ollama run gemma4:12b --ctx-size 8192
# llama.cpp
./llama-server -m model.gguf -c 8192
# 不是真需要 256K 就別開 256K原因四:KV 快取膨脹
KV 快取存的是注意力資訊,對話越長快取越大,吃顯存還拖速度。
解決方法: 定期開新對話,或者量化快取:
# llama.cpp:量化 KV 快取
./llama-server -m model.gguf -c 8192 --cache-type-k q8_0 --cache-type-v q8_0
# 量化後的 KV 快取省顯存,品質損失很小原因五:批次處理大小不對
如果在做推論服務,批次處理參數不對會嚴重影響吞吐量:
# vLLM:調整批次處理
python -m vllm.entrypoints.openai.api_server \
--model google/gemma-4-12b-it \
--max-num-batched-tokens 4096 \
--max-num-seqs 8各平台最佳化
Mac(Apple Silicon)
Mac 上效能完全取決於 Metal GPU 加速是否正常:
# 檢查 Metal 支援
system_profiler SPDisplaysDataType | grep Metal
# Ollama 在 Apple Silicon 上自動用 Metal
# 如果還是慢,查記憶體壓力:
memory_pressure
# llama.cpp 確保開啟 Metal
cmake -B build -DGGML_METAL=ON
cmake --build build
# M 系列晶片推薦設定
./llama-server -m model.gguf -ngl 999 -c 8192| Mac 機型 | 統一記憶體 | 12B Q4 速度 | 備註 |
|---|---|---|---|
| M1 8GB | 8GB | ~12 tok/s | 能用但緊張 |
| M1 Pro 16GB | 16GB | ~18 tok/s | 舒服 |
| M2 Pro 16GB | 16GB | ~22 tok/s | 日常主力 |
| M3 Pro 18GB | 18GB | ~25 tok/s | 甜蜜點設定 |
| M3 Max 36GB | 36GB | ~30 tok/s | 能跑 27B Q4 |
| M4 Max 48GB | 48GB | ~35 tok/s | 什麼都能跑 |
Mac 小提醒: 跑大模型前關掉 Chrome 和 Docker。Apple Silicon 的 CPU 和 GPU 共用記憶體,沒有獨立顯存池。
Windows(NVIDIA CUDA)
# 確認 CUDA 在用
ollama ps
# Windows 常見問題:電源設定
# 改成「高效能」模式
# 筆電在「平衡」模式下 GPU 會瘋狂降頻
# llama.cpp Windows 編譯
cmake -B build -DGGML_CUDA=ON
cmake --build build --config ReleaseWindows 小提醒: 把模型目錄加到 Windows Defender 排除清單。即時掃描會掃每次檔案讀取,嚴重拖慢速度:
# PowerShell(系統管理員)
Add-MpPreference -ExclusionPath "C:\Users\你的使用者名稱\models"Linux(NVIDIA 或 AMD)
# NVIDIA:開啟持續模式
sudo nvidia-smi -pm 1
# 設定 GPU 最大效能
sudo nvidia-smi -ac 1215,1410 # 具體值看你的 GPU
# AMD:確認 ROCm 正常
rocm-smi快速加速清單
按這個清單過一遍:
1. [ ] GPU 加速在工作(不是 CPU 回退)
2. [ ] 在用 Q4_K_M 量化(除非對品質有極高要求)
3. [ ] 上下文長度設成實際需要的(不是預設 256K)
4. [ ] KV 快取已量化(--cache-type-k q8_0)
5. [ ] Flash Attention 已開啟(如果框架支援)
6. [ ] 關了吃記憶體的背景程式
7. [ ] 電源設定為「高效能」(筆電)
8. [ ] 裝了最新驅動程式有些「慢」是正常的
有時候 Gemma 4 慢是預期行為:
- 首 token 延遲:第一個 token 總是慢(在處理輸入),這是正常的
- 超長輸入:處理 10 萬 token 的輸入,不管怎樣都需要時間
- 27B 跑在 16GB 上:能跑但勉強,考慮換 12B
- 純 CPU 推論:沒有 GPU 就是 1-5 tok/s,這是 CPU 跑 LLM 的現實
如果不只是速度問題,還遇到了當機或報錯,看看疑難排解指南,有 OOM、GPU 偵測等各種問題的解決方案。
下一步
- 不確定硬體夠不夠? 看 硬體需求指南 了解最低和推薦設定
- 不知道選多大的模型? 看 Gemma 4 模型選擇指南 根據硬體選型號
- 想了解量化? 看 GGUF 量化指南 有詳細比較
加速最佳化說到底就是把基礎搞對。解決 CPU 回退、選對量化、設合理的上下文長度——這三件事搞定,90% 的速度問題就解決了。
Stop reading. Start building.
~/gemma4 $ Get hands-on with the models discussed in this guide. No deployment, no friction, 100% free playground.
Launch Playground />


