推理预算委员会：Token 支出突破七位数时的治理之道

在每月 50,000 美元的水平时，你基础设施账单上的“计算 + Token”这一项只是可以忽略不计的零头。但当每月达到 5,000,000 美元时，它就是一个 CFO 级别的问题。这两个阶段之间的转变并不是渐进的——它是组织讨论模型支出方式的一种“相变”，而大多数工程组织对于随之而来的社会和政治工作都准备不足。账单依然是那简单的一行；但围绕它的对话却不再简单。

改变的是谁有资格问“为什么”。当三个产品团队共享一个 API Key 和一个预留容量时，每一个配额争论的结构都是相同的：某人正以牺牲他人的利益为代价获胜，而没有中立方来主持公道。当一个团队的发布第一次因为另一个团队上线了一个“话痨”智能体（agent）而受到限制时，整个工程组织会立刻感受到治理机构缺失带来的痛苦。在压力之下召开会议并凭空发明流程，是设计流程最糟糕的时机。

本文讨论的是拥有这些决策权的机构：推理预算委员会（Inference Budget Committee）。它的一部分职能属于财务，一部分属于平台，还有一部分属于政治。正是它将“我们应该优化 Token”变为了一项有专人负责的定期季度评审。它虽然是不起眼的产物，但却能将 AI 支出曲线趋于平缓的组织，与那些支出曲线直线上升且居高不下的组织区分开来。

为什么账单不再仅仅是一个科目

账单的构成比上面的数字更重要。到 2026 年，推理将占企业 AI 支出的约 85%——而不是训练，不是数据准备，也不是标注。一旦月支出突破七位数，推理经济学中的三个结构性事实就不再是抽象概念，而是开始决定你的路线图。

首先是智能体循环（agentic loops）的复合效应。单个用户可见的动作可以扇出为几十个 LLM 调用——规划、工具选择、检索重排序、自我验证、反思。每一次调用都是一份 Token 账单。发布智能体的产品团队并不总是知道在真实的生产轨迹中，智能体会进行多少次内部轮次，开发环境成本与生产成本之间的差距往往高达 20 倍。

其次是检索增强生成（RAG）对每个提示词（prompt）产生的潜在倍数效应。“每个请求的 Token 成本是多少”这个问题预设了一个标准答案。但事实并非如此。一个命中 30 个上下文块的新文档请求比缓存的请求成本更高，同一类型的最便宜请求与最昂贵请求之间的比例可以轻易达到 50:1。

第三是始终在线的智能——后台智能体、定时扫描、持续监控——隐藏在没有用户参与的表象下。没有人盯着这些工作负载进行压力测试。它们只是持续地消耗容量，唯一能表明出问题的信号就是账单。

这些动态中的每一个都将“LLM 成本是多少”从粗略估算变成了一个真正的预测难题。而一旦它成为了真正的预测难题，财务部门就有资格询问谁是负责人了。

共享 API Key 是一场公地悲剧

在 AI 项目的早期，一个团队从供应商那里获得一个 API Key，第二个团队会要求访问权限。平台团队默认会提供一个子密钥或包装器。当三四个团队使用同一个供应商账户时，共享密钥就成了组织中最大的无人管理的共享资源——它具有任何无人管理共享资源的所有故障模式。

供应商级别的配额适用于整个账户，而不是团队。如果一个团队不小心进入了重试循环，或者上线了一个导致提示词长度翻倍的代码回滚，所有人都会触发频率限制。从故障报警中醒来的值班人员与造成问题的团队毫无关系。不追究责任的事后剖析（blameless postmortem）变成了“我们应该更好地隔离容量”，这固然没错，但并没有改变平台团队现在成为每个产品团队事件响应瓶颈的事实。

成本分摊同样存在缺陷。供应商的发票每月送达一次，上面只有一个数字。如果不在网关层进行按团队标记，唯一的分配方式就是自我报告——也就是说，根本无法分配。财务最终只能按团队人数或上季度的使用情况进行摊派，这奖励了少报的团队，而惩罚了那些如实记录的团队。

解决方案是结构性的，而非劝诫性的。你在供应商前端部署一个内部 LLM 网关，每个请求都在 Header 中携带团队标识符，网关执行每个团队每分钟 Token 数（TPM）的限制，而分摊报告则是一个数据库查询，而不是一场辩论。像 LiteLLM 这样的开源项目，以及来自 Portkey、TrueFoundry 和 Kong 的商业网关，都大致收敛到了这种形态，因为这是唯一行之有效的形态。

但网关本身只是基础设施。网关回答的是“谁使用了什么”。它并不回答“谁应该得到多少”。这第二个问题正是委员会存在的意义。

工作委员会实际上在做什么

当你建立一个管理 AI 支出的机构时，诱惑在于将其搞得像个指导委员会。每季度的会议、幻灯片、没有决策。拒绝这种做法。推理预算委员会更接近于容量规划会议，而不是战略审查，其产出是具体的：配额分配、突发窗口、异常请求和少量的常设政策。

合理的人员构成：来自每个主要消耗团队的一名工程主管，负责网关的平台团队负责人，能够权威地将 Token 成本映射到预算类别的财务合作伙伴，以及一名被授权在无需升级汇报的情况下拍板的主席。总共五到七人。规模再大，决策就会停滞；规模再小，单一团队就会主导。

该委员会拥有四个产出物：

• 容量池。 从每个供应商处购买的总预置吞吐量，每月审查。这是委员会进行分配的库存。
• 分配表。 每个团队每分钟的 Token 配额，并为发布和季节性活动提供明确的突发余量。公开发布；不接受实时议价。
• 费用分摊报告。 每月各团队的消耗情况，映射到团队设定的“单位产出成本”指标。这是下一季度分配的输入。
• 异常日志。 近期异常请求的简短列表、审批人以及附加条件。这是防止每季度都出现同样的“紧急审批”模式的组织记忆。

这些都不是什么新鲜事。它们与 Kubernetes 平台团队为计算配额提供的产出，或数据库团队为共享集群容量提供的产出是一样的。新颖之处在于，底层资源是供应商的 Token，而底层成本驱动因素是平台团队无法直接观察到的应用行为。

按产出分摊费用，而不是按 Token

委员会做出的最具影响力的决策是费用分摊模型。天真的费用分摊是按原始 Token 消耗计算的：每个团队看到自己的账单份额，使用 Token 最多的团队支付最多。这听起来很公平，实际上却是灾难性的。

按 Token 收费会诱发提示词压缩比赛。一个团队如果花了一个季度把提示词改得更简洁，虽然报告的支出降低了，但并没有产生更多价值。一个团队如果切换到更小、更便宜但产出效果更差的模型，在仪表板上看起来像个成本英雄，却在悄悄地降低产品质量。如果一个指标只惩罚支出而不衡量产出，它就是在惩罚优秀的工程实践，并奖励那些看不见的削减。

功能性的替代方案是按经过验证的业务产出计费。每个消耗团队选择一两个产出指标——解决每个支持工单的成本、获取每个合格线索的成本、处理每个文档的成本、生成每个通过评审的测试用例的成本。费用分摊报告显示 Token 支出、交付的产出以及两者的比率。委员会审查的是比率，而不是原始支出。

这种重构正是核心所在。如果一个团队解决每个工单的成本是 0.40 美元且正在下降，那么这个团队应该获得更多容量。如果一个团队解决每个工单的成本是 4 美元且正在上升——即使其原始 Token 消耗很小——这个团队也应该进行一次不同性质的谈话。将费用分摊与产出挂钩，才能将委员会从“削减预算的演习”转变为“投资组合审查”。

这也迫使人们诚实面对哪些 AI 功能其实并不划算。许多企业 AI 推广中的公开秘密是，一旦诚实地归集了 Token 成本，某些功能在生产环境中的 ROI 其实是负的。按产出计费的视角能让这一点浮出水面。仅按 Token 归集则会掩盖它。

预测突发相关的需求

传统服务的容量规划基于一个假设：人均需求近似独立。如果 10,000 个用户在给定秒内各有 1% 的概率发起请求，总负载的方差是可控的，中心极限定理是你的好帮手。

LLM 工作负载以两种方式打破了这一假设。首先，智能体工作流（agentic flows）意味着单个用户动作会快速连续触发多次模型调用——需求单位不是“请求”而是“会话”，且会话内部是突发性的。其次，各团队之间的流量会受外部事件影响而产生关联。营销团队的线索评分智能体和销售团队的电话摘要智能体都会在活动发布后的周二出现高峰。如果将这些视为独立的泊松过程，你将在最关键的窗口期面临严重的配置不足。

经得起考验的预测学科看起来更像金融投资组合风险管理，而非排队论。每个团队提交一份月度需求概况，包括基准线、峰值倍数以及驱动峰值的事件。委员会将这些汇总成一个具有协方差感知的预测，考虑到哪些峰值可能同时发生。预置吞吐量的规模是根据第 95 百分位的总负载来确定的，而不是各团队峰值的总和。

当峰值确实重叠时，每个团队分配中的突发余量就是吸收冲击的缓冲。当突发余量不足时——当两个团队在同一个发布日确实都需要相同的增量容量时——委员会就是定胜负的人。这就是为什么主席必须是能够拍板并让决策生效的人。如果主席必须将每个冲突都升级给 VP，那么委员会就没有实际权力，其会议不过是演戏。

政治层面

运行推理预算委员会的大部分摩擦并非来自技术。它源于在同级团队为筹备了一个季度的发布做准备时，不得不对他们说“不”时的不适感。它源于在财务部门面前，当上个月的数据表现不佳时，要求团队为他们的单次产出成本（cost-per-outcome）指标辩护时的尴尬。它还源于与高级领导之间反复进行的对话——他们想无视分配表，因为他们团队的功能是“战略性”的。

做得出色的组织有几个共同的习惯。他们广泛发布分配表，并在冲突中直接引用它，因此对“为什么我不能获得更多容量”的回答是“因为分配表是这么规定的，而下一次审查是在三周后”。他们让异常申请变得罕见，并要求提供书面理由，从而使申请异常的成本与批准异常的成本同步增加。他们每年轮换委员会主席，这样就不会有哪个人永远扮演那个“唱黑脸”的角色。他们让委员会的决定是可逆的——每一项分配都有审查日期，任何团队都可以带着新数据请求重新考虑。

做得不好的组织则让委员会变成了咨询机构。分配表虽然存在，但没人执行。异常申请通过 Slack 私聊批准。单次产出成本指标每季度报告一次，但从未真正用于重新调整分配。在两个季度内，委员会就变成了没人参加的会议，而下一次推理支出意外翻倍时，就没有机构来进行处理。

领导层思维的转变

在经历过这种转型的组织中，最有趣的变化不是流程——而是高级领导层谈论账单的方式。推理预算不再是埋在“基础设施”下的财务条目，而是变成了与员工人数和云支出处于同一粒度级别的规划类别。路线图在编写时就包含了 Token 预算约束。功能提案不仅包含工程估算，还包含预估的单次产出成本。针对 AI 密集型团队的招聘计划也包含了这些团队保持高效所需的推理容量。

这就是委员会所服务的领导层转变。委员会只是机制，更深层的变化是组织已将推理内化为一种需要治理的受限资源，而不是寄希望于单价的下降能让使用曲线保持线性。单价多年来一直在下降；但总支出却一直在攀升。那些注意到这一差异的领导者，是那些在月支出达到七位数之前，而非之后，就组建委员会的人。

前瞻性的看法很简单：每个大规模发布 AI 功能的组织最终都会拥有一个推理预算委员会，就像每个运行生产基础设施的组织最终都会拥有一个变更咨询委员会（CAB）一样。唯一的问题是，你是在每月 50 万美元的关口有意识地建立它，还是在财务升级导致对话变得比原本更艰难之后，在每月 500 万美元的压力下仓促应战。无论哪种方式，工作内容都是一样的；晚做的代价将以信任度作为偿还。