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时下降,可能是因为我们量化的时间点(即实时量化每个令牌而不是分块量化),而不是量化本身永远无法工作。
相似文章
我在 16GB 显存下测试了 Qwen3.8 27B 的 21 种模型/KV 量化组合(189 项基准测试)的 KLD
一项社区基准测试评估了 21 种能在 16GB 显存内运行的 Qwen3.8 27B 模型/KV 量化组合(189 项基准测试),发现 q5_1/q5_1 通常是最优选择,而提高模型量化级别(q4_0/q4_0)优于在完整 f16 KV 缓存下使用更低的量化级别。
@sakurayukiai: 通过计算推测模型的KV缓存字节数(而非将其隐藏在平坦的显存缓冲中),Unsloth将Qwen…
Unsloth通过精确计算推测模型的KV缓存字节数(而非使用平坦的显存缓冲),将Qwen3.6-27B Q6_K在单张32GB显卡上的上下文长度从23K提升至64K。
您可以将Qwen3.8-Flash-Next模型的大部分KV缓存卸载到RAM中,而不会明显影响解码速度。 在使用8bit量化的Qwen3.8-Flash-Next模型时,KV缓存大小约为每token 12.5MB。通过将大部分KV缓存从显存移至RAM,并只在显存中保留少量热数据,可以显著扩大显存能够支持的上下文长度。这种混合存储方式仅会增加约1.2ms的延迟,对实际推理速度影响微乎其微,为处理超长上下文提供了一种高效且低成本的解决方案。
演示了将Qwen3.8-Flash-Next模型的KV缓存卸载至系统内存的技术,通过利用该模型高效架构,可在最大程度减少解码速度下降的情况下支持长上下文推理。
你们是对的 - 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通常过于夸张。包含分析和数据,见链接文章。