账单涨得快，通常不是单价的问题
模型账单上涨时，第一反应往往是「找一个更便宜的模型」。但在动手换模型之前，有一件事更值得先做：把花的钱按请求类别拆开。拆不开的情况很常见——你知道这个月花了多少，但不知道其中多少来自一次批量处理、多少来自用户随便聊两句、多少来自重试。
这篇给的就是这个拆分方法，工具只需要一张表和你自己的调用日志。
三栏单价：输入、输出、缓存命中
成本表的第一部分是单价，而且必须按三栏记：输入价格、输出价格、缓存命中（cached input）价格。第三栏经常被忽略，但它的折扣幅度往往很大，能不能用上直接决定长上下文场景的可行性。
记的时候有两个纪律：一是只抄官方定价页上的原文数字，不要按输入价去推算缓存价，也不要拿「听说打折」当依据；二是记下核对的日期和来源链接——价格会变，表里没有日期的数字三个月后就没法用了。厂商没公布缓存单价，就老老实实留空，别填 0。
从日志里算出你真实的用量占比
第二部分是你的真实分布，来源是调用日志：每次调用记下模型、输入 token、输出 token、其中缓存命中的输入 token、以及这次调用属于哪个业务类别（这个标签得你自己打，通常按功能名或入口分就够）。
汇总后你最关心的两个数是：输入 token 占总花费的比例，以及缓存命中率。第一个数告诉你瓶颈是「读得多」还是「写得多」——读得多说明该考虑缓存和检索收敛，写得多说明该考虑限制输出长度或换更便宜的模型出草稿。第二个数如果长期很低，那大概率不是模型不支持，而是你的请求前缀每次都略有不同（时间戳、随机 id、用户特定的开场白都会让缓存落空）。
把「哪类请求走哪档模型」写成能执行的规则
第三部分是路由规则。不要写成「重要请求用好模型」这种没法执行的描述，要写成判断条件：比如「只有当输入超过一定长度且需要多步推理时才升级模型」「分类、抽取、格式转换一律走小模型」「草稿用小模型、终稿用大模型」。
规则写好后，回测一下：拿过去一周的日志套一遍，算出「按新规则会花多少」。如果省下来的钱主要来自「把本该简单处理的请求降级」，那这条路对了；如果省下来的钱主要来自「减少重试」，那说明真正该修的是稳定性，而不是模型档位。
缓存那部分，先算清能省多少再改架构
缓存命中是最容易被神话的一块。它的前提是「前缀一模一样」：系统提示词、工具定义、以及放在最前面的那部分上下文都稳定，才能命中。很多团队以为自己在用缓存，其实每次请求都因为开头一行时间戳而落空。
做法是先量后改：在日志里区分「命中」和「未命中」的输入 token，算出当前命中率；再把系统提示词里会变动的部分挪到后面（或直接去掉），看命中率会不会明显上升。命中率上去之后省下来的钱是实打实的，而且不需要改业务逻辑。
每周只维护十分钟，比做一套系统更可持续
这套表不需要做成系统：三栏单价每月核对一次，用量分布每周从日志跑一次，路由规则改动时回测一次。关键是别追求「精确到分」——量级正确就足够支撑决策，追求万分之一精度反而会让你放弃维护。
唯一不能妥协的是口径一致：同一个指标前后要用同一套定义（比如「缓存命中」必须指厂商计费意义上的命中，而不是你自己在应用层做的缓存），否则趋势线会被你自己的口径变化骗到。