LLM API 很容易被错误地测量。请求数上升、token 用量上升、仪表盘变得更花哨，但团队仍然无法回答真正重要的问题：用户是否获得了可用的答案，延迟是否始终符合产品承诺，重试是否掩盖了提供商问题，以及被接受的结果是否符合预期成本？
正确的 LLM API 指标会把模型调用与产品结果联系起来。它们帮助工程、产品和财务团队就 AI 功能是否足够可靠以便扩展、是否足够便宜以便保留，以及是否足够可观测以便排障达成一致。
本指南为生产环境中的 LLM API 工作提供一份实用评分卡。在你理解什么是 LLM API之后、在比较直接使用提供商和通过网关接入时，或者当你的团队正从原型调用迁移到真实流量时，都可以使用它。
快速答案：衡量被接受的结果，而不只是 API 活动
常见的错误是测量包装层，而不是工作流。200 响应、token 数量、模型名称和总支出都很有用，但它们并不能证明产品从这次 LLM API 调用中获得了价值。
真正重要的指标是：
| 指标组 | 它回答的问题 | 为什么重要 |
|---|---|---|
| 被接受的响应率 | 应用是否收到了可用的答案？ | 原始 HTTP 成功并不能发现 schema 失败、错误的工具调用、拒绝回答和用户重新生成。 |
| 按用户路径划分的延迟 | 答案是否足够快地到达以满足这个工作流？ | 聊天、编码代理、批处理任务和工具工作流需要不同的延迟目标。 |
| 每个被接受输出的成本 | 有用输出的真实成本是多少？ | 仅看 token 单价会忽略重试、回退、被拒绝的答案以及长上下文浪费。 |
| 重试与限流健康状况 | 系统在真实需求下是否稳定？ | 隐藏的重试可能会在整体成功率变化之前，就增加延迟、成本和事故风险。 |
| 回退质量 | 备用路径是否在不破坏契约的情况下恢复了问题？ | 只有当最终答案仍然符合工作负载的质量、schema 和策略需求时，回退才有用。 |
| 审计完整性 | 团队能否快速解释一次糟糕的请求？ | 排障需要请求、密钥、工作负载、模型、路由、token、成本、延迟和错误上下文。 |
这就是操作视角。目标不是证明 LLM API 接收到了流量。目标是证明 API 层帮助某条产品路径变得更可靠、更快、更便宜，或者更易于运营。
指标 1：被接受的响应率
先从被接受的响应率开始，因为它最接近用户价值。
accepted_response_rate =
accepted_outputs / user_or_job_requests
在应用层定义 accepted_output。对于客服摘要器，它可能表示摘要通过了长度、语气和引用检查。对于编码代理，它可能表示补丁已应用且测试通过。对于信息抽取工作流，它可能表示 JSON 符合 schema 和置信度规则。对于聊天功能，它可能表示用户没有立即重试、升级处理或放弃。
每次 LLM API 请求至少跟踪以下字段：
| 字段 | 为什么重要 |
|---|---|
request_id |
让支持、工程和财务围绕同一事件进行讨论。 |
workload |
区分聊天、代理、抽取、增强和批处理路径。 |
requested_model |
记录应用请求了什么。 |
final_model |
记录实际生成答案的模型。 |
status |
区分成功、超时、速率限制、提供商错误、验证失败和策略拦截。 |
accepted_output |
说明结果是否产出了可用的产品价值。 |
retry_count |
显示一次可见请求背后的隐藏工作量。 |
fallback_count |
显示恢复是否改变了模型或提供商路径。 |
不要把 HTTP 200 / total requests 视为主要可靠性指标。它是基础设施信号。LLM API 可能返回一个技术上成功的响应，但产品上却失败了：JSON 格式错误、函数调用错误、缺少引用、不安全的拒绝、幻觉字段、答案不完整，或者响应到达得太晚。
指标 2：按路径计算延迟，而不是平均延迟
平均延迟通常是错误的数字。它掩盖了用户实际感受到的尾延迟，以及运维人员需要排查的路由问题。
对于交互式 LLM API 路径，请跟踪：
| 指标 | 最佳用途 |
|---|---|
| 首个 token 或首个 chunk 的时间 | 流式聊天、copilot、编码代理，以及任何进度很重要的 UI。 |
| 端到端时长 | 非流式回答、结构化输出、工具调用链和批处理作业。 |
| p90 延迟 | 面向大多数用户的产品体验评审。 |
| p99 延迟 | 事故复盘、提供商不稳定性，以及长尾回归检测。 |
对于后台工作负载，也要跟踪吞吐量：
| 指标 | 最佳用途 |
|---|---|
| 每秒 token 数 | 长文本生成、摘要和编码工作负载。 |
| 每分钟完成作业数 | 队列容量规划和 worker 健康状况。 |
| 经重试调整后的吞吐量 | 将失败和重试计入后的真实容量。 |
OpenTelemetry 的 GenAI 语义约定 定义了诸如 token 使用量、操作持续时间、首个分块耗时、每个输出分块耗时、服务器请求持续时间、首个 token 耗时、工作流持续时间、agent 持续时间、推理调用、工具调用以及工具持续时间等有用的原语。你不需要一次性实现每一个指标，但应尽早使用稳定的命名，这样你的 LLM API 遥测就不会在之后变成一次性的电子表格。
按以下维度拆分延迟：
- 工作负载；
- 流式与非流式；
- 请求的模型；
- 最终使用的模型；
- 提供商或路由；
- 重试次数；
- 回退次数；
- 提示词大小或上下文窗口分桶。
这样的分层能告诉你，延迟变化究竟是因为模型变慢了、提示词变大了、路由变了、某个提供商触及限制了，还是重试策略开始做了太多工作。
指标 3：每个被接受输出的成本
Token 价格并不等于生产成本。一个低价模型如果需要重复重试、产生被拒绝的答案，或者迫使人工检查低置信度输出，最终可能变得很昂贵。对于某些工作负载，一个高价模型如果能用更少的调用产出被接受的答案，反而更便宜。
使用这个 LLM API 成本指标：
cost_per_accepted_output =
total_workload_cost / accepted_outputs
然后将成本拆分为：
| 成本组件 | 它揭示了什么 |
|---|---|
| 首次尝试成本 | 当第一次调用成功时的基线成本。 |
| 重试成本 | 隐藏在一次用户可见请求背后的成本。 |
| 回退成本 | 恢复路径的成本。 |
| 被拒绝输出成本 | 未产生可用产品价值的支出。 |
| 长上下文浪费 | 由于发送重复或不必要上下文而产生的成本。 |
| 工具或媒体成本 | 与工作流相关的付费工具、图片调用、视频调用、浏览器操作或增强步骤的成本。 |
在财务审查中，按工作负载、密钥、环境、路由策略和最终模型报告成本。在工程审查中，在成本旁边加入被接受响应率。没有质量维度的成本图表，可能会把团队引向一个看起来便宜、却造成更多产品故障的模型。
这正是 Flatkey 的产品表面相关的地方。Flatkey 的公开文档描述了一个与 OpenAI 兼容的 REST API，地址为 https://router.flatkey.ai/v1，而其快速开始指南告诉用户在请求后查看 Usage Logs 以获取模型、token 数量、延迟和成本。这为团队提供了一个有用的基础账本。生产团队仍应在这份账本周围添加工作负载标签、被接受输出规则以及路由策略备注。
指标 4：重试、429 和速率限制压力
速率限制不只是提供商的文书工作。它们会改变延迟、成本和用户体验。
Flatkey 的 REST API 文档说明，API 请求使用 Bearer 身份验证，速率限制按 API 密钥应用，超过限制会返回 429 Too Many Requests。这意味着一个真正的 LLM API 仪表板应该区分提供方故障、客户端压力以及密钥级容量问题。
跟踪：
| 指标 | 公式或定义 | 关注点 |
|---|---|---|
| 429 rate | 429 responses / total requests |
激增意味着需要检查密钥级容量、突发流量形态或队列设计。 |
| Retry rate | requests with retry_count > 0 / total requests |
较高的重试率可能会把不稳定性掩盖在最终成功之下。 |
| Retry success rate | accepted outputs after retry / retried requests |
显示重试是恢复了价值，还是只增加了成本。 |
| Retry latency penalty | latency after retry - primary-success latency |
显示恢复带来的用户体验成本。 |
| Retry cost penalty | cost after retry - primary-success cost |
显示恢复带来的账单成本。 |
重试应该有预算。如果一个请求可以悄悄重试三次，产品可能看起来很可靠，但 p99 延迟和成本会失控。对于交互式路径，重试预算应该比后台任务更严格。对于批处理路径，排队可能比立即重试更好。
指标 5：回退恢复与回退不匹配
当回退能拯救一个本来会失败的请求时，它是有用的。当它返回一个破坏应用契约的答案、从而掩盖提供方问题时，它就很危险。
OpenRouter 的回退文档描述了：当主模型的提供方宕机、被限流，或因内容审核而拒绝回复时，尝试其他模型；它还指出，定价取决于最终实际使用的模型。OpenRouter 的提供方路由文档展示了诸如提供方顺序、允许回退、按价格、吞吐量或延迟排序，以及首选性能阈值等路由控制。具体实现因平台而异，但对于任何具有多个可选路由的 LLM API 来说，这些运维问题都具有普遍价值。
跟踪：
| 指标 | 公式或定义 | 回答的问题 |
|---|---|---|
| 回退触发率 | fallback_count > 0 的请求数 / 总请求数 |
主路由失败或选择备用路由的频率有多高。 |
| 回退恢复率 | 回退后被接受的输出 / 触发回退的请求数 |
回退是否 वास्तव वास्तव能恢复出有用的输出。 |
| 回退不匹配率 | 因 schema、tool、context、modality 或 policy 不匹配而被拒绝的回退输出 / 触发回退的请求数 |
备用路由是否兼容。 |
| 回退成本惩罚 | 回退成功成本 - 主路径成功成本 |
恢复在财务上是否可接受。 |
| 回退延迟惩罚 | 回退成功延迟 - 主路径成功延迟 |
恢复对于用户路径是否可接受。 |
| 最终路由可见性 | 记录了最终模型和提供方的请求数 / 总请求数 |
团队是否能够调试和审计路由。 |
对于 LLM API，回退应按契约测试，而不只是看可用性。如果主路径需要工具调用、JSON schema、较长的上下文窗口或特定的数据政策，那么回退路径必须满足相同要求，或者从该工作负载中排除。
指标 6：上下文效率
LLM API 的成本通常会随着上下文增长而上升。团队会发布更长的 system prompt，附加重复指令，加入检索结果，包含对话历史，并提高最大输出 token 数，却没有把这些变化和被接受的输出关联起来。
跟踪：
| 指标 | 为什么重要 |
|---|---|
| 每个被接受输出对应的输入 token 数 | 显示提示词和检索内容是否臃肿。 |
| 每个被接受输出对应的输出 token 数 | 显示响应是否比产品实际需要的更长。 |
| 上下文利用率 | 显示工作负载是否接近模型的实际上下文上限。 |
| 可缓存 token 占比 | 显示当提供方或网关支持缓存时，重复的提示词部分是否可以复用。 |
| 截断或上下文错误率 | 显示输入大小是否在生成质量评估之前就导致失败。 |
有用的复盘问题不是“哪一个模型的上下文窗口最大？”，而是“这个工作负载需要多少上下文才能生成一个被接受的答案？” 这样可以让模型选择与结果挂钩，而不是与最大规格挂钩。
指标 7：审计完整性
生产环境中的 LLM API 事故通常始于一个具体投诉：某个用户得到了糟糕的答案、某个任务变得昂贵、某个提供方变慢、某个 key 达到了限制，或者某个模型返回了格式错误的输出。审计完整性衡量团队是否能够快速重建该事件。
至少，每个生产请求都应连接：
| 审计字段 | 所需回答 |
|---|---|
request_id |
我们在讨论哪一个具体请求？ |
timestamp |
它是什么时候发生的？ |
api_key_id or environment |
是哪个应用、团队或环境发送的？ |
workload |
是哪个产品路径或作业发送的？ |
route_policy |
本应应用哪条规则？ |
requested_model |
应用请求了什么？ |
final_model |
谁做出了回应？ |
final_provider_or_route |
请求实际上去了哪里？ |
status and error_type |
发生了什么？ |
input_tokens and output_tokens |
完成了多少工作？ |
latency_ms and time_to_first_chunk_ms |
它有多慢？ |
cost |
它花了多少钱？ |
retry_count and fallback_count |
发生了多少恢复？ |
accepted_output |
应用接受了结果吗？ |
如果这些字段分散在不同工具中，LLM API 仍然可能正常工作，但运维会更慢。团队应该能够回答“发生了什么变化？”，而不必把供应商发票、应用日志、队列日志，以及五个仪表盘的截图拼凑在一起。
LLM API 记分卡
在供应商选择、网关迁移以及每月运营复盘时使用这张记分卡。
| 问题 | 指标 | 通过条件 |
|---|---|---|
| 用户是否获得了可用的答案？ | 已接受响应率 | 在模型或路由变更后，按工作负载保持稳定或更高。 |
| API 是否足够快？ | p90/p99 延迟和首个分块时间 | 满足每条用户路径的目标。 |
| 系统在实践中是否更便宜？ | 每个已接受输出的成本 | 在包含重试、回退、被拒绝输出和工具成本后更低。 |
| 限流是否可控？ | 429 速率、重试率、重试成功率 | 限流压力是可见的，不会悄然抬高成本或延迟。 |
| 备用路由是否有效？ | 回退恢复率和不匹配率 | 回退在不破坏 schema、工具、策略或质量的情况下恢复故障。 |
| 上下文是否可控？ | 每个已接受输出的输入 token 数和上下文错误率 | 提示词和检索增长产生可衡量的价值。 |
| 工程师能否调试事故？ | 审计完整性 | 请求、工作负载、路由、最终模型、状态、延迟、token、成本和错误类型都可见。 |
| 财务能否归因支出？ | 按 key、工作负载、环境、路由和模型划分的成本 | 支出可映射到负责人和产品路径。 |
如果某个工具无法暴露此记分卡所需的字段，请谨慎使用。你仍然可以将它用于实验，但在没有配套仪表化的情况下，它不应成为生产 LLM API 流量的运营控制平面。
一个简单的 30 天测量计划
你不必在第一天就拥有完美的可观测性栈。先从足够的结构开始，让下一次路由或模型决策可以被衡量。
第 1 周：定义工作负载和请求 ID
选择三到五个有代表性的工作负载：
- 一个交互式助手或聊天路径；
- 一个编码代理或工具调用路径；
- 一个批量抽取或增强路径；
- 一个高成本模型路径；
- 一个对回退敏感的路径。
添加 request_id、workload、environment、requested_model 和 status。没有这些字段，后续分析就会变成猜测。
第 2 周：添加结果和错误
为每个工作负载定义 accepted_output。然后用一个简短的列表来分类错误：超时、限流、提供方错误、验证失败、策略拦截、上下文错误和未知。避免使用过于细分的错误标签，否则图表会变得难以阅读。
第 3 周：添加延迟、token 和成本
采集操作时长、流式调用的首个 chunk 到达时间、输入 token、输出 token 和成本。按工作负载构建一个视图，再按最终模型构建一个视图。这通常足以发现第一个有意义的优化点。
第 4 周：比较路由和策略
比较：
- 直连提供方路径与网关路径；
- 旧模型与新模型；
- 仅主路径成功与回退成功；
- 每次请求成本与每个已接受输出成本；
- 平均延迟与 p90、p99 延迟；
- 同一工作负载下关闭重试路径与启用重试路径。
复盘应当产出一个路由或模型决策，而不仅仅是一个更漂亮的仪表盘。
Flatkey 的位置
当 LLM API 必须成为共享运营层，而不是单一提供方调用时，Flatkey 就很有相关性。当前 Flatkey 资料支持以下产品事实：
- Flatkey 提供一个与 OpenAI 兼容的 REST API，地址为
https://router.flatkey.ai/v1。 - API 请求使用 Bearer 认证。
- 同一个基础 URL 可用于各个端点、提供方和模型。
- Flatkey 的 API 文档列出了聊天补全、responses、embeddings、图像生成、视频生成和模型列表的端点。
- Flatkey 的快速开始说明，REST API、OpenAI SDK、Flatkey CLI 和编码代理路径共用一个密钥、一个账户余额和一个模型目录。
- 快速开始说明，Usage Logs 会在请求后显示模型、token 数、延迟和成本。
- Flatkey 的官网将产品定位为一个密钥、一个余额、官方模型、按次付费工具和一张发票。
这些都是衡量 LLM API 运行的有用基础指标。它们不能替代针对特定工作负载的指标。团队仍然需要定义可接受的输出、延迟目标、重试预算、回退策略和审计要求。
如果你已经在比较 API 层，可以将本文与 AI 路由 API 指标评分卡 一起阅读。如果你还处在更早阶段，可以先阅读 如何使用统一 AI API，然后在将生产流量切换之前再回到这份评分卡。
常见错误
错误 1：止步于 token 总数。
Token 总数告诉你消耗情况。它并不能告诉你输出是否被接受、重试是否抬高了账单，或者用户体验是否更好。
错误 2：把所有工作负载混在一起。
代码代理、客户支持助手、夜间补充任务和图像工作流不应该共用一个成功目标。
错误 3：把回退当作自动可靠性。
只有当备用路径满足相同的输出契约并产生被接受的结果时，回退才能提升可靠性。
错误 4：比较标价时忽略被拒绝的输出。
如果一个更便宜的模型会产生更多被丢弃的响应、更长的提示词或更多人工审核，那么它并不便宜。
错误 5：让日志只对工程师有用。
财务需要按所有者和工作负载查看支出。产品需要查看被接受的结果。支持团队需要按请求级别查询。LLM API 分类账应同时支持这三者。
常见问题
最重要的 LLM API 指标是什么？
最重要的 LLM API 指标是按工作负载划分的被接受响应率。它把 API 调用与产品是否真正收到了可用答案联系起来。
Token 使用量是 LLM API 的质量指标吗？
不是。Token 使用量是成本和容量信号。只有与被接受的输出、延迟和工作负载上下文结合起来时，它才有用。
LLM API 仪表盘应该重点关注平均延迟吗？
不应该。平均延迟不足以用于生产审查。应跟踪 p90 和 p99 延迟，以及流式路径的首个 token 或首个分块耗时。
团队应如何比较不同提供商之间的 LLM API 成本？
比较每个被接受输出的成本，而不只是 token 价格。要包含重试、回退、被拒绝的响应、长上下文浪费，以及工作流附带的任何工具或媒体调用。
LLM API 网关在什么时候有助于指标管理？
当团队需要一个基础 URL、共享模型访问、使用日志、计费可见性、路由策略、回退行为，以及跨多个提供商的审计上下文时，网关会很有帮助。它仍然需要来自应用的工作负载标签和被接受输出规则。
最终结论
LLM API 应该像生产基础设施一样衡量，而不是像演示端点一样衡量。请求数量、模型名称、token 总数和 HTTP 成功只是起点。
真正重要的指标是被接受响应率、按路径划分的延迟、每个被接受输出的成本、重试和限流健康状况、回退恢复、上下文效率以及审计完整性。按工作负载和路由策略跟踪这些指标，LLM API 就会更容易调优、更值得信任，也更容易在工程、产品、财务和支持团队询问“发生了什么变化”时作出说明。
从一个实际测试开始：选择一个真实工作负载，将其通过你当前的提供商路径以及 Flatkey 的 OpenAI 兼容基础 URL 发送，然后用同一张评分表比较接受的输出、最终模型、延迟、token 使用量、成本、重试次数和回退行为。
