DeepSeek V4.1 Flash用了哪些黑科技？竟让Flash（差点）逼退Pro

几天前，DeepSeek V4.1 Flash 正式发布，凭借其快速且强大的性能，迅速吸引了大量关注与测试热潮。

例如，知名评测机构 Artificial Analysis 在对 V4.1 Flash 进行详尽测试后，给出了 40 分的指数评分，这一成绩超越了 DeepSeek 旗下参数规模更大的 V4 Pro。

当然，这并不令人意外，因为 DeepSeek 自身也得出了类似结论，并曾计划让 V4 Pro 下线，将相关请求直接路由至 V4.1 Flash。值得一提的是，DeepSeek 已两次更改决定，先是推迟了 V4 Pro 的下线时间：

随后又放弃了 V4 Pro 的下线计划，并继续提供其 API 调用服务：

此外，Artificial Analysis 的系统评测中还包含其他亮点：

• DeepSeek V4.1 Flash 在智能体能力和长上下文推理方面取得了显著进步。
• DeepSeek V4.1 Flash 以 69% 的成绩在 AutomationBench-AA 上排名第一，与 GPT-6 Astra（69%）持平，略高于 Grok 4.6（67%）。
• DeepSeek V4.1 Flash 是其测试过的冗长度最高的模型之一，每个 Intelligence Index 任务消耗 89k Tokens。
• 尽管冗长度较高，DeepSeek V4.1 Flash 每个 Intelligence Index 任务仅花费 0.27 美元。这主要得益于其低定价策略。

Sebastian Raschka 甚至认为，DeepSeek V4.1 Flash 的创新程度之大，足以命名为 DeepSeek V5。

那么，DeepSeek V4.1 Flash 究竟是如何实现的？它是如何凭借 552B 参数的较小模型，超越拥有 1.6T 参数的 Pro 版本？下面我们将基于其官方技术报告进行解读。

报告地址：https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/blob/main/DeepSeek_V41_Tech_Report.pdf

这是一篇围绕 KV 缓存展开的报告

先看技术报告的标题：「DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression」。推动 KV 缓存压缩的极限。 翻看架构章节，我们发现这并非修辞手法，几乎每一项设计都指向同一个目标：降低 KV 缓存。

先看几个数字。V4.1-Flash 的全局 KV 缓存（始终常驻 HBM 的部分）被压缩至每 token 890 字节，约为 V4-Flash 的1/4；若与 DeepSeek-V1 的 389,120 字节相比，则相差 437 倍。持久化 KV 缓存（存储在 SSD 或主机内存中，用于前缀复用的部分）则被压缩至 V4-Flash 的约1/8。

模型本身是一个拥有 552B 主干参数和 196B Engram 参数的多模态 MoE，原生支持 100 万 token 上下文，在 45T token 的多模态语料上预训练，prefill 阶段每 token 仅激活 8B 参数，decode 阶段激活 16B。

DeepSeek 历代模型每 token 全局 KV 缓存大小对比

这套数字组合起来，才是「552B 战胜 1.6T」的真正含义：比较的核心在于同样一次 agent 调用中，模型需要占用多少显存、从 SSD 搬运多少数据、以及重算多少次 prefill。

稀疏注意力之后，瓶颈在于存储和搬运

要理解 DeepSeek 为何全力聚焦 KV 缓存，必须先看清瓶颈的变化。

从 V3.2 的 DSA 到 V4 的 CSA，稀疏注意力已将长序列的计算成本大幅降低。但长程 agent 的工作负载有一个特点：输入重（input-heavy）。

一个运行数小时的编码 agent，每次工具调用都会触发一次新的 prefill 请求，上下文只增不减，而实际需要生成的 token 反而较少。

于是，当「计算」不再是瓶颈后，「存储」和「搬运」便成为新的限制。

报告将这一新瓶颈分解为三个方面：

• HBM容量限制了运行时能同时容纳的并发请求的全局 KV；
• SSD和主机内存容量限制了前缀缓存的存储时长和命中率；
• IO与互联带宽则限制了缓存迁移和加载的速度。

这三个问题共同决定了一个 agent 服务的吞吐上限和单位成本。V4 时代 DeepSeek 已通过 CSA 与 HCA 混合实现序列维度的压缩，而 V4.1-Flash 则选择在架构、精度、部署三个层面同时发力。

CED：将一半 prefill 计算直接削减

V4.1-Flash 的语言主干有 40 层，但被分为两半：前 20 层是因果编码器（Causal Encoder），后 20 层是解码器。这个结构称为Causal Encoder-Decoder，简称CED。这也是 DeepSeek 官方发布页上「输入激活 8B、输出激活 16B」这一不对称设计的来源。

有趣的是，Arena 的 Peter Gostev 还让 Astra 阅读了 DeepSeek v4.1 Flash 的论文，并用 3D 模型将其架构与原始 Transformer 架构进行了直观对比。他将其分享出来，你可以放大并排查看每一个元素：

https://transformer-architecture.petergostev.chatgpt.site/

关键在于解码器那 20 层的全局 KV 是如何生成的？

在常规 Transformer 中，每层的 K、V 都从该层自身的隐藏状态计算得出，因此处理一段提示词必须跑完所有 40 层。

CED 则不同：解码器各层的 KV 条目直接由第 20 层（即编码器最后一层）的隐藏状态，通过各自的投影矩阵映射得到。换句话说，prefill 阶段只需运行前 20 层，上半部分的全局 KV 缓存就能以极低成本获得。当序列长度远大于窗口时，prefill 的复杂度从 O(NL) 降至约 O(NL/2)，几乎减半。

这一思路继承自微软的 YoCo（You Only Cache Once），但 CED 在结构上进行了增强：YoCo 让上半部分直接共享下半部分生成的同一份 KV 缓存，而 CED 则为每一层配置独立的投影权重，在保持「只计算一半」的前提下，扩大了 KV 的有效容量和生成深度。

不过，这也带来了代价，主要体现在滑动窗口注意力上。SWA 仍需逐层计算，每层的局部 K、V 都来自本层隐藏状态，以维持局部信息的计算深度。但这意味着 prefill 时解码器仍需额外处理 n_win × L/2 个 token 来补齐 SWA 状态，对于多轮短提示的场景反而成为新开销。

DeepSeek 的处理方式是「近似」：既然已有研究表明 SWA 的实际有效感受野远小于理论上的 n_win × L/2，那就只回放提示词最后的 n_win 个 token。这就是后面要讲的 Decoder SWA Bounded Replay。

CSA2：三个压缩维度首次同时被充分利用

CED 负责计算，CSA2（Compressed Sparse Attention 2） 则负责存储。

报告将 KV 缓存的压缩空间归纳为三个相互乘数的维度：条目大小（GQA 减少 KV 头数、MLA 让各头共享一个小 latent）、序列维度（每 m 个 token 压成一条，V4 的 CSA 和 HCA 属于此类）、以及层维度（让部分层复用其他层的缓存和选择结果）。

报告中还介绍了三项之前的成果：

• IndexCache 跨层复用 Top-K 索引，节省的是索引器的算力而非缓存；
• YOIO 将稀疏路由算作一次全网共享，但全网共享会损害性能；
• HySparse 让稀疏层复用稠密层的 KV 缓存，但它仍保留了完整的注意力层。

三者都没有覆盖全部三个维度，而 CSA2 的目标是同时充分利用所有维度。

它的做法是为每个 CSA2 层静态分配三种模式之一。

• Full 模式：自行计算 main KV 和索引器 Q，从 main KV 投影出索引器 K，运行完整的索引流程以生成新鲜的 Top-K 索引。
• Reindex 模式：复用前面某层的 main KV 和索引器 K，但使用自己的索引器 Q 重新打分，选出属于自己的 Top-K——缓存共享，但选择权归自己。
• Reuse 模式：最为节省，main KV 和 Top-K 索引全部沿用，直接进行稀疏注意力，连索引器 Q 都不计算。

三种模式的共同点是，每层仍保留自己的全局 Q 和 SWA KV，因此层与层之间的表达能力并未被抹平。具体配置参见原报告。

FP4 与 Bounded Replay

架构之外，还有两项改进。

第一项在精度上。V4 已对索引器的 Q、K 进行了 FP4 量化感知训练，V4.1-Flash 则将 FP4 扩展到 main KV 缓存。格式上选用 E2M1 搭配每 16 通道一个 E4M3 缩放因子，接近 NVFP4 但省去了其二级全局缩放。报告也严谨地论证了这一做法，感兴趣的读者可自行查阅。

第二项在部署上，即前面提到的 SWA Bounded Replay。由于 SWA 的依赖会逐层累积，精确重建 L 层的 SWA KV 需要回放 L × n_win 个 token，V4 的技术报告中曾提出「Zero SWA Caching」的思路，但该代价在生产部署中被证明过高。V4.1-Flash 则直接接受近似：只回放最近的 n_win 个 token（配置中 n_win = 128），并将 SWA 截断至回放段内。

这个「接受近似」带来的收益非常明显。在 V4 的部署中，SWA KV 占据了持久化缓存近一半的容量，但其访问模式与持久化缓存的长留存策略根本不匹配——全局 KV 具有长尾复用价值，而 SWA KV 仅在一个活跃会话内的分钟级窗口中有用，会话结束后便是无用数据。

因此，V4.1-Flash 将 SWA KV 整体移出持久化缓存，改为放入由每台机器 10% 主机 DRAM 组成的分布式内存池，TTL 仅几分钟，依靠高周转服务绝大多数并发会话；全局 KV 则继续留在 SSD 上，保证至少 72 小时的生命周期。

偶尔出现全局 KV 命中而 SWA KV 未命中的请求，就用 bounded replay 重算 n_win 个 token 兜底。报告称，这将一次灾难性的缓存未命中转变为一次廉价的优雅降级，持久化 KV 缓存也因此降至 V4-Flash 的约 1/8。

所有这些措施叠加的效果：上下文从 4K 扩展到 1M、放大 256 倍，V4.1-Flash 的单 token decode FLOPs 仅增加了 1/4。

各代 DeepSeek 模型单 token decode FLOPs 随上下文长度的变化

Single-Pass mHC、Engram 与 DSpark

熟悉 DeepSeek 这一年论文节奏的读者，会在架构章节中看到许多熟悉的面孔。

mHC（流形约束超连接） 来自今年元旦发布的一篇论文，旨在解决超大规模训练的稳定性问题。

V4.1-Flash 将其升级为Single-Pass mHC。

在原始实现中，输入混合系数 A 必须等待隐藏维度上的规约完成才能获取，导致残差更新、系数预测、输入混合三个 kernel 只能串行执行，激活访存量是理论下界的两倍。

新版本的做法是将混合系数错开一个 block——每个 block 消费上一个 block 产出的混合系数，依赖关系就此消失，三步可以融合进一个名为 Mega-mHC 的 kernel 中，激活访存从 (4n+4)d 降至 (2n+2)d，正好减半。报告称，这种错位带来的性能损失可以忽略。

Engram 则是今年 1 月 DeepSeek 与北京大学合作提出的条件记忆模块，思路是利用 N-gram 哈希实现 O(1) 复杂度的静态知识检索，将「记忆」从昂贵的 GPU 显存卸载到廉价的 DRAM，让 MoE 专注于组合推理。

V4.1-Flash 中它首次进入正式版模型：196B 参数平均分配给两个模块，放置在第 1 层和第 14 层，采用 {2, 3, 4} 阶 N-gram、8 个哈希头、每阶总嵌入维度 2048，每个头索引约 1600 万条目，表大小取互不相同的质数。嵌入表和投影均使用 FP8，推理时通过确定性寻址从主机内存后台 RDMA 预取，第一个模块的预取直接与第一个 Transformer block 的计算重叠。相比原始 Engram 设计，此处去掉了短因果卷积，原因是其收益不足以抵消推理栈的复杂性。

投机解码模块 DSpark 由三个 Transformer block 组成，滑动窗口 128 token，一次前向并行给出五个草稿位置的 base logits，再用一个轻量的 Markov 头建模草稿 token 之间的依赖，另有一个置信度头预测逐位置的接受概率，由调度器结合引擎吞吐曲线动态决定每个请求的验证长度。与 V3 中全程与主干联合训练的 MTP 不同，DSpark 是在预训练之后单独训练的，后训练阶段跟随主干但不回传梯度，其好处是能持续对齐不断演化的策略，同时加速线上服务和 RL 的 rollout 生成。

优化器层面也有两处调整：Q、K 权重采用按头切分的 head-wise Muon，以处理注意力头之间的异质性；Engram 嵌入表、token 嵌入和预测头则使用动量更新配合 Sinkhorn 平衡替代 Adam，仅需一个动量缓冲，节省了大量优化器状态显存。

这些优化效果显著：占绝大多数的 Reuse 模式层，prefill 时仅需执行 15 个 kernel，decode 时仅需 11 个。

后训练：「没有算法创新」

DeepSeek 在后训练章节坦率地表示：这一版本没有引入新的后训练算法，流程是标准的 SFT 加 RL 加 on-policy 蒸馏，没有超出成熟实践的改动。所有改动都集中在数据管线上，此处不再赘述，详见原论文。

一个有趣的点是，后训练引入了一个对用户直接可见的设计：reasoning effort。

训练时，将一个 1 到 100 的标量 effort 显式写入系统提示，同一 effort 下的多个采样构成一个子组，组内进行奖励中心化，而长度惩罚系数随 effort 指数衰减：effort 每增加一个特征尺度，惩罚系数乘以 1/e。这样一来，同一份权重就能在成本-质量曲线上滑动。DeepSeek API 暴露的 max、high、low 三档，对应的正是 b=100、75、50。

这也解释了开头 Artificial Analysis 那条「最冗长模型之一」的观察：它测试的是 max 档，而 max 档在设计上正是这条曲线最右端的点。

报告给出的数据显示，effort 从 25 提升至 100，八个推理密集型基准的平均 Pass@1 从 67.1% 升至 76.3%，DeepSWE v1.1 从 66.0% 升至 74.2%，Terminal-Bench 2.1 从 82.4% 升至 90.6%，代价是约 2.5 倍的输出 token。

性能与输出长度随 reasoning effort 的变化

但收益是前置的——60 到 80 这一档已经能用不到一半的 token 预算获得接近满档的准确率，而从 80 走到 100 会让 agent 轨迹再长 1.6 到 1.8 倍，换来的只是边际提升。报告建议将 max 留给最难的任务。

结语

通读这份报告，最值得注意的是三个层次被拧在同一个方向上：架构层通过 CED 削减一半 prefill、通过 CSA2 实现跨层复用的三个维度全覆盖，精度层将 main KV 压缩至 FP4，部署层则通过 bounded replay 将 SWA KV 整体移出持久化缓存。

任何单独一项都只能带来百分之几十的改善，叠加在一起才效果显著。

顺便一提，DeepSeek 还开源了一些新的代码仓库，以便更轻松地部署 V4.1 Flash 及后续开源模型：

• deepseek-recipe：是一组 Rust 库和 Python bindings，可将不同格式的 API 请求统一转换为 Conversation 格式，将其编码为 DeepSeek 模型的提示，并将模型输出转换为相应格式的响应。使用这些组件将推理后端连接到支持多种格式的 API 服务。https://github.com/deepseek-ai/deepseek-recipe
• DeepJIT：一个轻量级、仅头文件的 C++20 JIT 运行时，面向 NVIDIA CUDA GPU 和华为昇腾 NPU。它为 C++/Python 扩展作者提供了一个共享接口，用于在运行时编译内核源代码、缓存生成的二进制文件、将其加载到设备上，并使用后端特定的选项启动它们。https://github.com/deepseek-ai/DeepJIT
• DeepSelect：是 DeepSeek 稀疏注意力（DSA）（用于 DeepSeek V3.2、DeepSeek V4 和 DeepSeek V4.1 模型）中所用 TopK 内核以及采样器的高性能实现。与原生 torch.topk 相比，它实现了 2 ~ 20 倍的加速。https://github.com/deepseek-ai/DeepSelect

再顺便一提，DeepSeek 已开始灰度测试语音交互。

本文来自微信公众号“机器之心”（ID：almosthuman2014），作者：Panda，36氪经授权发布。