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

量化，就是用更少的位元來存模型的每一個權重：模型變小、跑得更快，代價是一點點品質。 模型原本的權重通常是 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 位元以下就完全跑不動，否則別往下降。本站每個模型頁面和「跑得動嗎？」試算的記憶體數字，都是依量化等級分別計算的。

量化在做什麼

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

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

以上為依本站估算方法算出的估計值，資料日期 2026-10-14。實際速度會因執行環境、驅動程式與提示詞長度而不同。

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

看懂量化名稱

這些名稱來自 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 散度（衡量量化後模型預測的機率分布偏離原始模型多遠）：

資料來源：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 在 GeForce RTX 5090 上，Q4_K_M 約每秒 63 個 token，Q6_K 約 46 個，Q8_0 約 36 個。

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

整個模型要多少記憶體

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

以上為依本站估算方法算出的估計值，資料日期 2026-10-14。實際速度會因執行環境、驅動程式與提示詞長度而不同。

對照 24 GB 的顯示卡，這張表的意思是：Q4_K_M 配 8K 左右的上下文放得下，Q5_K_M 差一點點，Q8_0 則需要 48 GB 等級的卡。每個模型頁面都有同樣的表格，「跑得動嗎？」試算則會直接幫你對照硬體。

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

用一個常見的問題把前面的概念串起來。Llama 3.3 70B Instruct 有 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。

該選哪個等級

想用 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。
• GPU 伺服器（vLLM 等）：常見的是 AWQ、GPTQ、FP8 和 bitsandbytes。FP8 運算需要運算能力 8.9 以上的 NVIDIA GPU（Ada Lovelace、Hopper、Blackwell）；Turing 以後的舊卡則能以「只量化權重」的方式執行 FP8 模型。vLLM 對 GGUF 的支援仍被官方形容為高度實驗性。什麼時候該用 vLLM，請看執行環境比較。