A First Comprehensive Study of TurboQuant: Accuracy and Performance

发表时间: 2026-05 · Blog post by Eldar Kurtić, Michael Goin, Alexandre Marques (Red Hat AI) (blog.vllm.ai)

原文: https://blog.vllm.ai/blog/2026-05-11-turboquant

作者/机构：Eldar Kurtić, Michael Goin, Alexandre Marques (Red Hat AI)

速读

一句话结论
本文在 30B 到 200B+ 参数规模的大模型和长上下文、复杂推理任务上全面评估了 TurboQuant 键值缓存量化方法，发现其激进的低比特变体虽能大幅节省显存，但会带来严重的精度下降与延迟开销，而 FP8 依然是兼顾容量与性能的最佳默认选择。

要解决什么问题
大语言模型在长上下文生成和高并发服务时，键值缓存（KV-cache）会占用海量 GPU 显存，导致系统极易触及显存瓶颈，进而引发请求排队、首字延迟（TTFT）激增甚至系统崩溃。为了缓解显存压力，社区近期推出了 TurboQuant 这一极低比特（3 到 4 比特）的 KV-cache 量化方法，并宣称能大幅节省显存。然而，原有的评估做法存在明显的局限性：此前的测试大多局限于小规模模型，且仅在短上下文基准测试上运行。这种测试环境根本无法真正对 KV-cache 量化施加压力。在真实的生产环境中，模型规模往往在数百亿参数以上，且需要处理极长的上下文检索（如 256K 长度）或生成大量 token 的复杂推理任务。在这些极端场景下，极低比特量化是否会导致误差随序列长度累积而引发外推失效？复杂的解量化过程是否会拖慢系统吞吐量？原有做法无法回答这些关于精度掉点和并行度下降的核心机制问题，导致工程师在部署时缺乏可操作的真实数据指导。

怎么做的
本文的核心思路不是提出新的量化算法，而是构建一套严苛的压力测试体系，从机制底层拆解并对比不同 KV-cache 量化路线的真实代价。研究的关键设计围绕两种截然不同的量化架构展开。第一条路线是硬件原生的 FP8 KV-cache 量化，其机制是将查询、键和值均以 FP8 精度存储，并且直接调用 GPU 硬件原生的 FP8 Tensor Core 指令来完成注意力机制的矩阵计算。第二条路线则是本文重点考察的 TurboQuant 方法，其内核是“仅压缩存储，不改变计算精度”。TurboQuant 仅将 KV-cache 的存储压缩到极低的 3 到 4 比特，但在执行注意力计算之前，必须在内存读取阶段将其动态解量化回 BF16 精度。为了探究这种架构差异带来的影响，作者引入了四种具体的 TurboQuant 变体进行消融对比：k8v4（8 比特键，4 比特值）、4bit-nc（4 比特键值，带范数校正）、k3v4-nc（3 比特键，4 比特值，带范数校正）以及最激进的 3bit-nc（3 比特键值，带范数校正）。由于 TurboQuant 的核心机制是动态解量化，其计算复杂度与访问的 KV-cache 数据量强相关。我们可以将其单次注意力计算的开销抽象为访存与计算两部分：

$$ T_{total} = O(N \cdot d \cdot b) + O(N \cdot d) $$

其中 $N$ 为上下文长度，$d$ 为隐藏层维度，$b$ 为量化比特数。第一项代表从低比特存储中读取并解量化的访存开销，第二项代表 BF16 精度下的注意力计算开销。这种设计虽然绕开了低比特直接计算的精度损失，但意味着随着批处理大小和上下文长度的增加，解量化的开销会显著放大，从而可能成为限制吞吐量的新卡点。为了验证这一点，作者在 vLLM 框架下，针对预填充密集型的长上下文检索和解码密集型的复杂推理任务，全面测试了这些变体。

效果如何
实验在 2xH100 和 4xH100 硬件上搭建，选取了涵盖稠密与混合专家架构的四个模型：Llama-3.3-70B-Instruct、Qwen3-30B-A3B-Instruct-2507、Qwen3-30B-A3B-Thinking-2507 以及 200B+ 参数的 MiniMax-M2.7。对比基线为两条路线：代表不压缩上限的无量化 BF16，以及代表计算与存储双量化路线的 FP8。量化结果表明，FP8 依然是最佳默认选择：它能提供 2 倍的 KV-cache 容量，精度几乎无损，且在吞吐量上持平甚至超越 BF16。相比之下，TurboQuant 的表现存在明显的代价。在精度方面，对于 256K 长上下文检索任务，激进的 3bit-nc 变体会导致准确率从 BF16 的 45.8% 暴跌至 31.2%（相对下降约 30%）；在 AIME25 等复杂推理任务上，k3v4-nc 和 3bit-nc 更是出现了高达 20 个百分点的严重掉点，证明低比特量化误差会在长生成任务中急剧放大。在性能方面，TurboQuant 降低存储成本并未转化为更快的服务速度。由于解量化开销，所有 TurboQuant 变体均会导致吞吐量下降，仅为 BF16 的 66% 到 80%，且延迟开销随批处理大小增加而增加（最高达 68% 的延迟惩罚）。作者承认的唯一有效场景是极度受限的显存环境：在突发高负载下，BF16 会因显存耗尽导致首字延迟飙升至 17 秒，此时 4bit-nc 变体能提供 3.4 倍的容量，将延迟压制在 3.5 秒以内。但即便如此，FP8 在该场景下依然能将延迟控制在 1.5 秒以内。因此，除非硬件显存极度匮乏且无法使用 FP8，否则不建议在生产环境中使用激进的 TurboQuant 变体。

A1 主要贡献

本文针对近期在社区中获得广泛关注的KV-cache量化方法TurboQuant进行了首次全面的准确性与性能研究。此前的报告大多基于小型模型和短上下文基准测试，未能对KV-cache量化进行极限压力测试。为了向社区提供更具指导意义的数据，本文的研究目标是跨越不同规模（从30B到200B+参数）、不同架构（仅稠密模型和MoE模型）的四个模型，在包含重预填充（prefill-heavy）的长上下文检索和重解码（decode-heavy）的推理任务等五个基准测试上，全面评估TurboQuant的实际表现。

本文的核心创新点与贡献在于：通过构建详尽的帕累托前沿（Pareto frontier），系统性地量化了不同TurboQuant变体在内存节省与吞吐量/延迟之间的权衡关系，并将其与未量化的BF16基线以及FP8 KV-cache量化进行了深度对比，得出了在生产环境中部署KV-cache量化的最佳实践建议。

A2 背景知识与关键Observation

FP8与TurboQuant的架构差异。FP8 KV-cache量化（通过--kv-cache-dtype fp8启用）不仅对KV-cache的存储进行量化，还利用硬件原生的FP8 Tensor Core操作对注意力计算本身进行量化。与此形成鲜明对比的是，TurboQuant仅仅将KV-cache的存储压缩至$3$-$4$ bits，在进行注意力计算时，必须先将其反量化（dequantize）回BF16格式。这一核心的架构差异对模型的最终准确性和推理性能产生了深远的影响。

A3 方法细节

量化方案的配置与对比。本文对四种TurboQuant变体（通过--kv-cache-dtype turboquant_{k8v4, 4bit_nc, k3v4_nc, 3bit_nc}启用）与未量化的BF16以及FP8 KV-cache基线进行了基准测试对比。具体而言，turboquant_k8v4采用$8$-bit的键（keys）和$4$-bit的值（values）；turboquant_4bit_nc采用带有范数校正（norm correction）的$4$-bit键和值；turboquant_k3v4_nc采用带有范数校正的$3$-bit键和$4$-bit值；而turboquant_3bit_nc则采用带有范数校正的$3$-bit键和值。FP8基线（--kv-cache-dtype fp8）将查询（queries）、键（keys）和值（values）均存储为FP8精度，并对注意力计算本身进行量化。

快速启动代码实现。以下是部署FP8和TurboQuant 4bit-nc变体的vLLM服务启动代码示例：

# 为所有层启用FP8 KV-cache
vllm serve MiniMaxAI/MiniMax-M2.7 --kv-cache-dtype fp8
 
# 启用TurboQuant KV-cache，并跳过最初和最后的两层
vllm serve MiniMaxAI/MiniMax-M2.7 --kv-cache-dtype turboquant_4bit_nc

A4 实验环境

• 数据集与基准测试：

  • 长上下文检索（重预填充）：使用openai/mrcr（一个具有挑战性的多轮上下文检索任务），测试序列长度直至每个模型支持的最大长度。
  • 推理任务（重解码）：使用AIME25、GPQA:Diamond、MATH500和LiveCodeBench-v6。所有评估均采用模型创建者建议的默认非贪婪（non-greedy）采样参数，以模拟真实世界的部署情况。

• 模型架构：包含四个模型，涵盖小规模与大规模、稠密与MoE架构：Llama-3.3-70B-Instruct、Qwen3-30B-A3B-Instruct-2507、Qwen3-30B-A3B-Thinking-2507以及MiniMax-M2.7（参数量达200B+）。注：TurboQuant目前仅支持具有标准注意力机制（如GQA）的模型，尚不支持滑动窗口或混合注意力模型。

• 硬件配置：Qwen3-30B-A3B-Instruct-2507在2xH100上运行；Llama-3.3-70B-Instruct在4xH100上运行。
• 软件配置：部署基于vLLM版本0.20.2（commit 6ec9bbec3）。

A5 实验结果

1. 准确性结果：长上下文检索

在openai/mrcr任务上，报告了每个序列长度桶在$5$次重复下的平均pass@1分数，以及作为聚合指标的曲线下面积（AUC）。

• Llama-3.3-70B-Instruct实验：如图3所示，高比特的TurboQuant变体（k8v4和4bit-nc）能很好地保留长上下文检索能力，并维持了具有竞争力的AUC（约$52\%$）。然而，TQ k3v4-nc（$48.6\%$）和3bit-nc（$50.3\%$）在所有序列长度上均表现出明显且一致的退化，在$64$k上下文处差距进一步拉大，准确率下降高达$8$个百分点。

• Qwen3-30B-A3B-Instruct-2507实验：如图4所示，该模型支持高达$256$k的上下文，差异更为显著。BF16（$45.8\%$）、FP8（$43.1\%$）和TQ k8v4（$43.0\%$）保持在彼此的标准差范围内。TQ 4bit-nc（$42.3\%$）同样具有竞争力。但激进的变体退化严重：TQ k3v4-nc的AUC降至$33.5\%$，TQ 3bit-nc降至$31.2\%$（相比BF16相对退化约$30\%$）。退化主要集中在最长的上下文长度（$128$k-$256$k），表明低比特KV-cache量化误差会随序列长度累积。

2. 准确性结果：推理任务

报告了平均pass@1分数：AIME25和LiveCodeBench-v6重复$10$次，GPQA:Diamond和MATH500重复$5$次。

• Qwen3-30B-A3B-Thinking-2507实验：如图5所示，存在清晰的准确性层级。FP8和TQ k8v4接近BF16基线，准确率恢复超过$98\%$。TQ 4bit-nc下降略大，恢复率为$96\%$。而TQ k3v4-nc和3bit-nc显示出约$20$个百分点的急剧下降。即使在相对简单的MATH500上，准确率也下降了约$4$个百分点，表明激进的TurboQuant变体不适合长生成的推理任务。

• MiniMax-M2.7实验：如图6所示，在这个200B+参数的模型上观察到类似模式。FP8和TQ k8v4保持了>$99\%$的准确率恢复，TQ 4bit-nc出现适度下降。激进的TQ变体（k3v4-nc, 3bit-nc）在AIME25和LiveCodeBench-v6上表现出高达约$8$个百分点的显著准确率退化。

3. 性能结果：延迟（Latency）

使用vllm bench latency，输入长度$1024$，输出长度$256$，批量大小（batch sizes）分别为$1$、$8$、$32$和$64$。$10$次预热后进行$30$次测量。

• Qwen3-30B-A3B-Instruct-2507实验：如图7所示，FP8在所有批量大小下均保持极低或零延迟开销。而TurboQuant变体增加了$10\%$到$60\%$的延迟开销。
• Llama-3.3-70B-Instruct实验：如图8所示，FP8开销可忽略不计。TQ的开销整体更高，范围在$10\%$到$68\%$之间。值得注意的是，对于更大的Llama-70B模型，TQ的开销倾向于随着批量大小的增加而增加。这是因为TurboQuant必须在计算注意力之前将KV-cache从低比特存储反量化回BF16，该成本随着访问的KV-cache量的增加而增长。

4. 性能结果：吞吐量（Throughput）

使用vllm bench throughput，$200$个提示词，输入/输出长度对为：$256$/$256$、$1024$/$512$、$4096$/$256$。

• 吞吐量对比实验：FP8在两个模型上均匹配了BF16的吞吐量。而所有TurboQuant变体均严格低于BF16：在Qwen3-30B上（图9），范围从$80\%$（k8v4）降至$73\%$（3bit-nc）；在Llama-70B上（图10），从$75\%$（k8v4和4bit-nc）降至$66\%$（3bit-nc）。量化越激进，吞吐量越低，因为反量化开销随着打包格式的复杂性而增加。

5. 性能结果：服务速度（Serving Speed）

使用vllm bench serve，输入$1024$，输出$512$，$300$个测量提示词，$5$次预热。请求率（request rates）设为$2$、$8$和inf（尽可能快地发送）。测量TPOT（每个输出Token耗时）和P99 TTFT（首个Token耗时）。

• TPOT实验（图11-12）：FP8在所有请求率下均跟踪或超越BF16，而TQ变体增加了大量随负载增长的每Token开销。在Llama-70B的突发负载下，FP8比BF16快近$2$倍，而TQ变体慢$1.5$至$2.5$倍。
• TTFT实验（图13-14）：在Qwen3-30B（2xH100，内存充足）上，FP8表现与BF16完全一致，TQ变体一致较慢（突发时慢达$2$倍）。在Llama-3.3-70B（4xH100，KV-cache空间受限）上，突发负载下BF16的TTFT爆炸至约$17$秒（因内存饱和导致请求排队）。所有TurboQuant变体均保持在$3.5$秒以下（提高了$5$倍），因为压缩的KV-cache允许处理更多并发请求而无需排队。同时，FP8实现了最低的TTFT（约$1.3$秒），并始终优于所有TurboQuant变体。

A6 结论

基于跨越准确性和性能基准的全面评估，本文得出以下关键发现与实用建议：

1. FP8（--kv-cache-dtype fp8）仍然是KV-cache量化的最佳默认选择。FP8提供了$2$倍的KV-cache容量且没有吞吐量成本，准确度损失可忽略不计，有时甚至通过量化注意力提高了性能。对于绝大多数工作负载而言，它是最安全且最可预测的选择。
2. TurboQuant k8v4相比FP8没有提供任何显著优势。该TQ变体仅提供了适度的KV-cache节省（$2.4$倍 vs $2$倍），这不值得其对吞吐量和延迟指标造成的一致负面影响。
3. TurboQuant 4bit-nc提供了一种极具吸引力的内存与吞吐量权衡。该变体提供了高达$3.4$倍的KV-cache容量，在大多数基准测试中仅有$1$-$4$个百分点的适度准确度退化。对于内存受限的部署场景，它特别有价值，因为突发负载下的TTFT改善超过了对所有其他指标的负面影响。但在部署前需对目标工作负载进行彻底的准确性验证。
4. 在没有彻底验证的情况下，应避免使用TurboQuant k3v4-nc和3bit-nc。这些激进的变体在具有挑战性的数学和编码基准测试中会导致高达$20$个百分点的急剧准确度下降。除了准确性外，由于复杂的反量化步骤导致的持续性能下降，也使得它们不适合生产部署。
5. 当GPU内存不是瓶颈时，请坚持使用BF16。如果工作负载使用短上下文、在低并发下运行，或者硬件具有充足的内存，BF16提供了最佳的准确性-性能权衡，且没有量化伪影的风险。