deepseek-chat / deepseek-reasoner 7 月 24 日停用：改一行迁移到 V4 Flash / Pro
2026 年 7 月 24 日 15:59 UTC 起，DeepSeek 官方停用 deepseek-chat 和 deepseek-reasoner 两个模型名，旧请求会直接报错。本文讲清楚改哪一行、deepseek-reasoner 的 thinking 参数怎么加、V4 Flash 与 Pro 怎么选，以及用 ofox 统一网关把这类 model 名变更收敛到一处。
Ofox 
TL;DR — 2026 年 7 月 24 日 15:59 UTC 起，deepseek-chat 和 deepseek-reasoner 两个模型名彻底停用，旧请求会直接失败。修法只有一处：deepseek-chat → deepseek-v4-flash；deepseek-reasoner → deepseek-v4-flash 且加 thinking 参数。base_url、API key、请求格式都不动。这不是模型下线，是名字下线——底层 V4 Flash 引擎一直在。
30 秒速览
| 你在问 | 答案 |
|---|---|
| 什么时候断 | 2026-07-24 15:59 UTC（北京时间 7 月 24 日 23:59） |
| 谁受影响 | 请求里 model 还写 deepseek-chat 或 deepseek-reasoner 的所有集成 |
| 断了会怎样 | 请求直接报模型不存在（400/404），不是变慢，是彻底不通 |
| 怎么修 | 只改 model 字符串；reasoner 流量另加一个 thinking 参数 |
| 要改 base_url / key 吗 | 不用，全都不动 |
这条属于”改一行就好、但不改就整条链路断”的变更。趁没到点，把代码里、配置里、环境变量里所有硬编码的 deepseek-chat / deepseek-reasoner 搜一遍换掉。
到底停用了什么
deepseek-chat 和 deepseek-reasoner 是 DeepSeek 用了很久的两个模型名。V4 预览版在 2026 年 4 月 24 日上线后，这两个名字就已经变成别名了：
deepseek-chat→ 指向deepseek-v4-flash（非思考模式）deepseek-reasoner→ 指向deepseek-v4-flash（思考模式）
7 月 24 日 15:59 UTC 之后，这两个别名被撤掉。引擎没变——V4 Flash 还在跑，价格、能力都不动；变的只是你请求里那个 model 字符串。DeepSeek 官方把它定性为 namespace 变更：一次会打断所有还在引用旧名字的 SDK 配置、路由规则和成本模型的改名，仅此而已。
所以别慌，这不是又一次模型退役、要重新评估选型。它就是一次查找替换。
改哪一行：三类流量对照
按你现在用的模型名，对号入座：
| 旧 model 名 | 换成 | 额外动作 |
|---|---|---|
deepseek-chat | deepseek-v4-flash | 无，直接替换 |
deepseek-reasoner | deepseek-v4-flash | 请求体加 thinking: {"type": "enabled"} |
| 想要更强推理 | deepseek-v4-pro | 作为显式目标单独压测再切 |
最省事的情形是纯文本默认路由（原来用 deepseek-chat）：把 model 改成 deepseek-v4-flash 就结束了。
# 之前
resp = client.chat.completions.create(model="deepseek-chat", messages=msgs)
# 之后（base_url、api_key 都不变）
resp = client.chat.completions.create(model="deepseek-v4-flash", messages=msgs)deepseek-reasoner 用户：多加一个 thinking 参数
V4 把”思考 / 非思考”收进同一个 Flash 模型，用参数切，而不是选两个模型名。原来走 deepseek-reasoner 的推理流量，改成 deepseek-v4-flash + 显式开启 thinking：
resp = client.chat.completions.create(
model="deepseek-v4-flash",
messages=msgs,
extra_body={"thinking": {"type": "enabled"}},
)如果你的应用真正依赖重推理，官方建议把 deepseek-v4-pro 当成显式目标测一轮再决定——Pro 是更大的 MoE，不是 Flash 开个开关就等价。
V4 Flash vs V4 Pro：迁移目标怎么选
两个都是 V4 代，参数规模和价格差一档：
| V4 Flash | V4 Pro | |
|---|---|---|
| 参数（总 / 激活） | 284B / 13B | 1.6T / 49B |
| 官方定价 · 输入（每 1M） | $0.14 | $0.435 |
| 官方定价 · 输出（每 1M） | $0.28 | $0.87 |
| 命中缓存输入 | 再低一个量级 | 再低一个量级 |
| 适合 | 高并发、低延迟、日常生产 | 重推理、复杂 agent、质量优先 |
多数从 deepseek-chat 迁过来的流量留在 Flash 就好，价格和原来一致。只有原本吃 deepseek-reasoner、且对推理质量敏感的路径，才值得单独评估 Pro。
想看 V4 完整接入路径、缓存计费细节和跟 Claude Opus 4.x 的正面对比，见 DeepSeek V4 API 调用完整教程 和 Claude Opus 4.7 vs DeepSeek V4 Pro 旗舰对决；缓存能把输入成本压到最低，配置见 DeepSeek V3.2 Prompt Caching 设置。
用 ofox 统一网关把这类变更收敛到一处
DeepSeek 这种”改模型名”的动作不会是最后一次。上游每换一次命名，直连的项目就要在代码、CI、密钥配置里各改一遍。
ofox.ai 是 OpenAI 兼容的统一网关，deepseek-v4-pro 和 deepseek-v4-flash 都已上架。它的价值在这类迁移里很直接：你只维护一个 base_url、一个 key，多个上游模型走同一套请求格式；上游改名时，你改的还是同一处 model 字符串，不必在多个供应商 SDK、多套鉴权之间来回切。用 OpenAI SDK 的话，把 base_url 指到 ofox、model 写 deepseek-v4-flash 即可，境内可访问、协议不变。
from openai import OpenAI
client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="<你的 ofox key>")
resp = client.chat.completions.create(model="deepseek-v4-flash", messages=msgs)常见报错
请求返回 model not found / invalid model（400 或 404）：说明 model 还写着 deepseek-chat 或 deepseek-reasoner，且时间已过 7 月 24 日 15:59 UTC。改成 deepseek-v4-flash / deepseek-v4-pro 即恢复。这类跨厂商的模型名报错排查，可参考 Claude / OpenAI / Gemini / DeepSeek 专属 API 报错对照。
改完 reasoner 后拿不到思考过程：检查 thinking 参数有没有真正带进请求体（OpenAI SDK 走 extra_body），漏了就退化成非思考模式。
第三方框架里搜不到 model 名：除了业务代码，别忘了 LangChain / LlamaIndex 这类框架的配置、网关路由规则、以及 .env 里可能硬编码的默认模型。
到点前把这三处都扫一遍，比 7 月 24 日当天等着报警强。
