TheRouter.aiTheRouter.ai
← 全部文章

用智能路由优化 LLM API 成本：2026 实战策略

一份面向工程团队的 LLM API 成本优化指南：用任务复杂度路由、fallback、prompt caching、batch 路径和预算护栏降低支出，同时避免“保证最低价”这类不真实承诺。

· TheRouter

30 秒答案：2026 年优化 LLM API 成本，最稳妥的方法不是把所有请求都打到“单价最低”的模型，而是把每类请求路由到成本最低的可接受结果：确定性低风险任务用低成本模型，高返工成本任务用更强模型，重复前缀用 prompt caching，离线任务用 batch API，provider 限流或故障时用 fallback 保住成功率。

这篇文章刻意比我们的 cost-per-outcome routing framework 更窄。那篇解释指标，这篇把指标落到可执行的路由策略。我们会保持克制：路由可以减少浪费，但任何 gateway 都不能保证每个 prompt、每个 provider、每天都是最低价。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

先拆出四个成本杠杆

LLM 成本通常由四件事决定：

  1. 模型选择：小模型或开源权重模型 token 单价低，但可能需要更多 retry。
  2. Provider 路径：OpenAI、Anthropic、DashScope、SiliconFlow 和 Google 的价格、限流、地域和缓存规则都不同。
  3. 请求形状：长 system prompt、大 tool schema、冗长输出、重复上下文，往往比模型本身更贵。
  4. 执行模式：实时、缓存、batch、fallback 的经济性完全不同。

只优化模型选择，容易得到一张看起来便宜、线上依然浪费的表。真正的目标是让四个杠杆都匹配工作负载。

用路由矩阵，而不是一个全局默认模型

我们通常先把流量分成四类，再讨论 provider 配置。

工作负载例子主要成本风险路由策略
简单确定性任务分类、抽取、标签清洗为简单任务过度付费低成本模型，限制输出长度
标准助手任务对话回复、客服草稿、摘要输出太长、上下文重复中档模型，结构化 prompt 以利缓存
复杂推理任务code review、agent planning、法律/财务分析retry 和人工审核成本优先更强模型，比较 accepted answer 的总成本
离线批量任务eval、数据 enrichment、文档回填为非实时任务支付实时价格使用支持的 provider batch API

这也是避免内容重复的边界：不要重讲 CPO 理论。这里真正要回答的是：每个 bucket 走哪条 provider/model 路径，什么信号触发切换。

策略一：按任务复杂度路由

任务复杂度路由最有杠杆，因为它同时避免两个极端：所有请求都用 frontier model，或者所有请求都压到便宜模型导致静默失败。

一个最小规则可以这样开始：

export function chooseRoute(job: {
  task: "classify" | "summarize" | "code_review" | "agent_plan";
  inputTokens: number;
  latencyTier: "realtime" | "offline";
  qualityRisk: "low" | "medium" | "high";
}) {
  if (job.latencyTier === "offline") return "batch-mid-tier";
  if (job.qualityRisk === "high") return "premium-reasoning";
  if (job.task === "classify" && job.inputTokens < 4000) return "low-cost-fast";
  return "standard-balanced";
}

在 TheRouter 中，可以保持 OpenAI-compatible API 形状，把这个决策放在发送到 base_url 的 model id 之前。真实能力表述很简单：TheRouter 可以把 OpenAI-compatible 请求路由到已配置 provider；当 live product path 支持时，可以做 provider/model routing 和 fallback。不要声称任何 route 一定最低价。

策略二：把 fallback 当可靠性保险

Fallback 省钱的前提，是它避免了失败工作，而不是机械跳到 token 单价最低的模型。一次实时请求失败，可能带来 retry、客服工单、人工绕路处理；这些都是成本。

适合 fallback 的场景包括：

  • provider 429 或 quota 用尽；
  • 临时延迟尖峰；
  • 特定模型 tool-call 失败；
  • 区域 endpoint 事故；
  • 高风险任务的 premium model 不可用。

安全的 fallback policy 应该写清业务目标：

{
  "primary": "premium-reasoning",
  "fallbacks": ["standard-balanced", "regional-backup"],
  "retry_budget": 1,
  "fallback_reason": ["rate_limit", "timeout", "provider_error"]
}

更完整的故障模式可以链接到 LLM API fallback routing guide 和 AI API rate-limit comparison。本文只保留成本策略，不重复解释所有 429 场景。

策略三：把重复上下文交给缓存

Prompt caching 是请求形状和路由经济性的交汇点。OpenAI 文档说明，近期模型的合格请求会自动使用 prompt caching，匹配精确前缀，并在 usage 中暴露 cached tokens；OpenAI Batch API 对异步任务提供 50% 成本折扣和 24 小时完成窗口。Anthropic 文档列出 cache write/read 价格、5 分钟和 1 小时 cache write，并提供 Message Batches API，价格为标准 API 的 50%。DashScope 文档列出 explicit context cache 的 125% 写入 / 10% 命中价格、implicit cache 的 20% cached input 价格，以及 OpenAI-compatible batch calls 的 50% 实时推理价格。SiliconFlow 则公开了每百万 token 价格、部分模型 cached input 价格和 RPM/TPM 等限流指标。

实现规则很朴素：稳定内容放前面。

GOOD: system policy + tool schema + repository summary + user question
BAD: user question + changing examples + system policy + tool schema

如果静态前缀很大，先测试 prompt caching，再考虑换 provider。如果任务不需要实时返回，先测试 provider batch path，不要直接支付同步价格。

策略四：用 stop-loss 规则做预算护栏

成本控制如果只在账单异常后提醒，就已经太晚。把 stop-loss 放进 routing layer：

  • 每条 route 的 max output tokens；
  • 按 route 和 error class 限制 retry 次数；
  • 按 tenant 或 workspace 设置每日预算；
  • 低风险流量超过预算阈值后自动降级；
  • 高成本 batch job 需要人工确认；
  • 记录 route、model、provider、cached_tokens、retry_count、accepted_outcome。

如果 TheRouter 的 live product path 已经提供 billing/accounting surface，就用它把 provider 账单和应用层 workflow 成本对齐。没有实现或没有验证的能力，不要写成承诺：记录自己的 route metadata，再与 provider usage export 对账。

一套实际 rollout 计划

先选一个 workflow，不要改全平台。

  1. 选择一个高流量、成功标准清晰的 workflow。
  2. 记录 7 天 baseline：token spend、retry rate、latency、人工审核时间、accepted outputs。
  3. 按上面的四类 bucket 分流。
  4. 一次只启用一个优化：model tiering，然后 caching，然后 batch，然后 fallback。
  5. 如果某条 route 降低 token 成本、但提高拒收率或人工审核时间，立即回滚。

关键指标不是“月度 API 账单下降”，而是“每美元 accepted outcome 上升，同时不破坏延迟和质量”。

2026 年 7 月 provider 备注

Provider优先测试的成本杠杆有来源支撑的 caveat
OpenAIautomatic / explicit prompt caching；Batch APIbatch 适合异步工作，完成窗口为 24 小时
Anthropiccache TTL；Message Batches APIbatch 是异步路径，部分参数不支持
DashScope区域化 Qwen 价格；context cache；OpenAI-compatible batchbatch 和 context-cache 折扣不能同时叠加
SiliconFlow低成本 open-weight route；cached-input 模型限流随模型和账号层级变化；免费模型限制固定
Google Geminicontext caching 和 batch（按当前可用性验证）上线前必须复核当前地区和模型价格

Production checklist

  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 小时，再正式切换。

把一条 cost-optimized route 标记为完成前，确认：

  • 每条 route 都有明确 workload bucket；
  • 每个 fallback 都有允许触发的 error class；
  • 文档里的价格表都有 retrieved date；
  • 缓存优化报告 hit rate，而不只是预期折扣；
  • 每个 batch job 都有 owner、最大输入文件大小和取消路径；
  • 每个 provider/model 能力声明都有 docs、code 或 live request evidence。

Sources

帮助与联系