DeepSeek API 文档里已经出现 v4 相关模型入口：deepseek-v4-flash、deepseek-v4-pro。
同一页还写明，deepseek-chat 和 deepseek-reasoner 将在 2026/07/24 弃用。这里要说清楚：弃用不是立刻停服，文档给的是迁移时间点。
更关键的变化不在名字。旧的“聊天 / 推理”两套叙事，被折进了 deepseek-v4-flash 的不同模式里。DeepSeek 现在更像是在整理入口，而不是单纯换一块模型招牌。
v4 模型入口出现，旧模型进入倒计时
目前能确认的信息都来自 API 文档。文档没有给出完整 v4 论文、性能榜单、价格、参数规模，也没有说明 deepseek-v4-pro 和 deepseek-v4-flash 的能力差距。
能确认的是这些：
| 事项 | 文档信息 | 对开发者的直接影响 |
|---|---|---|
| 新模型名 | deepseek-v4-flash、deepseek-v4-pro | 新接入项目应开始按 v4 命名评估 |
| 旧模型弃用 | deepseek-chat、deepseek-reasoner 将于 2026/07/24 弃用 | 老项目有缓冲期，但不能无限期沿用旧名 |
| 旧新对应 | deepseek-chat 对应 v4-flash 非思考模式；deepseek-reasoner 对应 v4-flash 思考模式 | 原来的“聊天/推理”边界被改写成模式选择 |
| OpenAI 格式 | base_url 为 https://api.deepseek.com | 使用 OpenAI SDK 或兼容工具链的项目迁移成本更低 |
| Anthropic 格式 | base_url 为 https://api.deepseek.com/anthropic | 使用 Anthropic 风格调用的软件也能更快适配 |
| API 兼容 | 兼容 OpenAI/Anthropic 格式 | 这是接口格式兼容，不代表官方合作 |
调用示例里还有两个细节：thinking: {"type":"enabled"}，以及 reasoning_effort: "high"。
这说明“推理”正在从一个模型名，变成一个调用参数。模型名决定底座，thinking 决定是否打开思考，reasoning_effort 决定推理强度。
这对开发者很实际。以前你选 deepseek-chat 或 deepseek-reasoner，心智负担低。现在要把判断前移到业务层：哪类任务开 thinking，哪些请求不值得开，reasoning_effort 到 high 会不会带来更高延迟或成本。
价格和性能还没在材料里出现，所以这里不能替 DeepSeek 下结论。工程团队能做的是先改适配层，别急着把关键业务全部押上去。
迁移摩擦降低，但评估成本转移给团队
DeepSeek 这次最聪明的地方，是没有逼开发者重学一套调用方式。
OpenAI 格式的 base_url 是 https://api.deepseek.com。Anthropic 格式的 base_url 是 https://api.deepseek.com/anthropic。对已经有网关、评测脚本、Agent 框架、日志系统的团队来说，这会省掉很多脏活。
省代码，不等于省决策。
真正变复杂的是评估。过去的分界线写在模型名里：聊天走 chat，推理走 reasoner。现在分界线藏在参数里：同一个 deepseek-v4-flash，开不开 thinking，reasoning_effort 设到什么级别，结果可能不同。
受影响最明显的是两类人。
一类是已经在生产环境调用 DeepSeek API 的开发者。他们应该尽早做三件事：抽象 model 名、把 thinking 和 reasoning_effort 放进配置、给旧模型名留迁移告警。不要等到 2026/07/24 前后才集中改。
另一类是企业采购和平台工程团队。他们不该只问“v4 强不强”。更该问：同一批任务下，非思考模式和思考模式的延迟差多少，失败率差多少，成本边界有没有明确文档。
这也是现实约束。文档能降低接入摩擦，但不能替企业完成上线评估。没有价格、延迟、稳定性和基准测试，采购大概率会延后最终替换，只先做兼容验证。
横向看，OpenAI 也在把模型能力拆成模型、工具调用、推理强度等组合。Anthropic 则用 Messages API 和思考相关能力，把接口本身做成控制面。DeepSeek 走的不是怪路，而是同一条商业化路：模型竞争会落到接口竞争，接口竞争会落到默认配置。
铁路时代抢的是轨距，浏览器时代抢的是默认入口。大模型 API 时代，抢的是 SDK 习惯和调用路径。历史不完全一样，但权力结构很像：谁控制入口，谁就更接近账单、日志和生产环境。
DeepSeek 真正在做入口标准化
“天下熙熙，皆为利来。”放到 API 生态里，这个“利”不是口号，是迁移成本、调用习惯、监控体系和工程默认值。
模型名会变，接口习惯很难变。一个团队一旦把某套 API 接进网关、权限、计费、评测、灰度系统，后面再换供应商，就不是改一行 model 名那么简单。
所以我更在意 DeepSeek 这次的清理动作。它没有只把 v4 放进文档，还给旧模型写了弃用时间，把 deepseek-chat 和 deepseek-reasoner 收到 deepseek-v4-flash 的模式之下。
这不是发布会话术，是产品线治理。旧入口还留着，但方向已经改了：以后 DeepSeek 更希望开发者围绕 v4 命名和参数开关组织代码。
接下来最该观察四个变量：
deepseek-v4-pro和deepseek-v4-flash的正式能力边界怎么写。- thinking 与 reasoning_effort 是否对应不同价格、延迟和稳定性。
- 旧模型弃用前，是否会有更完整的迁移指南和评测建议。
- 兼容 OpenAI/Anthropic 格式的行为细节是否足够稳定，尤其是流式输出、错误码、工具调用和上下文处理。
如果这些补齐，v4 才能从“文档里能调用”走向“企业敢替换”。
如果迟迟不补，开发者会先接上，但关键业务会观望。工程团队不怕新名字，怕的是边界不清。上线后才发现延迟、计费、推理质量不可预期，那才是真成本。
DeepSeek 这一步做对了半步：入口统一是对的，迁移缓冲也给了。但剩下半步更硬。要让开发者把生产流量迁过来，不能只靠兼容格式，还要给出可验证、可采购、可追责的产品边界。