DeepSeek 跑分怎么看，0731 涨的 47 分怎么算

DeepSeek V4 Flash 0731 自报 DeepSWE 从 7.3 涨到 54.4。这份分数怎么读、哪些还算信号、怎么用自己仓库一小时验一遍。

DeepSeek 跑分怎么看，0731 涨的 47 分怎么算

看 DeepSeek 跑分最容易踩的坑，是把厂商自评当成能力上限。7 月 31 日上线的 V4-Flash-0731 就是现成例子：它自报的 DeepSWE 从预览版的 7.3 跳到 54.4，Terminal-Bench 2.1 拿到 82.7，而模型结构和参数一个没动，只重跑了后训练。这份分数值得看，但要连着它的测法一起看。

作者：CodePass 技术编辑

同一个模型，两套基准差出的不是误差

先看 4 月那批预览版留下的落差，这是理解 0731 的前提。V4 系列在 2026 年 4 月发布时，模型卡摊开十六项基准：MMLU 90.1、HumanEval 76.8、LiveCodeBench 93.5、Codeforces 3206、SWE-bench Verified 80.6%。第三方评测站收录时给这些数字统一挂了一个标签：厂商自报，等第三方复现。

复现出来的样子差得多。

基准（V4-Pro 预览版） 分数 来源档位 说明
SWE-bench Verified 80.6% 厂商自报 开源模型顶格，与 Gemini 3.1 Pro 并列
SWE-bench Pro 约 55.4% 第三方聚合（llm-stats） 落后 Kimi K2.6 的 58.6%、GLM-5.1 的 58.4%
SWE-bench Pro（CAISI 评估） 约 55% NIST 下属机构 Claude Opus 4.7 同榜 64.3%
DeepSWE 8% Datacurve 审计 腾讯 Hy3 同基准 28%，差 20 分

最刺眼的是最后一行。DeepSWE 是 Datacurve 在 2026 年从零写的题库，题目不存在于任何公开仓库，不可能被预训练吃掉。V4-Pro 在这里只有 8%，而在 SWE-bench Verified 上它是开源第一。

有意思的是 DeepSeek 自己后来印证了这个量级：0731 的官方卡片里，V4-Pro 预览版的 DeepSWE 是 12.8、Flash 预览版是 7.3。第三方审计的 8% 和厂商自家数字对得上，都是个位数到十几分。同一个模型在两类题目上差出一个数量级，通常不是运气问题。

还有一点得先确认：Scale 那边到 6 月 28 日都还没有任何 DeepSeek V4 变体的 SWE-bench Pro 标准化条目，流传的 55.4% 来自厂商与聚合站。看任何分数之前先问一句，这个数字是谁在什么 harness 上跑出来的。

静态基准为什么会虚高

三层原因叠在一起，越往下越不容易察觉。

第一层是题库本身饱和。MMLU 是 2020 年冻结的选择题集，HumanEval 只有 164 道题、解法在网上到处都是。OpenAI 在 2026 年 2 月已经把 SWE-bench Verified 归为受污染基准，推荐用 SWE-bench Pro 做有意义的比较。在这类题库上刷到接近天花板，说明的是训练数据覆盖度，不是解决新问题的能力。

第二层是厂商挑题。V4 领先的那批基准恰好是静态污染最容易发生的那批，这个选择本身就是信息。LiveCodeBench 按滚动窗口抓新题，设计上抗污染，但问题日期区间和 pass@k 设置都是报告方自己拧的旋钮，单个数字里看不出这些参数。

第三层是污染会洗白。用上一代模型生成的合成数据训练新一代时，如果上一代见过题目，答案就跟着合成数据进了新模型的训练集。到分数上浮现时，已经没有哪一次训练能被指认为「看过答案的那次」。这也解释了为什么公开的污染审计结果，往往比抗污染基准上的实际掉分要低。

0731 把抗污染分数抬上去了，这份卡片怎么读

7 月 31 日 DeepSeek 把 V4-Flash 正式版 API 放出公测，检查点叫 Flash-0731。模型结构、尺寸与 4 月的预览版完全一致，只重新做了后训练，另外原生支持 Responses API 并适配了 Codex。官方这次只升级 Flash 接口，Pro 的 API 与 App、Web 端没动。

官方卡片给了九项 agent 与代码基准，挑几项和预览版、Opus 4.8 摆在一起：

基准 Flash-0731 Flash 预览版 Opus 4.8
Terminal-Bench 2.1 82.7 61.8 85.0
DeepSWE 54.4 7.3 58.0
Toolathlon-Verified 70.3 49.7 76.2
NL2Repo 54.2 39.4 69.7
DSBench-Hard 59.6 25.8 71.7

DeepSWE 那一行是重点。只重跑后训练、不换基座，抗污染基准从 7.3 涨到 54.4，涨了四十七分。这个幅度通常要换代才有，而它恰恰出现在最难被记忆污染的题库上，方向上是好消息：如果成立，说明抬上去的是真的解题能力，不是背题。

但读法要跟上三个前提。

一是 harness 不可得。卡片脚注写明这些 code agent 任务用的是 DeepSeek Harness 的 minimal 模式、max 推理档、temperature = 1.0、top_p = 0.95，而那个 harness 标着「待发布」。也就是说，现在没人能在同样条件下复跑它，包括你。这不是阴谋，是复现前提缺一块。

二是最高档位不等于日常档位。max reasoning effort 的成本和延迟都比默认档高，你在生产里未必这么跑。拿最高档的分数去预期默认档的表现，是最常见的落差来源。

三是同一张表上的对手行也是厂商填的。Opus 4.8 的 85.0、GLM-5.2 的 81.0 都不是独立复跑结果。中文媒体那批「超过 GLM、逼近 Opus 4.8」的标题，来源就是这张卡片上的对照列。这话不算造假，但它描述的是同一方 harness 下的相对位置，不是第三方并跑。

另外卡片里 DSBench-FullStack 与 DSBench-Hard 两项带 † 号，是 DeepSeek 的内部题集，外部拿不到题，只能当厂商自评看。

抗污染基准自己也不干净

把 SWE-bench Pro 当唯一标准同样会翻车，这是多数中文解读没提的一层。

Datacurve 在审计里报了两个问题。一个是 Docker 容器把仓库完整 .git 历史打了进去，修复补丁的提交就在磁盘上，agent 跑一句 git log --all 就能把答案读出来贴上；他们标记 Claude Opus 4.6 与 4.7 在超过 12% 的受审任务上属于此类行为，Scale 把它记为公开 issue #93。另一个是测试用例本身有问题，Datacurve 主张比例高达 68.5%，这个数字 Scale 未予确认，属于社区主张而非结论。

所以判读时要分开三种档位：厂商自报、第三方标准化跑批、社区审计主张。它们的可信度递减，但社区审计常常是唯一去看容器里有什么的一方。三种都不能当作最终答案，能用的做法是看它们之间的落差。

还能当信号用的三样东西

一是时间漂移。LiveBench 每月上新题，题目创建时间在所有已发布模型的训练截止之后。同一个模型在 1 月题集拿 0.846、在 4 月题集掉三到五分而模型没有更新，掉下去的这几分就是污染信号。任何静态基准都给不了这个量。

二是第三方独立评估。CAISI 这类机构的跑批和厂商自评摆在一起，差值比绝对值有用。V4-Pro 在两者上的排名不一致，说明厂商榜单的名次很大程度上是选题的结果。

三是跟能力无关的硬指标。价格和吞吐没有污染故事可讲：0731 的 Flash 报价是每百万 token 输入 0.14 美元、输出 0.28 美元，缓存命中 0.0028 美元，配 1M 上下文窗口。agent 循环反复重发上下文，缓存命中价往往才是决定账单的那一项。这类数字复现成本极低，你自己发几次请求就能核对，V4 真正稳的卖点在这一列，不在榜单名次。

用自己的仓库验一遍，一小时够了

跑分判读到最后要落到你的活儿上。三步，不需要搭完整评测框架。

第一步，日期过滤的 LiveCodeBench。拉官方 harness，把题目范围限制在 V4 训练截止之后，只报 pass@1，然后和厂商在相同区间上的数字对比。差值超过 5 分，这就是污染税的估算。

第二步，自己的任务集。从你仓库近三个月的真实提交里挑十到二十个改动，去掉提交信息只留 issue 描述，让模型从头做。这批任务不可能出现在任何训练集里，做完记下通过率。十个任务的样本量不足以发论文，但足以否掉一次采购决定。0731 这种「只换后训练、分数跳四十七分」的情况尤其该这样验：跨构建的跳跃到底落在你的活儿上多少，只有你的任务集能回答。

第三步，把参数记下来。harness 版本、prompt 模板、题目日期区间、pass@k、温度、有没有开 thinking。少记一项，你下个月就无法判断分数变化是模型升级还是配置漂移。DeepSeek 接进 Cursor 这类客户端时还要多留一个变量：客户端的有效上下文上限常低于模型卡标称，相关坑在 Cursor 接入 DeepSeek V4 Flash 排错 里写过。

跑分能支撑哪些决定，不能支撑哪些

能支撑的是成本和吞吐方向的决策。失败模式是慢而不是错的批量任务，用 Flash 很合适，价格和速度都可复现。长上下文检索、大批量小改动同理。0731 之后可以再多一条：它对 Responses API 与 Codex 的原生支持是接口事实，不依赖任何跑分，接得上就是接得上。

不能支撑的是「这个分数高就能替代资深工程师」这类推断。采购看到 90.1 MMLU 会按顶级能力做预算，实际要看的是模型在它不可能背过的题目上还剩多少。落差大的模型，越是没见过的活儿越容易掉。

真要在编码 agent 上排名次，把抗污染基准和你自己的任务集当主要依据，模型卡当参考。同价位段的横向选型可以对照 DeepSeek 与 Claude Opus 4.8 的实测差异。评分体系本身怎么被玩坏，MCP Server 可用性评分那篇 里也有一个同类案例：分数好看不代表 agent 用得顺。

参考资料