停止像监控网络服务那样监控AI系统

许多AI系统的监控方式仍然与它们旁边的网络服务相同。API网关会发出正常运行时间、错误率和延迟百分位数，仪表板随基础设施免费提供。不幸的是，这些数字都无法告诉你用户盯着空白屏幕四秒钟后才看到第一个token，或者自上次提示更新以来每个任务的token消耗翻了一番，或者模型已经开始在检索到的上下文之外编造答案。

这种差距的存在是因为LLM系统打破了网络监控所依赖的假设。响应是逐个token生成的，因此“延迟”取决于你在时间线上的位置，至少有三个不同的数字。成本随token而非请求数量变化。此外，最具破坏性的故障是无声的：质量回归不会抛出500错误，而是以200状态码返回自信的文本。

文章提出了一种方法：将指标按它们回答的问题分组。五个问题涵盖了生产中的大部分问题：是否快速、能否扩展、是否正确、是否可靠、当有代理参与时表现如何。文章详细介绍了每个组、指标的机械含义以及哪些需要自行构建。

指标地图

在进入问题之前，文章还预告了一个关于将AI演示转化为部署应用的研讨会。

是否快速？（延迟）

LLM请求有两个阶段，产生不同的延迟数字。预填充阶段模型处理整个提示并构建内部状态，用户看不到任何东西。解码阶段模型逐token生成输出。每个值得追踪的延迟指标都是该时间线上的一个位置。

首token时间（TTFT）是从发送请求到第一个token到达的时间，包括排队时间和预填充时间。在流式UI中，这是用户感知的延迟。TTFT随提示长度增长，因此RAG系统将大上下文塞入提示会付出感知速度的代价。

token间延迟（ITL，也报告为每输出token时间TPOT）是流式传输开始后连续token之间的间隔，它决定了输出是否流畅。用户容忍稳定但略慢的流式传输远胜于快速但冻结的流式传输。

端到端延迟的p50、p95和p99是完整跨度，输出长度主导它。单一的全局百分位数几乎毫无意义：它将50个token的分类调用与2000个token的报告生成平均在一起。按用例追踪端到端延迟，让每个数字对应一个工作负载。

代理会放大效果。一个链式调用多个LLM的任务会倍增每次调用的数字，可容忍的每次调用p95可能变成不可容忍的任务级延迟。对于代理工作负载，将延迟预算设定在任务级别，并让它约束步骤。

能否扩展？（吞吐量和成本）

每个用户的每秒token数与总系统吞吐量。服务系统对同一硬件上的并发请求进行批处理，批次大小是可调整的：更大的批次提高总系统每秒token数，但每个单独的流会变慢。这两个指标在同一GPU上相互权衡。因此，为每个工作负载决定你要保护哪一个。交互式聊天应偏向每个用户的速度，离线批处理应偏向总吞吐量。

每个请求的输入和输出token数。这是单位经济的核心，输出token通常定价为输入token的倍数。记录每个请求，按用例分解，仔细监控。

缓存命中率。提示缓存使重复的提示前缀处理成本大幅降低，是系统提示、工具定义或共享文档上下文稳定的系统中的最大成本杠杆之一。它也容易出错，因为缓存逐字节匹配提示前缀：一个插在提示前部的时间戳或重排的工具列表都会使缓存失效。监控缓存命中率下降，这可能意味着有人更改了提示的组装方式。

每次成功任务的成本，而非每次请求的成本。每次请求成本使得错误廉价的系统看起来很好。成本只有三分之一但成功次数减半的请求实际上更昂贵，而且失败的尝试会触发重试，无形中倍增支出。这也是连接所有五个组的指标：你可以单独压低延迟、成本或质量，而每次成功任务的成本告诉你系统整体是变好还是变坏。

是否正确？（质量）

服务栈中没有任何东西会生成正确性。这一组中的所有指标都需要自行构建。

标记评估集上的任务成功率。几十到几百个已知正确结果的示例，在提示更改、模型升级或检索更改时重新运行。这是AI系统的回归测试套件。评估集不需要很大就能有用，但需要具有代表性并得到维护。

基于性（RAG）。答案是否由检索到的上下文支持，还是编造的？系统可能有出色的检索能力，但仍然在检索到的内容与最终输出之间产生幻觉。随着强大模型的出现，这个问题正在减少，但在实际生产系统中，最终你会希望使用尽可能小的模型来降低成本。

检索精确度和召回率@k。在k个检索块中，精确度@k询问有多少实际上相关。召回率@k询问在最初的k个中有多少相关材料被检索到。生成无法修复检索从未浮现的内容，因此当答案质量下降时，在重写提示之前先检查检索指标。检索仍然是AI系统中更难的问题。

LLM-as-Judge评分随时间变化，并针对人工标签进行校准。评判员使得质量可在大规模上测量，但它们会漂移——评判模型升级可能会改变评分，而系统本身没有变化。在开始时根据人工标签样本进行校准，并在评判模型更改或评分趋势看起来过于乐观时重新校准。

用户反馈信号。显式点赞很少见且偏向极端。重新生成率和用户在接受生成输出前编辑的程度更常见且更真实，因为它们是在用户对输出采取行动时记录的，而不是在他们感觉想评分时。

是否可靠？（可靠性）

每个提供商的错误率、超时率和限流率。按提供商拆分很重要，因为聚合可用性会隐藏哪个依赖项正在退化，特别是限流往往以突发形式出现，与某个提供商的配额绑定。

重试和回退率。回退到备份模型保持可用性为绿色，但质量悄然变化。按服务路径追踪质量指标。

护栏触发率和拒绝率。两者激增意味着用户行为发生变化、可能发生注入攻击或模型更改移除了拒绝边界。无论如何，都值得追踪，而且在护栏操作被正确记录后成本很低。

代理如何表现？（代理指标）

代理以单个LLM调用不会的方式失败，因为模型做出了一系列决策，每一个都可能悄然退化。

工具调用错误率，按原因拆分。模式和参数错误意味着模型误解了工具，修复方法在工具描述中。执行错误意味着工具本身坏了，修复方法在你的代码中。

每个已完成任务的步骤数和token数。成功率保持稳定但每个任务的步骤数增加意味着成本上升而准确性不变。在每次模型交换和提示更改后观察这一点。

上下文窗口利用率。压缩和截断问题的早期预警。质量通常在上下文填满时下降，因此利用率趋势告诉你需在失败对用户仍不可见时进行干预。

循环检测。代理重复相同工具调用和相同参数的比例。循环纯粹是token浪费，从轨迹日志中用几行代码即可检测。

监测差距

回顾五个组，模式很明显。延迟和可靠性在第一天就出现，因为网关、负载均衡器和提供商SDK作为服务流量的副产品发出它们。质量、每次任务成本和代理行为指标不会产生，直到你构建测量它们的管道：从每次响应记录的token和缓存字段、每次更改时运行的评估集、校准过的评判员、代理的轨迹日志。

这也是为什么全面监控和真正的盲点并存：监控覆盖了基础设施报告的维度，而故障位于它没有报告的维度。后果是预算问题。质量和每次任务成本的检测应属于AI功能的初始构建估算，而不是在后续审查中。

从何处开始

你不应该通过一次性实施所有措施来减慢开发进度。按信息密度排序的顺序：

TTFT和端到端延迟，按用例区分。如果你使用流式传输，TTFT是用户感知的延迟，两者都来自你已有的时间戳。

每个请求的token数和缓存命中率。两者都是API响应中的字段，记录它们很容易，并且它们能立即阐明单位经济。

带任务成功率的标记评估集。从50个示例开始，并在每次相关更改时重新运行的纪律。

每个提供商的错误率和回退率。添加成本低，回退与质量的交互是常见的无声退化。

代理指标，当你部署代理时。按原因拆分的工具调用错误、每个任务的步骤数和上下文窗口利用率都可以在轨迹日志中找到。

这个列表具有代表性而非详尽无遗。它故意省略了当你自己托管推理时重要的GPU级服务指标（KV缓存利用率、批处理占用率），以及嵌入和数据漂移，以及业务层指标如包含率或每次会话的收入。

要点

按指标回答的问题分组：速度、扩展性、正确性、可靠性、代理行为。

将延迟作为请求时间线上的位置追踪：TTFT用于感知速度。

每次成功任务的成本是连接所有指标的单一数字。

质量指标需要自行构建，它们不会自动生成。

代理指标需要追踪步骤、工具调用和循环。

从TTFT和延迟开始，逐步添加成本、质量和代理指标。