在長上下文 LLM 的服務裡,KV cache 一直是房間裡的記憶體大象。每個 token 都會產生一對 keys 和 values 張量,在整段序列期間常駐顯存;長上下文疊加大模型時,cache 經常吃掉總 VRAM 的 20% 到 30%。現有的緩解方案(grouped-query attention、PagedAttention、INT4/INT8 量化)都有幫助但走到了瓶頸。本週 Google 在 arxiv 2504.19874 發布的 TurboQuant 聲稱相對 FP16 基線可做到約 4.5 到 5 倍壓縮,精度損失近乎為零;如果在生產中也扛得住,這就是迄今最激進的可用 KV cache 壓縮方案。

關鍵在兩段流水線。第一階段對輸入向量做隨機旋轉,把座標分布集中到 Beta 分布上,從而允許每個座標獨立應用最優純量量化器。第二階段先做 MSE 量化,再對殘差套一層 1-bit Quantized Johnson-Lindenstrauss 變換。每個 token 的儲存就被壓成量化索引、符號位元和一個 L2 範數純量。每通道 3.5 bit 時,論文報告「絕對品質中性」,也就是在他們的評測裡精度損失在統計意義上是零;每通道 2.5 bit 時則是「邊際品質下降」。旋轉這一步是架構上的關鍵:你花一點計算把座標分布變成「對量化友好」的形狀,然後就用逐座標純量量化替代傳統的逐組或逐張量方案來做壓縮。

對任何在長上下文下跑 LLM serving 的人,算帳都很直接。如果你的 stack 還在 FP16 快取 KV、並且被 VRAM 卡住(單節點、32k+ 上下文的常見情形),4.5 到 5 倍的壓縮大致等價於在同一記憶體預算下處理 5 倍並發請求,或者每個請求吃下 5 倍的上下文長度。要留心的是,abstract 沒列具體測了哪些模型,所以上生產之前,先確認他們評測覆蓋了你的模型系列和序列長度。論文同時把最近鄰檢索作為第二個目標應用,說明「旋轉 + 量化」這個套路能跨出 attention cache。

生產 serving 團隊的實用路徑是盯緊參考實作,並對著你現在在跑的東西跑基準。TurboQuant 插進你推理堆疊的位置和 KIVI、KVQuant、Atom 差不多,整合成本也相近。如果你已經量化過 KV cache,把每通道 3.5 bit、零品質損失當作對照你當前配置的地板價;在 2026 年這已經是有競爭力的底線。如果還沒量化,這篇論文就是現在最好的啟動理由。更大的趨勢是:KV cache 壓縮已經不再是「可選優化」;在長上下文負載上,它是最吃緊的約束,而前沿實驗室的研究正在快速收斂到「低於 4 bit 但保精度」的方案。