TurboQuant 與 FP8 實測結果
vLLM 首次大規模比較 TurboQuant 與 FP8 KV-cache。結果很直白：FP8 在速度上更穩，TurboQuant 的高壓縮版本則常掉準確率。
vLLM 首次大規模比較 TurboQuant 與 FP8 KV-cache。結果很直白：FP8 在速度上更穩，TurboQuant 的高壓縮版本則常掉準確率。
vLLM 在 2026 年 5 月 11 日發文。它把 TurboQuant 拉進真實服務場景測。測了 4 個變體、4 個模型、5 個 benchmark。還同時比了 BF16 和 FP8 KV-cache。
講白了，這不是小 demo。這是看伺服器真的扛不扛得住。KV-cache 一旦進到長上下文、高併發、記憶體吃緊的場景，速度和準確率就會一起露餡。
| 方法 | KV-cache 容量 | 延遲影響 | 吞吐影響 | 準確率訊號 |
|---|---|---|---|---|
| FP8 | 2x | 幾乎沒有 | 接近 BF16 | 接近基準 |
| TurboQuant k8v4 | 2.4x | 慢 10% 到 68% | BF16 的 80% 到 75% | 接近基準 |
| TurboQuant 4bit-nc | 2.3x 到 3.7x | 有明顯變慢 | 約 BF16 的 75% | 有中度下降 |
| TurboQuant k3v4-nc / 3bit-nc | 高於 FP8 | 最慢 | BF16 的 66% 到 73% | 下降明顯 |
TurboQuant 為什麼會紅
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
TurboQuant 的做法很直接。它把 KV-cache 壓到 3 到 4 bit。之後再解量化回 BF16，才能做 attention。這跟 FP8 很不一樣。FP8 是直接存 FP8，attention 也能跑 FP8 Tensor Core。
差別就在這裡。TurboQuant 省記憶體很兇。可是在推理路徑裡，它多了一段解量化成本。你省下來的空間，常常又被額外運算吃回去。
所以 vLLM 這篇比較像實測報告，不像產品宣傳。很多方法在簡報上很漂亮。可是一到延遲、吞吐、準確率，尤其是長提示詞和推理題，結果就很誠實。
- 測試的 TurboQuant 變體有 4 種：k8v4、4bit-nc、k3v4-nc、3bit-nc
- 基準是 BF16 和 FP8
- 模型包含 MiniMax-M2.7、Llama-3.3-70B-Instruct、Qwen3-30B-A3B-Instruct-2507、Qwen3-30B-A3B-Thinking-2507
- benchmark 包含 openai/mrcr、AIME25、GPQA:Diamond、MATH500、LiveCodeBench-v6
準確率到底掉多少
準確率的結論沒有那麼單一，但趨勢很清楚。FP8 和 TurboQuant k8v4 大多能貼近原始基準。這代表它們還算能用，至少不會一上線就把答案搞歪。
4bit-nc 就開始有感了。它還在可討論範圍內。若你的伺服器真的卡在記憶體，這版本可能還能試。可是一旦壓到 k3v4-nc 或 3bit-nc，掉分就很明顯。
在長上下文檢索上，Llama-3.3-70B-Instruct 於 128k context 的結果很有代表性。BF16 平均恢復率約 98%。4bit-nc 約 96%。k3v4-nc 和 3bit-nc 則大約少了 20 分。
"FP8 via --kv-cache-dtype fp8 remains the best default for KV-cache quantization." — vLLM blog, 2026-05-11
這句話很直白。我也覺得很合理。你如果想保住準確率，又想省一點記憶體，FP8 就是最穩的預設值。TurboQuant 比較像特殊情境工具，不是通用答案。
- 長上下文檢索測到各模型支援的最長長度
- 準確率是 5 次重複的平均 pass@1
- k3v4-nc 和 3bit-nc 在最難的長上下文案例大約掉 20 分
- MiniMax-M2.7 上，激進版本在 AIME25 與 LiveCodeBench-v6 最多掉約 8 分
速度這關，TurboQuant 輸得更明顯
速度結果更不漂亮。vLLM 用 1,024 個 input tokens 和 256 個 output tokens 來測延遲。batch size 也掃了 1、8、32、64。FP8 幾乎沒什麼負擔。TurboQuant 就不是這樣。
在 Qwen3-30B-A3B-Instruct-2507 上，TurboQuant 的延遲開銷大約落在 10% 到 60%。在 Llama-3.3-70B-Instruct 上，範圍更大，約 10% 到 68%。而且 batch size 越大，開銷還會往上爬。這對服務團隊來說很煩。
吞吐量也一樣。FP8 在兩個模型上都能貼近 BF16。TurboQuant 則低一截。Qwen3-30B 介於 BF16 的 80% 到 73%。Llama-3.3-70B 則是 75% 到 66%。
這代表一件事。KV-cache 省下來的容量，不會自動變成更快的服務。你把解量化成本加回去，整個算式就變了。
- 延遲測試用了 10 次 warmup 和 30 次正式測試
- 吞吐測試用了 200 個 prompts，token 組合為 256/256、1024/512、4096/256
- vLLM 版本是 0.20.2，commit 為 6ec9bbec3
- FP8 在延遲和吞吐上都接近 BF16，TurboQuant 則持續落後
對實際部署代表什麼
這份測試最實際的結論是，TurboQuant 是記憶體工具，不是效能工具。若你的模型服務真的卡在 KV-cache 容量，而且你能接受慢一點，那 TurboQuant 4bit-nc 可以先試。若你同時在意延遲、吞吐、準確率，FP8 比較乾脆。
還有一個硬體面很重要。FP8 會吃到現代 NVIDIA GPU 的原生 Tensor Core。TurboQuant 則要先把低 bit 資料拆開，attention 才能跑。慢的那一段，通常就卡在這裡。
所以這篇文章對工程團隊的價值，不是給你一張漂亮圖表，而是幫你縮小實驗範圍。先試 FP8。只有在記憶體真的還不夠時，再去碰 TurboQuant。若你打算在 H100 上部署，問題就不是 TurboQuant 能不能省空間。問題是，你願不願意拿速度和準確率去換那點空間。
我也建議把這篇和 OraCore 的 FP8 KV-cache in vLLM、KV-cache optimization strategies 一起看。你會更快看懂，哪些優化是真的能上線，哪些只是實驗室裡好看。
結論
vLLM 這次的大規模比較很直接。TurboQuant 只有在記憶體壓力很大時才值得考慮。就算要用，FP8 還是大多數團隊該先試的預設值。
如果你在做模型服務，我的建議很簡單。先量你的 KV-cache 壓力，再看延遲預算。若兩者都緊，就別急著追低 bit。先把 FP8 跑穩，才有資格談 TurboQuant。