DeepSeek-V4.1-Flash 技术报告与架构解析

DeepSeek-V4.1-Flash 是 DeepSeek 在 2026 年 9 月发布的新一代多模态模型。它最值得关注的地方，不只是参数规模，而是将 Causal Encoder-Decoder（CED）、MoE、压缩稀疏注意力和 KV Cache 优化组合到了一起，专门面向长上下文和 Agent 场景。

1. 论文与官方资料

严格来说，目前公开的正式资料名称是 DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression 技术报告，而不是一篇单独名为“DeepSeek-V4.1”的论文。

• DeepSeek 官方发布公告
• DeepSeek-V4.1-Flash Technical Report（PDF）
• DeepSeek-V4.1-Flash 官方模型卡

本文的架构信息主要来自技术报告和官方模型卡。部署方面的细节可能随着推理框架实现继续变化，因此需要将“论文中定义的模型结构”和“某个推理框架的工程实现”区分开来。

2. 先看模型规格

项目	DeepSeek-V4.1-Flash
模型类型	多模态 Mixture-of-Experts（MoE）
Backbone 参数量	约 552B
每 token 激活参数	Prefill 约 8B；Decode 约 16B
Transformer 层数	40 层，20 层 Encoder + 20 层 Decoder
上下文长度	最长约 1M tokens
输入模态	文本、图像
输出模态	文本
MoE 路由	1 个共享专家 + 384 个路由专家，每 token 激活 6 个路由专家
权重许可	MIT

“552B 参数”与“每 token 只激活 8B/16B”并不矛盾：前者是模型中保存的总参数规模，后者是一次计算中实际参与当前 token 的参数规模。

3. 总体架构

可以先用下面这张图理解 V4.1-Flash 的数据流：

                         ┌──────────────────────┐
文本 token ──────────────┤                      │
                         │   统一输入 Embedding │
图像 ─> DeepSeek-ViT ─>  │                      │
       MLP Projector     └──────────┬───────────┘
                                    │
                         ┌──────────▼───────────┐
                         │ 20 层 Causal Encoder │
                         └──────────┬───────────┘
                                    │
                   Encoder 最终隐状态投影全局 K/V
                                    │
                         ┌──────────▼───────────┐
                         │    20 层 Decoder     │
                         └──────────┬───────────┘
                                    │
                              LM Head 输出文本

这里的 Encoder 不是 BERT 那种可以双向看完整序列的普通 Encoder，而是 causal encoder：它仍然遵守自回归因果约束。Decoder 的关键变化是，它的全局 KV 不再由每一层分别从自己的隐状态生成，而是从 Encoder 的最终隐状态投影得到。

这就是 CED 结构带来的输入/输出不对称：

• 读取长 prompt 时，主要运行 Encoder，激活参数约 8B；
• 生成答案时，再运行 Decoder，激活参数约 16B。

对于 Agent，这种设计很自然：Agent 经常需要读取很长的代码、历史消息、工具输出和文档，但最后只生成相对短的计划或操作结果。

4. CED：为什么不是普通 Decoder-only？

DeepSeek 之前的语言模型通常可以理解为一个 Decoder-only Transformer：输入 token 和输出 token 都经过同一组层级结构，长上下文 Prefill 阶段会产生大量 KV Cache 和计算量。

V4.1-Flash 把 40 层拆成两段：

输入序列
   │
   ▼
20 层 Causal Encoder
   │
   ├── 保存 Encoder 的最终隐状态
   └── 投影出 Decoder 使用的全局 K/V
                       │
                       ▼
                 20 层 Decoder
                       │
                       ▼
                    输出 token

Decoder 仍然负责自回归生成，但不必为每个 Decoder 层都完整保存一份长序列的全局 KV。这是 V4.1-Flash 降低输入阶段计算和缓存成本的核心原因。

5. MoE：大参数规模与低激活量

V4.1-Flash 的每个 MoE 层包含一个共享专家和 384 个路由专家。路由器会针对每个 token 选择少数专家参与计算：

                         ┌─ 路由专家 1
                         ├─ 路由专家 2
Token ─> Router ─────────┼─ ...
                         ├─ 路由专家 384
                         └─ 共享专家

每个 token 激活 6 个路由专家，同时经过共享专家。这样做的好处是：

1. 模型可以拥有更大的总容量；
2. 单个 token 不需要运行所有专家；
3. 不同专家可以逐渐形成不同的知识或任务分工。

因此，V4.1-Flash 的“552B”更接近整个专家池的容量，而不是每个 token 的实际计算量。

6. CSA2：压缩稀疏注意力

百万 token 上下文最大的瓶颈之一是 Attention 的计算和 KV Cache。V4.1-Flash 使用 Compressed Sparse Attention 2（CSA2），沿着两个方向优化：

• 在序列维度上，只关注少数重要位置；
• 在层维度上，让不同层复用已有的 KV 和稀疏索引。

CSA2 为不同注意力层分配三种模式：

Full

当前层自己计算主 KV、索引器 K，并重新选择稀疏注意力中的 Top-K 位置。

Reindex

复用上一层的主 KV 和索引器 K，但使用当前层自己的查询重新计算索引。

Reuse

主 KV、索引器 K 以及 Top-K 索引都复用前面层的结果，进一步减少计算。

Decoder 中还使用 Hierarchical Sparse Indexer，先构造一个候选池，再在候选池中进行更细粒度的选择。这样可以避免深层索引开销随着上下文长度线性增长。

7. KV Cache：V4.1-Flash 的重点优化

报告标题直接强调了 KV Cache，因为这是 V4.1-Flash 最核心的工程目标之一。

它组合使用了：

• CSA2 的跨层 KV 复用；
• FP4 格式的主 KV Cache；
• Sliding-Window Attention；
• SWA Bounded Replay；
• 从 Encoder 最终隐状态投影 Decoder 的全局 KV。

其中，SWA Bounded Replay 的思路是：不把所有滑动窗口 KV 都持久化到 SSD，需要时只重放最近的一小段 token，重新构造缺失的局部 KV 状态。

官方技术报告给出的结果是：

• 全局 KV Cache 约为 890 bytes/token；
• 相比 DeepSeek-V4-Flash，约缩小到四分之一；
• 持久化 KV 存储需求约降到上一代的八分之一。

这对长时间运行的 Agent 很重要，因为 Agent 的上下文可能包含多轮工具调用、代码文件、终端日志、截图和中间结果。此时缓存成本往往比单次生成计算更容易成为瓶颈。

8. Engram：条件记忆模块

V4.1-Flash 还加入了 Engram conditional memory。它可以理解为一种大规模、稀疏访问的 token/n-gram 条件记忆：

输入 token / n-gram
          │
          ▼
     Hash / Lookup
          │
          ▼
   读取对应的记忆向量
          │
          ▼
      写回残差流

Engram 的参数规模约为 196B，但不是每个 token 都访问全部参数，而是通过 token 相关的查表进行稀疏读取。

它的目标不是替代 Transformer，而是把一些高频、稳定、适合记忆化的模式交给条件记忆模块处理，从而减少 Transformer 层反复重建这些模式的负担。

9. 原生视觉架构

V4.1-Flash 原生支持图像输入。图像首先经过从头训练的 DeepSeek-ViT，再通过两层 MLP projector 转换为语言模型可以接收的视觉 embedding。

图像
  │
  ▼
DeepSeek-ViT
  │  2D-RoPE、视觉特征提取
  ▼
Pixel Unshuffle 下采样
  │
  ▼
两层 MLP Projector
  │
  ▼
与文本 Embedding 合并
  │
  ▼
CED 主干统一处理

这意味着图像和文本不是先由两个完全独立的模型处理、最后再拼接结果，而是在语言模型预训练阶段就共同进入统一的处理流程。

10. DSpark：推测解码

模型还包含 DSpark speculative decoding，用一个较轻量的草稿结构一次提出多个候选 token，再由主模型并行验证。

基本过程是：

主模型已生成 token
          │
          ▼
DSpark 草稿模块提出多个 token
          │
          ▼
主 Decoder 一次验证一整个 token block
          │
          ├─ 接受正确的 token
          └─ 从第一个不一致位置继续生成

它不会改变模型最终分布，但可以减少逐 token 解码时的串行等待，尤其适合输出较长的场景。

11. 一张表总结 V4.1-Flash 的设计目标

设计	解决的问题	V4.1-Flash 的做法
CED	长输入 Prefill 太贵	Encoder/Decoder 分工，输入只激活约 8B
MoE	模型容量与计算成本的矛盾	384 个路由专家，每 token 只选少数专家
CSA2	全局注意力计算和 KV 太大	稀疏索引、KV 压缩、跨层复用
SWA Replay	局部窗口 KV 持久化成本高	只重放最近窗口，按需重建
Engram	高频模式反复由 Transformer 计算	稀疏查表读取条件记忆
原生视觉	图像与文本信息割裂	ViT + Projector 后进入统一主干
DSpark	自回归生成串行速度慢	草稿生成 + 主模型批量验证

12. 我的理解：V4.1-Flash 真正改变了什么？

DeepSeek-V4.1-Flash 的主要变化不是简单地“把 V3 做得更大”，而是重新围绕长上下文 Agent 设计了模型的计算路径：

1. 用 CED 将读取输入和生成输出拆成不对称的两种计算模式；
2. 用 MoE 提高总容量，同时控制每 token 的激活量；
3. 用 CSA2 和 KV 压缩降低百万上下文的缓存成本；
4. 用 Engram 记忆化一部分适合查表的模式；
5. 用原生视觉编码器统一处理图像和文本；
6. 用 DSpark 减少自回归解码的串行等待。

所以，V4.1-Flash 更像是一个面向 长上下文、工具调用和 Agent 工作流 的系统性架构，而不只是一个参数量更大的语言模型。

参考资料

1. DeepSeek 官方发布公告
2. DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression
3. DeepSeek-V4.1-Flash 官方模型卡