【2026 最新】GGUF 量化怎麼選？Q4／Q6／Q8、KV Cache 與品質懸崖實測

GGUF 量化最常見的錯誤，不是選了 Q4，而是把所有寫著 Q4 的檔案當成同一件事。同樣叫 Q4，實際 tensor 配方、檔案大小、KV Cache、Context、backend 與硬體 kernel 都可能不同；結果就是一台機器跑得飛快，換一台卻更慢，聊天看似正常，JSON、長文找針或程式題卻突然崩掉。

這篇專為第一次在本機跑 LLM 的讀者寫。我會先把 GGUF、K-quants、IQ、AWQ、NVFP4、QAT 與 KV Cache 放回正確層級，再用同一份 F16 原始檔現場量成 Q4_K_M、Q6_K、Q8_0，在 16GB Apple Silicon 上比較檔案、prefill、decode、Context 記憶體與固定 10 題回歸測試。最後不是頒發「唯一最佳量化」，而是交給你一棵可複做的選擇樹。

GGUF 量化先說結論：別先問 Q4 還是 Q6

• 先選模型與 checkpoint：若高精度基線連你的任務都做不到，任何 Q4／Q6 比較都沒有意義。
• 再選權重量化：一般可先試 Q4_K_M；若 coding、JSON、長文或多語回歸跌太多，再升 Q6_K、Q8_0，而不是把網路口訣當定律。
• KV Cache 是另一顆旋鈕：GGUF 權重是 Q4，不代表 KV 也是 Q4。Context 越長、同時對話越多，KV 才越值得量化。
• 檔案小不等於一定快：本機 Metal 實測中，量化權重加速 decode，卻沒有加速 512-token prefill；量化 KV 省下記憶體，也讓這組長 Context 測試變慢。
• QAT 要看訓練目標：weight-QAT checkpoint 不會自動抵抗任意 KV dtype；只有訓練時模擬相符量化路徑，才有理由期待保護。

請記住這條式子：量化選擇＝checkpoint × 權重 recipe × KV dtype × Context／slots × backend／hardware。少寫一項，通常就不是可比較的實驗。容量則用另一條：可用記憶體 ≥ 常駐權重＋KV Cache×同時對話數＋compute／runtime 餘量。

GGUF 是行李箱，Q4_K_M 才是打包方法

GGUF 規格把模型 tensor 與 metadata 放進可快速載入、mmap 的二進位容器。換句話說，GGUF 像行李箱；箱內可以裝 F16、Q8_0、Q6_K、Q4_K 或混合 tensor。看到副檔名 .gguf，你只知道容器，不知道品質。

K-quants：Q4_K_M 其實是「mostly Q4」配方

K-quants 會在一個 super-block 內替小區塊保存 scale／min，不是把每個權重獨立塞進剛好四個 bit。更重要的是，目前 llama.cpp 的 Q4_K_M recipe會依架構與 tensor 用途，把部分 attention、FFN、output 或 embedding 升成 Q5_K、Q6_K，尺寸不相容時還會 fallback 到其他型別。因此 Q4_K_M是整體 preset，不是「每顆權重都是 4-bit」。目前 CLI 中 Q4_K也是 Q4_K_M的 alias。

llama.cpp 自己列出的 Llama 3.1 8B 範例中，Q4_K_M 是 4.8944 effective bpw、Q6_K 是 6.5633、Q8_0 是 8.5008；那只是指定模型與版本的例子。你應優先讀實際檔案 bytes，並用 gguf_dump.py檢查 tensor，而不是把名稱中的數字直接乘參數量。也不要拿 Q8 再量成 Q4：官方量化文件明確警告 requantization 可能比從 16／32-bit 原檔開始造成更嚴重的品質損失。

IQ、imatrix、AWQ、NVFP4、QAT 差在哪？

• IQ quants：llama.cpp 的另一族低位元 tensor encoding，會用非線性 grid／codebook；極低位元配方常搭 importance matrix，但 IQ 不等於 AWQ。
• imatrix：llama-imatrix以校正文字跑推論，用 activation² 累積哪些權重較重要，再協助分配量化誤差。校正資料若離你的任務太遠，配方名稱漂亮也不代表適合。
• AWQ：Activation-aware Weight Quantization是 PTQ（訓練完才量化）方法，利用 activation statistics 找敏感 channel，再用等價 scaling 降低 weight-only 低位元誤差。activation-aware 不等於把 activation 也量化。
• NVFP4：NVIDIA Blackwell 的 E2M1 4-bit 值加上兩層 scaling recipe；NVIDIA 的格式說明計入每 16 個值共用的 FP8 scale 後約為 4.5 bits/value，並非無 overhead 的 4.0。它和 GGUF不是同一分類層級，也不能把不同 engine 的速度差全歸因於格式。
• QAT：Quantization-Aware Training 在訓練／微調時插入 fake quant，讓模型提前看見 rounding 與 clipping 噪音。它是訓練歷史，不是檔案格式；部署時仍要問它究竟模擬了 weight、activation 還是 KV。

權重、KV Cache、Context：記憶體怎麼估？

權重可以先用 參數量 × effective bpw ÷ 8估算，但最可靠的仍是實際 GGUF 檔案與 runtime loader。因為 tokenizer metadata、對齊、未量化 tensor、混合精度與部分 GPU offload 都會讓「參數×bit」失準。想先看懂推論時權重、KV 與 compute buffer 各做什麼，可搭配 LLM 推論引擎白話教學。

傳統 decoder-only、各層 K／V 維度相同時，單一 stream 可簡化成：

KV bytes ≈ Context tokens × Layers × n_kv_heads
           × (K head_dim × K bytes + V head_dim × V bytes)

總記憶體 ≈ 常駐權重 + KV × slots + graph/compute/runtime buffer

這條式子也解釋為什麼 Context 從 4K 升到 8K，KV 預算近似翻倍，權重卻不變。GQA／MQA、sliding-window、hybrid attention、MLA、state-space、每層不同 head 維度與 residual cache 都會改寫公式，所以它只拿來排預算；最後看啟動 log、llama-fit-params與實際峰值。Hugging Face 的 worked example中，Llama 2 7B 在 10K tokens、FP16 KV 約需 5GB，正是長 Context 會突然把顯存吃滿的原因。

llama.cpp 的權重名稱與 KV 名稱不要混用。截至本次測試的 commit，-ctk與-ctv可選 f16、q8_0、q4_0等，但沒有 q4_k_m或q6_k；量化 V Cache 還需要 Flash Attention。詳細限制可查同版 server 文件。

同機實測：Q4／Q6／Q8 到底差多少？

測試機是 Apple M4 Mac mini（10-core、16GB unified memory），Metal 全 offload。llama.cpp 固定在 commit 1f368f354d9edcfea9fd6a1e0989b3e7335a050f，來源是 HuggingFaceTB 的 SmolLM2-135M-Instruct F16 GGUF，由指定 Unsloth revision提供；來源 SHA-256 為 5157ca60744d21631818364854ac8e4452e1b8022d2ab4c8a2f9cda2344afb30。三個檔都直接從同一份 F16 產生、未用 imatrix：

./llama-quantize model-F16.gguf model-Q4_K_M.gguf Q4_K_M 8
./llama-quantize model-F16.gguf model-Q6_K.gguf   Q6_K 8
./llama-quantize model-F16.gguf model-Q8_0.gguf   Q8_0 8

最意外的不是速度，而是量化器警告：這個模型大量 tensor 的 576 columns 無法整除 K-quant 所需 block，Q4 recipe 多次 fallback 到 q5_0／q8_0，Q6 也大量 fallback 到 q8_0。最後 Q4_K_M 是 6.17 bpw、Q6_K 是 8.12 bpw，兩者都遠高於名稱給人的直覺。實際檔案由 F16 258.34MiB 降為 100.57、131.97、138.10MiB。

llama-bench固定 F16 KV、512-token prefill、128-token decode、5 次 repetitions。Q4 的 decode 為 328.1 tok/s，較 F16 的 226.2 高；但 prefill 是 10,138.6 tok/s，反而低於 F16 的 11,169.7。這只代表這顆小模型、這版 Metal kernel；它不能變成「Q4 一定快」或「F16 prefill 永遠快」的規則。若你在 Apple Silicon 跑較大模型，可接著看 Metal 與 Apple Silicon 本機推論實測。

固定 Q6 權重，只換 KV Cache

下一輪鎖住 Q6_K 權重，Context 4,096、單 slot、Flash Attention，只把 K／V 同時由 f16 改成 q8_0、q4_0。llama-fit-params估出的裝置 KV 從 90MiB 降到 47MiB、25MiB；Context 8,192 時則是 180、95、50MiB。實測 idle RSS 也由 287.3MiB 降至 248.1、226.1MiB。這裡說的是整個 process 的 Apple unified-memory RSS，不是假裝可分離的「純 VRAM」。

把 decode depth 放到 4,096 後，F16／Q8／Q4 KV 的速度是 238.4／223.4／220.0 tok/s；prefill 也由 F16 的 4,690.3 降到 2,609.4／2,722.3 tok/s。這就是「bit 越低不一定越快」：當 kernel 的 dequant／packing 成本大於少搬資料的收益，壓縮只解決容量。短 Context 本來就放得下時，應優先保留 F16 KV；長 Context 或多 slots 真的卡記憶體，再用同機數字決定是否交換。

固定 10 組 prompts：怎麼找品質懸崖？

「品質懸崖」不是公認的 Q4 或 Q3 分界。本文把它操作化定義為：量化只降一階，固定任務的 pass rate、schema contract 或 long-context recall 卻出現不成比例跳跌。位置會跟模型、任務、recipe、校正資料與 backend 一起移動。

1. 精確算術：必須輸出指定數值與格式。
2. 邏輯排序：四人唯一順序。
3. JSON/schema：不開 grammar，直接檢查能否 parse、鍵與型別。
4. 資料內 prompt injection：不得服從被引號包住的惡意 note。
5. 程式除錯：只改造成 TypeError 的一行。
6. 摘要忠實：保留否定句，不能把未定項全怪給模型。
7. 短紀錄 needle：找回核准碼與 owner。
8. 日文轉繁中：測否定與時間方向。
9. 資訊不足：不得亂算淨利率。
10. 長 Context：在 10%、50%、90% 深度找三個值並求和。

所有權重版本使用同一 chat template、temperature=0、seed 42、128 output tokens；長文題用同一份 8,018-token prompt，SHA-256 為 b9fa926bd80d4eb8937bcafd43c7b2e787bff53cb57e17168501d5bafc414560。每題依事先定義的數值、結構與格式 contract 判定 pass／fail，先跑 F16，再輪到 Q8、Q6、Q4。這是固定採樣設定的 regression control，不代表一般抽樣聊天的品質。

這次品質比較被基線 gate 擋下：F16 在十題都沒有產生符合 contract 的答案，主要是重複題目或續寫資料，strict pass 為 0／10；三個量化版也都是 0／10。因此正確結論不是「Q4 跟 F16 一樣好」，而是「135M checkpoint 不適合這套任務，無法用它定位量化懸崖」。這個負結果比硬湊排名更重要：先替高精度基線設定可接受門檻，例如十題至少通過九題，再看 quant 相對掉多少。若你的任務是 tool calling，還應像 離線工具呼叫實測一樣，直接驗證 schema 與執行結果。

大型模型在哪裡真的出現過懸崖？

公開案例給了三種不同答案。第一，LFM2.5-2.6B 的可複做報告在 RTX 3080、BeeLlama fork、WikiText 32K 下發現某些 provider 的 Q4_K_M 異常，Bartowski 檔卻不受影響。這證明的是 recipe／provider 差異，不是 Q4_K_M 普遍有毒；128K 記憶體是外推，Raspberry Pi 只有容量推算，速度來自 RTX 3080。

第二，Qwen3.6 27B 的16 種 quant 比較用作者自有的 100 組 structured-agent 對話觀察到，該資料集的 Q5 位在較佳 loaded-GiB frontier；但截至 2026 年 8 月 13 日，作者公開頁面未列完整 prompts、硬體、engine commit 與完整程式，跨 engine baseline 也不同，所以不能升格為「Q5 永遠甜蜜點」或「GGUF 一定勝 NVFP4」。

第三，Gemma 4 31B 的社群 QAT／KV 測試在 RTX 3090、BeeLlama、單次 WikiText teacher forcing 中，官方 QAT Q4_0 checkpoint 對 KV 量化明顯較不敏感。可是兩個 checkpoint 各自對自己的 baseline，比的是 cache sensitivity，不是絕對模型品質；截至 2026 年 8 月 13 日，我查到的 Google 官方 Gemma 文件也未描述該 checkpoint 採用專門的 KV-aware objective。較嚴格的證據來自LLM-QAT：它在訓練中真的量化 W、A、K、V，LLaMA-7B 的 W4-A8-KV4 八項平均由一般 RTN 的 41.2 回到 63.0，而 FP16 是 66.2。結論應是「targeted KV-aware QAT 有效」，不是「任何 QAT 都讓 Q4 KV 安全」。

長 Context 又是另一個敏感面。EMNLP 2025 的長文量化研究在其模型、方法與至少 64K 的任務中，8-bit 平均影響很小，但 4-bit 在部分長文任務最多可跌 59%，同一方法在不同模型也可能相差約 32 個百分點。它研究的是 weight quant，不是 KV-Q4；真正有用的教訓是：短聊天沒壞，不能證明 64K retrieval 沒有 cliff。

GGUF 量化決策樹：照硬體與任務選

情境一：記憶體只夠一個版本

先算目標 Context 與 slot，而不是下載最大的可見檔。若 Q6 加 F16 KV 留不出 runtime 餘量，就先試 Q4_K_M＋F16 KV；如果長 Context 才 OOM，可先保留權重品質、把 KV 改 q8_0。只有 q8_0 仍放不下，才測 q4_0，並加入長文 retrieval 回歸。大型 30B 本機部署可參考 Muse Glimmer 30B 硬體與 Context 配置，看「檔案放得下」為什麼不等於整條 pipeline 跑得穩。

情境二：Q4 過不了任務

先確認不是 chat template、thinking、context truncation 或第三方壞檔，再用同一 F16 source 產生 Q6。Q6 若恢復 contract，就接受容量交換；若 Q8 也失敗，問題更可能在 checkpoint 或任務，而不是 bit 數。imatrix／IQ 可以成為另一條實驗 lane，但不能和「只換 bit」混在同一因果結論。

情境三：2-bit 大模型 vs 4-bit 小模型

比較必須是 iso-total-memory：權重、目標 Context 的 KV、runtime overhead 都要算，還要固定 backend 與硬體 kernel。ParetoQ確實在 bit-specific QAT 與部分等有效 model size frontier 中，看到 2-bit 較大模型勝 4-bit 較小模型；但範圍是 MobileLLM 與 Llama 1B／3B／8B，不是一般下載的 PTQ Q2 GGUF，更不是「Q2 70B 必勝 Q4 35B」。如果 kernel 對 INT2 不成熟，多出的參數也可能被速度與 runtime 成本抵銷。

可直接複製的 llama.cpp A／B 流程

第一輪隔離權重：F16／BF16 → Q8_0 → Q6_K → Q4_K_M，KV 全固定 F16。第二輪鎖住一個權重檔，再把 KV 由 F16 → q8_0 → q4_0。第三輪才改 Context。新版 llama.cpp 的 --fit預設開啟，可能自動改 placement 或 Context；比較時務必關掉：

./llama-server \
  -m model-Q6_K.gguf \
  -c 32768 -np 1 -ngl all \
  --fit off --no-cache-prompt \
  -fa on -ctk q8_0 -ctv q8_0 \
  --metrics

速度分開量 prefill 與 decode；llama-bench不含 tokenization 與 sampling，所以不要把它叫完整端到端延遲。品質先看 task pass／schema，再看 PPL、KLD 或 same-top 作診斷；llama.cpp 也提醒不同模型／tokenizer 的 PPL 不可直接橫比。每個 artifact 至少保存 source SHA、quant SHA、llama.cpp commit、build backend、完整命令、prompt SHA、raw output 與實際 Context。

GGUF 量化常見問題 FAQ

Q1：新手是不是直接選 Q4_K_M？

可以當第一個候選，不能當答案。先確認來源可信、Context 放得下，再用自己的任務對 F16／Q8 或較高精度基線做回歸。

Q2：Q8_0 等於無損嗎？

不等於 bit-exact 無損。它在許多同模型指標上會接近高精度，但仍經 rounding；任務是否等價要測，不能只看「Q8」。

Q3：Q6_K 一定比 Q4_K_M 慢嗎？

不一定。速度取決於 backend kernel、packing、memory bandwidth、prefill／decode 與實際 tensor fallback。本機小模型實測兩者 decode 只差約 1%。

Q4：權重 Q4 時，KV Cache 也是 Q4 嗎？

不是。llama.cpp 預設 KV 是 F16；K、V dtype 由 runtime 的 -ctk、-ctv獨立決定。

Q5：KV q4_0 會剛好省四倍嗎？

不會剛好。q4_0 的 block 還有 scale，實際是 4.5 bpw；再加 padding、allocator 與 compute buffer，整個 process 更不會整齊縮成四分之一。

Q6：QAT 模型一定更耐 KV 量化嗎？

不一定。先讀 model card／paper，確認訓練是否模擬相符的 KV scheme；只做 weight-QAT，不能自動推出 KV robustness。

Q7：AWQ、NVFP4 可以跟 GGUF 直接比嗎？

品質可做 full-stack A／B，分類不能混在一起。GGUF 是容器，AWQ 是 PTQ 方法，NVFP4 是數值格式與 scaling recipe。若各用不同 engine，速度差必須標成完整 stack，不可只怪 quantizer。

Q8：只跑 10 題就能決定量化嗎？

只能篩選，不能定論。10 題適合抓 contract failure；重要部署還要加標準 eval、多 seeds、真實長文、可執行測試、PPL／KLD 與盲評。

給新手的五個帶走重點

1. GGUF 是容器，Q4_K_M 是 mostly-Q4 recipe。
2. 先讓高精度 checkpoint 通過任務，再談量化相對損失。
3. 權重與 KV 分兩輪測，Context 最後改。
4. 容量、prefill、decode、品質是四個獨立指標。
5. 只在相同模型、commit、backend、硬體與 prompts 內下結論。

想把這套方法變成自己的本機模型驗收流程，可以先複製十題，把 JSON schema、程式測試與長文 needle 換成你的真實工作，再從最高精度一路往下量。若想系統化學會模型選型、推論與 Agent 工作流，也可以查看 AlphaLab AI 課程。