← 全部文章

DeepSeek V4-Pro 正式版发布:峰谷定价、Responses API 与路由成本优化指南

DeepSeek V4-Pro 于 8 月 13 日正式发布,带来灵活推理力度、原生 Responses API 支持以及全新的峰谷定价模型(8 月 16 日生效)。本文梳理具体变化、完整价格表以及通过路由层调度工作负载来降低成本的方法。

· TheRouter

DeepSeek V4-Pro 正式版(模型版本 DeepSeek-V4-Pro-0813)已于 2026 年 8 月 13 日上线。这次更新对 API 路由层有三项实际影响。推理力度(reasoning effort)新增 low/high/max 三档可控。API 层原生支持 OpenAI Responses API 格式,Codex 可以直接接入。2026 年 8 月 16 日 16:00 UTC 起,所有调用采用峰谷定价,谷时价格只有峰时的一半。批量任务放到谷时跑,成本立刻减半。

这篇指南会列出 V4-Pro 和 V4-Flash 的完整价格表、峰谷时段在各时区的对应关系、推理力度对成本的影响,以及如何利用路由层在峰谷之间调度。

8 月 13 日发生了什么

DeepSeek 在 V4-Pro GA 公告中打包发布了几项更新。

  1. V4-Pro 转正。 模型版本号升至 DeepSeek-V4-Pro-0813,API 模型名仍为 deepseek-v4-pro,已有代码无需改动。

  2. 推理力度可调。 V4-Pro 和 V4-Flash 均支持 low、high、max 三档。默认 high。简单的分类和抽取任务设成 low 可以大幅削减 thinking token。

  3. 原生 Responses API。 DeepSeek 是第一个在 https://api.deepseek.com 端点原生兼容 OpenAI Responses API 的非 OpenAI 提供商。Codex 和其他 Responses API 消费者可以直接对接。

  4. 峰谷定价。 自 2026 年 8 月 16 日 16:00 UTC 起生效,谷时价格 = 峰时价格 × 50%。

完整价格表

所有价格以每 100 万 token 为单位。数据来自 DeepSeek 官方定价页面,获取日期 2026 年 8 月 17 日。

V4-Flash(deepseek-v4-flash)

计费项谷时峰时
输入(缓存命中)$0.007$0.014
输入(缓存未命中)$0.22$0.44
输出$0.66$1.32
并发上限2,5002,500

V4-Pro(deepseek-v4-pro)

计费项谷时峰时
输入(缓存命中)$0.022$0.044
输入(缓存未命中)$0.66$1.32
输出$1.98$3.96
并发上限500500

峰谷时段

峰时为 UTC 01:00–04:00 和 UTC 06:00–10:00,其余时段全部为谷时。

换算到常用时区的对照表如下。

时区峰时谷时
UTC01:00–04:00, 06:00–10:00其余时段
北京时间(UTC+8)09:00–12:00, 14:00–18:00其余时段
美西 PDT(UTC-7)18:00–21:00, 23:00–03:00其余时段
美东 EDT(UTC-4)21:00–00:00, 02:00–06:00其余时段
中欧 CEST(UTC+2)03:00–06:00, 08:00–12:00其余时段

峰时基本覆盖中国的工作时间加上欧洲上午。如果你的用户主要在美洲,大部分流量自然落在谷时。

调价前后对比

8 月 16 日之前 DeepSeek 采用统一定价。以 V4-Pro 为例,新旧价格对比见下表。

场景(V4-Pro,1M token)原统一价新谷时价新峰时价
输入(缓存未命中)$0.44$0.66$1.32
输出$1.32$1.98$3.96

谷时价格比原来上涨约 50%,峰时价格是原来的 3 倍。对于不做任何调度优化的工作负载,这是一次净涨价。但如果把批量任务搬到谷时,成本仍然可以接近原来的水平。

OpenAI 兼容指供应商提供一个 chat-completions 接口,其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值(API key、base URL、模型名),原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model, 并返回 OpenAI 形式的流式响应。

推理力度选择

V4-Pro 和 V4-Flash 默认开启 thinking mode,力度为 high。各档映射关系见下表。

请求值实际映射
lowLow(最少链式推理)
mediumHigh(内部映射到 high)
highHigh(默认)
maxMax(最深推理)

通过 OpenAI SDK 设置 reasoning_effort 的写法如下。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_KEY",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "分析这份合同条款..."}],
    reasoning_effort="low",
    extra_body={"thinking": {"type": "enabled"}},
)

要完全关闭 thinking,把 thinking.type 设为 "disabled" 即可。这样模型跳过链式推理,直接输出最终回答。

成本影响。 Thinking token 按照和输出 token 相同的价格计费。选择 low 可以大幅减少推理 token 数量,分类和抽取任务中 low 相比 max 通常能减少 60%–80% 的 thinking token 用量。

Responses API 与 Codex 集成

DeepSeek 的 Responses API 实现了 OpenAI Responses API 格式的直接兼容。目前支持的特性有以下几项。

  • 语义化 SSE 事件流,包括 response.output_text.delta、response.reasoning_text.delta 和类型化的 tool call 事件
  • 函数调用与 web 搜索,通过 tools 参数
  • 推理力度控制,通过 reasoning.effort 字段
  • instructions 参数,作为首条 system 消息插入
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_KEY",
    base_url="https://api.deepseek.com",
)

response = client.responses.create(
    model="deepseek-v4-pro",
    instructions="你是一个编程助手。",
    input="把这个函数改写成 async/await 风格。",
)

print(response.output_text)

与 OpenAI Responses API 相比,DeepSeek 不支持 previous_response_id、conversation、store、background 和 metadata。实现是无状态的,每个请求独立。不支持的参数被静默忽略,不会引发错误。

Codex 接入

DeepSeek 提供了 Codex 一键配置,预设了 multi-agent v2 支持、apply_patch 工具类型设为 freeform、1M token 上下文窗口。V4-Flash 和 V4-Pro 两个模型均可使用。

通过 TheRouter 路由 DeepSeek V4-Pro

TheRouter 可以把 OpenAI 兼容请求路由到已配置的提供商。你可以把 DeepSeek V4-Pro 设为主模型,配合 fallback 路由 在 DeepSeek 不可用时自动切换。

基本调用方式如下。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_THEROUTER_KEY",
    base_url="https://therouter.ai/api/v1",
)

response = client.chat.completions.create(
    model="deepseek/deepseek-v4-pro",
    messages=[{"role": "user", "content": "解释峰谷定价"}],
)

用 DashScope 做备用路径

V4-Pro 也在阿里云百炼(DashScope)上线,模型 ID 为 deepseek-v4-pro-0813。DashScope 的计费结构不同(人民币计价,目前没有峰谷分段),可以作为 DeepSeek 峰时的稳定成本备选路径。

调度工作负载以利用谷时折扣

峰谷定价带来了一个直接的优化思路,把可以延后的任务放到谷时执行。

可以延后的工作负载

  • 批量评测跑分
  • 数据集标注
  • 文档摘要流水线
  • 非紧急 PR 的代码审查
  • RAG 索引的 embedding 生成

不能延后的工作负载

  • 交互式对话
  • 实时编程助手响应
  • 延迟敏感的 API 端点

落地方案

1. 定时批量任务。 用 cron 把批处理排到谷时。北京时间的团队需要避开 09:00–12:00 和 14:00–18:00 的峰时窗口。

2. 队列化延迟执行。 非紧急请求推入消息队列(SQS、RabbitMQ、Redis),在谷时消费。文档处理流水线特别适合这种模式。

3. 对比 OpenAI Batch API。 DeepSeek 目前没有单独的 Batch API,但谷时 50% 折扣在效果上等同于 OpenAI Batch API 的 50% 折扣,只是切换维度从"批量 vs 实时"变成了"谷时 vs 峰时"。

常见错误与解决办法

错误原因解决方式
400: reasoning_content must participate in contextthinking mode 下有 tool call,但后续请求没有回传 reasoning_content当涉及 tool call 时,必须把 assistant 消息中的 reasoning_content 传回后续请求
400: request exceeds context window输入超过 1M token 上限截断输入或拆分为多个请求
Rate limit exceeded超出并发上限(V4-Pro 500,V4-Flash 2500)增加退避逻辑,或将溢出请求路由到其他提供商

上线前检查清单

在生产环境部署 V4-Pro 之前,确认以下事项。

  • 确认使用的模型名是 deepseek-v4-pro,不是旧的 deepseek-chat 或 deepseek-reasoner
  • 按用途显式设置 reasoning_effort,不要所有场景都用默认的 high
  • 监控峰谷时段的 token 用量分布。如果超过 60% 的量落在峰时,评估是否能把批量任务移到谷时
  • 配置至少一条 fallback 路由(V4-Flash、DashScope 上的 V4-Pro,或完全不同的模型)
  • 如果打算用 Codex 或其他 Responses API 消费者,提前测试兼容性
  • 对 V4-Pro 的 500 并发上限设置告警

延伸阅读

本文涉及的模型

帮助与联系