先把结论甩前面：大模型调用账单失控，九成是因为你把 input、output、cache 三种 token 混在一起当一个数看。拆开算，你会发现真正烧钱的往往不是你以为的那部分。我上个月就是这么把一个内部问答服务的月成本从 ¥2400 砍到 ¥780 的，过程比想象的无聊，但有用。

一、先看我当时那笔糊涂账

事情是这样。我们组有个跑了俩月的客服问答接口，接的是某主流大模型 API，每天大概 8000 次调用。财务月底甩给我一张截图，说这玩意儿怎么越来越贵，让我查。

我一开始也懵，盯着总价看了半天看不出门道。后来把每次请求的 usage 字段（prompt_tokens / completion_tokens / cached_tokens）单独 log 出来，跑了一周采样，才算看清。下面这张是我按真实采样拍的单次平均账（单价按当时那家的报价，单位是元/百万token，凑个整方便算）：

token 类型	单次平均量	单价(元/M)	单次成本	占比
input（系统提示+知识片段）	3200	4	0.0128	71%
output（回答正文）	380	12	0.00456	25%
cache 命中（复用部分）	0	1	0	0%
合计	—	—	0.0174	100%

看出问题没？我之前一直以为是 output 贵、回答太啰嗦，琢磨着去压回答长度。结果一拆——真正的大头是 input，占了七成。每次请求我都把一整段两千多字的系统提示 + 检索回来的知识片段原样塞进去，而且这段内容八成是重复的、几乎不变的。output 那点钱反倒是小头。

我当时有点惊到，方向差点搞反。

二、拆完之后，钱该往哪省

把三类拎清楚，省钱路径自然就出来了，优先级照着占比来：

1. input 大头 → 上 cache（最划算） 那段两千多字的固定系统提示，每次都全价重算太亏。开了 prompt caching 之后，命中部分的单价直接降到原来的四分之一甚至更低（各家折扣不一样，我那家是命中按 1/4 计）。光这一步，input 成本就掉了一半多。

2. 检索片段 → 砍冗余 RAG 召回我原来一股脑塞 8 段进去，其实前 3 段就够用了。把 top_k 从 8 调到 3，input 又瘦了一圈，回答质量肉眼看没掉。

3. output → 最后再管 确实有几个场景回答太长，加了句"控制在 150 字内"的约束。但说实话这步省的钱最少，我放最后做。

改完再采样一次的对比账：

项	改之前	改之后
input 单次成本	0.0128	0.0041
output 单次成本	0.00456	0.0030
单次合计	0.0174	0.0071
按 8000次/天月成本	¥2400	¥780

省钱结论一句话：先 log 出三类 token 的真实占比，谁占大头先治谁，别上来就瞎压 output。 cache 是性价比最高的那一刀，前提是你的 input 里有大块重复内容——客服、文档问答这类几乎都满足。

三、一个真实跑题：算账的活儿我后来甩给了个小助手

每天手动扒 log、按单价乘一遍、出对比表，烦。第三天我就不想干了。

后来我用那种零代码就能配智能体的工具，拖了个小助手出来——没写一行代码，把每天的 usage 数据喂给它，配了张单价表和我那套算账逻辑，让它自动出日报。现在每天早上它把"昨天三类 token 各花了多少、环比涨没涨、哪个接口异常"直接推给我。搭这玩意儿前后大概花了我一个下午，中间配检索那块卡了会儿，第一版输出干巴巴的全是数字没人话，调了两轮提示词才像样。

它也就干这种杂活，复杂判断还得我自己上。但每天省下来扒数据那二十分钟，挺香。

成本这东西，不拆开你永远以为是别处在烧钱。你们的大模型账单，大头是 input 还是 output？评论区报个数，我猜十个里有七个跟我一样、栽在 input 上。

（算账小助手挂的现成大模型 API 我走的 讯飞星辰MaaS，现成调，没自己折腾部署和算力。）