RESEARCH

3 月 24 日，Google Research 發(fā)布了一套量化壓縮算法，叫 TurboQuant。核心能力一句話講完：把 LLM 推理時最吃內(nèi)存的 KV cache 壓到極低的 bit 寬度，3.5 bit 精度零損失，2.5 bit 僅有極微小的質(zhì)量下降，內(nèi)存縮小至少 6 倍，attention 計算在 H100 上最高快 8 倍

整個過程免訓練、免微調(diào)、免校準，純軟件方案，拿來就能用

32 bit per channel 幾十 GB 內(nèi)存 → TurboQuant → 3.5 bit per channel 零精度損失 內(nèi)存 ÷6 速度 ×8 3.5 bit 零損失

有多直接呢，發(fā)布不到 24 小時，已經(jīng)有人在一臺幾千塊的 Mac Mini 上用它跑通了 Qwen3.5-35B-A3B 的 64K token 長對話，回答質(zhì)量跟不壓縮的時候完全一樣

論文下個月在 ICLR 2026 主會上發(fā)表。作者來自 Google Research、Google DeepMind 和紐約大學

6 倍壓縮，什么概念

先把這個數(shù)字翻譯成大家能摸到的東西

一個 8B 參數(shù)的模型跑長對話推理的時候，KV cache 可以吃掉幾十 GB 內(nèi)存。一張 80GB 的 H100 顯卡，光 KV cache 就能占掉一大半。壓縮 6 倍 之后，這部分從幾十 GB 降到幾個 GB

直接的效果：同一張顯卡能跑更長的對話，或者同時服務更多用戶

再換一個更直覺的場景。一臺 Mac Mini M4 Pro，24GB 統(tǒng)一內(nèi)存。之前跑 Qwen3.5-35B 做長對話，KV cache 膨脹到一定程度就撐不住了。TurboQuant 把 KV cache 壓下來之后，這個上限往后推了很多

Mac Mini 上跑 Qwen3.5-35B 的 6 萬字長對話，needle-in-a-haystack 測試全部命中

發(fā)布不到 24 小時，Twitter @Prince_Canuma 已經(jīng)把 TurboQuant 移植到了 Apple Silicon 的 MLX 框架上，用 Qwen3.5-35B 做了驗證。從 8.5K 到 64K token 上下文，2.5 bit 量化，KV cache 縮小近 5 倍，needle-in-a-haystack 測試 6/6 精確命中

第三方模型，第三方硬件，跟 Google 自己的 benchmark 結果吻合

https://x.com/Prince_Canuma/status/2036611007523512397

KV cache 為什么是瓶頸

你跟 AI 聊天的時候，對話越長，AI 需要記住的「前文」就越多，內(nèi)存占用就越大。這部分專門用來存「前文」的內(nèi)存，叫 KV cache

技術上：LLM 生成文本的時候，每讀到一個 token，都會算出一組 key 和 value 向量存起來。后面生成新 token 時，模型要回頭查這些 key-value 對，來決定該關注之前哪些內(nèi)容

對話越長，存的越多，內(nèi)存線性增長。上下文到了 32K、64K、128K token 的時候，KV cache 的內(nèi)存開銷經(jīng)常比模型權重還大

壓縮 KV cache 是自然的方向。把 32 bit 浮點數(shù)量化成更少的 bit，內(nèi)存就省下來了。但傳統(tǒng)的量化方法有一個很煩的問題

傳統(tǒng)方法在壓縮的同時，需要額外存儲一堆歸一化常數(shù)。這些常數(shù)要用高精度來存（比如 16 bit），每個數(shù)據(jù)塊都配一組。算下來，額外開銷大概 1-2 bit

壓縮省了 3 bit，歸一化常數(shù)吃回去 1-2 bit，凈收益就打折了

TurboQuant 要解決的就是這個問題

TurboQuant 怎么做的

兩步壓縮。第一步把數(shù)據(jù)壓小，第二步把壓縮帶來的誤差修掉。最終效果：32 bit 的數(shù)據(jù)變成 3 bit 多一點，模型該記住的東西一個都沒丟

TurboQuant 兩步壓縮 32 bit 原始向量 Step 1 · PolarQuant 隨機旋轉 → 極坐標變換 歸一化開銷 → 0 消耗 b-1 bit · 捕獲主體信息 微小殘差 ↓ Step 2 · QJL JL 變換 → 符號位 (+1/-1) 消耗 1 bit · 消除內(nèi)積偏差 b bit · 零偏差 · 零額外開銷

第一步：PolarQuant

傳統(tǒng)壓縮方法在壓數(shù)據(jù)的同時，要額外存一堆「輔助參數(shù)」保證精度。這些參數(shù)本身也占內(nèi)存，相當于壓縮打了折。PolarQuant 通過一個數(shù)學技巧，讓這些輔助參數(shù)變得不再需要

具體做法：先對輸入向量施加一個隨機旋轉矩陣。旋轉之后，每個維度上的數(shù)值分布變得非常集中、非常規(guī)律，跟原始數(shù)據(jù)長什么樣無關。分布規(guī)律了，就可以用一套事先算好的固定量化表來處理所有數(shù)據(jù)

數(shù)學上：把向量從笛卡爾坐標系轉成極坐標系。笛卡爾坐標是「沿 X 軸走多少、Y 軸走多少」，極坐標是「總距離多少、角度多少」。角度的分布在高維空間中是已知的、高度集中的 Beta 分布

歸一化開銷，消掉了

隨機旋轉還帶來一個額外好處：高維空間中，旋轉后的各個坐標之間近似獨立同分布（i.i.d.）。獨立了，就可以把多維的量化問題拆成一堆一維的標量量化問題（Max-Lloyd 問題），每個維度單獨求最優(yōu)解。算一次，存好 codebook，之后在線推理直接查表

PolarQuant 單獨作為一篇論文，將在 AISTATS 2026 上發(fā)表

第二步：QJL

第一步壓完之后，數(shù)據(jù)體積大幅縮小了，但會帶一點微小的誤差。這個誤差如果不管，模型在判斷「這段對話里哪些內(nèi)容更重要」的時候會出現(xiàn)系統(tǒng)性偏差。聊幾千字可能看不出來，聊幾萬字就會累積

給一個數(shù)學直覺：一個 1-bit 的 MSE 最優(yōu)量化器在高維空間中，會引入一個 2/π 的乘性偏差。這個偏差聽起來不大，但在 attention 計算中會被放大

QJL 的做法是：對第一步的殘差向量施加 Johnson-Lindenstrauss 變換，把每個數(shù)值壓成 1 bit 的符號位（+1 或 -1）。然后用一個特殊的估計器，在數(shù)學上保證內(nèi)積估計無偏

E[?y, Q?1(Q(x))?] = ?y, x?

壓縮后的內(nèi)積期望值，嚴格等于真實內(nèi)積。偏差消除了，額外開銷只有 1 bit

QJL 這篇論文已經(jīng)在 AAAI 2025 上發(fā)表

合起來

兩步加在一起：b-1 bit 給 PolarQuant 做主體壓縮，1 bit 給 QJL 做殘差糾錯?？偽粚?b bit

論文證明，TurboQuant 的 MSE 失真率距離信息論的理論下界只差大約 2.7 倍 的常數(shù)因子。在低 bit 寬度下這個差距更小

3.5 bit，零損失，免重訓

傳統(tǒng)方法用 3 bit 壓縮，1-2 bit 被歸一化開銷吃掉，實際有效壓縮可能只有 1-2 bit。TurboQuant 的每一個 bit 都是有效壓縮

Benchmark 數(shù)據(jù)

說了這么多原理，回到大家最關心的問題：壓完之后模型到底還好不好用

Google 在五個長上下文 benchmark 上做了測試：LongBench、Needle In A Haystack、ZeroSCROLLS、RULER、L-Eval。測試模型用的是開源的 Gemma、Mistral 和 Llama-3.1-8B-Instruct

KV cache 壓縮

論文里的精確表述：3.5 bit 達到「absolute quality neutrality」（絕對質(zhì)量中性），2.5 bit 只有「marginal quality degradation」

→內(nèi)存縮小至少 6 倍

→LongBench 的 QA、代碼生成、摘要任務上，匹配或超過 KIVI baseline

→Needle-in-a-Haystack（在海量文本里精確找到一條特定信息）：滿分

→PolarQuant 單獨用，這個任務也近乎無損

論文中 LongBench 各任務得分對比

速度

壓縮不只省內(nèi)存，還能加速。要讀取和計算的數(shù)據(jù)量變少了，速度自然就快了

在 NVIDIA H100 上，4 bit 模式的 attention logits 計算，比 32 bit 未量化版本最高快 8 倍。測量基線是高度優(yōu)化過的 JAX 實現(xiàn)

論文中 H100 不同 bit 寬度速度對比

向量搜索

TurboQuant 不只能壓 KV cache，在向量搜索場景也好用。向量搜索就是搜索引擎和 RAG 背后的技術：你輸入一個問題，系統(tǒng)要在幾十億條數(shù)據(jù)里找到最相關的那幾條

Google 在 GloVe 數(shù)據(jù)集（200 維）上跟 Product Quantization 和 RabitQ 做了對比。TurboQuant 的 recall 全面領先，對方用了大 codebook 和數(shù)據(jù)集特定調(diào)優(yōu)，TurboQuant 什么都沒調(diào)

索引構建時間幾乎為零（1536 維向量只需 0.0013 秒）

論文中 GloVe 數(shù)據(jù)集 recall 對比

四個工程屬性

對部署 LLM 的團隊來說，下面四個屬性可能比壓縮率本身更重要。它們決定了這個東西能不能真的用起來

Training-free 量化表預先算好，拿到模型直接用
Data-oblivious 數(shù)據(jù)進來直接壓，省掉了校準步驟
加速器友好 用 GPU 擅長的批量向量化運算
純軟件 H100、A100 直接跑，零硬件改造

四個屬性合起來：拿到一個新模型，零準備，直接壓，直接部署

外部反應

這個算法發(fā)出來之后，技術圈和資本市場同時給了很大的反應

Google Research 的官方推文獲得了超過 770 萬 次瀏覽

Twitter @eastdakota 的評價是「Google 的 DeepSeek 時刻」

Matthew Prince，Cloudflare CEO

社區(qū) 24 小時內(nèi)開始移植到 MLX 和 llama.cpp。前面提到的 Qwen3.5-35B 實測就是這么來的

美股內(nèi)存板塊當天下跌：SanDisk -5.7%，Micron -3%，Western Digital -4.7%，同期納斯達克 100 是漲的。市場在擔心軟件壓縮效率的提升會減少對 HBM 芯片的需求。評論區(qū)也有人搬出 Jevons Paradox 來反駁：效率越高，總消耗可能反而增加，歷史上這種事發(fā)生過很多次

論文和資源

TurboQuant 主論文（ICLR 2026）

arxiv.org/abs/2504.19874

PolarQuant（AISTATS 2026）

arxiv.org/abs/2502.02617

QJL（AAAI 2025）

arxiv.org/abs/2406.03482

Google Research 官方博客

research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression/