一、算费用时最容易漏的三块
输入、输出、缓存。
大部分人只看单价，结果账单出来和估算差一倍。
二、输入 token 怎么增长
多轮对话里，每一轮都要把前面的内容再发一遍。
所以一个聊了二十轮的会话，后面几轮输入的 token 可能是前面的十倍。
这不是模型的问题，是设计问题。
三、输出 token 比输入贵
大多数平台输出单价是输入的两到四倍。
所以让模型“精简回答”不只是体验好，也是省钱。
四、缓存的价值
如果平台支持提示词缓存，固定不变的开头部分可以命中缓存，单价会降。
这就要求把固定内容放前面，变化内容放后面。
顺序错了，缓存就命不中。
五、一个简单的估算方法
```
单次成本 =
(系统提示词 + 历史 + 本次问题) × 输入单价
+ 回答长度 × 输出单价
```
再乘上日均调用量，就是账单。
四项里，最容易失控的是“历史”。
六、四个降本手段（按性价比排）
- 减少历史。只带最近几轮 + 摘要。
- 缩短系统提示词。把例子从十个减到三个。
- 控制输出。要求“不超过 300 字”。
- 换小模型。简单任务不给大模型。
四个都做，成本能降一半以上。
七、一个反直觉的发现
提示词写得长，不一定效果好，但一定更贵。
很多时候删掉一半例子，效果差不多。
八、一个建议
先算一笔再上线。
不估算就先上的项目，第一个月账单出来时往往很难接。
九、扩展阅读
想自己搭一套统计，基础的后端能力要有。
BackendWiki 的 Redis 专题里讲了计数与缓存，适合做调用量统计。