UltraQuant：4-bit KV 快取加速長代理

UltraQuant 證明 4-bit KV 快取能讓長篇多輪代理在更少記憶體下維持更多上下文，並在後段輪次明顯加速服務。

• 研究機構：Advanced Micro Devices + UCLA + Purdue University
• 核心數據：後段輪次 P50 TTFT 提升 3.47×
• 突破點：FP4 KV 與 UE8M0 對應

長上下文代理的瓶頸，常常不是模型算不動，而是 KV cache 塞爆 HBM。這篇 UltraQuant: 4-bit KV caching for long agents 想證明一件事：把 KV cache 壓到 4 bit，不一定只是在省記憶體，也可能直接改變多輪服務的延遲表現。

它的重點很明確。不是只問「能不能量化」，而是問「在多輪、會重複使用前文、還要同時服務多個 session 的情境下，4-bit KV 能不能真的跑得順」。這篇論文把品質、cache 常駐率和 kernel 效率當成同一個系統來看。

這篇論文在解什麼痛點

現在的 LLM agent 不只是聊天。它會瀏覽網頁、看程式碼、呼叫工具，還要把一段很長的工作記憶帶著跑很多輪。這時候，KV cache 會快速膨脹，變成高頻寬記憶體的主要消耗者。

問題在於，cache 一大，系統就容易把有用的 prefix 擠出去。prefix 被趕走後，下一輪又得重新 prefill。對 serving 來說，這不只是浪費算力，還會拖慢 TTFT 和 TPOT。

因此，這篇論文處理的不是單純壓縮，而是「壓縮之後還能不能留住上下文」。它把目標放在長上下文、多輪、並發的 agent 工作負載上，因為這才是 cache 壓力真正會爆出來的地方。

論文也把 UltraQuant 放在兩個對照點之間看：一邊是 TurboQuant 類型的 4-bit 量化思路，另一邊是 vLLM 的 FP8 KV caching。FP8 已經能做到約 2× 壓縮，而且品質接近無損，還有原生硬體支援。這代表 4-bit 方案不能只靠「更小」來說服人，還得證明自己在服務面有實際價值。

方法怎麼做，白話講

這篇其實走了兩條路。第一條叫 Ultra-TurboQuant，也就是 Ultra-TQ。它保留 TurboQuant 的表示方式，但把實作做得更順。第二條才是 UltraQuant 本體，直接走向硬體原生的 FP4 近似路徑。

Ultra-TQ 的核心概念，和 TurboQuant 一樣，是先把 KV 向量做旋轉，讓離群值分散到各個 channel，這樣分佈比較好量化。論文用的是 Walsh–Hadamard rotation，並且移除了 QJL，同時把 key 和 value 做成非對稱處理，因為兩者在量化下的行為本來就不一樣。

論文特別強調一個很實際的修正：calibrated centroids。它不是只靠理論上的 Lloyd–Max centroid，而是用實際抓到的 activation 重新擬合 16-entry table。這個步驟成本很低，只需要對每個旋轉後 layer 抽大約 20 個 vector 做一次 forward pass；而且在實作上，只套用到 per-element quantization MSE 較高的 10% layer。

UltraQuant 再往前一步，直接把 codebook 路徑換成 FP4 micro-tensor 的做法。摘要提到它使用 FP8 queries、FP4 KV tensors、UE8M0 group scales，以及 CDNA4 上的 native scaled-MFMA。白話就是：它想讓 dequantization 不要變成額外的軟體查表，而是盡量吸進 matrix core 的硬體路徑裡。

這點很重要。因為 codebook quantization 雖然可以很準，但 serving 時常常會卡在 lookup 和不規則存取。UltraQuant 的判斷是，對服務來說，硬體原生格式可能比更精準、但更難跑快的表示法更有用。

它實際證明了什麼

這篇的評估不是拿單輪 benchmark 來講故事，而是直接對準 agentic workload。論文使用 vLLM 的原生多輪 benchmark，資料來自 ShareGPT conversation，並以 32 個 concurrent chat sessions 來跑，報告指標是 P50 TTFT 和 P50 TPOT。這種設計就是要模擬長時間服務下的 cache 壓力。

結果上，UltraQuant 在長上下文、多輪代理工作負載裡，晚期輪次的 P50 TTFT 提升了 3.47×。如果看全部輪次，TTFT 平均提升 2.3×，輸出吞吐量也比 FP8 KV baseline 高出 1.63×。

但這裡有一個很值得注意的細節：UltraQuant 並不是每個階段都贏。論文提到，在 warm rounds，P50 TTFT 是 FP8 的 0.86×，也就是 FP8 反而更快。真正拉開差距的是後段輪次，當每個 client 的 prefix 越來越長，FP8 的 resident cache 開始不夠用，而 UltraQuant 還能把更多 prefix 留在 device 上。

所以這個結果不是單純的「壓縮越多越快」。論文把提升歸因於 cache residency，而不是重新 prefill。換句話說，UltraQuant 的優勢來自它比較能把上下文留在 GPU 上，而不是每 token 都更快。

論文也給了 calibrated centroids 一個品質面上的數字。和 apples-to-apples 的 fakequant control 相比，重新擬合 codebook 可以把 per-element K quantization MSE 降低 10.3%，從 1.32×10^-4 降到 1.18×10^-4。摘要沒有提供完整 task accuracy 表，所以這個 MSE 數字是目前最清楚的品質證據。

對開發者代表什麼

如果你在做 context-heavy 的 agent，這篇論文在提醒一件事：KV cache 不是後端細節，它本身就是產品體驗的一部分。4-bit 方案只有在量化、kernel 執行和多輪服務都站得住腳時，才真的有價值。

最實用的工程啟發是，壓縮格式和部署格式不是同一件事。TurboQuant 類的 codebook 可能在演算法上很漂亮，但如果它帶來昂貴的 lookup 或 dequantization，服務系統最後還是會把省下來的東西吐回去。UltraQuant 的策略是讓表示法直接對齊硬體路徑，而不是把兩件事分開看。

另一個重點是，最好的指標要看工作負載。這篇沒有想做「一個 benchmark 打天下」的宣告，它盯的是長上下文、並發、多輪的 agent session。這正是 cache 常駐率和 latency 會互相拉扯的場景。如果你的工作負載多半是短 prompt，結果可能完全不同。

限制也很明確

根據目前提供的摘要內容，這篇沒有公開完整的 benchmark 細節。除了 agentic serving 的結果和 quantization MSE 例子之外，沒有看到更廣泛的任務表現數字，所以不適合直接把這些提升外推到所有模型或所有工作負載。

另外，這套方法也明顯綁在 AMD Instinct GPU 和 CDNA4 的原生支援上。UltraQuant 的 FP4 路徑依賴 scaled-MFMA 這類硬體能力，所以它的實作經驗不一定能平移到其他 accelerator。

結果本身也透露出一個 tradeoff：warm rounds 沒有 late rounds 那麼亮眼。這表示它的價值主要來自減少 eviction、把更多 context 留在 device，而不是一種全面性的 per-token 加速。

對開發者來說，真正要問的是：你的 serving stack 現在是不是已經卡在 resident KV capacity。如果是，UltraQuant 提供了一條路，讓 4-bit caching 不只是省記憶體，也可能變成實際的延遲優化。如果不是，這篇看到的 headline 數字，體感可能不會那麼大。

結論

UltraQuant 是一篇很明顯的 serving-first 研究。它不是只談量化精度，而是把量化、cache 版型和 AMD GPU kernel 支援一起考慮，目標是讓壓縮後的 KV state 真的能在多輪代理服務裡派上用場。

這篇論文的核心訊息很直接：對長上下文 agent 來說，4-bit KV cache 可以同時改善記憶體常駐和端到端服務速度，但前提是 representation 和 hardware path 必須一起設計。

• 4-bit KV caching 的價值，重點在能不能留住上下文。
• UltraQuant 的優勢主要出現在後段、cache 壓力大的輪次。
• 這篇的貢獻是把量化格式和硬體執行路徑對齊。