[Benchmark] TurboQuant 實測：KV Cache 3-bit 壓縮，真的零損失？

白話版：壓縮 AI 的記憶體卻不損失品質

AI 模型跟你對話時，需要記住整段對話歷史。這塊記憶體叫「KV cache」（鍵值快取），會隨著每條訊息成長。光是 8,000 個 token 的對話就要用掉 289 MB 的記憶體。拉長到長文件或複雜任務，瓶頸就不是 AI 的大腦，而是它的筆記本。

TurboQuant 是 Google Research 在 ICLR 2026 發表的技術，宣稱可以把這塊記憶體壓縮 6 倍——每個值只用 3 bit 而不是通常的 16 bit，而且不損失回答品質。可以想成照片的 JPEG 壓縮：檔案小很多，但肉眼看不出差異。

這篇在真實硬體——NVIDIA DGX Spark 桌上型 AI 電腦——上測試了這些宣稱。對標準 AI 模型來說，壓縮效果確實如論文所述。但對新一代的 hybrid 模型如 Qwen3.5-35B（本身就已經用了省記憶體的架構），節省幅度比標題數字暗示的小很多。數學是對的；效益取決於你跑的是什麼模型。

對量化的基礎還不熟？ 如果「3 bit 對 16 bit」或「Q4_K_M」這些詞對你來說還很陌生，建議先讀 LLM 101 Part 4：什麼是量化？——那篇用 MP3 比喻講清楚權重量化。這篇就是同系列的 KV cache 續集：一樣的技術家族，壓縮的是不同的東西。

---

LLM 推理的記憶體瓶頸不在模型權重，在 KV cache。一個 8K context 的 Qwen2.5-3B，KV cache 就要 289MB，而且隨 context 線性增長。這個問題在長 context 推理和大模型上會放大到讓人難受的程度。

3/24 Google Research 發了一篇 TurboQuant（ICLR 2026），宣稱能把 KV cache 壓到 3-bit，記憶體少 6x，精度零損失。社群五天內就冒出六個獨立實作。這篇是在 GX10（GB10/SM121）上的親測記錄。

---

TurboQuant 是什麼：30 秒懶人包

傳統量化是把浮點數對應到固定 bit 寬度。TurboQuant 用兩個步驟：

步驟一：PolarQuant 把每個 KV 向量做隨機旋轉，轉成極座標後再量化。旋轉後的向量分布更均勻，每個維度都可以用 Lloyd-Max 演算法找到最佳化的量化點。重點：不需要 calibration data，不需要 fine-tuning。

步驟二：QJL（Quantized Johnson-Lindenstrauss） 第一步會有殘差誤差。QJL 用 Johnson-Lindenstrauss 變換把殘差投影到 1-bit（只保留正負號）。數學上能保證 attention score 計算是 unbiased 的——這是 MSE-only 量化做不到的。

論文數字：品質無損約 3.5 bits/channel、KV 壓縮超過 5x、配合 optimized kernel 時 attention logit 計算有加速、LongBench/RULER/Needle-in-Haystack 零精度損失。（網路上常引用的「H100 8x」這個具體數字我在 arxiv 原文找不到，二手來源的 performance 數字看看就好。）

---

環境

• 機器：GX10，NVIDIA GB10（SM121），128GB unified memory，273 GB/s bandwidth
• vLLM venv：torch 2.10+cu130，transformers 5.3.0
• 實作：tonbistudio/turboquant-pytorch（PyTorch from-scratch 實作，非官方）
• 驗證模型：Qwen2.5-3B-Instruct（本機，fp16）

安裝：

source ~/.python-vllm-custom/bin/activate
pip install accelerate scipy -q

# 注意：目錄名需要是合法 Python module name
git clone https://github.com/tonbistudio/turboquant-pytorch ~/experiments/turboquant-pytorch
mv ~/experiments/turboquant-pytorch ~/experiments/turboquant

cd ~/experiments && python -m turboquant.test_turboquant

---

測試一：Synthetic Benchmark

不需要下載模型，直接驗證演算法數學正確性。

cd ~/experiments && python -m turboquant.test_turboquant

Lloyd-Max Codebook

不同維度（d=64/128/256）和 bit 寬度的量化失真：

d=128, bits=3: distortion/coord=0.000270
d=256, bits=3: distortion/coord=0.000135

維度越高，每個維度的失真越小——高維向量量化的數學有這個好性質。

MSE-Only vs QJL：bias 差異確認

bits=2: MSE-only bias=+0.001052  (有 bias)
bits=3: MSE-only bias=+0.000191  (有 bias)

QJL correction 後：

bits=3: bias=-0.000317  (≈ 0)
bits=4: bias=+0.000559  (≈ 0)

這是論文的核心主張之一：MSE-only 量化對 attention score 有系統性偏差，QJL 校正消除它。在 GB10 上親自驗證，結果如論文所述。

Needle-in-Haystack（Synthetic）

bits	seq=512	seq=2048	seq=8192
2-bit	EXACT	EXACT	EXACT
3-bit	EXACT	EXACT	EXACT
4-bit	EXACT	EXACT	EXACT

2/3/4-bit 全部精準找到。

GB10 速度

GPU: NVIDIA GB10
Config: d=128, bits=3, seq_len=8192, n_queries=64
Quantize 8192 keys:          31.04 ms
Inner product (64q × 8192k): 11.16 ms
Full-precision matmul:        0.02 ms
Memory: 2048 KB (fp16) → 384 KB (TQ-3bit) = 5.3x

這裡有個重要的數字：full-precision matmul 只要 0.02ms，但 TurboQuant inner product 要 11ms。

原因：這個 PyTorch 實作沒有寫 fused CUDA kernel。論文有提 optimized kernel 下的 attention 加速（網路上常引用的「H100 8x」具體數字我在 arxiv 原文找不到，當二手來源看）。在 GB10 這個非主流硬體（SM121）上，用現成的 PyTorch ops，目前沒有速度優勢。記憶體節省是真的，速度優勢要等上游 kernel 支援。

---

測試二：Real Model Validation（Qwen2.5-3B-Instruct）

用真實模型的 KV cache 向量驗證，3 種 context 長度（2K/4K/8K），needle-in-haystack 場景。

# validate.py 中把 MODEL_NAME 改成本機路徑，移除 bitsandbytes dependency
python -m turboquant.validate

壓縮率與精度

bits	壓縮比	Cosine sim (2K)	Cosine sim (8K)	Top-1 match (8K)
4-bit	3.8x	0.9987	0.9982	84.7%
3-bit	5.0x	0.9959	0.9943	80.6%
2-bit	7.3x	0.9891	0.9846	69.4%

原始 KV cache 大小：289MB（8K context, fp16）。3-bit 壓後：57.6MB。

幾個觀察：

3-bit 是甜蜜點。 Cosine similarity 0.9943，Top-1 match 80.6%。在長 context 任務上，不是每個 attention head 都需要精準的 top-1——整體分布夠好就行。

品質隨 context 微幅下降。 3-bit cosine sim 從 2K 的 0.9959 降到 8K 的 0.9943。幅度小，但存在。更長的 context 壓縮後誤差會累積。

2-bit 不建議生產使用。 69.4% Top-1 match 在 attention-heavy 任務（需要精確找到特定 token）可能出問題。

---

Qwen3.5-35B 的特殊情況

本來想直接在 production 模型上測，結果發現了一個架構特性值得記錄。

Hybrid Attention：只有 25% 的層有 KV cache

~/models/qwen35-35b-hf/ 的 config：

layer_types: [
    "linear_attention", "linear_attention", "linear_attention", "full_attention",  # 0-3
    "linear_attention", "linear_attention", "linear_attention", "full_attention",  # 4-7
    ...  # 每 4 層才有一個 full_attention
]
# full_attention 層：[3, 7, 11, 15, 19, 23, 27, 31, 35, 39]
num_key_value_heads: 2
head_dim: 256

40 層裡，只有 10 層是傳統的 full attention，其他 30 層是 GatedDeltaNet（線性注意力，狀態固定大小，不用 KV cache）。

TurboQuant 只能壓縮 full_attention 的 KV cache，也就是 10/40 = 25% 的層。而且 num_key_value_heads=2，每層的 KV cache 本來就已經很小。

記憶體估算

fp16，200K context：

2 KV heads × 256 dim × 2 bytes × 10 layers × 200K tokens ≈ 2GB
TurboQuant 3-bit → ~400MB

現在 GX10 vLLM 用 --kv-cache-dtype fp8（8-bit），KV cache 已是 1GB。TurboQuant 3-bit 再壓：~400MB，節省 600MB。

換句話說：對 Qwen3.5-35B-A3B，TurboQuant 的記憶體節省效益比論文測的 dense 模型小很多。這不是 TurboQuant 的問題，是 hybrid attention 架構的特性。

對比，如果跑一個純 dense 模型（像 Llama-3.1-70B），全部 80 層都有 KV cache，效益就接近論文的 6x。

---

現在能用嗎？

不能在生產環境直接用。 vLLM PR #38280 在 2026 年 3 月下旬 review 中，但 2026-04-06 未合併被 close 掉。llama.cpp 有多個 fork 但尚未合併 main。追 upstream vLLM 有沒有後續 PR。

可以學習和實驗。 pip install turboquant 或 tonbistudio/turboquant-pytorch 可以跑 Python 驗證，理解演算法。

等時機：

vLLM PR #38280 合併
    ↓
--kv-cache-dtype turboquant3
    ↓
測 Qwen3.5-35B 的實際效果（預計 context 1.8M → 4.8M tokens）

---

什麼值得學

最花時間的：搞清楚 qwen35-35b-hf/ 是 multimodal model（Qwen3_5MoeForConditionalGeneration），不是純文字模型。transformers 無法在 89GB 記憶體裡載入 fp8 MoE + vision encoder，掉進去花了一個小時。

可遷移的診斷：對任何 hybrid attention 模型（Mamba hybrid、GLA、DeltaNet、RetNet 混合架構），算 TurboQuant 效益前先確認有多少層是 full attention。架構改變了演算法的適用範圍。

一句話 takeaway：TurboQuant 的數學是對的，3-bit 是可用的，但效益取決於模型架構——hybrid attention 讓它的節省比論文說的少。

---

TL;DR

• TurboQuant 3-bit 在 GB10 上驗證正確：5x 壓縮，cosine sim 0.9943，Needle-in-Haystack EXACT
• QJL bias 校正是真實有效的（MSE-only 有系統性偏差，QJL 消除）
• 速度優勢目前不存在於 GB10：需要 fused kernel，目前的 PyTorch 實作比 matmul 慢 500x
• Qwen3.5-35B-A3B 只有 25% 的層有 KV cache（hybrid attention），TurboQuant 效益遠低於 dense 模型
• 等 vLLM PR #38280 合併，再決定是否在 production 上開啟