AI 网关的监控该看哪几个指标？五个维度与一份排障顺序
数据截至 2026-07，价格与限额以各官网为准。
AI 网关的监控，价值不在于面板上有几张漂亮的曲线图，而在于线上一卡住时，你能在几分钟内分清是上游供应商挂了、是路由策略选错了模型、还是你自己的调用姿势有问题。凡是不能帮你缩小这个判断范围的指标，做出来也只是装饰。
常见的误解是把网关监控等同于看账单：月底导一份消费明细，看看花超没超。账单是滞后的、聚合的，它只能告诉你”上个月贵了三成”，没法告诉你贵在哪个调用方、哪一次策略调整、哪一家供应商悄悄换了计费口径。真正有用的监控必须能拆维度，而拆维度的前提是先想清楚要拆哪几个。
先分清三层，指标才有归属
一次经过网关的请求至少穿过三层：调用方（你的应用、Claude Code / Cursor 这类 IDE 与 CLI 工具）、网关本身（例如以 MIT 协议开源的 OmniRoute，装完后所有工具统一指向 http://localhost:20128/v1）、以及上游的模型供应商。
三层各有各的失败模式：调用方可能参数写错、上下文塞爆；网关可能路由到一个当前不可用的模型、或者凭证过期；上游可能限流、降级、直接 5xx。监控的第一原则是每个指标都要能落到某一层上，否则你看到”错误率涨了”也无从下手。下面五个指标都按这个思路设计。
指标一：成功率，必须按供应商和错误码拆开
只看一个总成功率几乎没用。挂了多家供应商的场景里，总成功率是被回退机制”抹平”过的——某家已经全线报错，但因为自动回退接住了，总数字看着还行，你完全察觉不到有一路已经废了。
建议至少拆成三个切面看：按供应商拆、按模型拆、按错误码拆。错误码里重点区分三类：鉴权类（凭证失效或过期）、限流类（配额打满或触发速率限制）、上游服务类（超时、5xx）。这三类的处理动作完全不同——鉴权类要去面板重新连一次，限流类要考虑加供应商或降频，上游服务类只能等或者切走。
OmniRoute 面板里给每个供应商提供了 Test Connection 做连通性验证，命令行也有 omniroute doctor 做自检。这两个是”手动探针”，适合怀疑某一路有问题时点一下确认；日常仍然需要靠请求日志里的错误码分布来发现问题，而不是等你想起来去点。
指标二：延迟，至少拆成首字延迟和整段耗时
把延迟压成一个平均值是第二个常见坑。对话类场景里用户的体感主要由首字延迟决定，批处理场景里真正卡流水线的是整段耗时，这两个数值可以差出一个数量级，混在一起平均掉之后什么都看不出来。
另外要看的是分位数而不是平均数。平均延迟正常、P95 很难看，是相当典型的形态：多数请求走了就近的快模型，少数请求触发回退，绕了一圈才成功，慢的正是这一小撮。如果你只盯平均值，用户抱怨”有时候特别慢”你会找不到证据。
网关本身也会引入开销。本地代理形态的网关额外开销通常不大，但它做的一些事情是有代价的——比如 OmniRoute 带的 RTK+Caveman 压缩，仓库称能省 15% 到 95% 的 token，压缩本身要占处理时间。这类”用时间换成本”的功能开没开，会直接体现在延迟曲线上，排查慢的时候记得把它算进变量。这里的节省幅度是项目仓库的自述口径，具体效果以你自己的实测为准。
指标三：token 用量与成本，按”谁在花”归因
成本监控的关键词是归因，不是总额。至少要能回答两个问题：这批 token 是哪个调用方消耗的（哪个项目、哪个 IDE、哪个人的机器），以及它落在了哪家供应商的哪个模型上。
第二个问题在多供应商网关里格外重要，因为回退机制会让钱悄悄流向别处。你原本设定的主力是某个免费或低价模型，某天它额度耗尽，网关按策略退到了付费模型上，请求全都成功，功能一切正常，只有账单知道发生了什么。能否按供应商拆分 token 消耗，直接决定了你会不会被这种静默切换咬一口。
还有一个容易忽略的口径问题：流式调用和非流式调用的用量统计字段不一定完全一致，网关转发之后可能又做了一层加工。如果你要拿这些数字做内部分摊，先用少量请求对一下网关记录与供应商侧账单的差值，别默认两边严丝合缝。成本这块的通用方法可以另看如何监控 AI API 的调用成本。
指标四：回退触发率与免费额度消耗速度
这是多供应商网关独有的指标，也是最能提前预警的一个。
回退触发率就是”有多少比例的请求没走成主力路线”。它平时应该很低，一旦持续走高，说明主力那一路已经不健康了——可能是额度快用完，可能是上游在限流。这个信号比错误率更早出现，因为回退成功的请求在错误率上根本不留痕迹。
配套要看的是免费额度的消耗速度。OmniRoute 的目录声称覆盖 290 个供应商、其中 90 多家有免费档、40 多家永久免费，仓库里给的零成本组合示例也标注了各自的额度形态（例如某个 Gemini 免费档标为每月 18 万 token）。这些数字都是项目仓库和目录的自述口径，且免费额度类信息变动极快，不能当成承诺——恰恰因为它随时会变，才更需要监控消耗速率：按当前速率还能撑几天，比额度上限本身有用得多。免费档的具体条款以各供应商官网与项目仓库文档的当前版本为准。
回退策略本身怎么设计，可以另看多模型 fallback 怎么设计和模型路由策略怎么定。
指标五：模型可用性与配置漂移
前四个指标盯的是流量，这一个盯的是配置。多供应商聚合环境里，配置的腐坏速度比很多人预期的快：上游下线了某个模型 ID、换了命名、调整了免费档门槛，你的路由配置却还停在半年前。
OmniRoute 提供了 omniroute models --search <term> 命令查模型可用性，也可以走 GET /api/models/catalog 拿目录。后者更适合做成定期任务：把你配置里实际用到的模型 ID 列一份清单，定期跟目录比对，发现某个 ID 从目录里消失就告警。这比等到线上报”模型不存在”再去查要从容得多。
模型 ID 的写法也值得纳入检查项。网关一般沿用供应商的原生格式，仓库示例里能看到 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5 这类写法，有的带点号版本号是因为上游 API 本来就那么要求。这种字符串靠人肉维护很容易抄错，用自动比对兜一层更稳。填 "auto" 让网关自动挑选可以省事，但代价是你的成本归因会变模糊——自动选出来的是哪个模型，得从日志里回溯。
一套从外往里的排障顺序
指标齐了还要有顺序，不然告警一响还是抓瞎。建议按这个次序剥：
- 先看网关自身是否活着（进程、端口、面板能不能开），排除掉”整个代理没起来”这种最粗的情况；
- 再看错误码分布落在哪一层——鉴权、限流、上游服务，三类各走各的处理路径；
- 然后看是不是单家供应商的问题，用面板的连通性验证或自检命令确认一路；
- 最后才怀疑自己的调用参数和模型 ID。
顺序反过来最耗时间：一上来怀疑业务代码，改了半天发现是上游在限流。这个从外往里的习惯，在任何多层链路里都成立。
这套监控解决不了什么
得诚实说几条局限。
一是质量不在指标里。成功率 100%、延迟很低，不代表回答有用。回退到一个能力更弱的便宜模型上，所有技术指标都会更好看，输出质量却掉了，这件事只能靠抽检和人工评估发现，监控面板看不出来。
二是网关记录的口径不等于供应商账单。中间多一层就多一层误差来源，做财务分摊前必须对账。
三是凭证与合规风险不是监控问题。第三方聚合网关意味着把各家凭证交给一个本地代理托管，认证形态可能是 OAuth 代管、web cookie、API key 或本地模型，风险不同。上游中不少是海外厂商，这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，具体以各自官网的地区政策页为准；本文不提供也不背书任何第三方中转渠道。这些属于选型阶段就要拍板的事，监控做得再细也补不回来。
四是指标本身会撒谎。回退机制的存在，天然会让表层指标变好看，这也是为什么前面反复强调要拆供应商维度。
网关自身暴露哪些可采集的指标接口、日志字段具体有哪些，各项目差别很大，以官方文档当前版本为准。
小结
给 AI 网关做监控，先确认每个指标能落到调用方、网关、上游三层中的哪一层，指标才有排障价值。成功率要按供应商和错误码拆，延迟要分首字与整段并看分位数，成本要按调用方和实际落地的模型归因。回退触发率和免费额度消耗速度是多供应商场景独有的早期预警，比错误率更早发声。模型可用性做成定期比对，能挡掉大部分配置腐坏。剩下的质量、对账和合规问题，监控帮不上忙，得靠别的手段兜。