为什么你不能用单一数字来估算 AI 功能的预算

财务部门对你发布的每个功能都会问一个问题：“每个用户的成本是多少？”对于传统功能，答案是一个数字。页面渲染、数据库查询、推送通知 —— 每一个的边际成本在不同请求之间几乎没有波动。你测量一次，乘以用户数量，预测就能成立。

AI 功能打破了这种契约。问一下“这个智能体（agent）每次请求的成本是多少”，坦诚的回答不是一个数字，而是一张直方图。同一个智能体，处理上一个工单可能只花 2 美分，但在处理下一个工单时可能会烧掉 4 美元。因为用户问了一个模糊的问题，智能体循环调用了 11 次工具，而每次调用都将不断增长的对话全文重新输入模型。这两次请求的平均值 —— 2 美元 —— 既无法描述其中任何一次请求，更无法真实反映最终账单。

这就是陷阱。当你向财务提交一个单一的平均成本时，你并不是在简化混乱的现实。你是在报告一个在特定的、昂贵的方向上完全错误的数字。

单次请求成本是肥尾分布

普通功能的单次请求成本紧密围绕其平均值。如果你将其绘制出来，你会得到一个狭窄的尖峰。平均值是一个忠实的总结，因为几乎每个请求的实际成本都接近平均值。

智能体功能则不然。其成本由循环深度决定，而循环深度是非确定性的。智能体进行推理、调用工具、观察结果、再次推理 —— 每一步都会针对完整的累积上下文产生按 token 计费的模型调用。朴素的智能体循环以大约 O(N²) 的速度复合成本，因为 API 在每一轮对话中都会对整个对话历史收费。简短的交互只触及模型几次。而长交互 —— 目标不明确、检索密集型查询，或是一个反复返回噪点导致智能体不断重读的工具 —— 在结束或放弃之前可能会触及模型数百次。

画出图表，你得到的不是尖峰。而是一个带有长而沉重的右尾分布：大多数请求很便宜，但有一小部分请求极其昂贵。昂贵部分的数量虽少，但在支出中占主导地位。在多租户 LLM 产品中，从业者一致报告了相同的形态 —— 几个百分点的租户消耗了绝大部分 token。某个客户悄无声息地烧掉你大部分 token 预算并不是一个需要防范的边缘案例。除非你针对它进行监测，否则这就是默认的结果。

当分布具有重尾特征时，平均值不再是典型情况的衡量标准，而变成了对尾部的衡量。它被极少数昂贵的请求向上拉动，因此它夸大了普通用户的成本 —— 与此同时，它又完全隐藏了尾部，因为“平均 2 美元”无法给财务任何提示，告知某些请求的成本是该数字的 40 倍。这个单一数字同时在两个相反的方向上出错。

为什么平均化会破坏容量规划和定价

由误导性的平均值造成的损害并非抽象概念。它会体现在三个具体方面。

预测。 建立在平均单位成本上的预算假设下个季度看起来就像本季度的等比例缩放。但尾部不会随着用户线性增长 —— 它随着任何改变请求组合的因素而增长。发布一个鼓励开放式问题的功能、接入一个拥有复杂数据的大型企业客户，或者更改提示词让智能体进行更多重试，尾部就会变厚，而你的平均值在发票寄达之前几乎纹丝不动。这就是为什么调查一再发现，绝大多数企业都严重偏离了其 AI 基础设施预测 —— 而且偏差极大，绝非舍入误差。他们预测的是一个点，得到的却是一个分布。

定价。 在肥尾成本之上采用统一的按席位定价是一种结构性赌博，赌的是你的便宜用户永远在数量和资金上超过你的昂贵用户。尾部决定了这场赌博是否能赢。如果 3% 的账户驱动了 60% 的 token 支出，你真正的核心问题不是“平均利润是多少”，而是“第 97 百分位用户的利润是多少，其他客户的收入能否覆盖他们”。平均成本无法回答这个问题。它将补贴者和被补贴者混为一谈，得出一个无法描述任何实际客户且悄悄隐藏了利润漏洞的数字。

容量和毛利。 基础设施必须吸收峰值并发负载和长会话尾部，而不是平均值。如果按平均值进行配置，那么当多个重型会话重叠时，你就会面临配置不足的情况。毛利率的表现也是如此：中位数请求的利润是健康的，但在尾部则是亏损的，只有百分位级别的可见性才能告诉你综合结果是否能盈利。

应该报告什么：p50、p99 以及决定账单的尾部

停止报告单一数字。报告分布形态。以下三个指标包含了大部分信号：

• p50（中位数）。 一个真正典型的请求花费多少。这个数字应该驱动按席位定价和“此功能是否健康”的直觉判断 —— 并且它几乎总是低于平均值，因为尾部会将平均值拉离中间位置。
• p99。 昂贵但非病态的请求花费多少。这是容量规划和最坏情况预算应该使用的数字。p50 和 p99 之间的差距是衡量功能不可预测性的最佳单一指标。
• 总尾部支出。 前 1% 的请求在整个账单中所占的份额。如果 p99 是 p50 的 30 倍，且前 1% 的请求占支出的 40%，那么你遇到的不是成本问题 —— 而是尾部问题，这会告诉你具体的优化方向。

加载中…