按密钥 AI 使用跟踪是一种运营实践：为每个 AI API 密钥明确指定所有者、环境、工作流和流量类别，然后按该密钥审查用量、成本、错误和配额事件。它的区别在于，你不仅知道“AI 账户本周花得更多了”，还知道是预发测试、生产功能，还是某个面向客户的集成导致了增长。
本指南已于 2026 年 6 月 17 日亚洲/上海时间，依据官方 OpenAI 使用与成本 API 指南、Cloudflare AI Gateway 日志和元数据文档、Vercel AI Gateway 可观测性文档，以及当前的 Flatkey 公开定价和站点快照进行了核查。请将所有仪表板标签、模型行、端点系列和定价单位视为某一时间点的证据；在生产流量上线前，请先在 Flatkey 定价中核实准确的行。
快速回答：每个密钥 AI 使用跟踪应证明什么
有用的按密钥 AI 使用跟踪应该回答五个问题，而不是让你陷入电子表格考古工程：
- 谁拥有这个密钥？ 工程、支持、增长、数据、客户工作区，或服务账户。
- 允许这个密钥在哪儿运行？ 开发、预生产、生产、批处理、评估，或面向客户的流量。
- 它允许调用什么？ 已批准的模型、端点系列、提供商、回退路由和模态类型。
- 它花了什么？ 请求数、令牌、缓存令牌、图像、视频任务、重试、回退尝试和成本。
- 当它偏离时会发生什么？ 告警、硬性上限、路由降级、密钥轮换、客户审核或财务审批。
实际目标不是为了多创建密钥而创建密钥。目标是让每个密钥足够小，以便成本归因、事故审查、配额策略和客户流量隔离都可以被审核。
为什么一个共享的 AI API Key 会破坏成本归因
单一共享的生产密钥看起来很简单，直到第一次使用量激增。当天的测试、cron 作业、模型评估、演示和客户流量都共用同一个凭证时，使用量图表只能告诉你“发生了什么”，却无法告诉你“是谁造成的”或“下一步该怎么做”。
按 Key 跟踪 AI 使用量通过让凭证边界与运行边界一致来解决这个问题。如果一个测试脚本运行过于频繁，测试环境就应该显示激增。如果某个客户细分消耗了高级模型预算，面向客户的那个 Key 就应该体现出来。如果一个批处理作业因昂贵的回退模型而重试，成本和事故复盘就应该归属于该批处理 Key。
| 共享 Key 问题 | 按 Key 跟踪的修复方式 | 复盘结果 |
|---|---|---|
| 测试环境会被算作生产支出 | 为非生产环境单独设置小额度 Key | 财务在查看生产成本时可以忽略测试噪声 |
| 客户流量与内部自动化混在一起 | 按工作区/层级使用面向客户的 Key 或元数据 | 支持团队可以将使用量与客户行为和套餐对应起来 |
| 一个泄露的 Key 需要大范围停机响应 | 缩小 Key 作用域并添加负责人标签 | 安全团队可以禁用单个 Key，而不会影响所有路由 |
| 回退和重试成本不可见 | 记录原始 Key、路由、重试次数、回退模型和最终状态 | 工程团队可以在无需猜测的情况下调整恢复行为 |
| 预算负责人对月度支出存在争议 | 通过 Key 所有权将使用量映射到团队、功能、客户或环境 | 财务可以在发票复核前完成使用量对账 |
用于预发布、生产和客户流量的关键分类矩阵
将此矩阵用作 按密钥的 AI 使用跟踪 推进的价值资产。具体的密钥名称应适配你的系统，但每个密钥都应有一个负责人、一个用途、一个重置窗口和一条升级路径。
| Key Scope | Allowed Traffic | Usage Fields To Review | Quota Policy | Incident Question |
|---|---|---|---|---|
| Development key | 本地实验、低量功能开发、模型冒烟测试 | 负责人、模型、端点、请求次数、状态、token 数、成本 | 非常小的硬性上限；除非获批，否则不使用高级模型 | 本地脚本或笔记本运行时间是否比预期更长？ |
| Staging key | 预生产 QA、带已批准限制的负载测试、发布验证 | 环境、发布、工作流、模型、延迟、token、错误、重试 | 与生产环境分开的上限；在负载测试窗口触发告警 | 预发布环境的使用是否意外地类似于生产流量？ |
| Production app key | 面向客户的线上功能和已批准的兜底路径 | 功能、客户细分、接受的结果、路由、使用单位、最终成本 | 更高的配额，配合软性告警以及提升额度的负责人审批 | 哪个功能或细分导致了支出或错误激增？ |
| Batch key | 回填、丰富化任务、评估、计划自动化 | 作业 ID、输入大小、输出大小、重试次数、已接受记录、每条记录成本 | 作业级审批、并发上限和停止条件 | 重试或被拒绝的输出是否放大了实际成本？ |
| Customer workspace key | 专属企业工作区、高流量客户或转售通道 | 工作区、套餐层级、模型、配额状态、超额、错误、使用单位 | 按层级设定上限，并向支持和财务开放可见性 | 客户是在经历正常增长、滥用还是套餐不匹配？ |
| Evaluation key | 模型基准测试、提示测试、提供商对比、预览路由 | 实验 ID、模型、数据集、token、缓存状态、输出接受情况、成本 | 较短的重置窗口；在预览或高级模型测试前需要审批 | 基准测试是否产生了不应计入生产环境的成本？ |
每个 API 密钥要记录什么
按密钥的 AI 使用情况跟踪 只有在该密钥出现在一条包含足够成本和上下文字段的日志记录中时才有效。最小记录应当便于工程、财务和支持团队阅读。
| 字段组 | 推荐字段 | 重要性 |
|---|---|---|
| 身份 | API key ID、所有者、团队、环境、工作流、客户或工作区标签 | 为每个请求提供预算和支持负责人 |
| 路由 | 提供商、模型行、端点族、路由组、备用路由、服务层级 | 显示流量是否转移到了更昂贵或更高风险的路径 |
| 使用情况 | 请求数、输入 token、输出 token、缓存 token、图像、视频任务、任务时长 | 防止仅按请求跟踪而掩盖长上下文或多模态成本 |
| 成本 | 预估成本、最终成本、计费单位、货币、重置窗口、预算所有者 | 将模型使用与财务审查和客户套餐关联起来 |
| 可靠性 | 状态、错误类别、延迟、首个 token 时间、重试次数、回退尝试、已接受输出 | 将健康增长与失败循环和昂贵恢复区分开来 |
| 治理 | 配额状态、告警阈值、审批工单、轮换日期、保留策略 | 使策略变更在支出或安全事件之后仍可审计 |
官方提供商和网关文档也指向同一个方向。OpenAI 的 usage API 支持按 API key 过滤，并可按 project、user、API key、model、batch 和 service tier 等字段分组使用情况；而 costs API 支持按 API key 过滤，并可按 project、line item 和 API key 分组成本。Cloudflare AI Gateway 文档描述了包含 provider、timestamp、status、token usage、cost、duration、user agent 和自定义元数据的请求日志。Vercel AI Gateway 可观测性文档则说明了按 project 和 API key 的请求摘要，以及带有 token 类型和成本的详细请求日志。请将这些作为有来源依据的设计模式，然后在你所运行的平台中核实确切字段和保留行为。
每个密钥的 AI 使用情况跟踪从独立的密钥范围开始
附加到一个共享密钥上的配额，仍然是共享配额。如果生产和预发布使用同一个密钥，预发布的压力测试可能会消耗生产所需的余量。如果客户流量和内部批处理作业共用一个密钥，支持团队可能会把由内部自动化造成的支出归咎于客户。
对于按密钥的 AI 使用情况跟踪，请在调优配额之前先建立密钥分类体系：
- 从环境开始：开发、预发布、生产和评估不应共用一个生产密钥。
- 按工作流风险拆分：批处理作业、代理、图像/视频生成以及回退较重的路径都应拥有各自的密钥或元数据标签。
- 按所有者拆分：每个高流量密钥都应由一个团队、客户、服务账户或成本中心负责。
- 在所有权清晰后再附加配额：对非生产环境和高风险路径设置硬性上限；对正常的生产增长使用软性告警。
- 记录超限后的处理路径：确定应用是阻止、降级、切换路由、请求审批，还是向所有者发出告警。
具体如何拆分取决于流量规模。小团队可能从开发、预发布、生产和批处理密钥开始。更大的团队可能会增加客户工作区密钥、模型评估密钥、支持自动化密钥，以及用于高成本图像或视频路径的独立密钥。按密钥的 AI 使用情况跟踪的判断标准很简单：如果两类流量需要不同的所有者、配额或事件处理动作，那么它们很可能不应该被隐藏在同一个密钥之后。
按 Key 跟踪使用情况如何帮助事件复盘
当使用量激增时，第一反应不应该是“API key 在谁手里？”，而应该是“哪个受限 key 发生了变化？”这就是按 key 进行 AI 使用跟踪不仅属于财务报表，也应纳入事件复盘的原因。
| 事件信号 | 按 Key 复盘应展示的内容 | 可能的动作 |
|---|---|---|
| 支出激增 | Key、所有者、模型、单位、路由、客户/工作流，以及重置窗口 | 发出告警、降低配额、切换路由，或批准计划内使用 |
| Token 激增 | 输入/输出拆分、提示词大小、缓存行为、可接受结果率 | 限制输入大小、缩短输出、改进缓存策略，或调整提示词 |
| 重试循环 | 原始错误、重试次数、备用路由、最终状态、每个可接受输出的成本 | 增加停止条件、退避机制、不可重试错误类别，或备用上限 |
| 客户投诉 | 工作区 key、配额状态、近期使用情况、失败请求模式、模型路由 | 调整客户配额、调试路由、解释套餐限制，或升级支持处理 |
| 可能的 key 泄露 | Key 所有者、来源环境、请求来源、异常模型或端点 | 禁用或轮换某一个受限 key，并保留不受影响的流量 |
如何在 Flatkey 中测试按密钥 AI 使用跟踪
Flatkey 的公开网站将该平台定位为面向生产 AI 团队的单一 API 网关，提供模型访问、路由、计费、使用分析和运营控制。本文核查的公开定价页显示，Flatkey 在 23 家提供商下列出了 638 个 AI 模型，并包含诸如 /v1/chat/completions、/v1/responses、/v1/images/generations、/v1/video/generations、Anthropic Messages 和 Gemini generateContent 等端点系列。请将这视为截至 2026 年 6 月 17 日的快照，而不是永久可用性的保证。对于按密钥 AI 使用跟踪，真正有价值的证据不只是目录规模；而是你的当前密钥、模型行、端点系列和使用日志是否能在请求后一起被审查。
一个实用的 Flatkey 验证计划，用于按密钥 AI 使用跟踪，应如下所示：
- 打开 Flatkey pricing，确认你计划使用的确切模型行、提供商、端点系列、可用性状态和计费单位。
- 为预发布、生产、批处理和面向客户的流量创建或选择独立的密钥。如果你的仪表板标签不同，请在上线说明中记录当前标签。
- 通过预期的端点和模型路由，为每个密钥运行一次低风险冒烟测试。
- 在每次请求后查看 Flatkey dashboard 的使用情况和计费可见性。确认你的团队将用于审查的密钥、模型、状态、使用单位和成本字段。
- 设置一个故意较低的预发布配额，并在向用户公开路由之前测试超限行为。
- 为每个密钥记录升级路径：负责人、告警阈值、配额审批人、轮换负责人和回滚路径。
- 对任何文本、图像、视频、批处理或回退路由重复测试，因为仅凭请求次数不足以进行多模态成本审查。
此测试计划避免假设精确的执行语义。在将某条路由用于生产控制之前，请先验证当前的仪表板标签、当前模型行、当前计费单位、日志字段、配额行为和 API 响应。
模板：按密钥使用记录
为每个生产或面向客户的密钥保留一份简明记录。该记录会将按密钥的 AI 使用跟踪变成一种日常运营习惯，而不是一次性查看仪表板。
按密钥 AI 使用记录
密钥 ID 或标签：仅限非秘密标识符
负责人：团队、服务账号、客户工作区或预算所有者
环境：开发、预发布、生产、批处理、评估或面向客户
允许路由：提供商、模型行、端点族、回退路由和模态
使用字段：请求数、输入 token、输出 token、缓存 token、图片、视频任务、时长
成本字段：预估成本、最终成本、定价单位、货币、重置周期
配额策略：硬上限、软提醒、审批负责人，以及超限时的产品行为
事件字段：状态、错误类型、重试、回退尝试、可接受输出率
审查频率：上线日、每周运营、每月财务或客户成功审查
轮换计划：负责人、日期、触发条件和回滚路径
不要在此记录中存储真实的 API 密钥。请使用非秘密的密钥标签或仪表板 ID，以便该记录可以与财务、支持和事件响应人员共享。
常见错误
- 在所有地方使用一个生产密钥：预发布环境、演示、定时任务和客户流量都需要单独归因。
- 跟踪请求而不是单位：长提示、缓存 token、图像生成和视频任务具有不同的成本形态。
- 跳过所有者标签：没有团队、客户或服务所有者的密钥在事故处理中会变得无法审查。
- 先设置配额再做分类法：当密钥范围不清晰时，配额更难调优。
- 忽略重试和回退成本：被接受的输出可能比第一次尝试的请求贵得多。
- 假设仪表板标签是永久的：在编写运行手册之前，请验证当前字段、导出、保留策略和计费单位。
- 在运行手册中嵌入密钥：记录非机密的密钥标签和所有权，而不是原始 API 密钥。
常见问题
什么是按密钥的 AI 使用情况跟踪？
按密钥的 AI 使用情况跟踪是按 API 密钥审查 AI API 的使用量、成本、配额状态、错误和归属的做法。它帮助团队区分预生产、生产、批处理、评估和面向客户的流量，而不是将所有 AI 支出都视为一个账户级总额。
为什么预生产和生产应该使用不同的 AI API 密钥？
预生产和生产应该使用不同的 AI API 密钥，因为它们有不同的负责人、风险级别、配额和事件响应。预生产压测不应消耗生产余量，也不应让财务误以为线上客户流量变得更昂贵。
我应该按 API 密钥跟踪 LLM 使用情况的哪些内容？
对于按 API 密钥的 LLM 使用情况，跟踪负责人、环境、工作流、模型、提供商、端点、请求数、输入 tokens、输出 tokens、缓存 tokens、状态、延迟、重试、备用路由、配额状态和最终成本。对于多模态路由，还要添加图像、视频、音频或作业时长单位。
API 密钥使用情况跟踪能帮助进行客户成本归因吗？
可以，当密钥或元数据标识了客户工作区、套餐等级或路由负责人时，API 密钥使用情况跟踪可以帮助进行客户成本归因。它对于企业客户、转售商路由、高流量工作区和支持调查尤其有用。
按密钥的 AI 使用情况跟踪与配额管理有什么关系？
按密钥的 AI 使用情况跟踪显示是谁使用了预算，以及是哪条路由产生了成本。AI API 配额管理决定应对该密钥应用什么限制、告警、审批或阻止。先使用跟踪来了解范围，然后为该范围设置配额。
最终审核步骤
在扩展 AI 功能之前，请审查所有可能到达该路由的密钥。每个密钥都应有负责人、环境、允许的模型、配额策略、使用记录、事件处理路径和轮换计划。这就是按密钥的 AI 使用跟踪的核心：让测试环境、生产环境、批处理和客户流量保持足够隔离，从而让成本、计费和事件由正确的负责人处理。
对于更广泛的运营栈，请将本指南与AI API 配额管理指南、AI 模型定价对比以及企业 AI API 网关检查清单搭配使用。
查看定价：在分配生产、测试或面向客户的密钥之前，请使用Flatkey 定价确认当前的模型行、端点系列和计价单位。
