推理服务观测看什么？延迟、吞吐与结果质量

推理服务上线后，监控不能停留在进程存活和 HTTP 状态码。服务可能没有报错，但延迟已经恶化；模型可能正常返回，但结果质量已经下降。

推理观测需要同时覆盖系统稳定性和模型结果质量。只看系统指标，无法判断模型是否有用；只看模型效果，又可能忽略服务是否稳定。

一套可用的观测体系，应能回答：请求是否变慢、吞吐是否下降、资源是否接近瓶颈、错误集中在哪里、输出结果是否出现异常变化。

相关主题可以结合 模型推理、模型部署、AI基础设施 一起阅读。本文重点放在推理与部署的工程边界、稳定性指标和平台化治理方法上，避免只停留在概念解释。

延迟指标要看分布

平均延迟只能反映整体趋势，不能代表用户体验。P95、P99 和最大延迟更能体现长尾问题。

延迟还应拆分为入口、排队、批处理、模型执行和后处理等阶段。否则总延迟升高时难以定位。

推理延迟观测的重点是分布和阶段，而不是一个平均值。

吞吐要结合队列判断

吞吐高不一定代表服务健康。如果吞吐提高的同时队列变长、长尾延迟恶化，说明服务可能已经接近瓶颈。

吞吐指标应结合 QPS、批大小、队列长度、拒绝请求和限流情况一起看。

不同模型的吞吐目标不同，应按模型和服务等级拆分，而不是只看平台总量。

错误率要能定位到版本和副本

推理服务错误可能来自模型加载失败、输入格式错误、资源不足、依赖超时或副本异常。

错误率必须按模型版本、副本、租户和入口拆分，才能快速定位影响范围。

整体错误率低不代表没有问题，低流量模型的错误可能被平台平均值掩盖。

资源水位是风险前置信号

GPU 利用率、显存、CPU、内存、网络和磁盘 IO 都会影响推理稳定性。资源水位接近阈值时，延迟和错误率可能很快恶化。

显存尤其关键。显存不足可能导致模型加载失败、批处理受限或多模型共存失败。

资源指标要和请求指标对齐，才能判断服务问题是否由容量引起。

结果质量需要单独观测

模型服务返回 200，不代表结果正确。输出分布、置信度、命中率、人工反馈、关键样本结果和业务转化都可能反映质量变化。

结果质量指标通常需要结合业务语义设计，不能完全套用系统监控方式。

模型观测的独特价值，是发现服务正常但结果变差的情况。

观测要服务发布和回滚

灰度发布、版本升级和回滚都依赖观测数据。没有按版本拆分的指标，就无法判断新模型是否真的更好。

观测面板应支持版本对比、租户过滤、时间窗口对齐和关键样本追踪。

当观测能直接支撑发布决策，推理服务才具备持续迭代能力。

指标要按角色组织

平台工程团队、算法团队和业务团队关注的观测指标不同。平台团队关注延迟、资源和错误；算法团队关注输出分布、置信度和样本；业务团队关注转化、命中和用户反馈。

如果所有指标混在一个面板里，反而会降低排查效率。更好的方式是保留统一数据底座，再按角色组织视图。观测不是堆指标，而是让不同角色快速回答自己的问题。

同一套推理服务，可以有运行视图、模型质量视图、发布对比视图和成本视图。

版本维度非常关键

推理服务经常存在多个模型版本并行，尤其在灰度和 A/B 测试阶段。如果指标不能按版本拆分，就无法判断新版本是否带来延迟、错误或质量变化。

版本维度应贯穿日志、指标和样本记录。每一次请求都应能追溯到模型版本、服务版本和路由规则。

没有版本维度的观测，无法支撑模型持续迭代。

样本观测补足指标盲区

数值指标能发现趋势，但不一定能解释模型具体错在哪里。关键样本、异常样本和人工反馈可以帮助团队理解模型结果质量。

样本观测应覆盖高风险场景、边界输入、长尾用户和业务重点请求。只看随机样本，可能错过最重要的问题。

对于生成类或推荐类模型，样本观测尤其重要，因为结果质量很难完全用单一数值衡量。

观测数据要能触发动作

观测的目的不是展示漂亮图表，而是支撑扩容、限流、灰度暂停、回滚和模型优化。每个关键指标都应该对应可能的处理动作。

例如 P99 延迟升高可能触发扩容或路由切换，结果质量异常可能触发灰度暂停，显存水位过高可能触发批处理调整。

能触发动作的观测，才是真正进入生产治理的观测。否则指标再多，也只是事后解释。

观测建设可以分阶段

第一阶段先补基础运行指标，包括延迟、吞吐、错误率、队列长度和资源水位。第二阶段按模型版本、租户和入口拆分，解决平均值掩盖问题。第三阶段再补结果质量和样本观测。

不要一开始追求所有指标完备，否则观测建设容易停留在设计阶段。先覆盖最常见的排障问题，再逐步补模型质量和发布决策指标。

观测体系还要定期复盘。每次故障后都应问一个问题：当时缺少哪个指标导致排查变慢，然后把它补进下一轮建设。

从观测到告警的边界

不是所有观测指标都适合直接告警。延迟、错误率、资源水位和队列长度适合设置明确阈值；结果质量、输出分布和业务指标则需要结合时间窗口和样本分析。

告警太少会错过问题，告警太多会让团队疲劳。推理服务更适合把高确定性的系统异常做实时告警，把需要解释的模型质量指标做趋势分析和发布观察。

观测和告警的边界清楚后，团队既能快速响应服务故障，也能持续跟踪模型质量变化，而不是被大量低价值告警淹没。

观测数据还应进入日常复盘。平台团队可以定期查看哪些模型长尾延迟最突出，哪些版本错误率异常，哪些资源池显存水位长期偏高。这样观测就不只是事故工具，也能成为容量规划和模型优化的依据。

小结

推理观测要同时回答两个问题：服务是否稳定，模型结果是否可靠。延迟、吞吐、错误率和资源水位能定位系统问题，输出分布、关键样本和业务反馈则能发现结果质量变化，两类指标缺一不可。

常见问题

推理服务观测为什么要同时看系统指标和结果质量？

推理服务可能系统指标正常，但模型结果已经发生漂移；也可能结果质量正常，但延迟和错误率已经影响用户体验。系统指标回答服务是否稳定，结果质量回答模型是否可靠，两者缺一不可。只看延迟、吞吐和资源水位，容易漏掉输出分布异常；只看效果样本，又会忽略容量、超时和成本问题。

结果质量指标应该如何落地？

不同模型的结果质量指标不同，不能直接套用一套固定面板。分类模型可以关注置信度分布、空结果比例和关键类别变化；生成式模型可以关注输出长度、拒答率、异常格式、人工反馈和敏感样本；推荐或排序模型则要结合点击、转化和业务反馈。早期可以先从关键样本和分布监控做起，再逐步接入业务闭环。

观测面板应该按什么维度拆分？

至少应支持按模型、版本、租户、入口、节点和副本拆分。推理问题经常是局部发生的，如果所有指标混在一起，平均值会掩盖特定版本或特定租户的异常。对于灰度发布，还要能单独比较新旧版本的延迟、错误率、资源水位和结果分布，否则灰度只是在切流量，而不是在验证风险。

告警应该覆盖哪些异常？

告警不应只覆盖服务不可用。更实用的告警包括 P95/P99 延迟升高、错误率或超时增加、队列持续堆积、显存接近上限、副本频繁重启、输出分布突变、空结果比例异常和关键样本失败。不同告警需要分级处理，避免所有问题都变成同一类紧急告警，最终让团队对告警失去信任。