我们现在就能在 llama-server 里用 Google 的 TurboQuant(TQ)压缩 KV Cache 吗?还是还得等 PR?
摘要
社区讨论:Google TurboQuant 压缩是否已可用于 llama-server 的 KV cache,还是仍在等待实现。
大家好!
自打 Google 公布 [TurboQuant](https://www.google.com/url?sa=E&q=https%3A%2F%2Fresearch.google%2Fblog%2Fturboquant-redefining-ai-efficiency-with-extreme-compression%2F) 以来,我就一直关注它“极端压缩却几乎不掉质量”的能力。这个名词在版里被反复提起,可看了这么多讨论,我还是有点懵:它到底能不能现在就给我们用?如果能,该怎么用?
最近看到一篇文章/帖子,有人直接把 TQ 量化用在了**模型权重**上。结果 Qwen3.5-27B 在接近 Q4_0 的质量下体积缩小了约 10%,终于能舒服地塞进 16 GB 显存(楼主用的是 RTX 5060 Ti)。这对消费级显卡来说简直是福音。
然而,TurboQuant 最初被大肆宣传的重点是“上下文与内存效率”,于是我的核心疑问就落在 **KV Cache** 上——毕竟真正吃掉显存的往往是上下文长度。
所以想问:
1. 目前能不能在 llama-server(llama.cpp)里把 TQ 量化应用到 KV cache?
2. 如果可以,要怎么开?有没有类似 `--cache-type q4_0` / `--cache-type q8_0` 的 CLI 参数?
3. 还是说现在只能用于模型权重,KV cache 还得等 llama.cpp 官方发 PR/新版本?
如果有人实测过或者了解开发进度,求分享!谢谢!
相似文章
动态KV缓存量化与按需加载mmproj/MTP:我的llama.cpp愿望清单
一位开发者已为llama.cpp实现了一个概念验证的PR,通过HTTP端点添加了动态KV缓存量化功能,允许用户按需重新量化其KV缓存,而无需完全重新加载模型。该帖子还概述了一个愿望清单,包括按需加载mmproj/MTP交换以及用于上下文优化的自动--fit标志。
这是我的KV缓存量化基准测试:TurboQuant被高估但被TCQ拯救,q5值得更多关注,对称q8可能浪费显存
一项详细的基准测试,使用PPL和KLD指标在Qwen 3.6 27B上比较KV缓存量化方法(TurboQuant、TCQ、q4、q5、q8),发现TCQ改进了低位量化,不对称KV在相同大小下优于对称KV,且q8通常过于夸张。包含分析和数据,见链接文章。
[llama.cpp] 非对称 KV q8/q4 缓存:当前注意事项及 GGML 仓库中的讨论
讨论了在 llama.cpp 中使用非对称 KV 缓存量化时的注意事项,其中不匹配的 q8/q4 类型会导致提示处理在 CPU 而非 GPU 上进行,并提出了通过编译标志进行修复的方案。
CompressKV:语义检索引导的KV缓存压缩方法,用于资源高效的长上下文大语言模型推理
CompressKV针对基于GQA的大语言模型,提出了一种语义检索引导的KV缓存压缩方法,通过识别语义检索头来保留关键令牌。在LongBench任务中,仅使用3%的KV缓存即可实现超过97%的全缓存性能。
受 TurboQuant 启发的 KV 缓存量化方案的统计推断与质量评估
本文分析了受 TurboQuant 启发的 KV 缓存量化方案,利用统计推断和新的 6D 误差框架来评估 KL 散度、几何误差等质量指标。