DeepSeek-V4 模型结构（3）：序列维度（下），HCA、混合排布与零件
内容提要
本文详解DeepSeek-V4模型结构：HCA将128个token压缩为一条目，无需稀疏选择；CSA与HCA交错排布，确保全局信息不丢失；滑窗分支弥补压缩导致近token不可见；Q/KV归一化替代QK-Clip；部分RoPE加输出反旋转消除绝对位置；attention sink解决softmax权重分配缺陷；1M上下文KV cache仅5.3GiB，FLOPs约38G。
延伸解读
HCA与CSA的互补设计
HCA将128个token压缩为一条目，无稀疏选择，确保全局信息不丢失；CSA每4个token压缩并选top-k，实现精读。两者交错排布，每两层至少有一层能覆盖全局，避免因indexer误判导致信息遗漏。这种设计类似于Kimi K3的混合注意力，但V4的两种注意力均基于softmax且有KV cache，区别在于粒度。
滑窗分支的必要性
压缩导致query无法看到当前块内的token，HCA下最近的127个token可能完全不可见，而语言建模中近token至关重要。因此，CSA和HCA均增加滑窗分支，每个query额外查看最近128个未压缩token的KV，与压缩条目在同一softmax中计算，而非分开加权。Flash版本前两层甚至仅用滑窗，凸显其重要性。
位置编码的精细处理
V4采用部分RoPE，仅对最后64维施加旋转，并利用RoPE的乘法性质对输出进行反向旋转，消除绝对位置影响，使输出仅依赖相对距离。压缩条目的位置取块首token，且压缩在无位置表示上进行。压缩层使用θ=160000并配合YaRN扩展至1M，而滑窗层θ=10000且无YaRN，因仅需处理128个token。
KV cache与FLOPs的显著优化
1M上下文时，V4-Pro的KV cache约5.3GiB，仅为GQA-8基线的2%，约为V3.2的12%；Flash版本约3.7GiB。核心注意力FLOPs约38G，得益于HCA的高压缩率（128:1）和CSA的稀疏选择，大幅降低计算量。相比V3.2，V4将indexer的查询长度除以4、层数减半，显著减少开销。
Q&A
DeepSeek-V4中的HCA（Heavily Compressed Attention）是如何工作的？为什么它不需要稀疏选择？
HCA将每128个token压缩成一个KV条目，且不重叠。在1M上下文下，压缩后仅产生8192个条目，因此每个query可以查看所有压缩条目，无需像CSA那样通过indexer进行稀疏选择。
为什么DeepSeek-V4要交错使用CSA和HCA？
CSA是精读，每个query只看1024个块，可能因indexer误判而遗漏重要信息；HCA是粗读，每个query查看全部历史的粗粒度摘要，确保全局信息不丢失。两者交错，每两层中总有一层能保证全局信息的完整性。
DeepSeek-V4中的滑窗分支有什么作用？为什么必须有它？
压缩导致query无法看到自己所在块及最近的token（HCA下最多127个token不可见），而语言建模中最近的token至关重要。滑窗分支让每个query额外查看最近128个token的未压缩KV，弥补压缩带来的近token信息丢失。
DeepSeek-V4如何解决K=V导致输出带有绝对位置的问题？
由于K=V且K经过RoPE旋转，注意力输出中每个v_j都带有绝对位置R_j。V4对输出施加反向旋转R_{-t}，利用RoPE的乘法性质，使输出变为R_{j-t}v_j，从而只依赖相对位置，消除绝对位置的影响。
DeepSeek-V4中的attention sink机制是什么？它解决了什么问题？
Attention sink为每个注意力头增加一个可学习的logit z'_h，只加入softmax分母而不加入分子，相当于一个value为零的虚拟条目。它解决了softmax权重必须和为1的结构性缺陷，当query与所有条目都不相关时，模型无需将注意力分配给无关token，输出可接近零。
DeepSeek-V4在1M上下文下的KV cache和FLOPs大概是多少？
KV cache：Pro版本约5.3 GiB，Flash版本约3.7 GiB。FLOPs：核心注意力每token每层约38 GFLOP（61层合计），加上CSA的indexer打分约30层×4.3 GFLOP。
DeepSeek-V4为什么不需要QK-Clip？
V4对query和KV都进行了RMSNorm，将logit的尺度结构性地限制住，防止其爆炸。而Muon优化器会使权重矩阵快速增长，Kimi K2使用QK-Clip事后压范数，V4则通过归一化从根源上避免，因此无需QK-Clip。
