Google 發了個壓縮演算法，記憶體砍 6 倍，速度快 8 倍，精度零損失

Google Research 昨天發了篇部落格，介紹了一個叫 TurboQuant 的壓縮演算法，將在下個月的 ICLR 2026 上正式發表。

一句話概括：把大模型的 KV Cache 壓縮到 3 bit，記憶體佔用降 6 倍，推理速度快 8 倍，精度損失為零。

零。

不是「接近零」，不是「可忽略」，是在所有基準測試上跑出了和未壓縮版本一模一樣的分數。

這，就值得好好說說了。

先說 KV Cache

大模型在生成回答時，有個東西叫 KV Cache，也就是 Key-Value 快取。

你可以把它理解成模型的「草稿紙」，每生成一個 token，它都要回頭看看之前寫了什麼，而 KV Cache 就是儲存這些「之前寫了什麼」的地方。

問題在於……這張草稿紙會越來越大。

對話越長，草稿紙越厚。

上下文窗口從 8K 到 128K 再到百萬級，KV Cache 的記憶體佔用也跟著線性膨脹。到了一定程度，GPU 的視訊記憶體就不夠用了，要麼縮短上下文，要麼加更多顯示卡。

這就是為什麼之前對於 1M token 的上下文模型，比如說 Claude 的模型，它會在超過一定窗口之後，要收取更高價格。因為費卡啊！

所以 KV Cache 壓縮，一直是業界的剛需。

老辦法的尷尬

傳統的做法是向量量化，把 32 位的浮點數壓成更少的位數。聽起來很直接對吧？

但這裡有個尷尬的地方：量化本身需要儲存一些「校準常數」，這些常數得用全精度保存，每個數字額外佔 1 到 2 bit。

打個比方，你好不容易把行李箱裡的衣服用真空袋抽成了紙片，正準備拉上拉鏈，結果發現每個真空袋上還得貼一張 A4 大小的操作說明。十件衣服十張說明，箱子又鼓起來了。

壓縮帶來的好處，被壓縮本身的開銷吃掉了一部分。

TurboQuant 要解決的，就是這個問題。

極坐標的妙用

TurboQuant 其實是兩個演算法的組合：PolarQuant 和 QJL。

先說 PolarQuant。

傳統量化在笛卡爾坐標系下工作，也就是我們熟悉的 X、Y、Z 軸。PolarQuant 做了一件事：把向量從笛卡爾坐標系轉換到極坐標系。

這是什麼意思呢？

想像你在一張方格紙上標記一個點的位置。笛卡爾坐標系的做法是：向右走 3 格，向上走 4 格。極坐標的做法則是：朝 53 度方向，走 5 步。

描述同一個點，但極坐標的表示方式有個天然優勢：角度的分佈是可預測的、集中的。

這意味著，你不需要額外儲存那些佔空間的校準常數了。

方格紙換成了羅盤，清單就不需要了。

這一步，PolarQuant 負責主要的壓縮工作，把資料壓到很小的體積，同時保留了關鍵資訊。

1 bit 掃尾

但光靠 PolarQuant 還不夠……壓縮之後總會有殘餘誤差。

這時候 QJL 登場了，全稱 Quantized Johnson-Lindenstrauss。

QJL 的思路相當大膽：它用 Johnson-Lindenstrauss 變換來處理殘餘誤差向量，然後把每個值壓縮到……1 個 bit。

對，就是正或負，+1 或 -1，沒有中間地帶。

聽起來粗暴得離譜對吧？但妙的地方在於，QJL 在計算 attention 分數時，用的是未壓縮的高精度 query 向量和壓縮後的 key 向量配合工作。高精度的那一側「兜住了」低精度那一側的誤差。

額外記憶體開銷：零。

PolarQuant 做主力壓縮，QJL 做 1-bit 掃尾，兩者合在一起就是 TurboQuant。最終實現了 3-bit 的 KV Cache 壓縮，而且不需要重新訓練模型，不需要微調，不需要針對特定資料集做校準。

拿來就能用。

TurboQuant 兩步壓縮流程

跑分全滿

:::

來看效果。

Google 的團隊在五個長上下文基準測試上做了驗證：LongBench、Needle In A Haystack（大海撈針）、ZeroSCROLLS、RULER、L-Eval，用的模型是開放原始碼的 Gemma 和 Mistral。

結果是：所有基準測試上，壓縮後的模型和未壓縮版本得分完全一致。

TurboQuant 成績單

在 NVIDIA H100 GPU 上，4-bit 的 TurboQuant 在計算 attention logits 時比 32-bit 未量化的 key 快了 8 倍。

而在向量搜尋任務上，TurboQuant 也打敗了現有最好的方法（Product Quantization 和 RabbiQ），在 GloVe 資料集上的召回率更高，同時記憶體佔用更少。

換句話說，壓得更小，跑得更快，還找得更準。

不只是論文

:::

通常一篇論文發完，大家看看就過去了。但 TurboQuant 的情況，有些不一樣。

論文放出來沒幾天，社區就已經有人用 PyTorch、MLX（Apple Silicon）和 C/CUDA（給 llama.cpp 用的）分別做出了可運行的實現，而且核心指標都得到了驗證。

可以說，演算法本身夠簡潔，不依賴複雜的訓練流程，獨立開發者幾天就能復現。

團隊陣容方面，除了 Google 的 Amir Zandieh 和 Vahab Mirrokni（Google Fellow），還有來自 KAIST 和 NYU 的研究者參與，三篇相關論文分別發在 ICLR 2026、AAAI 2025 和 AISTATS 2026。

未來影響

:::

TurboQuant 解決的問題，表面上看是「省視訊記憶體、提速度」。但往遠了想，它動的其實是 AI 部署的門檻。

現在跑大模型，動輒需要幾塊 H100，一年下來光算力成本就是天文數字。如果 KV Cache 能壓縮 6 倍，同樣的視訊記憶體就能裝下更長的上下文，或者服務更多的並行請求。對雲端來說，這直接就是成本帳。

而對本地部署來說，意義可能更大。32GB 視訊記憶體的消費級顯示卡，原本只能勉強跑個 7B 模型的長上下文，壓縮 6 倍之後，想像空間就打開了。

更遠一點……手機、邊緣裝置、嵌入式系統，這些地方記憶體寸土寸金，TurboQuant 這類技術可能是 AI 真正進入這些場景的前提條件。

有人評論稱：

這可能是 2026 年最重要的創新之一。

說「最重要」可能有些誇張了。

但我想，至少可以說，最性感的 AI 突破，未必來自下一個兆參數的巨無霸模型，而可能來自這種聰明的數學技巧。

壓縮、量化、高效計算，

這也許才是，讓 AI 真正無處不在的關鍵。 (AGI Hunt)