模型越来越便宜，为什么你的 AI 账单反而更高？

如果你最近核对过 AI 服务的月度账单，可能会有一种错位感：模型单价明明在降，总支出却在涨。这不是错觉，而是应用从 Demo 走向生产时必然撞上的成本结构问题。

一、单价下降，掩盖了用量膨胀

过去两年，主流模型的单位 token 价格整体走低，这是公开事实。但与此同时，产品形态变了：从「用户问一句、模型答一句」的对话框，变成了常驻助手、后台批处理、定时任务和多步 Agent。单价降了 80%，调用量涨了 20 倍，账单当然是涨的。

经济学里管这叫杰文斯悖论：效率提升带来的不是总消耗下降，而是需求释放。放在 AI 上就是——便宜不会让你省钱，只会让你敢用更多。所以看到账单上涨，第一反应不该是「换更便宜的模型」，而是先搞清楚钱到底花在哪。

需要说明的是，下面四个漏斗是按「浪费程度」排序的，不是按技术难度排序。越靠前的越容易改，也越省。

二、漏斗一：上下文被无脑全量携带

这是最常见、也最容易被忽视的一笔钱。很多对话实现的做法是：把历史消息全部拼进 prompt 再发出去。结果是第 1 轮只带几百 token，到第 20 轮就带了几万 token——成本随轮数近似平方增长。

更关键的是结构问题：在多数请求里，输入 token 的占比远高于输出 token。也就是说，你付的大部分钱不是让模型「说话」，而是让它「读材料」。而其中一大半材料，其实和当前这一问毫无关系。

三、漏斗二：Agent 把一次问答变成几十次调用

Agent 的爽点在于自主规划，痛点也在于自主规划。一个看似简单的任务，背后可能是十几到几十次模型调用：规划一次、选工具一次、读结果一次、发现不对重试一次、最后反思一次。

真正烧钱的不是「正常路径」，而是失败重试。如果重试没有次数上限、没有幂等判断、没有在明显失败时提前终止，一个卡住的循环能安静地烧掉一整天的预算，而你的监控面板上只会显示「任务进行中」。

四、漏斗三：缓存没命中，等于重复付费

多数云厂商都提供上下文缓存或前缀缓存，命中后这部分输入的成本会大幅降低。但缓存能不能命中，取决于你的 prompt 前缀是否稳定。

常见的踩坑写法是：把当前时间戳、随机 request id、用户昵称放在系统提示的最前面。这样一来，每次请求的前缀都不一样，缓存永远不命中，你就在按原价反复为同一段模板付费。正确的做法是把稳定不变的内容（角色设定、规则、few-shot 示例）放前面，把动态变量放到最后。

五、漏斗四：所有请求都走旗舰模型

分类、打标、摘要、格式转换、意图识别这类任务，小模型的准确率通常已经够用，成本却可能只有旗舰模型的几分之一。很多团队不是不知道，而是缺少一个路由层——业务代码里直接写死了模型名，改起来要动几十个文件，于是就这么将就着。

六、四步把账单压回去

第一步，先让它可见。 给每次调用打上会话 ID、功能模块、用户维度的标签，做一张按功能拆分的成本看板。没有归因的优化都是猜。

第二步，给上下文做减法。 滑动窗口保留最近若干轮，更早的对话压缩成摘要，需要的历史细节走检索按需注入，而不是全量携带。

第三步，把前缀固化。 把 prompt 模板拆成「静态段 + 动态段」，静态段永远放最前，动态变量全部后置，让缓存能吃到。

第四步，加路由和熔断。 按任务难度分级路由到不同模型；同时给单次任务、单次会话、单日总量分别设 token 上限和调用次数上限，超限直接中断并告警。

结语

AI 成本从来不是运维问题，而是产品设计问题。同一句需求，设计成「每次全量重读」还是「增量携带」，成本可能差一个数量级。在模型还在持续降价的时间窗口里，先把结构性的浪费堵住，比等着下一次降价要划算得多。