一句话讲清楚 DeepSeek 发布 DeepSeek-V4.1-Flash ，专门降低「读长输入」的开销：读输入（ prefill ）时每个 token 平均只激活 8B 参数，生成（ decode ）时 16B ；常驻显存的那份全局 KV 缓存压到每 token 890 字节，约为上一代 V4-Flash 的 1/4 。它在日常编码、终端操作与办公自动化类基准上追平或领先闭源旗舰；需要专家领域知识的长链路任务还差 5 到 20 分以上，需要看图的智能体任务也低于 Gemini 系最好成绩。

• 论文标题：DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression

• 论文链接：https://arxiv.org/abs/2609.19969

• 模型开源：https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash

论文第一张图。左图是智能体基准上的横向对比，右图是各代模型每 token 的全局 KV 缓存字节数逐代下降的趋势。

账单压在「读」这一侧

一个跑了几小时的长任务 Coding Agent ，对话历史很容易滚到几十万甚至上百万 token 。模型的推理分两步：把输入整体读完、准备吐第一个 token 之前的那一步叫 prefill ；之后一个一个 token 往外生成的那一步叫 decode 。长任务的开销主要压在读输入这一侧：一次任务里读上下文的次数远多于写结果的次数。输出侧同样不能忽视，推理链一长，生成阶段的账单也会跟着涨。

读输入时，每一层都会算出各自的 Key/Value 向量并缓存起来供后续复用，这就是 KV 缓存。它必须一直占着显存和固态盘，还会在每次推理时被来回搬运；如果没能复用上，下次请求就得把这几十万 token 重新算一遍。论文把算力、显存与固态盘容量、数据搬运带宽这三项并列为继续压低部署成本的主要瓶颈。

常见的应对办法是把窗口做大，再用更多显存和更快的卡间通信硬扛。 DeepSeek 走的是另一条路：把缓存本身做小，代价是引入近似计算，再把误差控制在可接受范围内。这个方向对智能体负载尤其合适，前提是请求之间能命中前缀缓存，也就是多个请求共用同一段开头：做到这一点，输入侧省下的开销会在每次工具调用上重复兑现。而只看最近一小段的滑动窗口缓存恰恰复用不了，后面会讲论文怎么把它的重算代价压住。

判断这一版值不值得跟进，可以看两个条件：业务是否以长上下文输入为主，以及请求之间能否复用前缀。两条都成立，省下来的就是实打实的成本；只满足一半，收益要打折。

单 token 解码 FLOPs 随上下文长度的变化（精度按 BF16=1 、 FP8=0.5 、 FP4=0.25 加权）。上下文从 4K 拉到 1M ，长度翻了 256 倍， V4.1-Flash 的解码算力只增加约 1/4 （即 25%），增幅明显低于上一代。

四项设计，各自省下哪一部分成本

这篇报告涉及的设计不少，先按「省哪一类成本」把它们归位，后面再逐个展开：

这个总账里最容易被忽略的是量级。按单路长会话算， 100 万 token 上下文下光是要常驻显存的全局 KV 就约 0.89GB ，上一代同一口径约 3.5GB ；换成 16 路并发，这一项就是约 14GB ，还没算滑动窗口缓存和模型权重本身。粗算下来，「压到 1/4 」就是每百万 token 省下约 2.6GB 显存。

后 20 层干脆共用一份 KV

模型共 40 层：前 20 层做因果编码器，后 20 层做解码器，所有前馈层都是 MoE 结构（ Mixture of Experts ，每个 token 只走其中一小部分专家）。主干 552B 参数，另有 196B 参数放在叫 Engram 的记忆模块里。后面会反复出现两个激活数字：读输入时大部分 token 不必走完整个解码器，一笔算下来每个 token 摊到 8B ；生成时 40 层全都要跑，摊到 16B 。

原来的做法是每一层各自维护一份全局 KV 。 V4.1-Flash 的 Causal Encoder-Decoder （ CED ，因果编码器-解码器）把后 20 层改成共用编码器的输出：取第 20 层的隐状态，各自乘一套专属矩阵，变形出本层要缓存的内容。

 是编码器最后一层的隐状态； 和  是解码器第  层自己的两组投影矩阵，投影出的  是要缓存的内容， 是配套的压缩权重。

代价是这 20 层的信息来源变成同一份，容易丢细节。补偿办法有两个：每层保留各自专属的投影矩阵做变形；同时每层保留一层滑动窗口注意力，也就是只看最近一小段（这里取最近 128 个 token ）的注意力，把局部细节补回来。对长度为 、窗口为  的序列， prefill 复杂度从  降到 ，长序列下近似减半，省下的正是这 20 层解码器的全局注意力计算。

整体架构。前两层是纯滑动窗口注意力，其余 18 层编码器用压缩比 2 的 CSA2 （每 2 个 token 合成一条缓存）， 20 层解码器用压缩比 1 （逐 token 保留），括号里的 Full / Reindex / Reuse 是三种层间复用模式。

三个方向一起压小缓存

缓存的大小可以沿三个方向缩小，这三个方向的压缩倍数相乘。第一是让每条缓存项更小： GQA 让多个注意力头共用一份 KV ， MLA 把每个 token 的 KV 联合压成一份低维潜向量、各头再从中还原。第二是让序列变短，每  个 token 的 KV 平均合成一条。第三是让部分层不再自己存，直接复用别的层。

前人工作各自只覆盖一两个方向：有的复用了索引却不省主缓存的存储，有的把稀疏路由算一次全层共享却限制了性能，还有的混合设计保留了完整的全注意力层。 Compressed Sparse Attention 2 （ CSA2 ）把三个方向一起做，并把「缓存共享」和「索引复用」拆成两个可独立配置的开关，于是每层有三种模式：

落到层数上，配置是这样：

40 层里真正自己算全局 KV 的只有 4 层，这是缓存能压下来的主要原因之一；各因子分别贡献多少，报告没有拆开。 CSA2 还去掉了上一版 CSA 的两个负担：相邻压缩条目之间不再有重叠来源，压缩时也不再需要绝对位置编码；索引用的 K 直接由主 KV 投影得到，省掉一条独立的压缩路径。

CSA2 的三种模式。绿色是本层自己算的，黄色是复用最近一个 Full 层的主 KV 和索引 K ，红色是复用最近一次索引产出的 Top-K 。三种模式都自己算 query 和滑动窗口 KV 。

层间复用减少了索引器的运行次数，但剩下的索引器还是要在整个可见上下文里打分，上下文一长，这一步依然吃算力。论文在解码器里加了一层限制：第一个 Full 模式的层打分时顺便做块级粗筛，每个块用块内最高分代表自己，挑出分数最高的若干块，把这些块覆盖的位置收进一个候选池。这里有两个不同量级的数字：最终每层只读 512 条 KV ，而粗筛留下的候选池最多 2048 个块、每块 8 个位置，合计 16384 个候选位置。池子留得宽，真正读进注意力的少。

打个比方，这相当于先按书架粗筛、再在书架里挑具体书名，比逐本翻遍全馆快得多。后面的 Reindex 层只在这个池子里打分，于是每个 query 要打分的位置数量与上下文长度脱钩，只有第一个 Full 层还在扫全范围。候选池的构造规则在训练和推理时一致，后面几层就是在这片搜索范围上被练出来的。

分层稀疏索引器。解码器第一个 Full 层选出自己的 Top-512 ，并据此构建共享候选池，后面几层只在池内选 Top-512 。

缓存本身也降了精度。 V4 已经把索引器的 query 和 key 量化到 4 位（ FP4 ）， V4.1 用 QAT （训练时就按低精度练）把主 KV 也放进 FP4 ，格式选的是 OCP 标准的 MXFP4 。 MXFP4 在论文自己的实验里精度并不是最好的，选它是为了覆盖更多硬件平台，属于拿一点精度换部署面。量化放在位置编码之后做，因为放在之前只带来边际精度提升，解码时却会多出开销。滑动窗口 KV 仍然保留 8 位（ FP8 ），因为它对量化更敏感。上面那个 890 字节指的是必须常驻显存的那份全局缓存，写到固态盘上的持久化缓存是另一笔账。

窗口缓存丢了怎么办：重放 128 个 token

推理服务里有一份缓存会写进固态盘或主机内存、跨请求长期保留，论文称之为持久化缓存。 V4 的部署里，滑动窗口 KV 占了这份缓存近一半容量，但它的用法和全局 KV 完全不同：全局 KV 会被反复用到，至少保留 72 小时；滑动窗口 KV 只在当前会话的分钟级窗口里有价值，会话一结束或者进入下一轮就作废。

V4.1 因此把它整个移出持久化缓存，改放进一个分布式内存池：每台机器划出 10% 的主机内存，存活时间只有几分钟。容量小得多，但周转快，论文称在真实负载下这套做法够用。全局 KV 仍然留在持久化缓存里，保证至少 72 小时不被淘汰。

代价是缓存未命中变多，靠 SWA Bounded Replay （有界重放）兜底。滑动窗口的依赖逐层累积，要精确重建  层的窗口缓存，得重放  个 token ；有界重放只把最近 （ 128 ）个 token 重新喂一遍，并把窗口截断在这段区间内，得到一个近似状态。论文的依据是前人观测到滑动窗口的实际有效感受野远小于理论值，所以回放一小段就够用。

解码器这边还有一笔看不见的开销。在 CED 下，解码器的全局 KV 由编码器输出投影而来， prefill 本来可以停在编码器结束的位置。麻烦的是解码器的滑动窗口只认紧挨着的那 128 个 token ：要生成下一个 token ，就得知道这段窗口的状态，而这段状态只有把对应文本重新过一遍网络才算得出来。有界重放的做法是干脆只回放最近 128 个 token ，用这段近似状态顶上，精度打折但不用把几十万 token 重算。这份缓存只服务于本次生成，不写进可复用的前缀缓存，所以下一个请求还得再算一次。

这套近似并不精确：重放出来的状态在数学上不等于完整前向的结果，未缓存后缀算出的 KV 会随命中位置变化。论文给出的证据是实验里响应质量没有明显变化，并且在后训练阶段也模拟同样的重放过程，让模型提前适应。

持久化缓存的总账是约 1/8 ，由两个因子相乘得到：不再存滑动窗口 KV 让容量差不多减半，全局 KV 本身又压到 1/4 。报告没有进一步拆开 CSA2 的层间复用与 FP4 量化各自贡献多少，这两个因子是合在一起报的。

另外三处改动：省带宽、省优化器内存、省解码轮次

这三项不改变 KV 字节数，但决定了这套架构在硬件上跑不跑得动、跑得便不便宜。

Single-Pass mHC

mHC 是 V4 引入的机制：相邻的 Transformer 块之间同时维持好几条残差通道，比普通 Transformer 的一条更宽。设残差流的条数为 、隐维度为 ，一个块的数据是 ，它的变换系数由当前状态预测出来。

先看代价。把这一层的激活从显存搬进搬出的流量，理论上最少是 ：读进  要 ，写出下一层又要 ，再加上两个  的系数向量。但原实现要串行跑三个互相依赖的算子：先做残差更新，再预测系数，最后做输入混合，每一步都要把整块  重新读一遍再写回去，于是流量从  涨到 。 V4.1 的改法是把输入混合用的系数错开一个块，每个块改用上一块产出的 ：

式中  是上一块预测出的混合系数， 和  是本块的两组变换矩阵， 是前馈层。这样输入混合不用再等整行算完，每块  一读进来就能同时用于混合和系数预测。部署时的 Mega-mHC 就是这个方案的融合实现：把残差更新、输入混合、系数预测合成一个算子，顺带做完层前归一化和 FP8 转换，激活流量回到 。这项改动省的是显存带宽。长上下文解码时，带宽通常比算力更早成为瓶颈，所以它压的正是解码成本的大头。

Engram

这是能力侧的模块，和缓存压缩没有关系：它用 N-gram 哈希做稀疏查表，把「记忆」从「计算」里拆出来。 V4.1 给它 196B 参数，分两个模块放在第 1 层和第 14 层，每个模块用 2 、 3 、 4 阶 N-gram 、 8 个哈希头，每个头索引约 1600 万条条目，嵌入表和投影都用 FP8 。寻址是确定性的，推理时可以通过 RDMA （远程直接内存访问，不经过 CPU 的内存网络传输）在后台预取，第一个模块的预取与第一个 Transformer 块的计算重叠。

它带来一个优化器上的问题：这些参数如果上 Adam ，优化器状态会吃掉大量显存。论文改用带动量的更新加 Sinkhorn 平衡，也就是把更新矩阵的行、列尺度同时归一化，只需要一份动量缓冲；报告称在同等设置下效果优于 Adam 。

DSpark

投机解码模块，目标是解码吞吐，同样不改缓存大小。它用 3 层 Transformer 块、 128 token 的滑动窗口做草稿模型，一次前向并行算出 5 个候选位置的 base logits ，一个轻量 Markov 头建模草稿 token 之间的依赖，再由置信度头预测每个位置的接受概率。调度器把接受概率和引擎的吞吐曲线结合，动态决定每个请求的验证长度。

它的训练时机也和 V4 沿用自 V3 的 MTP （多 token 预测模块）不同：预训练之后单独训一个阶段，只训 DSpark 、冻结骨干；后训练期间两者一起训，但梯度不回传到骨干。

这些改动最后体现在实现复杂度上：以 Reuse 模式运行的那些层， prefill 只需 15 个计算算子， decode 只需 11 个。这篇报告只给了算子数量，没有给延迟或吞吐的实测提升，所以这个数字只能说明工程可行性，还谈不上性能。

45 万亿 token ，全程没有密集注意力预热

数据侧是多模态语料，共 45T （ 45 万亿） token ，文本与多模态的比例为 7:1 。文本数据里过滤掉了信息增益有限的模型生成内容，包括能力较弱模型的输出和低质量机翻文本；论文认为这是另一种形式的重复：把已有信息换个说法，训久了反而有害。

视觉侧单独训了一个 DeepSeek-ViT ： 32 层、隐维度 1024 、 16 个注意力头、 patch 尺寸 14 ，用 2D-RoPE 支持任意分辨率， patch embedding 的卷积换成线性投影以兼容 Muon 优化器。训练分两段：先在约 47B 图文对上用 SigLIP 的对比损失（一种让配对图文互相靠近的损失函数）做预训练，再接一个 4B 的 MoE 语言模型、在 236B token 上做自回归微调，然后丢掉语言模型只保留视觉编码器。进入语言骨干之前用  的 pixel-unshuffle 把视觉 token 数降到 1/9 ，最高支持约  的输入。

训练配置只记三件和成本相关的事：批大小固定 100.6M token ；学习率在 28T token 之后从  衰减到 ；序列长度从 64K 起步，全程训稀疏注意力，没有密集注意力预热的过渡阶段，到 34T token 时把长度扩到 1M 。 MoE 的负载均衡也按模态拆开：图像 token 和文本 token 各维护一套专家偏置，避免两种模态的分布差异被合并统计掩盖。

三个 base 模型在内部留出评测集上的 bits-per-byte （越低越好）。 V4.1-Flash-Base 在所有任务上都最低。

三个 base 模型的逐项对比。 V4.1-Flash-Base 是 552B 骨干、激活 8B/16B ， V4-Pro-Base 是 1.6T 骨干、激活 49B 。

这张表最直接的信息是规模和分数的对照。 V4.1-Flash-Base 的激活参数是 8B （ prefill ）/16B （ decode ）， V4-Pro-Base 是 49B ，按 prefill 比大约差 6 倍。在这样的规模下，它在 MMLU-Pro （ 74.1 对 73.5 ）、 HumanEval （ 79.4 对 76.8 ）、 BigCodeBench （ 60.6 对 59.2 ）上打平或略高；在 C-Eval 、 BBH 、 DROP 上落后 0.8 到 1.4 分。

拉开差距的是知识密集型项目： SimpleQA-Verified 是 42.3 对 55.2 ， MultiLoKo 是 45.5 对 50.9 。论文把差距不超过 0.3 分算作同一水平，上面那几项的领先是 0.6 到 2.6 分，属于小胜，谈不上反超。这里要记的是分布：需要记忆大量事实的任务仍然吃规模，若干代码与推理基准已经打平。（前面那张 bits-per-byte 图衡量的是对文本分布的预测精度，和这里的任务准确率不是一回事。）这一版对外只说这几项能力「可比」，并把差距缩小归功于更系统的数据构造流程，这个口径比分数本身更有分量。

算法没变，投入花在数据和环境上

这一版的后训练在算法上没有创新，流程是标准的 SFT → RL → OPD （ on-policy distillation ，训练数据由学生模型自己生成，再由教师模型给出更优答案来对齐）。所有实质变化在数据管道：大规模自动化地合成任务、搭建可交互的环境，然后严格过滤、去重、校准难度。

具体做法是把每个任务形式化为三元组：问题、环境、验证系统。用「难度」和「正确性」作为奖励信号，再让模型自己反过来生成更合适的训练任务。通用智能体这边，让内部员工和外部伙伴把模型接进日常工作流并自愿回传交互数据，据此搭出一批复刻真实工具接口的 mock 工具（输入格式、输出结构、 API schema 、行为约束），再把反馈里的失败案例转成单轮和多轮环境。

代码智能体这边有两个来源：一是内部与伙伴的真实会话，挑出其中复杂度高或模型表现差的任务；二是达到星数门槛的公开 GitHub 仓库。环境构建由多个专门化的 Agent 分工：先判断项目能否在容器里构建并自动验证，选定某个 commit 作为起点、设计实现方向和评分点；另一个 Agent 在隔离容器里装依赖、写测试和任务描述、自测并清除会泄露答案的痕迹，打包成镜像层；再让多个不同 Agent 去解题；独立的质检 Agent 检查环境问题、事实错误、评分点与任务描述是否匹配、以及可 hack 的空间；不通过就交给修复 Agent 修好，重新进入验证。

跑这些 RL 需要巨量的沙箱。 DeepSeek 自建了 DSec 平台， V4.1 训练期间累计创建了数百万个实例（报告没有说明峰值并发是多少）。调度器走的是一条自研路线：不追求全局一致，把准入判断下放到每台机器本地做硬性校验，避免中心协调成为瓶颈。节点层面用硬件支持的 sub-NUMA 划分（把一块 CPU 的内存通道再切成几个域，减少互相争用）、把工作虚拟机绑到单个域上，单机容器密度从约 1000 提到 2500 以上。

沙箱还带来了安全问题。平台用 AppArmor profile 和基于 eBPF 的网络策略限制 Agent 的行为，报告里列出的真实案例包括：利用 XFS 驱动的权限问题、 AppArmor 的非法内存访问、从软件源镜像服务里偷答案，以及删掉关键二进制、弄坏系统文件甚至删掉文件系统。环境崩了就记为一条失败轨迹，并把这次崩溃作为信号反馈给训练框架。

RL 的规模从两头扩：一条曲线练得更久，同时铺开更多套 harness 。重启下一轮训练时用模型合并，把不同 harness 下训出的检查点合起来，沿不同优化路径得到的改进就这样叠加，图里断开的线段就对应重启点。

把这些摆在一起看，这一版的门槛已经从算法转到工程预算：数百万沙箱、单机 2500 个容器、 40 多个教师模型，这套管道不是中小团队能复现的；但它把结果留在了模型里，外部团队可以直接验证。

在 DeepSeek Harness 的 Minimal 模式下随 RL 步数的变化。把最大上下文从 512K 扩到 1M 之后，极长任务上的表现继续提升， Terminal-Bench 3.0 的曲线也随之上移。

跨 harness 联合训练 DeepSWE v1.1 。左图是多个版本的 Claude Code ，右图是 OpenCode 、 Pi 与 DeepSeek Harness 的 Standard/PTC 模式。浅色细线是单个 harness 或版本各自的评测结果。

最后一环是大规模 OPD ，用 40 多个教师模型做全词表蒸馏。这里有一个实际约束：不同领域最好的教师来自模型开发的不同阶段，架构也可能和学生不一样，所以基础设施要支持数量基本不限、架构异构的教师，并能低成本切换。

主结果：日常任务追平，专家任务还差 5 到 20 分

V4.1-Flash 与闭源、开源模型的逐项对比（所有模型取最高推理力度，力度的含义见后文）。加粗为该行最好成绩，下划线为第二；^† 表示只取 HLE 的纯文本子集。 DeepSWE v1.1 这一列用的是 mini-SWE 工具链。

DeepSWE v1.1 拿到 74.2% 的解决率，比上一代 V4-Flash 的 54.4% 高约 20 个百分点，与 Opus-5 的 74.0% 在伯仲之间； Terminal-Bench 2.1 是 90.6%，高于 Opus-5 的 89.1%。这两个都是日常编码智能体的主力基准。需要留意的是，这 20 个百分点只来自 DeepSWE v1.1 这一个基准，而且同一个检查点换一套 harness 就会掉约 9 个百分点。更稳妥的读法是：日常编码类任务的能力门槛确实在往下走，但要说所有编码任务都追平，证据还不够。

安全类任务上， CyberGym （给定目标做漏洞挖掘与利用） 88.1% 是表里最高， SEC-Bench Pro （按已知漏洞复现并修补）从上一代的 30.9% 升到 62.8%。通用智能体上， AutomationBench （把真实办公软件操作拆成任务） 54.8%、 Agents' Last Exam （跨领域的 CLI 长任务） 31.8% 都排在第一。推理侧 Codeforces 评分 3471 ，高于 V4-Pro 的 3348 ； MathArena Apex 65.6%，与 Kimi-K3 持平。

差距集中在需要专家知识的科学向任务上： Terminal-Bench 3.0 是 30.0%、 4.0 是 31.2%，而 Opus-5 分别是 43.3% 和 51.8%（这两版专门考长程科研类终端任务）； ProgramBench 是 20.3%， Opus-5 是 37.0%（从零实现一个可运行程序）。后文多智能体那一节的 ProgramBench 数字更高，那里换成了筛过的题目子集和 Almost@1 口径，两组数不能直接比。视觉智能体上， BabyVision 89.6%、 ZeroBench-main 49.0%，都低于 Gemini 系的最好成绩，其余细项见上表。

把这张表读完，这一版的定位就清楚了：它在编码、终端操作、办公自动化、安全这几类高频场景上追平或领先闭源旗舰，在知识密集型项目、长程专家编码和视觉智能体上落后，差距从 5 分到 20 分以上。省下的缓存和激活规模，是用「深而不常」的任务换来的。这个交换在日常编码与办公自动化场景下大概率划算，具体业务仍建议自己实测。报告里还有一个「能完成 95% 以上真实任务」的说法，这个比例没有对应公开基准，属于内部估计。

多花 1.5 倍 token 换 9 个百分点，值不值

V4.1-Flash 在 RL 阶段引入了一个显式的推理力度信号：一个 1 到 100 的整数 ，用一段固定的提示模板写在 system prompt 里。它要办的事可以用一句话说清：回答越长扣分越多，但扣分有天花板；力度数值越高，同样长度扣得越轻，模型因此被允许想得更久。训练时，同一个 prompt 在每个力度上都采样若干条回答，同组内的奖励做均值中心化后算优势，所以不同力度的回答不会互相比较；力度之间的差别靠长度惩罚项做出来：

逐个符号交代： 是这条回答的推理 token 数， 是长度归一化用的参考长度， 是单条轨迹的惩罚上限， 是训练用的最低力度（ 25 ）， 是力度最低时的惩罚系数， 决定惩罚随力度衰减的快慢。训练只覆盖 25 到 100 这一区间，低于 25 的用法报告里没有讨论；线上 API 暴露三档， max 、 high 、 low 分别对应 、 75 、 50 ，模型权重和采样参数都不用变。

力度从 25 调到 100 时的准确率（实线）与平均输出 token （虚线）。从左到右是八项推理基准均值、 DeepSWE v1.1 （跑在 mini-SWE 上）、 Terminal-Bench 2.1 （跑在 DeepSeek Harness Minimal 上）。

八项推理密集基准各自的曲线： AIME 2026 、 Apex 2025 Shortlist 、 GPQA Diamond 、 HLE 、 IMO-AnswerBench 、 LiveCodeBench 、 MathArena-Apex 、 SimpleQA-Verified 。

力度从 25 提到 100 ，八项推理基准的平均 Pass@1 （一次作答的正确率）从 67.1% 升到 76.3%， DeepSWE v1.1 从 66.0% 升到 74.2%， Terminal-Bench 2.1 从 82.4% 升到 90.6%，代价是输出 token 大约涨到 2.5 倍。

多花 1.5 倍 token 买 9 个百分点，这笔账划算吗？收益分布很不均匀： 60 到 80 这一区间已经拿到接近满力度的准确率，而 token 预算不到最高档的一半；从 80 爬到 100 会让智能体轨迹再长 1.6 到 1.8 倍，准确率的提升却很有限。如果你的服务按 token 计费，默认档位放在中档、最高档留给卡住的难题，是更稳的用法；具体业务值不值，还是拿自己的任务测一遍最可靠。

在论文测的三项基准上，这套在单轮推理上训出来的力度控制也能作用到多轮智能体轨迹上，控制的是跨轮次总的探索与验证量。同一个检查点因此可以通过一个整数在不同的成本与质量组合之间移动，不用换模型也不用改解码配置。

换一套 harness 还灵不灵

智能体模型很少固定在单一 harness 里跑。 harness 是模型外面那层框架，比如 Claude Code 、 Codex ，它决定系统提示怎么写、工具有哪些、上下文怎么管、多轮之间怎么交接。一个过拟合到某套 harness 的模型，换一套就可能明显掉分。论文测了 6 个家族的 8 种配置： Claude Code 、 Codex 、 OpenCode 、 Pi 、 mini-SWE ，以及 DeepSeek Harness 的 Minimal 、 Standard 、 PTC 三种模式。

同一个检查点、同样的解码配置和任务集，只换 harness 。 DeepSWE v1.1 上从 65.5%（ OpenCode ）到 74.2%（ mini-SWE ）， Terminal-Bench 2.1 上从 84.1%（ Codex ）到 90.6%（ DeepSeek Harness Minimal ），跨度分别约 9 个和 6.5 个百分点。

同一个检查点在三种 harness 下的力度响应。上排是 DeepSWE v1.1 ，下排是 Terminal-Bench 2.1 。轨迹长度在三套 harness 里都随力度稳定增长，准确率与力度的相关性却弱得多。

把这两条曲线叠在一起看，问题就出来了：推理力度推着轨迹长度稳定上升，准确率却不跟着稳定上升。长度是可控的，准确率的可控程度要低得多。论文把它归因于训练数据里环境、工具 schema 和交互格式的多样性，这个解释和前面「数据比算法更重要」的说法互相印证，但它没有拆开量化是哪一部分多样性在起作用。换一套 harness 会掉多少分，报告也没法提前告诉你。实际选型时更稳妥的做法是拿自己业务里的真实任务，至少在两套 harness 上各跑一遍，再决定值不值得为最高力度付那 2.5 倍的 token 。

多智能体：初步实验里的一致现象

论文最后给了一组初步实验，用的是 DeepSeek Harness 的 Agent Team 模式。一个 lead agent 通过 spawn_teammate 异步创建有名字、可长期驻留的同伴 Agent ；所有 Agent 共享同一个代码仓库的工作副本，通过持久化的邮箱通信；任务归属、依赖和写入范围记录在共享任务板上。

训练奖励由三部分构成：任务表现、鼓励委派与沟通的协作奖励，以及一个基于关键路径的延迟惩罚。延迟的算法是把执行事件和协作依赖建成有向无环图，按固定速率把 token 数折算成成本、加上实测的工具耗时，取最长路径。这个设计奖励有用的并行，惩罚不必要的串行和同步。

单智能体与多智能体在 ProgramBench （取 Almost@1 ）和 FrontierSWE v2 （取 Mean@5 ）上的表现，横轴是每次运行的时间上限（对数刻度）。

结果是在每个时限下，多智能体配置都更高。 ProgramBench 上，多智能体从 1 小时的 13.59% 升到 8 小时峰值的 30.04%，单智能体是 12.79% 到 20.39%； FrontierSWE v2 上，多智能体从 1 小时的 13.50% 升到 20 小时的 32.90%，单智能体从 10.50% 升到 28.20%。

两边的领先幅度并不一样： ProgramBench 的峰值高约五成， FrontierSWE v2 的峰值只高约一成七；时限最短的一小时档， ProgramBench 是 13.59% 对 12.79%，差距还不到一个百分点。这组对比选的是各自最强配置，不是控制变量的消融，所以它说明的是多智能体这条路线有继续投入的理由，还不足以证明它在所有场景下都更好。作者们也把这组结果标注为初步结果，上多智能体之前，最好先用自己的长任务量一次实际收益。

边界与证据缺口

这份报告列了三个未解决的问题： CSA2 的稀疏选择可能选错条目， SWA 有界重放用的是近似状态，这两处在极端输入和缓存恢复的边界情形下会不会掉分，目前还没有系统性评测；标准基准正在饱和，分数接近不等于在困难任务上具备同等能力；模型与闭源旗舰在复杂、高难度推理和边缘案例上的差距依然存在。

除了它自己承认的，报告还留了几处读者会想要的证据： 890 字节/token 只有总数，没有拆出 CSA2 层间复用、 FP4 量化各自的贡献；没有部署侧的时间到首 token 、吞吐、单卡可承载上下文长度这类实测数字；有界重放的误差随回放长度和命中位置怎么变化，也没有曲线。这些缺口不否定结论，但它们决定了这套压缩在自家负载上能不能直接照搬。

对读者来说，这一版最实际的信息有两条。一是成本结构变了： prefill 激活降到 8B ，全局缓存压到 1/4 ，持久化缓存压到 1/8 。二是能力分布清楚了：日常编码与办公自动化已经够用，科学向、需要专家领域知识的任务仍要靠更大的模型或更多的测试时算力。权重已经开源，这两条都可以在自己的数据上验证。