DeepSeek V4.1 Flash | 长程 Agent 的成本，开始由 KV Cache 决定
DeepSeek V4.1 Flash | 长程 Agent 的成本，开始由 KV Cache 决定
原始报告：DeepSeek-AI，《DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression》
https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/blob/main/DeepSeek_V41_Tech_Report.pdf
如果只看名字，DeepSeek V4.1 Flash 很容易被理解成又一个“更快的小模型”。报告讲的事情其实更具体：当模型变成会调用工具、会持续处理代码仓库和网页、会跑很多轮的 Agent 后，瓶颈已经不只是每次生成一个 token 要算多少 FLOPs，而是此前上下文留下的 KV Cache 要如何保存、搬运和恢复。
这也是为什么报告的主线不是再堆一种新的推理技巧，而是围绕一条很工程化的问题链展开：
- Agent 的上下文不断增长，未命中缓存时，重新读入上下文的 prefill 很贵；
- 命中缓存后，缓存本身仍要占 HBM、主存或 SSD，还要在机器之间传输；
- 稀疏注意力已经显著降低了“看全上下文”的计算量，于是 KV 的存储和搬运反而越来越突出；
- 因此，V4.1 Flash 同时改了 prefill 的计算路径、全局 KV 的跨层复用，以及持久化缓存的恢复方式。
报告给出的模型规模是 552B backbone parameters，支持 1M context；但更应该关注的是每 token 激活参数：prefill 为 8B，decode 为 16B。这里的 “Flash” 并不意味着总参数最少，而是它试图把长上下文 Agent 的主要系统成本压下来。
1. 先把问题说清楚：长程 Agent 到底贵在哪里
1.1 一轮 Agent 任务里，其实有三种不同的成本
对普通聊天来说，几十轮以内的上下文通常还不至于让 KV Cache 成为第一问题。但对代码 Agent、浏览器 Agent 或企业流程 Agent 来说，模型会反复经历“读历史—调用工具—把工具结果塞回上下文—继续读”的循环。
这时可以把成本拆成三部分：
- Prefill：模型第一次读入一段新上下文，并为它计算 KV Cache。工具返回很长、缓存失效、或者切换机器后要恢复任务时，这部分会重新出现。
- Decode：模型基于已有上下文逐 token 生成答案、命令或下一步工具调用。
- KV Cache 的存储与迁移：长任务不能只把缓存放在单张 GPU 的 HBM 里；缓存需要持久化到主机内存或 SSD，也可能跨节点搬运。此时容量和带宽都会变成吞吐限制。
这里的 KV Cache 可以粗略理解为：模型读过历史 token 后留下的一份“可直接复用的注意力记忆”。下次生成时不必从头重新计算每个历史 token 的 Key 和 Value，但代价是这份记忆会随上下文长度增长。
图 1。先看右图：报告把 V4.1 Flash 的全局 KV Cache 标成 890 bytes/token，约为 V4-Flash 的四分之一。左图则放了 Agent 基准表现。两张图并列的意思不是“缓存更小必然分数更高”，而是作者要说明：压缩缓存之后，模型并没有只换来成本下降，也维持了较强的 Agent 能力。
一个容易被忽略的点是：运行时 KV 和 持久化 KV 不是同一回事。
运行时 KV 常驻在 HBM 中，直接影响单机能同时服务多少长上下文请求；持久化 KV 则被放到主存或 SSD，供后续回合或迁移恢复使用。前者主要受显存容量限制，后者还会受到 I/O 和网络带宽影响。报告后面“约四分之一”和“约八分之一”这两个数字，分别对应这两层问题，不能混在一起看。
1.2 稀疏注意力解决了一半，剩下的一半变得更显眼
DeepSeek V4 的路线是把注意力分成两支：局部的 Sliding-Window Attention（SWA）只看最近窗口；全局分支用稀疏方式，从很长的历史里挑少量位置读取。
SWA 的缓存上限由窗口大小决定，窗口固定时不会随上下文无限增长。真正会随序列增长的，主要是全局分支的 KV。因此，当稀疏注意力已经让全局检索的算力下降后，长期保存这部分 KV 的空间和搬运开销就会更刺眼。
图 2。横轴是 context length，纵轴是生成一个 token 的加权 FLOPs。要看的不是某个点绝对值，而是曲线斜率：V4.1 Flash 从 4K 扩到 1M context 时，decode FLOPs 只小幅增长；V4-Flash 的曲线则更明显上扬。报告将不同精度的操作按 BF16=1、FP8=0.5、FP4=0.25 加权，因此这不是通用硬件上的真实延迟图，而是计算量口径下的架构比较。
到这里，问题才完整：既要少算新上下文，也要少存、少搬旧上下文。V4.1 Flash 的三个核心设计正好分别对应这三个动作。
2. 第一步：CED 先减少“重新读一遍上下文”的计算
2.1 不是标准 encoder-decoder，而是给预填充阶段减半
报告把前半层 Transformer 看作 causal encoder，后半层看作 decoder。这里的 causal 仍表示只能看当前位置之前的 token，并不是把输入和输出完全分成两段的传统机器翻译式 encoder-decoder。
设模型一共 $L$ 层，输入长度为 $N$。常规做法中，每一层都要为全部 $N$ 个输入 token 形成自己的全局 KV。CED 的变化是：前 $L/2$ 层照常计算；对于后 $L/2$ 层，全局 KV 不再从该层自己的隐藏状态生成，而是直接从第 $L/2$ 层的输出投影出来：
\[C_l = H_{L/2}W^{KV}_l,\qquad Z_l = H_{L/2}W^{Z}_l,\qquad l>\frac{L}{2}.\]这里 $H_{L/2}$ 是 encoder 最后一层对整段输入的表示；$C_l$ 是第 $l$ 个 decoder 层使用的压缩全局 KV 表示，$Z_l$ 是对应的压缩权重；$W_l^{KV}$ 与 $W_l^Z$ 则是该层各自的投影参数。公式想表达的不是某种复杂的数学目标，而是一件很朴素的事：后半层不必各自把整段 prompt 再跑一遍，仍可以拿到供全局注意力使用的记忆。
图 3。阅读顺序可以从下往上看。40 个 Transformer block 被分为 20 层 causal encoder 和 20 层 decoder；encoder 产生的表示向上投影为 decoder 的全局 KV。图中 decoder 仍保留局部 SWA 路径，因此“只算半个模型”并不等于后半层完全消失，而是把昂贵的全局 KV 生成改成复用 encoder 的结果。
对于 $N\gg n_{\text{win}}$ 的长输入，报告给出的 prefill 复杂度近似从
\[O(NL)\]变成
\[O\left(N\frac{L}{2}+n_{\text{win}}\frac{L}{2}\right) \approx O\left(N\frac{L}{2}\right).\]其中 $n_{\text{win}}$ 是 SWA 的局部窗口大小。这个近似成立的前提很明确：输入足够长，窗口项相对于 $N$ 可以忽略。因此 CED 特别适合“工具结果很长、每轮新输入很多”的 Agent，而不是声称对任何短 prompt 都会获得同样接近一半的收益。
2.2 局部注意力仍需要状态：有界回放是在省存储，不是在凭空消失
CED 没有把所有计算都砍掉。为了保持局部建模能力，SWA 的 KV 仍然是逐层形成的。问题在于：如果要精确恢复 decoder 各层的 SWA 状态，理论上需要重放最近 $L\times n_{\text{win}}$ 个 token。
DeepSeek V4.1 Flash 采用了 SWA Bounded Replay：恢复时只重放最近 $n_{\text{win}}$ 个 token，而不是每层都沿着窗口继续展开。它用一小段重新 prefill 来近似重建需要的局部状态，于是不必把所有 SWA KV 持久化到 SSD。
这也是报告把持久化 KV 降到 V4-Flash 约八分之一的关键原因：一部分来自全局 KV 更小，另一部分来自不再长期保存 SWA KV。代价也不能略过——这是近似恢复。报告只在已评估设置中观察到很小的性能影响；在极端长程依赖、缓存断点附近或未覆盖的输入分布上，状态误差仍可能累积，这也是报告在局限性中明确提到的边界。
3. 第二步：CSA2 不是只做稀疏，而是让层与层共享“怎么找记忆”
3.1 先理解全局稀疏注意力里重复了什么
长上下文的全局注意力通常不会对每个 query 和全部历史 token 做完整计算，而是先用一个轻量 indexer 从历史中选出 Top-K 个候选位置，再让主注意力读取这些候选 KV。
如果每一层都独立完成这件事，至少会有三类重复：
- 每层都保存一份全局 main KV；
- 每层都保存或计算用于检索的 indexer K；
- 每层都对长历史重新打分，得到自己的 Top-K 索引。
报告把压缩视为三个相乘的维度：减少单个 KV entry 的字节数、减少序列维度上的 entry 数、以及减少层维度上的重复。前两种做法已经比较常见；CSA2 的重点是第三种，即跨层复用。
3.2 Full、Reindex、Reuse：把“建库、检索、读取”拆开复用
CSA2 为每个注意力层静态指定三种模式。它们都保留当前层自己的 main Q 和局部 SWA KV；区别只在全局 KV、检索 key 与 Top-K 索引从哪里来。
图 4。按从上到下读即可。绿色是当前层新计算的量，黄色是从最近 Full 层复用的 main KV 与 indexer K，红色是从最近一次 Full 或 Reindex 复用的 Top-K 索引。关键是三种模式不是“有无注意力”的区别，而是对建库、重新排序、直接读取这三项工作做不同粒度的复用。
- Full Mode：当前层完整生成 main KV，投影 indexer K，用自己的 indexer Q 扫描并得到新的 Top-K。它相当于建立一份新的全局记忆基准。
- Reindex Mode：不再生成新的 main KV 和 indexer K，而是复用最近 Full 层的那一份；但它用自己的 indexer Q 重新打分，得到自己的 Top-K。这样“库”可以共用，层的检索偏好仍可不同。
- Reuse Mode：连 Top-K 也直接沿用最近一次产生索引的层；它只计算自己的 main Q、局部 SWA KV，并对同一批全局位置做注意力。这样最省索引计算，但也最依赖此前的选择没有漏掉关键信息。
这三种模式把一个很大的取舍拆得更细：完全逐层独立，效果上最自由但最贵；全层共享同一套 Top-K，最便宜但可能太死；CSA2 则在中间插入 Reindex，让一部分层能换检索结果，而不需要重新建全局 KV。
报告同时把全局 KV 用 FP4 存储。精度压缩和跨层复用是叠加的：前者让一份缓存更小，后者让需要存的“份数”更少。最终，报告给出的运行时全局 KV 体积是 890 bytes/token，约为 V4-Flash 的四分之一。
3.3 分层索引：只有第一层全量扫，后续层在候选池里找
即使已经有 Reindex，重新检索的层如果仍要对 1M 个位置逐个打分，成本还是会随 context 增长。于是报告又加了 Hierarchical Sparse Indexer。
图 5。最上面的 Full Mode 先看完整历史：绿色方块是它选出的 Top-512，蓝色框表示这些高分位置所在的 block。中间和下面的 Reindex Mode 不再遍历全部位置，而只在蓝框覆盖的共享候选池中选自己的 Top-512。要注意：后续层共享的是“搜索范围”，不是强制共享最终 Top-K。
具体过程是：
- decoder 中第一个 Full Mode 层对所有可见的全局 KV 位置打分；
- 它一边选出自己要读的 Top-K，一边按 block 聚合分数：一个 block 的分数取内部位置的最大值；
- 选出高分 block，拼成比最终 Top-K 更大的候选池。报告举例：选 2,048 个 block、每个 block 8 个位置，会得到 16,384 个候选位置；
- 后续 Reindex 层只在这 16,384 个位置里用自己的 query 重新选 Top-K；Reuse 层则继续复用已有索引。
这一步为什么能让 decode 对上下文长度不敏感？因为第一层仍要全局扫描，但后续 indexer 的评分数量被候选池上限固定住了。随着 context 从 4K 变成 1M，后续层不会再按 256 倍的历史长度重复扩大检索工作。
代价也同样明确：如果第一层建候选池时漏掉了某段真正重要的历史，后续 Reindex 层就没有机会把它找回来。报告称训练和推理都使用同样的候选限制，目的是让后续层适应这个搜索空间；但这并不能替代对超长稀疏检索失败案例的压力测试。
4. 第三步：缓存小了之后，还要让模型与系统真的跑得动
4.1 单 token 的 decode 曲线，来自一组叠加而非单点技巧
CED 主要处理 prefill，CSA2 主要处理全局 KV 与索引。报告还放入了几项不那么显眼、但会影响实际吞吐的设计：
- Single-Pass mHC：把当前 block 使用的输入混合系数改为前一个 block 产生的系数，解除 kernel fusion 的数据依赖。报告称 Mega-mHC 可将原实现的 activation memory traffic 减半。
- Engram：把部分记忆能力放在稀疏访问的条件记忆模块中。它有 196B 参数，但并不意味着每个 token 都激活这些参数；表格里的 backbone parameters 和 activated parameters 也应与这类模块区分开看。
- DSpark：用半自回归草稿生成和置信度调度验证做 speculative decoding，目标是减少真正需要目标模型逐 token 验证的次数。
这些组件不是 V4.1 Flash 最值得读的理论创新，但它们解释了一个现实：模型架构上的节省，只有落到 kernel、通信与内存访问上，才会成为服务成本上的节省。报告提到 CSA2 的 Reuse Mode 层在 prefill 使用 15 个 kernel、decode 使用 11 个 kernel；这是部署实现层面的指标，不该直接等同于任何硬件、任何 batch size 下的端到端延迟。
4.2 “Flash”不等于所有阶段都比前代少算
下面这张 base model 表也值得看，因为它纠正了一个过于简单的叙事。V4.1 Flash 的 backbone 有 552B 参数，明显大于 V4-Flash Base 的 284B；decode 激活参数是 16B，也高于 V4-Flash 的 13B。它所换来的，是 prefill 时只激活 8B，以及更小的 KV footprint。
表 1。先看表头的三行：V4.1 Flash Base 的 backbone 是 552B，prefill/decode 激活参数为 8B/16B；V4-Flash Base 是 284B/13B，V4-Pro Base 是 1T/49B。再向下看，报告的内部评测中，V4.1 在代码、数学和多模态项目上总体接近或优于 V4-Pro Base，但长上下文 LongBench-V2 仍低于 V4-Pro。结论不应被简化成“参数更少、能力更强”，而应是它针对长程服务重新分配了参数、计算与缓存预算。
报告称，该模型在 45T 多模态 tokens 上预训练，并从 64K sequence length 起就训练稀疏注意力，没有先用 dense attention warmup。作者报告 V4.1 Flash Base 在其 held-out evaluations 上相对 V4-Pro Base 有 5%–10% 改善，同时使用约三分之一总参数和四分之一激活参数。由于这些 held-out 集的构成没有完全公开，这个结论更适合被理解为作者的训练内证据，而不是跨模型的独立排名。
5. 后训练部分的重点不是新算法，而是让 Agent 见过更多真实结构
5.1 报告把能力增长归因于数据、环境与 rollout 的扩展
在 post-training 上，报告反而说得很直白：采用的是 SFT、RL 与 on-policy distillation 的常规路线，没有宣称新的 RL 算法。变化主要放在数据生产和环境构造。
通用 Agent 数据来自真实工作流中的工具接口、失败反馈和多轮交互，再被重建成可复现的 mock environment；代码 Agent 环境则从复杂会话和公开 GitHub 仓库中构造，要求容器可运行、任务可验证，并由多个 agent 做环境搭建、求解、质检和修复。这里值得注意的不是“用了多少 agent 造数据”，而是训练目标从单个回答变成了带工具、带状态、带验证器的过程。
图 7。四个子图分别是 DeepSWE v1.1、SWE-Bench Pro、Terminal-Bench v2.1 和 v3.0。实线看 Pass@1，虚线看输出 token 数。图想说明两件事：更多 RL steps 仍带来提升；在最右侧 Terminal-Bench v3.0 上，最大 context 从 512K 增至 1M 也有额外收益。虚线同时提醒我们，这些提升伴随着更长轨迹，不能只看准确率。
5.2 Scaffold 多样性，是在防止模型只会一种“做题姿势”
Agent 能力很容易被某个固定 harness 放大或限制：系统提示词、工具 schema、上下文压缩方式、轮次控制都会影响结果。如果训练和评测只在一种框架里完成，模型可能学到的是某套交互惯例，而不是真正稳定的工具使用能力。
图 8。左图把多个 Claude Code 版本一起训练，右图混合 OpenCode、Pi 和不同 DeepSeek Harness 设置。深色线是联合训练后的总体表现，浅色线是单一 scaffold 或版本。作者据此主张：把交互协议做得更多样，RL 的收益仍可继续累积。这个图并不能单独证明因果关系，但至少说明报告没有只用单一 harness 来展示训练曲线。
这种训练方式也让“性能属于模型还是属于 harness”变成一个应当正面回答的问题。报告后面给了跨 scaffold 的评测，算是对这点做了必要补充。
6. 如何读结果：能力有提升，但不要把所有 benchmark 混成一个结论
6.1 相对 V4-Flash 的提升最明确；对顶级闭源模型仍是分任务看
表 3。先纵向看 V4-Flash 与 V4.1 Flash 两列：DeepSWE v1.1 从 54.4 到 74.2，Terminal-Bench 2.1 从 82.7 到 90.6，Codeforces rating 从 3289 到 3471，这是最直接的代际改进。再横向看其他模型：V4.1 在 Terminal-Bench 2.1、DeepSWE、CyberGym 等任务很强，但 Terminal-Bench 3.0/4.0、HLE、视觉 Agent 项目上并不全面领先。不同 benchmark 的 harness、预算和评价设置并不完全相同，因此不宜把其中某一个最高分外推成笼统的“全面超越”。
几个具体结论可以相对稳妥地读：
- 对前代 V4-Flash，报告中的 Agent 任务增幅很大，尤其 DeepSWE v1.1 为 74.2 对 54.4，Terminal-Bench 2.1 为 90.6 对 82.7。
- 对 DeepSeek V4-Pro，V4.1 在 Codeforces（3471 对 3348）和部分 Agent 基准上更高，但并不在每个项目都占优。
- 对表内闭源模型，V4.1 在 Terminal-Bench 2.1、DeepSWE、AutomationBench 等单项上有竞争力；而在 Terminal-Bench 4.0 这类更偏科学与专家知识的任务上，仍显著落后于 Opus-5 和 GPT-5.6 Sol。
报告自己也承认这条边界：日常 coding 和白领工作流已可覆盖很多场景，但在需要专家级领域知识的科学型 Agent 任务上还有差距。这个说法比“能完成 95% 真实任务”更值得参考，因为后者缺少可复核的任务分布与统计口径。
6.2 reasoning effort 是一个可用的成本旋钮，而非免费提升
报告在 RL 时向 system prompt 加入 $b\in[1,100]$ 的 scalar effort。较高 $b$ 会降低长度惩罚，让模型有空间输出更长的推理与探索轨迹；不同 effort 下的样本在各自子组内计算相对优势，而不是直接把低 effort 和高 effort 的回答拿来比较。
图 9。每个子图的实线对应 Pass@1，虚线对应平均输出 token 数；横轴从 effort 25 增至 100。三个任务上分数都上升，但 token 数也明显增长。报告给出的汇总是：八个推理基准的平均 Pass@1 从 67.1% 到 76.3%，DeepSWE 从 66.0% 到 74.2%，Terminal-Bench 2.1 从 82.4% 到 90.6%，代价约为 2.5 倍输出 tokens。
对实际使用者更有价值的信息在边际收益上：报告认为 effort 60–80 已拿到大部分最大 effort 的准确率，而到 100 时，Agent 轨迹会再长 1.6–1.8 倍，提升则变得有限。因此 API 中 low/high/max 映射为 $b=50/75/100$，应该被看成服务质量与 token 预算的操作点，而不是同一个模型的“免费档位”。
表 4。保持 checkpoint、解码参数和任务集不变，只替换 Claude Code、Codex、OpenCode、Pi、mini-SWE 与 DeepSeek Harness 等外围框架。DeepSWE 的区间为 65.5–74.2，Terminal-Bench 2.1 为 84.1–90.6。它说明模型并未只在某一种框架下工作；但 8 个配置之间仍有明显差距，也说明部署时 scaffold 不是可忽略的“外壳”。
6.3 多 Agent 曲线值得看，但目前仍是初步结果
图 10。横轴是每次 rollout 的墙钟时间上限，纵轴分别是 ProgramBench 的 Almost@1 与 FrontierSWE v2 的 Mean@5。两项任务上，多 Agent 曲线都高于单 Agent：ProgramBench 在 8 小时处为 30.04% 对 20.39%，FrontierSWE v2 在 20 小时处为 32.90% 对 28.20%。但这是作者挑选的最强配置之间的 preliminary comparison，不应直接读作“多 Agent 必然更好”。
这部分实验真正传达的是：当任务预算从一次模型回复变成数小时的工具执行，多 Agent 的价值可能来自并行探索和分工，而不是单个模型突然更聪明。但相应地，协调、共享工作区、消息同步和截止时间都会成为算法的一部分。
7. 这份报告真正给出的启发，与仍未回答的问题
7.1 最值得带走的是一套成本建模方式
V4.1 Flash 最有价值的地方，不是某个单独模块，而是它把长上下文 Agent 的成本拆成了可分别优化的对象：
| 约束 | 对应设计 | 解决的不是 |
|---|---|---|
| 新上下文读入太贵 | CED + decoder SWA bounded replay | 单纯减少输出 token |
| 全局 KV 太大 | CSA2 跨层复用 + FP4 KV | 只降低注意力算力 |
| 长上下文检索反复扫描 | Hierarchical Sparse Indexer | 让所有层共享同一检索结果 |
| 缓存要跨回合保留 | 不持久化 SWA KV、恢复时有限重放 | 永久不再计算 |
| 模型在单一工具框架里过拟合 | 多环境、多 scaffold 的 RL | 不需要评测 harness |
这张表也解释了为何“更长 context”本身不是完整答案。上下文窗口做到了 1M，如果缓存必须按层完整保存、每层都重新索引、缓存恢复还要精确重放所有局部状态，服务系统依然会被显存、SSD 与网络拖住。
7.2 它的风险也恰好藏在最省钱的地方
报告的节省都有对应的假设：
- CED 假设 encoder 中间层的表示足以为 decoder 生成有效的全局 KV；
- Reuse Mode 假设相邻层可以共用一批被检索到的位置；
- Hierarchical Sparse Indexer 假设第一层构造的候选池不会漏掉后续层真正需要的信息；
- Bounded Replay 假设只重放一个局部窗口就能近似恢复所需的 SWA 状态；
- FP4 KV 假设极低精度存储不会在关键长程任务上造成不可接受的误差。
这些不是理论上无代价的压缩。报告已把 CSA2 的 selection error 和 Bounded Replay 的近似状态恢复列为尚需继续做压力测试的边界。更完整的后续验证，应该包括：对针尖式长程信息检索的对抗样本、跨缓存恢复点的一致性、不同 I/O 条件下的端到端吞吐，以及真实长任务的成本曲线，而不只是单 token FLOPs 或单一 benchmark。
结语
如果把这份报告只概括成“DeepSeek 又发布了一个更强的 Flash 模型”，会漏掉最重要的部分。它真正处理的是：当 Agent 工作流越来越长时，模型能力之外的 KV Cache 已经变成产品可用性的一部分。
CED 让输入阶段少跑一半左右的全局计算；CSA2 让全局缓存和检索决策在层间以不同粒度复用；Bounded Replay 则把持久化缓存从“完整保存状态”改成“保存更少、需要时小范围重算”。三者拼在一起，才得到报告中运行时全局 KV 约为前代四分之一、持久化 KV 约为前代八分之一的结论。
对做模型服务的人来说，这比一个漂亮的参数量或单项分数更接近实际问题：未来的竞争不只是模型能不能完成任务，也是谁能以可恢复、可迁移、可承受的缓存成本，让它把任务做得足够久。
如果你对 MoE、KV Cache、长上下文推理这些问题感兴趣，可以看看我的新书《大模型基础与前沿：从 Transformer 到 Agent》。书里尝试从 Transformer 的计算图出发，把注意力、推理、训练与 Agent 系统里的概念放在同一套框架下解释；和本文一样，更关心“一个设计究竟在解决哪一类约束”。
