指标一：每任务 token
按场景统计输入加输出的 token 总数，再除以任务数。为什么拆场景：客服问答与文档摘要的量级差一个数量级，混在一起算平均值，既看不出浪费点，也无法给预算提供依据。
指标二：输入输出比
输入远大于输出时，成本主要由上下文决定；比值接近一时，输出长度才是关键。怎么用：按场景看比值，再决定先压缩检索片段还是限制输出长度，两类手段的成本与风险完全不同。
指标三：缓存命中率
统计前缀缓存与检索缓存的命中比例。为什么重要：相同系统提示与知识片段被反复送入，命中率高能显著降低输入侧花费；边界是缓存按权限隔离，命中率再高也不能跨租户复用。
指标四：重试放大系数
实际计费请求数除以用户请求数，得到放大系数。怎么查：按链路看超时、限流与格式错误的比例，系数明显大于一时，先修稳定性再谈压缩；只压长度不改重试，账单仍会被放大。
指标五：加权有效单价
把混合路由后的各模型单价按调用量加权，得到有效单价。为什么要算：只报最便宜模型的单价会误导决策，实际账单取决于高价模型占比；加权单价与路由分布要一起看，才能判断降级是否值得。
适用与不适用
适合谁
- 已能按场景统计调用与 token 的团队
- 输入长、检索片段多的问答类系统
- 正在做模型路由与降级方案的项目组
不适合谁
- 调用量小、月度账单可忽略的团队
- 拿不到请求明细的采购与财务岗位
典型场景
一家律所的知识检索助手每月 token 消耗居高不下。团队按场景统计后发现，合同审阅类请求的平均输入是问答类的数倍，其中大半是重复的条款原文。先做条款切片与缓存，再限制输出长度，两个月后单位任务 token 明显下降。
可执行步骤
- 按场景统计每个任务的输入与输出 token，算出每任务总量并按大小排序
- 计算输入输出比，判断成本主要压在上下文还是输出长度上，再定压缩方向
- 统计前缀缓存与检索缓存的命中率，并核对缓存键是否按权限隔离
- 查超时、限流与格式错误的比例，算出重试放大系数与主要来源
- 按调用量加权各模型单价得到有效单价，再与路由分布对照，判断降级是否值得
常见坑
- 只统计用户请求数，不统计计费请求数，重试带来的放大被完全忽略，预算自然偏低。
- 拿最便宜模型的单价做预算，而实际路由里高价模型占多数，预算必然失准，月底只能追加。
- 把缓存命中率当成唯一目标，跨权限复用导致答案串号，返工成本比省下的费用高得多。
- 输入输出比不看场景，统一限制输出长度，把需要详细说明的任务压成残句，业务方不满。
自检与验收清单
- 每任务 token 是否按场景分别统计并排序
- 输入输出比是否算过并用于决策，谁在看
- 缓存命中率是否与权限隔离一起检查
- 重试放大系数是否有人持续跟踪并归因
- 加权有效单价是否与路由分布对照
常见问题
token 数能自己估算吗
可以用分词工具估算，但与供应商计费口径可能有差异，尤其在工具调用与结构化输出场景。建议以账单为准，用估算做日常监控，两者每月校准一次，差异扩大时再查口径。
输入输出比多少算正常
没有统一标准，取决于场景。检索问答常见输入远大于输出，创作类则相反。关键不是比值本身，而是它是否稳定；比值突然变化，通常意味着检索配置、提示词或输出格式发生了改动。
缓存命中率高就一定省钱吗
不一定。缓存写入本身可能计费，过期策略不当还会返回旧答案。要看净收益：命中带来的节省减去写入与失效成本，再对照错误率。只盯命中率容易做出看似省钱、实际返工的选择。