Day 11 的同場加映，是提到近期一直很熱門的 Ollama 這款地端 AI 推論引擎平台，當時給了大家一個問題，兩款都叫 MXFP4 的 gpt-oss-120b，同一個引擎同一組旗標，decode 這個 AI 推論很重要的項目成績卻差了 19%。
這時去打開檔案才發現，其中一個模型檔案的注意力層是 BF16，另一模型的檔案是 q8_0。兩款檔案的名字都沒有騙人，但「量化格式」這四個字，有他自己的眉角，因此我想協助大家簡單地去理解量化版到底是甚麼意思?
看完這篇你會知道三件事，一款 AI 模型的量化版本常見格式（GGUF 家族、MXFP4、FP8、AWQ、NVFP4）各自是什麼? 一款量化模型檔案裡面其實是配方而不是單一數字，以及在 128GB 統一記憶體的機器上該怎麼選量化模型好呢? 針對更小 VRAM 顯示卡的量化模型怎樣選，我也有一些小心得可以分享給大家。
模型權重原本以 16 位元浮點數（BF16）儲存，量化就是用更少的位元表示同一批數字，8 位元砍一半、4 位元砍四分之三。賣掉的是數值精度，買回來的有兩樣，也就是最重要的 記憶體空間（讓 VRAM 能放得下比原本可容納空間更大的大檔案模型）與速度。
速度這一項在這台機器上特別值錢，複習 Day 2 的結論，decode 是記憶體頻寬受限的工作，每生成一個 token 都要把啟用權重完整讀一遍。權重從 16 位元變 4 位元，每個 token 要搬的位元組直接變四分之一，在頻寬固定 273GB/s 的前提下，量化就是 decode 的直接加速器。這也是為什麼 Spark 社群對量化格式的討論比獨顯社群更熱衷，GB10 的頻寬比它的普通 AI 算力要更珍貴。
那為什麼砍到 4 位元模型還能用？關鍵在於現代量化不是無腦四捨五入直接讓模型降智商，而是分組縮放，把權重切成小群組，每組各自記一個縮放係數，用少量額外空間保住數值範圍，和原先本人的智商就不會降太多。各家格式的差異，本質上就是「怎麼分組、怎麼縮放、哪些層捨不得砍」的各種大小配方差異，也因此效率、速度、品質，都有相當的不同。
| 格式 | 位元數 | 主場引擎 | 特點 |
|---|---|---|---|
| GGUF q8_0 | 8 | llama.cpp 系 | 品質幾乎無損的保守選擇 |
| GGUF q4_k_m | 約 4.5 | llama.cpp 系 | 社群最流行的平衡點 |
| GGUF iq 系（imatrix） | 2 到 4 | llama.cpp 系 | 用校準資料決定哪裡該省，低位元的救星 |
| MXFP4 | 4 | 跨引擎 | microscaling 標準格式，Blackwell 硬體原生支援 |
| FP8（e4m3） | 8 | vLLM 系 | 浮點量化，Hopper 之後硬體原生 |
| AWQ | 4 | vLLM 系 | 校準式整數量化，保護活化敏感的權重 |
| NVFP4 | 4 | vLLM、TRT-LLM | NVIDIA 為 Blackwell 推的新 4 位元浮點 |
我這邊挑幾個稍微簡單說明一下。
GGUF 的 k 系與 iq 系的差異是有沒有「讀過書」。 q4_k_m 用固定規則分組，iq 系（imatrix）先拿一份校準語料跑過模型，記下哪些權重對輸出影響大，量化時重點保護它們。低位元（3 位元以下）沒有 imatrix 幾乎不能用，ds4 那款專為 128GB 機器調的 2-bit 就是 imatrix 的功勞。這裡有個對繁中使用者的實務提醒，imatrix 的校準語料大多是英文，對中文任務的保護效果是未知數，這是社群量化檔很少被討論的盲點。
MXFP4 與 NVFP4 是「硬體認識的格式」。 傳統整數量化在推論時要先解壓回浮點數再運算，microscaling 格式則是 Blackwell 的 Tensor Core 直接支援的資料型別，省掉解壓這一手。gpt-oss 官方直接以 MXFP4 發布就是看上這件事，這也是 GB10 這類新架構的紅利。
FP8 不只量化權重，還管 KV cache。 Day 9 到 11 反覆出現的 kv-cache-dtype fp8 就是它，同一個技術用在兩個地方，權重的 FP8 是發布時決定的，KV 的 FP8 是你啟動引擎時決定的，兩者獨立。
回到 19% 之謎。用 gguf 工具把兩個「MXFP4」攤開看每一層的實際型別：
# llama.cpp 內建的檢視工具
./build/bin/llama-gguf-dump /mnt/models/gguf/<模型檔> | head -50
所謂「一個 MXFP4 模型」，實際上是 FFN 層用 MXFP4、注意力層各自表述、embedding 與輸出層又是另一回事的混合配方。兩個量化者對「哪些層捨不得砍」的判斷不同，成品的名字卻一樣。這帶出本篇最重要的一個習慣：
下載量化檔不要只看檔名的位元數，花三十秒 dump 一下配方。 尤其當兩個同名模型檔案的大小差了好幾 GB 的時候，差的那幾 GB 就藏在配方裡。
這次的測試模型我改用市場上熱門的 Qwen3.8-27B，它不但新、實務上也是很能打的，地端在 Mac、PC 搭配 NVIDIA 顯卡都能夠跑它的量化版，也具備相當的代表性。最大的好處是其 27B 的尺寸讓 BF16 全精度也放得進 128GB，我們才有「無損基準」可以對照，這正是這台機器做量化評測的獨特優勢，如果是 VRAM 24GB 的卡連裁判都當不了。
速度階梯（llama-bench，方法論同 Day 8）：
| 量化 | 檔案大小 | 實際每權重位元 | decode（t/s） | 相對 BF16 |
|---|---|---|---|---|
| BF16 | 54.66 GB | 16.00 | 4.66 ± 0.00 | 1.00 倍 |
| q8_0 | 29.12 GB | 8.52 | 7.93 ± 0.01 | 1.70 倍 |
| q4_k_m | 17.77 GB | 5.20 | 11.77 ± 0.00 | 2.52 倍 |
| iq4_xs | 15.57 GB | 4.56 | 14.04 ± 0.01 | 3.01 倍 |
| 量化 | decode 加速 | 檔案大小比 | 折扣 |
|---|---|---|---|
| q8_0 | 1.70 倍 | 1.88 倍 | 90.6% |
| q4_k_m | 2.52 倍 | 3.08 倍 | 82.1% |
| iq4_xs | 3.01 倍 | 3.51 倍 | 85.8% |
位元愈低折扣愈重，因為解壓與縮放係數的固定成本佔比變大了。但 iq4_xs 反過來比 q4_k_m 效率更高，又小、又快、折扣還更少。
量化只加速 decode，它不加速 prefill，而且可能拖慢 prefill。
| 量化 | decode 對 BF16 | prefill 對 BF16 |
|---|---|---|
| q8_0 | 1.70 倍 | 0.90 倍 |
| q4_k_m | 2.52 倍 | 0.93 倍 |
| iq4_xs | 3.01 倍 | 1.04 倍 |
品質階梯（llama-perplexity，同一份測試語料）：
| 量化 | PPL（英文語料） | 劣化 | PPL（繁中語料） | 劣化 |
|---|---|---|---|---|
| BF16 | 6.9529 ± 0.0450 | 基準 | 11.1337 ± 0.1608 | 基準 |
| q8_0 | 6.9569 ± 0.0450 | +0.058% | 11.1365 ± 0.1607 | +0.025% |
| q4_k_m | 6.9880 ± 0.0453 | +0.505% | 11.2275 ± 0.1624 | +0.842% |
| iq4_xs | 7.0138 ± 0.0455 | +0.876% | 11.3287 ± 0.1645 | +1.751% |
英文用 wikitext-2 的標準測試集（580 個 chunk），繁中是自產語料，把這個系列自己的舊文與草稿串起來，剝掉程式碼區塊與表格只留散文，共 147 個 chunk。用自己的文章有一個附帶好處，它不太可能出現在任何人的 imatrix 校準集裡。
繁中那一欄是本表的重點。前面說過 imatrix 的校準語料以英文為主，英文 PPL 幾乎無損不代表中文也是。實測的答案是：
8 位元那一級，兩種語言都真的無損，0.058% 與 0.025% 已經是雜訊等級。4 位元那一級，繁中付的代價是英文的 1.67 到 2.00 倍。 q4_k_m 英文掉 0.505%、繁中掉 0.842%；iq4_xs 英文掉 0.876%、繁中掉 1.751%，剛好翻倍。
「換一份語料會不會翻掉」是一個可以省思的好問題，所以我把兩份語料各切成前後兩半，各自獨立算一次：
| 語料 | q4_k_m 前半／後半 | iq4_xs 前半／後半 |
|---|---|---|
| 英文（290 / 290 chunk） | +0.471% / +0.538% | +0.890% / +0.862% |
| 繁中（73 / 74 chunk） | +0.934% / +0.752% | +1.669% / +1.833% |
兩半各自算，繁中大於英文的結論都成立。
vLLM 那一側補一組對照，同一個 Qwen3.8-27B 的官方 FP8 版（Day 13 會再見到它），decode 7.92 t/s，與 GGUF q8_0 的 7.93 t/s 相比差 0.1%。兩個引擎、兩種完全不同的 8 位元格式、同一款模型、同一台機器，是落在同一個數字上。到了 8 位元這一級，決定單用戶 decode 速度的是每個 token 要搬多少位元組。
把今天的知識收斂成 128GB 統一記憶體上的三條決策原則。
第一，你有不量化的選擇權，先用非量化版當基準
70B 以下的模型 BF16 都放得下，正式採用任何量化檔之前，跟全精度版本並排跑幾個你自己的真實任務，量化的品質代價自己驗，不要只信英文基準，原因是我們有使用到繁體中文，這點和國際上的英文使用者和其他語言使用者是有差異的，合先敘明。
第二，日常主力選 q8_0 或 FP8
空間夠的時候，8 位元幾乎無損又比 BF16 快上一截，是品質與速度的甜蜜點。4 位元留給兩種情況，模型大到 8 位元放不下，或你確認過它的品質劣化在你的任務上是可接受的水準。
第三，越低位元越要挑量化者
8 位元隨便量都差不多，2 到 4 位元的品質幾乎取決於 imatrix 校準的功力，這就是模型官方或長期經營的量化者功力差異，下載完 dump 配方、驗 sha256，這是 Day 5 測試老規矩的量化版囉。
至於一般桌機用的 NVIDIA 顯示卡要選量化模型的話，關鍵不是顯卡越大就一定用越高量化，而是要看「模型大小 × KV Cache × 推論框架開銷」之後還剩多少 VRAM。
以一般 NVIDIA 顯卡來說，16GB、24GB、32GB 可以這樣選：
VRAM
│
├─ 16GB
│ ├─ 小模型：BF16 / Q8
│ └─ 中大型模型：Q4 / Q5
│
├─ 24GB
│ ├─ 小模型：BF16
│ ├─ 中型模型：Q6 / Q8
│ └─ 大模型：Q4 / Q5
│
├─ 32GB
│ ├─ 小～中型：BF16 / FP8 / Q8
│ ├─ 中大型：Q5 / Q6
│ └─ 超過容量：Q4
│
└─ 128GB Unified Memory
├─ ≤70B：BF16 優先當裁判
├─ 70B～120B：FP8 / Q8
└─ 更大型：Q4～Q6
量化決定了權重的大小，明天處理這些幾十 GB 然後累積到幾百 GB 、上 TB 的檔案怎麼分類、分配與放置比較好，還有一些地端 AI 使用上的眉角。
我們 Day 13 見囉。
Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程
Day 8｜llama.cpp 實測：先定量尺與 SOP
Day 9｜vLLM 實測：官方容器、同時處理吞吐曲線，與剛出爐的新模型 Ornith 1.5
Day 10｜TensorRT-LLM 實測：我花了一個下午，跟它的預設值搏感情
Day 11｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓
Day 12｜量化格式解析：「4-bit」兩個字，古今多少事 ? 都付笑談中
Day 13｜Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書
Day 14｜Qwen3.8-27B 與 Flash-Next 加碼實測：地端模型世代對決與落地評估
Day 15｜Ornith 1.5 實測：為 AI agent 而生的 35B-A3B
Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型
iThome鐵人賽
看影片追技術