问一个团队上个月 LLM API 花了多少钱，大多数都答得上来。再问钱是哪个应用、哪个 agent、哪位同事花的——分别用在哪些模型上——得到的通常是耸耸肩，然后开一个表格工程。这篇文章描述一套方案，把成本归因变成基础设施自带的属性，而不是每月一次的取证作业。
核心思路很简单：所有模型调用走同一个网关，每个工作负载发一把自己的 API key，记账交给网关的账本。
为什么 provider 控制台不够用
如果你直接调两三家 provider，开销就散落在两三个控制台里，各有各的更新节奏、币种处理方式，连"一次请求"的定义都不一样。更麻烦的是，归因止步于账号层面：控制台能告诉你整个账号花了多少，却说不清是你的哪个服务调的——除非你给每个服务单开一个账号，那是在成倍增加账务负担，不是在减少。
常见的变通办法是在应用侧自己记日志：包一层 SDK 调用、估算 token 数、乘以一张手工维护的价格表，再祈祷没人调用你忘了录入的模型。它能用，直到某次价格调整或者有人新接了一家 provider，然后悄无声息地坏掉。
第一步：每个工作负载一把 key
网关把这个问题倒了过来。Router One 站在你的应用和 40+ 个受支持模型之间，每次调用本来就要经过这个知道模型、token 数和公开费率的地方。归因于是落到一条实践上：每个应用、agent 或环境，单独创建一把 API key。
sk-rk-...prod-chatbot给生产环境的助手sk-rk-...batch-pipeline给每晚跑的批处理任务sk-rk-...claude-code-alice给同事的 coding agentsk-rk-...staging给所有预发布环境
创建 key 免费，粒度由你掌握。每个工作负载有了自己的 key 之后，用量仪表盘直接给出每个负载一条开销曲线，你的代码里不需要加任何埋点。
第二步：读每请求 trace
聚合数据告诉你开销变了，trace 告诉你为什么。每条经过网关的请求都会记录模型、输入输出 token 数、按公开费率计算的成本、延迟、状态，以及实际服务它的路由。批处理任务的开销翻倍时，trace 能看出是请求变多了、prompt 变长了，还是悄悄切到了更贵的模型。
成本按各模型公开费率的按量付费 token 价位计算——也就是模型页上公布的每百万 token 单价——FX 和支付通道费在结账时单独展示。没有需要你维护的价格表，也没有估算环节：trace 记录的就是这条请求实际花掉的钱。prompt 和 completion 正文不留存，计量只用 token 数和元数据。
第三步：在出血之前设上限
只有归因、没有强制，你还是要等账单出来才在事后读到事故。每把 key 可以带三个限制：
- maxSpend —— 这把 key 最多能花多少的硬上限
- rateLimit —— 单位时间内的请求数
- tokenLimitTpm —— 每分钟 token 上限
staging 环境里的重试循环撞到 staging key 的上限就停了，生产照常运行。泄漏的 key 被自己的上限兜住，而不是掏空整个钱包。可用额度归零时，网关返回 HTTP 402，而不是默默累积意外欠费——计费语义在计价方法论页有详细文档。
第四步：按周复盘，而不是按月
有了按 key 的归因，一个值得养成的节奏是每周五分钟复盘：按开销给 key 排序，扫一眼各模型的用量分布有没有意外，看看有没有 key 快撞到上限。坚持这么做的团队，能在模型漂移和 prompt 膨胀还便宜的时候就抓住它们；具体的模式和仪表盘视图见 LLM 成本追踪和 LLM 可观测页面。
结论
成本归因不是事后补装的报表功能——把调用路由进同一个账本、用 key 给工作负载命名，它自然就有了。一次性把这套搭好，"谁花了多少钱、用在哪些模型上、为什么"就从季度悬案变成一个仪表盘视图。
从每个工作负载一把 key 开始，入口在 router.one；账本具体记录什么，见成本追踪概览。