DeepSeek-v4.1 闪存：突破 KV 缓存压缩的极限

TL;DR DeepSeek-V4.1 Flash发布的时候，我以为这可能只是一个训练后的迭代版本...但是用了一段时间，发现速度达到了近420 Tokens/s，然后Cui说所有DeepSeek-V4 Pro模型都要下线...突然觉得这事非同小可...直到技术报告完全发布，我才意识到应该叫DeepSeek-V5 Flash...正如论文标题所说，目的DeepSeek-V4.1 Flash的核心就是将KVCache压缩推向极致。主要原因是Long-horizo​​n Agent Workflows导致Context变得越来越长，而各种工具调用带来了沉重的预填充计算压力。 KVCache在HBM和外部SSD中的存储压力非常大，这些都是导致Scaling无法进行的原因。因此，在模型架构上进行了一系列的优化，尤其是KVCache的压缩和Prefill的计算优化。 Prefill计算优化：借鉴YOCO，整个模型有40层，Prefill时只需要20层。因此，Prefill激活的参数只有8B，Decode激活的参数为16B KVCache压缩：从工程上来说，KVCache压缩分为几个维度：类似GQA的头数压缩，然后是像CSA这样的基于块的压缩，以及本文中CSA2的跨层压缩。同时，Sparse Attention的索引器计算也得到了优化。最后还有一些数值精度的优化，比如DS41F采用了FP4 KVCache。最后，在模型保持高质量任务完成的前提下，KVCache进一步压缩了4倍：另外，论文原文写得有些复杂，尤其是CED的描述。事实上，如果我们以KVCache为中心，结合计算机架构的角度重新画一张图，似乎一下子就变得清晰了。它可以看作是一种Recursive Transformer架构，一种在递归过程中修改Q并重用KV的方式。关于Recursive Transformer架构，可以参考《On the Future Transformer: Loops Are Not What You Need》。接下来我们将根据技术报告的章节结构进行详细的解读和分析。本文是本系列的第一篇，详细分析了模型架构，比较关键的内容在第 3 章。 1. 概述 1.1 为什么需要 KVCache 压缩 首先，报告指出，近年来 Long-horizo​​n Agent 使超长上下文处理成为越来越重要的模型工作负载。支持此类工作负载不仅需要高效处理长序列，还需要大型 KVCache 的持久存储、复用和传输。因此，KVCache管理成为模型部署的基础能力，同时也带来了计算、存储和通信方面的重大挑战。然后介绍了 DeepSeek-V4 架构，该架构通过将完全覆盖上下文的稀疏注意力与覆盖本地窗口的滑动窗口注意力（SWA）相结合进行处理。尽管与稀疏注意力相关的进步显着降低了长序列处理的计算成本，但持久存储和数据移动逐渐成为更加突出的瓶颈。在长上下文中，Global KV Cache 的使用将占据主导地位，并且持续进行前缀复用，将大量占用 Host 内存容量和 SSD 容量，并且对 KVCache 移动的互连带宽提出很高的要求。这些限制了服务吞吐量，增加了部署成本，最终阻碍了智能体向更长的任务跨度和更广泛的应用场景的部署和推广。因此，进一步减少键值缓存占用空间对于缓解存储和通信瓶颈以及降低长上下文服务成本至关重要。 DeepSeek-V4.1-Flash 是一种多模式专家混合模型，专为更积极的 KVCache 压缩而设计。 DeepSeek-V4.1-Flash参数规模为552B，原生支持多模态输入，支持高达100万个token的上下文。它采用因果编码器-解码器（CED）架构，其中解码器的全局KVCache是​​通过投影编码器的最终隐藏状态获得的。这样的设计使得模型在 Prefill 阶段每个 token 激活 8B 个参数，在 Decoding 阶段激活 16B 个参数，这对于输入为主的 Agent 场景尤其经济高效。虽然DeepSeek-V4.1-Flash明显大于DeepSeek-V4-Flash，但在相同的序列长度下，其所需的运行时KVCache存储仅为后者的1/4左右，其持久性KVCache存储也仅为后者的1/8左右。此外，DeepSeek-V4.1-Flash的整体性能优于DeepSeek-V4-Flash。这些c