AI 网关监控详解

覆盖监控指标四层体系、AI 网关监控黄金指标、告警阈值建议、每个指标的业务影响与排查思路、商业与开源监控工具选型。

1、为什么 AI 网关监控不同于传统 API 监控

传统 API 监控关注三件事：延迟、错误率、吞吐量。AI 网关在此基础上增加了一个全新的维度——成本：每次请求都消耗 Token，而 Token 消耗速率随模型、提示词长度、响应冗长程度动态变化。一个在传统指标上"完全健康"的 AI 网关，可能正在悄悄烧光你的预算。

核心洞察：对于 AI 网关而言，"系统在线 + 响应快 + 返回 200" 并不等同于 "服务正常"。一次返回 200 的调用，可能输出了幻觉内容、泄露了个人敏感信息（PII），或者因为 Agent 陷入死循环而在一夜之间消耗了数万元的 Token 费用。因此，AI 网关的监控必须同时回答两个核心问题："系统是否在正常运行？"（可靠性信号）与 "钱花得对不对？"（经济信号），并进一步回答 "输出质量好不好？"（质量信号）。

这是因为 LLM 系统具有三个传统软件不具备的特征:

• 非确定性：相同输入可能产生不同输出,无法靠单元测试覆盖质量。
• 成本动态：Token 用量按请求波动,可因 Agent 循环、提示词注入等意外场景突然飙升——已有多起一夜烧掉万元美元的事故。
• 静默失败：模型可以"自信地胡说"(幻觉),不报任何错误,传统错误率指标完全捕捉不到。

2、监控指标体系总览:四层框架

AI 网关的监控指标可以归纳为四个层次，从底层基础设施到上层业务价值逐层递进。传统 APM 只覆盖第一层，Dedicated LLM 平台覆盖 1-4 层，这是二者的核心差异。

关键提醒：很多团队只监控第 1 层(延迟/错误率)就觉得够了,直到某天收到一张天价账单,或用户投诉"AI 答非所问"才发现第 2、3 层完全是盲区。第 1 层只告诉你"网关活着",第 2-4 层才告诉你"网关在正常干活"。

3、AI 网关监控黄金指标

Google SRE 的"四大黄金信号"(延迟、流量、错误、饱和度)是监控的经典框架。AI 网关在此基础上做了适配——加入成本与质量两个 AI 专属维度,形成"AI 网关六大黄金指标"。

五项最关键的 AI 网关指标(生产经验排序)

#	指标	为什么关键	监控建议
1	提供商延迟(按模型)	LLM 延迟差异巨大:快的 GPT-4o Mini 约 400ms,慢的 Claude Sonnet 可能 8s。必须按 provider×model 分别跟踪 P50/P95/P99。一个模型 P95 飙升而其他稳定 → 该提供商有问题。	分维度跟踪
2	Fallback 触发率	有多少请求触发了备选模型?5 分钟窗口内 >5% 值得排查,>20% 说明主提供商严重降级。	5%/25% 双阈值
3	Token 漂移	输出 Token / 输入 Token 比率随时间变化。突然升高 = 模型在生成更长的响应(提示词变了或模型行为变了),成本会在不触发任何错误的情况下飙升。	趋势告警
4	预算燃烧速率	1 小时消耗速率超过 7 天均值的 2× 时告警。能抓住失控循环、错误配置的提示词、意外流量峰值——在烧光余额之前。	2×/5× 双阈值
5	单 Key 成本集中度	单个 API Key 占总花费 >60%(且非预期)→ 该 Key 对应的功能可能在过度调用,或一个没设预算限制的测试环境在偷偷烧钱。	>60% 排查

4、监控指标详解:定义、业务影响、排查与解决

下面逐层展开每个核心指标,给出详细定义、正常范围、异常时的业务影响、排查思路和解决方法。

4.1 运维层指标(Operational)

① 延迟 Latency — TTFT & 总响应时间

运维层指标类型:Histogram / Summary  |  维度:model, provider, prompt_type, customer_id, cache_hit

定义：TTFT(Time To First Token)= 从请求发出到收到第一个 Token 的时间;总响应时间 = 从请求发出到最后一个 Token 输出完成。对流式响应,TTFT 是用户体验的关键——用户等待第一个字出现的时间。

正常范围(参考)：快模型(GPT-4o Mini/Flash)TTFT 200-500ms、总时间 1-3s;慢模型(Claude Sonnet/GPT-4)TTFT 500ms-2s、总时间 3-10s。P95 不应超过基线的 1.5 倍。

业务影响：P95 延迟持续升高 → 用户感知"卡顿",流式对话体验变差,用户可能中断等待或转向竞品;Agent 工作流因单步变慢导致整体编排时间倍增(多步串行时延迟叠加)。

排查思路：① 确认是全局升高还是单个模型——按 provider×model 分维度看;② 检查是否提供商侧问题(查提供商状态页);③ 检查提示词长度是否突增(长上下文 → 首 Token 延迟增加);④ 检查网络链路(网关到提供商的出口延迟);⑤ 检查网关自身 CPU/内存是否饱和。

解决方法：启用提示词前缀缓存(Prompt Caching);对低延迟场景路由到更快的小模型;启用流式响应降低感知延迟;设置 Fallback 到备选提供商;长上下文场景考虑用支持更大 KV Cache 的模型。

② 吞吐量 Traffic — QPS & 并发数

运维层指标类型:Counter / Gauge  |  维度:model, route, api_key, feature_flag

定义：每秒请求数(QPS)和当前并发请求数(并发上限由提供商配额决定)。还需跟踪 Token 吞吐量(tokens/sec)——这是衡量"实际计算负载"的更准指标。

正常范围：取决于提供商配额和网关自身容量。突然的流量峰值或断崖式下跌都值得关注。

业务影响:QPS 突增 → 可能是流量暴涨(好事)也可能是某功能在死循环调用(坏事,会烧钱);QPS 断崖下跌 → 可能是上游应用故障或网关路由配置错误,用户请求根本没到达。

排查思路：① 按 api_key / feature 分维度看,定位是哪个来源的流量异常;② 检查是否有 Agent 死循环(同一 session 短时间内大量重复请求);③ 检查上游应用是否有发布导致请求量变化;④ 检查网关路由规则是否被误改。

解决方法：按 Key/Feature 设置 QPS 限流和并发上限;为 Agent 请求设置最大循环次数熔断;配置自动扩容;异常流量自动降级到更便宜的模型。

③ 错误率 Errors — 4xx / 5xx / 429 / 超时

运维层指标类型:Counter(按 error_type 分维度)  |  维度:error_type, model, provider, status_code

定义：错误请求占总请求的比例。AI 网关需区分错误类型:429 限流(提供商配额不足)、4xx 客户端错误(格式错误/内容违规)、5xx 服务端错误(提供商故障)、超时(请求超时未返回)。

正常范围:整体错误率 <1%。429 偶发可接受(触发限流后 Fallback 即可),5xx 持续 >2% 需立即处理。

业务影响：5xx 持续 → 用户直接看到报错,无法获取 AI 响应,体验崩溃;429 频发 → 主提供商配额耗尽,如果 Fallback 未配好则服务降级;超时 → 流式响应中断,用户等待后得到空响应。错误率 >10% 属严重事故级。

排查思路：① 按 status_code 分类——429 查配额、5xx 查提供商状态页、4xx 查请求格式/内容;② 检查 Fallback 是否正常触发(看 fallback_rate);③ 检查是否因内容安全策略触发 4xx(某些提供商对特定内容返回 400);④ 检查超时阈值是否设置过低。

解决方法:配置多提供商 Fallback 链;申请提高提供商配额;对 429 实现指数退避重试;设置合理的超时阈值(流式 60s+,非流式 30s);对 4xx 内容违规启用网关层护栏前置拦截。

④ Fallback 触发率

运维层/AI 独有 指标类型:Counter / Rate  |  维度:primary_model, fallback_model, reason

定义：因主模型不可用/超时/限流而触发备选模型的比例。这是 AI 网关特有的关键健康指标——它直接反映"你的主提供商是否可靠"。

正常范围：<5%(5 分钟窗口)。>5% 值得排查,>20% 说明主提供商严重降级,>25% 为 Critical。

业务影响：Fallback 频发 → 主提供商不稳定,用户可能感知到响应质量波动(不同模型输出风格不同);Fallback 到更贵模型 → 成本上升;Fallback 链全部失败 → 服务完全不可用。

排查思路：① 按 reason 分类——是 429(配额)还是 5xx(故障)还是 timeout;② 查主提供商状态页确认是否在降级;③ 检查 Fallback 模型是否也出现高负载(级联故障);④ 检查路由策略是否合理(是否把太多流量打到单一提供商)。

解决方法：增加更多提供商作为 Fallback;调整路由权重分散流量;申请提高主提供商配额;对间歇性故障启用自动重试(指数退避);考虑自托管模型作为最终 Fallback 兜底。

4.2 成本层指标(Cost)

⑤ Token 用量 — 输入/输出 Token

成本层指标类型:Counter  |  维度:model, api_key, customer_id, feature, prompt_version

定义：每次请求消耗的输入 Token(提示词)和输出 Token(响应)。直接决定提供商账单。需按模型/团队/用户/功能维度归因,否则成本黑箱。

正常范围：取决于业务。关键是监控趋势和异常值——单次请求 Token 远超均值往往是问题信号。

业务影响：Token 用量异常飙升 → 账单暴涨,可能一夜烧掉数万元;按团队无法归因 → 无法做成本优化和内部结算;Token 漂移(输出/输入比升高)→ 模型行为变化导致成本隐性上涨。

排查思路：① 按 api_key/feature 定位异常来源;② 检查是否有 Agent 死循环(同一对话重复调用,Token 累积);③ 检查提示词是否变长(system prompt 改动、上下文堆积);④ 检查是否有提示词注入攻击(注入超长内容);⑤ 检查输出 Token 是否异常增多(模型幻觉/无限输出)。

解决方法：按 Key/Feature 设 Token 上限和预算;启用提示词前缀缓存(省输入 Token);对长输出设 max_tokens 截断;启用语义缓存(相似请求复用历史结果);Agent 设最大循环次数熔断;低成本场景路由到更小模型。

⑥ 预算燃烧速率 & 成本异常

成本层指标类型:Rate / Anomaly  |  维度:api_key, team, model, budget_pool

定义：当前消耗速率 vs 历史均值的比值。如果 1 小时燃烧速率 >7 天均值的 2× → Warning;>5× → Critical。这是防止"天价账单"事故的最后一道防线。

正常范围：1× 基线。短期波动正常,持续 >2× 需关注。

业务影响:未及时告警 → 月度预算在几天内烧光;已有团队因单个故障功能一夜生成数百万 Token 烧掉 $10K+;预算耗尽后服务被迫降级或停服。

排查思路：① 查"单 Key 成本集中度"——哪个 Key 在烧钱;② 查该 Key 的请求模式——是 QPS 暴涨还是单请求 Token 暴涨;③ 查是否 Agent 循环/提示词注入/测试环境无限制;④ 查是否有新功能上线未设预算。

解决方法：从第一天就设日消费告警(不要等月底);按 Key 设硬预算上限(超限直接拒绝);测试/预发环境强制限流;启用异常检测自动熔断;高成本请求自动降级到小模型。

⑦ 单 Key 成本集中度

成本层指标类型:Gauge / Ratio  |  维度:api_key

定义：单个 API Key 的花费占总花费的百分比。如果某 Key 意外占比 >60%,说明该 Key 对应的功能在过度调用,或是一个没设预算的测试环境在偷偷烧钱。

业务影响：成本过度集中 → 单点故障风险(该 Key 被封则服务受影响大);可能掩盖了某个功能的低效使用或 Bug;内部成本无法合理分摊。

排查思路：① 定位该 Key 对应的应用/功能;② 查其请求模式——是正常高频还是异常循环;③ 检查是否该功能本应走更便宜模型但配错了;④ 检查是否测试 Key 泄漏到生产。

解决方法：为每个 Key 设独立预算和告警;测试/预发 Key 设更严格的上限;定期审查成本分布;对高消耗功能做模型降级评估。

4.3 质量层指标(Quality)

⑧ 幻觉率 Hallucination Rate

质量层指标类型:Derived / Eval Score  |  维度:model, prompt_version, feature, retrieval_source

定义：模型编造事实/引用的比例。AI 网关最难但最重要的指标。无法直接实时测量,需用代理信号:RAG 忠实度(回答是否基于检索文档)、事实核查不匹配率、LLM-as-a-Judge 评分、人工标注率。

业务影响：幻觉率高 → 用户获得错误信息,可能引发法律/合规风险(医疗、金融场景尤其严重);用户信任崩塌;RAG 系统中幻觉意味着检索有效但模型忽略了上下文。

排查思路：① 按 prompt_version 对比——是否近期提示词改动导致;② 按 model 对比——是否换了模型后幻觉增加;③ 检查 RAG 检索质量——是否检索到无关文档;④ 检查温度(temperature)设置是否过高;⑤ 采样人工审查幻觉样本找共性。

解决方法：降低 temperature;强化 RAG 检索(提高 top-k、加 reranker);在提示词中加"基于以下上下文回答,不确定时说不知道";加事实核查护栏(对关键事实做二次验证);用 LLM-as-a-Judge 对输出做实时评分拦截。

⑨ 拒答率 & 任务完成率

质量层指标类型:Rate  |  维度:model, prompt_version, feature

定义：拒答率 = 模型拒绝回答的比例(因安全策略或内容策略);任务完成率 = 模型成功完成用户意图的比例(Agent 场景尤其重要)。

业务影响：拒答率突升 → 安全护栏过严,误伤正常请求,用户体验下降;任务完成率下降 → Agent 无法完成用户任务,影响业务转化(如客服无法解决工单)。

排查思路：① 检查是否近期更新了安全策略/护栏规则;② 按 prompt_version 对比;③ 检查是否有提示词注入攻击触发安全策略;④ 采样拒答案例看是否误伤。

解决方法：调优护栏阈值(区分"确实该拦"和"误伤");对安全拒答提供有意义的替代回复;Agent 场景设任务完成检测和重试逻辑;持续用 eval 集回归测试。

⑩ 用户反馈信号(显式 + 隐式)

质量层指标类型:Counter / Rate  |  维度:user_id, model, feature

定义：显式 = 点赞/踩、评分、纠错提交;隐式 = 重试率(用户重新生成)、会话时长、后续追问(暗示首个回答不够好)、转人工率。这些信号单独看有噪声,聚合后却是质量回归的最早信号。

业务影响：重试率飙升/点赞率骤降 → 质量回归已发生且用户已感知,如不及时修复会导致流失;这些信号往往比延迟/错误率更早暴露问题(系统报 200 但用户不满意)。

排查思路：① 按时间对齐质量下降的拐点与最近的变更(模型/提示词/检索);② 按模型分维度看;③ 采样差评/重试案例做人工审查;④ 检查是否有特定话题/用户群集中差评。

解决方法：建立质量回归告警(重试率 >X% 告警);版本化所有提示词和模型配置便于回滚;上线前用 eval 集做回归测试;定期把差评样本加入 golden set 持续改进。

4.4 安全与治理层指标(Security & Governance)

⑪ 提示词注入检测率

安全层指标类型:Counter / Rate  |  维度:api_key, source_ip, pattern_type

定义：检测到对抗性用户输入(试图绕过安全策略、提取系统提示词、执行未授权操作)的频率。

业务影响：注入攻击成功 → 攻击者可提取系统提示词、绕过安全护栏、让模型执行有害操作;在 Agent 场景中可能触发未授权的工具调用(如发邮件、访问数据)。

排查思路：① 按来源 IP/Key 定位攻击来源;② 分析注入模式(是否在尝试已知攻击向量);③ 检查是否有注入成功绕过了护栏;④ 审计该来源的工具调用记录。

解决方法：部署提示词注入检测模型;对用户输入做输入净化;Agent 工具调用加二次确认;系统提示词加防注入指令;对高频攻击来源限流/封禁。

⑫ PII 泄露检测

安全层指标类型:Counter / Rate  |  维度:detection_type, severity

定义：请求/响应中检测到个人敏感信息(身份证、手机号、银行卡、地址等)的频率。GDPR/CCPA/中国《个保法》合规的核心指标。

业务影响：PII 泄露 → 合规违规,面临罚款(GDPR 最高营收 4%);用户隐私事故,品牌信任受损;数据驻留违规(跨境传输)。

排查思路：① 定位泄露来源(用户输入携带 vs 模型生成);② 检查是否日志未做脱敏就存储;③ 检查是否模型从 RAG 检索到了含 PII 的文档;④ 审计数据流向(是否传给了不该接收的提供商)。

解决方法：在网关层部署 PII 检测 + 自动脱敏(捕获时脱敏而非存储后);对日志设保留期限制;按合规要求做数据驻留(特定地区数据不跨境);对 RAG 文档做 PII 预处理;用 Datadog SDS 等工具自动扫描脱敏。

⑬ Key 异常使用 & MCP 工具调用追踪

安全层指标类型:Anomaly / Audit Log  |  维度:api_key, tool_name, agent_id

定义：API Key 的异常调用模式(非常规时间、非常规频率、异常来源 IP);Agent 调用的工具记录(MCP 场景尤其重要——Agent 可能调用了不该调用的工具)。

业务影响：Key 泄漏 → 攻击者盗用余额;Agent 调用未授权工具 → 可能执行有害操作(删数据、发邮件、访问敏感 API);审计缺失 → 合规违规,事故无法追责。

排查思路：① 对比 Key 的历史使用模式,定位异常时段;② 查该 Key 在异常时段的工具调用记录;③ 检查是否 Key 已泄漏(查公开仓库/GitHub 是否有泄漏);④ 检查 Agent 工具权限是否过大。

解决方法：Key 定期轮换;按最小权限原则限制 Agent 可用工具;所有工具调用记录审计日志(不可篡改);异常使用自动告警 + 自动禁用 Key;用 mTLS/签名认证而非裸 Key。

5、告警阈值建议

告警的核心原则:分可用性、延迟、成本三类分别告警,一个混合告警会掩盖根因、增加恢复时间。同时告警要有优先级分级——不是每个指标都值得半夜打电话。

5.1 核心指标告警阈值表

信号	Warning	Critical	优先级	说明
提供商错误率(5xx)	> 2% / 5min	> 10% / 5min	P1 立即电话	持续 5xx 说明提供商故障,需触发 Fallback
Fallback 触发率	> 5% / 5min	> 25% / 5min	P1/P2	主提供商严重降级,需手动调整路由
P95 延迟(vs 基线)	+ 50%	+ 200%	P2 Slack 告警	持续 5 分钟超 SLA 阈值触发
预算燃烧速率(vs 7 天均值)	2×	5×	P1 立即告警	防天价账单,最关键的 AI 专属告警
429 限流率	> 5% / 5min	> 20% / 5min	P2	提供商配额不足,需提高配额或分散流量
单 Key 成本集中度	> 40%	> 60%(非预期)	P2	某功能过度调用或测试环境失控
服务可用性(成功率)	< 99.5%	< 99%	P1 立即电话	传统可用性告警
质量评分下降(eval/反馈)	> 10% 下降	> 25% 下降	P2	幻觉/差评率回归,最难但最重要
安全违规率(PII/注入)	> 0.1%	> 1%	P1 立即告警	合规风险,需立即阻断
缓存命中率	下降 > 20%	—	P3 每日复查	缓存失效导致成本上升,非紧急
Token 漂移(输出/输入比)	偏离基线 > 30%	—	P3 每日复查	模型行为变化,影响成本

5.2 告警优先级模型

特别提醒：AI 指标(如 Token、按模型分维度的延迟)默认在 Prometheus中是关闭的，因为高基数标签(每请求一个 trace_id、每用户一个标签)会导致Prometheus性能问题。

建议：

① 指标维度只保留低基数的(model, provider, route, feature);

② 高基数数据走 Trace/Log 而非 Metric;

③ 用 OTel 的 span 存高基数关联。

6、异常排查流程:从告警到根因

当告警触发时,一套标准化的排查流程能大幅缩短恢复时间。下图是 AI 网关告警的通用排查决策树。

排查黄金法则：对 AI 系统来说，每次请求都要有 correlation_id 贯穿完整 trace——从组装提示词、到 RAG 检索、到每次工具调用、到最终输出。Agent 场景还要 span 每次循环迭代。没有 trace,一次不可复现的非确定性故障就无从追查。

7、监控工具选型:开源与商业

AI 网关监控工具分两大阵营:Dedicated LLM 平台(专为 LLM 设计,覆盖质量/成本/安全,如 Langfuse、Phoenix、Helicone)与扩展型 APM(传统监控平台加 LLM 模块,如 Datadog、New Relic,适合已有投资)。成熟实践是两者组合:LLM 平台管质量/成本追踪,APM 管基础设施运维指标。

7.1 开源 / 自托管监控软件

工具	协议	核心特性	免费额度	最适合场景
Langfuse	MIT/ELv2	细粒度 trace(树状流程)、提示词版本管理、成本看板、评测、SOC2、会话回放、协作调试。工程与生产导向,功能最全的开源方案。	云端 5 万 events/月
自托管免费	需要完整 trace + 评测 + 自托管的团队;复杂工作流调试
Arize Phoenix	Apache 2.0	基于 OpenTelemetry(无厂商锁定)、本地优先调试、RAG 检索可视化、LLM-as-a-Judge 评测、模型漂移检测、嵌入分析。8000+ GitHub Stars。	完全免费
自托管	需要 OTel 原生、无厂商锁定、RAG 调试的团队;预算有限的初创
Helicone	GPL	代理式集成(改 base URL 即可,2 分钟接入)、内置缓存降本、成本追踪最佳、Cloudflare Workers 部署低延迟(50-80ms)、SOC2/GDPR。已处理 20 亿+ LLM 交互。	10 万 req/月
Pro $25/月	想最快落地、成本优化优先、代理式接入的团队
Portkey	MIT	AI 网关 + 可观测 + 护栏 + 治理 + 提示词管理一体化。40+ 指标实时看板,连接 1600+ LLM,模型路由与故障转移,OTel 兼容。	1 万 req/月	需要网关+监控一体化、多模型路由、复杂治理的团队
Lunary	Apache 2.0	专注聊天机器人/对话式 AI、实时分析、企业安全(SOC2/ISO27001)、反馈追踪、Agent trace、提示词管理。	1 万 events/月	构建对话式 AI/聊天机器人、安全合规要求高的团队
Opik (Comet)	MIT	全生命周期可观测 + 自动化提示词优化(6 种算法)、内置护栏(PII/竞品/离题拦截)、性能极快(比 Phoenix 快 7-14×)、CI/CD 单元测试。	2.5 万 spans/月
Pro $39/月	需要自动化提示词优化、重视迭代速度的团队
OpenLLMetry	Apache 2.0	OpenTelemetry 原生,自动埋点所有主流 LLM 框架,trace 可导出到任意 OTel 后端(Grafana/Jaeger/Datadog)。无厂商锁定。	完全免费	已有 OTel/Grafana 技术栈、想统一可观测体系的团队
**Grafana + Prometheus
+ Tempo + Loki**	开源栈	经典开源可观测栈:Prometheus 指标 + Tempo 追踪 + Loki 日志 + Grafana 可视化。需自行搭建,最大灵活性,零许可费。	自托管免费
云端有免费层	成本敏感、有运维能力、想完全自主可控的团队
TruLens	MIT	专注 LLM 评估与研究、可扩展反馈函数库、应用版本对比、Snowflake 支持。研究导向。	完全免费	学术/研究环境、专注评估方法论的团队

7.2 商业 / 托管监控软件

工具	定价模式	核心特性	LLM 评测	最适合场景
Datadog
Agent Observability	Free 4 万 spans/月
Pro $160/月起(10 万 spans)
额外 $3.5/万 spans	端到端 trace、数据集、实验、测试沙盒、离线/在线评测、提示词工作流、人工标注。统一 AI Agent 行为与后端服务/基础设施/RUM。内置 Sensitive Data Scanner。	支持	已有 Datadog APM 投资、想统一全栈可观测的企业
New Relic
AI Monitoring	按数据摄入计费
免费 100GB/月
+$0.40/GB	LLM trace 集成 APM、模型性能指标(延迟/吞吐/Token/成本)、已有告警看板、基础设施关联。2026 NOW 大会推出 AI Observability。	不支持	已有 New Relic 投资、想要基础 AI 遥测的企业
Dynatrace	按 GiB 摄入计
企业定制	自动全栈发现(Davis AI)、零配置拓扑、自动根因分析。企业级自动化强。	有限	500+ 主机的大型企业、复杂分布式架构
LangSmith	Free 5k traces/月
Plus $39/座/月	LangChain 深度集成、trace 调试、LLM-as-Judge 评测、提示词实验沙盒、业务指标看板。框架无关但 LangChain 生态最佳。	支持	深度使用 LangChain/LangGraph 的团队
Honeycomb	按事件量计
有免费层	高基数可观测(百万级属性组合查询)、不预定义看板也能灵活查询。适合"不知道要问什么"的探索式调试。	有限	需要高基数查询、探索式调试的工程团队
Fiddler AI	企业定制	护栏、EU AI Act 合规支持、模型监控、公平性/偏差检测。强合规导向。	支持	受监管行业(金融/医疗)、EU AI Act 合规
Galileo	Free 5k traces
Pro $100/月	企业级实时护栏、Luna-2 评测模型(低成本)、运行时干预。	支持	需要实时护栏干预、成本敏感的评测
Braintrust	Free 1GB 数据
Pro $249/月	非技术团队友好的 UI 驱动实验沙盒、评测优先。	支持	PM/QA 需要参与评测、跨职能协作
Langwatch	Free 1k traces
€59-€199/月	OTel 原生、800+ 模型 Token 成本追踪、质量告警(不只延迟)。	支持	OTel 原生、重视成本追踪的团队

7.3 选型决策框架

成熟实践：大多数团队的最佳组合是 Dedicated LLM 平台(质量/成本/trace)+ 已有 APM(运维指标)。例如 Langfuse(管 LLM trace+评测+成本) + Datadog/Prometheus(管基础设施+延迟+错误)。不要指望单一工具覆盖全部四层——Dedicated 平台不监控 GPU/CPU,APM 不评测幻觉率。

8. 监控体系建设的最佳实践

8.1 从第一天就跟踪正确的指标

很多团队跳过完整日志以省存储费,这个决定几乎总会后悔。每个 LLM 交互应记录:完整提示词(含 system prompt 和对话历史)、完整模型响应、模型名与版本、时间戳和 request_id、延迟和 Token 数、用户/会话 ID(匿名化)、元数据(feature flag、A/B 变体、RAG 检索源)。注意 PII 要在捕获时脱敏,而非存储后。

8.2 监控成熟度阶梯

阶段	特征	能力	缺失的代价
L0 盲飞	只有提供商账单	知道花了多少钱,不知道花在哪、为什么	天价账单事故无法追查
L1 基础运维	延迟+错误率+QPS	知道系统是否在线,不知道输出质量	幻觉/低质输出用户已投诉才发现
L2 成本可视	+Token 归因+预算告警	知道每个功能/团队花了多少,能设预算	质量回归仍靠用户反馈
L3 质量可测	+幻觉率+评测+用户反馈	能主动发现质量回归,不依赖用户投诉	安全/合规仍无覆盖
L4 全栈可观测	+安全护栏+审计+漂移检测	四层全覆盖,合规可审计,主动防御	— (目标状态)

8.3 七条核心实践

最后的提醒：AI 网关本身是一个新的攻击面。一个配置错误的端点可以让攻击者访问多个后端模型与敏感数据。监控不只是为了"系统健康",更是为了安全合规的最后一道防线。把网关当作关键安全边界来监控,而非一个普通中间件。