这篇写给自掏腰包调 API 的独立开发者。做副项目、写小工具、跑自动化脚本，账单从几块钱悄悄涨到几百块，是挺常见的事。省钱的核心不在于找全网最便宜的模型，而在于让每一分钱都花在真正需要它的请求上。
一、模型分档，别一刀切
很多人习惯全项目用一个模型。更划算的做法是分三档：规则或小模型处理分类、抽取这类确定性任务；中档模型做摘要、改写；只有复杂推理和生成才交给旗舰模型。同样一段文本，便宜档和旗舰档的价格能差一到两个数量级，落到月账单上就是十倍差距。
二、上下文是最大的隐形开销
输入 token 单价低，但架不住量大。对话类应用很容易把完整历史每次都塞进去，聊到第十轮，单次请求的输入就膨胀到几千 token。两个办法：一是裁剪，只保留最近几轮加一条滚动摘要；二是给固定的 system prompt 和长文档开提示缓存，命中缓存的部分价格往往只有原价的一成左右。
三、加一层本地缓存和硬限流
同一个问题问两遍，没必要付两次钱。用 prompt 哈希做 key，把结果存进 SQLite 或 Redis，命中就直接返回。再给每个功能加日调用上限，防止调试时的死循环把额度烧光：
关键在 max_tokens 和 daily_limit 这两个硬约束，它们比任何花哨的优化都管用。
四、额度监控提前做
在控制台设预算告警，别等扣款短信来了才发现。如果项目有多个功能，给每次调用打个 tag，月底看哪个 tag 最烧钱。多数平台的用量面板能按模型拆开，比翻日志快得多。
五、一组真实对比
一个每天跑 2000 次的文章摘要机器人，最初用旗舰模型、每次带 3000 token 历史，月支出大概三四百元。换成便宜档模型、历史裁剪到 800 token、加上缓存后，命中率约四成，月账单降到三十元上下，摘要质量肉眼可见地差一点，但不影响使用。
省钱的顺序其实很清楚：先砍上下文，再换模型，最后才是缓存和限流。多数人反过来做，代码写了一堆，账单没降多少。
如果你也想试试一个Key调多个模型的方便，可以看看充站——¥50起步，额度永久有效，用支付宝/微信就能付款。