AI成本该算到谁头上？一套可落地的成本归因方案

月初收到云厂商账单：上个月模型调用花了八万。老板问：这八万块，哪来的？

如果你答不上来，说明你缺一套 AI 成本归因体系。模型的账单是一个总数，而你需要的，是把它拆到每个用户、每个功能、每个场景上。

为什么”总账”没有用

一个总数字能告诉你的只有”涨了还是跌了”。它无法回答：

• 是哪个功能在烧钱？是那个实验性的翻译功能，还是核心的客服 Agent？
• 是哪个客户造成的？有没有一个客户的用量就顶了半个公司？
• 是模型贵，还是我们 prompt 写得太啰嗦？
• 涨价是自然的业务增长，还是某个 bug 导致重复调用？

没有归因，所有的成本优化都是盲猜。

归因的最小单位：一次调用要带标签

核心思路是：每一次模型调用，都必须携带足够的上下文标签。

调用时至少要记录：

user_id       # 谁触发的
feature       # 哪个功能（客服/摘要/翻译…）
model         # 用了哪个模型
input_tokens  # 输入 token 数
output_tokens # 输出 token 数
cost          # 本次成本（按模型单价算）
latency_ms    # 延迟
timestamp     # 时间
request_id    # 唯一标识，用于追溯

feature 这个标签最关键，也最容易被忽略。它让”技术调用”变成”业务动作”，才能对上业务方要的账。

三种归因维度

有了标签，就能从三个方向切账：

1. 按功能：找出成本大头，判断它值不值。
2. 按用户/客户：算出每个客户的”AI 单位成本”，为定价和配额提供依据。
3. 按场景：比如”问答 vs 长文生成”，长文往往 token 数高，是优化重点。

一个实用指标是 单位业务成本，例如”每单客服对话的成本”、“每条内容的生成成本”。它比总成本更能反映效率。

落地：四步搭建

第一步：统一埋点

所有模型调用走同一个网关或封装层，在那一层统一埋点。不要指望各业务自己记得加标签，强制在基础设施层完成。

第二步：定义成本字典

为每个模型维护单价表，并定期更新。国产和海外模型价格差很大，混用时会严重失真。

第三步：归因到账单

把埋点数据聚合成日/周报表，与厂商账单对账。对不上的差额往往是遗漏的调用源，挖出来往往有惊喜（或惊吓）。

第四步：设预算与告警

给每个 feature、每个大客户设月度预算，超支告警。把成本从”事后看账单”变成”事中可干预”。

三个立竿见影的优化点

归因做完，你会发现钱通常漏在这几处：

• 重复调用：同样的 prompt 反复请求，加缓存即可省下可观比例；
• 过度使用大模型：简单任务用了最贵的模型，路由到小模型即可；
• 超长上下文：把整段历史都塞进去，其实只需要摘要。压缩上下文能直接降本。

一个反直觉的提醒

别把成本压到损害质量。 归因是为了让投入更聪明，不是无脑砍预算。一个花两块、能挽回一个客户的客服 Agent，比一个花两毛、把客户气跑的版本划算得多。看单位业务成本，而不是绝对成本。

结语

AI 成本归因的本质，是给每一分算力找一个责任人。数据、标签、字典、告警，四件事做齐，你就能从”又涨价了”的被动，变成”我知道该优化哪一块”的主动。下次老板问八万块花哪了，你可以打开一张按功能、按客户拆得清清楚楚的报表。