GGUF 量化完整教學 2026：Q4_K_M、Q5_K_M、Q8_0 差在哪？VRAM 怎麼算？27B 模型實測 4-bit 幾乎無損、1-bit 直接崩潰

GGUF 是目前開源 LLM 本機執行最通用的檔案格式，量化就是把模型從 16-bit 壓到 8/5/4/2/1-bit 以省下記憶體。實測與社群共識一致：Q4_K_M（4-bit）在絕大多數任務上幾乎無感，是「8GB 顯卡跑 7B、24GB 顯卡跑 27B」的甜蜜點；再往下到 1-bit 品質會斷崖式崩潰，接近亂猜。

如果你玩過 Ollama、LM Studio 或 llama.cpp，一定看過檔名尾巴那串神秘代號：Q4_K_M、Q5_K_S、Q8_0、IQ2_XS……它們就是「GGUF 量化格式」的命名。同一顆模型，未壓縮要 55GB、壓成 4-bit 只要 17GB——但代價是什麼？怎麼選才不會讓模型「變笨」？這篇一次講清楚，最後附上 27B 模型的真實基準數據。

30 秒結論：你的顯示卡該選哪個

一句話：預算夠就 Q6_K 以上，記憶體吃緊就 Q4_K_M，非必要別碰 2-bit 以下。

GGUF 是什麼？

GGUF（GPT-Generated Unified Format） 是 llama.cpp 團隊在 2023 年推出的模型封裝格式，取代舊版 GGML，如今是開源本機推理的「事實標準」。它把權重、模型設定、tokenizer、特殊 token、提示詞模板全部包進一個 .gguf 檔，從此不用再湊一堆 json + safetensors 碎片。

三個關鍵設計：

• 單檔封裝：一個檔就是一個模型，管理超方便；
• mmap 零拷貝載入：檔案採嚴格的位元組對齊，可以直接映射進記憶體、按需讀取，大幅縮短啟動時間；
• 跨平台：同一顆 .gguf 檔，CPU、NVIDIA（CUDA）、AMD（ROCm）、Apple Silicon（Metal）通吃。

量化原理白話文：把 16-bit 小數塞進 4-bit 整數

原始模型權重通常用 FP16/BF16（16-bit 浮點數） 儲存，每個參數佔 2 bytes。量化就是用數學方法，把權重對應到更少的整數刻度——8-bit、5-bit、4-bit、甚至 2-bit/1-bit——再記一組「縮放係數」把它還原回來。

llama.cpp 的做法是分塊量化：每 32 個權重當一組，各自算縮放參數，減少精度損失。更進階的 K-quants（超級塊量化） 則把 256 個權重當一個 super-block，內部再分 8 個子塊，對敏感的注意力層保留較高精度、對不敏感的 FFN 層大力壓縮——這就是為什麼 Q4_K_M 品質能逼近原版的原因。

衡量壓縮程度的單位叫 bpw（bits per weight）：Q4_K_M 約 4.5～4.8 bpw，Q8_0 約 8.5 bpw，Q2_K 約 2.5 bpw。檔案大小約等於 參數量 × bpw ÷ 8。

主流量化格式比較表

* 以 7B 模型粗略估算（實際依架構略異）。Unsloth 等第三方另提供 UD（Dynamic）+ imatrix 優化版本，2-bit 品質比傳統 Q2_K 好，但 1-bit 依然救不回來。

VRAM 怎麼算？別忘了 KV Cache 這個隱藏大戶

純權重的粗略公式很簡單：

權重記憶體 (GB) ≈ 模型參數量 (B) × bpw ÷ 8

例如 7B 模型用 Q4_K_M：7 × 4.5 ÷ 8 ≈ 3.9 GB；70B 用 Q4 則約 35GB（實際檔案含 overhead 會再大一點）。

但實測執行時還有四大隱藏開銷，忘掉任何一個都可能 OOM 或溢出到 CPU 拖慢速度：

1. KV Cache（最容易被忽略）：存放對話歷史，隨上下文長度線性增加。以 27B 模型為例，32K 上下文約需 2GB、64K 約 4GB（Qwen 3 系列因 GQA 分組查詢已經算省的了）。可以用 --cache-type-k q8_0 --cache-type-v q8_0 對 KV Cache 做 8-bit 量化，直接省一半；
2. 框架底層開銷：CUDA/驅動約固定吃 0.75GB；
3. 並行請求：每多一個並發使用者/Agent 就要多一組 KV Cache（約 0.5～2GB）；
4. 桌面顯示預留：視窗環境約吃 0.5～1GB。

實戰範例（Qwen3.8-27B Q4_K_M 實測）：模型檔 17GB、開 64K 上下文，總共約 20GB——所以 24GB 的 RTX 4090 剛好跑得動，這正是它在社群被稱為「27B 甜蜜點卡」的原因。

實戰：用 llama.cpp 把 Hugging Face 模型轉成 GGUF 並量化

兩個階段：先轉成 FP16/BF16 的 raw GGUF，再用量化工具壓縮。

# 1. 安裝 llama.cpp（原始碼：https://github.com/ggml-org/llama.cpp）
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
pip install -r requirements.txt

# 2. 編譯（Windows 用戶可直接抓 Releases 的預編譯包，內含 llama-quantize.exe）
cmake -B build && cmake --build build --config Release -j

# 3. 把 Hugging Face 模型轉成 BF16 GGUF（直接吃遠端 repo，或先下載改傳本機路徑）
python convert_hf_to_gguf.py --outfile model-bf16.gguf --outtype bf16 --remote 你的帳號/你的模型

# 4. 量化成 Q4_K_M
./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M

# 5. 開跑
./build/bin/llama-cli -m model-Q4_K_M.gguf -p "用一句話解釋什麼是流體力學"

進階：用 imatrix 提升低位元品質（IQ 系列建議必做）：

# 先跑一次校準文本，算出每個張量的「重要性矩陣」
./build/bin/llama-imatrix -m model-bf16.gguf -f imatrix_dataset.txt -o model.imatrix
# 再帶入量化指令
./build/bin/llama-quantize --imatrix model.imatrix model-bf16.gguf model-IQ4_XS.gguf IQ4_XS

懶人路線：Ollama、LM Studio、Open WebUI 這類工具會自動幫你下載社群做好的 GGUF 量化檔（例如 Hugging Face 上的 unsloth/Qwen3.8-27B-GGUF，一個 repo 就附 Q8_0、Q4_K_M、Q2、1-bit 全套），完全不用自己轉。

實測數據：4-bit 幾乎無損，1-bit 直接崩潰

2026 年 9 月，Quesma 團隊把 Qwen3.8-27B 用 Unsloth 的 GGUF 量化版跑了一輪真實基準（GPQA Diamond 科學問答、IFBench 指令遵循、Terminal-Bench 2.1 代理寫程式），結論非常清楚：

關鍵發現：

1. 4-bit 是黃金甜蜜點：Q4_K_M 在寫程式基準上與 55GB 原版完全相同，17GB 也剛好塞進 24GB 顯卡；
2. 損傷是非線性的：先無感 → 小跌（2-bit）→ 斷崖崩潰（1-bit）。Red Hat 用 50 萬次任務的大規模測試也得出一致結論：Q8_0 精度恢復 >99.5%、Q4_K_M 約 98.9%；
3. 1-bit 是宣傳話術的重災區：Unsloth 宣稱 1-bit 保留「72% top-1 準確率」——但剩下那 28% 剛好都是關鍵 token。實測中 1-bit 在 GPQA Diamond 掉到隨機水準，而且思考越久越糟（reasoning token 燒完回傳空白答案）；
4. 困惑度（perplexity）佐證：Llama-2 7B 的 WikiText 實測，FP16 為 13.0000，Q8_0 13.0004、Q6_K 13.0044、Q4_K_M 13.0535——4-bit 的困惑度增加幾乎可以忽略；但壓到 Q2_K 會暴增到 23.6（+92%），就是大家常說的「模型變笨了」。

flowchart TD
    A["你的 GPU 有多少 VRAM？"] --> B{"8–12 GB"}
    A --> C{"16 GB"}
    A --> D{"24 GB"}
    B --> B1["7B–14B 模型<br>選 Q4_K_M（記憶體 8GB 以下別碰 Q5+）"]
    C --> C1["14B 以下可選 Q5_K_M / Q6_K<br>要跑 27B 就 Q4_K_M"]
    D --> D1["27B 選 Q4_K_M（17GB）<br>可開 64K 上下文；<br>32B MoE 可試 Q4/Q5"]
    B1 --> E["跑得順嗎？"]
    C1 --> E
    D1 --> E
    E -- "順，且想再提升品質" --> F["升級 Q5_K_M / Q6_K<br>（記憶體還夠的話）"]
    E -- "OOM 或太慢" --> G["降一階：Q4_K_M → Q3 →<br>或換更小模型（勿迷信 1-bit）"]

常見迷思

Q：量化後的模型是不是一定比較笨？ A：4-bit（Q4_K_M）在實測與日常使用上幾乎無感——27B 的 Q4 甚至比原版 7B 更聰明。真正會「變笨」的是 2-bit 以下。與其用 1-bit 硬塞大模型，不如選小一點但量化輕的模型。

Q：為什麼 1-bit 檔案那麼小卻沒人推薦？ A：1-bit 把每個權重壓到只剩 1～2 個刻度，注意力層的關鍵權重全部失真。基準分數直接掉到隨機水準，省下來的 10GB 記憶體換來的是「會回話但內容接近亂講」的模型。

Q：Ollama 預設用的是什麼量化？ A：Ollama 通常預設抓 Q4_K_M，對多數人已經是最好的平衡；想要更好品質，可以在模型頁面指名 :q5_k_m、:q8_0 等 tag（例如 ollama run qwen3:27b-q4_K_M）。

資料來源

• Quesma：Benchmarking Qwen3.8 27B quantizations – 4-bit holds up, 1-bit collapses
• llama.cpp 官方量化文件（tools/quantize README）
• Unsloth Qwen3.8-27B GGUF（Hugging Face）
• Kaitchup：How to Quantize a Model to GGUF with llama.cpp

延伸閱讀

• Ollama：以類 Docker 簡潔風格在本機執行開源 LLM
• Open WebUI：自託管類 ChatGPT 介面，讓本機 LLM 更易用
• ik_llama.cpp：具有 IQ4_NL 和進階量化的 llama.cpp 分支
• Meta Muse Glimmer 開源了！30B 本地 AI Agent 模型，Apache 2.0 授權、24GB 顯示卡就能跑（2026）