DeepSeek 官方 API 已经不是全天同价。工作日北京时间 9:00–12:00、14:00–18:00 为高峰时段，其余时间使用空闲价；周末全天都落在空闲时段。空闲价正好是高峰价的一半。
这并不意味着所有调用都该挪到夜里。实时对话、在线 agent、用户正在等待的代码任务，延迟本身可能比 token 折扣更贵。真正适合移时的是有明确截止时间、可以排队、失败可重试并且结果可核验的批处理。
以下价格和时段核验于 2026 年 9 月 3 日。DeepSeek 明确提示价格可能调整，正式预算前应再看一次中文官方价格页。
先确认你用的是哪一张价格表
中文官方页面以人民币列出每 100 万 tokens 的价格，并把输入拆成“缓存命中”和“缓存未命中”。这三类 token 不能合并成一个平均单价。
| 模型与时段 | 输入：缓存命中 | 输入：缓存未命中 | 输出 |
|---|---|---|---|
deepseek-v4-flash 空闲 | ¥0.05 | ¥1.50 | ¥4.50 |
deepseek-v4-flash 高峰 | ¥0.10 | ¥3.00 | ¥9.00 |
deepseek-v4-pro 空闲 | ¥0.15 | ¥4.50 | ¥13.50 |
deepseek-v4-pro 高峰 | ¥0.30 | ¥9.00 | ¥27.00 |
不要拿英文页面的美元数字按即时汇率反推这张表，也不要把第三方中转站的售价套进来。它们可能有不同的计费单位、加价、赠送额度和退款规则。这里计算的是 DeepSeek 官方托管 API 的人民币价表。
V4 Flash 与 V4 Pro 都支持思考和非思考模式，但价格差距很大。Flash 适合先承担大量可验证任务；Pro 只有在更高的任务成功率、较少重试或较低人工复核成本能够抵消价差时，才值得成为常用路线。价格低不等于任务总成本低。
用三项 token 数量直接算账
一批调用的原始 token 成本可以写成：
text费用 = 缓存命中输入 tokens ÷ 1,000,000 × 对应单价 + 缓存未命中输入 tokens ÷ 1,000,000 × 对应单价 + 输出 tokens ÷ 1,000,000 × 对应单价
假设一天的批处理累计使用：
- 600 万缓存命中输入 tokens；
- 200 万缓存未命中输入 tokens；
- 100 万输出 tokens。
如果使用 deepseek-v4-flash，空闲时段费用是 6 × 0.05 + 2 × 1.50 + 1 × 4.50 = ¥7.80；全部落在高峰时段则是 ¥15.60。
同样用量换成 deepseek-v4-pro，空闲时段是 6 × 0.15 + 2 × 4.50 + 1 × 13.50 = ¥23.40；高峰时段是 ¥46.80。
这个例子说明了两个不同的优化动作。把相同调用从高峰移到空闲，可以把官方 token 费用减半；提高缓存命中率，则是把一部分昂贵的“未命中输入”换成更便宜的“命中输入”。二者可以叠加，但不能互相替代。
实际账单还要加入你自己的重试、失败调用、第三方加价、税费和汇率成本。更重要的是，如果为了省 token 而造成任务积压、交付延误或人工返工，节省的 ¥7.80 很可能没有业务意义。
“工作日”以官方时区规则为准
DeepSeek 的英文价格页把高峰窗口写成周一至周五 01:00–04:00 UTC 与 06:00–10:00 UTC。换算为北京时间，正好是当天 09:00–12:00 与 14:00–18:00。
因此，在中国时区配置定时任务时，可以直接使用北京时间窗口，但跨地域系统最好仍保存 UTC 规则。一个团队若在北京配置 scheduler、在美国触发任务、又在欧洲查看日志，只写“上午九点”很容易在夏令时和日期边界上出错。
建议让调度器判断一个明确的 UTC 时间段，而不是依赖服务器本地时区。还要在日志里同时记录：
- 请求发出时间与时区；
- 实际模型 ID；
- 缓存命中输入、未命中输入与输出 tokens；
- 重试次数、最终状态和单任务费用。
只有这些字段齐全，才能确认任务是否真的按空闲价运行。单看每天总余额下降无法区分时段、缓存和重试造成的差异。
哪些任务值得进入空闲队列
判断标准不是“能不能晚点跑”，而是晚点跑之后仍能稳定完成任务。
适合排队的工作通常包括离线分类、批量摘要、索引补全、夜间评测、非紧急代码扫描、可重建的内容预处理。它们有共同特征：输入已经落盘，任务带唯一 ID，重复执行不会重复扣业务结果，失败后可以从队列恢复，且在下一个业务节点前完成即可。
不适合为了折扣等待的工作包括面向用户的实时回复、支付或风控决策、线上故障诊断、交互式 coding agent、严格 SLA 内的自动化，以及任何“现在不返回就失去价值”的请求。
如果一项任务介于两者之间，可以先给它增加最晚完成时间，而不是硬编码“夜里运行”。调度器只有在截止时间允许、当前窗口为空闲、队列容量充足时才延后；否则按正常优先级立即执行。这样既能捕获折扣，也不会让价格规则接管产品体验。
队列改造要先守住四条边界
第一，任务必须幂等。消费者重复领取同一任务时，不应重复发邮件、写两次数据库或生成两个收费结果。可用稳定的业务键去重，并把 DeepSeek 请求与业务提交分开记录。
第二，必须有截止时间和优先级。周末全天空闲并不意味着可以把所有工作压到周末；队列过长会带来新的恢复风险。临近截止时间的任务应退出省钱等待，进入立即执行。
第三，价格窗口不等于容量承诺。官方限流文档目前列出 Flash 每账户 2500 并发、Pro 500 并发，超出时会返回 HTTP 429。这只是公开限制，不保证空闲时段一定更快，也不代表所有账户都具有相同扩容条件。客户端仍需要退避、重试上限和死信处理。
第四，先做小流量账本。连续记录至少一个完整工作周，分别观察高峰与空闲任务的 token、成功率、p95 延迟、重试和人工复核。只有“完成一项可接受任务”的总成本下降，才值得扩大调度比例。
Flash、Pro 与时间窗口应该一起选
一种稳妥做法是先按失败代价分配模型，再按时限决定执行窗口：可自动验收、失败成本低的任务先交给 Flash；困难任务或 Flash 未通过验收的任务再升级到 Pro；其中可延迟部分进入空闲队列，实时部分保持立即执行。
这比“所有任务夜里跑 Pro”更容易控制预算。模型升级、缓存与移时分别解决质量、重复输入和费率问题。每次只改一个变量，才能从日志中看清收益来自哪里。
如果你还在比较不同供应商的价格，不要只把本页四行数字放进表格。还应统一任务、提示、输出上限、重试政策和验收标准，再参考当前 LLM API 价格比较。供应商之间的缓存定义和计费边界未必相同。
上线调度前的最小验证
先用一组固定任务在高峰和空闲各运行一次，保存 API 返回的 usage、模型 ID、时间戳与余额变化。确认计算值和账单方向一致后，再把少量批处理切到新队列。若出现时间窗口判断错误、重复消费、HTTP 429 激增、任务超时或人工复核上升，就立即恢复原计划。
最后，把官方价格页作为配置数据的人工核验入口，而不是把价格永久写死在业务逻辑里。峰谷定价能把合适的工作负载成本减半，但只有在任务仍按时、正确、可追踪地完成时，这个折扣才是真正的节省。
