大模型可观测性指标：从延迟监控到 Agent 评测闭环
大模型可观测性指标用于理解模型与 Agent 应用运行状态。通过延迟、令牌使用量、错误率和 CPU/GPU 使用率监控性能，并结合 Span 评测集支撑排障与改进。
什么是大模型可观测性指标？
大模型可观测性指标，是用来理解 LLM 或 Agent 应用从接收输入到生成输出全过程运行状态的一组监控信号。它通常覆盖性能、资源消耗、错误情况、令牌使用量和系统效率，帮助团队判断应用是否稳定、响应是否及时，以及问题可能发生在链路的哪个环节。
对于普通 LLM 应用，核心关注点通常是响应速度、请求处理能力和资源消耗；对于 Agent 应用，由于执行过程可能包含规划、工具调用和多轮推理，还需要补充端到端时间、首个 token 生成时间等指标。
要点： 大模型可观测性不是只看模型有没有返回结果，而是持续观察一次请求在模型、系统资源、应用链路和评测闭环中的表现。
大模型可观测性指标解决什么问题
大模型应用上线后，问题往往不只来自模型本身，也可能来自上下文过长、并发压力、外部依赖、资源瓶颈或 Agent 多步骤执行链路。持续跟踪指标，可以帮助团队更快发现问题、定位故障，并保障用户交互体验。
常见问题与指标之间的关系如下：
| 需要回答的问题 | 相关指标 | 观察价值 |
|---|---|---|
| 用户为什么感觉慢 | 延迟、TotalTime、TTFT | 判断整体响应、端到端处理和首响应体验 |
| 系统是否扛住当前请求量 | 吞吐量、延迟、错误率 | 判断容量压力和服务稳定性 |
| 推理消耗是否异常 | 令牌使用量、CPU/GPU 使用率 | 识别上下文长度、请求复杂度和资源瓶颈 |
| 请求为什么失败 | 错误率、请求处理结果 | 发现异常返回、处理失败或依赖问题 |
| 线上问题能否复用于改进 | Span 数据、线上调用样本 | 沉淀评测样本，支持后续版本评估 |
在 Agent 应用中，可观测性尤其重要。Agent 的执行过程更复杂，结果也具有一定不确定性，因此需要通过指标帮助团队了解、调试、评估并改进其性能、安全性和可靠性。
性能指标应覆盖延迟、吞吐量和整体效率
性能指标用于回答应用是否足够快、是否能处理当前请求规模，以及系统整体运行是否高效。大模型应用不宜只看单一指标，因为低延迟、高吞吐和稳定资源消耗之间，往往需要综合判断。
延迟
延迟表示从用户输入到模型输出之间的持续时间，是判断响应速度的基础指标。对于对话、搜索问答、智能客服、代码生成等交互场景，延迟会直接影响用户是否认为系统可用。
分析延迟时，可以结合以下问题：
- 输入内容或上下文是否变长；
- 并发请求是否增加；
- 模型推理、应用编排或外部依赖是否拖慢响应；
- 延迟上升是否伴随错误率或资源使用率上升。
吞吐量
吞吐量用于观察系统在一定时间内处理请求的能力。它适合与延迟一起分析：如果吞吐量上升时延迟同步上升，通常说明系统正在接近容量压力；如果吞吐量下降但错误率上升，则需要进一步排查请求失败、依赖异常或资源不足等问题。
整体系统效率
整体系统效率不是某一个单独数值，而是对响应时间、请求处理能力、错误情况和资源消耗的综合观察。只看延迟可能忽略资源过载，只看吞吐量也可能忽略用户等待时间，因此更适合把性能指标放在同一个看板中联动分析。
| 指标 | 主要含义 | 适合回答的问题 |
|---|---|---|
| 延迟 | 从输入到输出的持续时间 | 响应是否足够快 |
| 吞吐量 | 单位时间内处理请求的能力 | 当前容量是否足够 |
| 整体系统效率 | 性能、错误和资源消耗的综合表现 | 系统运行是否健康 |
稳定性指标要关注错误率和请求处理结果
错误率用于衡量请求失败、异常返回或处理失败的比例，是发现服务不稳定的重要信号。对于面向用户的大模型应用，错误率上升通常会直接影响对话连续性和任务完成率。
错误率不应孤立观察，而应与延迟、吞吐量一起分析：
- 如果错误率和延迟同时上升，可能存在资源压力、依赖变慢或请求排队；
- 如果错误率上升但吞吐量下降，需要关注服务异常、限流或外部接口失败；
- 如果错误集中在特定任务、工具或模型调用环节，应进一步结合链路数据定位。
要点： 错误率是稳定性告警的重要入口，但定位问题时仍需要结合请求链路、性能指标和资源指标共同判断。
令牌使用量和资源利用率反映运行消耗
大模型应用的运行消耗通常与输入输出规模、上下文长度、推理复杂度和计算资源有关。令牌使用量和 CPU/GPU 使用率可以帮助团队理解消耗趋势，并排查资源瓶颈。
令牌使用量
令牌使用量反映输入和输出的规模，也可以帮助观察上下文长度变化和推理消耗趋势。当令牌使用量持续上升时，通常需要关注提示词、历史对话、检索内容或工具返回内容是否过长。
令牌使用量适合与延迟联合分析：如果令牌使用量增加后延迟也明显上升，说明请求复杂度可能正在影响响应体验。
CPU/GPU 使用率
CPU/GPU 使用率用于衡量推理过程中消耗的计算资源，适合排查资源瓶颈和负载异常。资源使用率上升并不一定意味着系统异常，但如果同时出现延迟升高、错误率上升或吞吐量下降，就需要进一步分析容量和调度问题。
| 观察组合 | 可能提示的问题 | 建议分析方向 |
|---|---|---|
| 令牌使用量上升，延迟上升 | 输入输出规模或上下文变长 | 检查提示词、历史上下文和检索内容 |
| CPU/GPU 使用率上升，吞吐量下降 | 推理资源压力增大 | 检查并发、模型调用和资源容量 |
| 令牌使用量、延迟、资源使用率同时上升 | 请求复杂度和资源压力叠加 | 联合分析上下文长度、并发和链路耗时 |
Agent 应用需要补充 TotalTime 和 TTFT
Agent 应用通常不是一次简单的模型调用，而可能包含任务规划、工具调用、多轮推理和最终响应生成。因此，单独观察模型延迟往往无法反映完整链路表现，需要补充 Agent 维度的时间指标。
TotalTime
TotalTime 衡量从接收用户请求到生成最终响应的完整时间，适合观察 Agent 的端到端处理效率。它比单次模型延迟更接近用户实际等待的总时间，也能反映规划、工具调用和多轮推理带来的额外耗时。
TTFT
TTFT 表示首个 token 生成时间，关注用户等待首个响应的时间体验。对于流式输出场景，最终完成时间可能较长，但如果首个 token 更快出现，用户对等待的感知会不同；因此 TTFT 可作为首响应体验的重要补充指标。
| 指标 | 衡量范围 | 适用场景 |
|---|---|---|
| 延迟 | 通常表示从输入到输出的响应持续时间 | 观察模型或请求响应速度 |
| TotalTime | 从接收用户请求到最终响应生成的完整时间 | 观察 Agent 端到端处理效率 |
| TTFT | 首个 token 生成时间 | 观察首响应等待体验 |
要点： Agent 可观测性应同时看端到端时间和关键阶段时间，否则容易低估规划、工具调用或多轮推理带来的链路成本。
观测数据可以进入评测集形成闭环
可观测性不仅用于排障，也可以服务后续评估和改进。在支持应用观测与评测集联动的平台中，Span 数据可以被添加到评测集，用于后续应用评测；真实线上调用数据也可以作为评测样本，帮助构建更贴近实际业务场景的评测集。
这一闭环适合将线上问题、典型请求和异常案例沉淀下来，避免每次优化只依赖人工经验。
一个可复用的评测闭环
收集线上调用与 Span 数据
先记录真实请求中的关键链路信息，包括请求过程、处理结果和相关上下文。Span 数据有助于保留一次调用在链路中的过程信息。
筛选典型样本
从线上调用中筛选高频问题、慢请求、失败请求或具有代表性的业务请求，形成更贴近实际使用场景的样本集合。
加入评测集
将选出的 Span 数据或线上调用样本加入评测集，用于后续应用评估。这样可以让评测覆盖真实业务中的复杂情况。
支持版本对比和改进
当提示词、模型、工具链或 Agent 编排发生变化后，可以使用评测集对比改动前后的表现，辅助判断优化是否有效。
指标看板应按排障和评估目标分层
大模型可观测性看板可以按排障和评估目标分层，避免把所有指标堆在一起。基础层用于判断服务是否稳定运行，资源层用于识别容量压力，Agent 层用于补足复杂链路体验，评估层用于把线上观测结果沉淀为改进依据。
| 层级 | 建议指标或数据 | 主要用途 |
|---|---|---|
| 基础性能层 | 延迟、吞吐量、整体系统效率 | 判断服务响应和处理能力 |
| 稳定性层 | 错误率、请求处理结果 | 发现失败、异常和服务不稳定 |
| 消耗与资源层 | 令牌使用量、CPU/GPU 使用率 | 分析推理消耗和资源瓶颈 |
| Agent 链路层 | TotalTime、TTFT | 观察端到端效率和首响应体验 |
| 评估闭环层 | Span 数据、线上调用样本、评测集 | 将线上问题转化为可复用评测样本 |
实际落地时，可以先从延迟、吞吐量、令牌使用量、错误率和 CPU/GPU 使用率开始，建立基础监控；如果应用包含 Agent 编排，再补充 TotalTime 和 TTFT；如果希望持续改进质量和稳定性，则应把线上调用与 Span 数据纳入评测闭环。
原文链接：https://www.qianwenai.com/discover/llm-observability-metrics
