动态定价下的LLM预算保护设计

大多数 AI 成本防护机制都基于一个假设：

你在发起请求之前就知道价格。

对大多数 LLM API 来说，过去确实如此。

但随着推理市场引入动态定价，这一假设正变得越来越不成立。在这种市场中，不同提供商会竞争请求，最终价格要到运行时才能确定。

这带来了一个很有意思的工程问题。

传统的预算防护机制

典型的调用前预算检查很简单：

• 查询模型价格。
• 估算 token 用量。
• 估算请求成本。
• 与当前 session 的剩余预算进行比较。
• 允许或阻止请求。

当价格固定时，这套机制非常有效。

但如果最终价格要等请求完成后才能知道，效果就没那么好了。

有两种显而易见的处理方式。

忽略价格的不确定性

这等于放弃了成本防护机制存在的一个主要理由。

始终按标价计算

这样做很安全，但往往过于保守。最终你会拒绝一些原本完全可以在预算范围内完成的请求。

预留最高金额，再按实际费用结算

一种借鉴自云基础设施的模式要有效得多。

与其估算精确成本，不如预留你愿意支付的最高金额。

interface SpotRequest {
  maxBidPerMillion: number;
  estimatedInputTokens: number;
  estimatedOutputTokens: number;
}

预留最坏情况下的支出。

如果这笔预留金额超过 session 预算，就拒绝请求。

请求完成后，用实际收取的金额替换预留金额。

将未使用的预算释放回 session。

这里最重要的特性是：你的预算永远不会在任何时刻被虚增。

预算执行变得确定

采用这种方式后，防护机制不再问：

这个请求会花多少钱？

而是问：

这个 session 能否承担我们愿意支付的最高金额？

这个问题在请求离开你的进程之前就可以得到答案。

出价上限成为另一种优化工具

一旦引入可接受的最高价格，这个上限就可以成为路由策略的一部分。

• 低价值分类任务 → 较低的出价上限
• 代码审查 → 中等出价上限
• 架构任务 → 较高的出价上限

随着 session 预算逐渐减少，这些上限也可以变得更加保守。

当资金不足时，你的系统不必只是简单地拒绝请求，而是可以自动提高选择标准，更谨慎地决定哪些任务值得付费。

今天面对的是现货定价的推理服务。

未来还可能是：

• 动态提供商市场，
• 特定区域定价，
• 或者跨多个提供商的实时路由。

它们的共同模式都是：

发送请求之前，精确价格不再能够得到保证。

这意味着运行时成本控制机制也需要随之演进。

它们不应继续假设每个请求都有固定价格，而应该被设计成能够在不确定性下运行——使用可接受的最高成本执行预算约束，然后在请求完成后根据实际价格进行核算。

对于 AI 基础设施看起来正在迈向的方向而言，这是一种灵活得多的架构。https://github.com/salimassili62-afk/ai-costguard

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。