为什么你的AI账单会突然失控？先算清每请求成本

年初定了一笔AI预算，数字合理，董事会点头，事情就算过去了。然后某个功能火了，用量往上走，账单却没跟着慢慢涨——它是跳着涨的。这时候你要解释一个没人建模过的偏差，而诚实的答案是：你从来没有过预算，你只有一个猜测，挂在一只没人盯着的表上。

这就是AI成本的陷阱。它不像软件授权那样是一个谈一次就忘掉的固定数字，它更像水电费：按用量计价的表，随着每一次请求、每一个token、每一次重试往上走。把它当成一行固定开支而不是一只表，意外账单就是这么来的。

让AI成本可预测，不是规划阶段做一次的财务动作，而是建进系统里的工程纪律。工作的基本单位是token，可预测性从这里开始，不在表格里。

先算清每个请求的成本

控制不了的东西，是因为你没在测量它。要测的是每请求成本，不是每月总花费。月度数字是结果，每请求数字才是杠杆。

先做算术。大模型的定价按token计，输入和输出分开算，输出通常比输入贵好几倍。以一个参考点看，公开的2026年Claude系列定价，从最快模型每百万输入token 0.25美元，到最强模型每百万输入token 15美元，输出价格还要高出数倍，所以一个小而快的模型可以比前沿模型便宜一到两个数量级。每请求成本就是：输入token数乘输入单价，加上输出token数乘输出单价。

拿你真实的流量去跑这个公式。一个带8000 token上下文、输出1000 token答案的请求，放在前沿模型上和放在小模型上，是完全不同的两个数字，这个差距就是全部胜负手。再乘以量：如果一个功能每天10万次请求、每次0.05美元，那就是每天5000美元、每月15万美元。流量翻三倍，账单自动翻三倍，不管有没有人规划过。

你的AI项目里最重要的一个数字就是每请求成本，而大多数团队说不出来。按功能算它，盯着它怎么变，你就把一张不可预测的账单变成了可以预测的模型。

把重复的活儿缓存起来

AI开销里很大一块，是在一遍又一遍地为处理完全相同的token付钱。系统提示词、工具定义、少样本示例、相似问题之间几乎不变的检索上下文，每次调用都要重新发送、重新计费。

缓存直接打这一点：

• 提示词缓存让服务商存下并复用提示词里不变的前缀。对每次请求都发送的长而稳定的系统提示词，这部分输入成本最多可降约90%，延迟最多降85%。如果你的输入token里有80%是固定前言，省下的钱非常可观，而改动很小。
• 语义响应缓存则在新请求与已答过的请求语义相同或近似时，直接返回存下的答案。对FAQ类或高重复负载，这能把相当一部分请求完全挡在模型之外，成本降到接近零。

缓存通常是回报最高的成本杠杆，因为它不需要在质量上做交换。你不是把产品做差了，你只是拒绝为同一次计算付两遍钱。

把请求路由到合适的模型

把所有请求都发给最强最贵的模型，是最常见的成本错误，而且是纯浪费。大多数请求不需要前沿模型，它们需要一个够好的模型，而“够好”往往便宜20到50倍。

模型路由就是按难度给每个请求分类，发给能处理它的最便宜模型：简单、结构化或高频的任务，比如分类、抽取、短回答、常规摘要，走小而快的模型；真正困难的任务，比如复杂推理、细腻生成、多步问题，走前沿模型；边界情况可以先从便宜的开始，等小模型给出低置信信号或校验失败时再升级。

如果70%的流量是常规任务，你把它从前沿模型挪到便宜二十分之一的模型上，总花费就砍掉一大块，质量影响可以忽略，因为这些请求本来就不需要贵模型。活儿在于建分类器和评测覆盖，证明便宜模型扛得住，但回报会随着每一次请求一直放大。

能等的活儿就批处理

不是每个请求都需要200毫秒内给出答案。夜间报表生成、批量文档处理、给积压数据做嵌入、离线富化，这些不需要实时服务，而实时服务正是你付溢价买的东西。

多数服务商提供批处理档位，用延迟换价格：结果几小时内返回而不是几秒，价格大约打五折。比如OpenAI的Batch API，相比同步API提供50%的成本折扣，24小时内完成。把负载按延迟分层，能容忍延迟的全走批处理通道，这一整类成本就白省一半。唯一需要的纪律是诚实判断哪些负载真的紧急，通常比你以为的少。

像盯延迟一样盯每请求成本

你不会在没有延迟和错误看板的情况下跑生产服务。AI成本值得同样的待遇：实时、带告警，因为它的故障模式是财务性的，而且动得很快。

一套能用的AI FinOps配置会跟踪这些：

• 每请求成本，按功能、模型、客户拆开。总花费会掩盖问题，拆开才看得出哪个功能的单位经济已经倒挂。
• token消耗趋势，让你在账单之前先看到用量在爬。
• 成本异常告警，在每请求成本或总花费跳升时触发，最好挂上能限流或叫人的预算阈值。
• 重试与失败成本，因为失败的请求照样烧token。重试率高的功能，其实在为一个成功答案悄悄付好几次钱。

给每个请求打上功能和模型的标签，成本才能精确归因。数字飙升时，你要在几分钟内知道是哪个功能干的，而不是三周后从月度账单里倒推。

这是FinOps，不是路线图预算

这个区分值得说清楚，因为两者常被混为一谈，而它们要做的活儿不一样。

路线图预算问的是“这季度我们该在AI上投多少”，那是关于把赌注押在哪儿的规划对话，一年发生几次，在一间有管理层的屋子里。这里说的是FinOps，是持续运营的纪律：管理单位经济，让花费随用量合理伸缩。它活在架构和看板里，不在规划PPT里。你可以有一份完全合理的路线图预算，然后照样被一张账单打穿，因为预算定的是天花板，单位经济决定你会不会撞穿它。可预测性来自FinOps这一层：缓存、路由、批处理、监控，烤进系统每天运转的方式里。

这季度从哪儿开始

不需要一次全上，按回报排序：

1. 先给每请求成本装上仪表。按功能和模型打标签，把数字放上看板。看不见就管不了，光这一步往往就能揪出最大的元凶。
2. 对稳定的提示词前缀打开提示词缓存。回报最高、投入最低、不牺牲质量。
3. 给高频常规流量加模型路由，用评测证明便宜模型守得住质量。
4. 把非紧急负载挪到批处理，拿那大约五折。
5. 接上挂预算阈值的异常告警，让成本飙升的消息来自监控，永远不来自账单。

把AI成本管住的团队，不是预算最大的那些，而是把token当作经济单位、并据此做工程的那些。可预测性不是一年谈一次的东西，是建出来的东西。