企业每月的大模型账单，为什么总说不清花在了哪儿？

这是「AI自动化指南」AI Gateway 系列的第四篇。

一笔说不清的账

月初，财务把上个月的大模型账单甩到群里：几十万。老板问一句"这笔钱主要花在哪儿了"，群里往往会陷入沉默——客服团队能说清自己那部分，知识库团队能说清自己那部分，但没有人能把这几十万加总起来，拆解成"谁花了多少、花在哪个模型上、值不值"。

这不是个例。企业规模化使用大模型之后，"账单说不清"几乎是必经的阶段。原因通常不是缺钱，也不是没人管，而是从一开始，调用记录就没有被放在同一个地方沉淀下来。

为什么总说不清

1. 调用记录散落在各个业务系统自己的日志里

即便所有业务系统都已经统一从网关领取 Key 来调用模型，如果网关本身不做计量记录，"谁调用了什么"这件事依然只存在于各个业务系统自己的应用日志里——格式不同、粒度不同，有的只记了"调用成功 / 失败"，有的干脆没记 Token 数。账单说不清的根源，从来不是"有没有用网关"，而是"有没有在统一的一层，把每一次调用都记下来"。

2. 调用次数不等于成本，Token 才是真正的计价单位

不同模型的定价可以相差几十倍，同一个模型的输入、输出 Token 单价通常也不一样（输出往往贵好几倍）。如果统计口径只停留在"调用了多少次"，一次简短问答和一次长文档总结在账本上会被算成完全一样的"一次调用"，实际花费却可能差几十上百倍。不区分模型、不区分输入输出 Token，统计出来的"用量"和真实的"成本"是两件事。

3. 一次业务请求，背后可能是好几次模型调用

一次知识库问答，背后往往是 Embedding → 向量检索 → Reranker → LLM 好几个环节串起来的。如果这几次调用发生在不同的服务、不同的模块里，没有人能把它们串成一条链路，算出"用户问的这一个问题，到底花了多少钱"——账本上看到的只是几笔互不相关的流水。

4. 有总数，没有维度，谁都不用负责

即便在网关或者供应商后台能看到一个月消耗了多少 Token、花了多少钱，如果这个数字不能按团队、按应用、按环境拆开，它就只是一个孤立的总数——回答不了"这笔钱该由谁负责"，更没法做部门间的成本分摊。

问题的根源：调用记录没有在统一的地方沉淀

以上问题，本质上都来自同一件事：每一次模型调用发生的时候，记录它的责任被交给了各个业务系统自己，而不是那个所有调用都必经的地方。

结果就是：一边是几十个格式互不相同的业务日志，一边是供应商甩过来的一张总账单，中间没有任何东西能把两者对上。

更合理的做法：在网关这一层统一计量，账本自动生成

网关本来就是所有模型调用的必经之路——不管是客服系统还是数据分析 Agent，请求最终都会经过网关转发给具体的模型后端。这意味着，只要在网关这一层把每一次调用的关键信息记下来，就不需要每个业务系统各自埋点、各自维护统计口径，一份统一的账本会自动生成。

具体来说，这一层至少要做到：

• Key 天然带着身份：每个业务系统持有的是网关为它单独签发的 Key，一条调用记录只要带上这个 Key，就自动知道"是哪个业务在调用"，不需要业务代码额外埋点上报；
• 区分输入 / 输出 Token，按模型定价换算成真实费用：而不是笼统的"调用次数"，不同模型、不同 Token 类型的单价都能在网关这一层统一换算；
• 按请求串联多级调用链路：一次问答背后如果触发了 Embedding、Reranker、LLM 好几次调用，网关能把它们串成一条链路，看到"一次真实的业务请求到底花了多少钱"，而不是几笔孤立的流水；
• 异常及时告警：某个 Key 或者某个应用的消耗速度突然偏离历史水平，可以在发生的当下就报警，不用等到月底账单出来才发现已经烧了多少钱；
• 数据可以直接导出：结构化日志、标准指标格式可以直接接入企业已有的 BI / 报表系统，不需要另起一套统计口径，也不需要人工每月对账。

账本从"月底被动收到的一个总数"，变成"调用发生的那一刻就已经写好的明细"

ModelPointer 如何解决这个问题

ModelPointer 在设计上，计量能力和转发能力是同一层的两件事——请求经过网关的同时，该记的都记下来了：

• API Key 独立签发：为每个下游业务系统单独签发 Key，调用记录天然带着"是谁在调用"的身份，不需要额外埋点；
• 完整访问日志：结构化 JSON 访问日志记录每一次调用的 Key、模型、输入 / 输出 Token、延迟、成功率，可以直接按应用 / 团队做聚合统计；
• Prometheus 指标与 OpenTelemetry tracing：既能看清楚"过去一小时每个团队消耗了多少 Token"，也能通过 tracing 看清一次请求里 Embedding → Reranker → LLM 的完整调用链路；
• 协议级独立计量：OpenAI 与 Anthropic 协议的调用各自独立统计，不会因为协议不同而漏记或者混算；
• 两种配置模式：无论是 YAML 热重载还是数据库配置，调整限流、路由策略都不需要业务系统重新发布，也不会中断已经在记录的计量数据。

结语

大模型的账单说不清，表面上看是"报表没做好"，实际上是"从调用发生的那一刻起，就没有一个统一的地方把它记下来"。

能不能说清楚一笔 AI 账单花在了哪，不取决于报表做得多漂亮，而取决于有没有在调用发生的那一刻，就把它记下来

把计量这件事收拢到网关这一层，业务系统不需要为了"算清楚成本"再多写一行埋点代码，账本会随着每一次调用自动生成。

官网：https://modelpointer.com · GitHub：https://github.com/modelpointer/modelpointer

---

关于这个系列

这是"AI Gateway 与企业 AI 基础设施"系列的第四篇。前三篇分别讲了这一层基础设施为什么会出现、为什么 API Key 不能直接下发给业务系统，以及私有化部署之后为什么仍然需要云端模型：

👉 为什么企业开始需要 AI Gateway？ 👉 企业为什么不能把大模型 API Key 直接发给业务系统？ 👉 为什么企业部署本地大模型后，仍然需要云端模型？

后面还会继续写这个系列，聊聊按任务复杂度做模型路由、私有化与云端的成本对比这些具体问题。想第一时间收到更新，欢迎关注公众号「AI自动化指南」：