先说结论：账单失控是结构问题，不是用量问题
我把线上 AI 应用的成本事故复盘过一遍，发现失控的从来不是「用户太多」，而是三个结构性问题——上下文膨胀、缓存缺失、模型滥用。这三个问题不解决，省下的都是零头；解决了，成本能压一个数量级。
来源一：上下文膨胀——每次调用都拖着整个历史
Agent / 多轮对话最常见的写法：把全部对话历史 + 全部检索结果原样塞进 prompt。第 10 轮时，一次请求的输入可能是第 1 轮的 20 倍。
解法（按收益排序）：
- 检索只带需要的内容：RAG 里召回 top-k 后，按相关性截断，别把 10 个 chunk 全塞进去（召回与重排讲过）。
- 上下文三层治理：最近几轮全量 + 历史滚动摘要 + 关键事实抽成结构化记忆。这一条通常能砍掉 40%–60% 的输入 token。
- 工具返回瘦身：工具调用结果截断到「够模型做决定」的长度，而不是把整张表丢回去。
来源二：缓存缺失——同一句话反复付钱
用户问「怎么请假」和「请假流程是什么」，模型每次都重新算一遍。语义相同的请求，是最大的可优化空间。
解法：
- 完全相同的 query：直接命中缓存（TTL 按业务定）。
- 语义相似：用 embedding 距离做短时缓存（阈值以上命中）。
- 检索结果缓存：同一知识库文档的 embedding 结果按版本缓存，别每次重算。
- RAG 场景把「检索结果 + 模型答案」一起缓存，命中时连模型调用都省了。
实测口径：接入两层缓存后，同场景月成本下降 30%–50%（缓存命中率要埋点观测，不观测等于没做）。
来源三：模型滥用——所有请求都走最强模型
90% 的请求用不上最强的模型：短回复、分类、抽取这类任务，小模型或专用模型又快又便宜。
解法：
- 模型路由：按任务类型和难度路由（分类→小模型，生成→中模型，复杂推理→大模型）。
- 先检索后生成：能命中知识库答案的直接返回，不调生成模型。
- 降级链：高峰期大模型排队时，先降级到小模型或模板答案（见降级与可观测）。
治理机制：成本要能「被看见、被限制」
技巧再多，没有机制都会偷偷反弹。我的固定配置：
- 成本观测面板：按「功能 × 模型 × 日均 token」切，每周看一次趋势，异常上涨当天定位（工具：Langfuse 可观测行）。
- 预算帽与熔断：每个功能设日预算，超阈值自动降级——不是报警等人处理，是系统自己先降级。
- 发布评审加一条：新功能的「单次调用成本 × 预估调用量」写进方案，超过某阈值必须过成本评审。这条我写进了架构评审清单的 AI 栏。
落地清单
- 上下文做三层治理（全量 + 摘要 + 关键事实）
- 检索与工具返回按需截断
- query 精确缓存 + 语义缓存 + 检索结果缓存
- 模型路由 + 降级链，别让所有流量打最强模型
- 成本面板 + 功能级预算帽 + 自动降级
- 新功能成本估算进评审
成本治理的边界在私有化部署篇讲——自建省 token 费还是调 API 划算，先算账再动手。