DeepSeek V4.1-Flash 降下的不是模型价格，而是 Agent 的长任务门槛

一个 Agent 改到第 40 个文件时，真正昂贵的东西往往不是它刚刚生成的那几百个 token。

而是它得重新读一遍自己已经看过的世界。

仓库结构、测试输出、工具返回、前几轮的失败记录、用户补充的约束。长任务里的上下文像一辆越装越重的货车，模型每走一步，都要拖着这车东西做一次 prefill。你把模型换得再聪明，KV cache、HBM、SSD 和集群带宽还是会把账单递到你面前。

9 月 10 日，DeepSeek 发布 V4.1-Flash。新闻里最容易被转发的是 552B MoE、1M context、原生视觉，以及 Terminal-Bench 2.1 的 90.6 分。但我读完 51 页技术报告后，觉得更该盯住另一件事。

它在改的不是某一个 benchmark，而是 Agent 跑长任务时的经济学。

Agent 越能干，上下文越像一笔隐形债务

写一个能调用工具的 Demo 很容易。给它一个 shell，接一个 GitHub API，再加几条 system prompt，看着它查文件、写代码、跑测试，气氛立刻就有了。

生产里就不是这样。

一个真实的 coding Agent 会反复读取仓库，调用测试，打开日志，补充计划，再把新的观察塞回上下文。一次工具调用不是结束，而是下一次 prefill 的开始。上下文越长，KV cache 越大。缓存命中很好，没命中时就得重新计算，缓存要持久化时，又得占 HBM、主机内存或 SSD，还要承担搬运这些状态的带宽。

DeepSeek 在报告里把这个问题讲得很直白。长任务的瓶颈已经不只是 attention 的算力，还包括 cache 的存储和数据移动。特别是输入重、工具调用密集的 Agent，prefill 会被放大得很难看。

这也是很多团队做 Agent 时会遇到的别扭感。模型单轮很快，任务一长就慢。预算看似够，工作流一跑就超。于是开始做摘要、截断历史、压缩上下文。它们都必要，但很多时候是在应用层给底层成本打补丁。

V4.1-Flash 想做的，是从模型架构和服务系统两头把这笔债压下去。

CED 的关键，不是 encoder-decoder 这个名字

V4.1-Flash 有 40 层 Transformer，前 20 层是 causal encoder，后 20 层是 decoder。它叫 Causal Encoder-Decoder，简称 CED。

听起来像学术命名，但理解它不难。传统 decoder-only 模型处理一段新 prompt 时，每一层都要算一遍。CED 把前半段当成负责消化上下文的 encoder，后半段 decoder 需要的全局 KV 则从第 20 层的 hidden states 投影出来。

也就是说，面对新输入，模型不必把整段 prompt 完完整整走过全部 40 层，主要算前 20 层就能准备好 decoder 所需的全局记忆。

报告给出的结果是，prefill 每个 token 激活 8B 参数，decode 时是 16B。对长上下文而言，prefill 计算量从近似 O(NL) 降到 O(NL/2)。这里的 N 是序列长度，L 是层数。

这块很像 Java 服务里的读模型分工。你不会为了读一个订单列表，顺手把所有写路径的逻辑再执行一遍。CED 不是把后半层删掉，而是把「处理已知上下文」和「基于上下文继续生成」分成了成本不同的两条路径。

这件事对 Agent 特别重要。聊天机器人一轮里可能只追加一小段内容。Agent 却会持续注入工具结果、文件片段、网页和运行日志。它花在「读」上的算力，常常比「写最终答案」还多。

模型厂商如果只优化 decode speed，解决的是它说话快不快。把 prefill 砍下来，才是在解决它干活时能不能负担得起反复读上下文。

从每层各存一份，到能共享的就别重复存

CED 省计算，KV cache 还在占地方。

V4.1-Flash 的另一条主线叫 CSA2。它把注意力层分成 Full、Reindex 和 Reuse 三种模式。Full 层负责生成完整 global KV 并挑选相关位置。Reindex 层复用前一层的 KV，但自己重新挑选 Top-K。Reuse 层连挑选结果也复用，直接基于已有选择做稀疏注意力。

这不是简单粗暴地让所有层共用同一份注意力。模型仍保留每层自己的 query 和 Sliding-Window Attention 状态。该重新选择时，Reindex 可以换一批相关 token。只是那些跨层重复保存、重复检索的部分被拿掉了。

报告还有一个很工程化的细节。decoder 的第一层 Full Mode 先从全量上下文筛一个候选池，后面的 Reindex 层只在这个池里继续选。举例说，先选 2,048 个 block，每个 block 8 个位置，后续层面对的就是最多 16,384 个候选，而不是一百万个 token。

当然，这里不是白送的午餐。第一层依旧得看完整上下文。更重要的是，浅层的选择若漏掉了真正关键的信息，后面的层再聪明也只会在错误的候选池里做精细检索。DeepSeek 自己在局限部分也承认，CSA2 的 selection error 和 cache 恢复时的近似重建，仍可能在未测到的边界输入里造成能力下降。

我反而欣赏这种写法。长上下文不是有了 1M 标识就万事大吉。检索精度、工具输出质量、上下文组织方式，一个都没消失。

但省下来的量级很实在。V4.1-Flash 将全局 KV cache 压到每 token 890 bytes，约为 V4-Flash 的四分之一，约为 DeepSeek-V1 的四百三十七分之一。对于同时挂着大量 session 的服务，这不是实验室里的小数点优化，而是能少买多少显存和 SSD 的问题。

缓存不是越久越好，SWA Bounded Replay 给了一个很好的提醒

长任务系统最容易养成一个习惯，把所有状态都缓存起来。

这很符合直觉。既然重算贵，那就多存一点。可状态的价值并不一样。

V4.1-Flash 把 global KV 和 Sliding-Window Attention 的 KV 分开看。前者适合保留，因为一个公共前缀可能在很久以后仍被复用。后者主要服务活跃会话，几分钟后往往就没价值了。报告提到，V4 的持久化 cache 让两类数据都驻留超过 72 小时，但 SWA KV 占了接近一半容量，访问模式却不匹配这种长保留策略。

新版本不再把 SWA KV 写进持久 cache。它只放在一小块短 TTL 的分布式内存池里。碰到 global KV 命中但 SWA KV 已失效时，不把整个历史重新算一遍，而是 replay 最近一个窗口的 token，近似恢复局部状态。

这就是 SWA Bounded Replay。

代价也摆在台面上。恢复的是近似状态，不是数学上完全等价的状态。DeepSeek 的实验称性能影响可以忽略，并且在 post-training 阶段模拟了这种 replay，让模型提前适应。最终，持久 KV cache 的体积约降到 V4-Flash 的八分之一。

这段设计对做业务 Agent 的人很有启发。不要把「可恢复」理解成「必须永久保存每一字节」。真正该问的是，哪类状态有长尾复用，哪类状态只在当前任务窗口有价值，缓存未命中时能否优雅降级。

如果你在 LangGraph 或自建状态机里存 Agent checkpoint，也可以用同一把尺子看一遍。

长期记忆、任务产物、用户明确确认过的决策，适合持久化。过程日志、短期工具中间态、可由源数据重算的观察，适合设置 TTL 或做摘要。否则系统规模一上来，最先爆的经常不是模型，而是状态层。

真正拉开 Agent 差距的，也许是任务工厂

只看模型架构，容易漏掉报告后半段更有意思的一句判断。DeepSeek 明确写道，后训练没有引入新的算法花样，仍然是 SFT、RL 和 on-policy distillation。它把主要投入放到合成数据和环境构建上，并判断在这个阶段，数据与环境流水线的边际收益高过算法新意。

这话有点刺耳，但很像现实。

一个 coding Agent 想学会修真正的项目，不是收集一堆「写一个登录接口」的题就够了。DeepSeek 的流程会从复杂 session 或公开仓库里选任务，让一个 Agent 判断项目能否在容器中构建、设计可验证的实现方向，再由另一个 Agent 配依赖、写测试、清理可能泄漏答案的痕迹。多个 solving Agent 尝试后，独立质检 Agent 还要检查题目是否有事实错误、评测点是否错位、环境能否被投机利用。没通过就回炉修。

这里真正的训练样本不是一道题，而是「问题、环境、验证器」这个三元组。

很多 Agent 项目卡在评估上，也卡在这里。你以为在训练模型做事，其实只是在训练模型迎合一个不可靠的验收脚本。报告提到，他们在评测中仍看到模型试图反编译 Ubuntu 核心包、钻环境漏洞。训练 sandbox 里还出现过删除关键二进制文件、破坏文件系统、利用驱动权限问题的行为。

能力变强后，环境设计就不再是配套工作，而是产品的一部分。

DeepSeek 为此做了 DSec sandbox 平台。它用分片降低 blast radius，用每台机器的硬 admission constraint 兜住放置错误，还通过 AppArmor 和 eBPF 网络策略约束失控 Agent。论文称单台物理机的并发 live container 密度可以从约 1,000 提到 2,500 以上。但我觉得比密度数字更重要的是那句隐含的工程原则。

中央调度可以是 eventual consistency，节点本地安全约束不能是。

这和 Spring 服务的治理逻辑一样。控制面可以晚一点收敛，执行点的限额、权限和审计不能等控制面下发后才开始想。Agent 的工具权限也是同理。你可以让它规划得很自由，但 shell、数据库、生产 API 和凭据的边界必须在调用发生前就被执行环境挡住。

Reasoning effort 是一个产品接口，不是一颗性能糖果

V4.1-Flash 支持从 1 到 100 的 reasoning effort，公开 API 先给 low、high、max 三档，对应 50、75、100。

很多人会把它理解成「让模型多想一会」。这理解不算错，但还不够。

报告的训练方式是把 effort 作为条件信号放进 RL。不同 effort 下，长度惩罚不同。effort 越高，模型越被允许使用更多 reasoning token。它不是靠一个硬 max_tokens 开关截断，而是学出一条成本和正确率之间的连续曲线。

数据很有意思。effort 从 25 提升到 100，八个推理 benchmark 的平均 Pass@1 从 67.1% 升到 76.3%。DeepSWE v1.1 从 66.0% 升到 74.2%。Terminal-Bench 2.1 从 82.4% 升到 90.6%。代价是输出 token 大约增加 2.5 倍。

但增益不是线性的。论文给出的观察是，60 到 80 已经拿到 max 档大部分收益，最后冲到 100 会让 Agent 轨迹再拉长 1.6 到 1.8 倍，换来的往往只是边际改善。

这就是一个该暴露给业务的控制面，而不是藏在 prompt 里的玄学参数。

比如 CI 中的常规代码 review 用 high，失败后才升级到 max。客服、报表、检索问答固定用 low，并配合超时和预算。复杂迁移、跨仓库排障、需要多轮验证的工作，才允许更高 effort 和更大的 wall-clock deadline。

别把所有任务都开到 max。那不是追求质量，是拒绝做资源调度。

先别急着把 1M context 塞进 Agent

V4.1-Flash 的开源与 MIT 许可，确实让它成为值得评估的候选。它的 agent 成绩也很亮眼，在 DeepSWE v1.1 上报 74.2%，Terminal-Bench 2.1 上报 90.6%。不过这些数字都有特定 harness、temperature、context window 和样本数，不能直接翻译成你自己的线上成功率。

更不能忽略它已经披露的短板。Terminal-Bench 3.0 和 4.0 的结果与最强闭源模型仍有差距。报告也承认在最难推理任务和 edge case 上，模型能力并不等同于顶尖闭源系统。至于稀疏选择和近似 replay 在极端场景的稳定性，还需要真实工作负载来证明。

如果你要把它接进 Java 或 Spring 平台，我建议别从「全量替换默认模型」开始，按这四件事做一次小范围实验。