先说最重要的一件事
如果你的代码还在调用 deepseek-chat 或 deepseek-reasoner，截止日期是 2026年7月24日。过了这个日期，这两个 model string 直接失效。迁移本身不复杂，大多数情况下改一行代码就够了。真正的风险不是技术难度，是拖到生产环境出问题才想起来。
什么在被弃用
两个旧 model string 将停止服务：
deepseek-chat→ 目前临时映射到deepseek-v4-flash非思考模式deepseek-reasoner→ 目前临时映射到deepseek-v4-flash思考模式
现在调用旧 model string 还能通，但 DeepSeek 随时可能在截止前调整路由逻辑。2026年7月24日之后，调用直接报错，没有降级，没有提示。
迁移目标：两个新 model string
| 旧 model string | 迁移到 | 适用场景 |
|---|---|---|
deepseek-chat |
deepseek-v4-flash |
日常任务、高频调用、成本敏感 |
deepseek-reasoner |
deepseek-v4-flash 或 deepseek-v4-pro |
看任务复杂度决定 |
唯一需要判断的是：之前用 deepseek-reasoner 做复杂推理的，Flash 思考模式够不够用，还是要升到 Pro。其他情况，直接换 Flash。
两种接入格式
DeepSeek V4 支持两套 API 格式：
OpenAI 兼容格式（大多数人用这个）
Base URL：https://api.deepseek.com
Anthropic 兼容格式
Base URL：https://api.deepseek.com/anthropic
格式选错会直接报错，不会静默失败。先确认你的 SDK 类型再选。
迁移操作清单
按顺序执行，不要跳步骤。
第一步：找出所有调用点
grep -r "deepseek-chat" .
grep -r "deepseek-reasoner" .
环境变量、配置文件、代码里 hardcode 的——全部找出来。漏掉一处就是潜在的生产事故。
第二步：替换 model string
# 之前
model="deepseek-chat"
# 之后
model="deepseek-v4-flash"
# 之前
model="deepseek-reasoner"
# 之后（轻量或中等复杂度任务）
model="deepseek-v4-flash"
# 之后（复杂推理 / Agent 任务）
model="deepseek-v4-pro"
第三步：确认 Base URL
# OpenAI 兼容
from openai import OpenAI
client = OpenAI(
api_key="你的 API key",
base_url="https://api.deepseek.com"
)
# Anthropic 兼容
from anthropic import Anthropic
client = Anthropic(
api_key="你的 API key",
base_url="https://api.deepseek.com/anthropic"
)
第四步：处理思考模式
V4 的思考模式不再通过 model string 区分，改为参数控制：
# 开启思考模式
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{"role": "user", "content": "你的 prompt"}],
extra_body={"thinking": {"type": "enabled"}}
)
# 关闭思考模式
extra_body={"thinking": {"type": "disabled"}}
之前用 deepseek-reasoner 的注意：不加这个参数，思考模式默认是关闭的。
第五步：在测试环境跑真实任务
不要用 hello world 测。拿你生产环境里最重要的10个 prompt 跑一遍，重点检查 JSON 输出格式和工具调用的响应结构——这两个地方最容易出差异。
第六步：灰度切换，观察两周
不要一次性全量切换。保留旧版本的 fallback，给自己两周观察期再全量。
最常见的四个误区
误区一：现在还能用，等快到期再改。 旧 model string 现在还通，但"能调用"不等于"行为稳定"。DeepSeek 可能在截止前就悄悄改变路由逻辑。越早迁移，越早在真实流量下暴露问题。
误区二：只换了 model string，没测输出格式。 V4 的 JSON 输出和工具调用响应结构与旧版有差异。如果你的下游代码在解析模型输出，这是最容易出问题的地方。
误区三：deepseek-reasoner 直接换成 deepseek-v4-pro。 官方临时映射是换到 Flash 的思考模式，不是 Pro。Pro 成本高12倍，适合任务复杂度确实需要的场景。先测 Flash 思考模式，不够再升。
误区四：没开思考模式参数，以为行为和 deepseek-reasoner 一样。 V4 默认关闭思考模式。从 deepseek-reasoner 迁移过来没有显式开启的话，推理行为会直接变掉。
迁移后的成本结构
V4 引入了缓存命中定价，这是旧版没有的：
| 计费项 | V4 Flash | V4 Pro |
|---|---|---|
| 输入（缓存命中） | ¥0.2 / 百万 tokens | ¥1 / 百万 tokens |
| 输入（缓存未命中） | ¥1 / 百万 tokens | ¥12 / 百万 tokens |
| 输出 | ¥2 / 百万 tokens | ¥24 / 百万 tokens |
如果你的 pipeline 有大量重复的系统提示或共享上下文，缓存命中率会显著压低实际成本。高频调用场景下，迁移后的实际费用可能比旧版更低。
哪类场景最容易出问题
工具调用密集的 pipeline —— 响应结构变化在这里影响最大，测试优先级最高。
严格依赖输出格式的下游处理 —— 在解析 JSON、提取字段、做格式匹配的地方，V4 和旧版输出可能有细微差异。
从 deepseek-reasoner 迁移的调用方 —— 思考模式变成参数控制，漏加参数就等于关掉了推理能力。
长对话历史场景 —— 确认你的 token 计数逻辑在新模型下还准确。
常见问题
7月24日之后不迁移会怎样？ API 调用直接失败返回错误，服务中断，没有降级处理。
需要重新申请 API key 吗？ 不需要。key 不变，只换 model string。
Flash 和 Pro 用同一个 key 吗？ 同一个账户下同一个 key，通过 model string 区分版本。
开启思考模式会影响成本吗？ 会。思考模式增加推理步骤，token 消耗更多，延迟更高。不需要深度推理的任务关掉。
Anthropic 兼容格式适合谁用？ 已经在用 Anthropic SDK 的团队，可以最小改动接入 DeepSeek。从头开始的话，OpenAI 兼容格式文档更多、社区资源更丰富。
最终建议
今天先做一件事：在项目里搜 deepseek-chat 和 deepseek-reasoner，数一下有几处。不需要改任何代码，但这个数字告诉你迁移工作量有多大。大多数项目不超过5处，一个下午能搞定。
等到7月才动，是在赌 V4 的输出格式变化不会影响你的生产环境。这个赌注不值得押。
相关阅读：DeepSeek V4 Preview 全解析：Pro vs Flash、1M 上下文、API 迁移，到底变了什么