模型调用排期怎么排？批处理该挪到哪个低谷窗口
同一份代码、同一个模型，挑不同时刻调用，成本可以相差 2 到 5 倍。这句话以前只能当常识记着，因为「什么时候便宜」这件事没法查——窗口信息散落在十家以上平台的官方文档站，格式各异，而且大量优惠带渠道门槛：仅指定工具可用、仅套餐内、仅积分抵扣。想判断「现在该用谁」，往往要先人工巡检十余个页面，而这些活动又基本以周为单位上下线。
模型使用时钟（dsh-client-ui-model-clock）是把这件事收敛进面板的一次尝试：它把各家大模型的时间维度优惠汇总成一张以时间轴为主视图的决策面板，实时回答「现在这个点，我该调哪家最省」。它是本站作者自己维护的插件，仓库在 GitHub 上的 zhanghao3693/dsh-client-ui-model-clock，npm 包版本 0.1.0，Star 数为 0。
安装一条命令就够了：
dsh plugin --profile web add dsh-client-ui-model-clock
装完在对话视图的标签页里选「🕐 模型使用时钟」。下面说的是怎么把它变成日常排期的一部分，而不是装完看一眼就关掉。
先算清差距：同一批任务换个窗口跑，账单差多少
面板里的「全天成本热力带」是一条 24 小时时间轴，颜色代表各平台的折扣深度，竖线标出当前时刻。它把下面这些窗口压缩进同一屏：
| 平台 | 机制 | 窗口（北京时间） |
|---|---|---|
| DeepSeek 官方 | 峰谷定价，闲时半价 | 高峰 09:00–12:00 / 14:00–18:00，其余半价 |
| 智谱 Coding Plan | 非高峰按基础积分 50% 抵扣 | 高峰仅周一至周五 14:00–18:00 |
| 百度千帆 | 全时段梯度折扣 | 白天 2 折 / 夜间低至 0.5 折 / 周末 1 折 |
| 阿里云百炼 | Token Plan 夜间五折 | 22:00–08:00 |
| 硅基流动 | 分时段计价 | 02:00–08:00 闲时 |
| 火山方舟 | Auto 模式夜间路由至更强模型 | 00:00–08:00 |
拿一个具体场景算账。我们有一批每天出数据报表的批量任务，走按量计费模型，原先固定在工作日 09:30 起跑——正撞在 DeepSeek 官方的高峰段里，按标准价结算。把这个任务整体推到 22:00 之后，同一批请求落进闲时半价区间，费用直接减半。如果这批活改放到百度千帆上跑，差别还会更大：白天 2 折、夜间低至 0.5 折，同一批 token 差出 4 倍。
关键在于，这个任务本身对交付时间没有硬要求，早上九点半跑只是因为它「一直这么跑」。把「可延迟」这件事单独拎出来，是整篇排期规则成立的前提。
把「等一等更省」变成一条条能执行的规则
面板里有一块叫「等一等更省」，给的不是价格表，而是一句可执行的调度建议：把可延迟的批处理任务挪到低成本窗口，最多能省多少。我的用法是把它当输入，自己写三条规则。
规则一：先分类，再排期。 只有「延迟无感」的任务才有资格谈窗口。日报表、语料清洗、离线评测、批量摘要这类能接受几小时延迟的任务归入可延迟池；线上用户请求、交互式补全不在此列——用户不会等你到凌晨两点。这一步不做，后面所有优化都是空谈。
规则二：给每个可延迟任务写死一个目标窗口，而不是写死一个时刻。 我从热力带里读出的不是「02:30 最便宜」，而是「02:00–08:00 这一段整体处于低成本区」。所以定时任务落在区间内的某一点，并在旁边注明它属于哪个窗口；窗口变了，改的是那个点，而不是重新猜。
30 2 * * * /opt/jobs/nightly-eval.sh >> /var/log/nightly-eval.log 2>&1
上面这一行是把离线评测挪到 02:30 的结果：它落在硅基流动的闲时段，也落在千帆的夜间区间，两边都吃得到折扣。真正要写进团队文档的不是这行 cron，而是「02:30 属于哪个窗口、为什么选它」这句话。
规则三：把「省了多少」记下来。 规则如果没有数字反馈，两周后就会因为一次紧急需求被打乱，然后再也不会恢复。我的做法是每周对比一次面板给出的预估节省量和实际账单，对不上的任务单独看一眼——是窗口判断错了，还是任务偷偷跑到别的时间去了。
一个时区问题，会让上面全部结论反过来
时段判断强制按 Asia/Shanghai 计算，不依赖本机时区，这不是可选的优化项。
原因很直接：上面所有窗口都是以北京时间为口径写的。如果插件读取本机时区，那么在一台默认 UTC 的云主机上，「22:00–08:00 五折」会被算成 UTC 的 22:00 到次日 08:00，换算成北京时间就是早上六点到下午四点——结论完全反过来，面板会把一天里最贵的时段标成最便宜的那一段。开发者不在 UTC+8 时，这个错误是静默发生的：界面照常显示，颜色照常染色，但每一条建议都是错的。
所以判断之前先确认一件事：面板显示的当前时刻和你手机上的北京时间是否一致。一致再往下看。这一步只要十秒钟，但它决定了后面所有数字是否可信。
坑一：优惠数据是内置的，不会自动实时更新
这是最容易建立错误预期的地方：看到「实时回答现在该调哪家最省」，会默认它在后台抓取各家官方活动。
不是。插件刻意不自动抓取，理由是准确性与可维护性优先于覆盖率——很多活动的起止日常只写在公告正文里，自动抓很容易把已经过期的页面当成有效条目，反而给出错误结论。
代价要如实说：数据集随插件版本更新，目前是人工核实的 11 家平台、21 条优惠记录，不是实时行情，厂商活动以周为单位变动。所以正确的用法是把它当「决策前的第一眼」；涉及大额调用或长期承诺时，仍然要回到官方页面确认一遍。把它当唯一依据，就会在某次活动下线之后继续按旧价排期，而账单不会替你修正。
坑二：面板里有广告专区，先把这件事说清楚
面板里有一块「注册专属福利」：长期用某家平台时，从专区入口注册可以另得新用户福利。这块内容里有商业成分，需要如实披露——作者持有部分平台的推广关系，通过这些链接注册，作者可以获得佣金。
相关的处理是明确写死的：该区块已显著标注「广告」（这是法定字样，不能用「推广」「返利」「佣金」之类的词替代）；提供一键关闭，关掉之后面板照常可用；跳转不注入任何 URL 参数，不会把来源信息塞进你拿到的注册链接里。更关键的一条是，返利数据在任何时刻都不影响推荐排序——verify-neutrality.mjs 用投毒式穷举验证过 7×24 = 168 个时刻，排序逐条相同。
换句话说，「此刻推荐」这一栏你可以当技术结论用，它和商业关系是两条独立的线。但知道这个区块存在、也知道它带佣金，是使用它的前提。
总结
把决策落到日常排期，靠的不是记住哪家便宜，而是三件事：先把任务分成可延迟与不可延迟两类，再给可延迟任务按窗口（而不是按时刻）写死排期，最后每周用账单核对一次预估节省。判断时段之前务必确认按 Asia/Shanghai 计算，否则不在 UTC+8 的机器上会得出完全相反的结论。想对照更多同类插件的中文清单与安装形态，可以翻一下 DeepSeek Harness Hub 插件清单 里的汇总。
适合与不适合
适合：有可延迟批处理任务、希望把成本压到低谷窗口的团队；开发机不在 UTC+8、需要统一按北京时间判断优惠的场景；想先看清「现在该用谁」再决定调用哪家的个人开发者。
不适合：所有请求都必须实时响应、没有可延迟任务余地的场景；要求优惠数据自动实时更新，不接受人工核实与随版本更新用法的团队；因为 Star 为 0、暂无用户评分、许可识别为 NOASSERTION 而对项目维护度有硬要求的人；以及不接受面板内存在商业推广区块、也不愿使用一键关闭的用户。
标签：模型使用时钟、DeepSeek Harness、成本排期、峰谷定价、dsh 插件
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页；本插件由本站作者维护。