vLLM TurboQuant 研究：准确性与性能分析

vLLM 已对 TurboQuant 进行全面研究，这是一种 KV‑cache 量化方法，将存储压缩至 3‑4 位，并在注意力计算时反量化为 BF16。研究得出结论，虽然 TurboQuant 能提升 KV‑cache 容量，但往往以吞吐量、延迟和准确性为代价，使得 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‑cache 容量，精度损失可忽略，并且性能匹配或超过 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‑cache dtype 提供以下指导：

  • 使用 FP8 (--kv-cache-dtype fp8)： 这是最佳默认选项。它提供 2 倍容量，无吞吐量损失，且精度损失可忽略。
  • 使用 TurboQuant 4bit-nc： 在内存受限的部署中可考虑此方案，当对更高容量（最高可达 3.4 倍）和提升突发 TTFT 的需求大于适度的精度损失和吞吐量下降时。
  • 避免使用 TurboQuant k8v4： 相较于 FP8 仅提供适度的节省（2.4 倍），且没有性能优势。
  • 避免使用 TurboQuant k3v4-nc 和 3bit-nc： 这些变体因精度大幅下降和性能显著退化而不适合生产环境。
  • 使用 BF16： 如果 GPU 内存不是瓶颈，保持未量化的基线。

Sources