你的 Token 预测从未考虑过的重尾效应

你的 AI 功能成本预测是基于一个 50 人的试点项目建模的。那些用户输入了三句话的提示词，因为那是人们在被要求评估测试版时通常会输入的内容。产品上线了，你突破了一万名用户，财务团队指出你的模型账单是计划书中人均成本的三倍。你去寻找 Bug。但根本没有 Bug。你的试点项目是从一个分布中采样，而生产环境是从另一个分布中采样，两者的区别在于一个长尾用户群——他们是在 Twitter 上了解到你的产品，并粘贴了从推文中截取的 30 KB 非结构化上下文。

这是每家消费级互联网公司在 2010 年代都吸取过的同样财务教训，现在被移植到了 LLM 经济学中。试点项目的中位数用户并非生产环境中的 p99.5，而一个使用平均值作为预测输入的 Token 成本模型，在面对账单时注定会一败涂地。

试点项目在结构上无法向你展示长尾

一个 50 人的试点项目没有重尾。它不可能有。生产环境中的 Token 消耗形状是一个分布，其 99.5 分位点比中位数高出几个数量级，你需要数万个样本，长尾才会出现在数据中。试点用户不是长尾。他们是团队的朋友、设计合作伙伴、由产品经理引导进入漏斗的测试人员，以及工程师的配偶。他们的行为方式一如既往：礼貌、简洁，且处于演示的理想路径之内。

生产环境与试点项目的不同之处体现在三个方面。首先，规模大到足以让长尾真实存在。其次，获客结构发生了变化——现在涌入的人是在社交媒体上读到你的，看了 YouTube 演示，或者是从同事那里收到了链接，同事说“试试这个来处理你要面对的巨型文档”。这是一种自选择机制，使得第一批输入的用户就是那些带着最困难任务的人。第三，没有人盯着他们。试点用户是为招募他们的团队而表演的。生产环境的用户则会为了达到目的而不择手段，这通常意味着直接将整个 PDF 粘贴到提示词中，因为那是阻力最小的路径。

那个根据试点平均值定价的团队在技术层面并没有犯预测错误。试点数据是准确的。只是它采样了错误的分布。

分布是重尾分布，而非正态分布

每个用户的 Token 消耗遵循幂律形状，而不是钟形曲线。极少数用户消耗了大部分 Token。从业者报告的比例显示，前 1% 的用户占总 Token 支出的 30% 到 50%，而中位数请求与 p99.5 请求之间的差距可达两到三个数量级。发往同一个端点的两个请求在资源消耗上可能有天壤之别——一个 50 Token 的提示词和一个 1 万 Token 的提示词都被计为一个请求，但计算成本却截然不同。

重尾改变了“人均成本”这个 KPI 的实际意义。如果你的团队报告平均值，你报告的是一个真实用户根本不会产生的数字。中位数用户的成本只是平均值的一小部分。平均值被长尾拉高了，而平均值背后的方差才是造成实际财务损失的原因。每个月，财务部门都会对预测与账单之间的差距感到惊讶，这并不是因为平均值发生了漂移，而是因为平均值所隐藏的方差现在显现在了发票上。

正确的操作框架是将消耗建模为一个分布，并根据分位数而非点位来做决策。你的 p50 用户成本是多少？p90 是多少？p99 呢？成本预测应该是一条曲线，毛利问题在曲线上的每一个点都是不同的问题。

重度用户也是 LTV 最高的用户

这一部分将单位经济效益从数学问题转变为战略问题。那些大量消耗 Token 的用户并不是对抗性的。他们不是机器人。他们不是随机产生的。他们是那些粘贴巨型文档的用户，因为产品在真正重要的事情上帮到了他们。他们正在推特上讨论你的工作流。他们正在招募更多像他们一样的用户。

限制他们的使用有流失风险。不限制他们则有毛利风险。你上线时采用的固定费率定价，实际上是通过对中位数用户征税来悄悄补贴重度用户，而这种补贴对两者来说都是不可见的——重度用户认为产品定价合理，因为无论使用量如何，账单都保持不变；中位数用户认为自己获得了公平的价值，因为他们根本不知道长尾消耗了你多少成本。你正在自己的客户群中运行一套再分配方案，并用毛利为此买单。

加载中…