AI 支出集中在少数用例上：先做用量归因再谈降本
一、先承认账单的形状，再谈怎么削
据公开报道，极少数企业占据了生成式 AI 支出的大头，同时 token 用量还在往上走、付费却未必同步。这些外部数字不进入本篇任何判断，只是引子，因为企业内部的形状本身就已经足够说明问题：打开一张自己项目的账单，绝大部分金额通常压在一个部门的两三个用例上，剩下的散落各处，加起来还没那头大。
形状决定了动作顺序。跳过归因直接降本，最常见的结果是三件事同时发生：砍在成本小头上一刀不痛；砍在大头上的时候没人认领，因为说不清这钱换回了什么；下个季度用量以更隐蔽的方式回来，比如从被砍的用例转进另一个没被记账的入口。反过来，一旦成本是可归因的对象，降本就从”行政压指标”变成”每个用例的负责人自己算账”，这才可能持续。
归因要回答的问题只有四个：归到哪个单位、数据从哪来、谁能看、超了怎么办。这四个问题任何一个没答案，降本动作就撑不过一个预算周期。
二、归因的四个维度，缺一个就会互相甩锅
维度不是越多越好，够用且能对齐组织即可。我们用四个。
| 维度 | 取值来源 | 典型问题 | 常见错法 |
|---|---|---|---|
| 业务系统与用例 | 申请单里由发起人填写 | 这个月哪三件事最贵 | 让开发者从代码注释里猜 |
| 部门或成本中心 | 网关侧按调用方身份反查 | 谁的预算花完了 | 按 IP 段划分，一换环境就错 |
| 模型与供应商 | 路由层实际选中的目标 | 换小模型能省多少 | 只记请求里声明的模型名 |
| 调用类型 | 由接口与用途判定 | 评测花掉了多少 | 评测与生产混在同一账户 |
四个维度里，”调用类型”最容易被省掉，而它恰恰最能揭示浪费。生成、嵌入、工具调用、评测、批处理，这五类的成本性质完全不同：生产调用要谈稳定与延迟，评测要谈可重复，批处理要谈吞吐与单位成本。把它们混在一格，就会出现”评测实验把预算吃光，业务方以为是自己用多了”的争议，而争议最后都会变成对整个治理机制的不信任。
还有一点值得单列：同一个用例在不同调用类型下的成本占比，常常比它总花费更有信息量。一个问答用例如果一半成本花在离线批量重跑上，那要动的就不是模型选择，而是重跑的必要性。
三、技术上怎么落地：网关记账加一组标签
归因是数据问题，不是管理问题。所有推理调用统一走网关，由网关在请求侧强制补齐标签，缺标签直接拒绝——这是唯一可靠的组合，指望调用方自觉写注释，三个月后必然出现无主流量。
每次调用要落的字段，按我们的经验至少这些：
- 发起方身份：服务名或应用凭据标识，不用共享密钥。
- 项目与用例标签：两级，项目由申请单生成，用例由负责人维护，枚举值受控而不是自由文本。
- 实际路由结果：命中了哪个供应商的哪个模型，是否走了降级路径。
- 用量分栏：输入、输出、缓存命中、嵌入各自的量，分开存，不要合成一个总数。
- 结果状态：成功、失败、超时、被限流、重试第几次。
- 流量性质：生产、灰度、实验、评测、批处理。
- 计费口径与金额：账单原始值与按内部分摊规则算出的值，两条都留。
三条容易忽略的规则值得写进代码。第一条，失败与重试也要入账。调用失败不等于没花钱，重试三次就是三份成本，而故障期间恰恰是失败最集中的时候；只记成功调用会让账单在最贵的那几天看起来最正常。第二条，评测与实验流量单列并强制带上”性质”标签，避免污染生产用量。第三条，token 与金额分开设口径。token 是自己能测的先行指标，金额依赖供应商账单、汇率与折扣，有滞后；只用金额做告警会永远慢一步，只用 token 又没法解释账单。
网关记账还有个副作用要用好：把”谁在绕过网关”变成可见事件。直连供应商接口的流量一旦出现，归因立刻失真，所以要在网络层限制出口，并在发现直连时只告警不阻断，避免把开发同学推到更隐蔽的绕法上去。
四、三种系统性失真，比数字不准更麻烦
第一种，共享密钥。一个密钥多个团队用，是所有归因失真的根源。它的修复成本最低但政治成本最高，因为要动的不是技术而是申请流程。务实做法是先按密钥拆出可见部分，再逐个替换为独立凭据，同时保留一层”归属未确认”的临时桶，让历史流量有地方放。
第二种，批处理被算成在线服务。夜里跑的批量摘要任务用同一套接口和同一个项目标签，白天在线问答的成本因此看起来高得离谱，而真正该优化的批处理却没人管。判据很简单：调用是否由用户请求触发。凡不由请求触发的，一律走批处理性质标签，并在告警阈值上分开。
第三种，内部实验被当作生产用量。这是最贵的一种，因为它会把探索成本永久摊进业务成本，让人误以为业务本身就这么贵。实验流量的处理原则不是禁止，而是让它显形：申请时写明预计用量和存续期，到期自动降级为只读或提醒续期。
五、从归因到治理的五个动作
有了归因，动作才有落点。按见效顺序，我们固定这五个。
- 每个用例设月度上限与告警，上限由申请时自报再加一档缓冲；先告警不动作，跑两个周期后再决定是否收紧。
- 把”单位业务量成本”做成主指标：每工单、每份报告、每次问答各花多少。总额指标只会让人砍需求，单位指标才让人改实现。
- 按归因结果做路由与降级：低价值高频调用换小模型或换缓存策略，高价值低频调用保留原路径。路由规则要能被用例负责人查到，否则会被当成黑箱削减。
- 下线零留存低价值用例。判据不是”用得少”，而是”用量小、且不产生任何被复用的产物”，比如没人再读的中间摘要、重复生成的同一段文案。
- 把重复计算做成缓存与批处理。同一份长文档被问二十次，正确解法是共享一次解析结果；这类改造的收益在归因表上一眼就能看出来，因为标签相同、输入前缀相同。
这五件事的顺序不能反。先做 2 再做 3，是因为单位指标没建立时，任何降级都会被解读为”平台在偷工减料”；先做 5 再做 4，是因为能靠缓存解决的用量不该被当成下线理由。
六、配额、审批与数据可见性
超支怎么处理，是整套机制能不能活下来的关键。我们的选择是：超支不自动拒绝，而是转成人工审批。自动拒绝看起来最有纪律，实际后果是业务方绕过网关找直连通道，从此这部分成本再也回不到账本上，治理机制被自己的严格杀死。审批的设计要点是快：材料只要求用例负责人说明用途、预计持续时间和是否接受降级方案，流程控制在当天可闭环；同时给一个”缓冲额度”，让正常的业务波动不需要走审批。
数据可见性的原则是向下透明、横向分域。用例负责人能看到自己用例的四维明细和趋势，部门能看到自己的汇总，但看不到别的部门的明细。这条边界一旦被打破，归因数据就会变成内部考核武器，接下来所有人都在标签字段上做文章：把成本拆分到多个用例里、把批处理伪装成实验、把探索流量挂到别人项目下。到那一步，数据还活着，但它已经不说明任何问题了。
归因的价值不在省了多少钱，在于它让每个用例都有一位能回答”这钱换回了什么”的人。洹拓把它当成一项基础设施来做，而不是当成一次财务专项，原因就在这里：财务专项会结束，而用量结构每个月都在变。