Qwen3.8-27b q8 KV缓存似乎确实损害模型性能
摘要
本文讨论了基于Qwen3.8-27B的实验,如何实时KV缓存量化因累积误差而降低长上下文模型的性能。
我经常看到的一个争论是是否使用KV缓存量化。我常见的观点是q8应该是无代价的/几乎无损的(对于模型权重来说通常是这样)。但根据我进行的一些实验,它实际上并非如此,原因比<量化损失精度>更奇怪一些。基本上,这是因为大多数后端,例如llama.cpp,在写入时进行KV量化。当KV在写入时被量化,每个后续的预填充步骤都会读取量化后的键。所以,尽管8位量化实际上只是低于1%的舍入误差,但它不是一次性应用的1%误差——因此,它在每一层都从略微错误的注意力到略微错误的键累积误差,并影响接下来写入的键。在我的测试中:在bf16下通过的针检索在125k长度下使用q8-on-write失败。然而!!问题实际上不是q8本身——当我取一个在bf16下构建的缓存,并一次性将其全部量化为q8时,误差真的只是1%,并且工作正常,针检索恢复。*注意事项:这仅基于我对一个模型家族(Qwen3.8-27B)的测试,试验次数较少,一些更激进的实验在我的略显怪异的自定义MLX堆栈上运行。但这种机制似乎可能具有普遍性。--- 总结:如果您的长上下文质量在使用量化KV时下降,可能是因为我们量化的时间点(即实时量化每个令牌而不是分块量化),而不是量化本身永远无法工作。
相似文章
@sakurayukiai: 通过计算推测模型的KV缓存字节数(而非将其隐藏在平坦的显存缓冲中),Unsloth将Qwen…
Unsloth通过精确计算推测模型的KV缓存字节数(而非使用平坦的显存缓冲),将Qwen3.6-27B Q6_K在单张32GB显卡上的上下文长度从23K提升至64K。
你们是对的 - Qwen 3.6 35B 确实不错...而且 KV 缓存确实重要。
一位用户分享了自己的发现:Qwen 3.6 35B 在智能体任务中优于 27B 模型,并将差异主要归因于 KV 缓存压缩质量。他们还从 LM Studio 切换到了 llama.cpp 以更好地管理上下文。
这是我的KV缓存量化基准测试:TurboQuant被高估但被TCQ拯救,q5值得更多关注,对称q8可能浪费显存
一项详细的基准测试,使用PPL和KLD指标在Qwen 3.6 27B上比较KV缓存量化方法(TurboQuant、TCQ、q4、q5、q8),发现TCQ改进了低位量化,不对称KV在相同大小下优于对称KV,且q8通常过于夸张。包含分析和数据,见链接文章。
大家忽略了 Qwen 3.8 27B Q2 + Q2 DFlash + Q5 KV 的实力
一位用户分享了使用 QAT Q2 和 Q5 KV 运行量化版 Qwen 3.8 27B 模型的经验,在 12GB 显卡上实现了高达 200K token 上下文的高性能,性能超越了 Sonnet 4.6 等模型。
我绘制了Qwen3.6-35B-A3B和Gemma4-E2B QAT模型的KV缓存量化的KL散度图
作者绘制了Qwen3.6-35B-A3B和Gemma4-E2B QAT模型的KV缓存量化的KL散度图。