Q4、Q5 和 Q8 比較：GGUF 行動裝置量化
Q4、Q5 和 Q8 的 GGUF 量化如何影響 iPhone 和 Android 上的模型大小、速度、品質和記憶體用量。全部基於真實裝置實測。
量化是讓 LLM 能在手機上運行的關鍵技術。一個 3B 參數模型在全精度（FP16）下佔 6GB。量化到 Q4 後只佔 1.7GB。模型大致相同，只是以更高效率儲存。
但「大致相同」隱藏了重要的細微差異。不同的量化級別在大小和速度與品質之間進行權衡。為你的行動應用程式選擇正確的級別，需要在真實硬體上理解這些權衡。
量化做了什麼
LLM 權重儲存為數字。全精度每個權重使用 16 位元（FP16）。量化減少每個權重的位元數，縮小模型：
| 格式 | 每權重位元 | 3B 模型大小 | 相對品質 |
|---|---|---|---|
| FP16 | 16 | ~6GB | 100%（基準） |
| Q8_0 | 8 | ~3.2GB | ~99.5% |
| Q6_K | 6 | ~2.5GB | ~99% |
| Q5_K_M | 5 | ~2.1GB | ~98.5% |
| Q4_K_M | 4 | ~1.7GB | ~97.5% |
| Q4_0 | 4 | ~1.6GB | ~96% |
| Q3_K_M | 3 | ~1.4GB | ~93% |
| Q2_K | 2 | ~1.1GB | ~85% |
「_K_M」後綴表示 k-quant 中等品質，這是 llama.cpp 中的一種量化方法，根據不同層的重要性對其應用不同的位寬。這比均勻量化更好地保留了品質。
甜蜜點：Q4_K_M
對於行動部署，Q4_K_M 是標準選擇。原因如下：
大小： 大約是 FP16 的 4 分之 1。3B 模型只佔 1.7GB，完全在行動應用程式的儲存預算內。
品質： 在 FP16 品質的約 97.5%，退化在大多數任務上幾乎不可測量。對於模型已微調的領域特定任務，微調資料會補償任何量化損失。
速度： 更小的權重意味著推理時使用更少的記憶體頻寬。Q4 模型通常比更高精度的版本運行更快，因為記憶體瓶頸被降低了。
相容性： 適合 4GB+ RAM 裝置（1B）或 6GB+ RAM 裝置（3B）。涵蓋了絕大多數在用的智慧型手機。
量化級別在真實裝置上的比較
3B 模型，iPhone 15 Pro（A17 Pro，8GB RAM）
| 量化 | 大小 | Token/秒 | 記憶體使用量 | 品質（困惑度） |
|---|---|---|---|---|
| Q8_0 | 3.2GB | 14-18 | 4.0GB | 8.12 |
| Q6_K | 2.5GB | 16-20 | 3.2GB | 8.18 |
| Q5_K_M | 2.1GB | 17-22 | 2.7GB | 8.25 |
| Q4_K_M | 1.7GB | 18-25 | 2.2GB | 8.38 |
| Q4_0 | 1.6GB | 19-26 | 2.1GB | 8.52 |
| Q3_K_M | 1.4GB | 20-27 | 1.9GB | 9.05 |
| Q2_K | 1.1GB | 22-29 | 1.5GB | 11.4 |
困惑度越低越好。Q4_K_M 到 Q8_0 之間的品質範圍很窄（8.12-8.38）。低於 Q4，品質明顯下降。低於 Q3，則顯著退化。
3B 模型，Galaxy S24（Snapdragon 8 Gen 3，8GB RAM）
| 量化 | 大小 | Token/秒（Vulkan） | 記憶體使用量 |
|---|---|---|---|
| Q8_0 | 3.2GB | 16-20 | 4.0GB |
| Q5_K_M | 2.1GB | 20-25 | 2.7GB |
| Q4_K_M | 1.7GB | 22-28 | 2.2GB |
| Q3_K_M | 1.4GB | 24-30 | 1.9GB |
1B 模型，iPhone 14（A15，6GB RAM）
| 量化 | 大小 | Token/秒 | 記憶體使用量 |
|---|---|---|---|
| Q8_0 | 1.1GB | 20-26 | 1.4GB |
| Q5_K_M | 750MB | 23-30 | 1.0GB |
| Q4_K_M | 600MB | 25-32 | 800MB |
| Q3_K_M | 500MB | 27-34 | 700MB |
何時使用哪個級別
Q4_K_M（預設選擇）
除非有特殊理由，否則使用這個。大小、速度和品質的最佳整體平衡。行動部署的標準。
- 適合：所有發布 GGUF 模型的行動應用程式
- 裝置需求：4GB+（1B）或 6GB+（3B）
Q5_K_M（品質優先）
當品質至關重要且你的目標裝置有空間容納較大檔案時使用。相比 Q4_K_M 的品質提升很小但可測量，尤其在需要精確用詞的任務上。
- 適合：醫療、法律或金融應用程式，字詞級準確性很重要
- 裝置需求：6GB+（1B）或 8GB+（3B）
- 大小增加：比 Q4_K_M 大約 25%
Q8_0（最高品質）
僅 在有充足 RAM 的旗艦裝置上使用。品質幾乎與 FP16 相同。速度較慢，記憶體使用量較高。
- 適合：測試和效能基準，不適合典型的生產部署
- 裝置需求：8GB+（1B）或 12GB+（3B）
- 大小增加：比 Q4_K_M 大約 90%
Q3_K_M（大小優先）
當你需要在受限裝置上塞入模型時使用。品質明顯下降，但對於簡單任務（分類、是/否、短答案）可能可以接受。
- 適合：入門裝置，或在通常只能放 1B Q4 的空間中放入 3B 模型
- 品質風險：在細緻任務上明顯退化
- 大小節省：比 Q4_K_M 小約 18%
Q2_K（不建議）
嚴重的品質退化。模型頻繁生成不連貫或不正確的輸出。不適合生產環境。
微調與量化
微調在全精度（FP16 或 BF16）下進行。量化作為匯出步驟在訓練後應用。工作流程：
- 使用 LoRA 在你的訓練資料上微調模型（全精度）
- 將 LoRA 適配器合併到基礎模型中
- 以你的目標級別量化為 GGUF（大多數情況下為 Q4_K_M）
- 在你的評估集上測試量化後的模型
像 Ertas 這樣的平台端到端處理這個流程。你上傳訓練資料、選擇基礎模型、訓練，然後直接以你選擇的量化級別匯出到 GGUF。
量化會更傷害微調模型嗎？
略有影響。微調模型的權重中包含更多資訊（領域特定知識）。積極量化（Q3 及以下）可能會失去一些這種特定知識。
在實踐中，Q4_K_M 很好地保留了微調的準確性。Q4_K_M 和 FP16 在領域特定基準上的品質差異通常不到 2 個百分點。Q3_K_M 可能顯示 3-5 個百分點的退化。
實用建議
- 預設使用 Q4_K_M。 它成為標準是有原因的。先用這個測試。
- 先微調再最佳化量化。 微調的 Q4 模型在領域任務上優於未調校的 Q8 模型。
- 在你的任務上測試，不要只看通用基準。 困惑度只是代理指標。重要的是你的模型在你選擇的量化級別下，在你特定評估集上的準確率。
- 每種模型大小只提供一個量化級別。 不要讓使用者在 Q4 和 Q5 之間選擇。發布 Q4_K_M 以獲得廣泛相容性。如果你同時支援 1B 和 3B，那就是足夠的選項了。
- 衡量真實世界的效能。 在量化後的模型上運行你的評估套件。如果準確率在 FP16 的 2% 以內，就可以發布。
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $10/mo USD.
Keep reading
Gemma 3 行動端：微調與裝置端部署
如何將 Google 的 Gemma 3 模型用於裝置端行動 AI。模型選擇、LoRA 微調、GGUF 匯出，以及透過 llama.cpp 在 iOS 和 Android 上部署。
Llama 3.2 行動應用：微調與裝置端部署
在行動應用中使用 Meta Llama 3.2 1B 和 3B 模型的完整指南。使用 LoRA 微調、匯出至 GGUF，以及透過 llama.cpp 在 iOS 和 Android 上部署。
LLM 真的能在 iPhone 上運行嗎？效能基準與實際表現
透過 llama.cpp 在 iPhone 上運行 LLM 的真實基準資料。從 iPhone 12 到 iPhone 16 Pro 各機型的 token 生成速度、記憶體使用量和溫度表現。