上一篇用 PagedAttention 解決了 KV Cache「怎麼放」的問題：切成 blocks、按需配置、用 block table 找到實體位置。

但每個 block 裡的 K、V 如果仍是 BF16，每個元素還是需要 16 bits。

下一個問題自然是：

能不能把 KV Cache 壓到 3–4 bits，同一張 GPU 放進更多 context 和 requests？

TurboQuant 就是在處理這件事。

先說清楚：今天是論文閱讀、容量手算與 vLLM source tracing，沒有執行 benchmark。以下手算是理想 bit budget；論文與 vLLM 的測量也不是我的實測結果。

為什麼不能直接四捨五入？

KV Cache 保存的是 attention 的 Keys 和 Values：

score  = Q · K
output = Softmax(score) · V

如果 K 的量化誤差改變內積，Softmax 後可能把注意力放到錯的 token；V 的誤差則會直接進入最後的加權和。

尤其少數很大的 outliers 會撐開量化範圍，讓大多數普通數值只能擠在少量 quantization levels 裡。bit 數越低，這個問題越明顯。

TurboQuant 的核心想法

TurboQuant 不是直接對原始向量逐元素量化，而是先做一次隨機旋轉：

原始 K / V vector
→ random rotation（可用快速 Hadamard transform）
→ 能量分散到各個 coordinates
→ scalar quantization
→ packed low-bit KV Cache

旋轉不會改變向量的 norm 與幾何關係，但會把集中在少數 coordinates 的大值攤開。分布變得比較均勻後，簡單的 scalar quantizer 也能得到較低 distortion。

論文針對兩種誤差提出不同做法：

• MSE：旋轉後，替每個 coordinate 選擇接近的最佳 centroid。
• Inner product：先做 MSE quantization，再用 1-bit QJL 表示 residual，修正內積估計的 bias。

論文報告，在其 KV Cache 實驗中，3.5 bits/channel 可維持品質，2.5 bits/channel 則只有小幅退化。這是論文設定下的結果，不代表所有模型與 workload 都一樣。

先手算能省多少

Day 11 算過，Llama-3.2-1B 在 BF16、GQA、batch 1、32K context 下，KV Cache 理論容量是 1 GiB。

K、V 原本各用 16 bits，因此理想容量只要乘上：

(K bits + V bits) / (16 + 16)

這些都只是 payload 的理想值。真實配置還要放 norm、scale、zero point，並考慮 packing、alignment、未量化 layers 與 allocator，因此不會精確等於表格。

vLLM 裡實際走哪條路？

目前 vLLM 的 TurboQuant path 可以從四個位置看懂：

config.py
→ 定義 K8V4、4bit、K3V4、3bit presets 與 packed size

turboquant_attn.py
→ 串起 attention backend、prefill 與 decode 路徑

triton_turboquant_store.py
→ 新 token 產生 K / V 後，量化、pack，再寫入 paged KV Cache

triton_turboquant_decode.py
→ 依 block table 讀取壓縮的 K / V，解碼並完成 decode attention

值得注意的是，vLLM 並沒有逐字照搬論文演算法。目前的 source 註解明確寫出 QJL 被省略；實作採用 Hadamard rotation、MSE-quantized keys、uniform-quantized values 與部分 presets 的 norm correction。

這是一個很典型的 paper-to-system 落差：論文先回答失真率與理論界線，serving engine 還必須處理 kernel、metadata、硬體利用率和端到端 latency。

壓得更小，不一定跑得更快

TurboQuant 可以減少 KV Cache storage 和 HBM 讀取量，但 attention 計算前仍有 rotation、unpack 或 dequantization 成本。

vLLM 在 2026 年 5 月發布的研究中，對 30B 到 200B+ 模型測量後給出的結論是：

• FP8 仍是較穩妥的預設，容量約為 BF16 的兩倍，效能與品質較穩定。
• 4-bit TurboQuant 適合 memory pressure 很高、願意交換部分 throughput 與品質的情境。
• 更激進的 3-bit variants 在 reasoning 與 very-long-context workloads 出現明顯 accuracy drop，也沒有自然轉化為較高 throughput。

所以「壓縮 4×」只描述 storage，不等於 latency 快 4×，也不等於 serving throughput 高 4×。

Reference

• TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate
• vLLM Blog — A First Comprehensive Study of TurboQuant: Accuracy and Performance
• vLLM — TurboQuant configuration
• vLLM — TurboQuant attention backend
• vLLM — TurboQuant store kernel
• vLLM — TurboQuant decode kernel