TurboQuant 把 vLLM KV 快取壓成 3 位元

這篇在講 TurboQuant 怎麼把 vLLM 的 KV cache 壓到 3-bit，還能直接拿去做部署判斷。

我用 vLLM 一陣子後，最常碰到的不是模型不夠強，而是記憶體老是在奇怪的地方爆掉。模型載得進去、prompt 也塞得下去，結果對話一長，KV cache 就開始吃 RAM，吃到你懷疑人生。最煩的是，你明明沒換模型，服務也看起來正常，偏偏一拉長上下文就卡住。這種痛我真的很熟：不是模型太大，是你以為自己已經控住了，結果 cache 才是那個偷吃空間的傢伙。

我這次是從 TurboQuant 的 GitHub repo 進去看的，順手也對照了 vLLM 的 upstream PR #38479，還有作者提到的 vibhavagarwal5。這個東西不是空談，repo 本身就把 KV cache 壓縮、權重壓縮、runtime kernel 跟 fallback 路線拆開講，至少不是那種一句「我們做了量化」就想混過去的玩法。

我先講結論：它不是在救模型，是在救記憶體

TurboQuant+ KV cache compression for vLLM. 3.8x smaller KV cache, same conversation quality.

白話翻譯就是：它想把注意力狀態的記憶體佔用砍下來，而且不要讓模型講話突然變笨。這件事我很買單，因為很多壓縮方案都很會秀數字，結果一上線就開始胡言亂語。對我來說，壓縮有沒有用，不是看它縮了多少，而是看它能不能讓我多撐幾輪對話、多開幾個 session、或是把同一張 GPU 用得更滿。

我以前在小卡上跑互動式服務時就遇過這種狀況。模型本體看起來沒問題，吞吐也還行，可是一旦上下文拉長，cache 就像水壩破洞一樣慢慢漏。你會先覺得是 batch 設定怪怪的，後來發現根本不是，是 decode 時的記憶體壓力一直在累積。這種問題最陰險，因為 benchmark 看起來很漂亮，真實使用卻很煩。

實操寫法很簡單：先把 KV cache 壓縮當成一級選項，不要只盯著模型權重。你的工作負載如果是聊天、多輪問答、長上下文檢索，先測 cache 壓縮，常常比你再縮一點 model size 更有感。

不要把權重壓縮跟 KV cache 壓縮混在一起

TurboQuant 的 repo 很誠實，因為它不只談 KV cache，還把權重壓縮一起包進來。這很容易讓人看花眼，所以我先拆開講。權重壓縮是在縮模型參數，影響的是載入時的記憶體；KV cache 壓縮是在縮生成時的注意力狀態，影響的是推理過程中的記憶體。兩個都重要，但瓶頸位置完全不同。

repo 裡提到它用 3-bit TQ3 壓縮，還說可以對 BF16 checkpoint 快速壓縮，而且不需要校準。它也提到 native packed checkpoints、Apple Silicon、MoE、還有一些舊版 MLA KV cache 的 monkey patch。這些東西放在一起很容易讓人以為是一包萬能工具，但我不會這樣看。我會先問：我現在卡的是載入、解碼，還是特定架構的相容性？

我自己比較喜歡這種拆法，因為它逼你把問題講清楚。你如果連瓶頸在哪都沒搞懂，就很容易把「我量化了」當成答案。實際上可能只是改到一半，真正吃資源的那一塊根本沒碰到。

• 權重壓縮：縮模型本體，對載入時記憶體最有感。
• KV cache 壓縮：縮生成時狀態，對長對話最有感。
• runtime kernel：決定你壓縮完之後是不是還跑得動。

實操寫法：先畫出你的瓶頸圖。載入爆掉，就先看權重壓縮；生成爆掉，就先看 KV cache 壓縮；兩邊都爆，再談混合方案。順序錯了，後面全是在繞路。

我最在意的是 fallback，不是漂亮的 demo

repo 一直提 fused CUDA kernels，但也很老實地保留 PyTorch fallback。這句話聽起來像工程細節，實際上很重要。因為我踩過太多次「某張卡上很快、換一張卡就死給你看」的坑。沒有 fallback 的優化，很多時候只是把風險包裝得比較好看而已。

白話一點說，TurboQuant 不是把所有希望都押在一條自訂 kernel 上。快路徑跑得動就跑，跑不動至少還能退回 PyTorch，不會直接整個服務掛掉。repo 也有提到 CUDA GEMV 路徑對 sm_80+ 的限制，這種細節我反而喜歡，因為它直接告訴你：不是每張 GPU 都吃得到。

我以前很討厭這種「有加速，但你要先祈禱硬體對得上」的東西，後來才知道，真正成熟的方案一定要有退路。沒有退路的優化，最後只會變成 ops 團隊的惡夢。

實操寫法：評估任何壓縮套件時，我都會先問兩件事。第一，快路徑是什麼。第二，快路徑失效時會怎樣。答案如果是「自己改 code」或「直接 crash」，我就先放一邊。答案如果是「自動 fallback」，我才會繼續看。

為什麼這份 repo 一直在講 kernel

TurboQuant 的 README 很直接：Triton 的 GEMV 路徑會把 batch size 1 的情境搞得很浪費，因為它偏向 tensor-core tile 的排法，結果很多 ALU 都空著。它因此改成 runtime dispatch 的 custom op。這種描述很工程，但我反而信，因為只有真的量過，才會知道哪裡在浪費。

也就是說，壓縮本身不是終點。你把資料壓小了，如果解壓或矩陣運算那段很爛，最後只是把瓶頸搬家。TurboQuant 比較像是把 memory path 跟 compute path 一起照顧，至少不是只做一半就拍拍屁股走人。

我看過不少團隊很愛貼壓縮比，卻不提 runtime 開銷。結果一上線，省下來的 VRAM 又被額外延遲吃掉。這就是我一直盯 kernel 的原因：如果速度掉太多，壓縮就會變成紙上談兵。

• 壓縮比告訴我省多少記憶體。
• kernel 行為告訴我能不能真的上線。
• fallback 告訴我出事時我會不會半夜被叫醒。

實操寫法：不要只看平均吞吐。請直接用你真正的 batch size 測，尤其是 batch size 1。聊天機器人最常見的產品型態就是單筆請求，不是壓測表上的漂亮數字。

上游整合這件事，比很多人想得重要

我會特別注意 vLLM 的 upstream PR #38479，因為 repo 的說法是 KV cache 壓縮已經往上游走，代表這不只是某個外掛專案的私房菜。對我來說，這差很多。只要功能進了上游，維護成本、相容性、部署習慣都會變得比較正常。

白話翻譯就是：你不用一直背著 fork 跑。很多 serving patch 一開始都很帥，後來變成技術負債，原因很簡單，大家一開始都以為自己只是在試新東西，最後卻把整個線上服務綁死在那個分支上。上游化至少表示，這件事已經不是單點實驗，而是開始進入正常 runtime 的範圍。

我也會順手看它支援哪些模型家族。repo 提到像 Qwen、Llama、Mistral、Gemma 這些常見系統，這就比較像真的能拿來評估的東西，不是只在某一顆 checkpoint 上表演。

實操寫法：如果你本來就在用 vLLM，先查你的目標模型跟 serving 模式是不是已經被上游涵蓋。能用上游就先用上游，fork 留給實驗。fork 一旦變成基礎設施，後面就是固定繳稅。

我會先拿它用在哪裡，不會亂上

我第一個會試的場景，是長上下文聊天、多租戶推理，還有任何記憶體頭寸已經卡住擴容的服務。這些場景最現實，因為你不是在追論文分數，而是在想怎麼讓同一批 GPU 撐住更多真實請求。尤其是小一點的卡，記憶體常常比算力更先見底。

但我不會把它當成萬用解。假如你的瓶頸其實是 CPU 前處理、網路延遲、或 scheduler 設得太爛，KV cache 壓縮救不了你。模型很小、上下文很短的情況也一樣，硬塞壓縮只會增加複雜度，收益卻很有限。

也就是說，這東西最適合那種很煩的中間地帶：模型有用、上下文是真的長、GPU 又剛好差那一點點。這種情境下，壓縮才會真的有價值。不是實驗室裡的漂亮 demo，而是產品跟財務在拉扯時，你還能多撐一點的那種工具。

實操寫法：先拿一條真實工作流做 before/after。量 VRAM、量延遲、也要看回答品質。只要記憶體真的降、品質也還能接受，就值得留。反過來就收手，別硬撐。

可抄的模板

# TurboQuant 風格的 vLLM 評估清單

## 1) 先決定你要縮什麼
- [ ] 模型權重記憶體
- [ ] KV cache 記憶體
- [ ] 兩者都要

## 2) 先選 serving 路線
- [ ] 直接走上游 vLLM
- [ ] 走 TurboQuant 外掛路線
- [ ] 只有特定模型才用 monkey patch

## 3) 先確認硬體支援
- [ ] GPU 架構支援快路徑
- [ ] 快路徑失效時 PyTorch fallback 可接受
- [ ] batch size 1 有實測

## 4) 先選壓縮模式
- [ ] 3-bit 權重壓縮
- [ ] KV cache 壓縮
- [ ] 混合模式，但只在你真的量過之後用

## 5) 用一條真實工作流驗證
- [ ] prompt 長度符合正式環境
- [ ] 對話品質有人工檢查
- [ ] 壓縮前後 VRAM 有記錄
- [ ] 壓縮前後 decode 延遲有記錄

## 6) 可直接改的 serve 範本
vllm serve <model-name> \
  --kv-cache-dtype <compression-mode> \
  --dtype bfloat16 \
  --trust-remote-code \
  --max-model-len <你的上下文長度>

## 7) 上線順序
- 先挑一個模型
- 先測一種 GPU
- 先保留 fallback
- 再擴到整個 fleet

## 8) 決策規則
如果記憶體真的降很多，而且品質還在可接受範圍，就保留。
如果記憶體有降但品質壞掉，就退回去。
如果快路徑不穩，就先留 fallback，之後再修。

這段模板是我把 TurboQuant 的思路整理成比較好落地的版本，不是 repo 原文。你可以直接貼進自己的評估文件、PoC checklist，或 deployment runbook，先把問題拆清楚，再決定要不要真的上。

來源致謝：原始 repo 是 https://github.com/varjoranta/turboquant-vllm，上游脈絡可對照 vllm-project/vllm#38479。我這篇是把它的做法拆開、重寫成台灣開發者比較好用的版本，模板與判斷框架是我自己的整理。