DeepSeek 旧模型名失效后怎么迁移：deepseek-chat / deepseek-reasoner 切到 V4

正文

如果你的 Agent、脚本或网关还在发送 deepseek-chat 或 deepseek-reasoner，先核对供应商当前支持的模型名。DeepSeek 此前公告旧模型名于 2026 年 7 月 24 日退役；迁移时还要注意，同一个可用别名背后的实际模型也可能发生变化。

截至 2026 年 11 月 2 日，DeepSeek API 文档推荐使用 deepseek-flash，说明该名称由 DeepSeek-V4.1-Flash-1017 提供服务。旧名称 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 仍被接受，但对应旧模型已退役，请求同样路由到 1017。API 请求中的名称与实际后端版本不是一回事。

先确认模型名与实际路由

官方文档提供了当前映射，但不能仅凭别名证明以后不会再变化，也不能假定响应字段一定披露底层快照。对于 deepseek-v4-pro，以最新官方文档和实际账户可用性为准，避免把历史公告中的临时路由当作永久规则。

先搜索所有写死的旧模型名

从仓库、部署脚本和密钥管理的非敏感配置开始。不要只改一个 .env 文件，CI、任务队列和第三方 Agent 的模型配置经常在不同位置。

rg -n "deepseek-chat|deepseek-reasoner" . --glob "!node_modules/**" --glob "!.git/**"

重点检查这些入口：

• OPENAI_MODEL、MODEL、DEEPSEEK_MODEL 等环境变量。
• OpenAI SDK 的 model 参数和 Anthropic-compatible 网关的模型映射。
• CI、定时任务、Worker、批处理脚本和 Agent 框架配置。
• 提示词模板、团队文档和运行手册中的示例模型名。

搜索结果为空时，也要检查平台控制台、Kubernetes Secret、云函数环境变量和代码外的网关路由规则。它们通常不在 Git 仓库中。

OpenAI ChatCompletions 只替换 model 参数

DeepSeek 官方说明中，V4 迁移保持原有 base_url，调用 OpenAI ChatCompletions 时将 model 改为当前支持的名称。先用无敏感上下文的小请求验证 Flash：

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-flash",
    "messages": [{"role": "user", "content": "只回复 OK"}]
  }'

响应应成功返回；记录请求模型名及响应中实际提供的模型字段。若字段只返回别名，不能据此独立证明底层快照。不要把真实 API Key 粘贴到终端录屏、CI 输出或提交到仓库。

需要 Pro 时，只替换模型名：

{
  "model": "deepseek-v4-pro",
  "messages": [{"role": "user", "content": "分析这个任务的失败原因"}]
}

Anthropic-compatible Agent 先更新模型映射

Claude Code、代理网关或其它 Anthropic Messages 客户端仍可以使用 DeepSeek 的 Anthropic 接口，但模型名必须由旧名换为 V4。入口、Key 与模型名必须来自同一家服务：不要把 DeepSeek 的模型名填进另一个网关，或用旧的模型映射覆盖环境变量。

PowerShell 中先在当前会话完成最小替换：

$env:ANTHROPIC_MODEL="deepseek-flash"

长期配置、项目 settings 或网关管理页中也要将旧名一并替换。变更后新开一个会话，让 Agent 完成一次只读任务，例如列出仓库根目录的主要模块；这样能验证客户端实际读取的是新配置，而不是旧终端进程中的缓存值。

Thinking 行为必须单独回归

旧模型名把“是否 Thinking”隐含在名称里。迁移 V4 后，模型选择与 Thinking 选择需要分开验证。先用一个固定的小任务分别测试非 Thinking 与 Thinking 配置，记录：

deepseek_v4_migration_check:
  model: "deepseek-flash"
  client: "agent-gateway"
  thinking_mode: "configured value"
  task: "解释一段固定错误日志，不调用工具"
  result: "success or failure"
  response_model: "recorded model name"
  latency_ms: "observed value"

不要把推理内容、完整生产日志或用户数据作为回归样本。选择一个没有密钥、客户信息和私有代码的确定性任务，才能比较迁移前后的延迟、输出格式和工具调用次数。

迁移后如何确认没有旧请求

一次成功迁移至少要同时满足：

• 仓库、部署配置和网关映射不再引用旧模型名。
• OpenAI 和 Anthropic-compatible 两类实际调用都返回成功。
• 日志或追踪能确认客户端请求的模型名；若响应未披露底层快照，结合供应商文档核验，不把别名当成快照证明。
• Thinking 配置已在一个固定任务上单独验证，不再通过旧模型名间接控制。
• 关键 Agent 有明确 fallback，并且 fallback 同样使用已验证的新模型名。

模型别名不变时，也要做后端更新回归

同一个别名仍能返回成功，不代表生成结果、工具调用或延迟完全不变。用无敏感数据的固定任务集记录请求时间、客户端版本、提供商、请求模型名和响应可见的模型字段。对比更新前后的结构化输出、工具参数、失败率、延迟和实际计费；条件允许时重复运行，不把单次波动当成稳定结论。

先在测试环境运行；如果回归失败，暂停扩大流量并切换到已验证的备用供应商或模型。不能假定 DeepSeek 支持固定旧快照或自行回滚，是否可用需要向供应商确认。

model not found、输出变化和上下文异常怎么处理

model not found 或 404

先检查运行进程实际读取的模型变量，再检查网关是否允许 V4 模型。不要只修改本地 .env 后立刻判断服务故障：容器、CI 和远程 Worker 可能仍保留旧的 Secret 版本。

模型切换后输出格式变化

先缩小到一条无工具调用的小请求，比较 role、JSON 字段和流式事件。通过后再恢复工具调用、结构化输出和长上下文。这样能区分模型行为变化与客户端协议兼容问题。

长任务成本或延迟上升

1M context 是最大容量，不是每个 Agent 都应该持续保留的会话长度。限制读取目录、裁剪工具输出、在阶段结束时写摘要，并为高风险任务准备一个已验证的模型 fallback。长任务的上下文治理比单纯改模型名更能决定迁移后的稳定性。

结论

DeepSeek V4 迁移可以从“保持入口不变、替换 model 参数”开始，但不能止步于一次字符串替换。把旧名清理干净，分别验证模型路由和 Thinking 行为，再用真实但不敏感的 Agent 任务完成回归，旧模型名退役就不会演变成线上运行时事故。

参考来源

相关文章