六个杠杆：不换模型降低LLM账单

页面上每个结论都是用自己的数字做的算术，不是从别人 workload 里抄来的百分比。这样做是有意的：每个杠杆的贡献占比完全取决于你的流量特征，借来的百分比弊大于利，因为它设错了优先级。

先找到账单的形态

四个数字决定了哪些杠杆可能有用。在拿到这四个数字之前，下面什么都没必要看。

每个 prompt 模板，在一个代表性周内：

  N        请求数
  P        平均 prompt token 数
  O        平均 completion token 数
  p_in     每个输入 token 的价格
  p_out    每个输出 token 的价格
  r        每个被服务请求的尝试次数（重试 + 故障转移），>= 1.0

  spend  =  N * r * (P * p_in  +  O * p_out)

两个比率决定一切：

  output_share = (O * p_out) / (P * p_in + O * p_out)
  repeat_share = (r - 1) / r

如果 output_share 很高，杠杆 2 和 3 占主导。
如果 P 很大且在请求间重复，杠杆 1 占主导。
如果 r 明显高于 1.0，杠杆 4 是白送的钱。

输出 token 通常比输入 token 贵好几倍，所以一个长 prompt 短回答的 workload 和一个短 prompt 长回答的 workload 需要截然不同的工作。先算 output_share 再选策略。

杠杆 1：停止为反复发送的上下文付费

任何带有稳定前缀的系统——系统 prompt、工具 schema、 few-shot 块、或很少变化的检索语料——每次请求都会重新发送相同的 token，且每次都付全价。Prompt 缓存让这些重复 token 在首次调用后以更低价格计费。

设  P = P_fixed + P_variable
     c = 固定部分的缓存价格倍率（provider 相关，命中缓存时通常有大折扣）
     h = 缓存命中率

  before = P * p_in
  after  = P_fixed * p_in * (1 - h + h*c)  +  P_variable * p_in

  输入端节省比例 = (P_fixed / P) * h * (1 - c)

算例（用你自己的数字标注）：P_fixed 6,000，P_variable 400，
h 0.9，c 0.1
  P_fixed / P = 6000 / 6400 = 0.9375
  输入端节省 = 0.9375 * 0.9 * 0.9 = 0.759  -> 输入账单享 76% 折扣

三个条件决定你能否拿到那个折扣。固定部分必须每次都排在消息数组最前面、字节完全一致；缓存不能因为某个每次请求都变的字段被塞进了前缀而失效；命中率必须是实测的而不是假定的。顺序是人们最常搞错的——缓存排序和缓存实际节省了什么这两篇文章都涵盖了。

杠杆 2：限制输出，因为输出是昂贵的那一半

输出每个 token 单价更高，而且通常占账单更大比例，也是最容易被没人要的东西膨胀的线条：重复问题、道歉式前言、刚说完内容的摘要。

  节省 = N * r * (O_before - O_after) * p_out

算例：N 200,000/月，r 1.0，p_out 每 token $0.000010
  O_before 700，O_after 420（格式规范带来 40% 缩减）
  节省 = 200,000 * 280 * 0.000010 = $560/月

O_after 来自哪里，按大致占比排序：
  - 一个反映真实答案长度的硬 max_tokens
  - 一个没有前言字段的 schema
  - "只回答 X" 加上一个示例，效果远好于单独一条指令
  - 删掉 "解释你的推理"，如果没有人在读的话

设置最大 token 限制是截断而不是压缩。如果模型本来要写 700 个 token，限制在 420 只能得到 700 token 答案的前 420 个，这是另一种失败。限制只是兜底；schema 和指令才是真正缩短它的东西。控制输出长度涵盖了这个区别。

杠杆 3：把简单的多数路由到更便宜的模型

大多数 workload 有一个大的简单多数和一个小的困难尾端，但两者都发到同一个模型。级联把所有请求先发到便宜模型，只有通过检查的才升级到贵的。

设  f = 升级到昂贵模型的请求比例
     C_cheap，C_exp = 各模型每次请求成本

  cascade = C_cheap + f * C_exp
  盈亏平衡点 f*（cascade = C_exp 时）：
     f* = 1 - (C_cheap / C_exp)

算例：C_cheap $0.0004，C_exp $0.0090
  f* = 1 - 0.044 = 0.956
  -> 除非升级超过 96% 的流量，否则级联更便宜
  当 f = 0.20：cascade = 0.0004 + 0.0018 = $0.0022（节省 76%）
  当 f = 0.50：cascade = 0.0004 + 0.0045 = $0.0049（节省 46%）

盈亏平衡点比大多数人的预期宽容得多，这就是为什么级联通常值得一试。有两个成本没算进那个算式，必须加上：失败的那次便宜尝试的延迟是升级请求支付的，以及升级检查本身如果有模型调用的话也有成本。确定性检查——schema 验证、置信度阈值、正则表达式——让算式保持诚实。模型级联有完整攻略。

杠杆 4：停止为重试付双倍的钱

这是页面上唯一一个不是权衡而是纯粹浪费的杠杆，也是成本工作中最常被遗漏的，因为它在按请求计费中是不可见的。

  浪费 = N * (r - 1) * cost_per_attempt

算例：N 200,000，r 1.18，cost_per_attempt $0.0031
  浪费 = 200,000 * 0.18 * 0.0031 = $112/月，什么都没买到

r > 1.0 来自以下情况：
  - 重试确定性错误（坏的 schema 每次尝试都以相同方式失败）
  - 重试一个账户已用完额度的 provider，有些 provider
    用看起来像临时状态的 status code 来表示这个
  - 客户端库默认重试好几次叠在你的重试循环上，
    是相乘而不是相加
  - 触发故障转移到更贵的路由，而便宜路由也会有同样故障

两个修复，都很便宜。重试前先分类错误，这样永久失败的请求根本不会重试——参见生产环境 LLM 错误分类。用幂等 key 这样竞态慢成功的重试不会买两次相同的 completion；安全重试涵盖了形态。

杠杆 5：把非交互式的请求批处理

Provider 通常提供一个有长 completion 窗口的大幅折扣异步层。任何没有人等待的 workload 都适用：夜间回填、分类、 enrichment、评估运行。

  节省 = N_async * cost_per_request * discount

问题不在折扣，而在 N_async。逐个调用点审计：
这个特定响应有人在等吗？

  用户面对的聊天              -> 否
  搜索结果摘要                -> 否
  夜间重新分类                -> 是
  摄入时 enrichment           -> 是（如果摄入对用户不可见）
  评估套件运行                -> 是，而且通常占比不小

评估套件是团队最常忘记的那个。夜间运行的回归集是纯批处理 workload，通常占总费用中不可忽略的比例。批处理折扣解释了权衡。

杠杆 6：删掉没人读的调用

许多系统中最大的单项节省根本不是优化。逐调用点插桩——不是按模型，不是按端点——然后问每个结果被谁消费了。

没人展示的推理。问模型解释自己的 prompt，其解释被丢弃了，在为没人看到的 token 付输出价格。

预生成。页面加载时生成的摘要、建议和标题，而用户可能根本不会打开那个内容。按需生成并缓存结果。

管道中的重复工作。两个阶段都从同一文档提取相同实体，因为他们是不同的两个人写的。

没人用的功能。它的推理通常只占其总成本的一小部分，但推理是你今天就能停掉的部分。完整账单在无用 AI 功能的真实成本里。

逐调用点归属是那个建起来很别扭、但却是本页所有东西的前提的部分。Multigrid 用你自己的标签记录每个请求的成本，所以"这个调用点花了多少钱"是一个查询而不是一个项目。

执行顺序

先做杠杆 4。它是纯粹浪费，不需要质量权衡，而且错误分类你本来就应该做。

然后做杠杆 6。删掉一个调用是唯一没有持续成本、没有回归风险的变化——针对仍在发生的工作。

然后如果 P_fixed / P 高就做杠杆 1，如果 output_share 高就做杠杆 2。你在开头算的两个比率决定选哪个。

然后做杠杆 5，那是配置和调度而不是模型工作。

杠杆 3 最后做，因为它是唯一一个可能改变输出质量的，而且安全地做它需要一个评估集。

验证节省真的落地了

成本工作有一个异常高的"已上线、已相信、什么都没做"的变化率。四个检查，每一个都抓到过没有产生节省的变化：

比较每单位工作的成本，而不是总支出。总支出随流量移动，所以 25% 流量增长期间的 20% 节省看起来像倒退，而安静一周里一个什么都没做的变化看起来像胜利。除以完成的任务数。

直接检查缓存命中率，而不是账单。一个静默失败的缓存变更——某个每次请求的字段被塞进了前缀、顺序变了、prompt 编辑移动了固定块——产生完全相同的响应却收完全一样的旧价格。如果你的 provider 报了缓存 token 数，那个数字就是验证；如果没有，拿实现的输入 token 价格和标价对比。

每次变更后观察每个被服务请求的尝试次数。一些节省是靠重试次数上升来支付的。更便宜的模型如果更频繁地无法通过 schema 验证，或者更小的 token 限制截断了内容并触发修复轮次，总成本可能更高而每次调用看起来更便宜。

重新运行评估集。除了杠杆 4 和 5，每个杠杆都可能移动质量，而降低输出的节省是价格变化，不是优化。记录分数时同时记下成本，这样两者之后可以对比。

一个结构性要点让这四个都更容易：按调用点而不是按模型归属成本。按模型汇总无法回答一个变更是否有效，因为单个模型服务多个调用点，每个有不同的 prompt 形态，你改的那个被平均掉了。

这些在你的 workload 上能不能总计 80%，不是这个页面能告诉你的，任何给出的数字都是编的。用你自己的数字花一个下午做算术，会在你实施任何东西之前给你一个真实的总数。降低 LLM 成本有更广泛的技术目录。