vLLM TurboQuant 研究：準確性與效能分析

vLLM 針對 TurboQuant 進行了一項全面研究，TurboQuant 是一種 KV 快取量化方法，可將儲存壓縮至 3‑4 位元，並在注意力計算時反量化為 BF16。研究結論指出，雖然 TurboQuant 能提升 KV 快取容量，但往往以吞吐量、延遲與準確度為代價，使得 FP8 成為大多數使用者的推薦預設。

量化方案比較

研究比較了四種 TurboQuant 變體與未量化的 BF16 及 FP8 基線，涵蓋參數規模從 30B 到 200B+ 的模型（包括 Llama-3.3-70B-Instruct、Qwen3-30B-A3B 與 MiniMax-M2.7）。

• FP8 (--kv-cache-dtype fp8)： 同時對儲存與注意力計算進行量化，使用硬體原生的 FP8 Tensor Core 操作。它提供 2 倍 KV 快取容量，準確度損失可忽略，且效能與 BF16 相當或更佳。
• TurboQuant k8v4： 使用 8 位元鍵與 4 位元值。
• TurboQuant 4bit-nc： 使用 4 位元鍵與值，並加入正規化校正。
• TurboQuant k3v4-nc： 使用 3 位元鍵與 4 位元值，並加入正規化校正。
• TurboQuant 3bit-nc： 使用 3 位元鍵與值，並加入正規化校正。

準確度影響

準確度下降程度因量化變體的激進程度而有顯著差異，尤其在長上下文與推理任務中。

長上下文檢索

使用 openai/mrcr 任務時，研究發現較高位元的變體（k8v4 與 4bit-nc）能良好保留檢索效能。然而，激進的變體（k3v4-nc 與 3bit-nc）則出現顯著下降。在 Qwen3-30B-A3B-Instruct-2507 上，這些激進變體相較於 BF16 約有 30% 的相對下降，且錯誤在序列長度 128k 至 256k 之間累積。

推理效能

在以解碼為主的推理基準測試（AIME25、GPQA:Diamond、MATH500 與 LiveCodeBench-v6）中，激進的 TurboQuant 變體（k3v4-nc 與 3bit-nc）在 Qwen3-30B-A3B-Thinking-2507 上導致準確度下降高達 20 分。即使在 200B+ 參數的 MiniMax-M2.7 模型上，這些變體在 AIME25 與 LiveCodeBench-v6 上亦顯著退化，證明模型規模無法完全抵消低位元量化帶來的準確度損失。

效能與服務指標

TurboQuant 會產生反量化開銷，因為它必須在計算注意力前將低位元儲存轉回 BF16；相較之下，FP8 直接在 FP8 中計算。

延遲與吞吐量

• FP8： 幾乎沒有延遲開銷，且在所有測試模型上與 BF16 吞吐量相當。
• TurboQuant： 所有變體皆增加可測量的延遲。在 Llama-3.3-70B 上，開銷介於 10% 至 68% 之間，且隨批次大小增加而上升。吞吐量嚴格低於 BF16，依變體不同約為 BF16 吞吐量的 66% 至 80%。

服務速度（TPOT 與 TTFT）

• 每個輸出標記時間 (TPOT)： FP8 的表現與 BF16 相當或更佳。TurboQuant 變體在每個標記上增加顯著開銷，且隨負載增長；在 Llama-70B 的突發情況下，TQ 變體比 BF16 慢 1.5 倍至 2.5 倍。
• 首次標記時間 (TTFT)： 在記憶體受限的情況下（例如 Llama-3.3-70B 使用 4xH100），BF16 的 TTFT 可能因記憶體飽和而急遽上升。TurboQuant 變體透過允許更多同時請求，將 TTFT 大幅降低（維持在 3.5 秒以下，對比 BF16 的 17 秒）。然而，FP8 提供最佳結果，TTFT 最低約為 1.3 秒。

最終建議

根據評估結果，vLLM 提供以下選擇 KV 快取資料型別的指引：

• 使用 FP8 (--kv-cache-dtype fp8)： 這是最佳的預設選擇。它提供 2 倍容量，無吞吐量損失，且準確度損失可忽略。
• 使用 TurboQuant 4bit-nc： 在記憶體受限的部署情境下可考慮，當需要更高容量（最高可達 3.4 倍）與改善突發 TTFT，且可接受適度的準確度損失與吞吐量下降時。
• 避免使用 TurboQuant k8v4： 它相較於 FP8 只提供約 2.4 倍的節省，且沒有效能上的好處。
• 避免使用 TurboQuant k3v4-nc 與 3bit-nc： 這些變體因準確度大幅下降與效能嚴重退化而不適合生產環境。
• 使用 BF16： 若 GPU 記憶體不是瓶頸，則保持未量化的基線。