核心要点
- 生效时间:官方公告写的是
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-pro500、deepseek-v4-flash2500,超出直接 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):
峰谷时段怎么划分
官方定义的峰时是 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-flash 与 deepseek-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 用分时计价给高峰负载加价,本质上是在用价格分配一份不够用的算力,而并发上限那组数字说明这不是短期波动。 对使用方,三条建议:- 重新做一次选型体检——pro 与 flash 的 3 倍价差没变,但绝对值涨上来之后,“随手用 pro”的代价比以前大得多
- 把缓存当成必选项而不是优化项——命中一次省 96% 以上输入成本,这是涨价后收益最确定的一项工程投入
- 不要指望通过换时段省钱——在 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易 侧价格以模型价格页实时数据为准。