DeepSeek V4.1 Flash，为什么能接替上一代旗舰

文｜Sleepy.md

让 AI 修改一个软件项目，可能只需要发出一句话。但在这句话之后，它要自己找文件、读代码，改完再运行测试。测试失败了，还得接着查。

用户看到的是一次请求，后台可能已经调用模型几十次。

9 月 10 日，DeepSeek 发布 V4.1 Flash，并宣布从北京时间 9 月 14 日中午 12 点起，将上一代 V4 Pro 的 API 请求交给它处理，按 Flash 的价格计费，直到 V4.1 Pro 发布。

Flash 一直强调速度和价格，如今却开始承担起了旧旗舰的工作，它真的够用吗？

分数涨在哪里

先看几项成绩。

科学问答测试 GPQA Diamond 上，V4.1 Flash 得到 90.9 分。旧 Flash 89.9，旧 Pro 92.4。新 Flash 有进步，但还是没打过旧 Pro。

软件工程测试 DeepSWE v1.1 上的变化就完全是另一回事了。旧 Flash 54.4，旧 Pro 62.7，V4.1 Flash 74.2。

终端任务测试 Terminal-Bench 3.0，三个数字分别是 7.6、11.8 和 30.0。

这些都是官方公布的最高推理强度成绩。不同测试用了指定的软件框架，V4.1 Flash 的 DeepSWE 成绩来自 mini-SWE，Terminal-Bench 成绩来自 DeepSeek Harness Minimal。

三组数字摆在一起，能看出一个很清楚的规律。

问模型一段代码哪里有问题，和让它接手一个项目，需要的能力差着十万八千里。

接手项目之后，它得判断先看什么文件。改这一行，会不会把别的功能带坏。遇到报错，还要分清楚是代码错了，还是机器上没装东西。下一步做什么，取决于上一步发生了什么。

这是一套连续动作。每一步都得看上一眼的结果。

所以从这几项测试看，V4.1 Flash 相对上一代的突出进步，出现在需要连续操作和反馈的任务里。GPQA 这项科学问答测试的提升，则小得多。

不过有件事得说在前面。接替旧旗舰的 API，不等于每项能力都超过了旧旗舰。实际表现取决于任务是什么，也取决于外面那套工具怎么配。

备考比考试难

模型用的软件，会影响它怎么完成任务。

同样是改一个文件，有的软件给它配了专门的编辑工具，有的就只能让它敲命令行。操作失败以后，报错返回得全不全，也直接影响它下一步怎么判断。

负责组织模型、工具和交互流程的这层软件，业内管它叫 Harness。

V4.1 Flash 的强化学习覆盖了多种 Harness，DeepSeek 自己的、不同版本的 Claude Code，还有 OpenCode、Pi 这些。DeepSeek 还会把不同框架或配置下训出来的模型检查点合并起来，用到后续的强化学习里。

同一个模型，换套 Harness，成绩就变了。DeepSWE v1.1 上，mini-SWE 拿到 74.2，DeepSeek Harness Minimal 是 72.6，Claude Code 是 69.8。到了 Terminal-Bench 2.1，DeepSeek Harness Minimal 又跑到最前面。

模型能力之外，工具怎么组织，同样是变量。

准备这样的训练，比准备一道有标准答案的题费劲得多。

一道 GPQA 题做错了就是做错了，标准答案在那儿。

项目不一样。它得先能跑起来，跑起来之后还得有一件明确的活要干，干完了还得有人能判断这活干得对不对。

而这三件事，每一件都可能出岔子。

项目里少装了一个依赖，模型就可能以为是自己改错了。修改要求写得含糊，它就朝另一个方向努力。验证程序本身有 bug，那它做得再对也可能算错。这种题放进训练里，可能给模型错误的反馈。

出一道「项目修好了没」的题，首先得有个能跑起来的项目。修改要求得写明白。还得有验证程序，检查它交出来的东西到底对不对。

DeepSeek 让好几个 Agent 一起干这活。有的判断项目适不适合出题，有的设计任务，有的搭环境，有的先去试着做一遍。

做完了，再由独立的检查 Agent 挑毛病，看环境有没有错，验证条件和题意对不对得上，答案有没有泄露。不合格的题修一修，再检查一遍。

任务的另一个来源，是真实使用中的失败。报告里提到，内部员工和外部合作伙伴自愿提供的交互与反馈，会被用来重建工具接口和工作流程。模型以前在哪儿做错了，就把那个现场还原成一个训练环境，让它反复练。

这活儿要跑大量软件和依赖。DeepSeek 说 V4.1 训练带来了百万级并发沙箱需求，靠自建的 DSec 平台扛。平台要做两件事，让模型真的把程序跑起来，同时把不同任务隔离开，限制资源争抢和故障波及。

百万级沙箱同时运行，本身就是一个不小的工程问题。

工作越久，输入越贵

一个 Agent 连续工作，输入里通常会不断增加文件内容、测试结果和修改记录。

假设一项任务已经攒了 10 万 token 的材料。后面 100 次调用都保留并复用这段输入，只这一部分，就累计对应约 1000 万个输入 token。新增的内容还没算进来。

可以把它想成，同一份长报告被重复送进模型一百次。这里算的是 token，不是字数；两者没有固定的换算比例。

这 100 次输入里，这段材料的内容是一模一样的。

为了减少重复计算，系统可以存下此前算过的注意力键值状态，也就是 KV cache。后面来的请求如果前缀一样，这些状态就能直接复用。

模型生成新 token 时，会使用此前保存的注意力状态，但不一定逐一读取所有历史 token。V4.1 Flash 使用稀疏注意力和滑动窗口注意力；它的全局 KV 缓存占用仍随上下文长度大致线性增长。

所以在其他条件相同时，缓存越省，同样的设备就有机会容纳更多长任务。

但缓存也要地方放，要读取，还得传输。

V4.1 Flash 把每 token 的全局 KV cache 占用压到 890 字节，大约是老 Flash 的四分之一。同样的工作量下，持久化 KV cache 的占用大约降到八分之一。

前一项压缩，靠的是跨层共享和更紧凑的存储格式。

后一项还牵扯缓存管理。滑动窗口注意力需要的局部状态，不再长期写进 SSD，而是短暂放在内存池里。

状态缺了，系统只重算最近一个窗口的内容，近似把它恢复出来。

这里有个取舍。重算要花算力，省下来的是存储和传输。报告将这些开销都列为长上下文部署的重要瓶颈。

DeepSeek 在后训练里模拟了这套恢复过程。报告说，在已经测过的设置里，这种近似恢复对回答质量的影响很小。没覆盖到的极端输入和恢复边界，还得接着验。

价格表是这样的。截至发布日，高峰时段每百万输入 token，没命中缓存是 0.30 美元，命中缓存是 0.006 美元。每百万输出 token，1.20 美元。非高峰时段一律减半。

命中缓存的价格是没命中的五十分之一。

按前面那个例子算：如果只比较这累计 1000 万个输入 token，全按缓存命中价计算是 0.06 美元，全按未命中价计算是 3 美元。两者差五十倍。这是两种计价的对比，实际请求还可能包含首次未命中的输入和新增内容。

多轮任务烧掉的钱，很大一部分可能就烧在反复送进去的那段上下文上。把它压下去，长任务的账单才会变得好看。缓存价格只是账单的一部分。实际花多少，还看新增输入有多少、输出多长、调用多少次，以及跑工具本身的成本。

读和写分开算

V4.1 Flash 的主干参数从旧 Flash 的 284B 涨到 552B，但每一步只动用其中一部分。旧 Flash 每 token 激活约 13B 参数。

V4.1 Flash 把输入预处理和答案生成拆开算，前者每 token 激活约 8B，后者约 16B。这是两个阶段各自的激活参数量，不能相加成 24B。

新的 CED 架构把主干分成因果编码器和解码器两块。

解码器的全局 KV 可以直接从编码器的输出搭起来，大部分输入 token 因此绕开了完整的解码器计算。

这件事为什么重要，得看 Agent 平时怎么干活。

读入长、写出短，是 Agent 常见的工作方式。它读进去一大片代码和运行结果，吐出一小段操作指令。给读得多、写得少的工作方式做优化，收益会落在输入处理成本上。这项改进主要降低新增输入和未命中缓存的输入处理开销，跟前一节说的缓存复用配着用。

552B 主干之外，V4.1 Flash 还有 196B 的 Engram 条件记忆参数。

它通过查表读取跟局部 token 组合相关的表示，再和主干计算结合。读取的位置可以根据输入提前定下来，所以系统能预先把要用的东西取回来。

这 196B 是训练里学出来的表示，跟用户会话里不断写进去的个人记忆不是一回事。

生成阶段用的是 DSpark。较轻的模块先打草稿，主模型负责验证。系统根据草稿被接受的概率和当前负载，调整每次验证多长，把生成吞吐量提上去。

参数变多了，不等于每个环节都更贵。V4.1 Flash 把读入、取记忆、写答案分开安排，让不同阶段各干各的活。

多想多久，也要学

给模型更多推理预算，可能提高完成质量，也会增加输出和等待时间。

V4.1 Flash 在强化学习里加了一个努力程度信号，让同一个模型学会在不同预算下干活。发布时的 API 提供 low、high、max 三档。

官方实验里，努力程度从 25 提到 100，DeepSWE v1.1 的成绩从 66.0 涨到 74.2。这个 25 是实验设置，不对应 API 的 low 档。报告给出的三档映射分别是 50、75 和 100。

报告还观察到一件事，努力程度到 60 到 80 之间，已经拿到最高档的大部分成绩，花的输出 token 不到最高档的一半。

最后那一截提升，贵得很。

另一种增加投入的办法，是让多个 Agent 一起来。

V4.1 Flash 训练了这样一种干活方式，主 Agent 分派任务，队友执行，主 Agent 回来检查结果。奖励里不只看任务做得怎么样，还鼓励它把活派出去、把话说清楚。同时用延迟惩罚压掉低效的等待和不必要的串行。

官方筛出的 172 道 ProgramBench 任务上，给 8 小时时限，多 Agent 的 Almost@1 是 30.04%，单 Agent 是 20.39%。这里的 Almost@1，指的是单次运行里达到至少 0.95 任务评分的比例。

这是初步实验。比的是一套观察到的较强多 Agent 配置，和一条较强的单 Agent 基线。

它说明在同一个时限里，协作能把成绩往上抬。它没有证明在同样的总花费下，多 Agent 更划算。

这两句话之间的距离，就是接下来要填的。

剩下的问题

V4.1 Flash 的技术报告里说，这次后训练用的还是那套成熟的流程，SFT、强化学习、在线策略蒸馏。主要投入放在数据和环境建设上。团队认为，在他们的实验里，把任务规模做大、种类做多、可验证性做高，带来了主要收益。

这个判断针对的是后训练，不能反过来理解成架构改进已经接近极限。V4.1 Flash 本身就做了多项架构调整。

想接着往上走，得把工作里更多的失败，变成能复现、能检查的训练任务。还得判断一件事，这次失败到底是模型判断错了，还是工具接口和交互流程设计得不行。报告已经把模型与 Harness 的共同设计，列为后续方向。

这也就解释了 Flash 为什么敢接旧旗舰的 API。官方评测显示，它在多项 Agent 任务上成绩比旧旗舰更好，同时把输入和缓存的成本压下来了。

至于它能接替多少实际工作，还得一个任务一个任务地看。

一次修改能不能顺手把检查也做完，昨天没干完的活今天能不能接着干，出错了能不能自己缓过来，这些事都能处理好了，人才敢把手里的事交给它。