TurboQuant 初探：精度与性能的全面研究

2026年5月11日12 分钟阅读

Eldar Kurtić, Michael Goin, Alexandre Marques (Red Hat AI)

简介

TurboQuant 是一种 KV 缓存量化方法，近期因其通过超低位宽量化模型 KV 缓存而带来的巨大 GPU 显存节省，在社区中获得了广泛关注。与 FP8 KV 缓存量化不同——后者同时对 KV 缓存存储和注意力计算本身使用硬件原生的 FP8 Tensor Core 操作进行量化——TurboQuant 仅将 KV 缓存存储压缩至 3-4 位，并在进行注意力计算时将其反量化回 BF16。这种架构上的差异对准确性和性能都有显著影响。

然而，大多数已发表的报告是基于短上下文基准测试中的小型模型，这些测试并不能充分压力测试 KV 缓存量化。为了向社区提供更具可操作性的数据，我们进行了一项全面研究，涵盖了从 30B 到 200B+ 参数的四种模型（包括纯密集模型和 MoE 模型），以及包括预填充密集型长上下文检索和解码密集型推理工作负载在内的五个基准测试。

Figure 1: Pareto frontier for Llama-3.3-70B-Instruct on 4xH100. FP8 dominates with 2.6x higher burst throughput than BF16 and 2x KV-cache capacity. All TurboQuant variants trade throughput for additional memory savings. — 图 1：Llama-3.3-70B-Instruct 在 4xH100 上的帕累托前沿（Pareto frontier）。FP8 的突发吞吐量比 BF16 高 2.6 倍，且 KV 缓存容量增加了 2 倍。所有 TurboQuant 变体都是以吞吐量换取额外的显存节省。

Figure 2: Pareto frontier for Qwen3-30B-A3B-Instruct-2507 on 2xH100. FP8 matches BF16 throughput at 2x capacity. TurboQuant variants extend capacity to 2.3-3.7x but at 40-52% throughput reduction. — 图 2：Qwen3-30B-A3B-Instruct-2507 在 2xH100 上的帕累托前沿。FP8 在容量翻倍的情况下，吞吐量与 BF16 持平。TurboQuant 变体将容量扩展到 2.3-3.7 倍，但吞吐量下降了 40-52%。

总结

FP8（通过 --kv-cache-dtype fp8）依然是 KV 缓存量化的最佳默认选项：它在提供 2 倍 KV 缓存容量且准确性损失可忽略不计的同时，在大多数性能指标上能与 BF16 持平，并在内存受限的服务场景中大幅提升性能。
TurboQuant k8v4 相比 FP8 没有任何显著优势：它仅提供适度的 KV 缓存节省（2.4 倍 vs 2 倍），但换来的却是吞吐量和延迟指标持续的负面影响。
TurboQuant 4bit-nc 可能是最实用的 TurboQuant 变体：它有助于缓解 KV 缓存的内存压力，但以牺牲适度的准确性、延迟和吞吐量为代价。它可能仍适用于内存是主要限制因素的边缘部署场景。
TurboQuant k3v4-nc 和 3bit-nc 表现出明显的准确性下降，特别是在推理和超长上下文任务中，同时大幅降低了延迟和吞吐量。这使得它们不适合生产环境部署。

实验设置
准确性结果
- 长上下文检索
- 推理能力
性能结果
主要发现与建议

快速入门

# FP8 KV-cache for all layers
vllm serve MiniMaxAI/MiniMax-M2.7 --kv-cache-dtype fp8
 
# TurboQuant KV-cache, skipping the first and last two layers
vllm serve MiniMaxAI/MiniMax-M2.7 --kv-cache-dtype turboquant_4bit_nc

实验设置

量化方案： 我们对比了四种 TurboQuant 变体（--kv-cache-dtype turboquant_{k8v4, 4bit_nc, k3v4_nc, 3bit_nc}）与未量化的 BF16 和 FP8 KV 缓存基准。其中 turboquant_k8v4 使用 8 位键和 4 位值；turboquant_4bit_nc 使用带有归一化校正（norm correction）的 4 位键和值；turboquant_k3v4_nc 使用带有归一化校正的 3 位键和 4 位值；turboquant_3bit_nc 使用带有归一化校正的 3 位键和值。FP8 基准（--kv-cache-dtype fp8）以 FP8 精度存储查询、键和值，并对注意力计算本身也进行了量化——这是其与 TurboQuant 的关键区别，TurboQuant 仅压缩存储。有关每种 TurboQuant 变体的更多详细信息，请参阅论文和 vLLM 文档。有关 FP8 KV 缓存量化的更多详细信息，请参阅 FP8 KV 缓存博文。

基准测试： 我们在五个旨在对预填充密集型和解码密集型工作负载进行 KV 缓存量化压力测试的基准上进行了评估。对于长上下文检索（预填充密集型），我们使用 openai/mrcr——这是一个具有挑战性的多轮上下文检索任务，用于测试高达模型所支持最大长度的序列长度。对于推理（解码密集型），我们使用 AIME25、GPQA:Diamond、MATH500 和 LiveCodeBench-v6。所有评估都采用模型创建者建议的默认非贪婪采样参数，以模拟真实世界的部署。

模型： 我们重点关注了涵盖小型到大型规模以及纯密集和 MoE 架构的四种模型：Llama-3.3-70B-Instruct、Qwen3-30B-A3B-Instruct-2507、Qwen3-30B-A3B-Thinking-2507 以及 MiniMax-M2.7。撰写本文时，TurboQuant 仅支持具有标准注意力机制（如 GQA）的模型——暂不支持具有滑动窗口或混合注意力机制的模型。

准确性结果

长上下文检索

对于长上下文评估，我们使用 openai/mrcr 任务，测试序列长度高达模型所支持的最大长度。我们报告了 5 次重复后每个序列长度区间的平均 pass@1 分数，以及作为所有测试长度汇总指标的曲线下面积（AUC）（Context Arena）。

Figure 3: Long-context retrieval results for Llama-3.3-70B-Instruct up to 64k context. At 128k, the model's maximum supported context length, the BF16 baseline collapses to <10%. — 图 3：Llama-3.3-70B-Instruct 在高达 64k 上下文的长上下文检索结果。在 128k（模型支持的最大上下文长度）时，BF16 基准的准确率降至 <10%。

在 Llama-3.3-70B-Instruct（图 3）上，位宽较高的 TurboQuant 变体（k8v4 和 4bit-nc）较好地保留了长上下文检索能力，并保持了具有竞争力的 AUC（~52%）。然而，TQ k3v4-nc (48.6%) 和 3bit-nc (50.3%) 在所有序列长度上均显示出明显且持续的下降，且在 64k 上下文时差距扩大，准确率下降多达 8 个百分点。

Figure 4: Long-context retrieval results for Qwen3-30B-A3B-Instruct-2507 up to 256k context. — 图 4：Qwen3-30B-A3B-Instruct-2507 在高达 256k 上下文的长上下文检索结果。

在支持高达 256k 更长上下文的 Qwen3-30B-A3B-Instruct-2507（图 4）上，差异更为显著。BF16 (45.8%)、FP8 (43.1%) 和 TQ k8v4 (43.0%) 彼此处于标准差范围内。TQ 4bit-nc (42.3%) 也具有竞争力。但激进的变体性能显著下降：TQ k3v4-nc 降至 33.5% AUC，TQ 3bit-nc 降至 31.2%——相对于 BF16 相对下降了约 30%。性能下降集中在最长的上下文长度（128k-256k），表明低位 KV 缓存量化误差会随序列长度累积。

结论： TQ k8v4 和 4bit-nc 对于长上下文检索是安全的。TQ k3v4-nc 和 3bit-nc 在长上下文中表现出明显的准确性下降。FP8 与位宽较高的 TQ 变体相当，同时提供更好的推理性能（稍后展示）。

推理能力

对于解码密集型的推理基准，我们使用 AIME25、GPQA:Diamond、MATH500 和 LiveCodeBench-v6。我们报告平均 pass@1 分数：AIME25 和 LiveCodeBench-v6 进行了 10 次重复，GPQA:Diamond 和 MATH500 进行了 5 次重复。

Figure 5: Reasoning results for Qwen3-30B-A3B-Thinking-2507. Aggressive TQ variants (k3v4-nc, 3bit-nc) show very large drops on AIME25 and LiveCodeBench-v6. — 图 5：Qwen3-30B-A3B-Thinking-2507 的推理结果。激进的 TQ 变体（k3v4-nc, 3bit-nc）在 AIME25 和 LiveCodeBench-v6 上表现出非常大幅的下降。

在 Qwen3-30B-A3B-Thinking-2507（图 5）上，我们看到了清晰的准确性等级：FP8 和 TQ k8v4 与 BF16 基准接近，平均准确率恢复率超过 98%。TQ 4bit-nc 表现出略大的下降，恢复率为 96%，而 TQ k3v4-nc 和 3bit-nc 的准确率出现了约 20 个百分点的急剧下降。即使在相对简单的 MATH500 基准上，准确率下降也达到了约 4 个百分点，表明激进的 TurboQuant 变体不适合长生成任务的推理。

Figure 6: Reasoning results for MiniMax-M2.7. Despite the fact that larger models tend to be more robust to quantization, aggressive TurboQuant variants still show significant accuracy degradation, specifically on AIME25 and LiveCodeBench-v6. — 图 6：MiniMax-M2.7 的推理结果。尽管大型模型往往对量化更鲁棒，但激进的 TurboQuant 变体仍然显示出显著的准确性下降，特别是在 AIME25 和 LiveCodeBench-v6 上。

在 MiniMax-M2.7（一种 200B+ 参数的更大模型，图 6）上，我们观察到了类似的模式。FP8 和 TQ k8v4 保持了 99% 以上的准确率恢复，而 TQ 4bit-nc 出现适度下降。正如较小的 Qwen 模型一样，激进的 TQ 变体（k3v4-nc, 3bit-nc）在 AIME25 和 LiveCodeBench-v6 上表现出显著的准确性下降，准确率降幅高达约 8 个百分点。

结论： 激进的 TurboQuant 变体（k3v4-nc, 3bit-nc）在 AIME25 和 LiveCodeBench-v6 等困难数学和编码任务上表现出显著的准确性下降。TQ 4bit-nc 表现出适度的准确性下降，而 TQ k8v4 的表现与未量化的 BF16 基准相当。FP8 也与未量化的基准持平；然而，它提供了比任何 TurboQuant 变体都显著更好的推理性能（稍后展示）。

性能结果

对于性能基准测试，我们重点关注 Qwen3-30B-A3B-Instruct-2507 (2xH100) 和 Llama-3.3-70B-Instruct (4xH100)。我们在不同的请求速率下测量延迟、离线吞吐量和在线服务指标（TPOT 和 TTFT）。我们使用 vLLM 版本 0.20.2 (提交 6ec9bbec3) 部署模型。

延迟

我们使用 vllm bench latency 测量延迟，使用输入长度 1024 和输出长度 256 的固定合成请求，批处理大小分别为 1, 8, 32 和 64。每个配置使用了 10 次预热迭代，随后进行 30 次测量迭代。结果显示为相对于 BF16 的减速比（越低越好）。

Figure 7: Latency overhead relative to BF16 for Qwen3-30B-A3B-Instruct-2507. FP8 has negligible overhead which disappears with batching; TurboQuant (TQ) adds up to 60% slowdown depending on the variant and batch size. — 图 7：Qwen3-30B-A3B-Instruct-2507 相对于 BF16 的延迟开销。FP8 具有可忽略不计的开销，该开销随批处理消失；TurboQuant (TQ) 根据变体和批处理大小增加了多达 60% 的减速。

Figure 8: Latency overhead relative to BF16 for Llama-3.3-70B-Instruct. FP8 has negligible overhead, whereas TQ overhead ranges from 10% to 68%. — 图 8：Llama-3.3-70B-Instruct 相对于 BF16 的延迟开销。FP8 开销可忽略不计，而 TQ 开销在 10% 到 68% 之间。

FP8 在这两种模型和所有批处理大小下始终具有可忽略或零的延迟开销——这是预期的，因为 FP8 使用硬件原生的 FP8 Tensor Core 操作来量化注意力计算本身，从而避免了反量化开销。所有 TurboQuant 变体都会增加可测量的延迟：在 Qwen-30B 上（图 7），开销范围从约 10% 到 60%；在 Llama-70B 上（图 8），整体开销更高，范围从约 10% 到 68%。值得注意的是，对于较大的 Llama-70B 模型，TQ 开销往往随批处理大小的增加而增加——这与我们对此用例的预期相反。这是因为 TurboQuant 在计算注意力之前必须将 KV 缓存从低位存储反量化回 BF16，且此反量化成本会随着被访问的 KV 缓存量增长。

吞吐量

我们使用 vllm bench throughput 测量离线吞吐量，使用跨三个输入/输出长度对（256/256, 1024/512 和 4096/256）的 200 个提示词。结果显示为 BF16 吞吐量的百分比（越高越好）。

Figure 9: Average throughput relative to BF16 for Qwen3-30B-A3B-Instruct-2507. FP8 preserves BF16 throughput, while all TurboQuant variants reduce throughput, indicating that lower KV-cache storage cost does not directly translate into faster serving. — 图 9：Qwen3-30B-A3B-Instruct-2507 相对于 BF16 的平均吞吐量。FP8 保留了 BF16 吞吐量，而所有 TurboQuant 变体均降低了吞吐量，表明较低的 KV 缓存存储成本并不能直接转化为更快的服务。

Figure 10: Average throughput relative to BF16 for Llama-3.3-70B-Instruct. FP8 preserves BF16 throughput, while all TurboQuant variants reduce throughput, indicating that lower KV-cache storage cost does not directly translate into faster serving. — 图 10：Llama-3.3-70B-Instruct 相对于 BF16 的平均吞吐量。FP8 保留了 BF16 吞吐量，而所有 TurboQuant 变体均降低了吞吐量。

吞吐量结果强化了延迟测试的发现。FP8 在两种模型上均与 BF16 吞吐量持平。所有 TurboQuant 变体均严格低于 BF16：在 Qwen-30B 上（图 9），范围从 80% (k8v4) 到 73% (3bit-nc)；在 Llama-70B 上（图 10），从 75% (k8v4 和 4bit-nc) 到 66% (3bit-nc)。更激进的量化始终产生较低的吞吐量——反量化开销随打包格式的复杂性而增长。

服务吞吐量

我们使用 vllm bench serve 测量服务性能，使用输入长度 1024 和输出长度 512 的合成请求，测试 300 个提示词并预热 5 次。我们测试了请求速率 2、8 和 inf（尽可能快地发送请求）。我们报告了 TPOT（每个输出 token 时间——衡量解码速度）和 P99 TTFT（首个 token 时间——衡量请求开始生成的速度）。

Figure 11: Serving time per output token (TPOT) for Qwen3-30B-A3B-Instruct-2507. — 图 11：Qwen3-30B-A3B-Instruct-2507 的服务每个输出 token 时间 (TPOT)。

Figure 12: Serving time per output token (TPOT) for Llama-3.3-70B-Instruct. — 图 12：Llama-3.3-70B-Instruct 的服务每个输出 token 时间 (TPOT)。

TPOT 结果（图 11-12）反映了延迟和吞吐量的发现：FP8 在所有请求速率下都跟踪或优于 BF16，而 TQ 变体增加了随负载增加的显著每个 token 开销。在 Llama-70B 突发负载下，FP8 比 BF16 快近 2 倍，而 TQ 变体慢 1.5 倍到 2.5 倍。

Figure 13: P99 TTFT for Qwen3-30B-A3B-Instruct-2507. — 图 13：Qwen3-30B-A3B-Instruct-2507 的 P99 TTFT。

Figure 14: P99 TTFT for Llama-3.3-70B-Instruct. Under burst load, BF16 TTFT explodes to ~17s due to memory saturation; TurboQuant variants stay under 3.5s and FP8 under 1.5s. — 图 14：Llama-3.3-70B-Instruct 的 P99 TTFT。在突发负载下，由于内存饱和，BF16 TTFT 激增至约 17 秒；TurboQuant 变体保持在 3.5 秒以下，FP8 在 1.5 秒以下。

在拥有更多内存余量的 Qwen-30B（在 2xH100 上，图 13）上，FP8 在所有请求速率下表现与 BF16 相同。TurboQuant 变体始终较慢，在突发负载下减速达 2 倍。在 Llama-3.3-70B（在 4xH100 上，KV 缓存空间有限，图 14）上，由于系统耗尽了 KV 缓存内存且必须对传入请求进行排队，BF16 的突发 TTFT 爆炸至约 17 秒。所有 TurboQuant 变体均保持在 3.5 秒以下——提升了 5 倍——因为它们的压缩 KV 缓存允许在无需排队的情况下处理更多并发请求。同时，FP8 实现了约 1.3 秒的最快 TTFT，并持续优于所有 TurboQuant 变体。

结论： TurboQuant 通过降低吞吐量和增加每个 token 的延迟，表现始终不及 BF16 和 FP8。然而，在内存受限的服务场景中，KV 缓存压缩防止了内存饱和，并在突发负载下相对于 BF16 显着降低了 TTFT。这是 TurboQuant 价值主张的核心：它以牺牲每个 token 的速度为代价，换取处理原本需要排队的请求的能力。另一方面，FP8 实现了两全其美：它匹配或优于 BF16 吞吐量，同时提供了可忽略的延迟开销，并在突发负载下显著改善了 TTFT。

主要发现与建议

基于在准确性和性能基准测试中的全面评估，我们得出以下实际建议

FP8 (--kv-cache-dtype fp8) 依然是 KV 缓存量化的最佳默认选择。 FP8 提供 2 倍 KV 缓存容量且没有吞吐量损失、准确性损失可忽略不计，甚至有时通过量化注意力提升性能。对于绝大多数工作负载而言，它是最安全、最可预测的选择，正如 FP8 KV 缓存博文中所详细说明的那样。

TurboQuant k8v4 相比 FP8 没有任何显著优势。 这种 TQ 变体仅提供微小的 KV 缓存节省（2.4 倍 vs 2 倍），不值得以吞吐量和延迟指标的持续负面影响为代价。

TurboQuant 4bit-nc 提供了令人信服的“内存换吞吐量”权衡。 此变体提供高达 3.4 倍的 KV 缓存容量，大多数基准测试中准确性下降 1-4 个百分点。它在内存受限的部署中特别有价值，即突发负载下的 TTFT 改善胜过了对所有其他指标的负面影响。在部署前，请彻底验证目标工作负载的准确性。

在没有彻底验证的情况下，避免使用 TurboQuant k3v4-nc 和 3bit-nc。 这些激进的变体可能导致剧烈的准确率下降，在挑战性的数学和编码基准上甚至高达 20 个百分点。除了准确性之外，由于复杂的反量化步骤导致性能持续下降，它们也不适合生产部署。

当 GPU 显存不是瓶颈时，请坚持使用 BF16。 如果您的工作负载使用短上下文、在低并发下运行或硬件内存充足，BF16 可在没有量化伪影风险的情况下提供最佳的准确性与性能平衡。