第一个注意到你推理模型回退的人，几乎永远不会是工程团队的成员。而是财务分析师，在周二下午联系你的经理，因为上个月的 Anthropic 账单比前一个月高了 2.4 倍，而且“我们并没有发布任何会导致这种结果的东西”。你打开仪表板，查看请求量——平稳。p99 延迟——平稳。每个响应的输出标记——平稳。错误率——平稳。你六个月前配置的每一个面板都显示系统运行健康。财务人员看的是另一个数字，而且他们是对的。
他们看的数字是推理标记（reasoning tokens），而大多数可观测性栈是在这个领域出现之前构建的。
你的 AI 功能成本是一个分布，而不是一个数字。挂在研发财务作战室墙上的仪表盘显示，上个月支出了 187,000 美元，并按功能、模型和区域进行了细分。然而，这些视图都无法回答 CFO 真正想问的问题：“谁每月付给我们 40 美元，却消耗了我们 4,000 美元的成本？”当你按 customer_id 而不是功能进行排序时，原本平稳的柱状图会变成一条曲棍球棒曲线，而那些针对平均用户进行设计的团队会发现，他们在一个季度里一直在默默地为长尾头部的用户提供补贴。
这种模式是如此一致，以至于完全可以被称为定律。在生产环境的 LLM 工作负载中，前 1% 的用户通常驱动了 30–50% 的 token 支出，而在排名前 0.1% 和 0.01% 的用户中也会出现类似的分布形状。这并非某个产品的特例 —— 当你发布一个边际成本可变且定价统一的功能时，这必然会发生。平均用户的利润率看起来不错，中位数用户的利润率看起来非常好。但重尾部分的积分才是季度预算的真正去向。
价格页面上最便宜的那一行很少是发票上最便宜的一行。团队选择主力模型（Workhorse model）——Sonnet、Haiku、Flash、GPT-mini——是因为每 token 的计算方式很友好。上线功能后，看着成本控制面板报告了一个季度的单位经济效益（unit-economics）好消息。然后长尾效应跟了上来：主力模型处理不了一部分请求，开始重试，接着是部分回答，最后升级到人工审核，每个功能的损益表（P&L）不再像每次调用的仪表盘那样好看了。
这里的套利在于，针对这些困难请求，团队永远不会作为默认选项的推理模型（Reasoning model）——Opus、o3，这类缓慢昂贵的模型——通常在第一次尝试时就能给出答案。一次 0.50 美元的推理调用总成本，胜过五次 0.05 美元的主力模型调用加上升级队列，以及周一调试失败的工程师成本。采购问题（哪个模型每 token 最便宜？）和架构问题（哪个模型解决每个请求最便宜？）是不同的问题，将两者混为一谈的团队正在支付这两者之间的差价。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
