2026 DeepSeek V4：deepseek-chat 下线后怎么换才不涨账单？

截至 2026 年 7 月 24 日 15:59 UTC，deepseek-chat 和 deepseek-reasoner 已退出可用模型名；而 DeepSeek V4 的 thinking 开关默认是启用状态。对应的本周动作很明确：普通对话、摘要、分类和批处理先迁移到 deepseek-v4-flash，并显式关闭 thinking；复杂推理不要直接跳到 Pro，先用同一评测集比较 Flash thinking 与 Pro thinking。官方迁移说明可参考 DeepSeek V4 发布说明 与 模型和价格文档。

最后更新于 2026 年 7 月 31 日，模型状态、thinking 默认值、请求字段和价格数据核实自 DeepSeek 官方文档。

这篇文章适合仍在处理旧模型名迁移的应用开发者、平台工程师、AI Agent 团队和技术负责人。如果你只想把旧模型名替换掉，却没有核对最终请求和完整任务链，下面的分流规则可以帮你避免把模型升级、thinking 开启和网关覆盖混成一个问题。

迁移时间表与本周动作

先把兼容期映射和下线后的工程建议分开。官方在兼容期内将 deepseek-chat 指向 deepseek-v4-flash 的非思考模式，将 deepseek-reasoner 指向 deepseek-v4-flash 的思考模式；这不等于下线后所有旧推理任务都必须改成 deepseek-v4-pro。(官方模型与计费说明)

本表中的价格、并发和默认参数不能靠旧配置推断。当前官方资料显示，两个 V4 模型都支持 thinking 与非 thinking，thinking 默认启用；可用模型列表也应通过 官方模型列表接口 复核，而不是继续相信内部别名。

普通对话迁移

如果你的应用原来使用 deepseek-chat 处理普通问答，基准迁移应是：

{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "user",
      "content": "请用三句话总结这段内容。"
    }
  ],
  "extra_body": {
    "thinking": {
      "type": "disabled"
    }
  }
}

关键不在于把 model 改成 deepseek-v4-flash，而在于同时锁定 thinking 状态。官方 API Reference 将 thinking.type 定义为 enabled 或 disabled，且默认值为 enabled；如果 SDK 只发送模型名，服务端可能仍按思考模式处理请求。(官方 Chat Completions 参数说明)

你还要检查 3 个容易被忽略的限制：

• ✅ SDK 参数位置：OpenAI 兼容接口通常需要将 thinking 放入 extra_body，不能假设所有 SDK 都会把顶层参数原样传出。
• ⚠️ 代理覆盖：共享网关可能为所有 V4 请求注入 thinking.enabled，导致应用侧的关闭设置失效。
• ❌ 只查业务配置文件：配置文件写对，不代表最终 HTTP 请求写对。必须记录脱敏后的出站 JSON 和响应字段。

迁移验收至少看两处响应证据：响应中的 model 是否为 deepseek-v4-flash，以及 usage 是否包含本次实际输入、输出和缓存相关用量。若日志只保存业务层的“模型别名”，你无法证明请求已经离开旧路由，也无法解释成本变化来自模式、Token 还是重试。

批处理成本边界

摘要、分类、字段抽取和批量内容生成通常有一个共同特点：单次任务质量可以通过固定样本和结构化规则快速验收，不需要每个请求都启用思考模式。对这类任务，Flash 非思考模式应作为第一条低开销基线。

官方计费页按输入和输出 Token 计费，并区分缓存命中与缓存未命中。当前页面列出的 V4 价格为：deepseek-v4-flash 缓存命中输入每百万 Token 0.0028 美元、缓存未命中输入每百万 Token 0.14 美元、输出每百万 Token 0.28 美元；deepseek-v4-pro 对应为 0.003625 美元、0.435 美元和 0.87 美元。价格可能调整，发布前应重新核对 官方计费明细。

这几个数字对批处理团队的意义不是“Flash 永远便宜”，而是要拆开观察：

1. thinking 开启后，输出和推理相关内容可能改变实际用量；
2. 输入前缀是否稳定，会影响缓存命中；
3. 并发重试会重复消耗输入和输出 Token；
4. 一次批处理任务的总账单，不能只用成功响应数量估算。

场景案例很典型：一个分类服务把旧模型名替换成 deepseek-v4-flash，但共享网关继续注入 thinking。业务端看到的是“模型已切换”，账单却同时受到思考模式、输出变长和失败重试影响。此时最先做的不是换 Pro，而是抽取一批脱敏请求日志，对照 model、thinking 状态、usage、HTTP 状态码和重试次数。

升级到 thinking 前，建议设置质量退出条件：

• 结构化字段准确率或人工抽检结果低于既定阈值；
• 非思考模式在复杂输入上出现稳定的漏项；
• 增加 thinking 后，质量提升能够覆盖额外 Token 和延迟；
• 失败请求不是由提示词、Schema 或网关超时造成。

如果你正在搭建隔离测试环境，可以先阅读 VpsGona 的帮助文档，确认远程开发、日志查看和测试资源交付方式，再决定是否把回归任务放到独立环境中。

⚠️ 注意：不要把“缓存命中率提升”当成“thinking 成本已经解决”。缓存主要影响输入部分，思考模式、输出长度和 Agent 子请求仍需单独统计。

AI Agent 路由

AI Agent 的选择不能沿用“旧推理模型就一对一换 Pro”的做法。工具数量、失败代价和任务是否允许人工介入，才是 Flash 与 Pro 的实际分界。

对于简单工具调用，例如一次查询、一次字段补全或一次确定性 API 调用，可以先用 deepseek-v4-flash。如果工具选择正确、参数格式稳定，而且任务链经常只有一个模型回合，没有必要默认承担 Pro 的资源代价。

对于多步 Agent，要把一次用户任务拆成完整链路统计。thinking 模式下，模型可能先分析，再调用工具，接收工具结果后继续生成；这意味着一个表面上的“用户请求”可能包含多次模型子请求。官方工具调用指南明确要求，在发生工具调用的思考回合中，后续请求需要继续传回 reasoning_content，否则可能出现请求错误。(官方工具调用指南)

你可以用固定任务集同时记录：

• 最终任务是否完成；
• 工具调用是否正确；
• 模型请求次数和子请求次数；
• 每次响应的 usage；
• 从首个请求到最终答案的端到端延迟；
• 失败后的重试和回退次数。

Flash 与 Pro 的选择可以按下面的条件执行：

• ✅ 选 Flash：工具链短、失败可重试、输出格式固定、质量差距不明显；
• ⚠️ 先测 Flash thinking：任务需要多步规划，但失败代价仍可控；
• ✅ 选 Pro thinking：错误会触发高额业务损失，且评测集显示质量增益稳定；
• ❌ 不要直接选 Pro：只是因为旧服务名曾经承担推理任务，但没有新的质量证据。

官方资料还显示，V4 Flash 和 V4 Pro 都支持工具调用；因此“能不能调用工具”不是二者唯一的判断标准，真正需要比较的是任务完成质量和完整链路资源消耗。

高质量推理回归

代码推理、复杂分析和高风险决策任务可以保留 thinking，但需要把“模型升级”和“模式变化”拆成两个变量。建议至少保留两条对照线：

• deepseek-v4-flash + thinking enabled；
• deepseek-v4-pro + thinking enabled。

如果你直接从旧推理模型切到 Pro，同时改变模型、上下文组织、网关参数和重试策略，最终质量变化无法归因。官方兼容期映射是旧推理模型对应 V4 Flash thinking，但没有确认下线后所有相关任务必须统一迁移到 V4 Pro。

评测集至少应覆盖 4 类样本：

1. 需要多步推导但答案可自动校验的代码题；
2. 需要引用上下文、容易遗漏条件的复杂分析；
3. 可能触发工具调用的任务；
4. 错误代价较高、需要人工复核的决策样本。

每组不要只看最终答案。应同时记录质量得分、格式通过率、请求次数、输入输出 Token、缓存状态、端到端延迟和回退成功率。只有当 Pro 的质量增益在连续观测窗口内稳定，并且资源代价符合预算，才扩大流量。

平台网关治理

平台团队需要停止传播含义不清的内部别名，例如“默认聊天模型”“推理模型”或“V4 自动路由”。这些名字可以作为业务标签，但不能替代最终模型身份。

建议在网关日志中固定记录 5 个字段：

• model：最终发送的 deepseek-v4-flash 或 deepseek-v4-pro；
• thinking：enabled 或 disabled；
• business_tag：对话、批处理、Agent、推理等用途；
• fallback_model：失败后的实际回退目标；
• request_id：用于串起主请求、重试和工具子请求。

同时执行 5 步检查：

• [ ] 在 SDK 层打印脱敏后的最终请求字段；
• [ ] 在代理层确认没有覆盖 thinking.type；
• [ ] 用模型列表接口确认模型 ID 仍可用；
• [ ] 从响应读取 model 和 usage，不要只看配置中心；
• [ ] 为未完成改造的服务设置临时映射、负责人和移除日期。

并发也要纳入路由设计。官方当前列出的账户级并发限制为：V4 Flash 2500，V4 Pro 500；超过限制可能返回 HTTP 429。不要把 Pro 的容量限制直接套到 Flash，也不要通过增加 API Key 假设可以绕过账户级限制。(官方速率限制说明)

如果你需要评估独立测试资源，可通过 VpsGona 首页 了解可用方案；但长期稳定的高负载 API 任务，仍应优先评估自有资源、正式云环境和网络链路，而不是把短期测试环境当成生产承载方案。

迁移签字条件

技术负责人签字前，建议让每个团队提交一张最终映射表，至少包含任务类型、最终 model、thinking 状态、回退目标和观测证据。账单恢复不能只看总额，因为总额同时受到请求量、输入输出 Token、缓存命中、失败重试和 Agent 子请求影响。

扩大流量前，至少满足以下条件：

• [ ] 普通对话已证明使用 Flash 非思考模式；
• [ ] 批处理任务已核对缓存状态和重试记录；
• [ ] Agent 已统计完整任务链，而非只统计首个请求；
• [ ] Flash thinking 与 Pro thinking 已使用同一评测集比较；
• [ ] 所有服务都能从响应读取真实 model 和 usage；
• [ ] 发现异常时可以快速回退到已验证路线；
• [ ] 连续观测期间没有旧别名路由或 thinking 参数覆盖。

若账单异常仍然存在，按“最终模型 → thinking 状态 → 输出用量 → 缓存命中 → 重试次数 → 子请求数量”的顺序排查。不要先假设是模型价格变化，也不要把某个团队的账单翻倍幅度写成所有迁移的普遍结果；没有用户账单、脱敏日志或本站实测，就只能描述为待核验现象。

常见迁移问答

旧聊天模型下线后，普通请求该如何选新模型？

普通对话、摘要、分类、抽取和批量生成，默认改为 deepseek-v4-flash，并显式关闭 thinking。复杂推理任务不直接指定 Pro，而是先比较 Flash thinking 与 Pro thinking。最终是否生效，要以出站请求和响应中的模型字段为准。

普通对话应该从 Flash 起步，还是直接使用 Pro？

普通对话先用 Flash 非思考模式。只有固定样本显示指令遵循、格式稳定性或复杂上下文处理不足时，才测试 Flash thinking；如果仍不达标，再评估 Pro。这样可以避免一次迁移同时增加模型档位和思考开销。

deepseek-v4-flash 的 thinking 参数如何设置为关闭？

在 OpenAI 兼容请求中设置 extra_body：

{
  "thinking": {
    "type": "disabled"
  }
}

不要只在业务配置中写入该参数，还要检查 SDK 和网关是否实际传出。验收时查看响应中的 model、usage，并保存脱敏请求日志。

旧推理路由下线后，是否必须统一切换到 V4 Pro？

不必统一处理。官方兼容期映射是旧推理路由对应 V4 Flash thinking，而不是确认所有推理任务都必须使用 Pro。是否升级，应由同一评测集中的质量增益、请求次数、Token 用量、延迟和失败代价共同决定。

如果你的迁移问题只在 macOS、iOS、Xcode 构建链或某个客户端 SDK 中出现，当前方案通常有 3 个隐患：生产环境反复切模型会污染日志，代理配置难以隔离，临时设备还可能受系统版本和交付周期限制。此时租赁 VpsGona 的云端 Mac 作为短期回归环境，往往比在生产设备上反复试错更容易控制；先核对可用系统、交付方式和租赁周期是否满足复现条件，再决定是否扩大测试资源。