LLM 量化指南：7 種方法實測比較（附基準數據）
Llama 3.3 70B 在 FP16 下光權重就要 140 GB，得用兩張 H100。換成 Q4_K_M，同一個模型大約 42 GB 就裝得下，一張從 eBay 買來的二手 RTX A6000 即可。這個差距正是 LLM 量化存在的理由，而選錯方法，你付出的代價不是肉眼可見的品質損失，就是根本不夠用的 VRAM。
本指南比較 2026 年真正重要的 7 種量化方法，每個數字都追溯到公開來源。
重點整理
- 量化用記憶體與頻寬換取可量化、通常很小的品質損失。
- GPTQ 和 AWQ 以 GPU 為主；GGUF 是同時能在 CPU 上執行的格式。
- Q4_K_M 實際落在每個權重約 4.8 bit，而非 4。命名方式掩蓋了額外開銷。
- 根據 llama.cpp k-quants PR 的數據，6-bit 量化與 FP16 的 perplexity 差距在 ~0.1% 以內。
LLM 量化到底對模型做了什麼？
LLM 量化以較低的數值精度儲存模型權重，用捨入誤差換取記憶體和頻寬的縮減。70B 參數模型從 FP16 的 140 GB 降至 4-bit 的約 42 GB。智慧留下來了，小數點位數被拿掉了。本指南中的每種方法，都是這個取捨的變體。
精度階梯從 FP32（32 bit）往下，經過 FP16 和 BF16（各 16 bit），再到 INT8，最後是 INT4。每降一級，每個參數佔用的位元組就減半。IEEE 754 標準定義了浮點格式；Mark Horowitz 2014 年的論文"Computing's Energy Problem"說明了為什麼搬運這些位元組、而非對它們做運算，才是能耗的主因。這就是量化能加速推理的物理原因。
量化靠兩個參數運作：縮放因子（將整數範圍映射回真實值的乘數）和零點（代表 0.0 的整數）。對稱量化將範圍置中於零，省略零點；非對稱量化則偏移範圍，在權重偏離零分佈時用滿整個整數區間。
權重之所以能量化得乾淨，是因為它們是靜態的、常態分佈的。激活值不行。離群激活值有時是中位數的 100 倍，天真地量化它們會讓捨入誤差爆炸。這種不對稱正是本指南多數方法只量化權重（W4A16）、將激活值留在 FP16 的原因。
訓練後量化（PTQ）在訓練完成後轉換模型。量化感知訓練（QAT）在訓練期間模擬捨入，讓模型自行適應。本文所有內容都屬 PTQ。QAT 需要更多算力和一輪訓練，那是另一個決策。
| 資料類型 | 位元數 | 位元組/參數 | 7B 權重 | 32B 權重 | 70B 權重 |
|---|---|---|---|---|---|
| FP32 | 32 | 4.0 | 28 GB | 128 GB | 280 GB |
| FP16 / BF16 | 16 | 2.0 | 14 GB | 64 GB | 140 GB |
| INT8 | 8 | 1.0 | 7 GB | 32 GB | 70 GB |
| INT4 | 4 | 0.5 | 3.5 GB | 16 GB | 35 GB |
| NF4 | 4 | 0.5 | 3.5 GB | 16 GB | 35 GB |
INT4 和 NF4 列是理論上的純 4-bit：每個權重 4 bit，不含其他東西。實際的 4-bit 格式還帶有區塊縮放和最小值，所以實際佔用更高。70B 模型在 Q4_K_M 下約 42 GB，而非 35。下方的 VRAM 表格使用的是有效速率。
量化不會縮減模型的智慧，它縮減的是儲存那份智慧的小數點位數。如果你正按 token 付費使用 API 推理，削減 LLM API 帳單往往從自己跑一個量化模型開始。
7 種量化方法並列比較
以下 7 種方法涵蓋了 2026 年量化 LLM 的所有生產路徑。兩種僅限 GPU（GPTQ、AWQ），一種哪都能跑（GGUF），一種在載入時量化（BitsandBytes），兩種針對高吞吐推理服務（SmoothQuant、FP8），一種是 PyTorch 原生（TorchAO）。正確選擇取決於你的硬體，而非哪種方法在排行榜上分數最高。
| 方法 | 位元數（典型） | 需要校正資料？ | GPU / CPU | 相對 FP16 速度 | 品質代價 | 最適合 |
|---|---|---|---|---|---|---|
| GPTQ | 3-4 | 是 | GPU | ~3.25x（A100）論文數據 | 4-bit 時低 | 批次 GPU 推理 |
| AWQ | 4 | 是（少量） | GPU | >3x 論文數據 | 低 | 低延遲推理服務 |
| GGUF（K-quants） | 2-8 | 否 | GPU + CPU | 依卸載比例而異 | Q4_K_M+ 時低 | 本地、CPU、Apple Silicon |
| BitsandBytes（NF4） | 4 | 否 | GPU | 無公開數據 | 低 | QLoRA 微調 |
| SmoothQuant（W8A8） | 8 | 是 | GPU | 最高 1.56x 論文數據 | 極低（8-bit 近無損） | 大批次推理服務 |
| FP8（W8A8） | 8 | 極少 | GPU（H100+） | 無公開數據 | 極低（近無損） | H100/B200 生產環境 |
| TorchAO | 4-8 | 否 | GPU | 無公開數據 | 低 | PyTorch 原生管線 |
GPTQ 逐層量化，利用逆 Hessian 矩陣將捨入誤差重新分配到剩餘權重。它需要校正資料集和 GPU。GPTQ 論文報告在約 4 GPU 小時內將 175B 模型量化至 3-4 bit。
AWQ 找出最重要的約 1% 權重（顯著權重，從激活幅度中發現），對它們進行縮放以保護其免受捨入影響。AWQ 論文（MLSys 2024 最佳論文）報告在桌面和行動 GPU 上，相對 HuggingFace FP16 實作均有超過 3 倍的加速。
GGUF 是檔案格式，不是演算法。裡面的演算法是來自 llama.cpp PR #1684 的 k-quant 區塊方案。它是本指南中唯一能在 CPU 上執行的方法，因此成為本地推理的預設選擇。看看值得量化的開放權重模型，了解該餵給它什麼。
BitsandBytes 在載入時量化，而非事先量化。NF4（4-bit NormalFloat）是它的招牌格式，也是 QLoRA 微調的骨幹。不需要校正資料集。
SmoothQuant 將激活離群值遷移到權重中，使兩者都能以 INT8 執行。論文報告最高 1.56 倍加速和 2 倍記憶體縮減，目標是大批次推理服務的吞吐量，在這種場景下 W4A16 方法會浪費效能。
FP8（W8A8） 是 H100 和 B200 GPU 的原生路徑。8-bit 近無損，沒有校正的麻煩，而且 vLLM 直接支援。
TorchAO 是 PyTorch 自家的量化函式庫，專為搭配 torch.compile 而建。如果你的管線已經是 PyTorch，這是阻力最小的路徑。
真正的問題只有兩個：你的硬體能不能跑它，以及你能不能接受它帶來的品質代價？
公開基準數據到底說明了什麼？
公開基準顯示，4-bit 量化在 7B 模型上損失 1-2% 的 perplexity，6-bit 損失不到 0.1%。這些數字來自 llama.cpp PR #1684（2023 年），由 llama.cpp 維護者在一張 RTX 4080 上對單一 7B 模型測得。它們是量化領域被引用最多的數據，而且是真的。但它們也是 n = 1。
| 類型 | 位元/權重 | Perplexity | 檔案大小 | ms/token |
|---|---|---|---|---|
| F16 | 16.0 | 5.9066 | 13.0 GB | 60.0 |
| Q2_K | 2.5625 | 6.7764 | 2.67 GB | 15.5 |
| Q4_K_S | 4.5 | 6.0215 | 3.56 GB | 15.5 |
| Q6_K | 6.5625 | 5.9110 | 5.15 GB | 18.3 |
來源：llama.cpp PR #1684（2023 年）。7B 模型，RTX 4080，由 llama.cpp 維護者測量。n = 1 個模型。
關於位元/權重那一欄的說明：那些是基礎 k-quant 類型的名義速率，而 _K 混合會提高有效速率。Q2_K 就是個例子。用本文的公式對名義 2.5625 和 6.74B 參數模型計算，得到約 2.0 GB，但該列報告的是 2.67 GB 檔案，反推回來約 3.4 bit/權重。本文其餘部分使用有效速率，由這些檔案大小推導而來。
GPU 方法的數字直接來自論文。GPTQ 報告相對 FP16 的端到端推理加速，在 A100 上約 3.25 倍，在 A6000 上約 4.5 倍，175B 模型在約 4 GPU 小時內量化至 3-4 bit。AWQ 報告「在桌面和行動 GPU 上，相對 Huggingface FP16 實作有超過 3 倍的加速」，加上透過 TinyChat 在行動 GPU 上首次部署 70B Llama-2。我們引用論文原文，而非將數字改述成虛假的精確度。
本文的原創貢獻是算術。權重記憶體遵循：weights (GB) ≈ params (B) × bits per weight ÷ 8。陷阱在於你餵給它哪個 bits-per-weight 數字。PR #1684 公佈的是基礎 k-quant 類型的速率（Q4_K = 4.5），而 _S/_M/_L 混合高於該基礎速率，因為它們將額外的位元分配給注意力和前饋張量。所以我們從 PR 本身公佈的檔案大小推導有效速率，對象是一個實際為 6.74B 參數的 7B 模型：Q2_K 的 2.67 GB 反推約 3.4 bpw，Q4_K_S 的 3.56 GB 約 4.5，Q6_K 的 5.15 GB 約 6.6。Q4_K_M 落在約 4.8。
這改變了標題數字。70B 模型在 Q4_K_M 下：70 × 4.8 ÷ 8 = 42 GB。多數文章說 35 GB，它們用的是 4.0 bpw，完全跳過了區塊縮放的開銷。交叉驗證只需一次點擊：Llama-3.3-70B-Instruct-Q4_K_M.gguf 在 HuggingFace 上是 42.5 GB，bartowski、lmstudio-community 和 second-state 的 repo 都一樣。我們據此重新計算了下表 VRAM 表格中的每個儲存格。
我們對這些數字的解讀：Q6_K（5.9110）和 F16（5.9066）之間的 perplexity 差距是 0.0044，這比同一基礎模型的兩個不同微調版本之間的差距還小。這就是為什麼「直接用 Q4_K_M 或 Q5_K_M」是經得起真實硬體檢驗的建議。ms/token 欄也顯示 Q2_K 相對 Q4_K_S 買不到任何速度（兩者都是 15.5 ms/token），卻要多付 0.75 的 perplexity。Q2_K 是表中交易條件最差的選項。
數字沒告訴你的事：wikitext perplexity 不等於你的提示詞上的品質。一個模型在一張 GPU 上就是 n = 1。速度數字取決於批次大小。把這些當作方向性參考，而非普世真理。
6-bit 量化落在全精度模型 perplexity 的約 0.1% 以內。在那個層級，壓縮幾乎是免費的。
GPTQ 對 AWQ：兩種 GPU 方法怎麼選
GPTQ 和 AWQ 都從校正資料集產生 4-bit GPU 檢查點，兩者在 vLLM 中都有良好支援。差別在於如何處理捨入誤差。GPTQ 用逆 Hessian 將誤差重新分配到剩餘權重。AWQ 保護激活值標記為重要的那 1% 權重。兩者都有效，選擇取決於你的推理服務模式。
GPTQ 逐層運作。對每一層，它一次量化一個權重，然後調整該層中剩餘的權重，以補償剛才做出的捨入。調整使用來自 Hessian 矩陣的二階資訊，這就是它需要校正資料集來計算的原因。結果在批次推理中表現強勁，因為在這種場景下吞吐量比每 token 延遲更重要。
AWQ 走不同的角度。它透過觀察校正資料集上的激活幅度來識別顯著權重，大約是前 1% 的通道。這些權重獲得一個逐通道縮放因子，使它們在捨入期間保持在較高精度的範圍內。校正資料集可以比 GPTQ 的更小，而且 AWQ 對它的過擬合更少，因為它保護的是結構特徵，而非擬合特定輸入。論文報告在低延遲推理服務上有強勁結果。
**選 GPTQ 的情況：**你在 GPU 上做批次推理，你有一個符合你領域的好校正資料集，而且吞吐量是關鍵指標。
**選 AWQ 的情況：**你在服務單用戶低延遲請求，你想要更小的校正資料集，或者你在邊緣/行動 GPU 上部署。
# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
--quantization awq \
--max-model-len 4096# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
--quantization gptq \
--max-model-len 4096如果你同時也在選推理引擎，vLLM 對決 SGLang 單獨涵蓋了那個決策。
GGUF 與 K-Quants：Q4_K_M 到底是什麼意思
GGUF 是檔案格式，不是量化演算法。GGUF 規格定義了一個容器，裝載模型權重、中繼資料和分詞器資料。GGUF 檔案裡的量化演算法是來自 llama.cpp PR #1684 的 k-quant（或 i-quant）區塊方案。把容器和演算法搞混，是這個領域最常見的錯誤，它會引出「GGUF 和 GPTQ 哪個比較好？」這類不太成立的問題。
命名方案的解碼方式如下。Q 代表 k-quant 區塊方案；IQ 代表重要性矩陣 i-quant（較新的變體，使用重要性矩陣在相同位元深度下取得更好品質）。數字是名義位元深度。_K 標記 k-quant 家族，區別於 Q4_0 等舊格式。_S、_M、_L 控制哪些張量群組獲得額外位元：small、medium、large。後綴越高，分配給最重要的注意力和前饋張量的位元越多。
| 名稱 | 位元/權重（有效） | 方案 | 品質等級 | 典型用途 |
|---|---|---|---|---|
| Q2_K | ~3.4 | k-quant | 差 | 緊急縮減體積 |
| Q3_K_S | ~3.5 | k-quant | 普通 | 緊繃的 VRAM 預算 |
| Q3_K_M | ~3.9 | k-quant | 普通 | 緊繃的 VRAM 預算，比 _S 高一級 |
| Q4_0 | 4.5 | legacy | 良好 | 舊版 llama.cpp 建構 |
| Q4_K_S | ~4.5 | k-quant | 良好 | 平衡的預設選項 |
| Q4_K_M | ~4.8 | k-quant | 很好 | 最受歡迎的本地選擇 |
| Q5_K_M | ~5.7 | k-quant | 優秀 | 品質優先的本地部署 |
| Q6_K | ~6.6 | k-quant | 近無損 | 體積幾乎不是問題時 |
| Q8_0 | 8.5 | legacy | 近無損 | CPU 推理，品質優先 |
| IQ4_XS | ~4.3 | i-quant | 很好 | 比 Q4_K_M 更小，品質相近 |
有效速率，由 PR #1684 公佈的 7B（6.74B 參數）檔案大小反推而來，而非基礎類型數字。legacy 列在構造上是精確的：Q4_0 區塊是 32 個權重各 4 bit 加上一個 FP16 縮放，即每個權重 4.5 bit；Q8_0 是 32 個權重各 8 bit 加上一個 FP16 縮放，即 8.5。PR 也佐證了這一點，將 7B 的 Q4_0 和 Q4_K_S 檔案列為相同的 3.56 GB。
Q4_K_M 不是每個權重 4 bit，而是約 4.8。區塊縮放和最小值得住在某個地方，而 _M 混合接著在注意力和前饋張量上多花位元，這正是 Q4_K_M 高於 Q4_K_S、Q3_K_M 高於 Q3_K_S 而非與之持平的原因。
為什麼 GGUF 能跑在 GPTQ 跑不了的地方：它支援 CPU 推理，以及 GPU VRAM 和系統 RAM 之間的層卸載。一個無法完全裝進 GPU 的 32B 模型，可以在卸載一半層的情況下執行，慢但能用。GPTQ 沒有 CPU 路徑。
# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M剛接觸本地模型？先讓你的第一個本地模型跑起來，再量化任何東西。如果你想要瀏覽器介面，在 Ollama 上架設 Open WebUI 大約十分鐘搞定。HuggingFace GGUF 文件說明了 Hub 如何呈現量化類型命名。
BitsandBytes、Marlin、SmoothQuant 和 TorchAO
這四者涵蓋了剩餘的生產路徑。沒有一個是「更好的 GPTQ」，它們解決的是不同問題。
BitsandBytes 在載入時量化，而非事先量化。你把它指向一個 FP16 檢查點，它即時轉換為 NF4 或 FP4。沒有校正資料集，沒有離線步驟。它最為人知的是 QLoRA：一個 4-bit 凍結基礎模型加上在其上訓練的 LoRA 適配器，使單 GPU 在 48 GB VRAM 上微調 65B 模型成為可能。QLoRA 是訓練技術，不是推理技術，但它是多數人第一次接觸 BitsandBytes 的原因。
Marlin 不是量化方法。它是一個 INT4xFP16 混合精度 GEMM 核心，讓現有的 4-bit 檢查點在中等批次大小下更快。Marlin 論文報告在 A100 和 H100 上的加速。如果你的推理服務堆疊支援它，你在已經量化好的模型上啟用它。你不會「用 Marlin 量化」。
SmoothQuant 透過逐通道縮放因子將激活離群值轉移到權重中，使 W8A8（權重和激活都在 INT8）可行。論文針對的是大批次推理服務，在這種場景下 W4A16 方法會浪費吞吐量。如果你同時服務數百個並發請求，這就是你的選擇。
TorchAO 是 PyTorch 原生量化，搭配 torch.compile 運作。沒有外部依賴，沒有格式轉換。如果你的推理管線已經是 PyTorch，這是摩擦最小的選項。對於在本地執行嵌入模型，Ollama 路徑通常更簡單，但 TorchAO 適合自訂 PyTorch 堆疊。
量化模型需要多少 VRAM？
公式是 weights (GB) ≈ params (B) × bits per weight ÷ 8。70B 模型在 Q4_K_M 下：70 × 4.8 ÷ 8 = 42.0 GB。下方的速率是有效值，由 llama.cpp PR #1684 公佈的檔案大小反推而來，而非基礎類型數字，因為 _M 混合總是高於其基礎 k-quant 速率。我們重新計算了，而非抄用常見的 4.0-bpw 捷徑。
| 模型規模 | FP16 | Q8_0 | Q6_K | Q5_K_M | Q4_K_M | Q3_K_M |
|---|---|---|---|---|---|---|
| 7B | 14.0 GB | 7.4 GB | 5.7 GB | 5.0 GB | 4.2 GB | 3.4 GB |
| 8B | 16.0 GB | 8.5 GB | 6.6 GB | 5.7 GB | 4.8 GB | 3.9 GB |
| 13B | 26.0 GB | 13.8 GB | 10.7 GB | 9.3 GB | 7.8 GB | 6.3 GB |
| 32B | 64.0 GB | 34.0 GB | 26.2 GB | 22.8 GB | 19.2 GB | 15.6 GB |
| 70B | 140.0 GB | 74.4 GB | 57.4 GB | 49.9 GB | 42.0 GB | 34.1 GB |
由有效 bits-per-weight 計算：Q8_0 = 8.5、Q6_K = 6.56、Q5_K_M = 5.7、Q4_K_M = 4.8、Q3_K_M = 3.9。由 PR #1684 中 7B（6.74B 參數）檔案大小推導，再對照已公開的 70B 建構交叉驗證：Llama-3.3-70B-Instruct-Q4_K_M.gguf 在 HuggingFace 上是 42.5 GB，此處預測為 42.0 GB。
誠實的提醒：這只是權重。KV cache、上下文長度和框架開銷會疊加在上面。KV cache 隨上下文長度和批次大小擴展。70B 模型上 32k 上下文的 session 可能多加好幾 GB。權重表是下限，不是預算。你的上下文窗口也在租用 VRAM。完整圖景請見逐模型 VRAM 需求詳解。
你該用哪種量化方法？
你的硬體在你的偏好之前就決定了答案。一個跑不了你 GPU 的方法不是選項，是願望。下表根據上述硬體限制和品質取捨，將常見配置對應到真正可行的方法。
| 你的配置 | 用這個 | 原因 |
|---|---|---|
| 24 GB GPU，品質優先 | AWQ 或 GPTQ INT4 | 完整 GPU 加速，GPU 上每 bit 品質最佳 |
| 16 GB GPU，單一模型，低延遲 | AWQ INT4 | 校正資料更少，延遲表現強勁 |
| 8-12 GB GPU | GGUF Q4_K_M，部分卸載 | 層卸載到系統 RAM 維持運作 |
| 僅 CPU / Apple Silicon | GGUF Q4_K_M 或 Q5_K_M | 唯一有真正 CPU 路徑的方法 |
| 大批次生產推理服務 | FP8 或 SmoothQuant W8A8 + Marlin | 吞吐量最佳化，8-bit 近無損 |
| 單 GPU 微調 | QLoRA（BitsandBytes NF4） | 4-bit 凍結基礎 + LoRA 適配器 |
| 純粹實驗 | 從 HuggingFace 下載預量化 GGUF | 先別自己量化任何東西 |
對多數使用消費級硬體的讀者來說，預量化的 Q4_K_M 或 Q5_K_M GGUF 就是正確答案。從 HuggingFace 拉下來，用 Ollama 或 llama.cpp 跑，然後停止最佳化。Q4_K_M 和 Q5_K_M 之間的品質差異小到，你應該根據檔案是否裝得下來決定，而非根據 perplexity 表格。除此之外的一切最佳化都是為了最佳化而最佳化，只有在你確認模型在 Q4 下確實解決了你的問題之後才值得做。
真正能在本地跑這些模型的工具指南涵蓋了選定量化等級之後的推理服務端。
量化出錯的五種方式
量化失敗幾乎總是配置問題，而非方法問題。以下五種不斷出現。
1. 校正資料集不符合你的領域。 GPTQ 和 AWQ 都擬合校正資料。如果你用 Wikipedia 校正，卻部署在醫療紀錄上，量化模型在它從未見過的 token 上表現會差。修正：使用取自你實際輸入分佈的校正資料集，即使只有 128 個樣本也有幫助。
2. 群組大小設太大。 GPTQ 的群組大小控制多少權重共享一個縮放因子。128 是標準。256 或 512 在量化時省算力，但在較小模型上會撞上品質懸崖。修正：維持 128，除非你已確認品質在你的提示詞上撐得住。
3. 期待 Q2_K 能用。 根據 PR #1684 數據，Q2_K 相對 F16 損失約 0.87 perplexity，而且相對 Q4_K_S 買不到任何速度（在 7B 基準上兩者都是 15.5 ms/token）。你得到更小的檔案和更差的輸出，卻沒有延遲收益。修正：Q4_K_S 是下限，除非檔案大小是硬限制。
4. 用 wikitext perplexity 做基準，而非你自己的提示詞。 Perplexity 是語言建模指標。它不衡量模型是否遵循你的系統提示、是否正確格式化 JSON、是否處理你的領域詞彙。修正：用 20-30 個你的真實提示詞同時跑量化和未量化模型，比較輸出。
5. 把 GGUF 容器和裡面的量化演算法搞混。 這會導致把「GGUF 對 GPTQ」當作同一類別來比較。它們不是。GGUF 是檔案格式，裡面的 k-quant 方案才是演算法。修正：比較 k-quant 等級（Q4_K_M 對 Q5_K_M），而非檔案格式。
常見問題
什麼是 LLM 量化？
LLM 量化降低模型權重的數值精度，通常是從 16-bit 浮點降到 4-bit 或 8-bit 整數。這會減少記憶體使用並透過降低頻寬來加速推理。70B 模型從 140 GB 降至 4-bit 的約 42 GB。品質代價在 4-bit 時通常是 1-2% 的 perplexity，6-bit 時更低。
量化會降低模型的準確度嗎？
會，但比多數人預期的少。根據 llama.cpp PR #1684 的基準，7B 模型上的 Q4_K_S 相對 F16 損失約 2% perplexity，Q6_K 損失不到 0.1%。對真實提示詞的實際影響往往比 perplexity 數字暗示的更小，尤其在 Q4_K_M 及以上。
GPTQ 和 AWQ 哪個比較好？
兩者都沒有絕對優勢。GPTQ 使用逆 Hessian 誤差重新分配，適合批次 GPU 推理。AWQ 透過激活感知縮放保護顯著權重，適合低延遲推理服務。AWQ 需要更小的校正資料集，對它的過擬合也更少。如果你在服務單用戶低延遲請求，從 AWQ 開始。
Q4_K_M 是什麼意思？
Q4_K_M 是一個 k-quant GGUF 量化等級。「Q4」代表名義 4-bit 深度，「K」標記 k-quant 區塊方案（區別於 legacy Q4_0），「M」代表 medium：注意力和前饋張量獲得額外位元。有效 bits per weight 約 4.8，而非 4.0，因為區塊縮放和最小值增加了開銷，而 medium 混合在此之上又多花了位元。
量化模型能在 CPU 上跑嗎？
可以，但只能透過 GGUF。GPTQ 和 AWQ 是僅限 GPU 的格式。GGUF 的 k-quant 模型透過 llama.cpp 或 Ollama 在 CPU 上執行，並支援 GPU VRAM 和系統 RAM 之間的層卸載。Q4_K_M 是標準的 CPU 量化等級。預期 token 生成比 GPU 慢，但推理功能正常。
GGUF 和 GGML 有什麼差別？
GGML 是 llama.cpp 最初使用的較舊張量函式庫和檔案格式。GGUF 在 2023 年 8 月取代了它，成為更靈活的容器格式，具有更好的中繼資料支援。你今天從 HuggingFace 下載的就是 GGUF 檔案。GGML 檔案是 legacy，已經很少再散佈。
我該自己量化模型，還是下載預量化的？
先下載預量化的。llama.cpp 和 HuggingFace 社群已經在每個等級量化了大多數熱門模型。自己量化只有在以下情況才合理：你需要針對你的領域的特定校正資料集，或者你的模型沒有預量化版本。
什麼時候該用量化，什麼時候該用較小的模型？
當你需要較大模型的能力、但它裝不進記憶體時，用量化。量化的 70B 模型在複雜推理任務上通常優於未量化的 13B 模型。當延遲是限制時，改用較小的模型，因為較小的模型無論是否量化都能更快生成 token。
量化和蒸餾有什麼差別？
量化降低現有模型權重的數值精度。蒸餾訓練一個較小的模型去模仿較大的模型，產生真正不同（且更小）的架構。量化保留原始模型的架構，原則上是可逆的。蒸餾建立一個新模型，需要一輪訓練。
簡短版本：量化就是把你想要的模型塞進你現有的硬體。對多數使用消費級 GPU 或 Apple Silicon 的人來說，從 HuggingFace 拉一個預量化的 Q4_K_M GGUF 就是整個解決方案。GPTQ 和 AWQ 是 GPU 推理服務的答案。FP8 和 SmoothQuant 是生產吞吐量的答案。其餘的一切，都是在你確認模型能跑之後的最佳化。
如果你正在決定要自架什麼，想要對硬體與方法的搭配聽聽第二意見，我們很樂意聊聊。