每个客户的成本集中度：为什么 AI 成本仪表盘隐藏了幂律分布

你的 AI 功能成本是一个分布，而不是一个数字。挂在研发财务作战室墙上的仪表盘显示，上个月支出了 187,000 美元，并按功能、模型和区域进行了细分。然而，这些视图都无法回答 CFO 真正想问的问题：“谁每月付给我们 40 美元，却消耗了我们 4,000 美元的成本？”当你按 customer_id 而不是功能进行排序时，原本平稳的柱状图会变成一条曲棍球棒曲线，而那些针对平均用户进行设计的团队会发现，他们在一个季度里一直在默默地为长尾头部的用户提供补贴。

这种模式是如此一致，以至于完全可以被称为定律。在生产环境的 LLM 工作负载中，前 1% 的用户通常驱动了 30–50% 的 token 支出，而在排名前 0.1% 和 0.01% 的用户中也会出现类似的分布形状。这并非某个产品的特例 —— 当你发布一个边际成本可变且定价统一的功能时，这必然会发生。平均用户的利润率看起来不错，中位数用户的利润率看起来非常好。但重尾部分的积分才是季度预算的真正去向。

为什么平均成本仪表盘在撒谎

大多数 AI 成本仪表盘是由习惯于监控传统 SaaS 基础设施的人构建的。在传统 SaaS 中，每个租户的计算成本几乎可以忽略不计。这些仪表盘按 COGS（销货成本）受固定成本支配时的维度进行聚合：功能、模型、区域、环境。其隐含的假设是用户层面的成本差异小到可以忽略不计 —— 认为关键在于平均用户成本乘以用户数量。

当边际成本接近于零时，这一假设是成立的。但当每次智能体调用的边际成本为 0.30 美元，且用户间的差异达到三个数量级时，它就会崩溃。在你的 DAU 图表中，每周运行一次总结器的用户和将其接入每 90 秒触发一次的定时任务 (cron job) 的用户，都显示为“1 个活跃用户”。但在毛利率方面，他们对你而言完全是不同的客户。

仪表盘在聚合层面说的是真话，而在决策层面却在撒谎。“支出环比增长 8%，与活跃用户增长保持一致”在技术上是准确的，但在操作上毫无用处 —— 如果 60% 的增量来自 40 个账户的话。在检查分布之前进行聚合，实际上是在假装差异并不存在。

曲线的形状

当你真正以双对数轴绘制每个客户的 token 支出时，曲线几乎总是一条直线。这就是幂律 (Power law)。你在城市人口、文件大小和维基百科编辑中都能看到同样的形状 —— 出于同样的结构性原因：富者愈富的乘法过程。在你的 API 上实现了一个工作流自动化的客户，往往会再自动化三个。发现智能体循环 (agent loop) 有用的团队，会在此基础上构建第二个智能体。

以下是几条在生产工作负载中普遍适用的经验法则：

• 前 1% 的用户驱动了 30–50% 的支出。 这是典型的重尾特征。如果你的前 1% 仅占约 10%，说明你的使用情况比中位数更均匀 —— 这通常意味着该功能受限过多，高级用户还无法充分发挥。
• 前 0.1% 的用户驱动了 10–25% 的支出。 这个级别的一个账户支出通常比底部 50% 的账户总和还要多。
• 尾部的延伸比你想象的还要多两个数量级。 无论你 5 月份最糟糕的客户是什么样，到 8 月份，肯定会有人做到其 10 倍，而直到账单寄来之前，你甚至都不知道他们的存在。

在架构上的含义是，你不能用平均值和标准差来推算成本。在你关心的范围内，分布并没有明确的标准差 —— 方差由尾部事件主导。正确的汇总统计指标应该是前 N 个分位数，以及每个分位数以上的积分。

工程团队在季度结账时是如何发现的

失败模式每次都如出一辙。财务在月底结算账目。AI 支出的总增长超过了用户群的增长。CFO 给工程副总裁发邮件。副总裁转发给 AI 平台负责人。负责人打开仪表盘，看到各功能的细分大致与上月成比例，便回复“模型价格变动了，我们会重新进行基准测试”。一周后，财务再次询问：不是单价问题，是使用量问题，而且使用量的集中方式是各功能细分图表无法展示的。

等到有人实现了按客户的归因监控并重新运行报告时，季度已经结束，而真正的问题 —— “哪些客户行为导致了集中度，本月发生了什么变化？” —— 已经无法回答了。日志已经轮转，智能体追踪 (agent traces) 已被采样清理，团队唯一能恢复的就是聚合数据。他们只能靠猜。而这些猜测随后成了下个季度的架构简报。

这个故事的深度版本在 2025 年底广为流传：一个市场研究流水线中的四个智能体往复运行了 11 天，在有人察觉之前就消耗了 47,000 美元，因为该团队的成本监控虽然发出了警报，但没有终止会话的机制。警报是事后总结，而不是护栏。同一个团队拥有按功能分类的成本仪表盘。成本是可见的。缺失的是观察与执行之间的闭环，而且是在每个主体 (per-principal) 级别上的闭环，且延迟要短到能在几分钟内捕捉到“每小时一千美元”的异常支出。

你真正需要的观测手段

只要具备一小部分原语，这类问题就能变得可控。这张清单并不长，但其中的每一项都必须从请求发起之初就承载起重任 —— 事后补救意味着要重新对每个调用点进行度量，而调用点的增长速度远快于补救工作的进度。

从请求发起时就进行单客户归因，而非月末汇总。 每一个 LLM 调用都携带一个 customer_id（对于多租户账户，还需要一个区别于账户的 principal_id，以便你能找到 Acme Corp 中具体负责的那名用户）。归因信息应与调用记录在同一个追踪（trace）中捕获，而不是事后通过合并异构日志来推导。附加这些信息的最佳位置是网关：所有 LLM 调用的统一入口，也是打标签的唯一检查点。

加载中…