推理账单：没人愿意背的损益表科目

公司里的某个地方，四个人各自都相信第五个人在管推理账单。工程把它当成云账单的一项。AI 团队把它当成做产品的成本。财务把它当成毛利率的可变输入，默认工程那边已经在管了。产品把它当成工程吸收的间接成本。账单一直在涨，唯一达成共识的是：这账不是我的。

这不是预算问题，而是所有权真空。它第一次浮出水面，往往是因为这条线大到 CFO 在董事会上点名问起。到那时，大家临时拼凑的回答——"我们会优化"、"我们会多做缓存"、"我们会换模型"——描述的是干预手段，却没有指出谁负责。本该在一年前发生的对话，并不是怎么把账单压下去，而是这笔账究竟属于谁的损益表。

这是结构性的变化。推理在企业 AI 支出中的占比，从 2024 年的 15% 涨到 2026 年的大约 85%；同一时间窗口里，企业平均的 AI 预算从 120 万美元涨到了 700 万美元左右。一项原本属于零头的科目，现在已经是董事会会注意到的数字，而那张在变化之前画好的组织架构图里，根本没有给它留一行。

云支出十年前已经解决过同样的组织缺口

云支出十年前走过完全一样的路。EC2 账单每月一到，基础设施团队付钱，产品负责人发布功能——而这些功能的单位经济学没人算得清楚。后来出现的 FinOps，这门学科先回答的是结构问题，再回答的是优化问题。容量规划属于 SRE。客户单位成本属于产品。承诺折扣谈判属于采购。每个职能各管同一张账单的不同切面，而联合论坛存在的意义，就是确保这些切面不会互相打架。

推理支出两头都没沾上。没有一个"SRE 等价"的职能在按延迟 SLO 管预留吞吐量。也没有一个"FinOps 等价"的职能在和模型厂商谈承诺折扣。做 eval 的团队管模型质量。写 prompt 的团队管延迟。两边都不会主动负责"这个功能产生的价值是否对得起它烧掉的 token"这个对话。

于是账单就在"工程工具"、"平台"或"共享服务"里悄悄长大，直到某一个功能大到把这个桶撑爆。撑爆的那天，回应方式是一场 panic 优化冲刺，领头的是那天早晨刚好倒霉出现在站会上的工程师。这场冲刺砍掉 30%，大家松一口气，所有权问题再次被搁置。下一次撑爆时，优化空间更小，紧迫性更高。

单次产出成本：组织架构算不出来的指标

推理真正对的指标，是单次有效业务产出的成本——单次解决的工单成本、单次合格销售线索的成本、用户真正用上的单次准确摘要的成本。工程能告诉你单 token 成本。产品能告诉你每场会话的产出数。财务能告诉你每客户的营收。这三者的交集——单次产出成本——需要跨三个系统做 join，而这件事不属于任何一个职能。

结果就是，"这个功能是不是已经赔本？"这个问题的答案，往往住在某个人每季度手工搭一次的电子表格里，而且通常等到问题变得紧急之后才出现。这个 join 在技术上是可做的。它之所以不存在，是因为这张仪表盘一旦有了主人，那些赔本的功能就有了原告。没人愿意主动当这个原告，除非被迫——通常是一个不再接受"我们还在校准"作为回答的 CFO 逼出来的。

一个能跑起来的版本需要四样东西，没有任何一个团队同时拥有：

• 在功能级别打标签的 token 遥测，而不是按模型或 API key 维度
• 一个由产品团队签字认可的、可归因的"产出"定义
• 一个财务愿意在领导面前为之辩护的营收或价值模型
• 一条把推理支出推回产品负责人损益表的分摊规则，而不是吸收进工程间接成本里

第一样是技术问题。后面三样是政治问题。这就是为什么光靠 FinOps 工具解不开这个题——它们能交付仪表盘，但仪表盘回答的是一个组织还没同意去问的问题。

分摊是披着技术外衣的政治决定

推理所有权最干净的实现是按功能分摊。负责 AI 摘要功能的产品团队，为自己功能消耗的 token 付钱。负责聊天机器人的团队，为聊天机器人的 token 付钱。推理支出像人力成本和广告费一样出现在产品负责人的损益表上，"留还是杀"的决定，是对着一个产品负责人无法外推的数字做出的。

加载中…