论文综述：Grouped Value Attention——用按需重建 Key 的方式给 KV 缓存瘦身

一、论文是干什么的？

大语言模型在和你聊天、帮你写代码的时候,并不是把之前说过的每句话都重新读一遍再回答下一个字,而是把之前每个词计算出来的两组”中间结果”——技术上叫 Key（键）和 Value（值）——存进一块叫作 KV 缓存 的显存里,后面每生成一个新词,都直接去翻这些缓存,而不用重新计算。这个机制大大加快了生成速度,但也带来一个新麻烦：对话或文档越长,缓存里存的东西就越多,显存很快就会被占满,能同时服务的用户数量、能处理的上下文长度都会因此受限。

你可以把 KV 缓存类比成”做笔记”：与其把一整堂课的每一句话都逐字记下来（那样笔记本很快就写满了）,不如学会一种更聪明的记法——只记关键词（Value）,等到真正要用的时候,再用一套固定的”展开规则”把关键词现场还原成完整的句子（Key）。这样笔记本（也就是显存）就能省下差不多一半的空间,而复习（生成新词）时的效果基本不受影响。这篇论文提出的 Grouped Value Attention（分组值注意力,简称 GVA）,做的正是这件事：它不再把 Key 和 Value 都存进缓存,而是只存(分组后的)Value,需要 Key 的时候用一个提前学好的线性映射”现场重建”出来,由此把 KV 缓存的体积压缩了约 45% 到 47%,同时在下游任务上的准确率几乎不掉。

二、核心方法与创新

要理解 GVA 的创新,需要先简单回顾一下它要改进的两种主流方案。

背景：MHA、GQA、MLA 都在解决同一个问题

最早的多头注意力（Multi-Head Attention, MHA）里,每一个注意力头（可以理解成模型内部并行工作的多个”小侦探”,各自从不同角度关注上下文）都拥有自己独立的一套 Key 和 Value,如果模型一共有 $H$ 个头,缓存里就要存 $H$ 份 Key 加 $H$ 份 Value,一共 $2H$ 条数据流。分组查询注意力（Grouped-Query Attention, GQA）的做法是让多个头共享同一组 Key 和 Value,把头数从 $H$ 分成 $G$ 组（ $G$ 远小于 $H$ ）,缓存量降到 $2G$ 条数据流,这也是目前很多主流大模型采用的方案。DeepSeek 提出的多头潜在注意力（Multi-Head Latent Attention, MLA）则走了另一条路：把 Key 和 Value 都压缩进一个低维的”潜在向量”,缓存的是这个更小的潜在表示,需要时再展开。

GQA 虽然把头数分了组,但每一步依然要同时存一份 Key 和一份 Value,论文认为这里还有压缩空间：既然同一组内的 Key 和 Value 本身就存在某种对应关系,那能不能干脆只存 Value,Key 靠”算”出来,而不是”存”出来？

GVA 的核心思路：只存 Value,Key 靠学出来的映射现场重建

GVA 的做法是：对于分到第 $g(h)$ 组的注意力头 $h$ ,缓存里只保留这一组的 Value（记作 $V_{g(h)}$ ）,当需要该头的 Key 时,用一个该头专属、且提前训练学好的线性映射矩阵 $M_h$ 现场算出来：

$K_h = V_{g(h)} M_h, \quad h = 1, \dots, H$

也就是说,虽然一共只缓存了 $G$ 组 Value,但因为每个头的映射矩阵 $M_h$ 是各不相同的,GVA 依然能为全部 $H$ 个头分别重建出各不相同的 Key,这一点比 GQA（同一组内的头连 Key 都完全共享,没有差异）保留了更多”头的个性”。这就像是几名侦探（注意力头）共用同一份原始线索卡片（Value）,但每个人都有自己独门的解读方法（ $M_h$ ）,能从同一张卡片里读出不同的重点（Key）。

关键技巧：把映射矩阵”吸收”进 Query,避免真的把 Key 算出来

如果每一步真的都先用 $M_h$ 把 Key 计算出来,再和 Query 做点积,那其实并没有省计算量,只是把存储的负担换了个地方。论文的巧妙之处在于利用矩阵乘法的结合律,把这一步计算重新分组：

原本的注意力打分是 $q_h k_{j,h}^\top = q_h (v_{j,g(h)} M_h)^\top$ ,通过结合律可以改写成：

$q_h (v_{j,g(h)} M_h)^\top = (q_h M_h^\top) v_{j,g(h)}^\top = \tilde{q}_h v_{j,g(h)}^\top$

也就是说,可以先把 Query 和映射矩阵的转置相乘,得到一个新的”合并后的 Query” $\tilde{q}_h = q_h M_h^\top$ ,这一步在每次解码时只需要算一次（因为 Query 本身每步只有一个新词）,算完之后,注意力打分就直接是这个新 Query 和缓存里 Value 的点积,全程都不需要把 Key 张量真的构造出来。这个技巧被称为把线性映射”吸收”（absorb）进了 Query,是 GVA 能够真正省下计算和存储、而不是只挪移负担的关键设计。

解耦 RoPE 通道：位置信息单独处理

现代大模型大多用旋转位置编码（RoPE, Rotary Position Embedding）给 Key 和 Query 注入位置信息,但 RoPE 本质上是对向量做旋转变换,这种旋转操作和”吸收进 Query”的矩阵乘法在数学上不能直接兼容——如果 Key 里也混入了旋转分量,前面 absorb 的技巧就会失效。为了解决这个矛盾,GVA 借鉴了 MLA 的思路,把 Query 和 Key 都拆分成两部分：一部分是宽度为 $d_n$ 的”无旋转内容切片”,专门用来做前面说的按需重建；另一部分是宽度为 $d_r$ 的”共享旋转位置切片”,所有头共用同一份,单独缓存,负责携带位置信息：

$K_j^{\mathrm{nope}} = v_{j,g(h)} M_h, \qquad K_j^{\mathrm{rope}} = (x_j W_r) R_j^\top$

最终的注意力打分是这两部分的和：

$q k_j^\top = q^{\mathrm{nope}} (k_j^{\mathrm{nope}})^\top + q^{\mathrm{rope}} (k_j^{\mathrm{rope}})^\top$

第一项延续了前面”吸收进 Query”的思路,不需要真正生成 Key;第二项则老老实实缓存一份很窄（ $d_r=16$ 或 $24$ ）的位置 Key,负责传递”这是第几个词”这类信息。论文中把这份共享的位置 Key 记作 $k^{\mathrm{rope}}$ 。

三种方案的缓存对比

论文用一张表格总结了 MHA、GQA、GVA 在”每层能重建出多少种不同 Key""实际缓存了多少条数据流”上的差异：

方法	不同的内容 Key 数量	实际缓存的数据流数
MHA	$H$	$2H$
GQA	$G$	$2G$
GVA	$H$ （重建出来的）	$G$ （Value）+ 共享的位置 Key

可以看到,GVA 用和 GQA 差不多规模的缓存开销（ $G$ 组 Value 加一份很窄的共享位置 Key）,却能重建出和 MHA 一样多、一样各不相同的 $H$ 种内容 Key,这正是论文标题里”On-Demand Key Reconstruction（按需重建 Key）“的含义。

三、使用了哪些模型和计算资源？

论文中明确提到的实验设置是：从零开始训练一个 3.5 亿（350M）参数规模 的仅解码器（decoder-only）Transformer 模型,使用 300 亿（30B）token 的 FineWeb-Edu 数据集进行训练,并对每种配置用三个不同的随机种子各跑一次,取各任务准确率的平均值来降低随机波动的影响。

以下信息论文中没有明确说明,原文没有给出具体数值：

具体的模型架构参数,如层数（number of layers）、隐藏维度（hidden size）、注意力头总数 $H$ 、分组数 $G$ 、每头维度 $d_h$ 等,都没有在正文中列出精确数字。
使用了什么型号、什么数量的 GPU,论文全文未提及。
30B token 的训练具体耗费了多长时间,论文也未给出。
论文没有”致谢（Acknowledgments）“部分,因此也没有从中找到计算资源来源的线索。

论文提到已经开发了自定义的解码 kernel（用于加速实际推理的底层计算代码）,并正在评估其端到端推理性能,但具体的 kernel 设计细节（如使用了什么框架、针对什么硬件优化）论文中同样没有公开,只说明”计划不久后开源发布”。作者团队来自 FrontiersMind,在 HuggingFace 上有一个对应的仓库页面（FrontiersMind/GVA）,但目前该页面只是论文信息的展示,并未包含模型权重或训练、推理代码。

四、实验结果

论文摘要中给出的核心对比数字是：在 350M 参数规模、30B FineWeb-Edu token 训练的设置下,采用 16 维位置通道（即 $d_r=16$ ）的 GVA 变体在五个下游任务上的平均准确率为 44.18%,非常接近 GQA 的 44.36%,并高于 MLA 的 43.88%。这五个任务分别是：HellaSwag（常识推理续写）、WinoGrande（代词指代消歧）、OpenBookQA（开卷式科学常识问答）、ARC-Easy 和 ARC-Challenge（分别是简单和较难的科学选择题）。

论文正文的详细结果表（Table 2）里,各方法在五个任务上的具体分数如下：

方法	HellaSwag	WinoGrande	OpenBookQA	ARC-Easy	ARC-Challenge	平均
GQA（基线）	43.41	52.48	33.40	63.42	29.09	44.36
MLA	43.20	51.61	34.60	62.87	27.13	43.88
GVA（基础版本）	42.12	52.96	34.80	61.95	27.73	43.91
GVA + 解耦 RoPE（ $d_r=24$ ）	42.94	53.12	33.20	63.69	28.50	44.29
GVA + 解耦 RoPE（ $d_r=16$ ）	42.69	53.35	33.60	63.81	28.32	44.35

需要如实说明一处细节：正文表格里 $d_r=16$ 这一行按五个任务分数直接平均得到的数字是 44.35,但论文摘要里给出的对应结论是 44.18,两处数字略有出入（相差约 0.17 个百分点）,论文中没有对此做特别说明,推测可能与摘要撰写和正文表格分属不同修订版本、或统计口径（比如是否在更多随机种子上取平均）有关。为避免误导读者,这里如实列出两个来源的原始数字,不做主观取舍。

不论具体是 44.18 还是 44.35,论文传达的结论是一致的：GVA 用明显更小的缓存,换来了几乎不打折的准确率,而且比同样走”压缩缓存”路线的 MLA 效果更好。

关于缓存缩减比例的计算,论文给出的公式是 GVA 缓存量与 GQA 缓存量之比：

$\frac{N_{\mathrm{GVA}}}{N_{\mathrm{GQA}}} = \frac{1}{2} + \frac{d_r}{2 G d_h}$

其中 $d_r$ 是共享位置通道的宽度, $G$ 是分组数, $d_h$ 是每个头的维度。当 $d_r$ 相对 $G d_h$ 很小时,这个比值会非常接近 $\frac{1}{2}$ ,也就是说 GVA 的缓存大致只有 GQA 的一半左右（对应约 50% 的缩减）;加上共享位置通道占用的少量额外空间后,论文测算出的实际缩减幅度落在约 45% 到 47% 之间。需要特别说明的是,这个 45% 到 47% 是理论上按数据量计数得到的静态缓存大小缩减,并不是在真实推理系统里实测出来的显存占用或速度提升数字——论文自己也承认,融合解码的吞吐量、峰值服务显存、批处理容量这些更贴近实际部署的指标”未在本文中报告”。

五、潜在应用与已落地应用

潜在应用方向：

更省显存的大模型推理服务：KV 缓存是长上下文、多用户并发场景下显存占用的大头,GVA 这类缓存压缩技术如果能在更大规模模型上验证有效,理论上可以让同样的硬件服务更多用户,或支持更长的上下文窗口。
和 MLA 类思路互补/竞争的技术路线：GVA 与 DeepSeek 的 MLA 都在解决”如何压缩 KV 缓存”这个问题,但实现思路不同（一个是按需重建 Key,一个是压缩进低维潜在向量）,未来两条路线可能会相互借鉴,或者被用于不同的模型架构中。
自定义解码 kernel 的推广：如果论文承诺的开源自定义解码 kernel 能顺利发布并证明确实能带来端到端的推理加速,可能会被推理框架（如 vLLM、SGLang 等）借鉴或集成。

已落地应用情况：

目前没有查到 GVA 已经被应用于任何已发布的商业模型或产品。论文本身处于”实验验证阶段”：只在 350M 这样偏小的模型规模上做了验证,尚未在更大规模（比如数十亿甚至百亿参数）的模型上进行测试;作者也在论文中明确说明代码开源”计划不久后发布”,截至综述撰写时（2026 年 9 月 18 日）尚未查到实际的代码仓库。HuggingFace 上的 FrontiersMind/GVA 页面目前也只是论文信息展示,不含可运行的模型或代码。

六、网络上的讨论与评价

由于这篇论文发布时间较新（2026 年 9 月 8 日提交,9 月 15 日更新到第二版）,网络上的深入讨论还比较有限,搜索未能找到 Reddit、Hacker News 等平台上的专门讨论帖,HuggingFace 论文页面下方目前也没有查到社区评论。找到的两处相关讨论如下：

一个名为 jjakimoto/research-issues 的 GitHub 自动化论文追踪项目在 2026 年 9 月 16 日创建了一条 issue（#1557）,对这篇论文做了总结,内容与论文摘要基本一致,并特别指出”45% 到 47% 的缓存节省是理论层面的计数,不是实际吞吐量或峰值内存的测量结果”,提醒读者不要把这个数字直接等同于实际推理速度的提升。
科技资讯站点 CCTest 发表的一篇文章将 GVA 定位为”一个有前景的缓存表示设计”,而非”已经完全验证、可以直接拿来用的加速方案”。文章认可其在降低缓存存储上的效果和有竞争力的准确率,但也指出核心待解决问题：缓存标量数量的减少并不自动等于解码速度更快,论文中的自定义解码 kernel 仍在评估阶段,尚未发布开源版本。文章还提出三个值得关注的后续问题：这一方法能否在更大规模模型上保持优势、能否把缓存流量的节省真正转化为推理延迟的降低,以及在效果、显存和计算量之间应该如何权衡。

整体来看,现有的网络讨论对这篇论文的态度是”方法思路有意思、方向对,但工程验证（尤其是真实推理速度和大模型规模下的效果）还需要时间检验”,尚未形成大规模、广泛传播的社区热议。

七、思维导图

mindmap
  root((Grouped Value Attention 论文核心概念))
    研究背景与问题
      KV缓存显存瓶颈：随序列长度线性增长，读取带宽限制解码速度
      现有方案局限
        MHA：2H条缓存流，无压缩
        GQA：2G条缓存流，仍需同存Key与Value
        MLA：压缩至低维潜在向量，需额外展开
      核心挑战：能否只存Value、按需重建Key且不增加计算量
    方法与技术贡献（GVA机制）
      GVA核心公式：K_h等于V_g(h)乘以M_h
        M_h维度为d_h乘以d_n，每头专属可学习映射矩阵
      Absorption吸收技巧：矩阵结合律将M_h吸收进Query，避免物化Key张量
      解耦RoPE Decoupled RoPE
        nope切片：K_nope等于v_j,g(h)乘以M_h，宽度d_n，按需重建
        rope切片：K_rope等于x_j乘W_r再乘R_j转置，宽度d_r=16或24，共享缓存
        总打分为nope项与rope项之和
      与GQA MLA缓存对比：G组Value加共享位置Key，重建出H种不同Key
    实验设计与结果
      训练配置：350M参数decoder-only Transformer，30B FineWeb-Edu tokens，三随机种子取平均
      Baseline与GVA变体
        GQA、MLA两个基线
        GVA baseline无解耦RoPE：平均43.91
        GVA scale-matched加Q-norm：44.41，GVA变体中最高，与GQA相当
        GVA加DRoPE位置通道16/24维：44.35/44.29
      五项基准与关键结果：HellaSwag、WinoGrande、OpenBookQA、ARC-Easy、ARC-Challenge；GQA 44.36、MLA 43.88、GVA加DRoPE位置通道16维摘要44.18、正文均值44.35
      缓存缩减公式：N_GVA除N_GQA等于二分之一加d_r除以2Gd_h，理论缩减约45%到47%
    理论分析与局限
      为什么有效：同组Value与Key存在可学习线性映射，结合律使吸收无损
      RoPE兼容性：解耦设计避开旋转变换与线性吸收的数学冲突
      局限性：仅在350M规模验证，解码kernel性能未实测，端到端延迟与显存未报告
    影响与展望
      潜在应用：长上下文省显存推理服务，与MLA互补的KV压缩路线
      未来方向：更大规模验证，端到端速度与显存实测，开源代码与kernel发布