参数几乎翻倍，推理反而更省：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 Predic