那个在 11 小时内烧光你季度推理预算的免费试用

你的试用版提供了“每天 100 次生成”。你的定价团队模拟了一个感兴趣的用户花一周时间进行体验。但第一个将智能体（agent）指向端点的试用者，在 70 秒内就用完了当天的配额，19 分钟内用完了每周配额，并在第二天午餐前耗尽了季度的推理预算。没有人收到警报，因为唯一设置的警报只在试用用户转化为付费用户时才会触发。

试用限制在制定时并没有错。它们针对的是不再适用于当前典型用户的用法分布。在六个月前的定价审查与今天早上的新用户注册之间，用户群体已经从点击按钮的人类转向了不知疲倦的程序。仪表盘上的数字不再代表你设定它们时的含义。

你统计的单位是错误的

行业内几乎所有的试用上限都是按请求、生成次数或会话来计算的。当每个单位都受限于人类的耐心时，这些单位是有意义的：一个人每小时只能发起有限的操作，且每个操作在后端成本上大致稳定。这个单位是支出的可用代理指标，因为“一次生成”与一美元推理成本之间的关系在数量级内是稳定的。

这种稳定性已经不复存在。现在的“一次生成”可能是一个成本仅为几分之一美分的单次补全，也可能是一个包含 50 个步骤的智能体循环——它检索四个文档、调用三个工具、生成一千个 token 的计划、执行计划、观察结果、重新规划，最后产生一个一万个 token 长的答案。两者都被计为一次生成。来自生产部署的报告显示，对于五步循环，智能体路径的成本大约是对话的三倍；在 50 步时，倍数超过 30 倍；在 200 步时，倍数达到 100 倍。你用旧单位计算的“每天 100 次生成”试用上限，现在是一张无法约束实际支出出现两个数量级波动的空支票。

解决方法是按你实际支付的单位来设定上限。消耗的 token 数、调用的工具次数、执行的检索操作以及占用的计算秒数，都是随成本等比例变动的计量单位。虽然对非技术背景的试用者解释这种计费方式更难，但另一种选择是向 CFO 解释预算超支——因为没人设置席位级限制，CFO 会看到那些关于公司意外向单一供应商支付 5 亿美元的新闻报道。

故障模式是无人察觉的分布偏移

如果你在三年前绘制一份每位试用者支出的直方图，它会有一个长尾，但形状清晰可辨：众数接近于零（注册后从未回访的人），中间有一个小起伏（活跃的评估者），以及一个由重度用户组成的细长尾部。尾部的宽度决定了你每个注册用户需要预算多少。容量规划之所以有效，是因为分布是稳定的。

现在的分布在零处有同样的众数，有同样的中间起伏，但尾部已经脱离了主体。少数试用者现在的消耗量被你的计费模型视为异常值，但实际上它们属于一个独立的集群：每分钟执行数千次操作、持续数小时，且仅在配额限制时才停止的程序化用户。运行大规模集群团队的报告是一致的：前 5% 的用户通常消耗了 50% 到 70% 的推理支出，而且这个比例在没有任何人干预的情况下每季度都在增长。

危险不在于这种分布的存在，而在于安全系统是针对旧形状设计的。“每用户软上限”的大小是为了容纳人类分布的长尾，但与程序化分布的长尾相比，前者微不足道。“异常检测器”被调整为标记前 1% 的用户，这意味着它现在会标记程序化集群中的所有人，由于没人能处理这么多警报，最终导致没人处理任何警报。反欺诈团队对“滥用”的定义早于智能体的出现，并不符合一个合法但昂贵的智能体用户的行为特征。

日上限不是周上限，两者都不是真正的限制

常见的试用设计是将日上限与没有周或季度上限相结合。隐含的假设是，达到日上限的人类会去睡觉，直到明天才回来，因此日上限也大约等于周上限。这个假设对人类成立。但在许多部署中，一个在早上 7:01 达到日上限的智能体，会在下一个配额窗口开启时立即重试，并在另外 70 秒内耗尽第二天的配额。连续七天如此，就是每周预算。连续九十天如此，就是季度预算。这不需要任何特殊的滥用，只需要一个会重置的配额窗口。

缓解措施是分层上限：设置一个用于短期爆发控制的日上限；一个小于七倍日上限的周上限（因为连续七天满额运行本身就是一种异常）；以及一个季度防滥用上限（除了你现在正防御的特定故障模式外，没人会触发它）。每一层都捕捉不同形态的过度消耗。每一层也很容易被遗忘，因为显示每日用量的仪表盘很少会显示滚动窗口，而滚动窗口能揭示某个试用者在第三天就已经达到了周上限的 95%。

加载中…