一篇 ICML 2026 论文把 Transformer 注意力层里一个默认设计重新拎了出来：Query、Key、Value 三个投影，真的都要独立吗？
论文《Do Transformers Need Three Projections?》的答案不激进。它没有说三投影可以一刀砍掉。它说的是，在 300M 和 1.2B 参数语言模型上，让 K 和 V 共享投影，可以用约 3.1% 的困惑度退化，换来 50% 的 KV cache 降幅。
这件事的看点不在“推翻 Transformer”。真正的账在推理侧。长上下文一拉长，KV cache 会很快吃掉显存或统一内存。对手机、PC NPU、边缘盒子这类设备来说，少存一半 KV，可能比再压一点权重更接近痛点。
论文做了什么：不是只砍 K-V，而是系统比较三种共享
论文评估了三类 QKV 投影共享约束。为了避免误读，Q-K=V 指的是 Q 保持独立，K 与 V 共享；Q=K-V 指的是 Q 与 K 共享，V 保持独立；Q=K=V 则是三者全共享。
实验覆盖合成任务、视觉任务，以及 300M/1.2B 参数语言模型。语言模型训练规模为 10B tokens。这个范围不算小，但也不能直接外推到 7B、13B 或更大的部署模型。
| 方案 | 共享方式 | 主要变化 | 论文中的倾向 |
|---|---|---|---|
| Q-K=V | K 与 V 共享，Q 独立 | KV cache 减少 50% | 语言建模退化较小 |
| Q=K-V | Q 与 K 共享，V 独立 | 注意力方向性受影响 | 风险更高 |
| Q=K=V | Q、K、V 全共享 | 约束最强，参数和缓存更省 | 更容易损伤能力 |
这张表的重点不是“哪个最省”。省得越狠，约束越强。Transformer 里的 Q、K、V 不是三块随便复制的线性层，它们分别参与匹配、索引和信息读取。
论文也尝试用 2D 位置编码缓解 Q=K-V、Q=K=V 带来的对称注意力问题。这个细节很关键：作者并不是简单删矩阵，而是在拆分不同投影到底承担什么功能。
我的判断是，K-V 共享能跑出来，说明 K 和 V 的独立性可能没有我们默认想的那么“神圣”。但 Q 和 K 不能随便绑死。查询和键是匹配关系的两端，一旦共享，注意力方向性就容易被破坏。
关键结果：K-V 共享省的是 KV cache，不是白送速度
语言建模实验里，Q-K=V 带来 50% KV cache reduction，困惑度退化约 3.1%。这要按“有代价的内存优化”理解。
它不是无损压缩。也不能写成推理速度提升 50%。
端到端速度还要看算子实现、批大小、上下文长度、内存带宽和调度框架。KV cache 少了，显存压力会下降；但吞吐和延迟能不能同步改善，要靠工程栈接住。
更有工程意味的是叠加能力。论文称，Q-K=V 可以与 GQA/MQA 叠加：结合 GQA-4 可达到 87.5% cache reduction，结合 MQA 可达到 96.9%。
| 路线 | 压缩对象 | 改动位置 | 对工程团队的含义 |
|---|---|---|---|
| GQA/MQA | 减少 K/V 头数 | 架构与推理框架已有较多支持 | 更接近现成路线 |
| Q-K=V | 合并 K/V 投影 | 需要训练期引入约束 | 适合做新模型或重训实验 |
| Q-K=V + GQA/MQA | 头数和投影同时压 | 约束叠加 | cache 降幅最大，但更要测能力损失 |
这和已有推理优化路线能接上。Llama 2 70B、Llama 3 等模型已经采用 GQA 来降低长上下文推理成本，MQA/GQA 也进入 TensorRT-LLM、vLLM 等推理优化语境。
Q-K=V 的位置更像第二层压缩：GQA/MQA 是“少存一些头”，K-V 共享是“每个位置少存一类投影结果”。两者不是替代关系，更像能否叠加的问题。
对大模型推理优化工程师来说，这篇论文最直接的动作不是立刻迁移，而是加一组实验：同参数量、同训练 token、同上下文长度下，对比标准 QKV、GQA/MQA、Q-K=V、二者叠加。指标也不能只看 perplexity，还要看真实设备上的峰值内存、prefill/decode 延迟和吞吐。
对关注 Transformer 架构压缩的研究者，它给了一个更细的切口：不要只问“能不能少参数”，还要问“哪些中间状态必须缓存，哪些状态可以结构化合并”。这比单纯剪枝或量化更贴近长上下文推理的瓶颈。
边界在哪里：它是实验选项，不是新默认架构
论文给出的解释是，K 和 V 可能处在相近表征空间，注意力计算也常呈现低秩特性。所以 K-V 共享未必会伤筋动骨。
但这个解释还不足以变成工程定论。语言模型只报告到 300M 和 1.2B 参数，训练规模是 10B tokens。今天很多实际部署模型已经到 7B、13B，甚至更大。规模上去之后，退化是否仍然只有约 3.1%，目前看不清。
还要看任务形态。论文覆盖了合成任务、视觉任务和语言建模，但端侧助手常常还要经过指令微调、对齐、长上下文扩展和工具调用适配。K-V 共享在这些环节后是否稳定，不能从当前数字直接推出。
对端侧模型团队，比较现实的做法是延后把它当成默认配置，但可以提前放进新模型训练方案。尤其是卡在 8GB 或 16GB 统一内存边缘的本地助手，KV cache 少一半可能决定能不能保留更长上下文。
采购或产品决策也要克制。不要因为看到 50%、87.5%、96.9% 这些 cache reduction 数字，就假设设备规格可以等比例下调。总显存还包括权重、激活、运行时开销和系统占用。cache 降了，不等于整机内存需求同幅下降。
接下来最该看三件事。
- 放大到 7B 以上后，困惑度和下游任务退化是否仍可接受。
- 长上下文、指令微调、多轮对话后，K-V 共享是否还稳。
- 推理框架能否把 cache 降幅变成真实吞吐、延迟或可部署性收益。
所以，这篇论文更像把一块旧木板敲开了一条缝。三投影不是不能动，但也不是哪里省就往哪里砍。省一刀之前，要先确认这一刀砍的是冗余，不是能力。