跳到主要内容

一周成本变化观察

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-21 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队第一次做 AI 成本复盘时，最先盯住的都是一个总数：这周花了多少钱，比上周多了还是少了。

这个数字当然重要，但它几乎永远不够解释问题。

我后来越来越相信，AI 成本看板如果只能回答“贵了没有”，那它对工程决策的帮助非常有限。真正有价值的是：这笔钱是被哪种请求、哪种失败路径、哪种系统漂移吃掉的。

前阵子我就碰到过一次很典型的情况：业务请求量几乎没变，但一周总成本突然涨了三成多。乍一看像是模型贵了，结果真正的问题根本不在模型单价。

先看一组更有用的周环比​

那次我们整理出来的数据大概是这样：

请求总量           +4%
总成本             +37%
平均输入 token      +42%
重试率             1.08 -> 1.61
回退到强模型比例    3% -> 17%
缓存命中率         34% -> 12%

只看总成本，你只能得到“这周更贵了”；
但把数据拆开之后，问题一下就清楚很多：

  • 请求量并没有大涨
  • 单次请求携带的上下文膨胀了
  • 失败重试把调用次数抬高了
  • 回退策略把一部分请求送到了更贵的模型
  • 缓存命中率下降，导致本来可复用的结果被重新算了一遍

这时你就知道，真正要查的是提示词和路由策略，而不是先去怀疑供应商调价。

成本变化往往是“系统拓扑漂移”​

为什么我现在很少把成本问题单独理解成“模型太贵”？因为线上实际更常见的是系统拓扑慢慢变了，只是团队没有第一时间察觉。

典型漂移包括：

1. Prompt 变胖了​

随着需求叠加，系统提示、few-shot、规则片段、历史上下文越塞越多。
单次请求看起来只是多了几百上千 token，但一周累计下来非常可观。

2. 检索结果放宽了​

RAG 一开始只拿 3 段文档，后来调成 8 段；
再后来又加了历史对话摘要和用户画像。
质量也许上来一点，但成本会先明显上涨。

3. 重试路径失控了​

如果超时、限流、解析失败都统一重试，而没有区分错误类型，系统就会在你没注意的时候把请求倍增。

4. 模型路由越来越保守​

一开始很多请求走轻量模型；
后来为了“先稳住效果”，回退阈值越放越宽，结果越来越多请求掉到强模型。

那一周里，真正的根因是什么​

最后我们追到了两个具体改动：

第一处：上下文拼装逻辑改了​

有个新版本为了“尽量给足信息”，把检索结果、规则摘要、最近三轮对话都无条件塞进了主请求。
这直接把平均输入 token 顶高了。

第二处：回退策略太激进​

原本只有结构化解析失败才会回退到更强模型，后来超时和空结果也一起走了回退。
一旦上游稍微抖一下，成本就会被放大。

这两个改动单看都像“稳妥的小优化”，叠在一起就变成了成本跳变。

我现在每周固定看 5 个指标​

如果只能选 5 个，我会看这几个：

  1. 每条业务链路的 cost / success
  2. 每个模型的平均输入 token 和输出 token
  3. 每类错误的重试率
  4. 回退到高价模型的比例
  5. 缓存命中率

原因很简单：它们对应的不是财务视角，而是工程动作。

  • token 膨胀对应上下文治理
  • 重试率对应失败分类
  • 回退比例对应路由策略
  • 缓存命中率对应系统复用能力

我更喜欢按“请求生命周期”记账​

现在如果要做 AI 成本看板，我不会只记录一条请求花了多少钱，而是尽量把生命周期拆出来：

select
  route,
  model,
  count(*) as requests,
  avg(input_tokens) as avg_input_tokens,
  avg(output_tokens) as avg_output_tokens,
  avg(retry_count) as avg_retry_count,
  avg(case when cache_hit then 1 else 0 end) as cache_hit_ratio,
  sum(cost_usd) as total_cost
from llm_request_logs
where created_at >= current_date - interval '7 day'
group by route, model
order by total_cost desc;

这类查询最有价值的地方是，你能立刻看见“最贵的是哪条业务路由”，而不是只知道总账单更大了。

成本优化不是一味换便宜模型​

很多时候，最有效的优化根本不是换模型，而是把系统里的浪费拿掉：

  • 把不必要的上下文裁掉
  • 把可缓存的输出缓存住
  • 把错误分类后再决定是否重试
  • 把简单请求从兜底大模型路由回轻量模型
  • 把工具调用成本单独拆账，不和推理成本混在一起

也就是说，成本优化更像一次系统治理，而不是一次采购动作。

总结​

一周成本变化观察，真正值得看的从来都不是“本周多花了多少钱”，而是“系统哪一层开始悄悄变胖、变绕、变保守了”。

对 AI 系统来说，成本不是事后统计数字，而是一种持续暴露架构问题的信号。你把链路拆得越细，后面的优化就越像工程；你只盯总账，它就永远只像焦虑。