做 AI 应用有个很普遍的阶段：一开始只接了一个模型，成本还能凭感觉管；后来接了两三个，再后来搞了路由和降级，调用链变复杂了——突然发现账单看不懂了。
不是费用数字看不懂，而是不知道钱花在了哪里、花得合不合理、有没有优化空间。
这时候你需要的不是"少花钱"，而是"看清楚钱是怎么花的"。成本治理的前提是可观测，可观测的前提是有一套清晰的指标体系。
为什么多模型场景下成本治理更难
单模型的时候，成本计算很直接：调用次数 × 平均 token 数 × 单价。但多模型场景引入了几层复杂度：
- 不同模型定价结构不同：有的按输入输出分别计价，有的有最低消费，有的思维链 token 单独算
- 路由分发导致流量分布不固定：今天 60% 的流量走了 A 模型，明天可能因为 A 限流变成 40% 走 A、60% 走 B
- 降级和重试产生额外消耗：一个请求在 A 模型失败后自动切到 B 模型，实际消耗了两个模型的 token
- 不同模型的"token 效率"不同：同样一个任务，A 模型可能用 300 token 就能答好，B 模型需要 800 token
你盯着总账单看不出这些细节。所以需要把成本拆开，用指标体系来管理。
核心指标：四层框架
我把多模型成本治理的指标分成四层，从最基础的到最有业务价值的，一层一层建起来。
第一层：调用量指标（知道"用了多少"）
这是最基础的一层，但很多团队连这层都没做好。
| 指标 | 定义 | 为什么重要 |
|---|---|---|
| 总调用次数 | 一段时间内的 API 请求总数 | 成本的最大驱动因素之一 |
| 按模型拆分的调用次数 | 每个模型各被调用了多少次 | 看清流量分布 |
| 按功能模块拆分的调用次数 | 每个业务功能各调了多少次 | 定位成本大头 |
| 有效调用率 | 成功返回且结果被使用的请求占比 | 区分有效消耗和浪费 |
特别说一下"有效调用率"——这个指标容易被忽略，但价值很大。如果你有 20% 的调用因为超时、格式错误、结果不符合要求而被丢弃，那这 20% 就是纯浪费。治理的第一刀往往该砍在这里。
第二层：Token 消耗指标（知道"花了多少"）
调用次数只是一个维度，真正决定账单的是 token 消耗。
| 指标 | 定义 | 关注点 |
|---|---|---|
| 总输入 token | 所有请求的输入 token 总和 | 反映 prompt 和上下文的"肥瘦" |
| 总输出 token | 所有请求的输出 token 总和 | 反映模型回复的"啰嗦程度" |
| Thinking token 占比 | 推理 token 在总输出中的比例 | 识别推理模式是否合理 |
| 单请求平均 token 数 | 总 token / 总调用次数 | 快速判断是否有 token 膨胀 |
| P95 单请求 token 数 | 95% 的请求低于这个值 | 识别异常偏高的请求 |
在多模型场景下，这些指标需要按模型分别统计。因为不同模型的 token 单价不同，100 万 token 花在 GPT-4o mini 上可能就几毛钱，花在 Claude Opus 上可能是几十美元。你需要知道"贵的模型"用了多少 token。
第三层：成本效率指标（知道"花得值不值"）
前两层告诉你花了多少，这一层告诉你花得是否合理。
| 指标 | 定义 | 用途 |
|---|---|---|
| 单请求平均成本（CPR） | 总费用 / 有效请求数 | 最核心的效率指标 |
| 按模型的单请求成本 | 每个模型的 CPR | 发现哪个模型在"吃预算" |
| 按功能的单请求成本 | 每个业务功能的 CPR | 发现哪个功能的 AI 成本最高 |
| 降级额外成本率 | 因降级/重试产生的额外费用占总费用的比例 | 评估降级策略的成本代价 |
| Token 利用率 | 有效输出 token / 总消耗 token | 衡量"有多少 token 真正创造了价值" |
这里面"降级额外成本率"是多模型场景特有的。当一个请求在 A 模型失败后切到 B 模型，A 的 token 消耗是白花的。如果这个比例高于 10%，说明要么主模型的稳定性有问题，要么降级策略太激进（触发阈值设得太低）。
第四层：业务价值指标（知道"这钱花得有没有产出"）
前三层是技术视角，这一层是业务视角。这也是很多团队缺失的——他们能说清"AI 花了多少钱"，但说不清"这些钱带来了多少价值"。
| 指标 | 定义 | 示例 |
|---|---|---|
| AI 功能的业务贡献率 | AI 功能对核心业务指标的影响 | 用了 AI 摘要后，用户停留时长提升了 15% |
| 单次业务结果的 AI 成本 | 产出一个有价值的业务结果需要多少 AI 费用 | 每生成一篇合格的文章，AI 成本是 0.3 美元 |
| AI ROI | AI 带来的收入增量 / AI 总成本 | 省了 2 个人力但 AI 月费 500 美元 |
这些指标不一定能精确计算，但哪怕只是粗估，也能帮你回答一个关键问题：这个 AI 功能值不值得继续投入？
怎么把这套指标跑起来
理论说完了，落地的时候你会遇到一个现实问题：数据从哪来？
如果你的系统直接调各家模型的原生 API，那你需要自己采集这些数据——在调用层加埋点，把每次请求的模型、token 数、耗时、状态码、业务标签都记下来，然后写入日志或时序数据库，再搭 dashboard。
这套东西不难，但繁琐。对于小团队来说，投入产出比不高。
如果你已经在用 poloapi.top 做多模型接入和路由，它的调用分析面板已经覆盖了上面前三层大部分指标——调用量、token 消耗、成功率、模型分布、成本明细，开箱即用。你不需要自己写采集逻辑，直接在控制台就能看到数据。
第四层的业务价值指标需要和你自己的业务系统打通，这个没有通用工具能替你做，但前三层的数据是基础——有了前三层，第四层的计算就是在上面加一层业务逻辑的事。
几条落地建议
- 从"看得见"开始：不要一上来就想做精细化优化。先把基础指标跑起来，看一周的数据，你会发现很多"没想到"的消耗点。
- 给每个功能打标签：调用的时候带上功能标签（比如"智能摘要""客服问答""内容审核"），后续按功能分析成本才有依据。
- 设成本预警线：比如"日成本超过 X 美元就告警""单请求成本超过 Y 就标记异常"。不需要很精确，但能防止成本悄悄失控。
- 每月做一次成本复盘：看看哪些指标变好了、哪些变差了、哪些模型的性价比发生了变化。成本治理不是一次性工程，是持续的过程。
没有指标体系的成本优化，就是在黑暗中摸索。先把灯打开，再决定往哪走。
