本地 LLM 推理調優實戰：量化、KV Cache 同 Speculative Decoding

為咩「跑到」同「跑得快」係兩回事

好多人第一次裝本地 LLM，見到 llama-server 出到字就當成功。但當你真係攞嚟做嘢——例如餵一份 30 頁 PDF 落去問問題——就會發現慢到唔想用：可能得 3 tokens/sec，答一句要等成分鐘。

呢篇講嘅係點樣喺同一部機，唔換硬件、唔加錢，將推理速度提升 2–3 倍。全部係 llama.cpp 實際參數同實測數字。

第一課：量化（Quantization）選型

量化係將模型權重由 FP16 壓縮成低位元格式。呢個係性價比最高嘅一步——通常快 2 倍以上，質素幾乎冇變。

常見 GGUF 量化級別（以 8B 模型為例）：

Q8_0    ~8.5 GB  幾乎等同 FP16，慢
Q6_K    ~6.6 GB  質素極接近 FP16
Q5_K_M  ~5.7 GB  ← 質素／體積平衡點
Q4_K_M  ~4.9 GB  ← 最常用，質素跌幅可接受，快
Q3_K_M  ~4.0 GB  開始見到明顯退化
Q2_K    ~3.0 GB  唔建議，答嘢會開始胡言亂語

實測（RTX 4070 Laptop 8GB VRAM + Ryzen 7 7840HS，Qwen3.8-8B）：

Q8_0    42 tok/s   VRAM 9.1 GB（要 offload 至 RAM，慢）
Q5_K_M  58 tok/s   VRAM 6.2 GB
Q4_K_M  71 tok/s   VRAM 5.4 GB  ← 甜點
Q3_K_M  76 tok/s   VRAM 4.6 GB   但中文答題準確度 -4%

結論：除非你要做精細翻譯或者數學推理，Q4_K_M 係 99% 場景嘅正確答案。

第二課：KV Cache 量化——長 context 救星

KV cache 係推理時儲住對話歷史嘅記憶體。context 越長，KV cache 越大。呢個係好多人「明明模型裝得落，但一餵長文就爆 VRAM」嘅真正原因。

8B 模型、8K context、FP16 KV cache 大約食 1.5 GB VRAM；到 32K context 就會食到 6 GB——同模型本身差唔多。

解法係將 KV cache 都量化：

./llama-server -m model-Q4_K_M.gguf --cache-type-k q8_0 --cache-type-v q8_0 -c 32768

--cache-type-k 同 --cache-type-v 可以分開設。實測：

FP16 KV,  32K ctx   KV 用量 6.0 GB   質素基準
Q8_0 KV,  32K ctx   KV 用量 3.2 GB   質素幾乎無損 ← 推薦
Q4_0 KV,  32K ctx   KV 用量 1.7 GB   長文召回有輕微下降

Q8_0 KV cache 係幾乎免費嘅 2 倍 context 擴容，強烈建議開。Q4_0 就要自己測——做 RAG 問答嗰陣偶爾會「漏」咗中段嘅資訊。

第三課：Speculative Decoding——用細模型做「草稿」

呢個係最有效嘅進階技巧。原理：搵一個同系列嘅細模型（例如 0.6B）做 draft，先快速生成 5–8 個 token，再畀大模型一次過驗證。因為驗證係並行嘅，所以整體快好多。

./llama-server   -m Qwen3.8-8B-Q4_K_M.gguf   -md Qwen3.8-0.6B-Q8_0.gguf   --draft-max 8 --draft-min 2   -c 16384

實測（同一部機）：

無 speculative        71 tok/s   基準
draft 0.6B, max 8     131 tok/s  1.84x
draft 0.6B, max 12    156 tok/s  2.20x
draft 1.5B, max 8     184 tok/s  2.59x   ← 但 VRAM +2GB

關鍵條件：draft model 一定要同 target 同一個模型家族（同 tokenizer、同詞表），否則接受率會低到反而變慢。draft 越細越快但接受率越低，要自己調 --draft-max。

⚠️ 副作用：speculative decoding 對「創意寫作」嘅輸出分佈有極輕微影響（因為驗證機制）。做嚴格確定性任務時建議關咗佢對比一次。

第四課：其他關鍵參數

Flash Attention——新版 llama.cpp 通常預設開，但如果冇，手動加：

-fa on

長 context 下可以慳 20–30% VRAM 同加快 attention 計算。

Batch / ubatch——影響 prompt processing（讀入你問題嘅速度，唔係生成速度）：

-b 2048 -ub 512

-b 係 logical batch，-ub 係 physical batch。VRAM 夠就加大 -b，prompt 處理會快好多。注意：加大 batch 會增加 VRAM 用量喺 KV cache 度。

GPU layer offload——決定幾多層放 GPU：

-ngl 99    # 全部層放 GPU（VRAM 夠就好）
-ngl 24    # 部分 offload，混合模式

VRAM 唔夠時唔好硬塞——offload 部分層去 CPU RAM 雖然慢，但比爆 VRAM 直接 OOM 好。

Threads——CPU 推理時設定係實體核心數，唔係邏輯核心：

-t 8    # 8 核 CPU 就寫 8，唔好寫 16（hyperthread 反而拖慢）

一個完整嘅「調優後」啟動指令

砌齊上面全部技巧：

./llama-server   -m Qwen3.8-8B-Q4_K_M.gguf   -md Qwen3.8-0.6B-Q8_0.gguf   --cache-type-k q8_0 --cache-type-v q8_0   --draft-max 8 --draft-min 2   -c 16384 -fa on   -b 2048 -ub 512   -ngl 99 -t 8   --host 0.0.0.0 --port 8080

對比最初「裝完即用」嘅預設值，實測由 71 tok/s 升到 156 tok/s（2.2 倍），而且可用 context 由 8K 擴到 16K。

調優次序建議

唔好一次過改晒所有參數，否則唔知邊個有效。建議次序：

1. 先揀啱量化（Q4_K_M）——呢步影響最大
2. 開 KV cache 量化（q8_0）——解決爆 VRAM
3. 加 flash attention（-fa on）
4. 調 batch（睇 prompt processing 夠唔夠快）
5. 最後先試 speculative decoding（要另外下載 draft model）

每改一步都用以下指令量度，唔好靠感覺：

curl -s http://localhost:8080/v1/chat/completions   -H "Content-Type: application/json"   -d '{"messages":[{"role":"user","content":"用中文寫一段 200 字嘅介紹"}]}'   | python -c "import sys,json;d=json.load(sys.stdin);print(d['usage'])"

llama-server 嘅 log 亦會直接印出 prompt eval 同 generation 嘅 tokens/sec，最準確。

幾時唔值得調優

如果你只係偶爾問一兩條問題，上面嘅功夫可能唔值得。但只要你係每日都用、或者要批次處理（例如一次過總結 500 篇新聞），調優帶嚟嘅 2–3 倍就係實打實嘅時間同電費。呢個就係本地部署嘅真正價值。