DeepSeek V4.1-Flash-1017 静默升级：开发者必须知道的三个陷阱

DeepSeek^广告 在 10 月 17 日把 deepseek-flash 背后的模型换成了 DeepSeek-V4.1-Flash-1017。官网、App、API 同时切换，名字没变，没有 opt-in 选项。权重已上传 Hugging Face，采用 MIT 许可（模型卡标注 763B 参数）。API 侧提供 1M 上下文、最高 384K 输出，支持视觉、工具调用、JSON，兼容 OpenAI 与 Anthropic 两种格式的端点。

官方基准表显示 DeepSWE v1.1 从 74.2 提升到 77.0（Mini-SWE-V2 环境），Terminal-Bench 4.0 从 31.2 提升到 42.3（Claude Code 环境），并声称输出更短、任务更快。但这次升级真正的风险不在榜单上，而在于那些已经在调用 deepseek-flash 的存量代码——它们的行为会在你毫无感知的情况下发生变化。

一、没人问你，升级就已经完成

V2EX 上有人问：名字一样，怎么判断自己是不是已经切到 1017，还是处于灰度阶段？回帖的说法是官方已正式发布，Flash 只有一个版本。文档也印证了这一点：deepseek-flash 现在由 V4.1-Flash-1017 提供服务。旧名称 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 仍然可用，但已经退役，实际指向 1017 并按 Flash 价格计费。

这周该做的事很具体：重新跑一遍评测。提示词和金标准文件都是在 9 月版 Flash 上调出来的，现在面对的是另一个模型。如果「输出更短」属实，依赖长度的启发式规则就可能漂移。把遗留的模型字符串统一改成 deepseek-flash，让日志与实际情况一致。还要检查第三方路由——开发者老章指出部分渠道（他点名 OpenCode Go）在他撰写时尚未切换。别处的「DeepSeek Flash」不一定来自 api.deepseek.com。

模型别名（model alias） 是这次升级风险的根源。在 API 设计中，deepseek-flash 这样的字符串并不是某个具体权重文件的 ID，而是服务端维护的一个指针，指向「当前 Flash 档位」的最新版本。服务方可以在不改动客户端代码的前提下替换指针目标，客户端看到的模型名、端点、SDK 接口全部不变，但实际推理的模型已经换了。这与固定版本号（如 deepseek-v4.1-flash-1017）形成对比：后者锁定权重，行为可复现，但需要用户主动迁移。别名带来的是「永远最新」的便利，代价则是行为漂移——同一份提示词、同一组参数，输出分布可能在某个时刻悄然改变，而调用方毫无感知。工程上应对别名的常见做法是：在日志中记录响应体里的模型版本字段、对关键任务做固定 seed 无法保证的回归评测、并保留一条指向固定版本的旁路以便回滚。

二、首次调用没变，但三个设置被静默忽略

首次调用的代码和以前一样：用 OpenAI SDK，base_url 指向 https://api.deepseek.com，模型填 deepseek-flash。坑藏在 Thinking Mode 文档里，而且都不会报错。

思考模式默认开启，强度为 high。 实际只存在三档强度：minimal 映射到 low，medium 和 xhigh 都映射到 high，ultra 映射到 max。传 medium 并不会得到中等强度的推理。

temperature、presence_penalty、frequency_penalty 在思考模式下完全无效。 不报错，不警告。旧评测配置里写着 temperature: 0，看起来是确定性的，实际上不是。

top_p 在 Flash 上被夹紧。 思考模式下低于 0.95 的值一律按 0.95 处理；非思考模式下固定为 1.0。

还有一个更容易踩的坑：使用 tools 时，必须把历史中每一轮 assistant 的 reasoning_content 原样回传，包括那些没有发起工具调用的轮次。漏掉任何一个都会得到 HTTP 400。不用 tools 时这个字段会被忽略，所以本地测试可能一切正常，上线开工具就崩。

作者的离线预检脚本 lint_request.py 把这些规则编码成了静态检查，输出很直观：旧评测配置会收到三条警告（模型名退役、temperature 被忽略、top_p 被夹紧），medium 会被提示映射到 high，丢掉 CoT 的 agent 循环直接报错「带 tools 会返回 HTTP 400」。如果需要一个确定性的分类器，用 {"thinking": {"type": "disabled"}} 关闭思考模式，并且不要依赖 top_p。修复 400 最简单的办法是照 DeepSeek 官方示例，把 response.choices[0].message 原样追加回消息列表。

思考模式（Thinking Mode） 指模型在给出最终回答前先生成一段内部推理链（Chain of Thought，CoT），这段内容通常通过 reasoning_content 字段返回，与最终的 content 分开。它与普通生成的关键区别在于采样逻辑：推理阶段倾向于高温、长输出，以探索多条解题路径；最终答案阶段则更收敛。正因如此，OpenAI 兼容接口中的 temperature、presence_penalty、frequency_penalty 这类控制「最终文本采样分布」的参数，在推理阶段没有对应的作用点，服务方选择静默忽略而非报错。reasoning_effort（或本文的 thinking 配置）则是控制推理预算的旋钮，档位越少，语义越粗，medium 被并入 high 就是典型例子——用户以为调低了成本，实际没有。理解这一分层，才能明白为什么「参数写了但不生效」不是 bug，而是思考模式架构的必然结果。

三、高峰定价换算成北美时间后，反而对白天友好

Flash 在高峰时段每百万 token 的价格是：缓存命中 $0.006，缓存未命中 $0.30，输出 $1.20（Pro 版为 $0.044 / $1.32 / $3.96）。非高峰半价。高峰时段是 UTC 周一至周五 01:00–04:00 和 06:00–10:00，中国法定节假日全天按非高峰计费。

这些窗口是围绕北京工作时间设定的。换算到多伦多时间后结论有点反直觉：对东部时区的团队来说，整个工作日的 09:00–17:00 全部落在非高峰，40 个小时里 0 个小时在高峰期。高峰打到的是夜间批处理任务——工作日晚间 9 点后（11 月 1 日夏令时结束后是 8 点后）、周日晚间和凌晨。该挪的是 cron 任务，不是站会。

按一个示例 agent 轮次算（60K 输入其中 50K 来自缓存，4K 输出含推理内容），Flash 高峰每轮 $0.00810，非高峰 $0.00405；Pro 版分别是 $0.03124 和 $0.01562。但如果没有缓存命中，Flash 高峰每轮跳到 $0.02280，是正常高峰价的 2.8 倍，而高峰本身只让账单翻倍。缓存命中的影响比时段更大，把系统提示和工具 schema 按字节稳定地放在提示词最前面，比掐着点跑任务更划算。

提示词缓存（prompt caching） 是理解这节成本数字的前提。服务端会把请求前缀（通常是系统提示、工具 schema、长文档等固定内容）的 KV 缓存保留一段时间，后续请求若前缀逐字节相同，就直接复用，按「缓存命中」的低价计费。本文示例中 60K 输入里有 50K 命中缓存，输入成本因此从 $0.30/百万降到 $0.006/百万，差距达 50 倍。缓存命中要求前缀完全一致，任何在前面插入的时间戳、随机 ID、动态排序的字段都会导致整段失效。所以「把系统提示和工具 schema 按字节稳定地放在最前面」不是优化技巧，而是缓存能否生效的硬性条件。这也解释了为什么缓存未命中会把单轮成本推到高峰价的 2.8 倍——它同时失去了低价档位和时段折扣。

四、Search 与 Fetch 免费到 11 月 1 日中午，之后工具费可能超过模型费

同一次发布还开放了 DeepSeek 的 Search（POST /v1/tools/search）和 Fetch（POST /v1/tools/fetch）API，各按 每 1000 次成功请求 $0.75 计费。计费规则：只有返回 HTTP 200 且结果非空才收费，失败和超时免费，count 参数（1–50）不影响价格。限额为每账户 Search 100 QPS、Fetch 25 QPS。

关键细节在于：如果你通过 DeepSeek Harness、Claude Code 或 Codex 使用 DeepSeek API，服务端的工具调用已经在打这些接口，而它们只在北京时间 11 月 1 日 00:00 之前免费，换算成多伦多时间是 10 月 31 日中午 12 点（EDT）。

按任务做的对比才是真正的意外。一个用 3 次 search 加 5 次 fetch 的任务，工具费 $0.00600，而一轮非高峰 Flash 调用只要 $0.00405——工具费是模型轮次的 1.5 倍。10 次 search 加 20 次 fetch 的任务，工具费 $0.02250，达到模型轮次的 5.6 倍。token 便宜到这个程度，研究型 agent 的网页调用可以比模型本身更贵。11 月 1 日之前，按任务记录 Search/Fetch 的消耗。既然价格与 count 无关，用一次大 count 的搜索（snippets 不够时加 need_content: true）替代多次窄搜索可能更省，不过作者并未验证这个节省是否成立。

Agent Harness（如 DeepSeek Harness、Claude Code、Codex）是包裹在模型外层的运行时，负责解析模型的工具调用意图、实际发起 HTTP 请求、把结果回填进对话。当你在这些 harness 里使用 DeepSeek API 时，模型发出的 search/fetch 工具调用由服务端或 harness 代为执行，走的就是本文提到的 /v1/tools/search、/v1/tools/fetch 接口。这意味着工具费并不显示在你的显式 API 调用里，而是叠加在 harness 的账单或服务端计量中，容易被忽略。计费口径「仅成功且非空的 HTTP 200 收费」意味着重试、抓取失败、空结果都不计费，但成功率高的研究型 agent 恰恰会大量产生成功调用。按任务而非按 token 核算成本，才能看清工具费与模型费的真实比例。

五、自托管需要注意的细节

模型卡明确说明没有 Jinja chat template。要用随附的 encoding.py 或 deepseek-recipe 的 Rust 绑定，参数上 temperature 取 1.0、top_p 取 1.0、max_tokens 至少 256K。

现实检验

社区实测提供了另一种视角。程序员天天困让 1017 构建了四个 3D 项目，全部能跑，但没有一个完全达到他的标准——他的规则是测试通过、审阅 diff、手动试用之后才合并。老章认可它在编程和 agent 场景的表现，但也报告了部分任务运行时间长、成本高于预期。需要说明的是，原文作者没有实际调用 API、没有测量输出长度与旧版 Flash 的差异、没有复现任何基准、没有验证响应是否报告 1017 版本号、没有评估 Search/Fetch 的质量，也没有运行权重。

为什么这件事值得关注

当一个模型名只是别名时，升级就是一次你没安排过的部署。把请求参数对着当前文档做静态检查，别名移动时重跑评测，并且把工具调用和 token 一起计入成本——这三点比榜单上的数字更能决定你的账单和线上稳定性。