DeepSeek V4 1-Flash 架构拆解：CED、CSA2、Engram、mHC 与 DSp

整理日期：2026-09-16。问题起点：DeepSeek 4.1 的模型结构发生了什么变化？这些变化为什么会直接穿透到推理系统？ 本文优先采用 DeepSeek 官方发布、技术报告及 vLLM/vLLM-Ascend 的公开实现与 Roadmap；工程状态按 2026-09-16 记录，后续可能变化。

核心结论：V4.1-Flash 不是“把 V4 放大或微调”，而是在 计算路径、KV 所有权、稀疏检索、低比特缓存与外部记忆 上共同重构。理解它时，不能只看 Attention 公式，而要同时问：每层存什么、谁拥有状态、下一层复用什么、P/D 边界要传什么。

1. 先建立事实基线

DeepSeek 于 2026-09-10 发布 DeepSeek-V4.1-Flash。官方将其描述为新架构系列中的较小型号，具有原生视觉理解；语言主体是 552B 参数 MoE，采用新的 Causal Encoder–Decoder（CED） 结构，输入阶段约激活 8B 参数，输出阶段约激活 16B。官方同时给出一个非常重要的 serving 结果：相对上一代，KV Cache 的 HBM 占用约为 1/4，SSD 持久化占用约为 1/8。DeepSeek 官方发布

Hugging Face 仓库的模型元数据显示架构标识为 deepseek_v41，仓库总参数统计约 763B。公开技术资料通常把 552B backbone 与约 196B Engram conditional memory 分开描述，因此学习时应区分“backbone 参数”“外部条件记忆参数”“每 token 激活参数”，不要把它们混成一个模型规模口径。Hugging Face 模型仓库

2. CED：从对称 decoder-only 走向输入/输出非对称

V4.1 的关键结构变化之一是 Causal Encoder–Decoder。技术报告所述语言 backbone 为 40 个 causal Transformer 层，可理解为前 20 层承担 causal encoder，后 20 层承担 decoder。这里的 encoder 不是传统 T5/BERT 式双向编码器，而仍保持因果约束。

传统 decoder-only 推理可以粗略抽象为：

for layer in layers:
    x = attention(x, kv_cache[layer])
    x = moe(x)

每一层通常拥有自己的 KV 状态。CED 改变了这个隐含假设：decoder 的 global memory 可以由 encoder 末端表示投影并跨层使用，导致 Prefill 与 Decode 的执行图天然不对称。

这解释了为什么官方分别给出 8B input-active 与 16B output-active：输入 token 和生成 token 不再沿完全相同的计算路径。对 Infra 的第一层启示是：以后不能默认“Prefill 只是 Decode 的批量版本”。

3. CSA2：从“每层一份 KV”变成跨层共享的状态图

Compressed Sparse Attention 2（CSA2）进一步改变 KV Cache 的组织方式。公开技术报告和上游实现将 attention layer 划分为 Full、Reindex、Reuse 三类静态模式：

模式	主要职责	Infra 含义
Full	建立 compressed KV / indexer 状态并执行稀疏选择	成为物理 cache owner
Reindex	复用已有 KV，但重新计算索引/候选	KV 与 index metadata 生命周期分离
Reuse	复用 KV，同时复用已有候选或 Top-K 选择	出现跨层 alias / dependency

因此缓存关系不再是 Layer i -> KV[i]，而更像：

KV owner layer
   ├─ compressed global KV
   ├─ indexer K / scale
   └─ candidate / Top-K metadata
          │
          ├─ consumer layer A
          ├─ consumer layer B
          └─ consumer layer C

这件事非常重要：KV Cache Manager 从数组管理器逐渐变成带所有权与依赖关系的状态图管理器。

技术报告给出的 global KV footprint 约为 890 bytes/token，相对 V4-Flash 约缩小到 1/4。它来自跨层共享、序列压缩以及 FP4 main KV 等机制的组合，而不是单一量化技巧。DeepSeek V4.1 Technical Report

4. Global KV + Sliding Window：两类状态具有不同生命周期

V4.1 并非只剩一份极小的 global KV。每层还保留局部 Sliding Window Attention（公开资料给出的窗口为 128 token）状态。于是一次请求至少存在两类语义不同的缓存：

Global compressed state：面向长上下文、跨层共享、需要长期复用。
Local SWA state：只覆盖最近窗口，容量有限，但与当前激活序列强相关。

这为后面的 SWA Bounded Replay 奠定了基础：不一定值得把短生命周期 local KV 一直持久化到 SSD；在缓存命中后，可以通过重算最近一个窗口来恢复 local state。

5. Bounded Replay：用小规模重算换长期存储

传统 prefix cache 思路常隐含“命中时把所有必要状态都保存下来”。V4.1 给出另一种工程取舍：

长期保存：global compressed state
不长期保存：部分 local SWA state
cache hit：重放最近 N 个 token，重建 local state

其本质类似系统中的 checkpoint + replay。这说明 LLM serving 正在从“所有状态物化”走向“物化 + 可重建状态”的混合策略。

适用条件是：重放窗口必须有严格上界，而且重算成本显著低于长期存储、SSD IO 与跨节点搬运成本。不能把这个思想无条件推广到任意 Attention 架构。

6. Engram：把一部分模型能力从 dense compute 迁到稀疏 memory lookup

V4.1 还引入 Engram conditional memory。它不是普通 Transformer MLP：其访问行为更接近根据 token n-gram/hash 进行稀疏表查找，再将结果注入 residual stream。

这会产生一种不同于 GEMM 的系统瓶颈：

MoE / Attention：算力、HBM bandwidth、collective communication
Engram：随机访问、地址翻译、NUMA、Host DRAM、PCIe/互联

因此“权重应该全部放 HBM”不再是唯一合理策略。对于大而稀疏访问的表结构，Host DRAM / 分层存储可能更有吸引力，但前提是访问延迟、并发、NUMA 亲和和预取策略能够控制。

7. mHC：Residual 也开始变成需要专门调度的状态

V4.1 的 mHC / Mega-mHC 路径意味着 residual 不再只是传统的一条 x + f(x) 数据流，而涉及多路 residual stream 与混合。对 kernel 层来说，这会带来新的 projection、mixing、归一化/规约与融合机会；对并行系统来说，则意味着 pipeline/sequence parallel 边界可能要携带更多状态，而不仅是单个 hidden tensor。

这里最重要的学习点不是记住某个 kernel 名字，而是认识到：模型内部“状态”正在从 KV 扩张到 residual、compressor、indexer、memory lookup 等多个维度。

8. DSpark：Speculative Decoding 从外挂策略逐渐进入模型设计

V4.1 同时围绕 DSpark speculative decoding 进行设计。传统 serving 可以把 speculative decoding 看成框架外挂的 draft model；当模型架构和训练本身为 speculation 优化后，runtime 需要更严谨地管理：draft state、target state、verification、commit/rollback 以及 prefix restore。

这与 PD 分离叠加时尤其复杂：状态不仅要“搬过去”，还要保证 目标模型状态与 speculative state 的生命周期一致。

9. 从 MLA / DSA 到 CSA2：优化维度在持续扩张

已有笔记 MLA、DSA 与 KDA：三种 Attention 优化如何改变缓存与推理可以作为前置知识。把演化过程压缩成一条线：

MLA：压缩“每个历史位置存多少”
   ↓
DSA：减少“每步读取多少历史位置”
   ↓
CSA / CSA2：压缩 + 稀疏 + 跨层共享 + 复用索引
   ↓
CED / replay / Engram：继续改变“谁计算、谁存、什么值得长期保存”

因此以后分析 Attention 不能只问 FLOPs。至少要同时问：

每个 token 产生哪些长期状态？
状态按 layer、head、token 如何分布？
哪些 layer 是 owner，哪些只是 consumer？
一次 decode 实际读取多少历史？
哪些状态可以重建而不必持久化？
状态的 dtype / scale 是否属于模型数值语义？

10. 实践阅读方法：从 config 到 runtime，而不是只看论文图

阅读 V4.1 或后续新模型时，建议按以下顺序：

模型 config：确认 layer 数、attention 类型、expert 数、window、cache dtype、compression ratio。
model forward：标出 encoder/decoder、Full/Reindex/Reuse 等路径分叉。
cache interface：找出实际 cache owner、alias、indexer/compressor state。
kernel：确认 FP4/FP8 quant/dequant、sparse select、MoE、mHC 的硬件路径。
distributed runtime：检查 TP/EP/DCP/SP/PD 如何处理这些状态。
benchmark：分别测 cold prefill、prefix hit、long decode、不同 concurrency，不要只看单一 tokens/s。

11. 与现有知识库的连接

Attention 基础与缓存演化：MLA、DSA 与 KDA：三种 Attention 优化如何改变缓存与推理
GQA 与 KV Cache 基础：GQA 深入理解：从 MHA、MQA 到 KV Cache 与内存带宽瓶颈
W8A8/C8 与数值精度：W8A8C8 与 GPQA：把量化位宽、数值误差和模型能力分开看

12. 资料与状态说明

边界提醒：架构事实与工程实现要分开。模型报告描述“应该有什么状态”，vLLM/SGLang/vLLM-Ascend 则决定这些状态在具体版本中是否已经正确、高效地实现。

13. 延伸：从模型结构进入 Serving Runtime

V4.1 的结构变化最终会落到 cache ownership、PD handoff、DCP 稀疏索引一致性、Memory Hierarchy、MoE 通信与低比特数值契约。对应的系统专题见：DeepSeek V4.1 对推理 Infra 的挑战：从 KV 状态图到异构 Memory Runtime。