DeepSeek-V3.1-Terminus 发布于 V3.1 之后约一个月. 官方材料只有两页: 三条改进说明, 一张包含十二项成绩的 V3.1 对照表, App, Web, API 与开源权重入口. 页面没有网络结构, 数据规模, 训练日程或后训练算法, 因而 Terminus 应被理解为 V3.1 权重线上的行为修订, 不能当作另一个已披露架构的新底座.
十二项成绩分成两组. 第一组是 reasoning mode w/o tool use, 即禁止工具的思考模式; 第二组是 agentic tool use, 即允许工具交互的 Agent 设置. 分组决定了分数含义. HLE 21.7 衡量闭卷推理, BrowseComp 38.5 与 SWE Verified 68.4 则包含模型和工具执行框架的共同作用. 两组数字不能混成一条统一能力刻度.
1. 同一权重线上的修订范围
Terminus 是 V3.1 同一权重路线上的行为修订, 不是一份公开了新架构的完整技术报告.
1.1. 为什么把 Terminus 归为后训练更新
发布页标题直接写成 DeepSeek-V3.1 → DeepSeek-V3.1-Terminus, 并称更新建立在 V3.1 的能力之上. 页面没有宣布参数量, 层数, MoE 配置, 上下文长度, tokenizer 或 UE8M0 格式变化. Hugging Face 仓库名也保留 DeepSeek-V3.1 前缀. 现有材料支持「沿用 V3.1 底座并修订后训练行为」, 不支持具体到某种优化算法的判断.
对照表中的 V3.1 一栏与前一版发布材料能够逐项对上. BrowseComp 30.0, BrowseComp-zh 49.2, SimpleQA 93.4, SWE Verified 66.0, SWE-bench Multilingual 54.5 与 Terminal-Bench 31.3 都来自 V3.1 Agent 表; GPQA-Diamond 80.1 与 LiveCodeBench 74.8 也对应 V3.1 的 CoT 压缩图. 这说明 Terminus 页面沿用同一组 V3.1 基线, 至少没有另换一个旧模型口径.
沿用基线不等于所有新分数都由完全相同的运行环境重跑. 页面没有列 Agent 框架版本, 搜索接口, 最大步数, token 预算, 温度和采样次数. 因而对照表适合描述官方系统的版本差异, 不足以让第三方只凭权重复现到相同小数位. 对 5 分以上的变化可以确认方向明显, 对 0.1–0.6 分的差距则要保留采样波动空间.
1.2. V3.1 的部署假设仍然有效
Terminus 没有发布新的 tokenizer, chat template 或量化说明. 在缺少相反声明时, 部署应沿用 V3.1 的 128K 上下文, 双模式模板与 UE8M0 FP8 Scale 处理方式, 同时以 Terminus 仓库内实际配置为准. 这是一条部署兼容判断, 不是官方明确承诺; 页面没有写「与 V3.1 二进制兼容」.
思考与非思考模式仍由同一权重承载. Terminus 表只给思考模式的无工具成绩和 Agent 的工具成绩, 没有单列非思考通用问答. 因而无法从表格判断语言一致性修复是否同等覆盖两种模式, 也无法判断短回答长度是否变化. App, Web 与 API 同时上线说明产品入口不变, 不能代替模式级回归数据.
双模式回归至少包含四种组合: 思考模式的纯文本回答, 非思考模式的纯文本回答, 带工具的单轮执行, 带历史的多轮执行. 语言混杂可能只在长推理段出现, 也可能在工具观察加入上下文后出现. 十二项表格没有按组合拆分, 因而某一组任务上涨不能证明所有入口都修复到相同程度.
同一份权重还会让修订相互牵连. 提高语言一致性可能使模型减少自由切换语言, 而搜索 Agent 有时需要用另一种语言构造查询; 强化工具格式可能提高结构化输出成功率, 同时改变自然语言回答的 token 分布. BrowseComp 英文上涨而中文回落说明至少存在一个方向不一致的结果. 没有消融时, 最稳妥的解释是 Terminus 重新平衡了多项目标, 并非在 V3.1 上增加一个互不影响的独立模块.
V3.1 的模板会在非思考模式预先闭合 </think>, 并在多轮历史中移除旧推理文本. Terminus 若专门修正混杂与随机字符, 模板处理错误仍可能在部署端重新引入异常. 权重修订只能改变模型分布, 无法纠正调用方使用旧 tokenizer, 错误特殊 token 或把历史思考段重复拼接的行为.
2. 语言一致性修复了哪类失败
2.1. 中英文混杂是序列级行为
官方第一条改进是 fewer CN/EN mix-ups & no more random chars. 中英文混杂指回答在没有语义需要时切换语言, 例如中文解释中突然转为英文段落, 或代码说明与用户语言不一致. 对双语模型而言, 两种语言的 token 都在可生成集合中. 问题不在模型能否生成另一种语言, 而在当前对话条件下能否持续维持目标语言.
语言一致性通常受指令数据分布, 推理轨迹语言与奖励共同影响. DeepSeek-R1 曾公开使用语言一致性奖励, 按 CoT 中目标语言词的比例提供信号, 并承认可读性约束可能牺牲少量推理表现. Terminus 页面没有说复用了该方法. 把混杂减少归因于某个奖励函数会超过材料范围; 可以确认的只有输出行为被纳入了修订目标.
语言约束也不能简单设成「全中文」或「全英文」. 代码标识符, API 名, 引文和专有术语需要保留原语言. 有效目标是保持叙述语言稳定, 同时允许必要的局部切换. 如果奖励只统计字符比例, 模型可能为了提高比例而翻译不该翻译的标识符. 页面没有给语言识别规则, 测试集或混杂率, 因而无法判断修复对代码与技术写作的边界处理.
CoT 又增加一层约束. 用户要求中文回答时, 推理段与最终答案可能采用不同语言; 如果服务端隐藏推理段, 用户只观察到答案语言, 训练侧却仍要控制隐藏部分. R1 的语言一致性奖励曾显示, 约束推理语言会影响推理表现. Terminus 没有分别报告可见答案和思考段的语言比例, 因而「fewer CN/EN mix-ups」究竟覆盖哪个区段并不明确.
衡量混杂也需要把字符, token 与语义片段分开. 英文缩写和代码标识符不应算失败, 一整句无缘由换语种则应算失败, 单个异常汉字又属于噪声字符. 如果只按 Unicode 范围计数, 三类现象会被混在一起. 官方没有发布判定器和测试集, 第三方只能根据自己的产品语言定义建立回归集合, 不能复算发布声明的绝对幅度.
2.2. 随机字符为何比文风问题更严重
no more random chars 指向局部异常 token. 随机字符若出现在自然语言段落, 会降低可读性; 若插入代码, JSON 或函数参数, 可能直接造成编译和解析失败. 用户曾报告 V3.1 输出中出现孤立汉字或不合上下文的字符, 但官方两页说明没有列具体字符, 频率和根因. 因而应保留官方的现象级表述, 不把社区样例当作完整故障定义.
异常字符可能来自训练样本噪声, tokenizer 边界, 模式 token 附近的分布偏移或解码尾部失稳. 多种原因都能产生相似输出, 仅凭「消失」无法定位根因. Terminus 没有提供异常率对照, 也没有给修复前后的受控提示集合. 「no more」是发布声明, 不是统计意义上的零故障保证.
工程验收需要覆盖字符异常最容易造成损失的结构化场景: 代码补丁能否编译, JSON 是否通过 schema, 函数参数是否保持字段名, Markdown 围栏是否闭合, 多轮长输出是否在尾部出现噪声. 这些检查与 benchmark 分数不同. 十二项表格衡量任务成功或知识问答, 没有直接测量中英文混杂率与随机字符率.
2.3. 稳定可靠不等于每项分数上涨
发布页称 Terminus 在各项 benchmark 上输出更稳定可靠, 但表中存在回退: Codeforces 从 2091 降至 2046, Aider-Polyglot 从 76.3 降至 76.1, BrowseComp-zh 从 49.2 降至 45.0. 因而「稳定可靠」更适合解释语言与格式行为, 不能改写成所有能力指标单调提高.
稳定性若按统计定义, 应报告多次采样的方差, 置信区间或失败率分布. 页面只给单列分数, 没有误差条和重复次数. 0.1 分的 LiveCodeBench 变化与 0.2 分的 Aider-Polyglot 回退都不足以单独支撑稳定性判断. HLE 增加 5.8 分, BrowseComp 增加 8.5 分, Terminal-Bench 增加 5.4 分, 这些大变化才构成清晰的能力信号.
3. 无工具推理成绩的结构
3.1. 六项结果并非同一量纲
无工具组为 MMLU-Pro 84.8 → 85.0, GPQA-Diamond 80.1 → 80.7, HLE 15.9 → 21.7, LiveCodeBench 74.8 → 74.9, Codeforces 2091 → 2046, Aider-Polyglot 76.3 → 76.1. 前五项变化分别是 +0.2, +0.6, +5.8, +0.1 与 -45 Elo, 末尾一项是 -0.2. Codeforces 使用 Elo 类分值, 不能与百分制项目直接比较绝对差.
MMLU-Pro 与 GPQA-Diamond 主要测知识和推理, LiveCodeBench 与 Codeforces 偏代码生成, Aider-Polyglot 偏多语言代码编辑. HLE 覆盖多学科高难问题. Terminus 的最大增量落在 HLE, 而代码组基本持平或小幅回落, 说明修订没有形成所有任务共振的统一提升. 页面没有任务级消融, 不能判断这种差异来自数据选择还是优化取舍.
GPQA-Diamond 约 198 题, 单题对应约 0.5 个百分点. 80.1 到 80.7 接近多答对一题的量级, 还取决于是否多次采样取平均. MMLU-Pro 的 0.2 分与 LiveCodeBench 的 0.1 分也需要结合方差读取. 官方没有给采样次数, 温度和置信区间, 因而这些小差值更适合表述为「基本持平」.
3.2. HLE 的 5.8 分增量意味着什么
HLE 从 15.9 升至 21.7, 绝对增加 5.8 分, 相对增幅约 36.5%. 在同一表的无工具协议下, 这是明确的大幅变化. HLE 包含跨学科高难问题, 分数提高说明 Terminus 在该评测所需的知识调用与推理链上更有效, 但不能由一项综合分数定位具体学科.
V3.1 另一份发布表曾给出 HLE 29.8, 该数字属于搜索 Agent, 允许调用工具. Terminus 页的 21.7 明确属于 w/o tool use. 两个数字的差异展示了工具检索对成绩的贡献, 也说明版本比较必须锁定协议. 若把 29.8 当作 V3.1 闭卷分数, 会错误得出 Terminus 大幅退步的结论.
Terminus 页面没有给带工具 HLE 的新成绩, 所以不能判断闭卷增量是否会传递到搜索 Agent. 工具场景还受查询生成, 页面选择和答案引用影响. 闭卷推理更强可以改善中间判断, 但最终成绩仍取决于 Agent 轨迹训练与执行框架.
HLE 的总分聚合不同学科和题型. 如果增量集中在少数学科, 21.7 的总体分数无法展示分布; 如果来自拒答减少, 又与推理步骤本身不同. 官方没有逐科成绩, 错误类型和回答长度. 因而该分数适合说明综合高难闭卷任务明显提高, 不适合声明所有学科均提高 5.8 分.
与 GPQA-Diamond 的小幅上涨结合读取时, Terminus 并非在所有科学问答上获得同幅增益. GPQA 只增加 0.6 分, HLE 增加 5.8 分. 两个题集的知识范围, 难度和评分协议不同, 差异可能来自数据覆盖或推理策略. 缺少题级结果时, 不能进一步选择其中一种解释.
3.3. 代码指标揭示了修订代价
LiveCodeBench 74.8 → 74.9 基本持平, Codeforces 2091 → 2046 下降 45, Aider-Polyglot 76.3 → 76.1 小幅下降. 这组结果说明语言一致性与 HLE 增益没有免费覆盖所有代码能力. 共享参数上的后训练修订可能改变输出风格, 搜索策略和解题长度, 任何一项都可能影响代码评测, 但页面没有提供因果分解.
Codeforces Elo 对题目集与比赛模拟设置敏感, 45 分是否显著需要重复运行和区间. Aider-Polyglot 的 0.2 分更可能处于小波动范围. 可靠结论是代码无工具组没有明显提升, 而不是「代码能力全面下降」. 代码 Agent 组反而在 SWE 与终端任务上涨, 表明裸代码生成和环境内执行需要分开评价.
4. Agent 成绩的收益与回退
Agent 评测总体上涨, 但搜索能力的提升不具跨语言一致性.
4.1. 代码 Agent 提升发生在环境交互
SWE Verified 从 66.0 升到 68.4, SWE-bench Multilingual 从 54.5 升到 57.8, Terminal-Bench 从 31.3 升到 36.7. 在 SWE Verified 的 500 个问题上, 2.4 分约对应多解决 12 个问题. 多语言子集增加 3.3 分, 终端任务增加 5.4 分, 三项方向一致.
SWE-bench 的最终结果由定位文件, 编辑补丁, 运行测试和根据失败反馈修正共同决定. Terminal-Bench 则要求在命令行环境持续执行动作. 这些任务与 LiveCodeBench 的单次生成不同. Terminus 在 Agent 组提升, 同时 LiveCodeBench 近乎持平, 支持「改进集中在多步工具使用」的描述.
三项结果还覆盖不同的失败层. SWE Verified 主要受仓库理解和补丁正确性影响; SWE-bench Multilingual额外加入非英语需求理解; Terminal-Bench 对命令选择, 环境状态和错误恢复更敏感. 三项同时上涨, 比单一 benchmark 的提高更能支持工具行为得到改善. 但它们仍共享 Agent 框架这一外部变量, 不能进一步推出具体训练数据类型.
按绝对增量看, Terminal-Bench 的 5.4 分最大. V3.1 已从 V3-0324 的 13.3 提高到 31.3, Terminus 又到 36.7, 说明这条权重线连续把优化重心放在环境内执行. 该趋势与无工具 Codeforces 回落并不冲突: 前者奖励完整任务成功, 后者更接近单题代码推理. 一个模型可以更会使用测试反馈, 同时在固定竞赛题协议下没有提高.
Agent 分数仍然是模型与脚手架的系统结果. 页面没有说明最大步数, 命令超时, 测试重试和上下文压缩策略. 若 Terminus 与 V3.1 使用相同框架, 差值可归到权重版本; 页面虽沿用旧基线, 却没有明确写出框架完全一致. 第三方复现应固定框架和预算, 再比较两个权重.
4.2. 英文 BrowseComp 上涨, 中文版本回落
BrowseComp 从 30.0 升到 38.5, 绝对增加 8.5 分, 相对增幅约 28.3%. BrowseComp-zh 则从 49.2 降到 45.0, 回落 4.2 分. 两项任务都强调多步浏览, 方向却相反, 是整张表中最需要保留的反例.
语言一致性修复可能改变查询语言和页面选择, 但这种联系没有官方证据. 英文和中文版本也可能在题目, 搜索索引, 页面可用性与评测时间上存在差异. 因而不能把中文回落直接归因于语言奖励. 可以确认的是 Terminus 的 Search Agent 增益不具有跨语言一致性.
SimpleQA 从 93.4 升到 96.8, 增加 3.4 分. SimpleQA 更接近短事实问答, 高分区间的提升说明事实检索或答案约束有所改善. 它与 BrowseComp 的多轮搜索难度不同, 两者一起上涨不能证明使用了同一种改进. 页面没有按错误类型拆分, 也没有给引用正确性或检索轮数.
搜索任务的最终分数由查询生成, 文档获取, 证据选择和答案生成串联得到. BrowseComp 更依赖前几步反复迭代, SimpleQA 更容易在较短路径内完成. 英文 BrowseComp 增加 8.5 分说明长路径成功率提高, SimpleQA 增加 3.4 分则说明短路径没有因此退化. 中文 BrowseComp 的相反结果提醒读者, 这种改进没有覆盖所有检索分布.
若搜索后端在两个版本评测之间发生索引更新, 页面内容变化也会影响结果. 官方沿用 V3.1 的旧分数, 却没有给两版是否同日运行的信息. 因而对动态网页任务, 权重差异与环境时间差可能同时存在. 这不会抹去官方对照表, 但第三方重跑时不应期待逐项精确复现.
4.3. Agent 表应怎样用于版本选择
如果任务以真实仓库修复和终端操作为主, Terminus 的三项代码 Agent 分数都优于 V3.1, 版本选择有一致依据. 如果任务以中文深度搜索为主, BrowseComp-zh 的回落要求单独回归, 不能由英文 BrowseComp 的上涨替代. 如果任务主要是闭卷代码生成, 两版差距很小, 还应比较延迟, 输出稳定性和实际代码库测试.
版本选择不能只看十二项平均. 这些指标量纲不同, 直接求平均会让 Codeforces Elo 与百分制混在一起. 更合理的做法是按应用路径选择对应组, 固定工具框架与预算, 再用自有失败样本测语言混杂, 结构化输出和随机字符. 官方表给出候选方向, 应用侧回归决定迁移风险.
5. 可确认结论与资料边界
5.1. 从 V3.1 到 Terminus 的变化
Terminus 没有宣布新网络结构, 公开定位是 V3.1 的修订版. 官方明确提出三类结果: 中英文混杂减少, 随机字符消失, Code Agent 与 Search Agent 能力加强. 表格支持代码 Agent 三项上涨, 搜索组则是英文 BrowseComp 与 SimpleQA 上涨, 中文 BrowseComp 回落. 无工具组最大的增量来自 HLE.
这些变化符合后训练调整的外观, 但具体训练方法没有披露. 页面没有说明数据规模, 轨迹来源, SFT 或强化学习阶段, 奖励设计和 CoT 压缩是否继续变化. 因而可靠描述应停留在可观察行为与结果, 不把某个常见算法写成 Terminus 的事实.
Terminus 也不是 V3.2-Exp 的架构更新. 后续 V3.2-Exp 才公开引入 DeepSeek Sparse Attention. 比较稀疏注意力的收益时, 应优先用 Terminus 作为前序行为基线, 避免把 Terminus 已取得的 Agent 与 HLE 增量计入注意力改动.
5.2. 公开材料无法回答的问题
语言一致性没有直接指标, 随机字符没有测试集合和故障率. 十二项 benchmark 衡量知识, 推理, 代码与工具任务, 不直接测两条发布主张. 因而「混杂减少」与「随机字符消失」目前是官方定性结果, 无法从表格复算.
评测协议也不完整. 无工具组缺少采样次数, 温度, 最大生成长度与置信区间; Agent 组缺少框架, 工具实现, 最大步数和失败重试. 这些信息不足不会使表格失效, 但限制跨机构比较和因果解释. 小数点后一位的微小变化应谨慎读取, 5 分以上且方向稳定的变化更有版本判断价值.
部署层没有新的价格, 路由名与模板说明. App, Web, API 已上线, 开源权重位于 deepseek-ai/DeepSeek-V3.1-Terminus. 实际部署仍需以仓库配置和 V3.1 文档为准, 分别验证双模式, tokenizer, UE8M0, 工具 schema 与多轮历史处理. 权重更新改善模型分布, 但不会自动修复调用栈中的模板错配.
迁移测试应保留 V3.1 与 Terminus 的同一批输入, 同一解码参数和同一工具环境. 纯文本集合测目标语言保持, 长回答尾部与特殊字符; 结构化集合测 JSON Schema, 函数名和参数类型; Agent 集合测工具失败后的恢复以及最大步数内的成功率. 固定外部变量后, 才能把变化归到权重版本.
线上监控也应把能力失败与格式失败分开. 答案错误, 工具选择错误, JSON 无法解析, 语言无故切换和随机字符属于不同故障类. 若只记录最终成功率, Terminus 声称修复的输出问题会被任务难度掩盖. 页面没有给官方分类标准, 应用侧可以依据自身协议定义, 但不能把内部统计写成官方数字.
Terminus 的资料边界很明确: 两页内容支持版本定位, 输出问题描述和十二项结果对照, 不支持训练复现. 在这个范围内, 可靠的版本判断是代码 Agent 与英文搜索取得较大增量, HLE 闭卷推理明显提高, 中文 BrowseComp 和两项代码指标存在回退, 语言一致性改善仍缺少公开定量指标.