还在用老办法监控你的AI应用？难怪你会踩坑

说实话，如果你监控 LLM 应用的方式跟监控普通 API 一样，那基本上就是在瞎子摸象。

这种情况我见太多了。团队搭好 AI 服务，接入现有的监控体系，看着仪表盘一片绿，就以为万事大吉。然后用户开始抱怨回答质量不行，或者月底账单比预期高出三倍——这时候才发现，那些监控工具一直在告诉你"一切正常"。

问题不在于选什么指标，而是 AI 系统从根本上打破了传统监控架构的假设前提。

为什么老套路不灵了

传统 Web 监控的逻辑很简单：请求进来，干活，返回结果。成不成功一目了然，延迟就是延迟，P99 数据说啥是啥。

LLM 完全不一样。响应不是一下子返回的，是逐个 token 生成出来的——这意味着"延迟"在不同阶段根本不是一回事。返回 200 OK 也不代表输出质量没问题。费用按 token 算，不是按请求次数。更要命的是，最严重的问题往往是静默的：模型一本正经地胡说八道，HTTP 状态码却是完美的 200。

TTFT：用户真正感受到的那段等待

用户发出一条 prompt，最先感受到的是什么？是等待。等屏幕上出现第一个字。

这就是 Time to First Token（TTFT），在 LLM 的世界里，它最接近"感知延迟"这个概念。

TTFT 有一个特点很多人没注意：prompt 越长，它就越长。比如你在做 RAG 系统，往每个请求里塞一大段上下文来提高准确率——代价就是用户要等更久才能看到第一个字。这是天然存在的取舍，传统的监控根本不会帮你发现。

ITL：流不流畅用户一清二楚

开始输出之后，用户就开始在心里算阅读速度了。Inter-Token Latency（ITL）——也就是相邻两个 token 之间的间隔——决定了体验是顺滑还是卡顿。

有意思的是，用户对"慢但稳定"的容忍度很高。但如果一个本来挺快的流，时不时卡一下、抖一下，用户就会很不爽。监控要看的不只是吞吐量数字，而是要区分这两种体验。

端到端延迟：得看场景

你 API 的 P99 延迟数据一直很准，但直接套到 AI 请求上会把你带沟里。原因很简单：一个 50 token 的分类任务和一个 2000 token 的报告生成，延迟根本不是一个量级，混在一起平均出来的数字什么都不是。

按使用场景分别统计延迟。每个指标对应一个特征一致的工作负载，否则你优化的只是一个不存在的抽象概念。

静默失败：最可怕的问题

AI 系统最吓人的生产事故，通常不会触发任何告警。

模型开始一本正经地胡说八道。Prompt 漂移引入细微偏见。检索到的上下文被模型无视，偏要用训练记忆来回答。这些统统返回 200，处理时间也在正常范围内，仪表盘绿得发光。

靠心跳检测发现不了这些问题。你需要监控输出质量，这确实更难做，但没得商量。

真正要看的指标

把 AI 相关指标按问题分类：

• 够快吗？ TTFT、ITL、按场景划分的延迟百分位
• 撑得住吗？ Token 吞吐量、队列深度、上下文利用率
• 答得对吗？ 任务完成率、输出中的错误模式
• 成本可控吗？ 单任务费用、Token 效率、模型稳定性
• 行为正常吗？（针对 Agent）任务完成情况、步数、循环检测

这些东西，有些你能从基础设施捞到，但大多数需要自己动手。给 LLM 工作负载做定制化监控不是可选项——这是唯一能看到真相的办法。

做得好的团队，靠的不是更花哨的仪表盘，而是问对了问题。