KV Cache 压缩:从“省显存”到“按思考阶段分配精度”

举报
yd_214439950 发表于 2026/11/03 00:23:04 2026/11/03
【摘要】 长推理模型把 KV Cache 从一个工程细节推成了推理系统的核心瓶颈。一个 7B 模型在 FP16 下每个 Token 的 KV Cache 大约 512 KB,长思维链加上高并发,显存会迅速被吃穿。过去两年的优化叙事主要是“压缩”——量化、驱逐、共享。但 2026 年的研究正在把这个问题重新表述得更细:KV Cache 里的 Token 不是同等重要的,压缩策略应该跟着推理的“思考阶段”...

长推理模型把 KV Cache 从一个工程细节推成了推理系统的核心瓶颈。一个 7B 模型在 FP16 下每个 Token 的 KV Cache 大约 512 KB,长思维链加上高并发,显存会迅速被吃穿。过去两年的优化叙事主要是“压缩”——量化、驱逐、共享。但 2026 年的研究正在把这个问题重新表述得更细:KV Cache 里的 Token 不是同等重要的,压缩策略应该跟着推理的“思考阶段”走。

ThinKV 的核心观察是注意力稀疏性揭示了思维链中不同类型的“思考”具有不同重要性。它不做全局统一的压缩,而是用混合的量化-驱逐策略:根据思考的重要性分配 Token 精度,随着推理轨迹推进,逐步从不太关键的思考中驱逐 Token。在 DeepSeek-R1-Distill、GPT-OSS 和 AceReason 上的实验显示,ThinKV 用不到原始 KV Cache 5% 的容量达到接近无损的准确率,推理吞吐提升最高 5.8 倍。这个结果的意义不在于“5%”这个数字,而在于它证明了压缩的粒度可以从“整个 Cache”下沉到“每一段思考”。

Agent 场景把这个问题变得更复杂。Agent 的记忆不是原始 RAG 段落,而是经过 LLM 整理的摘要、关键词和标签组成的结构化单元。每次检索都触发这些单元的一次完整重编码,prefill 延迟被反复支付。AgentKVShift 发现,每个记忆单元的 KV 复用残差可以分解为一个共享的记忆级偏移加上小的逐 Token 波动。从一个小探针集估计这个偏移,就可以用一个加权校正修正整个记忆单元里的每个复用 Token,包括那些没有被重新计算的 Token。结果是只刷新 10%—30% 的缓存就能达到接近全量重算的性能,在单张 A100 上 prefill 加速 2—3.5 倍。

这两条路线指向同一个判断:KV Cache 优化的下一层不是“压得更小”,而是“知道什么可以少算、什么必须保留”。推理模型的思考有阶段,Agent 的记忆有结构,压缩策略如果无视这些语义结构,就只能靠调低精度或粗暴驱逐来换空间,代价迟早会以准确率的形式回来。UltraQuant 在 4-bit KV 缓存上的工作则从另一个方向补充了这个判断:在上下文密集的 Agent 场景里,低精度缓存的可行性取决于量化方案是否能保留对后续推理关键的信号,而不是取决于 bit 数本身。

对做推理部署的团队来说,一个可操作的顺序是:先确认瓶颈是 prefill 还是 decode,再看 KV Cache 的占用结构——是长上下文堆出来的,还是 Agent 反复检索堆出来的——然后选择匹配结构的压缩路径。通用量化能降本,但如果不区分思考阶段和记忆结构,省下来的显存可能会以另一种方式被重新支付。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。