这是我的KV缓存量化基准测试：TurboQuant被高估但被TCQ拯救，q5值得更多关注，对称q8可能浪费显存

来自前TurboQuant最大捍卫者的问候，现在是中等规模、有细分领域意识的TurboQuant捍卫者。今天我将向您展示我使用单张RTX 3090通过[BeeLlama v0.1.2](https://github.com/Anbeeld/beellama.cpp)深入探索PPL和KLD基准测试世界的结果，并附带一些背景故事：我曾尝试其他测试但未成功，随后更彻底地重新探索了PPL和KLD以作补偿。测试使用Qwen 3.6 27B（`Q5_K_S`和`IQ4_XS`），上下文长度为64k和128k——一个不错的模型、不错的量化、不错的上下文长度。基本上就是我们这些24GB显存用户实际使用的配置，因此结果真实可信。我并非要抨击[vLLM研究](https://vllm.ai/blog/2026-05-11-turboquant)，但它对我来说就像一本“如果你已经有100万美元，如何投资致富”的书，对比中缺少了常规的4位和5位量化。以下是我的发现： * **PPL隐藏尾部，KLD暴露尾部。** 在`q4_0`中，整个PPL范围保持在`bf16`以上0.01以内。即使是`turbo3_tcq`也只增加了约0.02 PPL。但99.9%的KL散度则讲述了不同的故事：虽然`q5_0`（占`bf16`的34.4%）明显落后于`q8_0`，但仍不算差。但随后`q4_0`的尾部KLD比`q5_0`差了32%。这就是破坏你的工具调用和JSON结构的原因。 * **旋转在4位上缩小了差距。** llama.cpp在量化前已对KV向量应用随机旋转，这与TurboQuant使用的基本技巧相同。在4位上，`turbo4`相对于`q4_0`没有质量优势，几乎不节省内存，且运行速度慢17%。TurboQuant的价值在于2-3位，反正那里也没有其他选择。 * **TCQ拯救了低端。** `turbo3_tcq`始终优于普通的`turbo3`，`turbo2_tcq`也远优于`turbo2`。对于需要激进压缩的情况，它们是合法的解决方案。你可能会问，TCQ是什么？幸运的是，文章也涵盖了这个内容！ * **不对称KV在相同大小下优于对称KV。** `q5_0/q4_0`的内存与`q4_1/q4_1`相同，但在所有测试配置中，99.9%精度均胜出。当K达到`q5_0`后，下一个有用的比特应分配给V，而不是`q5_1` K。 * **更高的模型精度意味着更大的缓存损伤。** 在相同的缓存量化下，`Q5_K_S`比`IQ4_XS`多承受3-5%的99.9%精度损失。模型和KV缓存量化并非独立，更好的做法是平衡它们的量化，而不是只关注其中之一，因为它们都从同一显存池中分配。 * **q8基本上属于奢侈级别，除非你有富余显存。** `q8_0/q5_0`占`bf16` KV的43.8%，在不同配置下保持93.7-98.2%的99.9%精度，因此完整的`q8_0/q8_0`占53.1%主要用于验证，前提是你已经不再为显存发愁。 **这里是文章，包含所有数据和大量分析：** [https://anbeeld.com/articles/kv-cache-quantization-benchmarks-for-long-context](https://anbeeld.com/articles/kv-cache-quantization-benchmarks-for-long-context)