给大模型装一个"记忆压缩器"：WUSH-KV如何用数学方式省显存

你有没有想过，当你和ChatGPT聊了很久一段很长的对话之后，这个AI到底是怎么"记住"你前面说过的话的？

答案可能有点反直觉。它不是真的记住了，而是把每一个说过的词都变成了一组数字向量,存在显存里,随时准备拿出来用。这组被存起来的东西,业内叫它KV缓存。

**KV缓存：**大模型在生成文字时，会把每个已经处理过的词转换成两类向量，一类叫Key（键），一类叫Value（值）。这两类向量会被缓存起来，这样模型在往后生成新词时就不用重新计算前面所有词的信息，直接复用就行。

问题来了，这玩意儿会越滚越大。你跟AI聊得越久，它存的KV缓存就越多，而且这个增长是线性的,文字越长,占的显存越多。如果你是开发者,同时服务成千上万个用户的长对话,这笔显存账单会让你肉疼。

于是整个行业都在琢磨同一件事:能不能把这些缓存的数字"压缩"一下,让它们占用更少的空间，同时又不让AI变傻？

这就是这篇论文要解决的问题。研究者给出的方案叫WUSH-KV，来自奥地利科学技术研究院（ISTA）和苏黎世联邦理工学院的团队。

压缩会丢失信息，这是硬道理

把一个数字从32位浮点数压缩成2位整数，意味着原来能表示40亿种不同数值的空间，现在只剩下4种可能。这中间丢失的信息去哪儿了？变成了误差，叫做量化误差。

**量化：**把高精度的数字（比如占32个比特的浮点数）转换成低精度的数字（比如只占2个比特的整数）来节省存储空间的过程。

这就像你本来有一支能画出256种灰度的铅笔，现在只给你黑白两种颜色去画同一幅肖像。有些细节必然会消失,但如果画得巧妙,比如把阴影集中在最重要的轮廓线上，整幅画看起来依然能让人认出是谁。量化的核心难题就是这个：在信息必然损失的前提下，怎么让损失发生在"无关紧要"的地方,而不是"性命攸关"的地方。

而KV缓存里恰好存在一个很烦人的现象：**少数几个数值特别大，剩下大部分数值都很小。** 这些异常值像是房间里站着的几个巨人，会把整个量化的"刻度尺"撑得老大，结果绝大多数普通数值反而挤在刻度尺的最底端，几乎没有可用的精度去区分它们。

打个比方，如果你有一个秤，最大称重是100公斤，但你平时称的东西大多在1公斤左右，而偶尔有个10公斤的异常值出现，为了让秤不爆表，你只能把刻度拉得很粗，于是1公斤和1.2公斤在这个秤上根本看不出区别。这就是量化误差的来源:异常值绑架了整个刻度系统。

旋转一下，异常值就消失了吗？

有一类解决方案叫做变换，顾名思义，就是在量化之前，先给这组数字做一次数学上的"换基"，让它们变得更均匀，然后再量化，最后再用逆变换把它换回原来的样子。

**变换：**在量化前对数据做一次可逆的线性运算（比如矩阵乘法），让数据分布变得更适合量化，之后用逆运算还原回来。

业界比较流行的一种变换叫Hadamard变换，它的思路很简单粗暴：把所有数值混合搅拌一下，让异常值的能量分散到所有坐标上，这样就没有哪个坐标特别突出了。QuaRot和SpinQuant这类工作就是用这个思路做到了4比特量化下还能保持不错的效果。

但这篇论文的作者们发现了一个问题：Hadamard变换是"一视同仁"的，它假设所有坐标的重要性都差不多，所以均匀地打散异常值。可现实是，并非所有坐标在后续计算里的重要程度都一样。有些坐标哪怕误差很小，传到后面的计算里也会被放大很多倍；有些坐标即使误差很大，影响却微乎其微。

这就好比一个班级要重新排座位。Hadamard变换的做法是把所有学生随机打乱重新坐，确保没有哪个座位特别拥挤。但WUSH这篇论文的思路是：先搞清楚哪些学生坐在哪个位置对班级纪律影响最大（比如爱讲话的学生坐在后排影响小，坐在讲台旁边影响巨大），然后针对性地安排座位，让"影响力大"的学生坐得宽松舒适，"影响力小"的学生挤一挤也无妨。如果不这样做，继续用随机打乱的方式，那些对最终结果影响巨大的坐标依然可能被塞进刻度最粗糙的区间里，造成本可避免的性能损失。

WUSH的核心思路：既看数据本身，也看数据的"下游影响"

这篇论文建立在团队之前另一项工作WUSH之上，WUSH原本是为大模型的权重和激活值量化设计的，这次被改造用在KV缓存上。

WUSH的关键创新在于，它构造变换矩阵的时候，不只看被量化的数据自己长什么样子，还要看这个数据接下来要跟谁做矩阵乘法，对方的统计特性是什么。

论文里有一个关键公式，用两个矩阵来描述这件事:一个叫Gram矩阵，记录的是数据自身的"能量分布"；另一个叫Hessian矩阵，记录的是误差传递到下游会被放大多少。

**Gram矩阵：**衡量一组向量彼此之间相关性和能量大小的矩阵，这里用来描述被量化数据本身的统计特征。

**Hessian矩阵：**原本是描述函数曲率的数学工具，这里被用来衡量某个坐标上的小误差，经过后续计算后会被放大成多大的最终损失。

有了这两个矩阵，WUSH通过一套Cholesky分解加特征值分解的流程，算出一个最优的变换矩阵。这个变换矩阵的奇妙之处在于，它是针对"数据统计特性"和"下游敏感度"两者联合优化出来的，而不是像Hadamard那样一刀切。

论文还证明了一件挺硬核的事情：在特定假设下（比如误差近似服从均匀分布,裁剪阈值选得合理），WUSH构造出的变换在所有"敏感度均衡"的变换里几乎是最优的，而且这个最优性和数据的维度、量化比特数都没有关系。这意味着不管你的KV缓存有多大，不管你想压到多少比特，WUSH的这套理论优势都站得住脚。

Key和Value，待遇不一样

论文里有一个设计细节特别值得说一说。KV缓存里的K（键）和V（值）在注意力机制里扮演的角色完全不同，所以WUSH-KV给它们设计了不同的处理方式。

**注意力机制：**大模型里让每个词能够"关注"前面所有词、从中提取相关信息的核心计算过程。Key向量用来和当前的Query（查询）向量做匹配打分，Value向量则是真正被提取出来、加权汇总的信息内容。

Value这一路比较幸运。它的变换可以被直接"焊死"进模型的权重里，推理的时候完全不需要额外计算，是白捡的免费午餐。这是因为Value只参与一次矩阵乘法（和输出投影矩阵相乘），插入一个变换再插入它的逆变换，数学上完全可以提前把这两次变换和原来的权重矩阵合并，变成一个新的权重矩阵，模型加载进显存时就是现成的，推理阶段毫无额外开销。

Key就没有这么好运了。因为Key要先经过RoPE（旋转位置编码）处理才存入缓存，而RoPE对每个缓存位置做的旋转操作都不一样,是跟位置绑定的。研究者在附录里详细推导过：如果想把Key的变换也焊死进权重里，这个变换必须能跟RoPE这个旋转操作"交换顺序"而不改变结果，但数学推导下来发现，能够同时满足这个条件和RMS归一化约束的变换，只剩下一些毫无意义的符号翻转操作,根本没法用来重新分配数值的重要性。

打个比方，这就像给一列正在跑的火车调整座位安排。如果火车还没出发（对应权重阶段），你随便怎么调座位都行,提前焊死就行。但如果火车已经在轨道上跑着(对应RoPE之后的位置相关处理),而且每一站乘客的上下车规则都不一样,你想临时重排座位,就必须在火车运行的过程里实时操作,没法提前焊死规则。所以WUSH-KV选择把Key的变换放在RoPE处理完之后再做，接受这部分计算必须在线上进行的代价，而不是去追求一个理论上更自由但实现起来会让每个缓存位置都要单独处理的方案。

这是一种务实的权衡：用稍微增加一点在线计算量，换来一个简单、统一、不会把推理系统搞得异常复杂的缓存结构。

量化器的选择：理论最优 vs 实际效果最好

论文里还有一个挺有意思的"反差"。研究者在理论证明部分用的是QuEST量化器，这是一种对称的、基于均方根（RMS）裁剪的量化方式，数学性质干净，适合写证明。

但是到了真正要跑端到端的下游任务测试（比如做数学题、回答科学问题、写代码）时，研究者换成了另一种叫OSCAR风格的量化器，这种量化器用的是非对称的仿射量化，加上按百分位数裁剪的技巧。

**OSCAR：**另一个研究团队提出的KV缓存量化方法，使用正交变换加上百分位裁剪的仿射量化方式，这篇论文中既作为对比基准，也借用了它的量化器实现方式。

有意思的是，论文坦诚地报告了一个反直觉的发现：在局部的、逐层的误差测量上，QuEST量化器的表现其实比OSCAR风格的量化器更好,误差数值更低。但一旦放到真实的、需要模型自己生成几千个词、层层递推下去的下游任务上，OSCAR风格量化器反而赢了,有一次用QuEST量化器配合GPQA Diamond测试,AIME 2025的分数直接掉到了0%。

这说明一件挺重要的事：实验室里测得的"误差指标好看"，不代表实际跑起来模型就聪明。局部的数学最优性和一连串自回归生成之后累积的实际表现，中间隔着相当远的距离。研究者没有回避这个矛盾，而是老老实实地把这两种结果都摆出来，这种态度在我看来比强行把两个指标都说成"我们最好"要可信得多。

全精度安全区：给缓存留一道保险

除了变换和量化器，WUSH-KV还设计了一套"全精度窗口"机制,作为额外的安全垫。

具体来说，缓存的最开头几个位置（叫sink窗口，一般固定在128或者更靠前的位置）会一直保持全精度不被量化，因为注意力机制里有个已知现象，模型会把很多注意力权重"倾倒"在序列最开始的几个token上，这些位置特别敏感，一旦量化出错，影响面会很大。同时，最近生成的一段位置（叫keep窗口）也会保持全精度，因为这些刚生成的内容还在被频繁读取和参考。

剩下中间那一大段"陈年旧账"，才会被真正量化压缩，而且是攒够一批（比如8个或16个位置）才一次性量化，不是来一个就压一个，这样能减少系统层面频繁操作的开销。

这就像图书馆管理员整理书架。最新上架的几本书和镶在最显眼位置的那几本经典名著，会一直摆在最好拿、最清晰标注的区域（全精度区），不会被压缩打包进仓库。而那些已经放了很久、不常被翻阅的旧书，会被打包压缩存进地下仓库，而且管理员不会一本一本地单独打包，而是攒够一箱才统一处理一次，这样效率更高。如果不设这个安全区，直接把所有书都塞进压缩仓库，哪怕是最新最常用的那几本，一旦有人急着要用、却发现要花时间从压缩包里"解压"出来，用户体验就会直线下降。

实验结果：数字说话

论文做了三层实验来验证这套方法，层层递进。

第一层是最细粒度的层面重建误差测试，直接在Qwen3-8B这个80亿参数的模型上，对比了六种不同的变换方案:什么都不做（恒等变换）、随机正交变换、Hadamard变换、OSCAR变换、WUSH变换，以及一个加强版WUSH-A（用了更精确的注意力感知Hessian）。结果显示，在2比特量化下，WUSH和WUSH-A的几何平均误差分别是0.208和0.195，而Hadamard变换是0.325，OSCAR是0.309，差距相当明显。

第二层是WikiText-2语言模型困惑度测试，这是衡量语言模型"说话顺不顺"的经典指标，数值越低越好。在2比特量化下，WUSH-KV拿到10.51的困惑度，而OSCAR是13.74，Hadamard变换直接崩到258.29，几乎已经不能正常生成文字了。论文里解释说，这是因为第一层注意力模块的Key向量里有个异常尖锐的尖峰，集中在几乎一个坐标上，而Hadamard变换会把这个尖峰强行打散成许多个大小接近、恰好卡在量化刻度中间最模糊区域的数值，造成大面积的量化误差。

第三层是真正的下游任务测试，涵盖AIME数学竞赛题、MATH-500数学题、GPQA Diamond科学问答、LiveCodeBench代码生成，测试了4B、8B、32B三种不同规模的Qwen3模型。

模型 | 方法 | AIME 2025 | MATH-500 | GPQA Diamond | LiveCodeBench v6

Qwen3-8B | BF16原始精度 | 67.8% | 95.1% | 57.4% | 47.8%

Qwen3-8B | OSCAR | 34.4% | 89.3% | 52.9% | 20.4%

Qwen3-8B | **WUSH-KV** | **46.7%** | **92.9%** | **54.5%** | **35.2%**

在8B这个尺寸上，WUSH-KV在全部四个任务上都超过了OSCAR，有些差距还相当悬殊，比如LiveCodeBench代码生成任务上，WUSH-KV是35.2%，OSCAR只有20.4%，差了接近15个百分点。而在4B和32B模型上，两种方法互有胜负，不过WUSH-KV整体表现的稳定性更好一些，随着模型变大、任务变难，它掉分的幅度相对比较可控。

值得一提的是用来对照的那个"TurboQuant风格的纯Hadamard变换"基准，在所有模型和任务上几乎全线崩溃，很多测试里得分是0%，而且生成的token数量疯狂飙升到接近用光整个预算上限，说明模型陷入了某种卡死循环说不出有效答案的状态。这从反面印证了：仅仅依靠一个"一视同仁"地打散数值的固定变换，在2比特这种极端压缩比下是远远不够的，必须结合数据统计特性和下游敏感度做针对性优化。

长文本场景下的额外验证

除了常规的推理任务，研究者还测试了长文本检索能力，用了RULER NIAH（在超长文本里找一根"针"）和MRCR（多轮对话里精确复述某一轮内容）这两个长上下文基准。

在RULER NIAH测试里，WUSH-KV在从4k到128k token各种长度下，分数都稳稳压过OSCAR，差距在128k这个最长的场景下拉得最大，WUSH-KV是57.26%，OSCAR只有25.69%，几乎是对半砍。这说明WUSH-KV在真正考验长距离记忆精度的场景下，优势会随着文本变长而更加凸显。

MRCR这个任务对所有量化方法来说都是硬骨头，BF16原始精度的分数本身就不算高（综合AUC只有21.95），量化之后更是大幅下滑。不过在8B模型上，WUSH-KV的综合AUC是8.35，比OSCAR的4.72要高出不少，而且随着context变长（64k到128k这个区间），WUSH-KV的衰减曲线明显更平缓一些。

Q&A

Q1：WUSH-KV是什么？

A：WUSH-KV是ISTA等机构研究者提出的一种KV缓存低比特量化方法，它借助数据的统计特性和下游计算敏感度，构造出专门的数学变换，分别作用于Key和Value缓存，让2比特这样极端压缩下的大模型推理依然保持较好的生成质量。

Q2：WUSH-KV和OSCAR方法相比表现怎么样？

A：在Qwen3-8B模型上，WUSH-KV在AIME数学题、MATH-500、GPQA科学问答、LiveCodeBench代码生成这四项任务上全面超过OSCAR，LiveCodeBench上甚至领先约15个百分点。在4B和32B模型上两者互有胜负，但WUSH-KV整体表现相对更稳定。

Q3：为什么Key缓存的变换不能像Value那样直接融进模型权重？

A：因为Key要先经过RoPE位置编码处理才存入缓存，而RoPE对每个位置的旋转操作都不同，是和位置绑定的。研究者证明，能同时兼容RoPE交换规则和归一化约束的变换只剩下无意义的符号翻转，所以Key的变换必须放在RoPE之后在线计算，无法提前焊死进权重。