真正重要的 AI 路由 API 指标
AI 路由 API 应该让生产环境中的 AI 调用更易于运维，而不仅仅是更容易发起。如果你检查的唯一仪表盘只是按模型统计的总 token 数，你就可能错过路由本该解决的问题：请求失败、首个 token 过慢、嘈杂的回退、隐藏的重试成本，以及事后很难解释的事故。
真正有用的问题很简单：在流量经过 AI 路由 API 之后，你的团队能否证明可靠性、延迟、成本控制和调试都得到了改善？
本指南提供了一份实用的评分卡。当你在评估 AI 路由 API 工具、审查现有的 LLM 网关，或者判断直接使用各家提供商账号是否仍然足够时，都可以用它。
快速答案：衡量结果，而不是路由活动
路由活动很容易统计。网关可以显示请求量、模型名称、提供商名称和总支出。这些都是必要的，但它们并不能证明 AI 路由 API 正在发挥有用的作用。
真正重要的指标是：
| 指标组 | 回答的问题 | 健康信号 |
|---|---|---|
| 请求结果质量 | 用户是否得到了可用的答案？ | 按工作负载统计，成功、被接受且无需重试的响应更多 |
| 回退有效性 | 回退是否真正修复了故障？ | 回退能恢复事故，同时不会产生错误输出或失控的成本 |
| 延迟与吞吐量 | 路由是否改善了用户体验？ | 交互路径的 p90/p99 延迟更低，批处理路径的吞吐量可预测 |
| 按可接受输出计的成本 | 路由后的答案在实际中是否更便宜？ | 将重试、回退、失败调用和被拒绝输出都纳入后，总成本更低 |
| 可观测性与可审计性 | 团队能否解释发生了什么？ | 每个请求都能关联到 key、路由、模型、提供商、策略、成本和错误类别 |
这就是模型选择器和运行层之间的区别。模型选择器只决定调用发往哪里。生产环境中的 AI 路由 API 还会帮助你理解这个选择是否有效。
指标 1：请求结果质量
先从请求结果开始，因为它们最接近用户价值。如果响应验证失败、破坏了 schema、不该拒绝却拒绝了，或者迫使用户重新生成，那么更便宜或更快的路由也没有意义。
要在工作负载级别跟踪结果，而不只是模型级别。支持摘要、代码审查代理、产品图片工作流和批量补全任务，都应该有各自的基线。
为每一次路由调用记录这些字段：
| 字段 | 其重要性 |
|---|---|
workload |
将面向用户的产品路径与内部任务区分开来 |
route_policy |
显示调用是否使用了延迟、成本、质量、区域或回退规则 |
requested_model |
记录应用请求的内容 |
final_model |
记录实际生成响应的内容 |
status |
区分成功、提供商错误、超时、速率限制、验证失败和策略阻止 |
accepted_output |
表明结果是否通过了你应用自身的质量门槛 |
retry_count |
显示单个看似请求背后的隐藏工作量 |
fallback_count |
显示路由是否更改了提供商或模型路径 |
最有用的单一指标是接受响应率：
accepted_response_rate =
accepted_outputs / user_or_job_requests
不要用原始 HTTP 成功率来代替。即使返回 200，如果输出违反 JSON schema、缺少工具调用、生成了错误的模态，或者到达时已太晚而不适合产品交互，响应仍然可能无法使用。
对于 AI 路由 API，这一指标应按 workload 和 route policy 进行审查。如果在新的路由规则之后接受响应率下降，即使模型支出看起来更好，这条规则也在损害产品。
指标 2：回退效果
回退是团队采用 AI 路由 API 的主要原因之一，但回退也可能具有误导性。回退事件并不总是好的。只有在它修复了用户可见的失败，同时又没有让结果变得更差或过于昂贵时，它才是好的。
跟踪这些回退指标：
| 指标 | 公式或定义 | 需要关注什么 |
|---|---|---|
| 回退触发率 | 至少发生一次回退的请求 / 总请求数 | 激增表明提供商不稳定、限制设置不当，或超时时间过于激进 |
| 回退恢复率 | 回退后的接受输出 / 触发回退的请求 | 恢复率低意味着回退路径只是摆设 |
| 回退代价 | 仅主路径成功与回退成功之间的延迟和成本差值 | 较高代价可能足以证明需要不同的主路由 |
| 回退不匹配率 | 因 schema、工具、模态或策略不匹配而被拒绝的回退输出 | 显示备用模型是否真正兼容 |
| 最终路由可见性 | 已记录最终模型/提供商的请求占比 | 调试和成本审查所必需 |
回退恢复率是高管能够理解的指标：
fallback_recovery_rate =
accepted_outputs_after_fallback / requests_that_triggered_fallback
对于开发者来说，更重要的指标是 fallback mismatch rate。如果你的主路由支持结构化输出、工具调用、长上下文窗口或图像生成参数，fallback 也必须支持相同的契约。否则，AI 路由 API 可能会隐藏提供方故障，却引入应用故障。
Flatkey 的 REST API overview 将其 API 表述为与 OpenAI 兼容，使用 https://router.flatkey.ai/v1，并为端点、提供方和模型提供一个基础 URL。这种兼容性在迁移期间很有用，但运行指标仍然需要检查每个工作负载的最终路由和输出契约。
指标 3：按百分位划分的延迟和吞吐量
平均延迟掩盖了用户能感受到的痛点。使用 p50 了解正常路径，使用 p90 了解大多数面向用户的预期，使用 p99 进行事故复盘。
对于交互式产品，请衡量：
| 指标 | 用途 |
|---|---|
| 首次 token 或首个 chunk 的时间 | 聊天、代码代理、流式助手，以及任何进度很重要的 UI |
| 端到端时长 | 非流式响应、结构化输出、图像任务和工具调用 |
| 按路由策略划分的 p90 延迟 | 面向用户的 SLO 复核 |
| 按提供方和最终模型划分的 p99 延迟 | 事故和尾部风险复盘 |
对于批处理或代理型工作负载，吞吐量可能比首 token 速度更重要：
| 指标 | 用途 |
|---|---|
| 每秒 token 数 | 长生成任务、代码代理、摘要、提取 |
| 每分钟完成的作业数 | 队列健康状况和 worker 规模设定 |
| 重试调整后的吞吐量 | 错误和 fallback 之后的真实吞吐量 |
OpenTelemetry 的生成式 AI 语义约定很有用，因为它定义了诸如 token 使用量、操作时长、首个 chunk 用时以及每个输出 chunk 用时等指标。你不必在第一天就复制整个 schema，但应避免发明一次性的命名方式，否则后续可观测性会很痛苦。
对于 AI 路由 API，百分位指标应始终按以下维度细分：
- 工作负载
- 路由策略
- 请求的模型
- 最终模型
- 最终提供方或路由
- 流式与非流式
- 重试和 fallback 状态
这种细分才能把图表变成可操作的答案。没有它，你可以看到延迟变差了，但不知道原因是提供方、模型、路由规则、重试风暴，还是工作负载变化。
指标 4：每个已接受输出的成本
token 价格只是起点。它不包括失败尝试、重试、fallback 尝试、被拒绝的响应、长上下文浪费，或调试路由事故所花费的人力时间。
在生产环境评审中，计算每个已接受输出的成本：
cost_per_accepted_output =
total_cost_for_workload / accepted_outputs
然后将这部分成本拆分为：
| 成本组成 | 重要原因 |
|---|---|
| 主要尝试成本 | 如果没有失败的基线成本 |
| 重试成本 | 来自瞬时故障和严格超时的隐藏成本 |
| 回退成本 | 恢复路径的成本 |
| 被拒绝输出成本 | 未产生可用产品价值的支出 |
| 工具或媒体成本 | 对于调用付费工具、图像 API 或视频 API 的工作流是必需的 |
当比较直接的提供商账户与 AI 路由 API 时，这一点尤其重要。直接账户在标价上看起来更便宜，但如果速率限制、停机或缺少模型导致重试和人工工作，其每个已接受输出的成本仍可能更高。反过来也可能成立：路由器看起来很方便，但如果每条回退路径都落到高价模型上，它就会变得昂贵。
Flatkey 的 模型目录 在这里很有用，因为它展示了模型比较维度，例如价格、上下文、速度和实时健康状态。正确的运营指标不是“这个模型的标价是不是最低？”而是“这条路由是否以最低的可靠成本为该工作负载产出了已接受输出？”
指标 5：可观测性和可审计性
最强的 AI 路由 API 指标通常不是图表，而是工程师能否在五分钟内回答一次事故问题。
对于每个生产请求，记录足够的上下文以重建路由：
| 审计字段 | 所需答案 |
|---|---|
request_id |
我们讨论的是哪一个具体请求？ |
api_key_id 或环境 |
哪个团队、应用或环境发送的？ |
workload |
哪个产品路径或任务发送的？ |
route_policy |
本应应用哪条规则？ |
requested_model |
应用请求了什么？ |
final_model |
谁响应了？ |
final_provider_or_route |
请求实际去了哪里？ |
status 和 error_type |
发生了什么？ |
input_tokens 和 output_tokens |
完成了多少工作？ |
cost |
花了多少钱？ |
latency_ms 和 time_to_first_chunk_ms |
有多慢？ |
retry_count 和 fallback_count |
发生了多少隐藏的恢复过程？ |
Flatkey 的 快速入门 建议用户在第一次请求后检查 Usage Logs，并期望看到模型、token 数、延迟和成本。这是正确的基础。对于生产环境，还应添加所有权、路由策略、结果状态和回退上下文，以便日志能够支持事故审查和财务审查。
AI 路由 API 评分表
在购买前、迁移后以及每月复盘时，请先使用这张评分卡。
| 问题 | 指标 | 通过条件 |
|---|---|---|
| 用户是否拿到了可用的答案？ | 已接受响应率 | 路由变更后，按工作负载保持稳定或更高 |
| 回退是否真的在恢复故障？ | 回退恢复率 | 足够高，足以证明新增路径复杂度是合理的 |
| 回退是否兼容？ | 回退不匹配率 | 足够低，以至于回退不会造成应用层故障 |
| 用户体验是否在改善？ | p90/p99 延迟，首块返回时间 | 满足特定工作负载的 SLO |
| 系统在实际中是否更便宜？ | 每个已接受输出的成本 | 在计入重试、回退和被拒绝输出后更低 |
| 工程师能否调试事故？ | 请求审计完整性 | 路由、最终模型、错误、延迟、token 和成本都可见 |
| 财务能否审查使用情况？ | 按 key、工作负载、路由和模型划分的成本 | 支出可映射到负责人和产品路径 |
| 团队能否安全地变更？ | 变更前/后的路由策略对比 | 新策略可以单独发布并单独衡量 |
如果某个供应商无法暴露此评分卡所需的字段，你仍然可以使用该产品，但不应将其视为生产 AI 流量的控制平面。
一个简单的 30 天衡量计划
不要试图一次性为所有可能的指标都埋点。先从一个基线开始，证明 AI 路由 API 是否真的有帮助。
第 1 周：定义工作负载和请求 ID
选择三到五个工作负载：
- 一个交互式聊天或助手路径
- 一个 agentic 或工具调用路径
- 一个批处理或内部自动化路径
- 一个高成本模型路径
- 一个对回退敏感的路径
添加请求 ID 和工作负载标签。没有这两个字段，后续分析就会变成猜测。
第 2 周：添加结果和路由字段
对于每个工作负载，采集请求模型、最终模型、路由策略、状态、重试次数、回退次数和已接受输出。保持错误类型的低基数：超时、限流、提供方错误、校验失败、策略拦截和未知，这些就足够开始了。
第 3 周：添加延迟和成本
采集操作时长、流式工作负载的首块返回时间、输入 token、输出 token 和成本。按工作负载和最终路由拆分 p90/p99 延迟。
第 4 周：复盘路由决策
现在比较：
- 直接提供方路径与路由后路径
- 仅主路径成功与回退成功
- 旧路由策略与新路由策略
- 每次请求成本与每个已接受输出的成本
- 平均延迟与 p90/p99 延迟
这次复盘应该产出路由策略变更，而不只是一个更漂亮的仪表盘。
常见错误
错误 1：把重试当作不可见。
重试是用户体验和账单的一部分。把它们统计进去。
错误 2：报告模型成本时不包含被拒绝的输出。
如果应用丢弃了结果，那么这笔支出就没有产生产品价值。
错误 3：对所有工作负载只使用一个延迟指标。
编码代理、聊天机器人、图像工作流和夜间补充任务需要不同的阈值。
错误 4：认为回退就等于可靠性。
只有当备用路径兼容且恢复后的输出被接受时，回退才会提升可靠性。
错误 5：只衡量路由器，而不衡量业务路径。
AI 路由 API 是基础设施。真正的指标是产品路径是否变得更可靠、更快、更便宜，或更容易调试。同样的原则也适用于更窄的场景，例如 图像生成 API 指标：衡量被接受的输出和运行成本，而不只是发送了多少调用。
常见问题
什么是最重要的 AI 路由 API 指标？
对大多数团队来说，最重要的 AI 路由 API 指标是按工作负载划分的已接受响应率。它把路由行为与应用是否收到了可用答案联系起来。
回退率是一个好的可靠性指标吗？
回退率是一个信号，不是成功指标。更高的回退率可能意味着 AI 路由 API 正在恢复提供商问题，但也可能意味着主路径不稳定，或者超时设置过于激进。应将其与回退恢复率和回退不匹配率配对使用。
我应该先优化成本还是延迟？
按工作负载来优化。交互式路径通常需要 p90 或 p99 延迟护栏。批处理路径通常可以优先考虑成本或吞吐量。错误在于把同一套 AI 路由 API 策略应用到每一种工作负载上。
Flatkey 如何融入 AI 路由 API 的衡量？
Flatkey 提供一个与 OpenAI 兼容的 API，地址为 https://router.flatkey.ai/v1，一个共享模型目录，以及显示模型、token 数、延迟和成本的使用日志。这为团队衡量路由后的 AI 调用提供了一个实用基础。生产团队仍应定义工作负载标签、已接受输出规则和路由策略审查。
最后要点
AI 路由 API 值得像生产基础设施一样去衡量。请求数量、token 总量和模型名称只是表面。
真正重要的指标是已接受响应率、回退恢复、回退不匹配、p90/p99 延迟、每个已接受输出的成本，以及审计完整性。按工作负载和路由策略跟踪这些指标，你的 AI 路由 API 就会更容易评估、更安全地调优，并且在产品、工程和财务询问发生了什么变化时更容易作出解释。
如果你现在正在比较路由，先做一个实用测试：把相同的工作负载分别通过你当前的提供方路径和 Flatkey 的 OpenAI 兼容基础 URL 发送，然后用同一张评分卡比较接受的输出、最终模型、延迟、token、成本以及回退行为。如果你还在定义基础层，先了解 LLM API 的基础知识，然后在生产流量开始通过路由器传输时使用这张评分卡。
