从月度总账到请求级归因：企业大模型调用成本治理实践

在企业大模型落地过程中，团队普遍能看到月度费用总额，但难以回答“具体由谁、在哪个项目、哪类调用产生”。本文给出一套可落地的工程方法：通过“虚拟凭证 + 运行时注入 + 请求级审计”，在不大改业务代码的前提下，实现分钟级成本可见与异常快速止损。

一、问题定义：为什么“有账单”仍然“难治理”

很多团队在生产环境会遇到以下情况：

1. 多个系统共用一组调用凭证，月末只有总额，缺少项目维度拆分。
2. 出现异常调用（重试风暴、循环任务、输出异常拉长）时，发现滞后。
3. 人员或项目变更后，历史环境变量中的凭证难以彻底回收。
4. 业务复盘时，缺少请求级证据链，难以完成成本与效果对照。

这类问题本质不是“单价高”，而是“归因口径不足”。

二、治理目标：先可见，再可控，再优化

建议分三步推进：

• 可见：每次调用都能回答“谁调用、调用什么、消耗多少、费用多少”。
• 可控：可按项目/环境/调用方设置预算、有效期、模型范围。
• 可优化：基于分钟级聚合做异常检测和策略迭代。

如果没有请求级可见性，后续优化通常只能靠经验判断。

三、方案设计：虚拟凭证与运行时治理层

可采用如下设计：

• 真实调用凭证统一保存在安全存储中；
• 业务侧仅使用“虚拟凭证”；
• 请求在运行时完成凭证映射与注入；
• 调用结束后写入请求级审计记录。

该设计的关键价值在于：把“身份、权限、审计、归因”统一到同一治理平面，而不是分散在多个脚本和环境变量中。

四、最小可落地实现（先做试点）

不建议一次性全量改造，可先在 2~3 个高频项目试点。

1）统一调用入口 通过 CLI、网关或 SDK 统一入口，保证每次调用都带项目与环境上下文。

2）定义最小审计字段 建议先记录以下字段（小而全）：

• timestamp
• caller（用户/服务）
• project
• environment（prod/staging/dev）
• requested_model
• actual_model
• prompt_tokens
• completion_tokens
• total_tokens
• unit_price_snapshot
• computed_cost
• latency_ms
• status_code / error_type
• trace_id

这组字段足以支撑成本归因、质量核验和故障定位三类需求。

3）分钟级聚合与基础告警 优先上线三条规则：

• 单项目分钟消耗突增告警；
• 单调用 Token 异常增长告警；
• requested_model 与 actual_model 不一致告警。

五、可复现示例：请求级记录长什么样

以下是一次调用的示例结构（字段示意）：

• timestamp: 2026-05-13 14:23:11
• project: customer-support
• caller: svc-support-prod-01
• requested_model: gpt-5
• actual_model: gpt-5
• prompt_tokens: 1287
• completion_tokens: 462
• total_tokens: 1749
• computed_cost: （按当时费率计算）
• latency_ms: 1830
• trace_id: 9f3a...

有了这类记录后，可直接回答：本次费用归属、是否异常、能否回溯到业务链路。

六、两周落地节奏建议

第 1 周：

• 停止新增共享真实凭证；
• 选 2~3 个项目接入统一入口；
• 打通最小审计字段采集。

第 2 周：

• 上线分钟级聚合看板；
• 配置三条基础告警；
• 输出首版项目级归因报表用于周会复盘。

先建立“可见性闭环”，再逐步做更细的策略优化。

七、结语

企业大模型成本治理不是单次“降本动作”，而是持续的工程能力建设。 当成本从“月度总账”下沉到“请求级账本”，团队才能实现：可审计、可回溯、可优化的稳定治理路径。