Skip to main content

核心要点

  • 生效时间:官方公告写的是 16:00 UTC on August 16, 2026,换算成北京时间是 8 月 17 日 00:00 (UTC+8)
  • 不是分时优惠,是整体上调后再分时:谷时价定为峰时的一半,但谷时价本身也高于调整前——deepseek-v4-flash 输出从 $0.28 涨到谷时 $0.66、峰时 $1.32
  • 涨幅最大的是缓存命中价deepseek-v4-pro 缓存命中输入从 $0.003625 涨到峰时 $0.044,约 12 倍
  • 根因是并发,不是成本:官方文档写明账号级并发上限 deepseek-v4-pro 500、deepseek-v4-flash 2500,超出直接 429;官方对调价的表述是”更合理地分配资源”
  • API易 的选择是固定峰值档:不随时段浮动,主因是官方并发不足时要用成本更高的备用链路保供,这部分我们不赚钱;充值加赠仍可叠加

背景介绍

DeepSeek 上一次调价还是往下走的。V4 系列今年上线时把百万 tokens 的输入压到 $0.14、输出 $0.28,是同档位里最便宜的一批,也因此成了大量批量任务、Agent 长链路的默认底座。 这次方向反过来了。官方在定价页挂出公告:API 改为峰、谷两档计费,谷时为峰时的一半,新价自 16:00 UTC on August 16, 2026 生效。官方对原因的表述很克制——为了”更合理地分配资源”,建议用户”根据实际使用情况安排任务”。 真正值得关注的不是”涨了多少”,而是涨价的形式:分时计价把成本的不确定性转嫁给了调用方。对直接用官网的个人开发者,这意味着可以把批量任务挪到夜里;但对承接聚合流量的第三方网关来说,这是一道必须先回答的定价题。 本文数据来自 DeepSeek 官方定价页 api-docs.deepseek.com/quick_start/pricing 与速率限制文档 api-docs.deepseek.com/quick_start/rate_limit,采集日期 2026 年 8 月 15 日。

详细解析

调整后的价格

deepseek-v4-flash(每 1M tokens): deepseek-v4-pro(每 1M tokens):
容易被”谷时半价”这个说法误导的一点:谷时价不是折扣价,它同样高于调整前的价格。以 deepseek-v4-flash 输出为例,即便全部调用都落在谷时,单价也从 $0.28 变成 $0.66,是原来的 2.4 倍。

峰谷时段怎么划分

官方定义的峰时是 01:00–04:00 与 06:00–10:00 UTC,其余时段为谷时。换算成北京时间: 看清楚这两个窗口:09:00–12:00 和 14:00–18:00 (UTC+8) 正好是国内工作日的两段核心工作时间。峰时一天只占 7 小时,听起来不多,但对以国内用户为主的业务来说,真实调用量的绝大部分恰恰压在这 7 小时里。“谷时”落在深夜、清晨和午休,能挪过去的只有离线批处理。 这个时段设计不是巧合,它就是冲着削峰去的。

涨价的根因:并发是硬上限

官方速率限制文档给出的数字比价格更能说明问题: 一个请求从发出到响应完成算一路并发,超出上限直接返回 429。文档同时写明可以提交扩容申请、扩容本身不额外收费,扩容后按 user_id 做隔离。 “扩容不收费”这句话反过来读,信息量很大:限制资源分配的手段不是价格,是审批与实际算力。行业媒体的解读也指向同一处——需求增长超过了算力扩张速度,供给约束下调价是必然。分时计价的作用不是多赚钱,是把 7 小时高峰里的部分负载赶到另外 17 小时去。 对第三方网关而言,这条并发上限才是最难受的部分。网关聚合的是成百上千个客户的流量,账号级并发很容易在业务高峰打满,而扩容需要走申请流程、有周期。这就是为什么第三方必须准备备用链路。

第三方平台的三种对策

分时计价传到中间层,只有三个出口。

对策一:跟随分时

照搬官方的峰谷两档,用户成本随调用时刻浮动。

对策二:固定谷时价

统一按谷时价挂出,账面最便宜。

对策三:固定峰值档

统一按峰时价,价格恒定不浮动。

对策一:跟随分时计费

最”忠实”的做法,但落地有两个坎。一是计费系统要支持按时段切换费率,并且要能在账单里把每一笔调用归到正确的档位,改造量不小。二是用户侧成本变得不可预测——同一份任务,上午跑和凌晨跑账单差一倍,做预算、做成本归因都会变麻烦。 对以稳定单价为卖点的中间层来说,这是把复杂度转嫁给了用户。

对策二:固定按谷时价

账面上最好看,但结合上一节的时段划分就知道问题在哪:峰时那 7 小时恰好是国内业务的用量大头。按谷时价对外收费,等于把最集中的那段流量按半价卖,缺口只能从别处补。 短期可以当作获客补贴,长期必然要么涨回去、要么在供给上打折扣(限流、排队、降级到便宜的备用源)。定价看着便宜、实际调用体验不稳定,多半是这个结构在起作用。

对策三:固定按峰值档(API易 的选择)

我们选了第三条:deepseek-v4-flashdeepseek-v4-pro 同步调整为官网峰值档,固定不随时段浮动,与官方同步在北京时间 8 月 17 日零点生效。 先说次要原因:计费系统目前不支持按时段浮动费率。这是事实,但它不是主要理由——真要做也能做。 主要原因在供给结构:
  • 我们优先走官方渠道,这是成本最低、行为最标准的一路
  • 官方并发不足时,用 BytePlus 与阿里云官转作为备用链路顶上,保证请求不排队、不掉在 429 上
  • 备用链路的实际采购成本明显高于官网,这一点在 DeepSeek 上一直如此
也就是说,我们对外的单价必须同时覆盖两条链路。按峰值档统一定价,是为了让备用链路在需要时随时能用——保供优先于账面价格,这部分我们不赚钱。
如果只按官方谷时价对外定价,一旦官方并发打满就只有两个选择:让请求排队等官方,或者贴钱走备用。前者牺牲可用性,后者不可持续。固定峰值档换来的是任何时刻的可用性都一样

实际应用

选型与省钱建议

一、能用 flash 就别上 pro。 调价前后 pro 与 flash 的价差都是 3 倍左右(未命中输入 $1.32 : $0.44、输出 $3.96 : $1.32),选型逻辑完全没变。V4 Flash 正式版实测五项 agent 基准反超 Pro 预览版,绝大多数场景够用,详见 V4 Flash 正式版上线说明 二、缓存依然极其划算,但性价比不如从前。 pro 的缓存命中价相对未命中价,从调整前的约 1/120 变成现在的 1/30;flash 从 1/50 变成 1/31。倍率虽然被压缩了,命中一次仍然省掉 96% 以上的输入成本,长系统提示词、长文档前缀该缓存还是要缓存。 三、别把批量任务挪到半夜。 这一条要说清楚:在 API易 上单价固定为峰值档,换时段跑没有价格收益。挪时段只对直连官网的用户有意义。想降成本,方向是压缩输出 tokens、用足缓存、把简单任务下沉到 flash。 四、充值加赠照常叠加。 单价与官网峰值档对齐,折扣走充值活动,实际到手成本仍低于名义价。

代码示例

模型名与调用方式都没有变化,调价不需要改代码:

价格与可用性

API易 侧调整后的价格(每 1M tokens,固定峰值档): 生效时间与官方一致:北京时间 2026 年 8 月 17 日 00:00 (UTC+8)。模型 ID、端点、参数结构均无变化,双端点(Chat Completions 与 Responses)继续可用。

叠加网站充值活动

API易 的价格始终对齐官网,折扣通过充值加赠体现 📖 充值优惠活动详情

总结与建议

这次调价的信号比数字更重要:低价供给的窗口正在收紧。DeepSeek 用分时计价给高峰负载加价,本质上是在用价格分配一份不够用的算力,而并发上限那组数字说明这不是短期波动。 对使用方,三条建议:
  1. 重新做一次选型体检——pro 与 flash 的 3 倍价差没变,但绝对值涨上来之后,“随手用 pro”的代价比以前大得多
  2. 把缓存当成必选项而不是优化项——命中一次省 96% 以上输入成本,这是涨价后收益最确定的一项工程投入
  3. 不要指望通过换时段省钱——在 API易 上单价恒定,成本优化要落在 tokens 和选型上
我们这边的承诺很简单:价格对齐官网峰值档、不随时段浮动、备用链路随时可用。保供优先,这部分不赚钱,折扣照旧走充值加赠。
数据来源:DeepSeek 官方定价页 api-docs.deepseek.com/quick_start/pricing、速率限制文档 api-docs.deepseek.com/quick_start/rate_limit。公告生效时间 16:00 UTC on August 16, 2026,数据采集日期 2026 年 8 月 15 日。API易 侧价格以模型价格页实时数据为准。