三大推理框架vLLM、llama.cpp、MLX 全部跟進！！！

本文是續集，看下主流推理框架跟進了情況

全面開花：誰在做，做到了什么程度？

先給一張全景圖，讓你 30 秒掌握當前進展：

框架

平臺

狀態

核心亮點

oMLX

Apple Silicon

? 已發布（v0.2.21）

128K 上下文 KV 省 79%，一鍵開啟

mlx-vlm

Apple Silicon

PR 進行中

Metal kernel 實現，解碼速度逼近全精度

llama.cpp

全平臺

實驗中

已有可編譯分支，社區在推進

vLLM

CUDA

方案已出

完整 6 步集成計劃，等 PR

oMLX：Mac 用戶已經可以用了

這是目前進度最快的——oMLX v0.2.21 已經把 TurboQuant KV Cache 作為實驗功能正式發布了。

oMLX TurboQuant KV Cache 功能界面

先簡單說說 oMLX 是什么：這是一個專為 Mac 優化的本地 LLM 推理服務器，支持菜單欄管理、連續批處理、熱/冷兩級 KV Cache（內存+SSD），還有漂亮的 Admin Dashboard。用 Homebrew 裝完就能跑，OpenAI API 兼容，Claude Code、OpenCode 都能直接對接。

更具體介紹請看：

TurboQuant 在 oMLX 里的實現思路很巧妙：

Prefill 階段完全用 fp16，零質量損失。第一個 decode token 生成時，才把累積的 KV Cache 量化成 3-bit 或 4-bit 的 codebook 索引。Decode 注意力用的是一個 fused 兩遍 Flash Attention Metal kernel，直接從 packed 索引讀取——不需要反量化，不需要 fp16 中間張量。

這個設計太聰明了，Prefill 不碰你的精度，decode 階段才壓縮，而且 kernel 直接操作壓縮后的數據，不走解壓再算的老路。

實測大海撈針（Qwen3.5-35B-A3B，3-bit TurboQuant）：

上下文長度

Baseline

TurboQuant

KV 內存節省

32K

735MB → 195MB（省 73%）

64K

1407MB → 327MB（省 77%）

128K

2749MB → 589MB（省 79%）

128K 上下文，KV Cache 從 2.7GB 壓到 589MB，質量零損失。

對于 Mac 用戶來說，這意味著你的機器一下子能裝下更長的上下文了。

速度方面也很穩：

模型

Prefill 速度

Decode 速度

Qwen3.5-35B-A3B

fp16 的 95%

fp16 的 87%

Qwen3.5-27B

fp16 的 97%

fp16 的 95%

用起來也簡單——Admin UI → 模型設置 → 實驗功能 → 打開 TurboQuant KV Cache 開關，完事。

# 安裝 oMLX
brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx


 # 啟動服務
brew services start omlx

順便提一句，這個版本還帶了 **oQ+**——在 oQ 的混合精度量化基礎上加了 GPTQ 權重優化。對 MoE 模型做了批處理算法加速，Qwen3.5-35B-A3B（256 experts × 40 layers）6 分鐘搞定，比順序處理快 15 倍。

mlx-vlm：Metal Kernel 正在逼近全精度

mlx-vlm 的作者 Blaizzy 在 PR [1] 里提交了一套完整的 TurboQuant Metal kernel 實現。

這個 PR 一共提了 5 個 commit，逐步構建了完整的 TurboQuant 推理鏈路：

基礎 kernel：

• _mse_score_kernel—— MSE 評分

• _pack_lowbit_kernel/_unpack_lowbit_kernel—— 低位打包/解包

• _qjl_score_kernel—— QJL 1-bit 殘差糾偏

• _prod_score_kernel—— 內積計算

多頭優化 kernel：

• _prod_score_multi_kernel—— 多頭批處理

• _mse_weighted_rot_multi_kernel—— 加權旋轉多頭處理

• _prod_score_repeat_kernel—— 重復模式優化

4-bit PolarQuant 路徑：

• _polar_prod_score_kernel—— 極坐標內積

• _polar_turbo_score_repeat_kernel—— 極坐標重復模式

同時scaled_dot_product_attention函數也做了適配，針對單 query 輸入走 TurboQuant 快速解碼路徑。

從已知數據看，MLX TurboQuant kernel 的解碼速度已經追到全精度的 **70-85%**，還在繼續優化。這個 PR 合進去之后，所有用 mlx-vlm 的項目都能直接受益。

llama.cpp：Issue 已開，社區在推

llama.cpp 這邊，Issue [2] 已經有人開了 feature request。

更值得關注的是，開發者 @mudler 已經在動手了——他 fork 了一個 feat/turbo-quant 分支[3]，目前已經能編譯和啟動，正在評估效果。

llama.cpp 一旦正式支持 TurboQuant，影響面是最大的。

因為 llama.cpp 是目前本地部署生態的基石——Ollama、LM Studio、GPT4All 等等一大堆上層應用都依賴它。

llama.cpp 支持了，意味著整個本地部署生態都支持了。

vLLM：方案最詳細，等 PR

vLLM 這邊開的 Issue [4] 信息量最大，直接給出了一份 6 步集成方案：

1. 擴展 Cache 配置—— 在CacheDType里加"turboquant"

2. 創建 TurboQuantConfig 類—— 用@register_quantization_config裝飾器

3. 實現 KV Cache Method—— 繼承BaseKVCacheMethod，注冊 codebook 參數

4. 更新量化檢測—— 讓is_quantized_kv_cache()識別 TurboQuant

5. 實現 CUDA/Triton Kernel—— 編碼 kernel（量化存儲）+ 解碼 kernel（注意力計算前還原）

6. 內存管理更新—— 適配 codebook 額外開銷和可變壓縮率

這個 Issue 寫得像一份小型技術設計文檔，給后來接手的開發者鋪好了路。

對于跑云端推理的場景，vLLM + TurboQuant 的組合會非常有沖擊力——4-5 倍 KV Cache 壓縮，意味著同樣的 H100 能撐更多并發、更長上下文。

2026 年的本地 AI 體驗，會因為 TurboQuant 而躍遷一個檔次。我很期待。

.cpp

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個 ，謝謝你看我的文章，我們下篇再見！

參考資料

PR : https://github.com/Blaizzy/mlx-vlm/pull/858

Issue : https://github.com/ggml-org/llama.cpp/issues/20977

feat/turbo-quant 分支: https://github.com/mudler/llama.cpp/tree/feat/turbo-quant

Issue : https://github.com/vllm-project/vllm/issues/38171