arXivDaily arXiv每日学术速递 周一至周五更新

PAPERDAILY REPORTS

DeepSeek新模型把KV缓存压到1/4,百万Token智能体更省内存

作者:arXivDaily编辑部 arXiv 2609.19969 cs · cs.CL

论文导读

DeepSeek推出多模态模型DeepSeek-V4.1-Flash,主干参数为552B,最长支持100万Token上下文。它把全局KV缓存降到每Token 890字节,约为DeepSeek-V4-Flash的1/4;持久缓存约降到1/8,让长时间运行的智能体明显少占显存、主机内存和SSD存储空间。

上下文越长,真正堵住部署的是缓存

智能体连续调用工具时,提示词、页面结果和历史动作会不断回填模型。计算只是开销的一部分,每层注意力保存的Key和Value还要长期驻留显存,或被搬到主机内存与SSD。上下文拉到百万Token后,缓存容量和传输带宽会直接限制并发量。

DeepSeek-V4.1-Flash给出的关键数字是每Token 890字节全局KV缓存。论文把它与历代DeepSeek模型放在同一口径下比较:相对V4-Flash约缩小3.9倍,相对V1缩小437倍。这个数字描述缓存结构,不等同于整套服务的实际显存占用。

图1:官方模型卡展示每Token全局KV缓存从DeepSeek-V1到V4.1-Flash的变化。

先算一半层,再让后半层复用上下文

模型采用因果编码器—解码器结构。40层网络分成20层编码器和20层解码器;处理长输入时,编码器先生成隐藏状态,解码器的全局KV由这些状态投影得到,不必让全部提示Token再完整跑过后20层。预填充阶段每Token激活8B参数,解码阶段激活16B参数。

另一项压缩来自CSA2稀疏注意力。部分层生成全局KV和检索索引,后续层可以只重新打分,或连索引一起复用;全局KV再用FP4保存。滑动窗口部分则通过“有界重放”按需重建,避免把全部局部缓存持续写进SSD。

图2:论文比较不同DeepSeek架构随上下文长度增长的单Token解码计算量。

从缓存压缩走向生产部署

团队在多组推理、代码、智能体和多模态基准上报告结果。DeepSWE v1.1为74.2,Terminal-Bench 2.1为90.6,AutomationBench为54.8;同一表中也能看到它并非所有任务都领先,例如更强调专家知识的Terminal-Bench 4.0仍落后于更大的闭源模型。

图3:官方模型卡列出的四项智能体基准对比,蓝色为DeepSeek-V4.1-Flash。

模型权重已放在官方Hugging Face页面,采用MIT许可证。部署端仍要计算路由专家、视觉编码、批处理和通信开销,论文的缓存比例不能直接换算成云端账单。对推理系统团队更实际的下一步,是在真实长轨迹、缓存命中和多用户并发下测吞吐、首Token延迟与SSD读写,确认架构收益能否完整落到生产环境。

还需要把运行时缓存与模型权重、激活值和专家通信分开计量。同一模型在单请求、连续批处理和前缀复用下,瓶颈可能分别落在显存容量、内存带宽或网络通信。只有公开端到端服务数据,开发者才能判断890字节这一结构指标最终换来了多少并发会话和每秒Token。

不同上下文长度下的功耗和故障恢复成本,也应进入同一套部署测试。

参考资料

https://arxiv.org/abs/2609.19969

https://arxiv.org/html/2609.19969

https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash