如何阻止失控的LLM API支出在调用发出之前（调用前预算执行）

大多数针对LLM应用的成本工具属于可观测性范畴：它们展示你已经花了多少钱。对于每周复盘很好，但对于失控循环毫无用处。重试风暴或卡住的代理可能在仪表盘更新之前的几分钟内就花掉数百美元。如果你真的想限制支出，检查必须在调用之前进行，而不是之后。我在被坑过之后总结出的模式是： 1. 先检查，后记录。每次调用提供商之前，问自己：“这会超出我的预算吗？”如果是，就抛出异常，绝不发起调用。如果否，则发起调用，然后记录实际的令牌数和成本。调用前检查保护你；调用后记录保持预算准确。 2. 你在调用前无法知道确切成本，因此要设定边界。输出令牌在返回响应之前是未知的。估算最坏情况：输入令牌（已知）加上你的 max_tokens 上限，乘以模型每令牌价格。用这个值比对窗口内的剩余预算。它会略微高估，这正是你想要的防护效果。 3. 调用后进行对账。当响应返回时，你得到实际使用量。用实际成本替换估算值，以便下一次检查准确。跳过这一步，预算就会漂移。 4. 有意识地决定故障开放还是故障关闭。如果你的预算存储慢或宕机，你是阻止所有调用还是放行它们？一个在临时故障时让整个应用瘫痪的防护通常比它要阻止的账单更糟糕。我采用故障开放模式，设置严格超时，并在防护不可用时发出警报。不要让库的默认设置替你决定。 5. 限定预算范围，不要使用一个全局数字。一个客户的失控循环不应阻塞其他所有人。按客户、按任务、按模型追踪支出，并在该级别设置上限。全局数字是用于财务报告的，而不是紧急开关。 6. 注意你增加的延迟。每次调用前的一次往返会累积起来。维护一个短期本地缓存或令牌桶，使常见情况保持在进程内处理，仅在接近限额时才访问真实数据源。 7. 硬限制与软限制。某些预算只需触发警报（你想知道某个任务支出达到了平时的三倍，但不想终止它）。另一些必须硬性停止（你卖给客户的按客户上限）。两者都要支持。 我遇到过的坑： * 流式传输在结束时报告使用量，因此你的“之后”步骤必须钩取流的最终事件，而不是第一个数据块。 * 提供商价格会变化；硬编码它们会导致估算过时。要同步更新。 * 并发问题：两个调用可能同时通过检查并都产生支出。对于硬性上限，扣减必须是原子操作，而不是先读取再写入。 我最终为此构建了一个小型开源库，以免每个项目都重做一遍，但这个模式本身是独立的；你可以用一个 Redis 计数器和一个定价表在一个下午内搭建起来。 其他人是如何处理估算与实际差异以及故障开放调用的？是按客户硬性阻止，还是仅发出警报并信任自己的代码行为？