指标一：单任务成本
把一段时间总花费除以通过验收的任务数，失败与重试同样计入分子。为什么用这个口径：只算成功请求会让成本虚低，团队误以为还有余量，扩量后账单突然翻倍，预算无从解释。
指标二：缓存与复用率
统计提示缓存命中、检索结果复用与模板复用三类比例。怎么用：命中率骤降通常意味着提示词改版或请求去重失效，先查变更记录；边界是缓存不能跨权限复用，命中再高也不能牺牲数据隔离。
指标三：模型路由分布
按场景统计高价模型与轻量模型的调用占比，以及自动降级的比例。为什么要看分布：整体单价下降可能只是把难题都推给轻量模型，任务成功率同时下滑，账好看了而业务在退步。
指标四：成本可归属率
能归到部门、场景或客户的花费占总花费的比例。做法是给每次调用打上场景与租户标签，归不到的部分单列为公共成本。边界是标签体系要与财务科目对齐，否则报表对不上账，治理推不动。
指标五：预算预测偏差
用月度实际花费减去预算，再除以预算，看连续三个月的偏差方向。为什么重要：偏差稳定说明口径可用，偏差忽高忽低说明需求或计量有问题，此时做优化只是把误差挪个位置，账并不准确。
适用与不适用
适合谁
- 已有稳定调用量、账单可查的团队与负责人
- 需要向业务部门分摊成本的平台方或集团
- 正在评估模型替换与降级方案的项目组
不适合谁
- 调用量零散、尚无稳定场景的团队或部门
- 只关心单次价格、不做长期统计的采购岗位
典型场景
一家电商客服团队把三个月的调用记录按场景打标，发现售后退款类请求占了大部分花费，其中重复问句的缓存命中率不足三成。团队先修去重与缓存，再谈模型降级，月度复盘时用同一套指标对照，不再凭印象。
可执行步骤
- 给每次调用打上场景、租户与模型标签，落到可查询的表里，便于按月拆分
- 设定统一统计周期与费用口径，把失败请求与重试一并计入分子
- 按月输出五项指标，逐项标出异常波动与对应的变更记录，逐项标注时间
- 对异常项逐条归因，先改调用次数与提示词，再谈单价与降级，顺序不要颠倒
- 把结论写进预算评审，明确下一周期的目标值、责任人与复核时间
常见坑
- 只统计成功请求的花费，失败与重试被忽略，成本被系统性低估，扩量后预算直接击穿。
- 把缓存命中率当成越高越好，跨权限复用导致答非所问，返工的人力成本远超省下的调用费。
- 指标口径每季度换一次，前后无法比较，团队只能凭感觉判断优化是否有效果，结论也站不住。
- 只做模型降级不做评测，任务成功率下滑没人发现，直到投诉集中才匆忙回滚，期间损失无人核算。
自检与验收清单
- 五项指标是否都有口径说明与原始数据
- 失败与重试是否一并计入成本分子，是否有例外
- 缓存是否按权限隔离，避免跨租户复用
- 降级方案是否跑过评测集再上线，有无对照记录
- 预算偏差是否连续三个月复盘，偏差是否有解释
常见问题
优化成本一定要换更小的模型吗
不一定。多数浪费来自重复调用、过长上下文与失败重试，先把这些削掉往往比换模型更有效。换模型会动到效果，需要评测集兜底；调用侧的优化可以逐项回滚，风险更低。
成本可归属率低怎么办
先从标签体系入手：给每次调用带上场景、租户与业务线，归不到的先单列为公共成本。标签要与财务科目对齐，否则报表对不上账。归属率提升本身就会带来优化动力。
指标要几个人维护
初期一个人足够，主要是脚本与看板；关键是有人对异常项负责归因。若指标没人看，再精细的口径也只是报表。建议把异常复盘放进现有的月度经营会，而不是另开一个会。