LLM开销拆解公式：U×a×s×r×c

总成本不是预测的正确指标。它会随着产品成功而上涨，这本身不能说明任何问题。应该预测每个活跃用户的成本，这样总额会从你已经有的增长计划中自然推导出来。

推理成本可以分解为五个因子的乘积，公司里每个人都能够估计或测量其中至少一个：

monthly_spend = U * a * s * r * c

  U  产品月活跃用户数
  a  其中真正使用了 AI 功能的用户占比
  s  每个参与用户每月的 AI 会话数
  r  每个会话的模型请求数
  c  每次请求的平均成本（来自按请求计费模型）

而真正需要追踪的数字是：

  cost_per_engaged_user = s * r * c

把这个公式保持为一条链而非一个单一的人均美元数字，原因是每个因子都有不同的负责方和不同的杠杆。a 和 s 随产品决策变化——把功能藏在菜单里还是放在首页上，a 会成倍变化而不是增减几个百分点。r 随架构变化：加一个验证步骤就会翻倍。c 随 prompt 和模型选择变化。当预测出错时，这条链会告诉你哪个团队的假设出了问题。

下面每个输入都是一个假设，选择的是看起来合理的值而非实际观测值：

U = 20,000        月活跃用户
a = 0.35          使用 AI 功能的用户占比
s = 6             每个参与用户每月 AI 会话数
r = 4             每个会话的请求数
c = $0.0055       每次请求平均成本

参与用户数         = 20,000 * 0.35 = 7,000
每月请求数         = 7,000 * 6 * 4 = 168,000
月度花费           = 168,000 * 0.0055 = $924

每个参与用户成本   = 6 * 4 * 0.0055 = $0.132 / 月

五个因子中有两个在填入数值时需要格外怀疑。a 在早期几乎总是被高估，因为构建功能的人会不断使用它，而其他人都还没发现这个功能；应该去测量它而不是假设它，并且预期它只有团队猜测的三分之一。s 是成功产品变化最大的因子，但它不是平滑变化而是阶梯式变化——一个通知、一个新的入口、或者一个 onboarding 改动可以在一个星期内让它翻倍，而推理本身没有任何变化。

每个参与用户每月十三美分。就这一个数字，你可以带入毛利率计算、和你的定价做对比、也应该在仪表板上保持平稳而其他所有指标都在增长。如果它不平稳，预测就出了问题，以下四个原因之一是罪魁祸首。

线性模型失效的四种情况

1. 对话变长，历史被重新发送

如果每一轮都重发整个对话，第 n 轮就要为前面的 n-1 轮付费。一个 k 轮会话的成本与 k(k+1)/2 成正比，而不是与 k 成正比。

k = 4  ->  4*5/2  = 10 单位
k = 8  ->  8*9/2  = 36 单位      2 倍轮数，3.6 倍成本

留存率提升会让 k 变大。所以产品越擅长让人保持对话，这个因子增长得越快——成功和成本通过一个二次关系耦合在一起。滑动窗口加滚动摘要可以恢复线性，这是标准解决方案。

2. 检索语料库增长

文档越多，通常意味着检索的 chunk 越多、每个 chunk 越长，或者两者兼有，而它们在每次请求中都是输入 token。追踪每个请求的 T_in 随时间的变化；如果它向上漂移，在假设 c 恒定的预测下面，c 其实在悄悄上涨。

3. Agent 循环让 r 成倍增加

一个变成 agentic 的功能不会按百分比增加 r，而是会乘以步数。从一次调用变成平均六步，就会在整个预测上产生 6 倍的效果，而且是在一个版本中突然到来的。任何路线图上包含"agent"这个词的项目都需要在预测中占一行。

4. 使用量有重尾分布

用户不会按均值消费。如果前 q 比例的用户占用了 s 比例的 token，那么该群体中的平均用户成本是整体均值的 s/q 倍：

heavy_user_multiple = s / q

如果前 5% 的用户产生了 40% 的 token：
  0.40 / 0.05 = 8 倍于普通用户

按 $0.132 的均值计算，前 5% 用户每月花费约 $1.06。

为你的产品测量 q 和 s；这是对一个月使用量按用户分组。分布形状很关键，因为当用户结构稳定时预测是准确的，而一旦你的增长渠道开始引入不同类型的用户——企业试点、集成合作伙伴、病毒帖子——尾巴变厚，预测就会失效。

场景，而非单一数字

点预测必定会错，给出一个数字只会引发关于错误问题的争论。给出三个场景，只对敏感度检查表明占主导地位的两三个因子做变化。

                low        base       high
U              15,000     20,000     35,000
a                0.25       0.35       0.50
s*r               18         24         40
c            $0.0040    $0.0055    $0.0080

spend          $270       $924     $5,600

高端场景是 base 的 6 倍，
来自各自并不极端的变化，因为因子是相乘的关系。

原则是只变化你真正不确定的东西，并且明确说出每列的假设。一个悄悄把每个因子最悲观值组合在一起的高端场景不是场景，是最坏情况，把它作为预测呈现会摧毁另外两列的可信度。为每个故事命名："low"是当前增长率继续且没有产品变化的情况；"high"是企业试点转化和 agent 功能在同一季度发布的情况。

这种相乘关系才是这个练习的意义所在。四个假设各自乐观 1.5 倍，就会产生 5 倍的意外——这是账单变成危机的正常方式。这也是支持用高端场景而不是 base 场景来设置硬上限的理由。

每月从日志重新拟合。每个因子都是可测量的。一个没有与实际比对过的预测只是一厢情愿。

对每个参与用户成本设置告警，而不是对总成本。总成本随用户增长是预期的；人均成本增长是回归，需要解释。

任何改变 r 的情况都要重新预测。Prompt 编辑让 c 逐渐变化；架构变化让 r 阶梯式变化。阶梯式变化才是打破预算的原因。

把模型放进代码仓库。某个人硬盘里的电子表格是不可重新运行的。用二十行代码对接你的使用量表。

也要预测二阶成本。向量存储、日志和评估运行与同样的因子成正比，但经常被遗漏。

从日志重新拟合 c 的难易程度取决于你的成本数据。由于 Multigrid 以微美元级别附带了精确的每次响应成本，任何流量切片的 c 都是一列的平均值，而不是从已经变更过的价格表重建——使用量和成本字段都在 API 文档里。

Cost per Request: Building a Model You Can Forecast With

Unit Economics of an AI Feature

Budget Alerts and Hard Spend Caps