推理成本预测：财务团队想要而你写不出来的容量规划

你的财务团队会要求你提供一份你写不出来的容量规划。这不是因为你缺乏经验，也不是因为模型是新事物，而是因为经典容量规划所依赖的两个假设——可衡量的负载分布和在季度维度上稳定的单位成本——在 AI 工作负载面前都失效了。你交给他们的数字从第一天起就会是错的，而当偏差出现时，随后的讨论将不仅仅关乎账单。

《2026 年 FinOps 现状报告》将 AI 列为增长最快的新支出类别，大多数受访者表示 AI 成本超出了最初的预算预测——对于许多企业来说，推理现在消耗了 AI 账单的大部分。用 SaaS 风格的容量规划来管理它的本能反应——选择一个峰值 QPS，乘以单位成本，再加上 30% 的缓冲——产生的数字看起来像预测，其实际预测能力却如同占星术。你真正需要的容量规划看起来更像是 FinOps 场景模型，而不是采购电子表格，而生成它所需的工程工作属于平台工作，会一直与功能开发竞争资源，直到财务部门失去耐心。

这篇文章将探讨为什么 SaaS 模式的容量规划不断失败，AI 模式的规划长什么样，以及在财务部门停止每季度要求重新设定基准之前，团队必须建立的四种规范。

为什么经典的容量规划会失效

经典的容量规划之所以奏效，是因为有两件事大致稳定。工作负载分布——每秒请求数、负载大小、峰谷比——具有你可以通过历史衡量并向前预测的方差。单位成本——每个请求的美元成本、每个 CPU 小时的美元成本——在季度时间尺度上是稳定的，因为供应商的价格变动会有公告通知，而且你的技术栈在董事会会议之间不会发生重构。

AI 工作负载打破了这两点。在同一功能下，不同用户之间每个请求的 Token 数量差异可能跨越三个或更多数量级。一个总结端点，在处理 200 字电子邮件的普通用户和处理 50 页合同的深度用户之间，单次调用的成本差异可达 250 倍。而且，任何特定时段的用户组合都不是历史流量数据能捕捉到的属性，因为上个季度的用户组合与下个季度的完全不同。“平均”请求是一个统计虚构——成本分布具有重尾特征，而预算实际上都消耗在了尾部。

单位成本的情况更糟。LLM API 的价格在 2025 年初到 2026 年初之间下降了大约 80%，但对于预算所有者来说，“下降”是一个错误的框架——实际发生的是你的技术栈在预算周期内默默地重构了。模型升级发布了，团队将默认层切换到了具有不同 Token 定价和不同 Token 效率的新模型，而预测中的单位成本行现在描述的是一个你已经不再使用的模型。1 月份产生预测的定价环境，并不是 4 月份计算账单时的定价环境。

还有放大效应。一个简单的功能更改——在循环中添加一个工具调用、将系统提示词扩大一个段落、从“提示词中的工具”切换到“代码中的工具”——就可以将每个任务的 Token 消耗放大一个数量级甚至更多。Agent 工作负载消耗的 Token 比聊天交互多 4 到 15 倍，而反思型（reflexion-style）循环可能会将其推高到 50 倍。一个四轮对话的成本不是单轮对话的 4 倍；它大约是 10 倍，因为每一轮都会重新发送累积的上下文。上线“让 Agent 最多重试三次”的产品经理并没有提交预算变更申请，而签署季度预算数字的财务团队也没看到那个刚刚翻倍的条目。

这不是通过增加缓冲就能解决的预测问题。对于一个在预算周期内波动 3 到 10 倍的指标，30% 的缓冲只是摆设。预测框架本身必须改变。

场景区间，而非点估计

第一项规范是停止向财务部门提交单一数字。AI 工作负载的预测单位是场景区间（scenario band）——一个与功能决策、模型选择和使用假设明确挂钩的合理范围——而不是一个点估计。

一个场景区间至少有三个分支：基准案例（“当前功能集、当前模型组合、当前使用轨迹”）；增长案例（“计划中的功能按计划上线，用户增长达到产品路线图目标”）；以及扩张案例（“设计中的 Agent 功能落地，并将采用该功能的群体的成本放大系数提高 N 倍”）。每个分支都指明了产生该数字的假设——什么模型在做什么工作、假设的缓存命中率是多少、有多大比例的请求命中了长上下文路径。

这听起来像是额外的工作，事实也确实如此。但它将一个脆弱的预测转变成了一个财务部门真正可以推理的结构化对象。当数字发生变动时，对话不再是“你预测错了”，而是“哪个假设发生了变化，以及那个假设是否是某人负责的功能决策”。区间为财务和工程部门提供了讨论偏差的共同语言，并迫使工程侧清晰地表达那些原本不可见的成本相关决策。

频率也必须改变。季度预测适用于稳定的工作负载；AI 工作负载需要每周或每月的滚动预测，以便在失控的支出演变成董事会级别的“惊吓”之前捕捉到它。滚动频率不是可选的——它是唯一能及时捕捉到 10 倍放大事件并采取行动的机制。

将模型组合作为一等预算杠杆

第二项原则是将模型组合（Model Mix）视为预测中明确列出的预算杠杆。旗舰级模型与预算级模型之间的差距大约是 20 倍，而非 2 倍。一个在“原型阶段无关紧要”的模型选择，在规模化后就是一个六位数的支出项。如果团队没有明确哪些功能运行在哪个层级，就等同于默认将所有功能都交付给了最昂贵的选项。

预测应该针对每个与收入相关的界面回答四个问题。该功能目前运行在哪个模型层级？如果降级一个层级，评估质量（Eval-quality）的差异是多少？成本差异是多少？路由逻辑是什么——是整个功能都在一个层级上，还是根据置信度信号从廉价模型级联到昂贵模型？

这正是评估基础设施从“质量关注点”转变为“预算关注点”的地方。如果没有能在各个层级对质量进行评分的评估系统，那么“将此功能降级到更便宜的模型”就只是一种猜测。有了评估系统，它就变成了一个预算输入——“切换到更便宜的模型但损失 2% 的质量”与“留在高级版但多消耗 40% 的成本”之间的权衡，就成了财务和产品负责人可以根据证据共同做出的决策，而不是工程团队在季度末才发现的问题。

在这里，路由（Routing）与原生层级选择同样重要。将简单请求路由到廉价模型，并将困难请求交给旗舰模型的级联系统，可以在保持大部分质量的同时大幅降低成本，而路由惩罚参数本身就是一个可调的旋钮。如果一份预测指明了路由策略及其质量成本运行点，那么这就是一份在你需要时可以调整的预测。而将所有模型支出捆绑成单一项目的预测，则是财务部门只能凭直觉接受的预测。

按功能的单位成本，而非单一的推理支出项

第三项原则是按功能（Feature）分解推理账单，而不是按模型。如果推理账单上只写着“本月 LLM API 调用花费了 X 美元”，这种粒度会让 CFO 质疑“这是否随收入线性增长？”，而工程团队却无法给出合理的回答。

按功能的单位成本追踪将推理日志与用户行为遥测数据相结合，从而将账单分解为每个用户可见功能的“每任务成本”。摘要功能有一个单位成本。带工具的智能体功能也有一个。聊天功能同样有一个。每个功能都会随着使用量、功能变更和模型更换而呈现不同的趋势，只有在这种粒度下，投资回报率（ROI）的讨论才可能真正发生。

这里的转变是将“每任务成本”而非“每 Token 成本”作为核心效率指标。Token 使用量是一个投入指标；而每任务成本是一个产出指标，它包含了 LLM 调用、工具执行、重试以及由智能体失败引起的人工介入成本。如果一个功能的每任务成本在上升而用户满意度持平，那么该功能就潜入了“放大效应”——而每任务单位成本是唯一能及时发现这一点的指标。

实现这一点的埋点工作（Instrumentation work）是实打实的。它需要在请求级别连接计费数据和产品分析，保留功能级别的 Token 计数，并定义一个在功能演进过程中保持稳定的“任务”概念。在 2026 年，大多数团队还没有做到这一点。而做到的团队，他们的预测往往能站得住脚。

将质量-成本曲线作为预算输入

第四项原则是将评估质量与成本的对比曲线作为预算流程的输入，而不是工程副作用的产出。团队做出的每一个模型决策——层级选择、路由阈值、提示词结构、缓存策略——本质上都是曲线上权衡质量与成本的一个点。没有衡量这条曲线的团队，是在盲目地进行权衡。

某个功能的质量-成本曲线绘制了在不同运行点（每个模型层级、每个路由激进程度、每个提示词长度）下的评估通过率与每任务成本的关系。曲线通常有一个“拐点（Knee）”——过了这个点，进一步的质量提升需要付出不成比例的成本，或者进一步的降本会导致质量不成比例地崩溃。拐点应该是功能的默认位置，而“让我们移动运行点”是一个能产生合理解释的预算对话。

这也是 Prompt 缓存（Prompt Caching）成为预算输入而非性能优化的地方。缓存命中的成本通常仅为标准输入价格的 10%，但这种折扣仅适用于团队构建的具有可缓存性的内容，且缓存写入溢价意味着只有在超过命中率阈值后才能实现节省。如果一份预测假设了系统架构无法提供的缓存命中率，那么这份预测的偏差将是折扣因子乘以业务量的结果。

组织失败模式及其结构化原因

导致季度基准重新对齐会议的模式是结构性的，而非个人原因。财务部门将 AI 建模为随用户线性增长的单一支出项，因为他们管理过的所有其他软件成本都是如此。而 AI 团队构建的功能会随着 Token 放大效应呈现超线性增长，因为这是技术所奖励的方向。这种偏差表现为没人相信的季度预测更新，而没人揭示的成本真相是：搞错这一点的真正代价不是账单本身，而是对路线图决策的抑制作用——因为财务部门无法区分一个“10% 的功能改进”与“10 倍的成本增加”。

当这种差距存在时，财务部门的保守做法是减缓每个 AI 功能的决策，直到他们理解为止。工程团队的保守做法是在成本上保守承诺，以免为下一次超支承担责任。这两者都是合理的个人反应，却产生了一个全局性的糟糕结果——团队交付的有野心的 AI 功能比技术实际支持的要少，而他们交付的功能也是为了成本可预测性而过度设计，而非为了用户价值。

解决之道不在于更好的模型或更好的仪表板。而在于一套共享的词汇表——场景区间、模型组合杠杆、按功能的单位成本、质量-成本曲线——这能让财务和工程部门针对同样的权衡进行理性讨论。没有这套词汇表，每一次关于 AI 成本的谈话都是一个翻译问题，而翻译总会丢失信息。

AI 基础设施经济学是 FinOps，而非 SaaS

架构上的认知在于，AI 基础设施经济学更接近云原生 FinOps，而不是 SaaS 单位经济学。当单位成本稳定且工作负载可预测时，SaaS 风格的预测是有效的。FinOps 风格的预测则假设两者皆非 —— 它假设单位成本是一个动态目标，而工作负载是团队自身不断演变的选择；它围绕场景建模、细粒度归因和滚动预测建立了一套纪律，因为在那种体系下，这些是唯一能产生可靠数据的工具。

如果一个团队向财务部门提交 SaaS 风格的预测，那么在有人投入精力构建 AI 感知版本之前，他们每个季度都会被迫参加重新设定基线的会议。这种投入不是可选的，也不是买个工具就能解决的 —— 它是一种度量手段和流程的变革，改变了谁可以在没有预算审查的情况下发布什么内容。好消息是 FinOps 社区已经完成了大部分基础工作；坏消息是 AI 工作负载非常特殊，基础工作只能帮你走一半的路，剩下的需要每个团队自行构建。

如果你无法写出财务部门要求的容量计划，正确的应对方式不是写一个更糟糕的。正确的做法是解释缺失了什么，需要构建什么才能得出可靠的答案，以及在此期间你能提供哪些场景区间。财务团队的适应速度比工程团队想象的要快，但前提是工程端不再向他们提交连自己都不相信的数字。