三大推理框架vLLM、llama.cpp、MLX 全部跟進(jìn)?。?！

本文是續(xù)集，看下主流推理框架跟進(jìn)了情況

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

先給一張全景圖，讓你 30 秒掌握當(dāng)前進(jìn)展：

框架

平臺(tái)

狀態(tài)

核心亮點(diǎn)

oMLX

Apple Silicon

? 已發(fā)布（v0.2.21）

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

mlx-vlm

Apple Silicon

PR 進(jìn)行中

Metal kernel 實(shí)現(xiàn)，解碼速度逼近全精度

llama.cpp

全平臺(tái)

實(shí)驗(yàn)中

已有可編譯分支，社區(qū)在推進(jìn)

vLLM

CUDA

方案已出

完整 6 步集成計(jì)劃，等 PR

oMLX：Mac 用戶已經(jīng)可以用了

這是目前進(jìn)度最快的——oMLX v0.2.21 已經(jīng)把 TurboQuant KV Cache 作為實(shí)驗(yàn)功能正式發(fā)布了。

oMLX TurboQuant KV Cache 功能界面

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

更具體介紹請(qǐng)看：

TurboQuant 在 oMLX 里的實(shí)現(xiàn)思路很巧妙：

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

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

實(shí)測(cè)大海撈針（Qwen3.5-35B-A3B，3-bit TurboQuant）：

上下文長度

Baseline

TurboQuant

KV 內(nèi)存節(jié)省

32K

735MB → 195MB（省 73%）

64K

1407MB → 327MB（省 77%）

128K

2749MB → 589MB（省 79%）

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

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

速度方面也很穩(wěn)：

模型

Prefill 速度

Decode 速度

Qwen3.5-35B-A3B

fp16 的 95%

fp16 的 87%

Qwen3.5-27B

fp16 的 97%

fp16 的 95%

用起來也簡(jiǎn)單——Admin UI → 模型設(shè)置 → 實(shí)驗(yàn)功能 → 打開 TurboQuant KV Cache 開關(guān)，完事。

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


 # 啟動(dòng)服務(wù)
brew services start omlx

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

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

mlx-vlm 的作者 Blaizzy 在 PR [1] 里提交了一套完整的 TurboQuant Metal kernel 實(shí)現(xiàn)。

這個(gè) PR 一共提了 5 個(gè) commit，逐步構(gòu)建了完整的 TurboQuant 推理鏈路：

基礎(chǔ) kernel：

• _mse_score_kernel—— MSE 評(píng)分

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

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

• _prod_score_kernel—— 內(nèi)積計(jì)算

多頭優(yōu)化 kernel：

• _prod_score_multi_kernel—— 多頭批處理

• _mse_weighted_rot_multi_kernel—— 加權(quán)旋轉(zhuǎn)多頭處理

• _prod_score_repeat_kernel—— 重復(fù)模式優(yōu)化

4-bit PolarQuant 路徑：

• _polar_prod_score_kernel—— 極坐標(biāo)內(nèi)積

• _polar_turbo_score_repeat_kernel—— 極坐標(biāo)重復(fù)模式

同時(shí)scaled_dot_product_attention函數(shù)也做了適配，針對(duì)單 query 輸入走 TurboQuant 快速解碼路徑。

從已知數(shù)據(jù)看，MLX TurboQuant kernel 的解碼速度已經(jīng)追到全精度的 **70-85%**，還在繼續(xù)優(yōu)化。這個(gè) PR 合進(jìn)去之后，所有用 mlx-vlm 的項(xiàng)目都能直接受益。

llama.cpp：Issue 已開，社區(qū)在推

llama.cpp 這邊，Issue [2] 已經(jīng)有人開了 feature request。

更值得關(guān)注的是，開發(fā)者 @mudler 已經(jīng)在動(dòng)手了——他 fork 了一個(gè) feat/turbo-quant 分支[3]，目前已經(jīng)能編譯和啟動(dòng)，正在評(píng)估效果。

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

因?yàn)?llama.cpp 是目前本地部署生態(tài)的基石——Ollama、LM Studio、GPT4All 等等一大堆上層應(yīng)用都依賴它。

llama.cpp 支持了，意味著整個(gè)本地部署生態(tài)都支持了。

vLLM：方案最詳細(xì)，等 PR

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

1. 擴(kuò)展 Cache 配置—— 在CacheDType里加"turboquant"

2. 創(chuàng)建 TurboQuantConfig 類—— 用@register_quantization_config裝飾器

3. 實(shí)現(xiàn) KV Cache Method—— 繼承BaseKVCacheMethod，注冊(cè) codebook 參數(shù)

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

5. 實(shí)現(xiàn) CUDA/Triton Kernel—— 編碼 kernel（量化存儲(chǔ)）+ 解碼 kernel（注意力計(jì)算前還原）

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

這個(gè) Issue 寫得像一份小型技術(shù)設(shè)計(jì)文檔，給后來接手的開發(fā)者鋪好了路。

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

2026 年的本地 AI 體驗(yàn)，會(huì)因?yàn)?TurboQuant 而躍遷一個(gè)檔次。我很期待。

.cpp

制作不易，如果這篇文章覺得對(duì)你有用，可否點(diǎn)個(gè)關(guān)注。給我個(gè)三連擊：點(diǎn)贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個(gè) ，謝謝你看我的文章，我們下篇再見！

參考資料

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