> https://router.one/zh/blog/track-llm-api-costs-per-key 的 Markdown 镜像，供 AI 助手与爬虫使用。Router One 是 OpenAI 兼容的统一 LLM API 网关。
> 发布：2026-06-10 · 修订：2026-09-05 · 作者：Router One Team

# LLM 成本归因实践：每个应用、agent 与环境各一把 API Key

_一套靠网关账本落地的成本归因模式：每个应用或 agent 一把 API Key、按周复盘每把 Key、用消费上限拦住失控循环——这是 LLM 成本追踪产品页背后的操作方法。_

如果你要找的是产品页（每请求成本 Trace 与 Key 级上限），请看 [LLM 成本追踪](https://router.one/zh/llm-cost-tracking)；本文讲的是操作方法——怎样拆分 Key，让账本把花费归到正确的应用上。

问一个团队上个月 LLM API 花了多少钱，大多数都答得上来。再问钱是哪个应用、哪个 agent、哪位同事花的——分别用在哪些模型上——得到的通常是耸耸肩，然后开一个表格工程。这篇文章描述一套方案，把成本归因变成基础设施自带的属性，而不是每月一次的取证作业。

核心思路很简单：所有模型调用走同一个网关，每个工作负载发一把自己的 API key，记账交给网关的账本。

## 为什么 provider 控制台不够用

如果你直接调两三家 provider，开销就散落在两三个控制台里，各有各的更新节奏、币种处理方式，连"一次请求"的定义都不一样。更麻烦的是，归因止步于账号层面：控制台能告诉你整个账号花了多少，却说不清是你的哪个服务调的——除非你给每个服务单开一个账号，那是在成倍增加账务负担，不是在减少。

常见的变通办法是在应用侧自己记日志：包一层 SDK 调用、估算 token 数、乘以一张手工维护的价格表，再祈祷没人调用你忘了录入的模型。它能用，直到某次价格调整或者有人新接了一家 provider，然后悄无声息地坏掉。

## 第一步：每个工作负载一把 key

网关把这个问题倒了过来。Router One 站在你的应用和 [30+ 个受支持模型](https://router.one/zh/models)之间，每次调用本来就要经过这个知道模型、token 数和公开费率的地方。归因于是落到一条实践上：**每个应用、agent 或环境，单独创建一把 API key。**

- `sk-rk-...prod-chatbot` 给生产环境的助手
- `sk-rk-...batch-pipeline` 给每晚跑的批处理任务
- `sk-rk-...claude-code-alice` 给同事的 coding agent
- `sk-rk-...staging` 给所有预发布环境

创建 key 免费，粒度由你掌握。每个工作负载有了自己的 key 之后，[用量仪表盘](https://router.one/zh/llm-cost-tracking)直接给出每个负载一条开销曲线，你的代码里不需要加任何埋点。基于框架的工作负载也一样：一条 LlamaIndex RAG 流水线在它的 OpenAI 兼容 LLM 类上配自己的 Key（[LlamaIndex 接入指南](https://router.one/zh/integrations/llamaindex)），开销就是单独的一条曲线。

## 第二步：读每请求 trace

聚合数据告诉你开销*变了*，trace 告诉你*为什么*。每条经过网关的请求都会记录模型、输入输出 token 数、按公开费率计算的成本、延迟、状态，以及实际服务它的路由。批处理任务的开销翻倍时，trace 能看出是请求变多了、prompt 变长了，还是悄悄切到了更贵的模型。

成本按各模型公开费率的按量付费 token 价位计算——也就是[模型页](https://router.one/zh/models)上公布的每百万 token 单价——FX 和支付通道费在结账时单独展示。没有需要你维护的价格表，也没有估算环节：trace 记录的就是这条请求实际花掉的钱。计量使用 token 数和请求元数据。Router One 不留存直接 API 调用的 prompt 和模型回复正文，仅记录用于计费、用量统计与故障排查的请求元数据。Playground 会保存会话历史，方便用户回看和继续对话。

## 第三步：在出血之前设上限

只有归因、没有强制，你还是要等账单出来才在事后读到事故。每把 key 可以带三个限制：

- **maxSpend** —— 这把 key 最多能花多少的硬上限
- **rateLimit** —— 单位时间内的请求数
- **tokenLimitTpm** —— 每分钟 token 上限

staging 环境里的重试循环撞到 staging key 的上限就停了，生产照常运行。泄漏的 key 被自己的上限兜住，而不是掏空整个钱包。可用额度归零时，网关返回 HTTP 402（见[错误码速查页](https://router.one/zh/llm-api-error-codes)），而不是默默累积意外欠费——计费语义在[计价方法论](https://router.one/zh/pricing-methodology)页有详细文档。

## 第四步：按周复盘，而不是按月

有了按 key 的归因，一个值得养成的节奏是每周五分钟复盘：按开销给 key 排序，扫一眼各模型的用量分布有没有意外，看看有没有 key 快撞到上限。坚持这么做的团队，能在模型漂移和 prompt 膨胀还便宜的时候就抓住它们；具体的模式和仪表盘视图见 [LLM 成本追踪](https://router.one/zh/llm-cost-tracking)和 [LLM 可观测](https://router.one/zh/llm-observability)页面。

## 常见问题

**如何按应用或按同事追踪 LLM API 开销？**
所有调用走同一个网关，并给每个应用、agent 或环境单独创建一把 API key——创建 key 免费。之后[用量仪表盘](https://router.one/zh/llm-cost-tracking)直接给出每个负载一条开销曲线，代码里不需要加任何埋点。

**网关会为每条请求记录什么？**
每条请求都会记录模型、输入输出 token 数、按公开费率计算的成本、延迟、状态，以及实际服务它的路由。计量使用 token 数和请求元数据。Router One 不留存直接 API 调用的 prompt 和模型回复正文，仅记录用于计费、用量统计与故障排查的请求元数据。Playground 会保存会话历史，方便用户回看和继续对话。

**每条请求的成本是怎么计算的？**
成本按各模型公开费率的按量付费 token 价位计算——也就是[模型页](https://router.one/zh/models)上公布的每百万 token 单价——FX 和支付通道费在结账时单独展示。没有需要你维护的价格表，也没有估算环节：trace 记录的就是这条请求实际花掉的钱。

**能给单独一把 API key 设消费上限吗？**
可以。每把 key 可以带三个限制：maxSpend（这把 key 最多能花多少的硬上限）、rateLimit（单位时间内的请求数）和 tokenLimitTpm（每分钟 token 上限）。泄漏的 key 会被自己的上限兜住，而不是掏空整个钱包。

**额度用完会发生什么？**
可用额度归零时，网关返回 HTTP 402，而不是默默累积意外欠费。计费语义在[计价方法论](https://router.one/zh/pricing-methodology)页有详细文档。

## 结论

成本归因不是事后补装的报表功能——把调用路由进同一个账本、用 key 给工作负载命名，它自然就有了。一次性把这套搭好，"谁花了多少钱、用在哪些模型上、为什么"就从季度悬案变成一个仪表盘视图。

从每个工作负载一把 key 开始，入口在 [router.one](https://router.one/zh)；账本具体记录什么，见[成本追踪概览](https://router.one/zh/llm-cost-tracking)。

## 相关页面

- 本页规范地址：https://router.one/zh/blog/track-llm-api-costs-per-key
- LLM API 网关与路由：https://router.one/zh/llm-api-gateway
- 全部博客文章：https://router.one/zh/blog
- 模型与每模型 token 价格：https://router.one/zh/models （markdown：https://router.one/zh/models.md ）
- 定价：https://router.one/zh/pricing
- API 文档（markdown）：https://router.one/zh/docs.md
- 公司事实（markdown）：https://router.one/zh/facts/company.md