从北京时间 2026 年 8 月 17 日 00:00 起，DeepSeek API 正式切换到峰谷定价模式。规则很直接：高峰时段价格翻倍，空闲时段价格降为高峰时段的一半。对已经上线的 AI 应用来说，这不只是一次价格表更新，还会影响批处理、缓存、重试和容量规划。
本次调整覆盖 DeepSeek-V4 系列的两个主力模型：DeepSeek-V4-Flash 和 DeepSeek-V4-Pro。高峰时段为北京时间 09:00-12:00 和 14:00-18:00，其余时间属于空闲时段。
价格变化应该怎样理解
如果某模型的标准参考价格记为 P，那么可以按下面的关系估算：
- 高峰价格：
2P - 空闲价格：
P - 高峰价格相对空闲时段：2 倍
因此，所谓“空闲时段价格为高峰时段价格的一半”，并不代表全天调用都涨价。真正的影响取决于业务流量分布：
- 在线问答、客服和实时编码助手通常集中在工作时间，成本可能明显上升。
- 报表生成、文档索引、离线评测和数据清洗可以迁移到空闲时段。
- 如果全天流量均匀，按完整日历日计算的平均单价可能接近原参考价格，但实际账单仍取决于各时段 token 分布。
- 重试请求如果落在高峰时段，会进一步放大峰值成本。
不要只看请求数量。应按输入 token、输出 token、模型和调用时段分别统计成本。
先把账单模型改成按时段计算
可以用下面的 Python 示例计算一批调用的预估成本。示例中的 base_input_price 和 base_output_price 是占位值，请替换成控制台或官方价格表中对应模型的实际参考价格。代码假设价格单位为“每百万 token”。
from datetime import datetime
from zoneinfo import ZoneInfo
BEIJING = ZoneInfo("Asia/Shanghai")
def is_peak_time(timestamp: datetime) -> bool:
"""判断北京时间是否处于 09:00-12:00 或 14:00-18:00。"""
local_time = timestamp.astimezone(BEIJING).time()
return (
(9 <= local_time.hour < 12)
or (14 <= local_time.hour < 18)
)
def estimate_cost(
input_tokens: int,
output_tokens: int,
base_input_price: float,
base_output_price: float,
timestamp: datetime,
) -> float:
multiplier = 2.0 if is_peak_time(timestamp) else 1.0
input_cost = input_tokens / 1_000_000 * base_input_price * multiplier
output_cost = output_tokens / 1_000_000 * base_output_price * multiplier
return input_cost + output_cost
request_time = datetime(2026, 8, 17, 10, 30, tzinfo=BEIJING)
cost = estimate_cost(
input_tokens=120_000,
output_tokens=30_000,
base_input_price=1.0, # 替换为实际输入 token 参考价
base_output_price=2.0, # 替换为实际输出 token 参考价
timestamp=request_time,
)
print(f"estimated cost: {cost:.6f}")
生产环境还需要确认价格表是否区分缓存命中、缓存写入、输入 token 和输出 token。上面的乘数逻辑只表达峰谷时段规则，不能替代具体模型的完整计费公式。
把可延迟任务移出高峰
最容易获得收益的动作，是给任务增加调度优先级和最晚完成时间。比如，离线任务可以只在空闲时段发送：
#!/usr/bin/env bash
# 服务器时区设为 Asia/Shanghai 时使用。
# 每天 00:30 启动夜间批处理，避开 09:00-12:00 和 14:00-18:00。
30 0 * * * /opt/ai/jobs/run_batch.sh >> /var/log/ai-batch.log 2>&1
如果任务不能简单地固定在夜间运行，可以让队列消费者在北京时间高峰期降低并发，空闲时段再提高吞吐。实时请求则不应为了省钱强行延迟，否则用户体验和 SLA 会直接受到影响。
应用侧需要补上的保护措施
峰谷价格生效后，建议检查以下几个边界：
- 成本监控按北京时间分桶。 至少记录模型、输入输出 token、请求时间、是否缓存命中和请求结果。
- 重试设置上限。 网络错误、超时或限流导致的重试应使用指数退避，并设置最大次数，避免高峰期重复付费。
- 区分实时和离线队列。 实时队列保障延迟，离线队列可以等待低价时段。
- 缓存高重复提示词。 系统提示词、长文档上下文和重复检索结果应尽量复用缓存能力，具体规则以模型价格表为准。
- 重新计算预算。 不要把“空闲价格减半”直接套到总账单上，应使用过去数周的时段流量分布进行加权。
一个简单的日成本估算公式是：
日成本 = 高峰时段 token 成本 × 2 + 空闲时段 token 成本 × 1
其中“token 成本”应分别代入输入和输出价格。若业务有不同模型，也应按模型拆开计算。
上线前的检查清单
- 确认应用所在系统和调度器使用的时区。
- 将
09:00-12:00、14:00-18:00作为北京时间处理，而不是服务器本地时区。 - 统计过去 7 至 30 天的 token 在峰谷时段的分布。
- 为离线任务增加队列、截止时间和失败重试策略。
- 在账单监控中设置高峰成本告警。
- 用实际模型价格表替换示例中的占位价格。
这次定价调整的核心不是简单地“涨价”或“降价”，而是让调用时间成为成本变量。实时业务需要接受高峰溢价；可以延迟的工作，则应通过队列和调度迁移到空闲时段。先按时段建立准确的 token 成本统计，再决定是否调整模型、缓存策略或任务执行时间，通常比盲目切换模型更稳妥。