TheRouter.aiTheRouter.ai
← 全部文章

LLM API 峰谷定价调度指南

DeepSeek 的峰谷 API 价格让时间成为真实成本变量。本文说明哪些 LLM 任务可以挪到低价窗口，怎样安全调度，以及路由层能做什么、不能承诺什么。

· TheRouter

三十秒答案很直接。峰谷定价适合能等待、能重试、能事后对账的 LLM 任务。DeepSeek 现在公布的高峰窗口是 UTC 1 点到 4 点与 6 点到 10 点，谷值价格为峰值的一半，并且在 8 月 23 日北京时间规则调整后，周末全天按谷值计费。离线 eval、文档补全、embedding 回填、夜间摘要和非紧急 agent 记录可以考虑挪到低价窗口。在线聊天、用户可见 tool call、支付决策和事故处理应继续按延迟与可靠性优先。

这里最容易弄错的是职责边界。路由层可以帮你选择已配置 provider 与 model fallback。它不等于自动按时间套利，除非这个能力已经在真实产品路径里验证过。实际系统里，队列或 scheduler 决定何时执行，TheRouter 决定请求进入哪条已配置的 OpenAI-compatible route。

  1. 替换三个值，不是三个 SDK。在现有 OpenAI 客户端里改 api_key、base_url、model。请求与响应代码保持不变。
  2. 显式映射 model ID。目标供应商的 model id 几乎不会和 OpenAI 完全一致。 在业务代码之外维护一份 { openai_id: target_id } 映射。
  3. 验证流式格式。SSE 分片必须遵循 OpenAI 的 data: {...} + data: [DONE] 契约。切生产前先跑一次流式调用。
  4. 检查限流响应头。部分供应商不返回 x-ratelimit-*。 在包装层 做缺省兜底，缺头不要崩。
  5. 留回滚路径。用 feature flag 切流；新旧 endpoint 影子并行 24 小时，再正式切换。

DeepSeek 价格发生了什么变化

DeepSeek 在 8 月 13 日的 V4-Pro GA 说明里公布了 flexible reasoning effort、原生 OpenAI Responses API 支持，以及新的峰谷价格。官方价格页现在列出 DeepSeek V4-Flash、V4-Pro 和 V4-Flash-Vision-Exp 的峰谷价格，谷值正好是峰值的一半。页面还写明，高峰时间是 UTC 1 点到 4 点与 6 点到 10 点，其余时间为谷值，并且 8 月 23 日北京时间规则调整后，周末全天按谷值计费。

这让时间变成成本变量。V4-Pro 输出 token 的峰值价格为每百万 $3.96，谷值为 $1.98。V4-Flash 输出从 $1.32 降到 $0.66。cache miss input 和 cache hit input 也遵循同样的两倍关系。

这不是整个 LLM 市场的统一规则。OpenAI 和 Anthropic 更常见的公开成本杠杆是 batch discount。OpenAI Batch API 文档说明，Batch 面向不需要即时响应的请求，成本低 50%，完成窗口为 24 小时。Anthropic Message Batches 文档说明，结果会在全部完成后或 24 小时后可取，官方价格说明里也写到 batch processing 有 50% discount。

哪些任务可以安全移动

安全候选任务通常有三个特征。结果不需要实时展示给用户，任务可以重放，输出可以用稳定 ID 对回去。

任务是否适合挪到谷值原因
离线 eval是结果通常事后比较，不在用户会话中使用
文档补全是可以从队列运行，写入经过复核的 metadata
embedding 回填是量大、不急、容易 checkpoint
数据集分类是天然适合按 row ID 对账
夜间摘要是本来就是计划任务
客户聊天否为价格窗口等待会破坏产品延迟
在线 agent tool call通常否延迟会改变 agent 行为和用户体验
支付、安全、风控决策否新鲜度与审计时序比 token 折扣重要

一个简单判断就够用。如果请求晚六小时执行会产生客服工单，就不要移动它。

我们采用的调度方式

把谷值执行当成一条 lane，不要把它设成全局默认。一个最小生产设计通常长这样。

  1. 给任务分类。 增加 latency_class 字段，例如 realtime、deferred、batch_window。
  2. 给任务截止时间。 可延迟任务也要有最晚完成时间。
  3. 记录价格规则。 保存 provider、时区、峰值窗口、周末规则、获取日期和来源 URL。
  4. 用稳定 key 入队。 使用 durable job ID，避免重试时重复写入。
  5. 在窗口释放任务。 worker 在 provider 处于谷值且 deadline 允许等待时释放任务。
  6. 执行路由和 fallback。 真正的 OpenAI-compatible 请求再进入配置好的 provider 或 router path。
  7. 对账结果。 比较 accepted output、retry、过期任务和实际 billable token。
const deepseekOffPeak = (date: Date) => {
  const utcHour = date.getUTCHours();
  const isPeak = (utcHour >= 1 && utcHour < 4) || (utcHour >= 6 && utcHour < 10);
  return !isPeak;
};

export function shouldRelease(job: { latencyClass: string; deadline: Date }, now = new Date()) {
  if (job.latencyClass === "realtime") return true;
  if (now > job.deadline) return true;
  return deepseekOffPeak(now);
}

这段代码故意不完整。它没有处理北京时间周末计费、节假日、provider policy change 和 model-specific exception。生产环境应把这些规则存成数据，并从官方价格页刷新，不要把它们埋在业务代码里。

TheRouter 放在哪一层

TheRouter 可以把 OpenAI-compatible 请求路由到已配置 provider，并在真实产品路径支持时提供 provider/model routing 和 fallback。scheduler 决定任务该运行以后，这一层就有价值。

例如，一个延迟 eval worker 可以调用同一个 OpenAI-compatible base_url，在低价 lane 里选择已配置的 DeepSeek target，并保留 provider error 的 fallback chain。时间由 scheduler 负责，provider/model path 由 router 负责。

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.THEROUTER_API_KEY,
  baseURL: "https://api.therouter.ai/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek/deepseek-v4-flash",
  messages: [{ role: "user", content: "Classify this support ticket." }],
});

当价格窗口和模型质量都合适时，可以使用 DeepSeek。困难 reasoning 或 agent 任务适合看 DeepSeek V4-Pro，高吞吐任务则优先评估 DeepSeek V4-Flash。相邻的成本模式可以继续看我们的 LLM batch processing guide、LLM API cost optimization guide 和 DeepSeek V4-Pro GA pricing guide。

需要提前设计的故障

第一个故障是价格规则过期。provider 价格页会改，scheduler 如果沿用上个月的窗口，成本会安静地变高。把来源和获取时间放在规则旁边，并在长时间未刷新时告警。

第二个故障是 deadline inversion。所有延迟任务都等同一个便宜窗口，队列可能在窗口开始时打满 rate limit。DeepSeek 公布的并发限制是 V4-Pro 500，V4-Flash 2,500。把它们当作容量约束，不要当作所有排队任务都会立刻完成的承诺。

第三个故障是不安全重试。分类 row 可以重试。客户邮件发送、扣费动作和数据库 mutation 需要幂等与复核才能 replay。

第四个故障是质量漂移。把任务移到更便宜的模型或时间窗口，不应改变验收标准。该看 cost per accepted output，不只看 cost per token。

决策矩阵

如果你的任务是建议做法
在线且用户可见按延迟与可靠性路由，忽略峰谷折扣
离线且高吞吐排队到谷值窗口，使用 row ID，对账输出
离线但有 deadline在 deadline 阈值前等待谷值，超时后立即运行
质量敏感先保留强模型并利用谷值时间，再考虑降级模型
provider 风险敏感抽样备用 provider 并准备 fallback，不要把价格窗口当成可用性保障

最稳的省钱方式通常是组合几个杠杆。可移动的 DeepSeek 任务用谷值时间，真正 async 的大批量任务用 provider batch API，重复前缀用 prompt caching，可靠性边界交给 routing 与 fallback。

Sources

本文涉及的模型

帮助与联系