省钱实战2026-09-21 发布 · 约 4 分钟读完

分时计价按北京时间走，你的 cron 多半不按

DeepSeek V4 Pro 的输入单价有两个数，¥9 和 ¥4.5（每百万 token），取到哪一个，看请求到达那一刻北京时间几点。官方把工作日 9:00-12:00 和 14:00-18:00 划成高峰时段，其余时间一律按高峰价的一半计费。

规则本身不难懂，难的是它和排程系统对不上。cron 跟随服务器时区，容器里默认是 UTC，团队排程器跟的是办公室所在地。三套时区，没有一套是北京时间。账单上于是出现一个很难归因的现象：同一批任务，同一个模型，同样的 token 量，这个月比上个月贵了接近一倍。

高峰时段每周只有 35 小时

官方口径是北京时间周一至周五（不含中国法定节假日）9:00-12:00、14:00-18:00 为高峰时段，其余时段，包括周末和法定节假日全天，都按空闲时段计费。一天 7 小时，一周 35 小时，占一周 168 小时的约五分之一。

八成时间你本来就在便宜的那一档。会中招的是剩下两成，而那两成正好是中国的办公时间，也正好是有人手动点下「跑一遍」最可能发生的时刻。

下面是 V4 Pro 的两档价，单位为元每百万 token，核自 2026-09-21 的官方价目页。三行都是整齐的两倍关系，官方脚注写得很直白：空闲时段价格为高峰时段价格的一半。不必逐项去记。

北京时间是 UTC+8。两段高峰折算到 UTC 是 01:00-04:00 和 06:00-10:00；折算到美东夏令时（UTC-4），是前一天 21:00-24:00 和当天 02:00-06:00。

凌晨 3:00 美东夏令时等于 07:00 UTC，等于北京时间 15:00，落在第二段高峰的正中间。「半夜没人用，跑批便宜」这个直觉在跨洋计价下是反的。对美东团队来说，安全的隔夜窗口只剩 00:00 到 02:00 这两小时，反倒是白天 06:00 到 21:00 全程都在空闲价。

还有一个容易漏掉的边界：北京时间周一 09:00 对应美东周日 21:00。周日晚上启动的周初全量重算，从第一分钟起就在按高峰价走。

美东冬令时是 UTC-5，整张换算表再往前挪一小时。所以别把换算结果硬编码进 crontab：一年两次夏令时切换，写死的时间点会自己失效。

这三条都不动模型，也不动 prompt，只改排程表。

在 crontab 顶部写 TZ=Asia/Shanghai，systemd timer 用 OnCalendar 搭配同样的时区声明。让排程表达式直接用计价方所在的时区，夏令时的问题一并消失。
长任务要算跨段。一个北京时间 11:00 开跑、耗时两小时的作业，前一小时走空闲价，后一小时走高峰价；把启动时间挪到 12:00 之后，整段都在空闲档。
检查重试与退避逻辑。失败队列在空闲时段攒下来、到上班时间才被消费，等于把最便宜的任务挪到最贵的窗口去执行，这类成本在按模型聚合的监控面板里通常看不出来。

分时计价最多省一半，缓存的落差要大得多。V4 Pro 缓存命中在空闲时段是 ¥0.15 每百万 token，缓存未命中在高峰时段是 ¥9，两端相差 60 倍。两个杠杆相乘，不是二选一。

优先级很清楚：先把可复用的部分固定成稳定的缓存前缀，再把批量作业挪出那 35 小时。只做后者，省下账单的一半；只做前者，省下一个数量级。

空闲时段的价格会一直是这个数吗？

官方页面写明产品价格可能发生变动。本文数字核自 2026-09-21 的官方价目页，做年度预算前建议重新核一次，也不要把单价写死在代码里。

中国法定节假日怎么计费？

官方口径把中国法定节假日全天都算作空闲时段。国庆、春节这类长假期间整周都是半价，适合把大批量的离线重算排在那几天。

所有厂商都有分时计价吗？

并非如此。分时计价目前是少数厂商的做法，多数 API 全天同价。所以「按时段调度」不是通用省钱手段，只有在计价方确实分时段时才成立，换供应商前要重新确认。

文中价格与价格表同源、每日核对。选型前去看一眼最新价。