02 · DeepSeek-V3.1: 一个检查点如何承载两种推理模式

DeepSeek 于 2025 年 8 月 21 日发布 V3.1. 公开材料是一份七页发布说明, 配套来源包括官方发布页与 Hugging Face 模型卡, 没有单独的 arXiv 技术报告. 因而能够确认的是产品接口, 模板行为, 840B token 的继续训练, CoT 长度变化, Agent 评测和 UE8M0 FP8 Scale; 网络层数, 专家配置, 后训练算法与数据配比没有披露.

V3.1 的主线是把此前分开的 V3 对话模型与 R1 推理模型收进同一个检查点. deepseek-chat 和 deepseek-reasoner 两个 API 名仍然保留, 但不再对应两份独立权重. 这种合并改变了训练约束和部署边界: 同一套参数既要直接回答, 也要生成较长的推理过程; 同一套 tokenizer 与 chat template 还要稳定表达模式选择, 工具调用和多轮历史.

1. 模式切换发生在生成协议

公开材料能确认的是模式切换协议, 不能确认新增了某种网络结构.

1.1. 同一权重如何区分两种行为

发布说明把 V3.1 称为「混合推理架构」, 但没有报告任何新增网络模块. App 和网页端通过「深度思考」按钮切换, API 端则由 deepseek-chat 与 deepseek-reasoner 分别进入非思考和思考模式. 两个入口都使用 128K 上下文. 从公开接口能够确定的是模式路由, 不能据此推导注意力层或 MoE 层发生了结构变化.

模型卡进一步给出生成前缀: 思考模式以 <think> 结束输入前缀, 模型随后生成推理内容; 非思考模式直接给出 </think>, 等于在生成开始前关闭推理区段. decoder-only 网络仍执行同一种 next-token prediction, 区别来自特殊 token 所设定的条件. 训练数据必须同时覆盖两种前缀及相应输出形态, 否则模型容易在非思考模式泄漏推理段, 或在思考模式过早闭合标签. 两类样本比例和联合训练日程没有公开.

多轮对话还要处理历史推理内容. 模型卡要求丢弃先前轮次的思考文本, 仅保留闭合标记与可见回答. 这样做控制上下文占用, 也避免模型把旧轮的中间推理当作新问题的事实前提. 代价是服务端必须理解模板协议, 不能把完整原始输出逐字拼回下一轮. V3 的旧模板若直接套用到 V3.1, 模式标记, 工具调用边界与历史裁剪都可能错位.

历史裁剪还改变了可恢复状态. 用户能看到上一轮最终答案, 模型却不再接收产生该答案的完整推理段. 如果后续问题引用中间步骤, 服务端无法从已裁剪上下文中恢复. 这种设计以较低上下文占用换取了推理过程的不持久化, 也要求最终答案保留后续对话真正需要的条件与结论. 发布说明没有给多轮思考一致性的专项评测.

1.2. 合并检查点带来的参数竞争

两种模式共享参数, 意味着后训练同时优化不同长度和不同节奏的输出. 非思考样本偏向短回答与快速执行, 思考样本允许在最终答案前展开推理. 如果某一类数据占比过高, 同一输入下的 token 分布会偏向该类行为. 特殊 token 提供了条件信号, 但条件信号只能让模型区分任务, 不能自动消除共享参数的梯度干扰.

V3.1 的价值因此不只是省掉一份部署权重. 同一检查点让系统能够按请求切换延迟和推理深度, 缓存管理, 权重驻留与版本治理也只维护一条线. 相应代价是回归测试必须成对进行: 思考模式的数学和代码能力提高, 不能以非思考模式的输出长度变长为代价; 非思考模式更简洁, 也不能破坏思考模式的搜索空间. 发布说明只给最终评测, 没有双模式互相干扰的消融.

strict Function Calling 与 Anthropic API 格式属于协议层扩展. strict 模式要求函数名和参数满足 schema, 但发布说明没有写服务端采用约束解码还是生成后校验. 两种实现对失败形态不同: 约束解码在生成过程中屏蔽非法 token, 事后校验则可能需要重试. 因而「满足 schema」只能解释接口承诺, 不能反推模型内部使用了哪种解码器.

2. 继续训练与推理长度控制

V3.1 Base 是从 V3 检查点继续训练 840B token, 不是重新预训练一套底座.

2.1. 840B token 用在长上下文外扩

V3.1 Base 从 V3 检查点继续训练 840B token, 不是从随机初始化重新预训练. Hugging Face 模型卡把过程分成 32K 与 128K 两段: 32K 阶段约 630B token, 128K 阶段约 209B token, 合计与发布说明的 840B token 相符. V3 原报告使用 YaRN 完成长上下文扩展, 相关机制可参见长度外推: 从 PI 到 YaRN.

继续训练的目标不是简单宣布 128K 窗口. 模型需要在长序列里学习跨越更远距离的依赖, 并适应长工具轨迹, 仓库上下文和搜索记录. 840B token 约占 V3 预训练 14.8T token 的 5.7%, 规模足以改变底座在长上下文条件下的行为. 公开材料没有给长短样本比例, 数据领域或位置分布, 因而不能把 Agent 提升按比例归因于这一步.

长上下文训练也不等于 128K 中每个位置都具有同等可靠性. 标称窗口说明接口接受的最大长度, 真实能力还取决于训练时的长度分布, 信息位置, 检索干扰和生成长度. 发布说明没有 needle-in-a-haystack, 长文问答或不同位置区间的曲线. 对代码 Agent 而言, 能装入整个仓库只是输入条件; 能否定位相关文件并维持跨文件约束仍由后训练与工具轨迹决定.

从训练计算看, 32K 与 128K 两段承担的作用也不同. 较短阶段可以让模型先适应扩展后的 RoPE 频率与更长序列统计, 较长阶段再把可用窗口推到接口上限. 模型卡给出的 630B 与 209B token 表明训练量并未按上下文长度等比例分配. 由于单个 128K 序列消耗的注意力计算和显存更高, 末尾一段用较少 token 仍可能占据较大计算份额. 官方没有给 batch size, 序列打包率与训练步数, 无法从 token 数复原算力投入.

继续训练还要避免短上下文能力退化. 如果训练批次过度偏向长序列, 常见短对话的分布会被稀释; 如果长序列只是把无关短文拼接在一起, 模型又未必学到远距离依赖. V3.1 发布说明只给后训练模型的任务结果, 没有 V3.1 Base 对 V3 Base 的短任务与长任务并列表. 因而 840B token 能确认训练规模和目标窗口, 不能确认每一种上下文长度都获得同等增益.

2.2. CoT 压缩减少的是生成成本

V3.1-Think 经过 CoT 压缩训练后, 官方称输出 token 减少 20%–50%, 平均任务表现与 R1-0528 持平. 图中的三项数据给出了具体口径: AIME 2025 从 22,615 token 降到 15,889 token, 准确率由 87.5% 变为 88.4%; GPQA Diamond 从 7,678 降到 4,122 token, 分数由 81.0 变为 80.1; LiveCodeBench 从 19,352 降到 13,977 token, 分数由 73.3 变为 74.8. token 分别减少约 29.7%, 46.3% 和 27.8%.

图 1: AIME 2025, GPQA Diamond 与 LiveCodeBench 上的平均输出 token 和任务表现, 出自 V3.1 发布说明第 4 页.

图 1 说明长度下降没有在三项任务上造成一致的分数损失: 一项下降 0.9 分, 两项上升. 它不能说明单个样本的推理过程都更好, 也不能说明所有任务都落在同一压缩比例. 平均 token 数还会受提前答错, 拒答和截断影响. 若模型更早给出错误答案, 长度同样会下降; 因而必须把长度与准确率成对读取.

CoT 压缩改变的是生成阶段的 token 数, 直接影响延迟与输出费用. 公开材料没有说明训练目标. 长度惩罚, 短轨迹蒸馏, 正确样本筛选或强化学习都可能得到相似表象, 但不能据结果替官方指定算法. 非思考模式也宣称相对 V3-0324 在性能相同时明显缩短输出, 却没有给分项数字. 推理训练的通用背景可参见推理与 Agent 能力.

2.3. 长度收益如何落到服务成本

新版 API 输出价格为每百万 token 12 元. 按图 1 的平均值, 一道 AIME 2025 题的输出费用约从 R1-0528 的 0.27 元降至 V3.1-Think 的 0.19 元, 只计算输出而不含输入. GPQA Diamond 的对应输出费用约从 0.092 元降至 0.049 元. 这是固定单价下由输出长度直接得到的差值, 不包含重试, 并发等待和缓存命中.

价格表同时规定输入缓存命中为每百万 token 0.5 元, 未命中为 4 元, 输出为 12 元, 并取消夜间优惠. 长上下文 Agent 的成本不只由 CoT 决定. 仓库文本和搜索页面进入输入侧, 缓存键是否稳定决定输入成本; 工具调用产生的新观察又会使后续请求变化. 因而 CoT 压缩主要降低输出侧开销, 不能替代上下文裁剪与缓存设计.

一次 Agent 请求若包含 100K 输入 token 和 10K 输出 token, 输入未命中时费用约为 0.4 元, 输出约为 0.12 元; 输入命中时输入费约为 0.05 元. 在这个设置中, 缓存命中带来的差额大于再压缩少量输出 token. 如果每轮工具观察都改变前缀, 可复用缓存的区段会缩短. 系统可以把稳定的仓库上下文和工具定义放在可复用前缀, 把变化的观察追加在后部.

CoT 压缩还会影响并发容量. 输出 token 减少后, 单请求占用解码资源的时间下降, 相同硬件可以服务更多并发请求. 这种收益取决于批处理, KV cache 容量和请求长度分布, 发布说明没有给吞吐或首 token 延迟. 因而图 1 能直接支持 token 和费用比较, 不能直接换算成服务器吞吐倍数.

3. Agent 评测呈现了什么能力

3.1. 代码任务的增量集中在多步执行

代码 Agent 表中, SWE-bench Verified 为 66.0, V3-0324 与 R1-0528 分别为 45.4 和 44.6; SWE-bench Multilingual 为 54.5, 两个基线分别是 29.3 和 30.5; Terminal-Bench 为 31.3, 基线为 13.3 和 5.7. 在 SWE-bench Verified 的 500 个问题上, 66.0 与 45.4 相差约 103 个成功修复, 量级远高于一般采样波动.

三个评测都要求模型在外部环境中连续行动. SWE-bench 提供真实仓库与 issue, 最终以测试是否通过计分; Terminal-Bench 更强调命令行中的多步操作. R1-0528 在 Terminal-Bench 只有 5.7, 低于 V3-0324 的 13.3, 说明长推理能力不能直接替代工具协议, 环境反馈处理与动作纠错. V3.1 的优势与发布说明所称 Post-Training 优化方向一致.

SWE-bench 的一次成功至少包含四个相互依赖的环节. 模型先从 issue 提取约束, 再在仓库中定位相关文件, 生成补丁后运行测试, 最终根据失败输出继续修改. 任一环节出错都会得到零分. 因而 66.0 不能解释成单纯的代码补全准确率. 它更接近在固定预算内完成整条修复路径的比例, 其中仓库检索, shell 使用和测试反馈与代码生成同样重要.

SWE-bench Multilingual 的 54.5 低于 Verified 的 66.0, 两者题集不同, 不能把 11.5 分差直接当作语言损失. 多语言 issue 会改变需求理解, 但仓库语言, 测试难度和问题分布也会变化. V3.1 相对两个基线在 Multilingual 上增加约 24–25 分, 增量方向与 Verified 一致, 这比两个绝对分数之间的横向差更有解释力.

这组结果仍缺少关键控制变量. 发布说明没有给 Agent 框架, 最大步数, token 预算, 温度, 补丁重试策略和工具错误处理. SWE-bench 的最终分数会随脚手架变化, 因此 66.0 应作为该次官方运行的系统成绩, 不能视为裸模型在所有框架中的固定能力. 表中也没有标明模式; 模型卡对工具调用的说明更接近非思考模式, 但发布页未明确绑定.

3.2. 搜索成绩要连同工具协议读取

搜索 Agent 表对比 V3.1 与 R1-0528. BrowseComp 为 30.0 对 8.9, BrowseComp-zh 为 49.2 对 35.7, HLE 为 29.8 对 24.8, xbench-DeepSearch 为 71.2 对 55.0, Seal0 为 42.6 对 29.7. Frames 与 SimpleQA 分别是 83.7 对 82.0, 93.4 对 92.3, 增量较小. 大幅变化主要出现在需要多轮浏览和下一步查询决策的任务.

搜索 Agent 的模型输入会反复加入页面内容, 查询结果和工具状态. 模型需要决定何时改写查询, 哪些来源继续展开, 何时停止并组织答案. 长上下文继续训练为容纳轨迹提供基础, Post-Training 则训练动作选择. 两者都可能影响分数, 但发布说明没有消融, 无法把 BrowseComp 的 21.1 分增量拆到具体训练阶段.

HLE 的协议差异尤其明显. V3.1 搜索 Agent 表给出 29.8, Terminus 表中「reasoning mode w/o tool use」的 V3.1 列只有 15.9. 同一检查点相差 13.9 分, 原因是前者允许工具, 后者禁止工具. 引用 HLE 时若省略工具设置, 会把检索系统的贡献混入模型闭卷推理能力. 搜索供应商, 每题调用次数和页面读取范围同样未披露.

3.3. 评测表不能回答训练配方

发布材料把 Agent 提升归为 Post-Training 优化, 但没有说明轨迹来自人工, 模型自生成还是线上反馈; 没有给 SFT, 偏好优化或强化学习的阶段划分; 也没有定义奖励. 评测结果能够证明最终系统在给定协议下更有效, 不能识别是哪一种训练算法带来增量.

Agent 轨迹与普通问答样本的结构不同. 一条轨迹包含用户目标, 模型动作, 工具返回, 新动作和最终答案, 每一步都受环境状态约束. 训练若只保留成功轨迹, 模型会看到正确行动顺序, 却较少学习怎样从错误命令与失败测试中恢复; 若加入失败轨迹, 又需要标明哪一步应被修正. V3.1 在 Terminal-Bench 和 SWE-bench 上的增量说明最终策略更有效, 页面没有披露轨迹是否包含错误恢复.

奖励可能只看最终任务成功, 也可能同时评价工具参数, 步数和输出格式. 最终奖励容易把长轨迹中的信用分配压到一个标量, 过程奖励可以提供更密集信号, 但需要可靠的步骤判定器. 发布说明没有相应细节. 因而 Post-Training 是训练阶段定位, 不是算法名称, 更不能由表格倒推出使用了 GRPO, PPO 或某一种偏好优化方法.

同样的边界适用于 CoT 压缩. AIME, GPQA 与 LiveCodeBench 展示长度和准确率的联合结果, 但没有训练消融. 840B token 的继续训练, 双模式数据与 Agent 轨迹可能共同改变表示和行为. 对版本谱系的可靠说法是 V3.1 同时调整了 Base 继续训练和后训练; 把某个分数单独归给其中一步, 需要官方未提供的对照组.

4. 部署格式与版本边界

4.1. UE8M0 改变比例因子的表示

V3.1 使用 UE8M0 FP8 Scale 参数精度. V3 的 FP8 训练按块保存比例因子, 使低精度值与原始张量动态范围匹配, 机制背景见FP8 混合精度训练详解. UE8M0 用 8 位无符号指数保存 scale, 没有尾数, 可表示的正 scale 是离散的 2 的幂. 相比 FP32 scale, 存储从 4 字节降为 1 字节.

指数格式便于硬件执行乘以 2 的幂, 但 scale 的粒度更粗. 若采用向上取整, 实际 scale 最多可能接近所需 scale 的两倍, 相应地会少利用约一位有效动态范围. 这是格式本身的量化边界, 不等于模型分数必然下降. 最终误差还取决于分块方式, 张量分布和内核实现. 发布说明没有给 block shape, 损失变化或精度消融.

设某一块浮点值的绝对最大值为 $a$, FP8 E4M3 的目标上界为 $m$. 理想比例因子是 $s=a/m$. UE8M0 只能保存 $2^k$ 形式的比例, 若取 $k=\lceil\log_2 s\rceil$, 实际比例 $\hat{s}=2^k$ 满足 $s\leq\hat{s}<2s$. 量化值按 $q=\operatorname{round}(x/\hat{s})$ 得到, 反量化为 $\hat{x}=q\hat{s}$. 当 $\hat{s}$ 接近 $2s$ 时, 相邻可表示值之间的间隔也接近理想情况的两倍. 这就是动态范围利用率下降的来源.

公式只描述单个 block 的刻度选择. 实际权重文件还要规定哪些元素共享一个 scale, scale 与数据块怎样排列, 特殊值如何编码. 分块越细, scale 越贴近局部分布, 元数据和读取开销也越高; 分块越粗, 少量离群值越容易抬高整块 scale. V3.1 页面只给 UE8M0 名称, 没有重新声明分块规格, 部署端应读取随权重发布的配置而不是从格式名猜布局.

部署程序需要正确解释权重文件中的 scale 布局. 旧 V3 内核若假设 FP32 scale, 直接读取 UE8M0 会得到错误反量化结果. 模型卡还要求路由偏置按 FP32 加载, 进一步说明不能只替换权重文件而沿用全部旧配置. 推理框架应以 V3.1 仓库的配置, tokenizer 和模板作为一个版本单元处理.

4.2. tokenizer 与 chat template 是行为接口

官方明确提示 V3.1 对 tokenizer 与 chat template 做了较大调整. tokenizer 决定文本到 token ID 的映射, chat template 决定角色标记, 模式 token, 工具调用和历史消息怎样排进序列. 二者任一错配都可能造成可读文本看似正常, 模型接收的控制序列却不符合训练分布.

模式切换依赖 <think> 与 </think> 的位置, 因而模板不是外围排版. strict Function Calling 也要求工具定义和返回值以约定形式进入上下文. 部署验收至少要分别测试思考与非思考输出, 多轮历史是否移除旧推理段, 工具 schema 是否稳定, 128K 请求是否使用正确位置配置. 发布说明没有承诺兼容 V3 的旧 prompt, 迁移时应按破坏性版本变更处理.

4.3. V3.1 在版本谱系中的位置

V3.1 沿用 V3 网络结构的公开基础, 在 Base 上追加 840B token 长上下文训练, 再把思考, 非思考与 Agent 行为收进一个后训练检查点. 后续 V3.1-Terminus 继续修正语言混杂和工具任务表现, 没有宣布新底座; V3.2-Exp 才公开引入新的稀疏注意力方案. 因而比较 V3.2-Exp 时, 需要把 Terminus 的后训练增量与注意力机制增量分开.

V3.1 的公开信息足以支持部署和结果复核, 不足以复现训练. 未披露项包括 840B token 的数据构成, 双模式样本比例, CoT 压缩目标, Agent 轨迹来源, 奖励形式与完整评测协议. 这些缺口限制的是因果解释, 不影响已公开接口和表格数字本身. 对底座结构应回到 V3 技术报告, 对推理强化学习应回到 R1 报告, V3.1 发布说明主要定义二者合并后的产品与工程边界.

从使用侧看, V3.1 最明确的变化是统一权重与协议. 从研究侧看, 最重要的缺口是没有拆分继续训练, 双模式后训练和 Agent 轨迹各自贡献. 两种视角需要分开: 前者可以按公开配置部署并验收, 后者若缺少消融就不能给出训练因果结论.

5. 长上下文、Agent 与数值格式如何共同决定最终能力

B token 是一次有目标的继续预训练： V3.1-Base 沿用 V3 的 671B 总参数、37B 激活参数框架,模型卡明确写出两阶段长上下文扩展:32K 阶段约 630B token,128K 阶段约 209B token. 两数因取整与官方总称的 840B 略有差异. 这批训练量约为 V3 原始 14.8T token 的 5.7%,不能当成一次从零训练,也绝非只改配置文件里的最大长度.

继续预训练可以看作在原参数 $\theta_0$ 附近寻找适应长序列的新参数:

$R$ 代表保持旧能力的约束,实际训练未必显式写出这一项;混入短文本、降低学习率或限制训练步数都可产生类似效果. 新语料若只含长文档,模型可能改善远距离依赖却损伤短对话分布;若只是把互不相关短文拼接成长序列,token 数够长也学不到有意义的跨段关系.

32K 阶段占大部分 token 有现实理由. 序列长度增长时,同样 token 数对应更少独立样本,attention 与通信开销也上升. 先在 32K 让位置编码和长文统计逐步适应,再用 128K 完成窗口外扩,比直接把所有 batch 拉到上限稳定. 但官方没有公开长度采样分布、packing 规则和跨文档 attention mask,无法进一步复原课程设计.

5.1. K 上限不等于 128K 有效记忆

上下文窗口先是一项接口容量:序列化后的 system prompt、历史消息、工具定义、检索文本和待生成空间合计不能超过限制. 有效记忆则要求模型在长距离干扰中找到正确信息并利用它. 两者之间至少隔着检索、绑定、计算和生成四步.

设目标证据位于位置 $i$,问题位于末端位置 $n$. 模型要让若干 attention head 对 $i$ 分配足够权重,把证据写入残差流,与问题实体正确绑定,再在输出时恢复. 上下文中若出现多个近似实体,模型既要找到目标句，也要避免把另一个日期或数字绑定到问题对象. 单针检索成功并不能保证多证据合成、顺序推理与跨文件约束成功.

位置效应也不可忽略. 同一证据放在开头、中间和末尾,准确率可能不同;填充文本从随机词换成主题相近段落,难度也会改变. 一条完整曲线应覆盖不同上下文长度、证据位置、干扰数量和所需证据数. V3.1 官方材料没有给这类曲线,128K 应按支持长度理解,不能改写成“任意位置均无损记忆”.

生成预算还会挤占输入. 如果接口总预算是 128K,预留 16K 输出后,可用输入小于 128K. chat template、工具 schema 和特殊 token 同样占位. 把仓库原文机械塞满窗口,可能导致最早文件被截断或答案没有生成空间. 使用侧要按 tokenizer 的真实计数规划,字符数和 token 数不能直接等同.

YaRN 扩展改变的是 RoPE 的频率使用方式： V3.1 配置公开了 YaRN 相关项:factor: 40,original_max_position_embeddings: 4096,beta_fast: 32,beta_slow: 1,以及 mscale 参数. RoPE 把每对隐藏维旋转一个与位置相关的角度. 对频率 $\omega_j$,位置 $p$ 的二维旋转可写为

query 与 key 旋转后,内积依赖相对位移 $p-q$. 直接把位置扩大到训练范围之外,高频维会经历未见过的快速相位变化,低频维又可能分辨率不足. YaRN 对不同频段采用平滑插值与外推策略,避免所有频率统一缩放造成短距离分辨率损失.

配置里的 factor 不能简单解释成有效长度恰好扩大四十倍. 原始位置基准、训练阶段、最大位置配置与推理实现共同决定可用区间. Hugging Face 配置给出 max_position_embeddings: 163840,官方服务宣称 128K;部署应遵循模型卡与框架适配,不要只把某个字段相乘得到新上限.

更重要的是位置编码只让网络能够表示远距离关系. 模型还要在长数据上训练,才会学会使用这些频率. V3.1 把两个阶段显著扩充到 630B 和 209B token,正是在补训练分布. 只给 V3 改 RoPE 配置,即使不报 shape 错误,也无法复制 V3.1-Base 的长上下文行为.

长上下文对 Agent 有帮助,但不能替代状态管理： 代码 Agent 的一条轨迹可能包含需求、目录树、几十次文件读取、补丁、测试日志和错误回溯. 128K 容量让更多历史原样留在提示中,降低过早摘要造成的信息丢失. 搜索 Agent 同样可以保留更多候选页面和引用片段. 这是长上下文与 Agent 提升之间合理的联系.

可容量越大,噪声也越多. 旧测试失败、已经废弃的计划、重复网页与相互矛盾的版本都可能留在上下文. attention 每步都能看到它们,不代表会自动选择最新状态. Agent 仍需要显式区分“当前事实”“历史尝试”“待办事项”和“最终证据”,必要时压缩或淘汰旧观察.

一个简单状态模型是把轨迹写成 $(s_t,a_t,o_{t+1})$:模型根据状态 $s_t$ 选择动作 $a_t$,环境返回观察 $o_{t+1}$,再更新状态. 若调用层只把全部文本拼接起来,状态更新由模型隐式完成;若外部维护结构化清单,模型可直接读取当前文件版本、测试结果和未解决约束. V3.1 的模型能力能改善动作选择,却不会消除调用层的状态职责.

反例是一次测试失败后文件已修好,但旧日志仍占大量上下文. 模型可能继续围绕已解决错误搜索. 另一个反例是搜索结果中的旧网页与新官方文档冲突,模型因旧页措辞更完整而选错. 这些失败发生在 128K 容量之内,说明问题是证据治理而非窗口不足.

5.2. Agent 成功率是多步概率的乘积

假设任务需要 $K$ 个关键决策,每步在当前状态下做对的概率为 $p_k$,粗略成功率为

若十步任务每步正确率都是 0.95,整体只有约 0.60. 这解释了为什么单轮代码生成看起来很强,进入真实仓库仍容易失败;也解释了后训练只要把多种常见动作各提高几个百分点,端到端成功率就可能大幅上升.

这个乘积不是严格独立模型. 早期错误会改变后续状态,某些错误可以被测试反馈纠正,不同路径步数也不同. 更贴近实际的评估要统计定位文件、修改正确、测试选择、错误恢复和停止判断等阶段通过率. SWE-bench 最终分只告诉我们全部链条完成多少次,不告诉失败集中在哪一步.

V3.1 在 SWE-bench Verified、Multilingual 和 Terminal-Bench 的提升都指向多步交互改善,但官方说明这些结果使用内部代码 Agent 框架. 框架决定可用工具、提示、最大步数和补丁格式. 模型升级前后若框架相同,纵向比较仍有价值;把 66.0 与另一机构不同 scaffold 的成绩横向排列时,必须核对协议.

搜索 Agent 的核心是价值信息选择： 搜索不是“多调用几次搜索框”. 在预算 $B$ 下,Agent 每一步要选择查询 $q_t$,得到页面集合,再决定打开、追问或停止. 理想策略最大化新观察对答案不确定性的预期降低:

这里 $H$ 表示答案不确定性. 实际模型不会显式精确计算熵,但“换关键词能否带来新证据”“再开一页是否值得”正是搜索策略的核心. 只重复同义查询会消耗步数而不增加信息.

复杂问题还要分解证据. 例如比较两项技术的发布时间、结构与结果,应分别寻找一手发布、论文方法和实验表,再按实体对齐. 模型若过早形成结论,后续搜索容易只寻找支持证据;若永不停止,上下文会被低质量页面淹没. Post-Training 可以用成功轨迹和失败反馈训练查询改写、来源选择与停止策略.

官方模型卡说明搜索评测使用内部框架、商业搜索 API、网页过滤器和 128K 上下文,R1-0528 使用预定义 workflow. 这意味着分数比较混合了模型策略与运行协议,尤其旧基线并非完全相同的自主流程. V3.1 的显著提升是有效系统证据,不能直接当作裸模型搜索能力的纯消融.

引用正确与答案正确是两条指标： 搜索 Agent 可能给出正确答案却引用错误页面,也可能引用可靠页面但在归纳时读错. 因而至少需要三个层次:结论正确性、引文是否蕴含对应陈述、来源本身是否权威. 把链接数量当作质量会鼓励模型堆页面,不解决证据对应关系.

对每条原子陈述 $c_i$ 和引文片段 $e_j$,可构造支持矩阵 $M_{ij}\in{0,1}$. 覆盖率衡量多少陈述至少有一个支持片段,精确率衡量引用是否真的支持附近陈述. 来源质量还要单独建模:参数声明、实验结果与个人经验拥有不同的证据强度,不能仅按文本相关度排序.

V3.1 的 BrowseComp、HLE 等结果反映回答成功率,公开发布页没有逐项给出引用质量统计. 因而可以说它在官方搜索系统中更会完成任务,不能据此宣称每个答案都拥有可审计引用. 用户若把模型用于研究资料整理,仍需让系统保留页面片段、访问时间和陈述映射.

5.3. 工具错误恢复比一次调用成功更接近真实 Agent

现实工具会超时、返回空结果、权限不足或输出格式变化. 一条鲁棒轨迹应识别错误类型,决定重试、改参数、换工具还是请求用户. 若训练只包含顺利执行的成功轨迹,模型可能在看到异常后重复同一动作,形成循环.

可以把恢复策略写成条件概率 $p(a_{t+1}\mid e_t,s_t)$,其中 $e_t$ 是错误观察. 对“文件不存在”,合理动作可能是列目录;对“测试断言失败”,合理动作是读失败上下文;对“网络限流”,合理动作是退避或换已缓存来源. 把所有失败都处理成再次调用,会浪费预算并放大外部副作用.

Terminal-Bench 对命令行交互有较强要求,V3.1 从旧模型基线显著上涨,与错误处理和持续执行能力改善相容. 但总分没有拆出恢复率. 更细的测试可主动注入一次性超时、权限拒绝、损坏 JSON 与过长输出,观察模型能否保持目标、避免危险命令并选择替代路径.

停止同样是一种动作. 测试已经通过后继续修改可能引入回归;搜索已有充分一手证据后继续浏览可能带来冲突噪声. 好的 Agent 不只会做更多步骤,还会在证据满足验收条件时结束. CoT 变短与 Agent 增强同时出现,一种合理但未经证实的解释是训练同时改善了停止判断;官方没有给对应消融.

MoE 的 37B 激活参数怎样理解： V3.1 配置延续 V3 的 MoE 主体:总参数约 671B,每个 token 激活约 37B. 61 层中前 3 层使用 dense FFN,其余 MoE 层拥有 256 个 routed expert 和 1 个 shared expert,每个 token 选择 8 个 routed expert. 总参数决定权重存储规模,激活参数更接近单 token 前向实际使用的计算量.

对第 $l$ 层输入 $h$,路由器产生专家分数 $g_i(h)$,选出集合 $S(h)$,MoE 输出可写成

不同 token 可以选择不同专家,因此总容量很大,单 token 不必跑遍全部参数. 代价是专家权重分散在设备上,路由后需要 all-to-all 通信. 长上下文增加 token 数,会同时放大专家通信和负载均衡压力.

混合思考模式并不意味着思考与非思考各有固定专家. 模式 token 会改变隐藏状态,进而可能改变后续路由分布,但官方没有公布按模式统计的专家选择. 若某些专家更常服务数学推理,那是训练后涌现的条件路由;不能从 256 个专家的配置直接指定其功能.

路由负载还影响吞吐. 若大量 token 集中到少数专家,这些设备形成瓶颈,其余专家空闲. 配置里的 group 与 top-k 约束服务于路由效率,V3 原报告还介绍了无辅助损失的负载均衡思路. V3.1 没有发布新结构报告,应把这些结构归于 V3 底座,不要写成 V3.1 新发明.

MLA 让长上下文可部署,但窗口仍然昂贵： Multi-head Latent Attention 将 key/value 压到较低维潜表示,减少 KV cache. 公开配置给出 kv_lora_rank: 512,128 个 attention head,每头 value 维 128. 若普通 MHA 为每个 token 保存所有 head 的 K/V,元素量近似 $2nhd_h$;MLA 保存低秩潜向量及少量位置相关部分,cache 显著缩小.

以符号表示,输入 $h_t$ 先映射为潜向量

各 head 的 key/value 再由 $c_t^{KV}$ 上投影得到. 推理时缓存 $c_t^{KV}$,不必缓存每个 head 的完整向量. RoPE 相关 key 仍需单独处理,因为旋转位置成分不能简单吸收到同一固定投影中. V3 配置把 qk_nope_head_dim 与 qk_rope_head_dim 分开,对应这两部分.

MLA 缩小 cache 常数,没有消除长度依赖. batch 中每个序列从 32K 增到 128K,cache 仍近似扩大四倍;预填充 attention 也要处理更多 token. 因而 128K 服务需要连续批处理、并行和缓存淘汰策略. 模型支持长窗口与低成本随意使用长窗口是两回事.

CoT 压缩与 MLA 在这里形成互补. MLA 降低每个历史 token 的 cache 成本,CoT 压缩减少历史 token 数. 前者来自 V3 架构,后者是 V3.1 后训练行为. 把二者混成一个“V3.1 新长上下文技术”会丢失版本边界.

UE8M0 描述 scale,不是把权重本体变成指数： 权重量化通常把一个 block 的浮点值 $x$ 写成低精度数 $q$ 与比例 $s$ 的乘积:

V3.1 权重主体使用 FP8 E4M3,UE8M0 用来保存 scale. UE8M0 有 8 位无符号指数、没有尾数,可表示离散的二次幂比例. 官方配置还给出权重 block size $128\times128$ 与动态 activation scheme. 因而准确说法是“FP8 block 量化采用 UE8M0 scale 格式”,并非所有参数都只有一个指数.

对 block 最大绝对值 $a$ 和 FP8 最大可表示值 $m$,理想 scale 为 $s=a/m$. 若向上量化到二次幂 $\hat s=2^{\lceil\log_2s\rceil}$,则 $s\le\hat s<2s$. 这样能降低溢出风险,代价是量化步长最多接近理想值两倍. 小值的相对误差会变大,但乘二次幂在硬件上更容易处理,scale 元数据也从 FP32 的四字节降为一字节.

block 大小体现另一组取舍. block 越小,scale 越贴合局部分布,离群值只影响少量元素;scale 数量和读取开销也越大. $128\times128$ 是公开配置中的具体选择. 推理框架若误用 tensor-wise scale 或把 UE8M0 当普通整数比例,会造成格式不兼容，反量化结果会系统性错误.