参数几乎翻倍，推理反而更省：DeepSeek V4.1-Flash 重构 KV Cache

DeepSeek 今天发布了 DeepSeek-V4.1-Flash。

DeepSeek-V4.1-Flash 是一款原生多模态 MoE 模型，支持最高 100 万 Token 上下文。模型拥有 552B 主干参数，另有 196B Engram 条件记忆参数；但在 Prefill 阶段每 Token 只激活 8B 参数，Decode 阶段激活 16B 参数。而上一代的 DeepSeek-V4-Flash，拥有 284B 主干参数，每 Token 激活 13B 参数。这意味着，新模型虽然主干规模接近翻倍，但读取 Prompt 时实际参与计算的参数反而减少。

这一代模型的技术重点明显转向长程 Agent 的真实部署成本：当 Agent 不断读取代码、网页、文档和工具返回结果时，模型工作负载正在越来越“输入重型”，长上下文带来的 Prefill 计算、KV Cache 占用、SSD 存储和数据搬运，开始成为比模型参数本身更突出的成本瓶颈。

根据技术报告，这次 DeepSeek 对 Transformer 结构进行了一次明显调整。

V4.1-Flash 共有 40 层语言主干，但不再简单按照传统 Decoder-only 模型的方式逐层处理全部 Prompt，而是划分成 20 层因果编码器（Causal Encoder）和 20 层 Decoder。前两层只使用滑动窗口注意力（Sliding-Window Attention，SWA），其余层则采用新的压缩稀疏注意力 2（Compressed Sparse Attention 2，CSA2）。此外，模型还集成了 Single-Pass mHC、Engram、DSpark 以及分层稀疏索引器等模块。

这套架构首先要解决的是 Agent 最现实的一个成本问题：它们通常读得远远多于写。

在 Agent 工作流中，每一次工具调用都会产生新的网页、Terminal 输出、代码或者文档，然后重新送入模型进行 Prefill。如果上下文不断增长到几十万甚至 100 万 Token，让所有历史 Token 每次都完整经过整个模型，会产生极高的计算成本。

为此，DeepSeek 在 V4.1-Flash 中加入了因果编码器-解码器（Causal Encoder-Decoder，CED）架构。Prefill 时，Prompt 首先经过前 20 层因果编码器；进入后 20 层 Decoder 后，Decoder 所需的全局 KV 不再由 Prompt 逐层重新计算，而是直接从第 20 层 Encoder 最终隐藏状态投影得到。这样，大部分 Prompt Token 不需要再完整经过后半部分网络。报告显示，Prefill 计算量接近减半。

KV Cache 成为这一代架构改造的核心

DeepSeek 在技术报告中花费很多篇幅讨论了 KV Cache。

V4 已经通过稀疏注意力降低长上下文计算成本，但随着上下文进一步拉长，另一个问题开始凸显：即使 Attention 计算变便宜，KV Cache 仍然需要长期占用 HBM、Host Memory 和 SSD，而且还需要在不同设备之间频繁传输。

DeepSeek 因此把 V4 使用的 CSA 与 HCA 混合架构，改成了纯 CSA2，并增加了一个此前较少被利用的压缩维度：跨 Transformer 层共享 KV Cache。

CSA2 中的 Layer 被划分成 Full、Reindex 和 Reuse 三种模式。Full Mode 完整生成 Main KV、Indexer K，并重新搜索 Top-K 历史 Token；Reindex Mode 直接复用此前 Layer 生成的 Global KV，只重新计算一次哪些历史位置最重要；Reuse Mode 则进一步连 Top-K 索引也一起复用，只执行真正的 Attention 计算。

也就是说，如果前面的 Transformer 层已经判断出，在 100 万个历史 Token 中，当前 Query 最需要关注某几百个位置，后面的很多层就不必再保存一套完整 KV，也不必从头扫描 100 万 Token。

在此基础上，V4.1-Flash 进一步引入分层稀疏索引器。Decoder 中的第一个 Full Mode 仍然会扫描完整可见上下文，但会首先生成一个较大的候选池。按照报告配置，系统最多选择 2048 个 Block，每个 Block 包含 8 个位置，因此后续 Layer 只需要在最多 16384 个候选位置中继续寻找最终 Top-512，而不必重新扫描整个百万 Token 上下文。在候选池规模固定后，后续 Indexer 的计算量基本不再随着 Context 长度线性增长。

DeepSeek 给出的结果是，当上下文从 4K 扩大到 1M、长度增长 256 倍时，V4.1-Flash 单 Token Decode FLOPs 仅增加约 25%。

DeepSeek 还直接对 KV Cache 进行了更激进的量化。

V4 已经对 Indexer 中的 Query 和 Key 使用 FP4 量化感知训练，但 Main KV 仍主要使用 FP8。到了 V4.1，DeepSeek 把 FP4 进一步扩展到 Main KV Cache，通过 QAT 让模型直接适应低精度 KV 存储；对量化更加敏感的 SWA KV 则继续保留 FP8。

CSA2 跨层共享与 FP4 叠加之后，V4.1-Flash 的 Global KV Cache 被压缩到约 890 Byte/Token，只相当于 V4-Flash 约 1/4。

如果简单按照百万 Token 折算，仅 Global KV 的数据量约为 890MB。相比之下，上一代在同等 Token 长度下大约需要其 4 倍规模。这里还没有计算模型权重和其他运行内存，但对于大量长上下文 Agent 并发服务而言，HBM 压力已经出现数量级明显的下降。

不过 DeepSeek 认为，真正昂贵的不只是运行时 HBM，还包括为了 Prefix Cache 长期保存到 SSD 或 Host Memory 中的 Persistent KV。

在 DeepSeek-V4 部署中，Global KV 和 SWA KV 都会进入持久化缓存，并在典型负载下保留超过 72 小时。但团队后来发现，两种 KV 的生命周期并不一样：Global KV 可能数小时甚至数天后仍然再次命中，而 SWA 只记录局部窗口状态，通常只在当前活跃 Session 的分钟级时间范围内有意义，一旦会话继续推进或结束，很快就失去价值。

因此，V4.1 直接改变了缓存策略：Global KV 继续放入 Persistent Cache 长期保存；SWA KV 则不再长期写入 SSD，而是放在由每台服务器约 10% Host DRAM 构成的短期分布式内存池中，TTL 仅为分钟级。

真正的问题在于，一旦 SWA KV 丢失，过去要精确恢复它成本很高。V4.1 为此设计了 SWA Bounded Replay：不再追求数学意义上的完全重建，只重新计算最近 nwinn_{win} 个 Token，用近似状态恢复 SWA。DeepSeek 表示，在内部测试中，这一近似恢复对回答质量的影响可以忽略。

经过这一调整，V4.1-Flash 的 Persistent KV Cache 最终降到 V4 约 1/8：一方面不再长期保存约占一半空间的 SWA KV，另一方面剩余 Global KV 本身又通过 CSA2 和 FP4 缩小到约 1/4。

mHC 继续保留，但从“多 Pass”改成 Single-Pass

V4.1 还对 DeepSeek-V4 首次引入的 mHC 进行了工程化改造。

原有 mHC 需要依次执行 Residual Update、Coefficient Prediction 和 Input Mixing，由于它们之间存在数据依赖，需要多个 Kernel 连续读写 Residual Stream。DeepSeek 计算发现，其 Activation Memory Traffic 约为理论下限的两倍。

V4.1 的 Single-Pass mHC 则把 Input Mixing 使用的系数向前错开一个 Block，让当前 Block 直接使用上一 Block 生成的系数，从而解除内部数据依赖。

在部署阶段，DeepSeek 进一步通过 Mega-mHC Kernel 把 Residual Update、Input Mixing、Coefficient Prediction 以及部分 Norm、FP8 转换融合到一起，使 Residual Stream 能够实现接近一次读取、一次写入。最终，Activation Memory Traffic 相比原始实现减半，而报告称性能损失可以忽略。

V4.1-Flash 还正式加入 Engram 条件记忆模块。其核心思路是，将模型的“记忆”能力与昂贵的 Transformer 计算部分分离。Engram 使用 N-gram、Hash 和条件门控等机制，在需要时检索对应 Embedding，而不是让所有已经记住的知识都通过 MoE 矩阵乘法重新计算。

模型总共配置 196B Engram 参数，被分配到两个模块中，并支持 2-gram、3-gram 和 4-gram 等记忆单元。由于寻址方式是确定性的，推理阶段可以提前从 Host Memory 通过 RDMA 预取相关 Embedding，并与 Transformer 计算重叠。

MTP 退出主干预训练，DSpark 接管推测解码

另一个变化发生在生成速度上。

V4.1-Flash 在主干预训练阶段取消 MTP，并引入独立训练的 DSpark 推测解码模块。DSpark 由 3 个 Transformer Block 组成，一次 Forward 可以并行预测 5 个 Draft 位置，并通过轻量 Markov Head 处理这些候选 Token 之间的依赖，再由 Confidence Head 预测各个位置被主模型接受的概率。

系统还会根据当前推理引擎的吞吐情况，动态决定一次应该验证多少 Draft Token，而不是固定使用某个推测长度，以最大化整套服务系统的 Token 吞吐率。

与此前 MTP 从预训练阶段便和 Backbone 联合训练不同，DSpark 在主干模型预训练结束之后单独训练，训练期间冻结 Backbone；后训练阶段则让 DSpark 随着主模型继续更新，但不会把 DSpark 自己的梯度反向传播到 Backbone。

这意味着推测解码进一步从模型核心能力中剥离出来，可以独立优化而不干扰 Backbone 本身。

这次，V4.1-Flash 正式把多模态能力集成到预训练阶段。模型使用从头训练的 DeepSeek-ViT 作为视觉编码器，并使用 2D-RoPE 适配不同输入分辨率。视觉特征在送入 LLM 之前经过 3×3 Pixel-Unshuffle，使视觉 Token 数量减少至原来的 1/9，最终支持约 1344×1344 分辨率的输入。

DeepSeek 还针对 MoE 引入了模态独立的负载均衡机制。由于图片 Token 和文本 Token 的分布不同，两者可能天然偏好不同 Expert，如果只看整体负载，很可能出现文本 Expert 和视觉 Expert 内部失衡。因此，V4.1 分别维护图片和文本的 Expert Correction Bias，让两种模态独立进行路由负载调整。

改进数据和训练环境的边际收益更高

相比底层架构的大幅修改，V4.1 在后训练算法上反而没有推出新的 RL 方法。

DeepSeek 明确表示，仍然沿用监督微调（SFT）、强化学习（RL）和在策略蒸馏（On-Policy Distillation，OPD）的标准流程，主要投入放在了训练数据和环境本身，包括大规模自动生成可验证任务、程序化构建 Agent 环境、扩展 Rollout 数量，并针对数据进行去重、难度校准和质量筛选。

DeepSeek 判断，在当前阶段，继续改进数据和训练环境 Pipeline 所获得的边际收益，已经明显高于后训练算法本身的创新。

团队甚至开始训练模型反过来生成自己的训练任务。每个任务被定义成“问题—环境—验证系统”三元组，再根据任务难度和正确性评分，让模型持续生成更高质量的 RL 训练材料。

参考链接：

https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/blob/main/DeepSeek_V41_Tech_Report.pdf