一张一万美元的账单:五种降低 LLM 成本又不让应用变笨的做法

每隔几周,r/LocalLLaMA 上就会出现同一类帖子。细节各不相同,但剧情永远一样:「月度账单来了,我才发现烧掉了一万美元。」 有时是失控的 agent 循环,有时是重试风暴,有时只是业务涨了。

另一类同样高频:「60% 的请求本可以用更便宜的模型,但所有流量都打到了最贵的那个,因为代码是这么写的。」

这两件事是同一种失败,而且不是定价失败,是可观测性与控制力的失败。账单是滞后指标:等财务转给你的时候,钱已经花掉了。而按 key 限流——大多数厂商控制台唯一提供的控制手段——对业务决策毫无用处。

如果你只是一个团队、调一家厂商、量也不大,你不需要这些东西:直接调 API 就好。但下面这些情况如果听着耳熟,那后面的内容就是给你的操作手册。

手段一:先搞清楚你在模型价格之外还付了什么

在优化任何东西之前,先查加价。

SaaS 聚合与中转服务通常在厂商自身费率之上再加一层平台费与支付费。这不合理吗?不,这是商业模式。但值得把它说清楚:在高推理量下,它是一笔持续支出,却没有换来你自己跑不了的东西。另一种形态是按实例的固定授权:你为网关软件付费,厂商按标准费率向你计费,Token 量翻倍也不会让软件费用变动。(披露:后一种正是 GateLLM 采用的方式 —— 2GB 的 Pro 实例 $400/月,不收 Token 加价。)这个判断与厂商无关:先搞清楚你用的网关站在「按 Token 计费线」的哪一侧。

手段二:分级路由 —— 真正改变数字的那一根杠杆

对多数团队来说,可用的最大一笔成本削减不是折扣,而是「每个请求跑对的模型」,而不是「所有请求跑同一个模型」。

生产流量并不是均匀地难。分类、抽取、摘要、格式化、工具参数构造,很少需要顶尖模型;而规划、模糊推理、长链路 agent 步骤则常常需要。分级策略——规划走顶尖闭源模型、执行走开源 SOTA——通常能让单任务综合成本变化一个量级,因为便宜的那一档吸走了量。

两个决定成败的实现要点:

• 路由决策必须按请求做,不能按部署做。 一个全局的「都用便宜模型」开关,迟早会被那 5% 难的流量打回原形。要按请求形态、计划模式或身份来判。
• 对客户端保持透明。 如果分级需要改应用代码,那它活不过下一次重构。把策略放进网关,客户端继续发同样的请求。

手段三:让 prompt 缓存可见,并审计它的计费

Prompt 缓存是性价比最高的一招,也是最容易悄悄失效的一招。反复出现的三种失效形态:

1. 缓存断点根本没设,于是什么都没缓存 —— 常见于客户端所用的协议本身没暴露缓存能力,或者没人加那个标记。
2. 缓存设了但没被计量,于是缓存读仍然按完整输入价计费,且没有任何可见性。
3. 缓存 Token 的统计在聚合层算错了,导致报表账单高于厂商实际收取的金额。

解法是把缓存读与缓存写做成计量里的一等公民:同样的单位、同样的归因,并且 per key、per team 可见。如果你没法在成本旁边看到缓存命中率,你就无法判断这项优化到底有没有生效。

手段四:给响应瘦身,而不是给模型降级

有一笔相当可观的开销花在没人读的输出 Token 上:模板化的开场白、被回显的重复上下文、调用方直接丢掉的冗长推理。输出 Token 是价目表上贵的那一侧,所以削它往往比降级模型更划算,而且不会损伤人类真正会看的那部分质量。

先从按端点统计「输出/输入比」开始。比值异常高的端点,通常就是改一下 prompt 或响应结构就能立刻回本的那些。

手段五:在账单之前做归因与硬闸门

活在电子表格里的成本管理是报表,不是控制。最小可用版本有三部分:

• 归因:每个请求都带上 key、团队或项目,让成本落到具体条目上,而不是一个共享大池子。
• 有牙齿的预算:阈值能降级或阻断流量,而不只是发告警。
• 实时可见:请求还在跑的时候成本就可见,而不是月底才看到。

「告警」与「阻断」的差别就是全部要点。失控的 agent 循环不会被一块仪表盘劝退。

从哪里开始

如果这周只做一件事:按端点统计一次「花的钱」与「产生的价值」之比 —— 哪些端点、团队和 key 在消耗预算,以及它们当中多大比例的流量真的需要所用的那个模型。这个数字本身通常就会告诉你第一根杠杆在哪。

这五根杠杆背后的模式其实是一件事:成本只有在变得「可归因」且「可实时执行」的那一刻才真正可控。其余的都是会计工作。