有一个数据近期被频繁引用：我国日均 Token 调用量，两年时间从一千亿涨到了一百四十万亿，翻了一千多倍。按弗若斯特沙利文的统计，最近一个完整年度全年 Token 调用量已经逼近两千万亿。
但另一组数据更值得关注：国内最大的独立 Token 供应商，最近一个财年营收五千多万，净亏三个多亿——每挣一块钱，亏六块。卖 Token 的龙头在亏本卖，那买 Token 的企业呢？
过去一段时间和不少技术团队交流，发现一个共同现象：AI 用起来了，成本管理却没跟上。多家模型商账单各自为政、格式五花八门，财务看不懂，技术负责人也只能给个大概。总结下来，企业 AI 成本管理逃不出三件事：先让钱看得清，再让预算管得住，最后把能省的省下来。
看得清：打破 AI 成本的「黑盒」
先讲一个典型案例。某家中型技术公司接了 OpenAI、Claude 和通义千问三家模型。几个月下来，AI 调用成本翻了好几倍。CTO 被问到「谁花的、哪个项目花的」，完全答不上来。不是不想管，是三张账单格式完全不同——一家按 token 类型出账，一家按模型维度，还有一家混着来。
这就是 AI 成本黑盒。打破它的第一步不是找技术方案，而是确定归因维度：成本到底要归到谁头上？按人、按项目、按部门、按模型、还是按 Agent 工作流？实践中的经验是「项目 + 环境」两维起步，跑顺了再下钻。
归因只是第一层。更关键的是效果归因——花了钱，值不值？目前绝大多数团队对 AI 投入的判断还停留在感觉阶段：「体感上还行」就继续，「好像有点贵」就砍一刀。没有产出绑定的成本评估，本质上是一种盲投。
还有一块容易被忽略：闲置识别。很多企业手上攒了一批模型商账号，有的开了套餐，有的按量付费。哪个账号长期空转、哪个额度快到期，完全没有人跟踪。光是关掉几个重复采购的账号，每个月就能省下可观的支出。
工程实现思路：成本归因的核心是在 API 调用链路中注入追踪元数据（trace context），将每次调用的 token 消耗、模型标识、调用方身份和业务标签绑定。可以采用 Sidecar Proxy 模式，在不侵入业务代码的前提下拦截和标记请求，通过 OpenTelemetry 或自定义 collector 将数据汇入时序数据库（如阿里云 SLS 或自建 Prometheus），按多维标签聚合展示。归因维度的选择决定了聚合查询的灵活度，建议在数据采集阶段就保留足够丰富的标签，而不是事后补。
管得住：预算的闸门应该装在哪里
看清账单结构之后，下一个问题是：超支了怎么办。
多数团队的现状是，API Key 发出去之后没有额度控制。谁能刷、刷多少、什么时候停，全靠自觉。一旦团队超过十个人，自觉就开始失效。更不用说 MCP、Agent、自动化工作流——调用是程序自动发的，人根本感知不到。
一个真实案例：某团队的测试脚本出了问题，凌晨开始大量循环调用，跑了几个小时才发现，账单多出来几千块。没有告警、没有熔断，全靠开发人员第二天自己觉得「好像不太对」。
预算管控的核心不是抠门，而是把「不该花的钱花不出去」变成系统能力。实践中比较好用的是四道闸门：
第一道，身份与权限。不是所有人都该调旗舰模型。按角色、按项目、按环境动态赋权，只发可控的派生凭证，未授权直接拒绝。
第二道，预算与配额。三层叠加：这个 Key 能用哪些模型、单次调用上限多少、日/月额度封顶多少。
第三道，阈值告警与阻断。给每个团队、每个项目设预算红线。常规场景到 90% 触发告警，特殊场景配置直接阻断。
第四道，异常风控与熔断。凌晨突发大量调用、失败率飙升、消耗曲线出现异常尖峰——这些模式应被自动识别并当场熔断。
工程实现思路：预算管控的本质是在 API 网关或 Sidecar 层实现一个轻量级的决策引擎。每次调用前执行一次策略评估（Policy Evaluation），检查调用方身份、当前累计消耗、模型权限和配额状态。策略配置可以存储在配置中心，执行点通过本地缓存 + 定时轮询的方式获取，保证低延迟。熔断逻辑可以复用断路器模式（Circuit Breaker），设定错误率阈值和恢复时间窗口。对于需要精确计费的场景，建议在请求发出后通过回写机制更新计数器，而非在请求前锁定资源，以降低延迟开销。
省得下：结构性降本，不靠砍预算
看清、管住之后，才是真正意义上的「省」。这里的省不是砍预算，而是同样的事用更经济的方式完成。
第一招：智能路由。 不是所有任务都需要最贵的模型。简单问答、格式转换、文本摘要用高性价比模型完全够用；复杂推理、长文撰写才该上旗舰模型。但目前大多数团队所有调用都走同一个模型——因为切模型意味着改配置、改代码。做好路由分层，简单任务自动走轻量模型，复杂任务上旗舰，质量骤降时自动回切稳定版本。
第二招：数据驱动的 A/B 选型。 「这个模型好不好」不该靠口碑回答。同一场景双模型并行跑一段时间，横向对比质量和成本，用数据决定用哪家。你自己的业务场景数据比任何评测榜单都靠谱。
第三招：池内动态分配。 当企业把多个模型商账号统一纳管后，可以按优先级动态调度。高优业务分到高端模型配额，简单业务用轻量模型。高峰期自动降级非关键业务，闲置账号零消耗，出问题时一键摘除。
第四招：降智检测。 通过第三方渠道调用模型时，实际响应的模型可能和声明的版本不一致。调用方花了旗舰版的钱，拿到的是降级版本的结果。在调用发生时实时验证实际响应的模型名，发现不一致当场告警或回切——这是堵住隐性成本漏洞的关键一环。
工程实现思路：智能路由的实现核心是一个可配置的路由表 + 任务分类器。可以用轻量级分类模型（或简单的规则引擎）判断请求复杂度，然后按预设的路由策略匹配目标模型。A/B 测试可参照微服务灰度发布的做法：按流量百分比或用户 ID 哈希将请求分流到不同模型，采集质量信号和成本数据后做统计对比。路由表设计建议支持「成本优先」「效果优先」「均衡」三种模式，并可动态热加载。降智检测则是在响应阶段捕获模型声称的版本标识与实际模型做比对，依赖模型商 API 返回的 model 字段或自定义响应头。
小结
三步走是一个递进闭环：看得清是前提——说不清钱花在哪，降本就是猜；管得住是底线——没有闸门的预算，迟早超支；省得下是结果——结构性优化比一刀切砍预算更可持续。
治理的最终目的不是减少 AI 投入，而是把钱从说不清、管不住、白白浪费的地方抽出来，投到真正有产出、能增值的地方去。
