成本监控与归因

每个响应里都带着 token 计数。把它们记下来不花一分钱。大多数团队没记，然后从一张什么都说明不了的月度账单上第一次看清自己的成本结构。

按功能归因，而不是看总额

总支出数字只告诉你出了问题，不告诉你在哪儿出问题。有用的单位是每个功能、每次请求的成本。

给每次模型调用打上发起它的功能标签——摘要、分类、聊天、查询改写——然后再汇总。分布结果总是出人意料：某个谁都没在意过的功能常常占了大头，原因通常是它在每次页面加载时都跑，或者每次都重发历史。

有了功能维度的归因（attribution）之后，再加两个维度：

按用户或租户。 揭示支出是普遍分散，还是集中在少数几个重度用户身上，这决定了该优化还是该做速率限制。

按模型。 确认流量是不是落在了你预期的档位上。调用悄悄走到一个昂贵模型上，是常见又看不见的浪费。

主导账单的三件事

对话历史。 因为模型在两次调用之间没有记忆，每一轮都要重发整份记录，token 总量就随对话长度的平方增长。这是最常见的意外，而它在单次请求上看不出来——每一次调用看上去都还算合理。

要追踪平均对话长度和每次对话的 token 数，而不只是每次请求的 token 数。

检索到的上下文。 检索增强生成（RAG）的文本块在每次调用里都是输入 token。五个够用时检索了二十个，成本就永久地变成四倍。把每次查询检索的文本块数量当成一项成本指标来追踪。

模型档位。 档位之间的价格差着一个数量级，所以路由决策的影响盖过其他所有优化。

值得做进仪表盘的指标

每小时成本，配一个阈值告警。最典型的无监控事故是循环或失控的 prompt，直到月度账单上才发现；按小时追踪，一小时内就能抓到。

每个成功结果的成本，而不是每次请求的成本。一次便宜的调用如果失败后又重试了三次，就不便宜。这才是真正重要的数字，也是最少被算出来的那个。

输入输出比。 比值上升说明 prompt 在变长——通常是历史或检索到的上下文在悄悄膨胀。

缓存命中率，在 prompt 缓存生效的地方。命中率下降说明有东西破坏了前缀的稳定性，往往是一个时间戳或某个每次请求都变的值被挪到了 prompt 最前面。

各功能 token 数随时间的变化。 prompt 一改成本就会挪动，没有趋势图没人会注意到。

在代码里设限

监控告诉你已经发生了什么。限制才能防住它。

给每次调用设 max_tokens 上限。 它不是目标值，而是防止生成失控的天花板。

限制输入长度，在花钱发给模型之前。

按用户做速率限制，不要只做全局的。

给每次 agent 运行设迭代次数和总 token 上限——成本随步数平方增长，一个不设上限的循环就是一张不设上限的账单。

开启服务商的预算告警（如果有的话），把它当兜底，而不是主要手段。

优化之前

先测量。两周带归因的数据，会改变你原本打算优化的东西。

然后按影响大小依次拉动杠杆：模型档位，然后是对话历史，再是通过「稳定内容前置」实现的 prompt 缓存，然后是检索的文本块数量，最后是输出长度。

而且要把质量和成本放在一起评。一个把开销砍半却弄坏了某个功能的改动不算赢，所以评测应该和成本优化放在同一个循环里。

要点回顾

• 按功能归因，再按用户和模型归因——总额只能指出问题，归因才能定位问题。
• 三项主导成本：平方级增长的对话历史、检索上下文的体积、模型档位。
• 追踪每个成功结果的成本、带告警的每小时支出、输入输出比、缓存命中率。
• 在代码里强制执行上限：max tokens、输入长度约束、按用户的速率限制、agent 迭代与 token 预算。
• 优化之前先测两周，并把质量和成本放在一起看。

下一篇： 延迟优化