Google TurboQuant 壓低 LLM 記憶體成本

Google 這次不是在拚更大模型。它盯上的是記憶體。新方法 TurboQuant，號稱可把 LLM inference 最多加速 8 倍，重點是壓低 vector quantization 的開銷。講白了，就是少搬資料，少等記憶體。

這篇方法會送到 ICLR 2026。它把 QJL 和 PolarQuant 組在一起。這組合很直白。不是只壓模型大小。是把量化後的雜事也一起砍掉。

如果你有碰過 LLM serving，你大概懂痛點。算力很貴，記憶體也很貴。很多時候，不是 GPU 不夠快，是資料搬運太慢。TurboQuant 就是在打這個洞。

TurboQuant 到底改了什麼

向量量化本來就很常見。問題是，壓縮之後還要查 codebook、讀索引、帶 metadata。這些步驟看起來不起眼，堆起來就很煩。模型一大，這些額外成本會直接吃掉壓縮紅利。

Google 的說法很明確。TurboQuant 不是只想把向量變小。它還想把量化流程裡的記憶體流量壓低。這很重要，因為很多最佳化只在論文圖表上漂亮，進到 production 就開始變形。

TurboQuant 的核心思路，是把兩種方法接起來。QJL 提供隨機投影式的壓縮路徑。PolarQuant 則從極座標的角度處理量化。兩者合併後，目標是更省空間，也更少記憶體負擔。

• TurboQuant 會在 ICLR 2026 發表
• Google 宣稱最高 8x inference speedup
• 焦點是 vector quantization 的 memory overhead
• 方法建立在 QJL 與 PolarQuant 上

這種設計的價值，在於它碰的是瓶頸本體。很多 serving 優化只是在算術層面做文章。TurboQuant 則是直接處理 memory traffic。對大型部署來說，這種方向通常比較有感。

QJL 和 PolarQuant 為什麼重要

Johnson-Lindenstrauss 相關概念其實不新。老早就有人在研究如何把高維資料投影到較低維，同時盡量保留結構。QJL 的重點，是把這個想法改成更適合量化的版本。

用白話講，QJL 想做的是：把向量壓縮，但不要壓到資訊全跑掉。這對 LLM 很要命。因為模型不是只看數字大小。它還在乎向量之間的關係。關係亂掉，輸出就可能飄。

PolarQuant 則是另一條路。它先改變向量表示方式，再做量化。這很像先整理行李，再塞進箱子。順序對了，空間利用率就比較好。

“The future of machine learning is not about bigger models, but about smarter models.” — Jeff Dean

這句話是 Jeff Dean 在 Google I/O 2019 說的。拿來看 TurboQuant，很貼切。因為這次不是在比誰模型參數最多。是誰比較會省記憶體、少浪費資料搬運成本。

我覺得這也反映 Google 的優先順序。訓練端很吸睛。可是真正燒錢的，常常是 inference。模型一上線，成本就開始算秒、算 token、算 GPU 小時。

數字怎麼看，跟競品比起來呢

先講最吸睛的數字。Google 說 TurboQuant 最多可快 8 倍。這不是保證值。這是上限式說法。實際效果會看模型大小、batch、硬體、cache 行為，還有是不是 memory-bound。

但 8 倍不是小數字。很多 serving 調校，能拿到 10% 到 30% 就很不錯了。若真能把記憶體開銷壓下來，改善幅度有機會比單純改 kernel 還大。因為你碰到的是系統瓶頸，不是表面症狀。

拿競品來看，大家的方向其實很像。有人做更小的模型。有人做更好的 kernel。有人做更激進的量化。TurboQuant 的差別，在於它把焦點放在量化本身的附加成本。

• OpenAI 主要靠模型與推理堆疊優化
• Google 這次把焦點放在壓縮流程的記憶體流量
• Hugging Face 讓量化工具更容易被開發者用起來
• TurboQuant 的 8x 說法，明顯高於常見的單位數百分比優化

這裡的重點是，很多量化方案在理論上省了空間，實作時卻多了雜訊。metadata、索引、查表，全部都會吃 bandwidth。TurboQuant 如果真能減少這些負擔，對大規模 serving 會很有吸引力。

這件事為什麼跟台灣開發者有關

台灣很多團隊現在都在做 LLM 應用。從客服、搜尋，到內部知識庫，都有人在碰。這些場景最怕一件事，就是成本算不攏。模型不是不能跑，是跑了太貴。

所以這類研究不能只當學術新聞看。它其實在提醒大家，推理成本不是只有 token 單價。還有 memory bandwidth、cache miss、資料格式轉換，這些都在偷偷吃錢。

如果你在做自架模型，TurboQuant 這種方法值得盯。不是因為它一定馬上能用。是因為它把問題定義得很準。真正卡住 LLM serving 的，常常不是 FLOPs，而是記憶體。

Google 近年的方向也很一致。它一直在推 研究 和產品之間的效率優化。從 TPU 到量化，再到各種 serving 技巧，核心都是同一件事：把成本壓低，讓模型更容易上線。

接下來該看什麼

接下來最重要的，不是看新聞稿，而是看程式碼和 benchmark。這種方法要進 production，得過 kernel、cache、GPU 排程這幾關。論文漂亮，不代表實機漂亮。

如果 Google 之後放出 reference implementation，或是更多測試條件，這篇研究的價值會更清楚。反過來說，如果細節很少，那它可能就只會停在 paper citation 層級。

我的判斷很直接。TurboQuant 這種方法，代表 LLM 優化正在往 memory-first 走。接下來半年，你大概會看到更多團隊開始算同一筆帳：不是只看模型多大，而是看每個 token 到底燒了多少記憶體。

你如果在做 serving，現在就可以問自己一題：你的瓶頸真的是算力，還是資料搬運？這題答對了，後面的優化方向才不會亂槍打鳥。