DeepSeek-V4-Pro 正式版没有预热，没有发布会，只在 API 更新日志里扔下三件事：Agent 能力上台阶，峰谷定价把闲时成本砍半，模型在 APP、网页端和 API 同步可用。调用名设为 deepseek-v4-pro。HLE 无工具 / 带工具成绩达到 42.7 / 60.0，Terminal Bench 2.1 拿到 87.9。
Agent 分数先拆开看
HLE 42.7 和 60.0，中间不是小数点，是工具链
先看 HLE 这组数字。无工具模式下 42.7，带工具模式下 60.0，两者相差超过 17 分。这个差距比看起来更重要，因为它不是模型突然变聪明了，而是 工具调用把模型的能力边界向外推了一圈。HLE 本身不是普通问答测试，题目设计得十分刁钻，前沿模型也很难刷出漂亮分数。42.7 的无工具成绩说明 DeepSeek-V4-Pro 在纯推理层面已经进入第一梯队；一旦接上工具链，它能够搜索、执行、验证、再修正，分数就跳到 60.0。对于开发者来说，这意味着模型更适合被放进 Agent 工作流，而不是只拿来当对话引擎。很多任务不是一步推理能解决的，模型需要调用外部环境、观察反馈、调整下一步动作。工具链的价值恰恰体现在这种多步闭环里。
Terminal Bench 87.9 讲的是终端操作
Terminal Bench 2.1 的 87.9 分更值得拆开看。终端环境没有聊天窗口，没有按钮，只有命令、输出和报错。模型要理解当前目录、文件状态、进程列表，还要在报错后判断是权限问题、路径错误还是参数缺失。一个只在聊天窗口表现好的模型，进入终端经常会陷入循环：重复执行同一条错误命令，或者忽略输出里的关键信息。87.9 分意味着 DeepSeek-V4-Pro 在 终端操作上具备不错的稳定性和纠错能力。对做自动化脚本、运维助手、代码代理的团队来说，这个分数比很多通用跑分更能反映实际可依赖性。终端操作容错率低，命令一错就会带来副作用，模型必须学会先看后做，而不是先做再猜。
三端同步上线，用户先感受到什么
这次发布没有把 APP、网页端和 API 拆成三批。正式版一次上线，API 调用名直接设为 deepseek-v4-pro，开发者不需要填申请表，也不用等灰测名额。这意味着 DeepSeek 对模型稳定性已经有足够把握，而不是把一个实验版本先扔给公众测试。对 APP 和网页端用户来说，最明显的感受可能是多步任务更连贯了：模型在需要查资料、做计算、整理结果时，不再频繁断线或过早停止。过去很多 Agent 能力停留在演示里，切到正式环境就失效。三端同时发正式版，至少说明 DeepSeek 自己认为这版模型可以扛住真实流量，而不是只适合做录屏。
峰谷定价不是促销，是重新定义 API 的时间成本
闲时砍半，便宜的那半从哪来
API 定价通常只有两个变量：token 数量和单价。DeepSeek-V4-Pro 多了第三个变量：时间。峰谷定价把闲时成本降到高峰的一半，等于把波谷算力当成一种可定价资源。算力在白天紧张，在夜里空闲，这是云厂商一直以来的难题。固定价格无法反映这种供需波动，用户也没有动力错峰。现在闲时价格更低，可延迟任务就有了经济动机往低峰移动。厂商赢在算力利用率，用户赢在成本下降。但便宜不是白来的，它要求团队具备任务调度能力，否则价格降下来，任务却还在高峰时段跑，账面上省不到一分钱。
批量推理和评估任务，最适合干夜班
最适合闲时价格的不是实时对话，而是那些不需要马上返回结果的工作负载。批量推理、离线评估、数据标注、回归测试、索引构建，这些任务天然可以排队。它们不需要毫秒级响应，晚几个小时执行通常没有影响。把这些任务从高峰挪到闲时，等于在不改变模型选择、不压缩提示词的情况下，直接减少近一半 API 支出。问题在于，很多团队没有把任务分类，所有推理请求都走同一条实时通道。等到账单出来才发现，大量离线任务一直按高峰价跑。峰谷定价出来后，任务分类和调度不再是可选项，而是成本控制的基本动作。
API 成本控制的旧习惯要改一改
过去控制 API 成本，通常靠三招：换更便宜的模型、缩短上下文、缓存提示词。这些方法依然有用，但 峰谷定价增加了一个新维度。现在成本不只是“调用什么”决定的，也是“什么时候调用”决定的。预算管理需要把时间窗口纳入模型选型和流程设计。高峰时段适合在线服务，闲时适合大批量任务，二者必须分开计价、分开调度。这个变化会逼着团队在推理管线上加一层调度逻辑，自动识别任务类型，匹配价格时段，甚至在不同时段选择不同副本。看起来只是半价，实际上改变的是整个 API 消耗结构的组织方式。
接下来盯调度层和竞争位
模型能力不再是唯一变量
DeepSeek-V4-Pro 这波发布把 Agent 能力和峰谷定价绑在一起，传递的信号很清楚：模型竞争已经越过单纯的跑分阶段。一个模型强不强，要看它能不能在真实环境里完成任务；一个 API 划不划算，要看它能不能配合业务的时间节奏。开发者在选模型时，过去习惯看几项基准分和 token 单价，现在还得看工具调用稳定性、终端操作能力，以及价格是否随时段波动。模型能力不再是唯一变量，工程适配成本、调度复杂度和长期 API 支出一起进入了决策表。
可延迟工作负载需要新的调度策略
峰谷定价真正落地，需要团队重新梳理工作负载。实时任务必须留在高峰，准实时任务可以短时排队，可延迟任务应该主动匹配闲时。这个分类听起来简单，做起来涉及队列管理、重试机制、结果校验和监控告警。比如批量评估任务在午夜运行，失败后如果没有自动重试，第二天早上才发现结果缺失，成本反而更高。调度策略不只是把任务推迟，还要保证任务在便宜时段可靠完成。否则省下的 API 费用会被人力和时间成本吃掉。
DeepSeek 这步棋的后续影响
峰谷定价一旦跑通，其他 API 厂商很难完全不跟进。算力有波峰波谷，谁先利用时间价格引导负载，谁就能提高利用率、摊薄固定成本。对开发者来说，这既是机会也是新的复杂度。接下来值得观察的是，DeepSeek 会不会把峰谷定价扩展到更多模型，以及开发者社区能不能围绕 Agent 能力做出真正可靠的应用。基准分数只是起点，终端操作和高工具调用分数是否能在生产环境里兑现，才是决定这版模型口碑的关键。
