DeepSeek 模型名对照：deepseek-chat 停用后该用哪个

有一类问题特别折磨人：代码一个字没动，某天开始不对了。另一类更隐蔽：你照着一篇写得很好的教程抄，抄完能跑，但跑出来的东西跟教程里描述的不是一回事。DeepSeek 这一年的模型名变动，同时制造了这两类问题——网上大量教程、大量脚手架模板、大量公司内部的封装层里，model 字段写的还是 deepseek-chat 或者 deepseek-reasoner。

这篇就把三件事说清楚：这两个名字的官方处置口径到底是什么、现在该换成什么、以及换完之后行为会不会跟着变（会，而且是安静地变）。想先把 DeepSeek 接入的整体轮廓补齐的，可以配合 DeepSeek API 接入总览 一起看。

一、先对齐官方时间线，别凭印象判断

关于这两个名字，官方更新日志里前后有两条关键记录。

第一条是 2026-04-24 的 V4 发布条目，原文写的是：

DeepSeek API 已支持 V4-Pro 与 V4-Flash，支持 OpenAI ChatCompletions 接口与 Anthropic 接口。访问新模型时，base_url 不变，model 参数需要改为 deepseek-v4-pro 或 deepseek-v4-flash。旧有的 API 接口的两个模型名 deepseek-chat 与 deepseek-reasoner 将于三个月后（2026-07-24）停止使用。当前阶段内，这两个模型名分别指向 deepseek-v4-flash 的非思考模式与思考模式。

这段话里有两个信息量很大的点。一是官方给了明确的停用日期，2026-07-24，这个日子现在已经过去了。二是它顺手解释了历史上这两个名字的性质：它们从来不是两个不同的模型，而是同一个模型的两种模式的两个入口。这一点是后面所有坑的根源，先记住。

第二条是 V4.1 Flash 上线时的 API 变更说明，原文是：

DeepSeek V4.1 Flash 已同步上线 DeepSeek API，原生支持多模态，将模型名称更改为 deepseek-flash 即可调用最新的 V4.1 Flash 模型。旧版本模型 V4 Flash 与 V4 Flash Vision Exp 现已下线，出于兼容考虑，模型名 deepseek-v4-flash、deepseek-v4-flash-vision-exp 将被暂时路由到 V4.1 Flash。

于是名字这条线就串起来了：deepseek-chat / deepseek-reasoner 曾指向 deepseek-v4-flash，而 deepseek-v4-flash 自己后来也被换掉了，现在的名字是 deepseek-flash。

这里要说一句诚实话，免得你把本文当成排障结论去用。我没有实测「现在调 deepseek-chat 会返回什么」，所以不会告诉你它一定报某个具体错误码。能确定的只有两件事：官方已经公告停用，且官方文档里列出的「仍可调用的旧名」清单只有 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 这两个，那两个老名字不在清单里。对生产代码来说这个判断已经够用了——一个被公告停用、又不在兼容清单里的标识符，不该出现在你的依赖链上，不管它今天还能不能返回 200。

顺带说一句，deepseek-v4-flash 这两个名字虽然还能调，但官方用的词是「暂时路由」。「暂时」是个有保质期的词，不要把它当长期承诺写进配置。

二、名字的对应关系：一张表说完

当前的端点与模型名，照官方快速开始页的口径：

项	值
base_url（OpenAI 格式）	https://api.deepseek.com
base_url（Anthropic 格式）	https://api.deepseek.com/anthropic
当前模型名	deepseek-flash、deepseek-v4-pro
暂时兼容路由的旧名	deepseek-v4-flash、deepseek-v4-flash-vision-exp，由 V4.1 Flash 提供服务，按 Flash 价格计费

注意 base_url 从头到尾没变过。这就是为什么这次迁移特别容易被低估——网关地址不动、鉴权方式不动、SDK 不用换，看起来就只是改一个字符串。如果你的接入层还在纠结 base_url 该怎么摆、Anthropic 格式那个后缀要不要带，base_url 怎么配 那篇讲得更细。

而模型名的对应关系是这样：

旧写法	正确的新写法	坑在哪
model: "deepseek-chat"	model: "deepseek-flash"，并且显式关闭思考模式	思考模式默认是打开的，而 deepseek-chat 原本对应非思考模式
model: "deepseek-reasoner"	model: "deepseek-flash"	思考模式默认已开，语义正好对得上，改名即可

看出不对称了吗。从 deepseek-reasoner 迁过来是一行字符串替换的事；从 deepseek-chat 迁过来不是。这是整次迁移唯一真正值得你停下来读两遍的地方。

三、为什么 deepseek-chat 不能裸改名

把话说透：「思考」现在是一个模式，由参数控制，不再是一个模型名字。

官方文档给的默认值是：思考模式默认打开，且 effort 默认为 high。而 deepseek-chat 这个名字过去代表的恰恰是非思考模式。所以如果你只做字符串替换，把 deepseek-chat 换成 deepseek-flash 就上线，实际发生的事是——你在没有任何提示的情况下，给全部流量打开了思考模式，还是最高强度那一档。

后果不是「报错」，而是一连串安静的变化：响应里多出了思维链内容、输出 token 的量级变了、单次请求的耗时变了，下游那些按固定结构解析返回体的代码可能开始拿到意料之外的字段组合。测试环境跑几条 demo 大概率看不出问题，因为答案还是对的，甚至更好；真正暴露是在账单和延迟监控上。

正确的写法，OpenAI 格式下是靠 thinking 字段：

{
  "model": "deepseek-flash",
  "thinking": {"type": "disabled"}
}

{"thinking": {"type": "enabled/disabled"}} 是这个开关的全部取值。想调强度则用 {"reasoning_effort": "low/high/max"}。

Anthropic 格式下换了一套字段名：开关是 {"reasoning": {"effort": "none/low/high/max"}}，其中 none 就表示关闭思考模式；强度是 {"output_config": {"effort": "low/high/max"}}。两套格式的字段名不通用，这一点在做多供应商抽象层的时候特别容易写混，抄的时候看清楚自己走的是哪个 base_url。

还有一个 SDK 层面的坑值得单独拎出来：用 OpenAI SDK 的 Chat Completion 接口设 thinking 参数时，必须塞进 extra_body，因为它不是 OpenAI 官方 schema 里的字段。官方示例长这样：

response = client.chat.completions.create(
  model="deepseek-flash",
  reasoning_effort="high",
  extra_body={"thinking": {"type": "enabled"}}
)

如果你直接把 thinking=... 作为关键字参数传给 SDK，它大概不会按你想的方式到达服务端。这类「参数没生效但也没报错」的情况，是本次迁移里排查成本最高的一类。

effort 的取值还有一层映射，用户传入的值会被折叠到三档：minimal 和 low 都生效为 low，medium、high、xhigh 都生效为 high，max、ultra 生效为 max。也就是说你精心调的 medium 和别人随手写的 high 跑的是同一档，不必在这上面做细粒度调参的幻想。关于思考模式本身怎么用、思维链该不该给用户看，推理模型的使用方式 那篇有更完整的讨论。

四、思考模式打开后，有三个参数设了不报错也不生效

这是我认为最阴的一节，因为它违反了大多数人对 API 的直觉。

在思考模式下，temperature、presence_penalty、frequency_penalty 这三个参数不被支持。而官方对此的处置写得很明确：为了兼容已有软件，设置这些参数不会报错，但也不会生效。

请体会一下这个组合的杀伤力。你的封装层里可能有一行 temperature=0，是当年为了让输出稳定、让 JSON 能被可靠解析而加的，加完就再没人动过。迁移到思考模式之后，这行代码仍然存在、仍然被发送、服务端仍然返回 200，但它已经不起作用了。你不会收到任何信号，只会在某个时刻发现输出的稳定性不如从前，然后花很长时间怀疑是提示词写坏了。

top_p 的行为也变了：思考模式下它生效，但下限被抬到 0.95，小于 0.95 的传入值会被抬升；非思考模式下这个参数恒为 1.0，你传什么都会被忽略。所以「靠收紧 top_p 来压住发散」这条老路子，在这两种模式下都走不通。

返回结构上也有一条要改代码的地方：思维链通过 reasoning_content 字段返回，与 content 同级——不是嵌在 content 里面。旧的解析逻辑如果只认 content，不会崩，只是会把思维链整段丢掉；反过来，如果你把 reasoning_content 直接当正文渲染给用户看，那又是另一种事故。

多轮对话的拼接规则还多一个条件分支，判据是这一轮请求里带不带 tools：

• 带 tools：历史轮的 reasoning_content 必须回传，并且会被拼进上下文。
• 不带 tools：无需回传，传了也会被忽略。

做 Agent 的人会天天撞上第一条，因为 Agent 的请求基本都带 tools。如果你的会话历史管理是「只存 content」的，函数调用链路上就会丢掉模型自己的推理痕迹，表现出来往往是多轮之后的工具选择开始变笨。

五、flash 还是 v4-pro：按什么维度选

当前两个模型名对应两条不同的路，选哪条不看「谁更强」，看你的场景卡在哪个硬约束上。

先说唯一一条硬性的能力分界：deepseek-flash 支持图像理解，deepseek-v4-pro 不支持。 如果你的输入里有截图、有票据照片、有图表，这一条直接就把选择做完了，没什么可权衡的。

其余常用功能两边都支持：Json Output、Tool Calls、Responses API、Anthropic API、对话前缀续写（Beta）。也就是说结构化输出和函数调用这两块不构成选型依据，不用为它们纠结。

还有一条容易被漏掉的约束：FIM 补全（Beta）两个模型都只在非思考模式下支持。做代码补全类产品的要特别小心这条和第三节的默认值撞在一起——思考模式默认打开，而 FIM 只在非思考模式下可用，这意味着你必须显式关掉思考模式，否则这条路根本不通。这又是一个「默认值不是你要的默认值」的例子。

六、计价结构：不看金额也能看出该怎么改

具体单价这里一个数字都不写，一是它会变，二是官方自己在价格页上写着「产品价格可能发生变动，DeepSeek 保留修改价格的权利」。但计价的结构是相对稳定的，而结构才是影响你怎么写代码的东西：

• 按输入与输出的总 token 计量。
• 输入 token 区分缓存命中与缓存未命中两个价位。这解释了为什么要把系统提示词、少样本示例这类长而不变的内容放在请求的最前面并保持稳定——前缀一动，缓存就废了。
• 分空闲时段与高峰时段两档，空闲价是高峰价的一半。高峰时段是北京时间周一至周五 9:00-12:00、14:00-18:00，其余时间都算空闲。批量清洗、离线评测这类不赶时间的任务，排到窗口外跑是纯赚。
• 扣费从充值余额或赠送余额扣减，两者同时存在时优先扣减赠送余额。

把第三节和这一节连起来看，就明白「裸改名」为什么是个成本事件而不只是个技术事件：思考模式默认打开会增加输出 token，而输出 token 恰好是计价里最贵的那一档。

七、这次迁移的动手清单

• 全库搜 deepseek-chat 和 deepseek-reasoner，别只搜业务代码——配置文件、环境变量默认值、单元测试的 fixture、文档和 README 里的示例、运维脚本里都可能有。
• 每一处 deepseek-chat 都要问一句：这里需不需要非思考行为？需要就补上关闭思考模式的参数，不需要就顺手确认一下打开思考不会撑爆下游的解析和预算。
• 检查有没有 temperature / presence_penalty / frequency_penalty 之类的老参数在思考模式下已经变成装饰品，以及 top_p 是不是还写着小于 0.95 的值。
• 检查返回体的解析是否认识 reasoning_content，以及带 tools 的链路是否把它存进了会话历史。
• 顺手把 key 的来源也理一遍。模型名换了不代表凭证管理就没问题，这两件事经常是同一层封装里的同一批硬编码。

还有一件事：把 model 收成配置，不要散落在代码里。这次能一天改完的团队和改了一周的团队，差别不在技术水平，而在于模型名到底是一个常量还是二十处字面量。OpenAI 兼容格式本身就给了这种收口的便利，OpenAI 兼容接口怎么用 那篇讲的就是这层抽象。

最后说几句不太好听的

第一，这篇文章会过期。模型名这种东西过去一年多改了好几轮，没有任何理由相信它会停下来；写死日期、写死名字的文章，包括本文，都只能算某个时间点的快照。真要动手改生产代码之前，请以官方模型与价格页为准核一遍当前名字，别拿任何二手文章当依据——包括这一篇。

第二，如果你正在看的是更早的那批教程，比如按 R1 的思路写的那些（DeepSeek-R1 那篇 也在这个行列里），里面的模型名要一律当历史看待。那些文章讲的原理、讲的思维链怎么读、讲的适用场景，基本都还成立；不成立的只是 model 字段里的那个字符串。区分「概念过期」和「标识符过期」，能省掉你大量的无效返工。

第三，把这次当成一个提醒：凡是供应商能单方面改的标识符——模型名、端点路径、默认参数值——都应该被当成外部依赖来管，而不是当成代码里的常识。默认值的变化比接口的变化更危险，因为前者不报错。