DeepSeek V4 API 迁移实战：从 deepseek-chat / reasoner 切到 v4-pro / v4-flash

DeepSeek V4 的发布，不只是多了两个新模型名。

从实战派视角看，它真正影响的是三件事：

1. 旧的 deepseek-chat 和 deepseek-reasoner 有明确退役时间。
2. 新模型拆成 deepseek-v4-pro 和 deepseek-v4-flash，需要重新做任务路由。
3. 1M context 和 Thinking / Non-Thinking 让调用策略变复杂，不能只按“便宜模型”和“强模型”粗暴区分。

官方入口建议先固定两页：

• DeepSeek V4 Preview 公告
• DeepSeek API updates

这篇文章只回答一个问题：现有项目已经用了 DeepSeek API，应该怎样稳妥迁移到 DeepSeek V4？

先给结论：不要从业务代码里直接替换

很多迁移会从搜索替换开始：

deepseek-chat -> deepseek-v4-flash
deepseek-reasoner -> deepseek-v4-pro

这能跑，但不稳。

更合适的顺序是：

1. 先盘点所有 DeepSeek 调用点。
2. 把模型名集中到一个配置层或模型路由函数。
3. 给任务打标签：快问快答、代码生成、长文档、复杂推理、Agent 步骤。
4. 按任务选择 deepseek-v4-flash 或 deepseek-v4-pro。
5. 小流量灰度，记录失败率、延迟、输出质量和成本。
6. 确认无误后，再移除旧模型配置。

迁移不是“换模型名”，而是“把模型选择从硬编码变成可观察、可回滚的路由”。

第一步：先找出所有旧模型调用

先在项目里搜索：

rg "deepseek-chat|deepseek-reasoner|DeepSeek|model:" .

重点看这些位置：

位置	为什么要查
后端 API 服务	主调用路径通常在这里
Agent runtime 配置	Agent 可能把模型名写在 workflow 或 profile 里
测试脚本	很多 smoke test 会硬编码旧模型
cron / worker	低频任务最容易漏
内部工具页面	页面下拉框、默认值、示例 JSON 可能还写着旧模型
文档和 README	用户照着文档复制，也会继续调用旧模型

如果项目已经上线，不要只看主应用。 真正容易出事故的，往往是那些一个月才跑几次的后台任务。

第二步：把模型选择收敛成一个路由

一个实用的迁移配置可以先长这样：

type DeepSeekTask =
  | "quick_answer"
  | "coding"
  | "long_context"
  | "complex_reasoning"
  | "agent_step";

export function chooseDeepSeekModel(task: DeepSeekTask) {
  if (task === "complex_reasoning" || task === "long_context") {
    return "deepseek-v4-pro";
  }

  return "deepseek-v4-flash";
}

这段代码不是最终答案，但它比到处散落模型名要好得多。

原因很简单：

• 想灰度时，只改路由。
• 想回滚时，只改路由。
• 想把某类任务从 Flash 切到 Pro，只改路由。
• 想统计成本时，可以按任务标签聚合。

实战派文章经常强调“先分层再优化”，DeepSeek V4 迁移也是一样。

第三步：给旧模型做一张替换表

可以先用这张表作为迁移起点：

旧调用	推荐新入口	适合场景
deepseek-chat	deepseek-v4-flash	高频问答、摘要、轻量分类、普通客服
deepseek-chat	deepseek-v4-pro	高价值输出、复杂代码、需要更稳质量的任务
deepseek-reasoner	deepseek-v4-pro	复杂推理、多步骤规划、长上下文分析
未区分模型的统一调用	路由到 Flash / Pro	根据任务标签动态选择

不要把这张表理解成绝对规则。

更稳的策略是：先用 Flash 承接大多数低风险任务，用 Pro 承接高风险和高复杂任务。

如果你的系统已经有任务分级，比如 low_cost、standard、critical，可以直接接到模型路由上。

第四步：确认 Thinking / Non-Thinking 行为

DeepSeek V4 Preview 公告里明确提到新模型支持 Thinking / Non-Thinking。

迁移时要做两类测试：

1. 非推理输出是否变啰嗦

例如：

把这段客服对话压缩成 3 条待办。

验收点不是“能不能回答”，而是：

• 是否保持短输出
• 是否没有过度解释
• 是否没有把内部判断过程暴露给用户
• 是否稳定遵守格式

2. 推理任务是否真的更稳

例如：

根据这 12 条错误日志，判断最可能的根因，并给出最小复现步骤。

验收点是：

• 是否能区分证据和猜测
• 是否能给出排查顺序
• 是否能指出还缺哪些信息
• 是否不会为了显得完整而编造结论

Thinking 能力不是为了让回答更长，而是为了让复杂任务更可靠。

第五步：1M context 不等于可以乱塞

DeepSeek V4 的 1M context 很有吸引力，但迁移时不要立刻把所有历史记录、代码库和文档都塞进去。

建议先按三档处理：

上下文长度	推荐用途	风险
短上下文	普通问答、分类、改写	风险最低
中上下文	单文件代码、单篇文档、一次客服会话	需要检查引用准确性
长上下文	多文档、代码库切片、知识库检索结果	容易上下文污染、延迟上升、成本上升

长上下文最该服务的是“少复制、多定位”。

也就是说，你应该让模型看到足够证据，而不是把整个系统都扔进去。

更完整的长上下文用法，可以继续看：

• DeepSeek V4 的 1M context 怎么真正用起来

第六步：灰度迁移时看这 5 个指标

迁移验收不要只看 HTTP 200。

至少看：

指标	看什么
成功率	请求是否稳定完成
延迟	P50 / P95 是否影响产品体验
输出质量	是否更准确、更稳定、更少跑题
成本	Flash 和 Pro 的比例是否合理
回滚能力	某类任务能否快速切回旧配置或备用模型

如果你在做 Agent workflow，还要额外看：

• 工具调用参数是否稳定
• 多轮步骤是否会漂移
• 长上下文下是否引用错误文件
• 失败时是否能给出可操作错误

一个可直接套用的迁移清单

## DeepSeek V4 迁移检查

### 调用盘点
- [ ] 搜索 deepseek-chat
- [ ] 搜索 deepseek-reasoner
- [ ] 搜索配置文件里的默认 model
- [ ] 搜索测试脚本和 cron
- [ ] 搜索文档、README、示例 JSON

### 路由改造
- [ ] 模型名集中到配置层
- [ ] 任务类型接入模型路由
- [ ] deepseek-v4-flash 承接高频低风险任务
- [ ] deepseek-v4-pro 承接复杂推理和长上下文任务

### 灰度验证
- [ ] 小流量上线
- [ ] 记录成功率和延迟
- [ ] 对比输出质量
- [ ] 对比成本
- [ ] 验证回滚路径

### 截止时间
- [ ] 在 2026-07-24 15:59 UTC 前移除旧模型依赖

和 DeepSeek V4 Pro / Flash 选型的关系

迁移完成后，真正长期影响成本和质量的是模型路由。

如果你还没确定怎么区分 Pro 和 Flash，可以继续看：

• DeepSeek V4 Pro 和 Flash 怎么选：Agent、长文档、代码任务的实战路由

参考与延伸

• DeepSeek V4 Preview 官方公告
• DeepSeek API updates
• DeepSeek V4 Pro 和 Flash 怎么选
• DeepSeek V4 的 1M context 怎么真正用起来