# 量化是什麼？Q4_K_M、Q8_0、FP16 差在哪，記憶體與品質怎麼取捨

> 地端世界 · https://onpremworld.com/zh-tw/guides/quantization-explained · 更新日期: 2026-10-14 · CC BY 4.0

**量化，就是用更少的位元來存模型的每一個權重：模型變小、跑得更快，代價是一點點品質。** 模型原本的權重通常是 16 位元（FP16 或 BF16）。Q8_0 每個權重約 8.5 位元，大小約為原本的一半，公開實測中和原始模型幾乎分不出差別。Q4_K_M 每個權重約 4.85 位元，不到原本的三分之一，品質損失很小，日常使用大多感覺不出來。低於 4 位元之後，品質就會快速下滑。這就是為什麼幾乎所有工具都預設 Q4_K_M，也是一般建議的由來：先用 Q4_K_M，記憶體有餘裕就升到 Q5_K_M、Q6_K 或 Q8_0；除非不量化到 4 位元以下就完全跑不動，否則別往下降。本站每個[模型頁面](https://onpremworld.com/zh-tw/models.md)和[「跑得動嗎？」試算](https://onpremworld.com/zh-tw/can-i-run.md)的記憶體數字，都是依量化等級分別計算的。

## 量化在做什麼

一個模型就是數十億個數字。模型開發者發布的檔案裡，每個數字通常是 16 位元浮點數：FP16，或保留 float32 指數範圍、但尾數較少的 BF16。量化把這些數字換成低位元的整數，再搭配每一小塊權重共用的縮放係數。模型執行時，每個權重會以「整數 × 該區塊的縮放係數」還原，結果很接近、但不完全等於原本的值。

省下的空間很直接：權重記憶體＝參數量 × 每權重位元數 ÷ 8。

| 量化 | 每權重位元數 | [Llama 3.1 8B Instruct](https://onpremworld.com/zh-tw/models/llama-3.1-8b.md) | [Qwen3-32B](https://onpremworld.com/zh-tw/models/qwen3-32b.md) | [Llama 3.3 70B Instruct](https://onpremworld.com/zh-tw/models/llama-3.3-70b.md) |
|---|---:|---:|---:|---:|
| Q4_K_M | 4.85 | 4.5 GiB | 18.5 GiB | 39.5 GiB |
| Q5_K_M | 5.69 | 5.3 GiB | 21.7 GiB | 46.4 GiB |
| Q6_K | 6.59 | 6.1 GiB | 25.2 GiB | 53.7 GiB |
| Q8_0 | 8.5 | 7.9 GiB | 32.5 GiB | 69.3 GiB |
| FP16 | 16 | 14.9 GiB | 61.1 GiB | 130.4 GiB |

*以上為依本站[估算方法](https://onpremworld.com/zh-tw/methodology.md)算出的估計值，資料日期 2026-10-16。實際速度會因執行環境、驅動程式與提示詞長度而不同。*

這張表就是「70B 模型需要資料中心等級 GPU」和「70B 模型放得進 64 GB Mac」之間的差別。表中的每權重位元數是本站[估算方法](https://onpremworld.com/zh-tw/methodology.md)採用的平均值；實際檔案會因各模型張量形狀不同而略有出入。

## 看懂量化名稱

這些名稱來自 llama.cpp 的 GGUF 格式，也就是本地模型最常見的格式：

- **Q** 代表量化，後面的**數字**是主要位元數：Q4 是 4 位元，Q8 是 8 位元。
- **K** 代表 llama.cpp 在 2023 年（PR #1684）推出的 K-quant 方案：權重被分組成「超級區塊」，連每個小區塊的縮放係數也一起量化。Hugging Face 的 GGUF 文件說明，Q4_K 的區塊格式換算下來是每權重 4.5 位元，Q6_K 則是 6.5625 位元。
- **S、M、L**（小、中、大）表示有多少張量被提升到較高位元數。Q4_K_S 全部維持 4 位元；Q4_K_M 則把部分最敏感的張量（注意力層的 value 投影與前饋層的 down 投影中的一部分）存成 6 位元，所以平均位元數略高於 4.5。
- **_0、_1**（例如 Q4_0、Q8_0）是較舊、較簡單的格式。Hugging Face 把它們列為舊式（legacy），但 Q8_0 仍是 8 位元的標準選擇。
- **IQ** 系列（IQ2_XS、IQ3_M、IQ4_XS 等）搭配重要性矩陣與非線性量化格點，在極低位元數下保住品質。
- **F16／FP16 與 BF16** 則是未量化的 16 位元權重。

## 品質會掉多少

llama.cpp 針對 Llama 3 8B 公布了詳細的實測：在 Wikitext-2 測試集上的困惑度（perplexity，越低越好）、相對 FP16 增加多少，以及 KL 散度（衡量量化後模型預測的機率分布偏離原始模型多遠）：

| 量化 | 大小（GiB） | 困惑度 | 相對 FP16 增加 | KL 散度 |
|---|---:|---:|---:|---:|
| FP16 | 14.97 | 6.2332 | – | – |
| Q8_0 | 7.96 | 6.2343 | +0.0027 | 0.0014 |
| Q6_K | 6.14 | 6.2534 | +0.0217 | 0.0055 |
| Q5_K_M | 5.33 | 6.2886 | +0.0570 | 0.0108 |
| Q4_K_M | 4.58 | 6.4071 | +0.1755 | 0.0313 |
| Q4_0 | 4.34 | 6.7001 | +0.4685 | 0.0719 |
| Q3_K_M | 3.74 | 6.8885 | +0.6569 | 0.1019 |
| Q2_K | 2.96 | 9.7516 | +3.5199 | 0.4451 |

*資料來源：llama.cpp perplexity README 的「LLaMA 3 8b Scoreboard」（未使用重要性矩陣），以 RTX 4090 量測。*

換個角度看：同一頁也公布了量化模型選出「和 FP16 相同的最可能下一個 token」的比例，Q8_0 是 97.7%，Q6_K 是 96.0%，Q4_K_M 是 91.9%，Q2_K 只剩 71.1%。品質曲線在 4 位元以上很平緩，低於 4 位元就急轉直下。另外也可以注意到，Q4_K_M 和舊式的 Q4_0 檔案大小差不多，品質損失卻不到後者的一半：K-quant 的混合配置確實有差。

解讀這些數字時，有三點要記得：

1. **這只是一個模型的結果。** llama.cpp 文件自己也提醒，不同模型的困惑度不能直接比較，而且 Llama 3 量化後的損失比 Llama 2 大。
2. **模型越大，越耐得住量化。** Qwen 官方文件用 MMLU、C-Eval、IFEval 測試 Qwen2 系列：72B 的 4 位元 GPTQ 平均 81.2 分，BF16 是 81.3 分，幾乎沒差；7B 則從 66.9 掉到 64.1；0.5B 從 34.4 掉到 29.7。
3. **困惑度不等於好不好用。** 精確數字、訓練資料較少的語言（對部分模型來說，繁體中文可能也屬於這類）或長串推理這類細節，可能在基準平均分數還沒變之前就先受影響。對你很重要的任務，請用你打算採用的量化版本實際測一下。

如果想知道某個量化版本對你的工作影響多大，最可靠的方法是自己測：準備十到二十個你平常真的會問的問題（例如公司文件摘要、程式碼修改、中英翻譯），分別用兩種量化版本各跑一次，比較答案的正確性與完整度。這比任何通用的基準分數都更貼近你的實際需求。

第二點引出一個實用原則：記憶體固定時，大模型的 Q4_K_M 往往比小模型的 Q8_0 更好。在 Qwen 的數據中，4 位元的 72B 模型遠遠領先全精度的 7B 模型。

## 對速度的影響

生成文字受記憶體頻寬限制：每個 token 都要把所有啟用中的權重讀一遍。每權重位元數越少，要讀的位元組越少，生成就越快。llama.cpp 的 quantize README 在同一台機器上量測 Llama 3.1 8B，Q4_K_M 約每秒 72 個 token，Q8_0 約 51 個，F16 約 29 個。本站的估算也是同樣的邏輯：[Qwen3-32B](https://onpremworld.com/zh-tw/models/qwen3-32b.md) 在 [GeForce RTX 5090](https://onpremworld.com/zh-tw/hardware/rtx-5090.md) 上，Q4_K_M 約每秒 56 個 token，Q6_K 約 42 個，Q8_0 約 34 個。

讀取提示詞（prefill）則不太一樣，它受算力限制而不是頻寬，所以量化對它的幫助較小，在某些硬體上甚至會變慢。

## 整個模型要多少記憶體

權重不是全部。隨上下文長度增加的 KV 快取，以及執行環境開銷，都要另外算。以常見的 32B 模型為例：

| 量化 | 每權重位元數 | 所需記憶體 @ 4K | 所需記憶體 @ 8K | 所需記憶體 @ 32K |
|---|---:|---:|---:|---:|
| Q4_K_M | 4.85 | 20.9 GiB | 21.9 GiB | 27.9 GiB |
| Q5_K_M | 5.69 | 24.3 GiB | 25.3 GiB | 31.3 GiB |
| Q6_K | 6.59 | 27.9 GiB | 28.9 GiB | 34.9 GiB |
| Q8_0 | 8.5 | 35.6 GiB | 36.6 GiB | 42.6 GiB |
| FP16 | 16 | 65.6 GiB | 66.6 GiB | 72.6 GiB |

*以上為依本站[估算方法](https://onpremworld.com/zh-tw/methodology.md)算出的估計值，資料日期 2026-10-16。實際速度會因執行環境、驅動程式與提示詞長度而不同。*

對照 24 GB 的顯示卡，這張表的意思是：Q4_K_M 配 8K 左右的上下文放得下，Q5_K_M 差一點點，Q8_0 則需要 48 GB 等級的卡。每個[模型頁面](https://onpremworld.com/zh-tw/models.md)都有同樣的表格，[「跑得動嗎？」試算](https://onpremworld.com/zh-tw/can-i-run.md)則會直接幫你對照硬體。

## 實際算一次：70B 模型放得進 64 GB 的 Mac 嗎？

用一個常見的問題把前面的概念串起來。[Llama 3.3 70B Instruct](https://onpremworld.com/zh-tw/models/llama-3.3-70b.md) 有 70B 參數：

1. **權重**：用 Q4_K_M 量化約 39.5 GiB；換成 Q8_0 是 69.3 GiB，FP16 更高達 130.4 GiB。
2. **加上 KV 快取和執行環境開銷**：8K 上下文下，Q4_K_M 的總需求約 44.5 GiB。
3. **對照可用記憶體**：Mac 的 GPU 預設只能使用部分統一記憶體，本站估算採用 75%，所以 64 GB 的 Mac 可用量約為 64 GB × 75%。

結論是：Q4_K_M 剛好放得下，Q5_K_M 以上就超過了。這也說明了為什麼「同一台機器能不能跑某個模型」的答案，常常取決於你選的量化等級。至於放得下之後跑多快，則要看記憶體頻寬，詳見[用 Mac 跑本地 LLM](https://onpremworld.com/zh-tw/guides/mac-local-llm.md)。

## 該選哪個等級

| 你的情況 | 建議 |
|---|---|
| 模型剛好勉強放得下 | Q4_K_M；連它都放不下時，改用搭配重要性矩陣的 IQ4 或 Q3_K |
| 一般使用，還有一點餘裕 | Q4_K_M 或 Q5_K_M |
| 記憶體充裕、重視品質（寫程式、數學、中文等非英文內容） | Q6_K 或 Q8_0 |
| 小模型（約 4B 參數以下） | Q8_0：小模型量化後損失最大，用 8 位元跑也不貴 |
| 要自己做量化或微調 | 保留 FP16／BF16 原始檔當來源 |

想用 Q4 以下時，先想想改用小一號模型的 Q4_K_M 以上會不會更好：上面的表格顯示，到了 3 位元和 2 位元，品質下滑得非常陡。

## 重要性矩陣與 IQ 量化

重要性矩陣（imatrix）的做法，是先讓模型跑過一批範例文字，找出哪些權重對輸出影響最大，量化時再把有限的精度優先留給它們。在 llama.cpp 的 Llama 3 8B 實測中，加上重要性矩陣後，同樣大小的 Q4_K_M 困惑度增加量從約 0.18 降到 0.15。IQ 系列就是圍繞這個技術設計的，當你需要用到 2 或 3 位元才放得下模型時，它是最好的選擇。

## KV 快取也能量化

KV 快取預設以 16 位元儲存。上下文很長時，它可能佔掉好幾 GB，所以各執行環境都能讓你把它和權重分開量化：

- **Ollama**：設定 `OLLAMA_KV_CACHE_TYPE=q8_0`（記憶體約為預設 f16 的一半，損失非常小），或 `q4_0`（約四分之一，長上下文下損失可能較明顯）。這是全域設定，會套用到所有模型，並需要 Flash Attention；硬體支援時 Ollama 會自動啟用。
- **llama.cpp**：`--cache-type-k q8_0 --cache-type-v q8_0`（也可寫成 `-ctk`、`-ctv`）。量化 V 快取需要 Flash Attention，llama.cpp 在預設的 `auto` 模式下會自動開啟。

Ollama 文件提醒，分組查詢注意力（GQA）比例較高的模型，對 KV 快取量化可能比較敏感，請用你實際使用的模型測試。

## 實際上怎麼選量化版本

- **Ollama**：預設標籤通常是 Q4_K_M，其他等級是不同的標籤，例如 `ollama run qwen3:8b-q8_0`。請到 Ollama 模型庫的標籤頁查看。
- **LM Studio**：在下載清單中選擇量化等級，或用指令 `lms get llama-3.1-8b@q4_k_m`。
- **llama.cpp**：在 Hugging Face 儲存庫名稱後面加上量化等級，例如 `-hf <user>/<model>:Q6_K`；不加的話，llama.cpp 預設選 Q4_K_M。
- **Hugging Face**：GGUF 檔名本身就帶有量化等級，例如 `model-Q4_K_M.gguf`。

## 其他常見格式

- **MLX**（Apple Silicon）：`mlx_lm.convert -q` 預設量化為 4 位元、群組大小 64。MLX 也支援較新的 mxfp4、nvfp4、mxfp8 格式，詳見[用 Mac 跑本地 LLM](https://onpremworld.com/zh-tw/guides/mac-local-llm.md)。
- **GPU 伺服器（vLLM 等）**：常見的是 AWQ、GPTQ、FP8 和 bitsandbytes。FP8 運算需要運算能力 8.9 以上的 NVIDIA GPU（Ada Lovelace、Hopper、Blackwell）；Turing 以後的舊卡則能以「只量化權重」的方式執行 FP8 模型。vLLM 對 GGUF 的支援仍被官方形容為高度實驗性。什麼時候該用 vLLM，請看[執行環境比較](https://onpremworld.com/zh-tw/guides/ollama-vs-lm-studio-vs-llama-cpp-vs-vllm.md)。

## 常見問題

### Q4_K_M 夠用嗎？

對大多數人來說夠用。llama.cpp 在 Llama 3 8B 上公布的實測中，Q4_K_M 的困惑度比 FP16 只多約 0.18，約 92% 的情況會選出和原始模型相同的最可能 token，而檔案大小不到三分之一。Ollama 模型庫中 qwen3:8b 等模型的預設標籤就是它，llama.cpp 從 Hugging Face 下載時也預設選它。記憶體有餘裕的話，Q5_K_M 或 Q6_K 會更接近原始模型。

### Q4_K_M 和 Q4_K_S 差在哪？

兩者都是 4 位元的 K-quant。Q4_K_S 所有張量都用 4 位元；Q4_K_M 則把部分最敏感的張量（注意力層與前饋層的一部分）保留為 6 位元。Q4_K_M 稍大一點，品質也明顯較好：在 Llama 3 8B 上，困惑度增加約 0.18，Q4_K_S 則是 0.27。

### 該用 Q8_0 還是 FP16？

用 Q8_0。llama.cpp 在 Llama 3 8B 上的實測顯示，Q8_0 和 FP16 幾乎沒有差別（困惑度只多 0.003），記憶體卻只要一半左右。FP16 或 BF16 只有在記憶體非常充裕、模型很小，或要拿來自己做量化時才有意義。

### 量化會讓模型變快嗎？

通常會。生成文字時的瓶頸是每個 token 要從記憶體讀多少位元組，每個權重的位元數越少，生成就越快。依本站估算，Qwen3-32B 在 RTX 5090 上用 Q4_K_M 約每秒 56 個 token，Q8_0 則約 34 個。

### IQ 量化和重要性矩陣（imatrix）是什麼？

重要性矩陣是讓模型先跑過一批範例文字，找出哪些權重對輸出影響最大，量化時再把有限的精度優先分給它們。IQ 系列量化以它為基礎，在 2 或 3 位元這種極低位元數下品質最好；重要性矩陣也能讓一般的 K-quant 品質略為提升。

### 把 KV 快取量化會影響品質嗎？

會有一點。Ollama 文件說明，KV 快取用 q8_0 時記憶體約為預設 f16 的一半，精度損失非常小、通常感覺不出來；用 q4_0 約為四分之一，在長上下文下損失可能比較明顯。這項功能需要 Flash Attention，而且每個 KV 頭對應較多查詢頭的模型可能比較敏感。

## 資料來源

- https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
- https://github.com/ggml-org/llama.cpp/blob/master/tools/perplexity/README.md
- https://github.com/ggml-org/llama.cpp/pull/1684
- https://github.com/ggml-org/llama.cpp/blob/master/tools/imatrix/README.md
- https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
- https://huggingface.co/docs/hub/gguf
- https://qwen.readthedocs.io/en/latest/getting_started/quantization_benchmark.html
- https://docs.ollama.com/faq
- https://ollama.com/library/qwen3/tags
- https://lmstudio.ai/docs/cli/local-models/get
- https://ml-explore.github.io/mlx/build/html/python/_autosummary/mlx.core.quantize.html
- https://docs.vllm.ai/en/latest/features/quantization/
- https://docs.vllm.ai/en/latest/features/quantization/llm_compressor/fp8/
- https://docs.pytorch.org/docs/stable/tensor_attributes.html
- https://docs.cloud.google.com/tpu/docs/bfloat16