LLM近期重大架构进化一览：从Gemma 4到DeepSeek V4|deepseek|key|上下文|卷积|新论文

机器之心编辑部

过去一段时间，很多人对大模型都有一个明显感受：token 总是不够用

毕竟用户想大模型更「聪明」更连贯，上下文窗口只会越来越大。

而在模型背后，长上下文是相当「奢侈」的。用户 token 消耗翻倍，其实是模型更大的 KV cache 和更高的 attention 计算成本。

尤其是在推理模型和 Agent 逐渐成为主流后，长上下文已经从一个「宣传亮点」，逐渐转变为大模型架构设计需要正面解决的问题。

Sebastian 精准地捕捉到，最近几个月发布的一批 LLM，正好体现了这个趋势。

从 Google 的 Gemma 4，到 Poolside 的 Laguna XS.2、Zyphra 的 ZAYA1-8B，再到 DeepSeek V4，这些模型在 Transformer 内部做了各种「省钱设计」，试图围绕长上下文推理降低计算和存储成本

Sebastian 为此发布了技术博客，以下为博客链接与全文翻译。

近期 LLM 一览。

博客标题：LLM 架构的最新发展：KV 共享、mHC 与压缩注意力
博客链接：https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures

Gemma 4：

通过跨层复用 KV Tensor 缩小 KV Cache

时间回到四月初，Google 发布了全新的开源权重模型系列 Gemma 4。整个系列大致可以分为三类：

面向移动端与小型本地（嵌入式）设备（即 IoT）的 Gemma 4 E2B 与 E4B；
面向高效本地推理、采用混合专家架构（MoE）的 Gemma 4 26B；
以及采用 Dense 架构、追求更高模型质量与更便捷后训练流程的 Gemma 4 31B（因为 MoE 模型通常更难进行后训练和调优）。

Gemma 4 架构示意图

Gemma 4 E2B 与 E4B 的第一个小型架构改动，是采用了「共享 KV Cache」机制：后续层会复用前面层已经计算出的 Key-Value 状态，从而降低长上下文场景下的显存占用与计算成本。

这种方法并不是 Gemma 4 首创。例如 NeurIPS 2024 的论文《Reducing Transformer Key-Value Cache Size with Cross-Layer Attention》已经提出类似思路。但 Gemma 4 是第一次将其大规模应用于主流开源架构中。

为什么 KV Cache 如此重要？

正如我最近几个月不断提到的，当前 LLM 架构设计中的一个核心主题，就是「缩小 KV Cache」。而缩小 KV Cache 的根本目的，是降低模型运行所需的显存占用，从而支持更长的上下文窗口。这一点在推理模型和 Agent 时代尤其重要。

举一个经典的例子（Gemma 4 目前依然在使用）：Grouped Query Attention（GQA）本身就已经通过让多个 Query Head 共享同一组 Key-Value（KV）Head，来减少 KV Cache 的大小，如下图所示。

Gemma 4 的跨层 KV 共享机制

如前所述，Gemma 4 使用了 GQA。不过，除了 GQA 中不同 Query Head 之间的 KV 共享之外，Gemma 4 还进一步在不同 Transformer Layer 之间共享 KV Projection，而不是像传统做法那样，在每一层 Attention 模块中分别计算自己的 KV

这种 KV 共享机制也被称为 Cross-Layer Attention，其结构如下图所示。

正如架构示意图中所提到的，Gemma 4 E2B 采用了普通 GQA 与 Sliding Window Attention 按照 4:1 的方式组合使用。（更准确地说，Gemma 4 E2B 实际使用的是 MQA，也就是 GQA 中只有一个 KV Head 的特殊情况。）

在 GQA（或 MQA）机制下，KV 共享的方式如下：后续层不再单独计算自己的 Key 和 Value Projection，而是直接复用最近一个、同类型且未共享层所生成的 KV Tensor。

换句话说：Sliding Window Attention 层会复用前面某个 Sliding Window 层的 KV， Full Attention 层则会复用前面某个 Full Attention 层的 KV。

当然，每一层仍然会计算自己的 Query Projection，因此不同层依然可以形成各自不同的 Attention Pattern；但代价最高、最占显存的 KV Cache，则会被多个层共同复用。例如：

Gemma 4 E2B 一共有 35 层 Transformer Layer，但只有前 15 层会真正计算自己的 KV Projection；后面的 20 层则直接复用之前同类型层的 KV Tensor。
类似地，Gemma 4 E4B 共 42 层，其中 24 层负责计算 KV，最后 18 层采用共享机制。

这种设计到底能节省多少资源？

由于大约有一半的 KV 在不同层之间被共享，因此 KV Cache 的整体大小也大致减少了一半。对于最小的 E2B 模型来说，在 128K 长上下文、bfloat16 精度下，可以节省约2.7GB显存；而 E4B 在同样条件下，则大约能够节省6GB

Gemma 4 E2B 类似配置中，GQA 与跨层 KV 共享带来的 KV Cache 显存节省效果

当然，KV Sharing 的缺点在于，它本质上是一种对完整 Attention 计算的「近似」。更准确地说，它会削弱模型容量。

不过，根据 Cross-Layer Attention 论文中的实验结果，在被测试的小规模模型上，这种影响可以非常有限。

Gemma 4 E2B / E4B：

Per-Layer Embeddings（PLE）与「有效参数量」

Gemma 4 的 E2B 与 E4B 版本还引入了第二种以效率为导向的设计：Per-Layer Embeddings（PLE，逐层嵌入）。这一机制与前面提到的 KV Sharing 是相互独立的。

KV Sharing 的目标是缩小 KV Cache，而 PLE 关注的则是参数效率（parameter efficiency）：它让小尺寸的 Gemma 4 模型能够携带更多 token-specific information（与 token 相关的特征信息），但又不会让整个 Transformer 主干像同参数量 Dense 模型那样昂贵。

例如，Gemma 4 E2B 与 E4B 中的「E」，代表的就是「effective」（有效参数量）。具体来说：

Gemma 4 E2B 标注为 2.3B effective parameters，但如果把 embedding 参数也算进去，总参数量实际上达到 5.1B；
Gemma 4 E4B 的 effective parameters 为 4.5B，而包含 embedding 后则约为 8B。

换句话说，在这些「E」系列模型中，真正负责主要计算的 Transformer Stack，其计算规模更接近前面的较小数字；而后面的总参数量，则包含了额外的 embedding table。

从概念上来看，PLE 的结构大致如下：

带有 PLE residual path 的简化版 Gemma 4 Block。普通 Transformer Block 会先完成 Attention 与 Feed-Forward 的 residual update；随后，生成的 hidden state 会作为 gating 信号，控制 layer-specific 的 PLE vector，并在 Block 末尾额外加入一次 projected PLE residual update。

PLE Vector 本身是在 Transformer Block 外部提前构建的。简单来说，它有两个输入来源：token ID 经过 per-layer embedding lookup；普通 token embedding 再通过一个 linear projection，映射到同一个 PLE 空间。

随后，这两部分结果会被相加、缩放，并 reshape 成一个 tensor，其中每一层都对应一个独立 slice，而每个 Transformer Block 只会接收属于自己的那一份。

简化版 PLE（Per-Layer Embeddings）构建流程

这里有一个很重要的细节：PLE 并不是给每个 Transformer Block 单独复制一整套 embedding layer。相反，per-layer embedding lookup 只会计算一次，然后再给每一层分发一个较小的 token-specific embedding slice。

因此，对于每个输入 token，Gemma 4 会提前准备一个 packed PLE tensor，其中包含每一层 decoder 对应的一小段 embedding vector。

真正进入 Transformer Block 后，Attention 与 Feed-Forward 分支仍然按正常方式运行。在完成 Feed-Forward residual update 后，当前 hidden state（图中记作 z）会用于 gate layer-specific PLE vector。被 gate 后的 PLE vector 会重新投影回 model hidden size、做 normalization，并作为额外 residual update 加回模型中。

一个比较直观的理解方式是 Transformer Block 的主体结构并没有改变，Gemma 4 只是额外在 Feed-Forward 分支后面，插入了一小段「层特定 token 向量」。这样做能够通过 embedding 参数与小规模 projection，提升模型的表达能力，同时避免把整个 Transformer Stack 都扩展到更大的参数规模。

为什么要用 PLE？

一种更直接的方法，其实是简单缩小 Dense 模型，比如减少层数、缩小 hidden state 或缩小 Feed-Forward Network。

这样当然能降低显存与延迟，但也会直接削弱模型真正负责计算的核心部分。

而 PLE 的思路则是：让昂贵的 Transformer Block 保持在较小的「effective size」，同时把额外容量存储在 per-layer embedding table 中。由于 embedding 本质上主要是 lookup-style parameter，它们远比增加 Attention 或 FFN 权重更便宜，也更容易缓存。

当然，目前我们还只能相信 Google 的实验结果，认为这确实是一个有效的设计。作者也提到，未来如果能看到更多对比实验，例如：PLE 版 Gemma 4 E2B vs 普通 2.3B Dense 模型 vs 普通 5.1B Dense 模型。

这样的对比会非常有意思。

此外，从理论上讲，PLE 并不只适用于小模型。更大的模型同样可以加入 per-layer embedding slice。但由于大模型本身已经具有足够容量，因此这些额外 embedding 的收益可能不再明显。而且在大模型中，我们通常已经通过 MoE 等结构，在不显著增加计算量的前提下提升模型容量。

Laguna XS.2：

Layer-wise Attention Budgeting

Laguna 是欧洲公司 Poolside 推出的首个 open-weight 模型，Poolside 主要专注于面向代码场景的 LLM 训练。

不同 Layer 使用不同 Attention Budget。

下图中的 Laguna XS.2 架构乍一看其实相当标准。不过，有一个我没有画进去（或者说没法硬塞进图里）的细节，是一个可以称为「Layer-wise attention budgeting」的概念。

Poolside 的 Laguna XS.2 架构示意图。

这里所谓 attention budgeting 的核心思路之一，是不再让每个 Transformer Layer 都拥有完全相同的 Attention 预算，而是根据层的不同，动态分配不同的 Attention 成本

Laguna XS.2 总共有 40 层，其中 30 层使用 Sliding-Window Attention，10 层使用 Global / Full Attention。

和常见做法一样，Sliding-Window Layer 只会关注局部窗口（这里是 512 个 token），因此 KV Cache 与 Attention 计算成本都更低；而 Global Layer 虽然更昂贵，但能够保留对整个上下文窗口中所有信息的访问能力。

这种 Sliding-Window Attention 与 Global / Full Attention 混合使用的结构，并不是 Laguna XS.2 独有的，很多其他模型（包括 Gemma 4）也采用了类似设计。

但真正新的地方在于：Laguna XS.2 引入了「逐层不同 Query Head 数量」的设计。

例如，在 Hugging Face 的 config.json 中，可以看到一个名为 num_attention_heads_per_layer 的配置项，这意味着不同 Layer 可以拥有不同数量的 Query Head，同时仍然保持 KV Cache 结构兼容。

Laguna 中的逐层 Query-Head Budgeting。其中 Full Attention Layer 每个 KV Head 对应 6 个 Query Head； Sliding Window Attention Layer 每个 KV Head 对应 8 个 Query Head。

因此，Laguna XS.2 的实际做法是：给 Sliding-Window Layer 分配更多 Query Head，给 Global Layer 分配更少 Query Head，同时将 KV Head 数固定为 8

这才是真正意义上的「Layer-wise Head Budgeting」。

Laguna XS.2 是近期 open model 中最具代表性的逐层 Query-Head Budgeting 实践之一。不过，更广义上的「按层动态分配模型容量」这一思路，其实至少可以追溯到 Apple 在 2024 年提出的 OpenELM。

为什么这样设计？

和 KV Sharing 类似，它的核心目标依然是：把 Attention Capacity 花在最值得的地方，而不是让所有 Layer 平均分配相同预算

具体来说，Full Attention Layer 因为需要访问整个上下文窗口，本身计算代价就更高，因此 Laguna 会相对减少它们的 Query Head 数量；而计算成本更低的 Sliding-Window Layer，则可以拥有更多 Query Head。

（此外，还有一个较小的实现细节：Laguna 还采用了 per-head attention-output gating，这一点与 Qwen3-Next 等模型有些类似。不过由于我之前已经讨论过类似机制，因此这里不再展开。）

ZAYA1-8B：压缩卷积注意力（CCA）

和 Laguna 类似，ZAYA1-8B 也是一位新玩家。它由 Zyphra 开发，而这次发布中一个很有意思的细节是：该模型并不是基于更常见的 NVIDIA GPU（或 Google TPU）训练，而是使用 AMD GPU 完成训练的。

不过，真正关键的架构设计，是一种名为Compressed Convolutional Attention（CCA，压缩卷积注意力）的机制，并且它与 Grouped-Query Attention（GQA）共同使用。

与 MLA（Multi-head Latent Attention）这类主要把 latent representation 当作紧凑 KV Cache 格式的设计不同，CCA 会直接在压缩后的 latent space 中完成 Attention 计算。不过这一点我们后面再详细展开。

（顺带一提：ZAYA1-8B 的 config.json 中实际上列出了 80 个交替出现的 layer entry，而不是传统意义上的 40 个 Transformer Block。这些 layer 在结构上会在 CCA/GQA Attention 与 MoE Feed-Forward Layer 之间交替出现。不过在架构图里，把它们简化理解成 40 个重复的「Attention + MoE」 Pair 会更直观，两种表示在概念上是等价的。）

采用 Compressed Convolutional Attention 的 ZAYA1（8B）Transformer Block。

正如上图所示，ZAYA1-8B 采用了 CCA，并结合了 4:1 的 GQA 结构。这里最关键的一点在于：它的 Attention Block 是围绕 CCA 构建的，而不是传统的 Sliding-Window Attention。

什么是 Compressed Convolutional Attention（CCA）？

我认为，从整体思路上来看，CCA 与 DeepSeek 模型中的 MLA（Multi-head Latent Attention）是相近的，因为它们都在 Attention Block 中引入了压缩后的 latent representation。不过，两者使用 latent space 的方式并不相同。

MLA 的核心目标，主要是通过 latent representation 来压缩 KV Cache。在 MLA 中，KV Tensor 会以压缩形式存储，随后再被投影回 Attention Head 空间，用于真正的 Attention 计算。

普通 Multi-head Attention（MHA）与 Multi-head Latent Attention（MLA）对比。

而 CCA 则更进一步，它不仅压缩 K、V，还同时压缩 Q，并且直接在压缩后的 latent space 中完成 Attention 运算。也正因为如此，CCA 不仅能够减少 KV Cache 的大小，还能够降低 Prefill 阶段与训练阶段的 Attention FLOPs。

MLA 与 CCA 的结构对比。

正如上图所示的，在 CCA 中，压缩后的 latent representation 会直接进入 Attention 机制，而生成出的 compressed attention vector 随后再被 up-project 回原始空间。

为什么叫「卷积注意力」？

这里需要特别注意：它被称为「Compressed Convolutional Attention」，而不仅仅是「Compressed Attention」，是因为在 latent K 与 latent Q 上，还额外加入了 convolutional mixing（卷积混合）

由于结构图中空间有限，没有把这一部分画出来，但它本身其实并不复杂。正如 Figure 12 所暗示的，卷积混合是直接作用在压缩后的 Q Tensor 与 K Tensor 上的。

原因在于压缩会让 Q、K、V 维度变窄，从而降低计算量与缓存开销，但与此同时，也可能削弱 Attention 的表达能力。

而卷积则是一种相对廉价的方法，它能够在 Q 与 K 被用于 Attention Score 计算之前，为这些压缩后的表示补充更多局部上下文信息。

（这里的卷积只作用于 Q 与 K，而不作用于 V。因为 Q 与 K 决定的是 Attention Score，而 V 则代表最终被加权聚合的内容。）

Sequence-Mixing Convolution 的概念示意图。

除了前文中展示的 Sequence Mixing 外，CCA 还包含一个 Channel Mixing Component。不过它们在原理上较为类似，因此这里不再单独展开。

CCA 看起来是 Zyphra 在 ZAYA1-8B Technical Report 发布之前就已经提出的一种 Attention 机制。独立论文《Compressed Convolutional Attention: Efficient Attention in a Compressed Latent Space》最早发表于 2025 年 10 月，并正式提出了 CCA；而 ZAYA1-8B 则将这一机制作为核心架构组件之一实际投入使用。

CCA 是否真的比 MLA 更好？

根据 CCA 论文中的实验结果，在相同压缩设置下，CCA 的表现确实优于 MLA。

CCA 论文中的实验结果标注图。

总体来说，这部分真正有意思的地方，其实是新的 Attention 机制本身。

当然，ZAYA1-8B 同时也采用了相当激进（也就是非常稀疏）的 MoE 结构：每个 token 只激活一个 routed expert。不过这一点相对已经比较常见。

真正更特殊的是 CCA，它直接在压缩 latent space 中执行 Attention 计算，并通过对压缩后的 Q/K 做卷积混合，来缓解压缩 Attention 本身表达能力受限的问题。

简而言之，ZAYA1-8B 不只是想在 Feed-Forward Layer 上节省计算量，它甚至试图从 Attention Mechanism 本身开始降低计算成本。

DeepSeek V4：mHC 与压缩注意力

DeepSeek V4 是今年最受关注的大模型之一。有意思的是，如果按照 active-parameter share（活跃参数占比）来衡量，DeepSeek V4-Pro 同时也是参数最稀疏的 MoE 模型。

关于 DeepSeek V4，其实有很多可以讨论的内容。不过由于它已经在新闻与社区中被广泛讨论，同时为了继续聚焦「架构层面的改动」，这里我主要关注两个相较以往架构真正新的部分：

用于扩展 Residual Path 的 mHC；
用于长上下文 Attention 压缩与稀疏化的 CSA/HCA。

从下图中的 DeepSeek V4 架构图来看，整个结构似乎非常复杂。不过，一个比较有效的阅读方式是将 Residual Path 上的改动（mHC），与 Attention Path 上的改动（CSA/HCA 与 Compressed Attention Cache）分开理解。

DeepSeek V4-Pro 架构概览。

5.1 mHC：流形约束超连接

我们先从 DeepSeek V4 中的 mHC 组件开始。

这一设计最早来自 DeepSeek 团队在去年（2025 年 12 月 31 日）发布的一篇研究论文《mHC: Manifold-Constrained Hyper-Connections》。不过，当时论文中的实验只在一个 27B 规模的实验模型上完成。而如今，我们已经在他们的旗舰模型中看到了这一机制，这也意味着，这一想法很可能已经在真实生产环境中被验证有效。

mHC 的核心目标，是重新设计 Transformer Block 内部的 Residual Connection。这一点其实非常新鲜，因为近年来绝大多数架构改动，通常都集中在Attention Mechanism、Normalization Layer 的放置方式与MoE 结构本身。

mHC 本身建立在更早的 Hyper-Connections 工作之上（见 Zhu 等人 2024 年论文《Hyper-connections》），因此我们需要先简单理解一下 Hyper-Connections。

传统 Transformer 中，只有一条单独的 Residual Stream。而 Hyper-Connections 会把它替换成：多条并行 Residual Stream，并通过可学习映射（learned mappings）在它们之间交换信息。

Hyper-Connections 的核心思想，是「扩宽 Residual Stream」。

可以把它理解为模型同时维护多条并行 Residual Path，并额外加入一个 Res Mapping 线性变换，在不同 Residual Stream 之间进行信息混合

由于 Attention Layer 或 MoE Layer 本身仍然工作在普通 Hidden Size 上，因此 Hyper-Connections 还会增加：

Pre Mapping：把多条 Residual Stream 合并成单一 Hidden Vector；
Post Mapping：再把 Layer 输出重新分发回多个 Residual Stream。

普通 Transformer Block（上）与带 Hyper-Connections 的 Transformer Block（下）。

上图主要展示了 Attention Branch 中的结构，但同样的思想也适用于围绕 MoE Layer 的第二条 Residual Branch。

Hyper-Connections 的目的，是在不真正扩大 Attention 或 MoE Layer 本身宽度的情况下，让 Residual Path 拥有更强表达能力。

而它带来的 FLOPs 增长其实很有限，因为这些额外映射只作用在较小的 residual-stream 维度上（例如 DeepSeek V4 中 n=4），而不是作用在巨大的 hidden dimension 上。

在最初的 Hyper-Connections 论文中，7B OLMo MoE 模型的 FLOPs per token 从 13.36G 增加到 13.38G，几乎没有变化；而性能指标则获得了稳定但温和的提升。

当然，只看 FLOPs 其实有些过于简单。因为扩宽后的 Residual State 依然需要存储、在显存中移动并参与混合计算。因此，真正的额外开销更多可能来自Memory Traffic 与 Implementation Complexity，而不仅仅是算术计算本身。

不过考虑到 DeepSeek V4 整体都在追求效率，这看起来依然是一个值得加入的设计。

Hyper-Connections 相较 Baseline 的性能表现。

传统 Transformer 只有单一 residual stream。而 Hyper-Connections 将其扩展成多个并行 residual stream。

此外，如图所示：Hyper-Connections 在大约只使用一半训练 token的情况下，就达到了 Baseline 的性能水平。

而从普通 Hyper-Connections（HC）到 Manifold-Constrained Hyper-Connections（mHC）最关键的变化，在于这些 Mapping 不再是「无约束」的。

在普通 HC 中，Res Mapping 是一个可学习矩阵，用于混合不同 Residual Stream。但当多个这样的矩阵不断堆叠时，信号可能会不可预测地被放大或缩小。

而在 mHC 中，这个 Residual Mapping 会被约束到「双随机矩阵（doubly stochastic matrix）」流形上。也就是说：所有元素非负；每一行之和为 1；每一列之和为 1。

这样一来：Residual Mixing 会更像是一种稳定的信息重新分配（stable redistribution），而不是不可控的信号放大或衰减。

与此同时 Pre Mapping 与 Post Mapping 也同样会被约束为非负且有界，从而避免在读取与写回扩宽 Residual State 时出现信息抵消。

简而言之，mHC 保留了 HC 更丰富的 Residual Mixing 能力，同时加入额外约束，使其在更大、更深的模型中能够更稳定地扩展。

除此之外，多 Residual Stream 的整体思路并没有改变，如下图所示。

采用 HC 与 mHC 的 Transformer Block。

在 mHC 论文中，DeepSeek 团队基于 27B 模型实验表明：在使用融合优化（fusion）、重计算（recomputation）与 pipeline scheduling 后，即使在整个 Transformer 中使用 4 条 Residual Stream（n=4），训练时间额外开销也仅增加约 6.7%。

总结来说：HC/mHC 的本质，是通过把单一 Residual Stream 替换为多条相互交互的 Residual Stream，重新定义信息在 Transformer Layer 中的传播方式。mHC 则进一步加入稳定性约束，同时只带来很小的计算额外开销

此外，它也与后面将介绍的 CSA/HCA Attention 改动形成了很好的配合。

通过 CSA 与 HCA 实现压缩 Attention

DeepSeek V4 的另一项核心架构升级，发生在 Attention 部分。其背后的动机依然非常明确：在超长上下文场景下，Attention 的成本不仅来自 Attention Score 本身的计算，还来自 KV Cache 会随着 Sequence Length 持续增长。

DeepSeek V4 针对这一问题，引入了两种压缩 Attention 机制的混合设计：

Compressed Sparse Attention（CSA）
Heavily Compressed Attention（HCA）

首先需要注意的是：DeepSeek V4 中的 CSA/HCA，与 DeepSeek V2/V3 中 MLA 风格的压缩并不是同一种思路。

MLA 的压缩对象主要是「每个 token 对应的 KV 表示」，而 CSA/HCA 压缩的则是「Sequence Dimension 本身」。

也就是说，它们不再为每个历史 token 都保留一个完整（或压缩）KV Entry，而是把一组 token 汇总成更少的压缩 KV Entry，因此整个 Cache 本身也变短了。

MLA、CSA 与 HCA 的概念对比。

MLA 会压缩每个 token 的 KV Representation，但依然保留「一 token 对应一个 latent KV」。而 CSA，尤其是 HCA，则进一步减少「Sequence Entry 的数量」

因此模型会牺牲部分 token-level 信息，以换取显著更低的长上下文成本。

当然，这种压缩也存在质量上的 Trade-off：如果压缩过强，模型能力就可能下降。

也正因如此，DeepSeek V4 并没有只依赖一种压缩机制，而是：交替使用 CSA 与 HCA

CSA 使用较轻的压缩率，并结合类似 DSA（DeepSeek Sparse Attention）的 Sparse Selector；
HCA 则采用更激进的压缩，用于更便宜地覆盖全局上下文；
两者都保留了一个 Local Sliding-Window Branch，用于处理最近的未压缩 token。

HCA 是其中更激进的版本：它会把每 128 个 token 压缩成一个 KV Entry，然后在这些高度压缩后的 KV 上执行 Dense Attention。

换句话说，CSA 保留更多细节，但采用 Sparse Selection； HCA 保留更少 Entry，但因此能够负担 Dense Attention

CSA 与 HCA 的对比。

CSA 与 HCA 在某种程度上是互补的，这也是为什么 DeepSeek V4 会交替使用它们，而不是只采用其中一种。

根据 DeepSeek V4 论文，在 1M Token Context 下，相比采用 MLA 与 DSA 的 DeepSeek V3.2：DeepSeek V4-Pro 的单 token 推理 FLOPs 仅为后者的 27%，KV Cache 大小仅为后者的 10%。

而 DeepSeek V4-Flash 更进一步：FLOPs 降至 10%，KV Cache 降至 7%。

DeepSeek V4 相较 DeepSeek V3.2 的 1M Context 效率数据。

不过，我并不会简单地把 CSA/HCA 定义为「比 MLA 更好」。CSA/HCA 本质上是一种更激进、更偏向长上下文效率的设计，而且它本身也更加复杂。

遗憾的是，论文中并没有提供完整的 Ablation Study。不过整体来看，论文确实展示了非常强的最终结果，例如：DeepSeek V4-Flash-Base 在多数 Base Benchmark 上超过 DeepSeek V3.2-Base；同时拥有很强的 1M-token Retrieval 能力。

但需要注意的是，这些结果来自整个 DeepSeek V4 完整训练体系，包括：更好的数据、基于 Muon 的优化、mHC、精度与存储优化以及训练推理系统优化；

而不仅仅是 CSA/HCA 本身。就我个人而言，目前我更倾向于把 CSA/HCA 看作：

一种以效率为核心的长上下文设计。它似乎能够在大型旗舰模型中很好地保留模型质量，但并不意味着它在所有场景下都绝对优于 MLA。

总结

2026 年的新一代开源 LLM，一个非常明显的趋势是：大家都在尝试降低长上下文成本，但并不是简单地通过缩小模型总参数量来实现，而是通过大量结构级优化。