LLM 模型特殊量化技術概論：以 Qwen3.5 MLX-4bit 為例
．作者：Jollen
．日期：August 3, 2026 at 8:00 AM
本文從 MLX、llama.cpp、4-bit 量化與 Gated DeltaNet recurrent state，理解 Qwen3.5 在 Apple Silicon 上的 Prefill 效能差異。
雖然 llama.cpp 也能透過 Metal Backend 使用 Apple Silicon GPU，但為什麼 GDN 透過 MLX 技術，在 Apple 裝置上能有更出色的效能表現？難道 Apple MLX 技術有特異功能嗎？本文探討，近期廣受 LLM 量化技術開發者重視的 MLX 硬體技術。
「特殊量化」也是一門「軟體整合實作技術」
本文整理筆者近期的 Qwen3.5 0.8B 特殊量化專案技術手札。
Qwen3.5-0.8B-MLX-4bit 在 Apple Silicon 上能取得較高的 Prefill 效能，主要原因來自 MLX 對 Unified Memory、Lazy Evaluation、運算圖與 Metal kernel 的整體設計。
總結來說，MLX 與 llama.cpp 的效能差距，需要從 Backend 實作、tensor layout、專用 kernel、graph dispatch 與 recurrent state 執行路徑分析。
MLX 如何安排 Apple Silicon 運算
MLX 是針對 Apple Silicon 設計的 Array Framework。Array Framework 是「多維陣列運算」的資料結構，並由 MLX 執行框架安排張量運算（tensor operations）的程式架構。
白話來說，LLM 模型需要先重新安排張量運算所需的資料結構，因此 MLX 模型才需要先以工具做格式轉換。
在 MLX 中，張量運算不一定會即時執行（邊跑邊算）。
MLX 使用 Lazy Evaluation 的技術，來預先記錄運算關係，「等到有需要時」，再進行真正的「組合」與運算；而不是讓程式碼在 Runtime 時期，執行陣列運算。
GPU workflow 是一組由資料配置、kernel dispatch 與同步操作構成的執行流程。Lazy Evaluation 讓 Runtime 有機會整併運算、降低中間結果的實體配置，並形成較連續的 GPU workflow。
此外，Apple Silicon 更採用 Unified Memory 技術，讓 CPU 與 GPU 可以存取同一套實體記憶體。但 Unified Memory 並不代表資料存取與同步完全沒有成本（Overhead）。Buffer 配置、資源綁定、CPU 與 GPU 同步，以及 kernel 之間的中間狀態，仍會影響實際效能。
因此，MLX 的效能優勢來自整體執行路徑。資料能否持續保留在適合 GPU 存取的 buffer、運算能否合併，以及 CPU 是否需要頻繁介入，都會影響 Prefill 吞吐量。
4-bit 量化降低權重讀取成本
以 Qwen3.5-0.8B-MLX-4bit 為例，檔名中的 4bit 代表模型權重主要採用 4-bit 量化表示。4-bit 量化（4-bit quantization）會以較低位元數保存模型權重，其主要目標是降低模型檔案大小、執行期間的權重記憶體用量，以及讀取權重時所需的記憶體頻寬。也就是說，一般認為 4-bit 模型的檔案通常較小，但是：
- Scale 是將低位元整數還原到近似浮點數範圍時使用的縮放參數
- 部分量化格式也可能使用 zero-point，表示量化數值範圍中的零點位置
- 量化 metadata、未量化 tensor，以及 Runtime 使用的中間資料都會占用額外空間
檔案實際大小，仍受量化所需的 scale、group metadata，與其他輔助資料影響。
再者，4-bit 量化模型，也會考慮保留 FP16、BF16 或其他較高精度，例如 normalization、activation、accumulator 與 recurrent state，可能使用高於 4-bit 的運算精度。
4-bit 權重通常需要先經過 dequantization，再以浮點或其他適合硬體的資料型別進行矩陣運算。Dequantization 是利用 scale 等參數，將量化數值還原成近似計算值的過程。因此，4-bit 量化主要降低權重的檔案容量與資料頻寬。
至於其它運算，例如 Prefill，其效能仍取決於 dequantization、矩陣運算、序列處理與狀態更新技術，須單獨研究。
模型量化，分為儲存精度與實際計算精度兩個不同概念。
Gated DeltaNet 的 recurrent state
Qwen3.5 採用的 Gated DeltaNet 技術，會依照 token 順序持續更新固定大小的 recurrent state。先前文章討論，GDN 讓資訊可以「退化」。Recurrent state 是模型處理序列時，用來「反覆」讀取與更新的狀態矩陣；它保存經過壓縮的歷史資訊，並參與後續 token 的計算。
以 Qwen3.5 0.8B 為例，模型包含 18 層 Gated DeltaNet；當 Prefill 在處理較長 Context 時，「每一層」都需要沿著 sequence 依序更新自己的 recurrent state。這類運算具有明確的時間相依性：後一個 token 的狀態更新，需要使用前一個 token 已完成的狀態。
附帶一提，computation graph 是描述「張量運算」與資料依賴關係的執行圖，若 LLM Backend 將 Gated DeltaNet 拆成多個細小的 computation graph nodes，則每個節點都可能產生 scheduling、buffer binding、同步與 kernel dispatch 成本。
Kernel dispatch：Runtime 將 GPU 運算提交給 Metal 執行的分發器。
先將上述技術，都統稱為 Prefill；Prefill 的效能直接影響文字生成速度。一般將文字生成的過程稱為 Decode，二者的效能單位都是 tokens per second，即 Tok/s。當 Prefill tok/s 越高時，Decode tok/s 也越高。
Prefill 效能直接決定 Decode 效能；也就是說，「特殊量化」工作不只考慮檔案大小與記憶體頻寬，也要優化 Prefill 運算。Prefill 效能又受到誰的影響呢？Kernel dispatch 也是關鍵。
單次 kernel dispatch 的成本可能不高，但當它出現在多個 token、18 層 Gated DeltaNet 與多個細小運算中，累積成本就會影響長 Prompt 的 Prefill 效能。
這時，就換 Apple Metal 登場了。
專用 Metal kernel 的作用
Apple Metal 是 Apple 底層圖形硬體加速器，類似 OpenGL 或 OpenCL；軟體透過 Metal 能與 GPU 直接溝通。針對 recurrent sequence 設計的 Metal kernel，可以在一次或較少次數的 dispatch 中處理較長的 sequence。
LLM 特殊量化本質就是「軟硬整合技術」：從格式轉換一路到 Metal 層。
Metal Kernel（以下簡稱 kernel）會在 GPU 內部依序讀取輸入、計算 gate、更新 Delta Rule，並將 recurrent state 持續保留在同一套 buffer 中。所以，便能降低剛才提到的狀態反覆回寫與重新綁定的成本。
對 Gated DeltaNet 來說：
- 專用 kernel 能保持序列更新的連續性
- Recurrent state 在 sequence 處理期間，能持續儲存於 GPU buffer
再者，如果多個運算能更進一步融合到同一個 kernel，還能減少暫存 tensor、graph nodes 與同步點，這項技術稱為 kernel fusion。當運算尚未完整「融合」時，GDN 運算可能被拆成較多 graph nodes；Runtime 也可能需要在每個 sequence step 進行額外的 scheduling 與 dispatch。
Kernel fusion 將原本分離的多個張量運算，合併成一次 GPU kernel 執行，以降低記憶體往返與 dispatch 次數（但也會增加 kernel 設計與驗證的複雜度）。
llama.cpp 支援不同的特殊量化模型，所以即便是 Apple 裝置，有些場合仍需要 llama.cpp 技術。如果 Metal GPU 能力這麼強，那 llama.cpp 那有存在價值嗎？
llama.cpp 同樣能使用 Metal GPU
GGML 是 llama.cpp 使用的張量運算與 computation graph 基礎架構；llama.cpp 可以透過 GGML Metal Backend 使用 Apple Silicon GPU。所以，MLX 與 llama.cpp 兩者都能使用 Metal 硬體，其實際效能差距，來自 Backend 與模型架構支援的完成度。
llama.cpp還是能享受部份 Metal GPU 的優點，所以 MLX 與llama.cpp的差異不能簡化為 GPU 與 CPU 的差異。
技術上，需要觀察的項目包括 GGML computation graph 的拆分方式、tensor layout、Metal kernel、kernel fusion、buffer reuse，以及 recurrent state 的生命週期。
- Tensor layout 是張量資料在記憶體中的排列方式
- Tensor 排列是否符合 kernel 的讀取模式，會直接影響記憶體連續性、向量化效率與 GPU 使用率
- Buffer reuse 是重複使用已配置的記憶體區域，降低每輪運算重新配置與釋放資源的成本
對傳統 Transformer 模型來說，現有矩陣乘法與 Attention kernel 已經有較成熟的最佳化路徑；Gated DeltaNet 再引入 recurrent sequence update，因此需要新的 tensor contract、狀態管理與專用 kernel。
當然，二者的效能還是有差別。因為 MLX 已經形成較直接的 Apple Silicon 執行路徑，而 llama.cpp 的實際效能，仍取決於 GGML Metal Backend 對 Gated DeltaNet 的支援程度。
小結
本文重點：
-
特殊量化，例如 4-bit 量化，能降低權重讀取頻寬，但無法單獨保證較高的 Prefill 速度。
-
Prefill 需要一次處理整段輸入序列。對 Qwen3.5 來說，這個階段同時包含量化權重讀取、矩陣運算、Gated Attention 與 Gated DeltaNet recurrent state 更新。
-
上述階段，只要其中一段需要頻繁建立 graph nodes、重新綁定 buffer 或等待 CPU scheduling，GPU 就可能無法維持連續工作。
-
當量化權重、專用 Metal kernel、Unified Memory 與 recurrent state buffer 能形成完整的 GPU workflow，Prefill 吞吐量就能進一步提高。
-
MLX 在目前的 Apple Silicon 測試環境中能取得較高的 Prefill 效能。這項優勢來自 Array Framework、Lazy Evaluation、專用 Metal kernel、Unified Memory 與狀態生命週期的整體設計。
根據筆者的 Qwen3.5 量化專案實測，以 GGML 與 llama.cpp 做為 Backend，配合 4-bit 特殊量化格式，其 Tok/s 雖無法比擬原生 MLX 模型，但其在 iPhone 裝置上，有非常明顯的記憶體優勢與省電優勢。
相比原生 MLX-4-bit 模型，其執行時期佔用 ~1GB 記憶體；特殊量化後僅僅只需要 ~200MB 即可執行，其模型檔案更可壓縮至 ~400MB；對於特定且需要內建 Qwen3.5 0.8B 模型的 iOS App 來說，己經是一個基礎版的解決方案了。
RAG、語意搜尋與 LLM
第 21 篇，共 21 篇 · 連載中