Google 新算法，Mac Mini 也能跑 Qwen3.5

RESEARCH

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

整個(gè)過(guò)程免訓(xùn)練、免微調(diào)、免校準(zhǔn)，純軟件方案，拿來(lái)就能用

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

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

論文下個(gè)月在 ICLR 2026 主會(huì)上發(fā)表。作者來(lái)自 Google Research、Google DeepMind 和紐約大學(xué)

6 倍壓縮，什么概念

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

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

直接的效果：同一張顯卡能跑更長(zhǎng)的對(duì)話，或者同時(shí)服務(wù)更多用戶

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

Mac Mini 上跑 Qwen3.5-35B 的 6 萬(wàn)字長(zhǎng)對(duì)話，needle-in-a-haystack 測(cè)試全部命中

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

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

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

KV cache 為什么是瓶頸

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

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

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

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

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

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

TurboQuant 要解決的就是這個(gè)問(wèn)題

TurboQuant 怎么做的

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

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

第一步：PolarQuant

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

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

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

歸一化開銷，消掉了

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

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

第二步：QJL

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

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

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

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

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

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

合起來(lái)

兩步加在一起：b-1 bit 給 PolarQuant 做主體壓縮，1 bit 給 QJL 做殘差糾錯(cuò)。總位寬 b bit

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

3.5 bit，零損失，免重訓(xùn)

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

Benchmark 數(shù)據(jù)

說(shuō)了這么多原理，回到大家最關(guān)心的問(wèn)題：壓完之后模型到底還好不好用

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

KV cache 壓縮

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

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

→LongBench 的 QA、代碼生成、摘要任務(wù)上，匹配或超過(guò) KIVI baseline

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

→PolarQuant 單獨(dú)用，這個(gè)任務(wù)也近乎無(wú)損

論文中 LongBench 各任務(wù)得分對(duì)比

速度

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

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

論文中 H100 不同 bit 寬度速度對(duì)比

向量搜索

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

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

索引構(gòu)建時(shí)間幾乎為零（1536 維向量只需 0.0013 秒）

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

四個(gè)工程屬性

對(duì)部署 LLM 的團(tuán)隊(duì)來(lái)說(shuō)，下面四個(gè)屬性可能比壓縮率本身更重要。它們決定了這個(gè)東西能不能真的用起來(lái)

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

四個(gè)屬性合起來(lái)：拿到一個(gè)新模型，零準(zhǔn)備，直接壓，直接部署

外部反應(yīng)

這個(gè)算法發(fā)出來(lái)之后，技術(shù)圈和資本市場(chǎng)同時(shí)給了很大的反應(yīng)

Google Research 的官方推文獲得了超過(guò) 770 萬(wàn) 次瀏覽

Twitter @eastdakota 的評(píng)價(jià)是「Google 的 DeepSeek 時(shí)刻」

Matthew Prince，Cloudflare CEO

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

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

論文和資源

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/