剛剛

Google 放了一個可能改變整個 LLM 推理格局的炸彈——TurboQuant

TurboQuant 把 KV Cache 從"最貴、最慢、最難優(yōu)化的部件"變成了"幾乎免費"的資源。

搞過大模型部署的人都知道，KV Cache 是推理階段最大的內存殺手。

上下文越長，KV Cache 越膨脹，顯存就越不夠用。

之前的量化方案要么損失精度，要么引入額外的內存開銷（存儲量化常數），搞半天省不了多少。

TurboQuant 的恐怖之處在于：3 bit 量化 KV Cache，質量零損失，速度還更快。

TurboQuant 工作原理動畫演示 TurboQuant 到底干了什么？

用人話講，它做了兩件事：

第一步：PolarQuant —— 換個坐標系看世界

傳統(tǒng)量化就像用網格紙去描點——每個點都需要 X、Y、Z 坐標，每個坐標都得單獨算一個縮放系數，這些縮放系數本身就要占內存（就是所謂的"量化開銷"）。

PolarQuant 換了個思路：先把向量隨機旋轉一下，讓數據分布變得非常集中、可預測，然后改用極坐標來描述。就像把"往東走 3 個路口，往北走 4 個路口"變成"朝 37 度方向走 5 步"。因為角度分布已知且高度集中，不再需要給每小塊數據算縮放系數了——量化開銷直接消失

第二步：QJL —— 1 bit 清理殘差

第一步壓完還有微小的誤差怎么辦？TurboQuant 只用1 個 bit做一個 Johnson-Lindenstrauss 變換，把殘差誤差中的偏差干掉，保證內積計算（也就是注意力分數）不會跑偏。

這兩步加在一起，就是 TurboQuant 的核心：PolarQuant 吃大頭 + QJL 擦屁股，零額外開銷，接近信息論下界。

論文里證明了，TurboQuant 和理論最優(yōu)只差一個約 2.7 倍的常數因子

實測數據有多炸？

Google 在 Gemma 和 Mistral 模型上，用 LongBench、Needle-in-a-Haystack、ZeroSCROLLS、RULER、L-Eval 等一堆長上下文基準做了全面測試。

下面是各方法在不同任務上的聚合性能得分對比（包括問答、代碼生成、摘要等任務）：

TurboQuant 在長上下文基準測試中的性能對比

Needle-in-a-Haystack 測試結果（在海量文本中找一根針）：

Needle-in-a-Haystack 測試結果

TurboQuant 在所有基準上都實現了完美分數，同時將 KV 內存縮小了至少 6 倍。

再看速度——H100 上 4-bit TurboQuant 計算注意力的速度比原始 32-bit Key 快了8 倍：

TurboQuant 在 H100 上的加速效果

• 
  

  同樣的 GPU，能跑 6 倍以上的并發(fā)用戶

• 上下文長度直接拉到 6 倍（長上下文基準全部零損失）

• H100 上端到端吞吐量暴漲

• 無需重訓、無需微調，直接套在現有 Llama、Gemma、Qwen 等模型上就能用

社區(qū)已經開始瘋狂復現：

mlx-vlm 上的 TurboQuant Metal kernel 實現：

mlx-audio & mlx-vlm 創(chuàng)建者 Prince_Canuma 使用 Qwen3.5-35B-A3B 在 8.5K、32.7K 和 64.2K 的上下文長度中進行“大海撈針”測試：

→ 每個量化級別都達到 6/6 完全匹配 → TurboQuant 2.5 位：KV 緩存縮小 4.9 倍 → TurboQuant 3.5 位：KV 緩存縮小 3.8 倍

最棒的是：與完整 KV 緩存相比，準確率沒有損失。

他在 mlx-vlm PR #858 里提交了 TurboQuant 的 Metal kernel 實現，包括：

• _mse_score_kernel、_pack_lowbit_kernel、_unpack_lowbit_kernel—— 基礎量化/反量化

• _qjl_score_kernel、_prod_score_kernel—— QJL 殘差糾偏和內積計算

• _polar_prod_score_kernel、_polar_turbo_score_repeat_kernel—— 4-bit PolarQuant 路徑

• 多頭處理優(yōu)化 kernel：_prod_score_multi_kernel、_mse_weighted_rot_multi_kernel

MLX 上的 TurboQuant kernel 已經把解碼速度追到了全精度的 **85-70%**（8K prompt 下 54 tok/s vs 62.5 tok/s），還在繼續(xù)優(yōu)化。

這意味著Mac 用戶很快就能在本地吃到這個紅利

llama.cpp 集成：TurboQuant+ 已經跑通 Apple Silicon

開發(fā)者 TheTom 做了一個叫 turboquant_plus 的項目，直接把 TurboQuant 移植到了 llama.cpp，用 Metal kernel 在 Apple Silicon 上跑通了端到端推理。

M5 Max 128GB 上的實測：

Cache 類型

壓縮率

Prefill 速度

PPL (wikitext-2)

f16

1.0x

q8_0

2.0x

2694 tok/s

q4_0

4.0x

turbo34.6x2747 tok/s

4.6 倍壓縮，速度還比 q8_0 快了一丟丟，PPL 只漲了 0.8%。

這就是所謂的"三贏"：壓得狠、跑得快、質量幾乎不掉。

實際使用也很簡單，編譯好他的 llama.cpp fork 之后：

# 用 TurboQuant 3-bit KV Cache 跑推理
./build/bin/llama-server \
  -m models/your-model.gguf \
  --cache-type-k turbo3 --cache-type-v turbo3 \
  -ngl 99 -c 262144 -fa on \
  --host 0.0.0.0 --port 8080

兩個參數--cache-type-k turbo3 --cache-type-v turbo3就搞定了，其他什么都不用改。而且他在 Qwen 3.5 35B-A3B MoE 模型上驗證過，2K 到 32K 各種上下文長度，速度都穩(wěn)定在 q8_0 的 99% 左右。

這哥們還在做 TurboQuant+ 擴展，包括自適應 bit 分配、時序衰減壓縮、MoE 感知壓縮等，后續(xù)更值得期待。

vLLM 集成也來了：

開發(fā)者 Mitko Vasilev（@iotcoi）已經在 vLLM 上實現了 TurboQuant。

他在 USB 充電器大小的 HP ZGX 設備上，GB10 顯卡跑出了4,083,072 個 KV-cache tokens。

是的，你沒看錯，400 萬 tokens 的 KV Cache。

他已經提交了 PR 估計合并需要時間。

這意味著什么？

說實話，我個人覺得這是 2026 年目前為止 LLM 推理領域最重要的進展，意義堪比當年 FlashAttention 把注意力從 O(n2) 優(yōu)化成近似線性。

對開發(fā)者：

• 同樣的顯卡跑更大模型、更長上下文，成本暴降

• 無需重訓、無需微調，部署門檻極低——pip install 完事

對 Mac 用戶：

• 16GB Mac Mini 的可用模型范圍直接擴大一圈

• MLX kernel 已經在路上，本地推理速度越來越接近全精度

對云廠商：

• 這是基礎設施層的一次降維打擊

• 推理成本下降意味著 API 降價，意味著更多應用能跑起來

對整個 AI 生態(tài)：

• 大家卷參數、卷 MoE、卷長上下文的時候，TurboQuant 直接把"硬件限制"這個天花板往上抬了一大截

• 訓練是一次性的炫技，推理才是永遠的賬單。TurboQuant 直接把這個賬單砍了一刀

更值得尊敬的是，Google 選擇了完全開放這項研究。

論文發(fā)了、代碼路徑清晰、社區(qū)可以自由復現。

• 論文：https://arxiv.org/abs/2504.19874

他們完全可以把這個捂在 Gemini 里獨享，但他們沒有。

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