降低LLM账单：先定位开销再分流

LLM API 账单降不下来，未必是模型选贵了，也可能是 Agent 一直循环、脚本反复发送整份文件，或者长对话不断累积上下文。作者提出六个方向：拆账单、给简单任务换模型、保持缓存、限制每个 key、使用批处理，以及减少输入输出。

其中最有用的判断是：自动路由不一定省钱，切换模型甚至可能破坏缓存。这篇适合拿来检查自己的调用链，但价格和产品能力都来自作者陈述，不能当成已经验证过的省钱报告。

先找出谁在花钱，再决定要不要换模型

作者建议先把上个月的账单按模型、API key 和工具拆开。目的不是平均削减每一项，而是找到最贵的那一两项：失控的 Agent、每次上传整份文件的脚本，或者用顶级模型回答简单问题的工具。

输入和输出也要分开看。按原文列价，GPT-5.5 每百万输入 tokens 为 $5，输出为 $30，后者是前者的 6 倍。如果任务只需要一句结论，却让模型写长篇解释，只压缩输入未必能解决主要开销。

长对话还有累积成本。作者指出，每条消息都会重新发送此前的对话，因此第十条消息通常比第一条携带更多内容。具体账单还受缓存影响，但旧上下文不会因为已经聊过就自动免费。

简单问题、重命名、短摘要，可以先交给便宜模型。作者推荐的 FUSR.ai 路由入口是 fusr/auto，开启 cheapest-good-enough 后，会选择被评为足够胜任该任务的最便宜模型。

问题在于，「足够胜任」怎么评，原文没有展开，也没有提供准确率、失败重试或成本对照。文中虽然提到要比较模型价格，却没有给出完整价格表，不能据此计算路由能省多少。

先用一个强模型搭配一个便宜模型，往往比直接引入复杂路由更容易评估。

如果已经在用便宜模型，或者几乎所有请求都是难题，路由本来就没有多少降价空间。

缓存是否命中，可能比单次模型价格更重要

提示缓存（prompt caching）可以理解为：请求开头有一段近期处理过的相同内容，服务商就有机会按更低价格读取它。系统提示、固定文件、对话前半段，都可能成为可复用的前缀。

原文给出的价格关系是：

• Anthropic 通常按输入价格的十分之一收取缓存读取费用，Sonnet 5.5 和 Opus 5.5 为二十分之一；缓存写入则比普通输入贵 25%。
• OpenAI 自动处理缓存，GPT-5.5 每百万缓存输入 tokens 为 $0.50，普通输入为 $5。
• xAI 同样自动处理缓存，Grok 4.7 每百万缓存输入 tokens 为 $0.50，普通输入为 $2。

这些是原文更新于 2026 年 10 月 27 日时列出的信息，实际接入仍应以对应服务商的计费规则为准。

要让缓存发挥作用，作者强调三个习惯：不要在同一段对话中频繁换模型，不要把时间等变化内容放在系统提示开头，也不要假设缓存会永久保留。原文称，闲置几分钟后缓存就可能过期，但没有展开不同服务商的有效期规则。

切换模型尤其容易被低估。每个模型有自己的缓存，换到便宜模型后，原来的缓存未必能继续使用。省下的模型差价，可能抵不过重新处理上下文的费用。

FUSR.ai 声称会为 Anthropic 请求设置缓存标记，让对话尽量留在缓存已预热的模型上，并按实际 token 数和列价展示节省金额。这是产品能力描述，原文没有给出实际请求报告来验证效果。

预算上限、批处理和少发送，各自解决什么问题

每个 key 的额度限制，解决的是意外支出。组织或项目预算覆盖面较大，按 key 限制则可以让每个工具、每位成员拥有独立额度，触顶时只停止对应 key。

原文称，FUSR.ai Free 提供其 key 的月度上限，Pro 和 Team 支持每个 key 的每日、每月上限，并可设置金额提醒。这里要分清：提醒负责通知，硬上限才负责停止继续花钱。

能等待的任务，则可以换一种执行方式。OpenAI 和 Anthropic 的 batch API 面向最多可等待一天的任务，价格为普通调用的一半，适合积压数据打标签、运行评测。FUSR.ai 不路由 batch 任务，需要直接调用服务商。

剩下的做法很朴素：话题变了就新开对话，只发送相关文件片段，为短答案设置最大输出长度，并保持系统提示简短、稳定。它们减少的是每次请求实际携带和生成的内容，不依赖路由判断是否准确。

我的判断

这篇最成立的地方，是把成本拆成了几个可分别处理的问题。模型单价、上下文体积、缓存复用、异常调用和任务时效，不能只靠「换个便宜模型」一起解决。

但它也带有明确的产品推广立场：作者就在 FUSR.ai 工作。原文没有团队实测、优化前后账单，也没有与直接调用服务商、手动选择双模型方案的对照。因此，关于路由收益的结论属于经验建议，不能替它背书。

FUSR.ai 声称不在 token 价格上加价，服务商直接向用户自己的 key 计费，但这不足以说明整体使用成本；原文没有给出订阅费用。它也明确不承诺省钱，不支持路由 batch、embeddings 或 image endpoints。评估时应把这些边界一起算进去。

能拿来做什么

• 给 Node 服务或 AI 编程工具记录模型、key、输入输出 token 数及任务类型，先找出费用最高的调用，再决定优化顺序。
• 把短摘要、简单问答与复杂代码任务分开，用固定任务样本比较便宜模型和强模型；把失败后的重试成本也计入结果。
• 检查提示词拼接顺序，将稳定内容放在前面，并为短答案设置最大输出长度；同一任务中减少没有依据的模型切换。
• 给脚本和 Agent 分配独立 key 并设置额度上限；对不要求即时返回的批量标注、评测任务，评估直接使用服务商 batch API。