Local LLM 量化如何跨硬體選擇：NVFP4、FP8、MLX 4-bit 與 8-bit¶

狀態：已發布　領域：AI／Local LLM／量化與推論系統
基準版本：NVIDIA、Apple、MLX 與 oMLX 官方資料（查證至 2026-08-20）　整理日期：2026-08-20
理解確認：已於 2026-08-20 明確完成　內容核准：已於 2026-08-20 取得

這篇文章要解決什麼問題？

「4-bit 一定比 8-bit 快嗎？」不能脫離硬體與 Runtime 回答。本文以 NVIDIA DGX Spark／GB10 與 48GB Apple M5 Pro MacBook Pro 為案例，建立容量、記憶體頻寬、Prefill、Decode、KV cache、量化 recipe 與軟體 kernel 的共同分析框架，並說明 NVFP4、FP8、MLX 4-bit 與 8-bit 為何不能只憑名稱直接比較。

適用範圍與限制

本文整理理論模型與官方已確認能力，不宣稱提供特定模型的實測排名。理論 tokens/s 是頻寬上限估算，不是效能保證。實際結果仍取決於模型架構、量化 recipe、Runtime、kernel、Context、Batch、KV cache 精度、記憶體壓力與散熱條件。

先看結論¶

先問能不能放得下，再問跑得多快。 權重、量化 metadata、KV cache、Runtime workspace 與作業系統都會占用記憶體。
低 Batch Decode 通常偏向記憶體頻寬受限。 較低位元權重能減少每個 Token 的權重流量，因此 4-bit 有合理的速度優勢，但端到端加速通常小於理想的 2 倍。
Prefill 通常更偏向計算受限。 多個輸入 Token 能重用同一批權重，運算密度提高，低精度矩陣計算能力與 kernel 效率更重要。
長 Context 會提高 KV cache 流量。 權重從 8-bit 降到 4-bit，不會自動縮小 KV cache；當 KV cache 成為主導流量時，兩種權重格式的速度差距可能縮小。
DGX Spark 的 FP4 與 Mac 上的「4-bit 模型」不能直接視為同一件事。 Spark 有 NVIDIA Blackwell FP4 硬體路徑；Apple Silicon 上則要看 MLX／Metal 的量化模式與 kernel。MLX 即使支援名為 nvfp4 的模式，也不能單憑名稱推導出與 Blackwell 相同的硬體峰值或加速比例。
量化格式不是唯一變因。 Calibration data、Group size、Scaling、敏感層保留精度、Activation／KV cache 精度與量化演算法都屬於量化 recipe。
真正的選擇是速度、容量與品質的折衷。 在固定記憶體下，較大模型的 4-bit 可能比小模型的 8-bit 更實用，也可能因量化退化而不值得；必須先定義品質門檻。

一、建立共同成本模型¶

1. 權重容量¶

忽略 metadata、對齊與 Runtime overhead，量化後的理論權重容量可近似為：

\[ M_{\mathrm{weights}} \approx N_{\mathrm{total}}\times\frac{b}{8} \]

其中：

\(N_{\mathrm{total}}\)：模型總參數量。
\(b\)：每個參數的理論位元數。
\(M_{\mathrm{weights}}\)：理論純權重容量。

這只是第一層估算。實際占用還包括：

Quantization scales、zero points、global scales 與 metadata。
部分未量化或保留高精度的層。
Tensor alignment。
Activations 與 Runtime workspace。
KV cache。
作業系統與其他程式。

因此，「純權重小於可用記憶體」不等於「能在目標 Context 與 Concurrency 下穩定執行」。

2. 低 Batch Decode 的頻寬上限¶

對 Dense 模型的低 Batch Decode，可先用以下概念式理解：

\[ \mathrm{TPS}_{\mathrm{ideal}} \approx \frac{B_{\mathrm{memory}}} {M_{\mathrm{traffic/token}}} \]

其中：

\(B_{\mathrm{memory}}\)：可持續使用的記憶體頻寬。
\(M_{\mathrm{traffic/token}}\)：每產生一個 Token 所需搬運的資料量。

若權重流量占主導，將權重從 8-bit 降為 4-bit，理論流量接近減半，Decode TPS 上限便可能接近提高一倍。但實際加速通常較小，因為還有 scale、unpack、其他層、KV cache 與非理想頻寬利用率。

二、Prefill 與 Decode 為何有不同瓶頸？¶

Prefill：通常較偏計算受限¶

Prefill 一次處理多個輸入 Token，主要工作較接近大型 Matrix–Matrix Multiplication：

多個輸入 Token × 模型權重
→ 權重能被多個 Token 重用
→ 運算密度提高
→ Tensor／Matrix 計算能力與 kernel 效率更重要

低精度在 Prefill 的價值不只來自資料較小，也來自硬體是否有高吞吐量的低精度矩陣運算路徑。

Decode：低 Batch 時通常較偏頻寬受限¶

Decode 通常一次只為每條序列產生一個新 Token，較接近 Matrix–Vector Multiplication：

少量 Token × 大量權重
→ 權重重用率低
→ 每個 Token 都要搬運大量權重
→ 記憶體頻寬容易先成為瓶頸

因此 4-bit 對低 Batch Decode 特別有吸引力：相同頻寬可以搬運更多量化權重。

Batch 增加後，瓶頸可能改變¶

Continuous batching 讓多條序列共同使用同一批權重：

Batch／Concurrency 增加
→ 權重重用率提高
→ 總吞吐量增加
→ 系統可能逐漸從頻寬受限轉向計算受限

所以單請求 Decode TPS 不能代表多人 Serving 的總吞吐量與尾端延遲。

三、長 Context：KV cache 何時接管瓶頸？¶

每產生一個新 Token，系統除了讀取權重，也要存取先前 Context 的 Key／Value：

每 Token 記憶體流量
≈ 權重流量＋KV cache 流量＋其他資料流量

短 Context¶

權重流量 ≫ KV cache 流量

此時降低權重位元數通常最有效。

長 Context¶

KV cache 流量占比逐漸增加

即使 4-bit 權重仍較小，整體 Decode 也可能逐漸由 KV cache 主導。若 KV cache 仍使用 BF16／FP16，單純降低權重精度的邊際收益會縮小。

KV cache 成本還受到下列因素影響：

Context length。
Batch／Concurrency。
MHA、GQA 或 MQA 架構。
KV cache precision。
Prefix cache 命中率。
Cache 是否位於可被 GPU 高效存取的 Hot tier。

四、DGX Spark：NVFP4 與 FP8 的合理比較方式¶

官方已確認的硬體基準¶

NVIDIA 官方 DGX Spark 頁面指出：

DGX Spark 使用 GB10 Grace Blackwell Superchip。
配備 128GB coherent unified system memory。
第五代 Tensor Cores 支援 FP4。
官方標示最高 1 petaFLOP FP4 AI performance。

因此，將 DGX Spark 描述成「沒有 FP4 支援，只能把 FP4 完全退回 FP8／FP16 路徑」並不符合官方產品資料。

NVFP4 不只是把 FP8 截成 4 bits¶

NVIDIA 對 NVFP4 的說明包括：

元素採 E2M1 4-bit 表示。
每 16 個值共享一個 E4M3 FP8 scale。
另有 per-tensor FP32 scale。
目標是在降低記憶體使用與提高吞吐量的同時，降低相較於其他 4-bit 格式的量化誤差風險。

因此，NVFP4 的實際容量並不是單純每參數剛好 4 bits；scale 與其他資料仍有成本。

何時合理預期 NVFP4 較快？¶

相同基礎模型
＋相容的量化 recipe
＋Runtime 選到最佳化 NVFP4 kernel
＋低 Batch Decode
＋權重流量是主要瓶頸
→ NVFP4 合理預期比 FP8 快

但「硬體支援 FP4」只是必要條件，不保證任意 Runtime、模型與 kernel 組合都能達到理論加速。

五、Apple M5 Pro 48GB：容量與頻寬如何估算？¶

官方已確認的硬體基準¶

Apple 官方 MacBook Pro 技術規格列出：

M5 Pro 可配置 48GB unified memory。
M5 Pro 記憶體頻寬為 307GB/s。

Unified memory 讓 CPU 與 GPU 共用同一記憶體池，但模型仍會與 macOS、應用程式、Runtime、KV cache 及工作區競爭容量與頻寬。

Dense 模型的理論上限示例¶

以下只用 307GB/s 與純權重大小估算理想上限，假設每 Token 讀取一次全部權重，且忽略所有 overhead：

Dense 模型	純 4-bit 權重	4-bit 理想上限	純 8-bit 權重	8-bit 理想上限
14B	7GB	43.9 tok/s	14GB	21.9 tok/s
32B	16GB	19.2 tok/s	32GB	9.6 tok/s
35B	17.5GB	17.5 tok/s	35GB	8.8 tok/s
70B	35GB	8.8 tok/s	70GB	4.4 tok/s

這不是實測預測

真實系統無法把全部 307GB/s 永遠交給權重讀取，也不能忽略 scale、Kernel、KV cache、工作區與系統流量。表格只能顯示「在純頻寬模型下，權重位元數與 TPS 上限的比例關係」。

48GB 裝置的實際含義¶

以 32B Dense 模型為例：

4-bit 純權重：約 16GB
8-bit 純權重：約 32GB

4-bit 不只可能提高 Decode TPS，也會留下更多空間給：

KV cache。
長 Context。
多條並行序列。
Runtime workspace。
macOS 與其他程式。

70B 4-bit 的純權重雖約 35GB，但加入量化 overhead、KV cache、Runtime 與系統使用後，在 48GB 裝置上會相當緊張。70B 8-bit 則單是理論權重便超過 48GB。

六、Apple Silicon 上的 4-bit 不等於 Blackwell NVFP4¶

MLX 提供多種量化模式¶

Apple 的 MLX 原始碼目前列出 affine、mxfp4、nvfp4 與 mxfp8 等量化模式，並在 Metal backend 中包含對應量化 kernel。這證明 MLX 軟體介面能表示並執行這些模式。

但必須區分：

軟體支援某個量化模式
≠
Apple 官方宣告與 Blackwell 相同的原生 FP4 Tensor Core 峰值

因此不能看到 MLX checkpoint 標示 nvfp4，就直接套用 DGX Spark／Blackwell 的理論 petaFLOP 或加速比例。兩邊仍需要分別分析硬體執行路徑與 kernel。

GGUF、MLX checkpoint 與數值格式是不同層次¶

GGUF：模型容器，可包含 Q4、Q5、Q8 等量化方案。
MLX checkpoint：適合 MLX Runtime 的模型權重與量化設定。
NVFP4／FP8／Affine quantization：數值表示與 scaling 方法。
Metal／CUDA kernel：實際執行 unpack、scale 與矩陣運算的程式路徑。

只比較檔名中的「4-bit」或「8-bit」，不足以推導實際速度與品質。

七、oMLX：Serving 層如何改變問題？¶

依 oMLX 官方專案說明，oMLX 是針對 Apple Silicon 的 LLM inference server，提供：

Continuous batching。
OpenAI-compatible API。
Hot in-memory 與 Cold SSD 的分層 KV caching。
模型常駐與按需求切換等管理能力。

這些功能不改變底層物理限制，但會改變使用者觀察到的延遲與容量。

SSD KV cache 的正確角色¶

SSD tier 主要用於保存與重用不活躍的 KV cache，減少相同前綴再次完整 Prefill 的成本。它不是 active Decode 的高頻寬替代品。

應分清：

Cold：沒有可重用 Cache，完整 Prefill
RAM hit：KV cache 已在 Hot tier
SSD hit：需從 SSD 恢復
Partial hit：只重用共同前綴

若未區分 Cache 狀態，較低 TTFT 可能只是 Cache hit，而不是量化格式本身較快。

Continuous batching 的作用¶

Continuous batching 可提高權重重用率與總吞吐量，但也可能提高單一請求的排程延遲。故單人使用與多人 API Serving 不能用同一個 TPS 指標概括。

八、Dense 與 MoE 必須用不同方式估算¶

Dense¶

Total Parameters ≈ Active Parameters

低 Batch Decode 時，每個 Token 通常要經過幾乎全部主要權重，因此前述「頻寬 ÷ 權重大小」模型較有直觀意義。

MoE¶

容量需求：主要看 Total Parameters
每 Token 計算量：主要看 Active Parameters
每 Token 權重流量：看被路由到的 Experts＋Shared Layers

MoE 不代表未啟用的 Experts 不需要保存。另一方面，每 Token 也不一定需要讀取全部 Total Parameters，因此不能把 Dense 70B 的理論 Decode 公式直接套到 70B Total 的 MoE。

九、量化 recipe：不能忽略的混雜變因¶

兩個模型即使分別標為 4-bit 與 8-bit，差異仍可能來自：

PTQ 或 QAT。
Calibration dataset。
Group size。
Per-tensor、per-channel 或 per-block scaling。
Outlier handling。
Embedding、LM head 或敏感層是否保留較高精度。
Weight-only、Weight＋Activation 或 KV cache quantization。
不同 checkpoint、Tokenizer 或模型修訂版。
不同 Runtime 與 kernel。

因此，若兩個模型來自不同製作者或不同量化流程，最多只能說：

這兩個具體 checkpoint 與軟體組合，在指定條件下有這樣的差異。

不能直接推廣成：

所有 4-bit 都比所有 8-bit 快，或所有 NVFP4 都優於所有 FP8。

十、工程決策流程¶

先定義任務與最低品質門檻
        ↓
模型權重＋KV cache＋Runtime 是否放得下？
        ├─ 否 → 降低位元、縮短 Context、降低 Concurrency 或換較小模型
        └─ 是
            ↓
主要工作是 Prefill 還是 Decode？
        ├─ Prefill → 看低精度計算能力、Attention 與 kernel
        └─ Decode → 看有效記憶體頻寬與每 Token 流量
            ↓
Context 是否很長？
        ├─ 是 → 加入 KV cache 容量、精度與頻寬分析
        └─ 否 → 權重量化的相對收益通常較明顯
            ↓
是否有多請求／Continuous batching？
        ├─ 是 → 同時看總吞吐量、單請求延遲與尾端延遲
        └─ 否 → 低 Batch Decode 模型較適用
            ↓
量化後品質是否通過任務門檻？
        ├─ 否 → 提高精度或改善量化 recipe
        └─ 是 → 在合格方案中選容量、速度與維護成本較佳者

十一、若未來要驗證，應分開測什麼？¶

本文不提供特定裝置的實測排名，但理論若要落地，至少要分開量測：

特性	測試方式	指標
容量	相同模型比較不同量化	權重大小、Peak memory、最大 Context
Prefill	固定輸出、掃描輸入長度	TTFT、Prompt tok/s
Decode	短 Prompt、長輸出、Batch 1	Decode tok/s、ITL
KV cache	掃描 Context 與 KV precision	TPS 下降、Memory growth
Concurrency	掃描並行請求數	Aggregate TPS、P50／P95 latency
Cache tier	Cold、RAM hit、SSD hit	恢復時間、TTFT
品質	相同任務與評分方式	Accuracy、Pass rate、人工驗收
穩定性	重複與長時間執行	OOM、Crash、Error rate

公平比較至少固定：

相同基礎模型與版本。
相同 Prompt、Tokenizer 與 generation settings。
相同 Runtime 與版本。
相同 Context、Batch、Concurrency 與 KV cache 精度。
相同 Cache hit／miss 狀態。
相同 Warm-up、重複次數與散熱條件。

十二、對原始討論的整理與修正¶

原始方向	決定	整理後表述
DGX Spark 沒有 FP4 計算支援	移除	NVIDIA 官方資料明確表示 GB10／第五代 Tensor Cores 支援 FP4。
NVFP4 一定比 FP8 快	條件式保留	在最佳化 kernel、低 Batch Decode 且權重流量主導時，NVFP4 有合理速度優勢；不是跨模型與 Runtime 的無條件定律。
NVFP4 容量是 FP8 的精確一半	修正	4-bit 元素之外仍有 block scales、global scale、metadata 與高精度層。
長 Context 仍只看權重大小	移除	KV cache 容量與流量可能逐漸成為主導瓶頸。
Mac 的 4-bit 等於 NVIDIA NVFP4	修正	MLX 量化模式、Metal kernel 與 Blackwell 原生 FP4 硬體路徑必須分開討論。
一個 tokens/s 就能決定格式優劣	移除	Prefill、Decode、Context、Concurrency、品質與 Cache 狀態要分別評估。
不同 checkpoint 的差異可全歸因於位元格式	移除	量化 recipe 與 Runtime 是重要混雜變因。

十三、尚未聲稱的事情¶

本文刻意不宣稱：

DGX Spark 上任意 NVFP4 模型必然比 FP8 快多少。
48GB M5 Pro 上任意 32B／70B 模型的實際 TPS。
MLX 的 nvfp4 模式等同 Apple 官方宣告的原生 FP4 硬體峰值。
SSD KV cache 可直接取代 active Decode 所需的統一記憶體頻寬。
某一量化格式在所有語言、Coding、RAG 或 Agent 任務都維持相同品質。

這些結論都需要特定版本、模型、Runtime 與測試條件才能成立。

來源¶

NVIDIA，〈NVIDIA DGX Spark〉：GB10、128GB coherent unified memory、第五代 Tensor Cores、FP4 支援與官方 FP4 峰值說明。
NVIDIA Technical Blog，〈Introducing NVFP4 for Efficient and Accurate Low-Precision Inference〉，2025-06-24：NVFP4 E2M1、16-value micro-block、E4M3 scale 與 per-tensor FP32 scale。
Apple，〈MacBook Pro Technical Specifications〉：M5 Pro 48GB unified memory 選項與 307GB/s memory bandwidth。
Apple MLX，〈Quantized layers implementation〉：Affine、MXFP4、NVFP4、MXFP8 等量化模式與 QuantizedLinear／Embedding。
Apple MLX，〈Metal floating-point quantized kernels〉：Metal backend 中對 NVFP4、MXFP4、MXFP8 模式的 kernel 定義。
oMLX，〈jundot/omlx〉：Apple Silicon inference server、Continuous batching、OpenAI-compatible API 與分層 KV caching。
私有 Gemini 討論：僅作為問題來源與錯誤修正脈絡，不作為技術證據，也不公開原始私人對話網址。