什么是大模型可观测性指标？

大模型可观测性指标，是用来理解 LLM 或 Agent 应用从接收输入到生成输出全过程运行状态的一组监控信号。它通常覆盖性能、资源消耗、错误情况、令牌使用量和系统效率，帮助团队判断应用是否稳定、响应是否及时，以及问题可能发生在链路的哪个环节。

对于普通 LLM 应用，核心关注点通常是响应速度、请求处理能力和资源消耗；对于 Agent 应用，由于执行过程可能包含规划、工具调用和多轮推理，还需要补充端到端时间、首个 token 生成时间等指标。

要点： 大模型可观测性不是只看模型有没有返回结果，而是持续观察一次请求在模型、系统资源、应用链路和评测闭环中的表现。

大模型可观测性指标解决什么问题

大模型应用上线后，问题往往不只来自模型本身，也可能来自上下文过长、并发压力、外部依赖、资源瓶颈或 Agent 多步骤执行链路。持续跟踪指标，可以帮助团队更快发现问题、定位故障，并保障用户交互体验。

常见问题与指标之间的关系如下：

在 Agent 应用中，可观测性尤其重要。Agent 的执行过程更复杂，结果也具有一定不确定性，因此需要通过指标帮助团队了解、调试、评估并改进其性能、安全性和可靠性。

性能指标应覆盖延迟、吞吐量和整体效率

性能指标用于回答应用是否足够快、是否能处理当前请求规模，以及系统整体运行是否高效。大模型应用不宜只看单一指标，因为低延迟、高吞吐和稳定资源消耗之间，往往需要综合判断。

延迟

延迟表示从用户输入到模型输出之间的持续时间，是判断响应速度的基础指标。对于对话、搜索问答、智能客服、代码生成等交互场景，延迟会直接影响用户是否认为系统可用。

分析延迟时，可以结合以下问题：

• 输入内容或上下文是否变长；
• 并发请求是否增加；
• 模型推理、应用编排或外部依赖是否拖慢响应；
• 延迟上升是否伴随错误率或资源使用率上升。

吞吐量

吞吐量用于观察系统在一定时间内处理请求的能力。它适合与延迟一起分析：如果吞吐量上升时延迟同步上升，通常说明系统正在接近容量压力；如果吞吐量下降但错误率上升，则需要进一步排查请求失败、依赖异常或资源不足等问题。

整体系统效率

整体系统效率不是某一个单独数值，而是对响应时间、请求处理能力、错误情况和资源消耗的综合观察。只看延迟可能忽略资源过载，只看吞吐量也可能忽略用户等待时间，因此更适合把性能指标放在同一个看板中联动分析。

稳定性指标要关注错误率和请求处理结果

错误率用于衡量请求失败、异常返回或处理失败的比例，是发现服务不稳定的重要信号。对于面向用户的大模型应用，错误率上升通常会直接影响对话连续性和任务完成率。

错误率不应孤立观察，而应与延迟、吞吐量一起分析：

• 如果错误率和延迟同时上升，可能存在资源压力、依赖变慢或请求排队；
• 如果错误率上升但吞吐量下降，需要关注服务异常、限流或外部接口失败；
• 如果错误集中在特定任务、工具或模型调用环节，应进一步结合链路数据定位。

要点： 错误率是稳定性告警的重要入口，但定位问题时仍需要结合请求链路、性能指标和资源指标共同判断。

令牌使用量和资源利用率反映运行消耗

大模型应用的运行消耗通常与输入输出规模、上下文长度、推理复杂度和计算资源有关。令牌使用量和 CPU/GPU 使用率可以帮助团队理解消耗趋势，并排查资源瓶颈。

令牌使用量

令牌使用量反映输入和输出的规模，也可以帮助观察上下文长度变化和推理消耗趋势。当令牌使用量持续上升时，通常需要关注提示词、历史对话、检索内容或工具返回内容是否过长。

令牌使用量适合与延迟联合分析：如果令牌使用量增加后延迟也明显上升，说明请求复杂度可能正在影响响应体验。

CPU/GPU 使用率

CPU/GPU 使用率用于衡量推理过程中消耗的计算资源，适合排查资源瓶颈和负载异常。资源使用率上升并不一定意味着系统异常，但如果同时出现延迟升高、错误率上升或吞吐量下降，就需要进一步分析容量和调度问题。

Agent 应用需要补充 TotalTime 和 TTFT

Agent 应用通常不是一次简单的模型调用，而可能包含任务规划、工具调用、多轮推理和最终响应生成。因此，单独观察模型延迟往往无法反映完整链路表现，需要补充 Agent 维度的时间指标。

TotalTime

TotalTime 衡量从接收用户请求到生成最终响应的完整时间，适合观察 Agent 的端到端处理效率。它比单次模型延迟更接近用户实际等待的总时间，也能反映规划、工具调用和多轮推理带来的额外耗时。

TTFT

TTFT 表示首个 token 生成时间，关注用户等待首个响应的时间体验。对于流式输出场景，最终完成时间可能较长，但如果首个 token 更快出现，用户对等待的感知会不同；因此 TTFT 可作为首响应体验的重要补充指标。

要点： Agent 可观测性应同时看端到端时间和关键阶段时间，否则容易低估规划、工具调用或多轮推理带来的链路成本。

观测数据可以进入评测集形成闭环

可观测性不仅用于排障，也可以服务后续评估和改进。在支持应用观测与评测集联动的平台中，Span 数据可以被添加到评测集，用于后续应用评测；真实线上调用数据也可以作为评测样本，帮助构建更贴近实际业务场景的评测集。

这一闭环适合将线上问题、典型请求和异常案例沉淀下来，避免每次优化只依赖人工经验。

一个可复用的评测闭环

收集线上调用与 Span 数据

先记录真实请求中的关键链路信息，包括请求过程、处理结果和相关上下文。Span 数据有助于保留一次调用在链路中的过程信息。

筛选典型样本

从线上调用中筛选高频问题、慢请求、失败请求或具有代表性的业务请求，形成更贴近实际使用场景的样本集合。

加入评测集

将选出的 Span 数据或线上调用样本加入评测集，用于后续应用评估。这样可以让评测覆盖真实业务中的复杂情况。

支持版本对比和改进

当提示词、模型、工具链或 Agent 编排发生变化后，可以使用评测集对比改动前后的表现，辅助判断优化是否有效。

指标看板应按排障和评估目标分层

大模型可观测性看板可以按排障和评估目标分层，避免把所有指标堆在一起。基础层用于判断服务是否稳定运行，资源层用于识别容量压力，Agent 层用于补足复杂链路体验，评估层用于把线上观测结果沉淀为改进依据。

实际落地时，可以先从延迟、吞吐量、令牌使用量、错误率和 CPU/GPU 使用率开始，建立基础监控；如果应用包含 Agent 编排，再补充 TotalTime 和 TTFT；如果希望持续改进质量和稳定性，则应把线上调用与 Span 数据纳入评测闭环。