一张账单一个接口，谁在消耗大模型预算？

模型账单寄到公司，只有一个数字。财务看到的是一个数字，每个团队看到的是同一个接口。没人说得清哪支团队烧掉了预算的大头，哪个用例在涨，哪个实验六周前就该关掉却还开着。一张账单和一个接口之间的这段空白，就是计量要填的地方。

这家公司在用量放大之前，就把计量做进了自己的大模型网关。做完之后，团队的行为变了。

大模型计量和普通接口计量不是一回事

普通 REST 接口的计量很简单：一次请求就是一次请求。按订阅密钥数请求数，数完就结束了。

大模型调用不是这个逻辑。发往聊天接口的一次请求，可能只花五个 token，也可能花五千个。有人写了个提示注入测试脚本，挂循环跑了一整夜，八小时花掉的钱能超过一整个产品团队的月度预算。只数请求数，什么都看不出来。成本的单位是 token，而 token 数写在响应里，不在请求里。

这个细节决定了后面所有事。计量代码必须读响应体，把 usage 块抠出来，在数据消失之前完成归属。Azure OpenAI 每次响应都会返回这样一段：

• prompt_tokens：1240
• completion_tokens：312
• total_tokens：1552

不在网关处截住，事后就得从日志里重建，那是一场打不赢的仗。

在网关做，别在应用里做

每个团队都想在自己的应用代码里做计量。这家公司说了不。网关是每一次调用都要经过的那一层，跟语言、框架、团队无关。让每个团队自己埋点的计量方案，覆盖范围注定有限。

做法是在网关的入站路径上加一条策略，给每个请求打上元数据：密钥属于哪个订阅、哪个产品、哪个环境。出站路径上另一条策略解析响应，取出 token 数，发一个事件进分析管道。策略不会以调用方看得见的方式改动请求体或响应体，它只观察、只上报。

入站打标、出站取成本、发到能持久保存的地方——这个形状比具体语法重要，毕竟每家网关的语法都不一样。

失败的调用也要算进去

第一版计量只统计成功的调用，这个版本活了两周。有人对着一个已废弃的模型部署跑批处理任务，一整天返回的都是 400。单次调用很便宜，但架不住几十万次，而模型供应商对每次失败请求的输入 token 照样收费。

失败的请求消耗输入 token，被限流的请求消耗输入 token，撞上内容过滤的请求也消耗输入 token。只统计 200，账单和看板就会对不上，而财务信的是账单。

出站策略记录每一个响应码。失败单独放一个桶，让团队能分开看，但不从总数里剔除。某支团队第一次看到自己在 400 上花了多少钱，当天下午就把客户端代码修了。

给团队看自己的数字，不是全公司的数字

一块只写着全公司大模型账单总额的看板，帮不了任何人。一块写着“你的团队花了多少、比上月涨了多少、花在某个具体模型上”的看板，一夜之间就能改变行为。

他们按团队发布视图：按团队、按模型、按天看 token 和估算成本。估算成本这部分很关键。token 是抽象的，美元不是。维护一张按模型的小价目表，乘一下就行。估算不完美，看板上也写明了不完美，但足够驱动决策。

行为变化是立刻发生的。团队开始批量发请求，开始缓存重复的提示词。有支团队看到单次运行成本后，把摘要任务从大模型换成了小模型。账单还是一行数字的时候，这些都没发生。

预算要有牙齿，但先给可见性

团队能看到自己的花费之后，下一个问题就是限额。这家公司先加预算告警，后加硬停。顺序很重要。

用量越过月度预算的50%、80%、100% 时，告警发到团队频道。多数团队在 50% 就自己纠偏了。没纠的，网关上的硬停会限流后续调用，直到有人提高预算。

他们刻意没有一上来就硬停。一个正在跑限时演示的工程师撞上硬限，学到的是“网关是敌人”；一个在 50% 收到警告的工程师，学到的是盯住自己的预算。硬停是给失控循环准备的，不是给正常工作准备的。

如果重来一次

有三件事会改。

1. 第一天就计量流式响应。token 数在流式响应结束时才到，第一版实现漏掉了它，而流式流行起来的速度超出预期。
2. 更早统一元数据标记。放任团队自由添加自定义属性，结果同一个项目名出现了三种不同的键，事后归一化相当繁琐。
3. 把价目表放进版本控制并加审核步骤。模型价格会变，一变旧估算就显得不对。现在价目表按代码对待：提合并请求、有人审、有变更记录。

真正的教训是：计量不是计费功能，是一个反馈回路。团队能看见自己每次调用花多少钱的那一刻，就开始按“成本要紧”的方式做工程。架构变好了，浪费降下来了。没有人需要一份政策文件来提醒他们对贵模型小心点，数字比任何文件都会讲故事。

如果正在搭大模型网关，而还没人问过成本归属——他们迟早会问。在账单变成一场对话之前，把计量做进去。