AI 调用成本归因：Token 花到哪里，要能算清楚

AI 调用成本归因Token 花到哪里要能算清楚一、模型费用不能只看月底账单企业级大模型后端上线后成本很容易被低估。一次用户请求可能包含意图识别、检索改写、rerank、主模型生成、结果校验和安全审核。月底账单涨了团队才发现不知道钱花到哪个业务、哪个接口、哪个模板、哪个模型版本上。AI 调用成本必须做归因。不是为了抠每个 token而是为了知道哪些能力值得继续投入哪些链路需要优化哪些异常调用正在烧钱。二、成本归因要挂到调用链上每一次模型调用都应该绑定业务、用户侧请求和内部步骤。flowchart TD A[用户请求] -- B[业务 Trace] B -- C[意图识别调用] B -- D[RAG 检索改写] B -- E[主模型生成] B -- F[安全校验] C -- G[成本汇总] D -- G E -- G F -- G如果成本只按 API key 汇总就只能知道总费用无法做业务决策。三、成本记录要足够细下面是一个简化成本事件。public record ModelCostEvent( String traceId, String bizCode, String model, String step, long inputTokens, long outputTokens, long costMicroCents ) {}step字段很关键。主回答贵还是检索改写贵还是安全审核重复调用太多只有拆开才看得见。四、成本优化要先找异常模式常见浪费包括 Prompt 过长、历史上下文不压缩、低价值请求调用高价模型、失败后无限重试、同一结果没有缓存、批处理任务和在线请求抢额度。还要看单位价值。某个功能成本高但转化也高可能值得保留某个后台辅助功能成本不高但调用量巨大也可能需要降级。成本治理不能只按绝对金额排序。预算要能实时触发保护。比如单用户、单租户、单业务线、单模型都有日预算。超过阈值后可以降级模型、缩短上下文、关闭非关键步骤或要求人工确认。最后成本报表要给研发能行动的信息。只给财务金额没有用要能定位到接口、模板版本、模型版本和调用步骤。能定位才有优化入口。成本归因还要处理异步任务。在线请求触发一个后台总结任务后台任务又调用模型费用不能只算到“定时任务”名下。需要把父 trace 或业务批次传下去否则后台成本会变成无法解释的黑洞。缓存收益也要量化。语义缓存、结果缓存、模板压缩和上下文裁剪到底节省了多少 token要在报表里体现。否则优化做完很难证明价值后续也无法判断哪些策略值得保留。最后要避免为了省钱牺牲关键质量。低价值链路可以切小模型关键链路更适合先减少无效调用、压缩上下文和提升缓存命中。成本治理的目标是把钱花在真正产生价值的地方。成本异常也要有告警。某个模板突然 token 翻倍、某个租户调用量异常、某个模型错误重试激增都应该触发通知。等账单出来再处理已经过了最佳止损窗口。还要把成本和延迟一起看。便宜模型如果输出更长、重试更多、人工修正更多综合成本未必低。模型选型不能只比较单价要比较一次业务成功的总成本。最后成本归因要能支持 chargeback 或 showback。即使不真正向业务线收费也要让各团队看到自己的模型资源消耗。可见性本身就会减少很多无意识浪费。成本归因系统本身也需要成本管控。为了精细归因可能需要记录大量细粒度事件每次模型调用、每个 token、每个步骤这会消耗存储、计算和人力成本。在设计时需要做分层实时归因用采样或聚合数据支持告警和初步定位详细归因用离线批处理支持深度分析和优化决策历史数据定期归档或降精度存储。不能为了完美归因而构建一个比被观测系统还复杂的成本系统那样本身就是一种资源浪费。多租户场景下的成本分摊也是实际难题。一个 SaaS 平台有多个租户共享模型服务如何公平地分摊固定成本如基础模型调用、共享缓存、安全审核和变动成本如各租户的直接模型调用简单的按比例分摊会导致大户补贴小户或反过来需要设计更精细的分摊模型。一种做法是区分专属成本和共享成本专属成本直接计入对应租户共享成本按租户的调用量、数据量或 SLA 等级分摊。成本报表要能解释分摊逻辑否则业务团队会对账单产生质疑。五、总结AI 调用成本归因要把 token、模型、步骤、业务和 trace 串起来。月底账单只能说明花了多少钱细粒度归因才能说明为什么花、花得值不值、下一步怎么优化。