LowRAM以低秩键与摊销值压缩KV Cache
摘要:论文提出 LowRAM,将自回归解码中的 KV Cache 压缩拆成两条互补路径:跨层低秩压缩 Key,并通过逐头预测器从 Key 重建大部分 Value,仅保留最难预测 Token 的残差。方法在不重训模型的前提下实现约4倍近乎无损压缩,并在4倍压缩下将峰值解码吞吐最高提升5倍;与量化和淘汰策略组合后,压缩比可达26.9倍,同时保留94.5%的基线性能。其工程价值在于直接释放长上下文推理中的显存容量,但摘要仍缺少模型、任务、硬件和质量损失等关键细节。
核心思路:不再把 Key 与 Value 当作同一种缓存
LowRAM 是一种面向自回归解码的测试时 KV Cache 压缩方法。标准 Transformer 在解码阶段需要保留历史 Token 的 Key 和 Value,缓存大小随上下文长度、层数、注意力头数及 KV 维度线性增长。论文的关键观察是:同一注意力头内,Value 在很大程度上可由对应 Key 预测,而不只是依赖 Token 间、层间或特征维度的传统冗余。
基于这一观察,LowRAM 采用了非对称压缩策略:Key 走跨层低秩压缩,Value 走预测式摊销。两部分共同组成可组合的 KV Cache 压缩流水线,论文称其在三个模型家族上接近无损。
两种压缩机制如何工作
Key:跨层低秩压缩
不同层的 Key 投影存在可利用的结构相关性。LowRAM 在层间建立低秩表示,以较小的存储成本保存 Key 的主要成分。其价值在于不必让每层都持有完整高维 Key 张量,同时尽量保留注意力查询与历史键之间的匹配信息。
这种设计的关键取舍是秩数。秩越高,重建误差通常越小,但压缩率和重建开销都会下降;秩过低则可能让注意力分布发生偏移。因而实际部署需要按模型、层和上下文长度标定,而不是采用统一的压缩比例。
Value:摊销预测与残差保留
Value 摊销为每个注意力头拟合轻量预测器,从对应 Key 重建 Value。解码时,缓存中主要保存预测器及少量残差,而不是每个 Token 的完整 Value。
与对所有 Token 使用统一误差阈值不同,LowRAM 只为预测器重建效果最差的 Token 保存残差。该策略把有限存储预算集中到高误差位置,摘要报告由此获得约4倍近乎无损的 Value 压缩。
Value 预测器有两种初始化路径:
- 通过元学习获得较好的初始参数,显著降低测试时拟合造成的 Prefill 开销;
- 在允许一次性成本的场景中从头拟合,例如多查询推理。
后者可能获得更好的实例适配能力,但会增加首轮延迟和服务冷启动成本。前者更适合在线服务,却把收益转移到了训练或离线元学习阶段。
为什么压缩后解码吞吐反而提高
KV Cache 不只是存储问题,也是 Decode 阶段的访存问题。上下文越长,缓存越难装入 HBM,批量大小和并发请求数就会受到限制。
LowRAM 并不在每个解码步骤重建所有 KV 对,而是只重建当前步骤选中的子集,从而将额外计算限制在必要范围内。其收益路径可以概括为:
- 压缩后的 KV Cache 占用更少 HBM;
- 可容纳更大的 batch size 和更多并发序列;
- 每步只恢复部分 KV 对,避免重建成本吞掉显存收益;
- 峰值解码吞吐最高提升5倍。
不过,5倍并不是 KV 重建数学计算本身带来的“免费加速”,而是显存容量、并发度、访存压力和稀疏重建共同作用的结果。该数字高度依赖具体硬件、模型、批量、上下文长度和调度策略。
与量化和淘汰的组合收益
LowRAM 被设计为可与其他 KV Cache 压缩技术叠加。摘要报告,在结合量化与缓存淘汰后,压缩比达到26.9倍,长上下文任务仍保留基线性能的94.5%。
这种可组合性有实际意义:低秩或预测压缩主要消除结构冗余,量化降低数值位宽,淘汰则直接删除低价值 Token,三者优化的对象并不相同。
但26.9倍不能被简单理解为“整体质量只损失5.5%”。性能损失高度依赖任务。长上下文检索、精确引用、多跳推理和代码生成对少量关键 Token 的丢失可能比对语言建模困惑度更敏感。此外,量化误差、预测误差和淘汰误差可能叠加,论文摘要也没有说明三者组合时的误差是否独立。
工程权衡与适用边界
优势
- 无需重新训练目标模型,适合现有推理服务栈;
- 直接针对 Decode 阶段的 KV Cache 内存墙;
- 可以提升批处理规模与并发解码吞吐;
- 能与量化、淘汰等现有方法组合;
- Key 与 Value 分离处理,避免仅依赖统一数值精度压缩。
成本与风险
- 预测器拟合和元学习会增加系统复杂度与冷启动成本;
- 每步重建部分 KV 对会引入额外算子、内存访问和调度开销;
- 极端压缩下可能丢失长上下文中的关键证据;
- 论文仅在三个模型家族上测试,跨模型架构、位置编码和注意力实现的泛化仍待确认;
- 摘要未披露压缩后的质量指标、硬件配置、batch size、Prefill 时间、端到端延迟及与具体基线的公平设置。
因此,26.9倍更适合作为研究上限,而非可直接用于生产的默认配置。
开发者落地建议
在接入生产推理服务前,建议先建立完整的 KV Cache 预算模型,同时记录缓存字节数、Prefill 延迟、Decode 延迟、tokens/s、并发数和任务质量。测试应至少覆盖短上下文、目标上下文和超长上下文,并同时观察首 token 延迟与稳态吞吐。
部署时可采用分层策略:先用 Value 摊销处理主要冗余,再用跨层低秩压缩 Key,最后按实际收益决定是否叠加量化和淘汰。对于高召回任务,应优先保留关键 Token,而不是为了压缩比执行激进的全局淘汰。
此外,应验证预测器是否需要在线适配。允许一次性拟合的离线批处理或固定流量场景,可能更适合从头训练预测器;高并发在线服务则更需要验证元学习初始化能否把冷启动成本压到可接受范围。
评测仍需回答的问题
论文摘要给出了有吸引力的压缩与吞吐数字,但尚不足以判断部署价值。后续需要公开三类证据:第一,不同压缩比例下的任务质量曲线,而非单一汇总分数;第二,峰值吞吐对应的具体 batch size、序列长度和硬件;第三,量化、淘汰和预测重建叠加后的误差传播。
LowRAM 的真正贡献,是把 KV Cache 压缩从单一的数值精度问题,扩展为“Key 的结构共享加 Value 的条件可预测性”这一联合建模问题。这使其有望成为长上下文推理基础设施的一层优化,但也需要更多独立复现来确认收益能否从受控实验迁移到真实服务负载。
—— 完 ——消息来源:ArXiv Machine Learning (cs.LG) (2026-11-06)
主题标签: #KV Cache #低秩压缩 #注意力推理 #显存优化 #大模型推理
编辑部与事实核查说明:本篇专刊由智客前沿资讯管线根据官方技术公告、学术论文及开源工程文档整理编译,经算法实体核验与人工编辑审校后发布。若发现技术事实纰漏,欢迎依据勘误方针或一键向编辑部发送勘误反馈。
社区整体评论区