你的 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 的用户并不是对抗性的。他们不是机器人。他们不是随机产生的。他们是那些粘贴巨型文档的用户，因为产品在真正重要的事情上帮到了他们。他们正在推特上讨论你的工作流。他们正在招募更多像他们一样的用户。
限制他们的使用有流失风险。不限制他们则有毛利风险。你上线时采用的固定费率定价，实际上是通过对中位数用户征税来悄悄补贴重度用户，而这种补贴对两者来说都是不可见的——重度用户认为产品定价合理，因为无论使用量如何，账单都保持不变；中位数用户认为自己获得了公平的价值，因为他们根本不知道长尾消耗了你多少成本。你正在自己的客户群中运行一套再分配方案，并用毛利为此买单。
凭直觉想通过使用限制来解决这个问题在原则上是正确的，但在执行上几乎总是错误的。在 p99 边界设立固定上限会摧毁那些最爱这个产品的人。在 p50 设立上限则会掩盖产品最引人注目的演示效果。现实的做法是将使用量转化为定价——将产品分层，让重度用户为他们提取的价值付费，并将消耗作为一项功能展示给客户，而不是作为一个账单惊喜。
弥合差距的准则 在生产环境的考验中幸存下来的模式通常如下：
将消耗量预测为分布，而非单一数值点。 将成本模型构建为基于历史 Token 追踪的蒙特卡洛模拟，而非简单的“用户人均 Token 数 × 用户数”。分别报告每位用户的 p50、p90 和 p99 成本。均值是一个派生统计数据，而非输入。将每用户预算作为一项产品功能显性化。 “你已使用本月额度的 80%” 这种提示能将账单惊喜转化为已知的限制。触达限制的客户有明确的下一步行动——升级、优化或接受上限——而不是等到财务部门上门质问的那天才发现成本超支。分层定价，从而捕获核心用户的价值，而非将其平均化。 免费层涵盖中位数用例，付费层涵盖重度用户场景，企业层则对长尾情况显式定价。其目的并非为了统一榨取更多收入，而是停止用核心用户群体去补贴长尾用户。无论输入形式如何，限制单次请求的 Token 消耗量。 用户粘贴 30KB 的内容表明他们有一个真实的问题。产品应当以有意的截断、摘要或分块来响应——并应告知用户做了什么，而不是静默丢弃上下文。每个租户的令牌桶（token-bucket）模式，通常辅以成本速率的熔断机制，是常用的运营机制。针对重长尾（heavy-tail）输入评估产品。 试用用户不会触发长尾用户才会遇到的故障模式。评估套件应将“巨量文档粘贴”、“千次对话”以及“格式错误的上下文”作为一类场景。如果产品在 p99 处崩溃，你会从推文（Twitter）中得知，而不是从评估报告中得知，这完全搞错了操作顺序。 账单背后的组织失败模式 这种情况不断发生，并非因为某个团队犯了错。产品团队根据试用阶段产生的数据为功能定价，而那是他们当时拥有的唯一数据。财务团队根据产品团队的预测来建模销售成本（COGS），而那是摆在桌面上的数字。工程团队构建产品来处理试用中出现的输入，那是他们观察到的输入分布。账单寄到时，没有任何团队的路线图中包含“为试用阶段无法展示的分布长尾建模”。
这种差距是结构性的。试用产生一种特定证据——对验证产品市场匹配度（PMF）有用，但对单位经济效益（unit economics）无用。将试用数据视为预测输入而非合理性检查是根本错误，而且这很容易发生，因为在发布时，试用数据是唯一的参考。那些发布 LLM 功能而没被灼伤的团队通常会做两件事：要么采取防御性定价，假设生产环境的分布会是试用期的好几倍；要么发布时带有使用上限，并在观察到长尾的真实形态后收紧或放开。
这两者都不需要预测天才。它们要求将试用视为成本的下限而非中心估算值，并接受一个事实：第一个真实的成本预测是在生产环境发布 30 天后，当你系统中有了真实用户时才写出来的。
重长尾是产品本身，而非噪音 结束这一切的架构认知可能令人不适，但值得明确表述。处于 Token 消耗量 p99 的用户并不是需要通过设计绕过的异常值。他们正是你产品所服务的用户，只是以对他们重要的体量表现了出来。用户粘贴 30KB 内容是在以最清晰的方式表达“这个产品对我很有用”。将这些用户视为边缘情况的成本模型误读了产品。
针对中位数用户定价的 Token 预测，定价的是那些随手试用产品的用户。针对均值定价的 Token 预测，定价的是一个不存在的用户。而针对分布定价的 Token 预测——了解 p50、p90 和 p99 用户的成本，并将定价结构与该形状匹配——定价的才是真实的业务。
消费级互联网公司在 2010 年代学到的关于参与度、留存和收入分布的教训，在这里同样适用，甚至节奏更快。核心用户（Power users）是需求信号。账单是以固定费率承保他们的成本。及早意识到这一点的团队会在长尾形成之前构建定价界面和消耗限制。意识到晚了的团队则会在经历毛利恐慌后才行动，而且每拖一个月，与财务部门的谈话就会变得愈发艰难。
针对分布定价。中位数用户从来不是业务的核心。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
