Monitoring
模型服务监控将请求、模型、硬件和业务信号转化为可操作的可观测性。监控的目的不是堆指标，而是让任何异常都能被快速定位到「服务层、推理层、硬件层还是质量层」，并在用户感知到问题之前触发告警。
快速开始¶
先采集核心指标：请求量（QPS）、错误率、TTFT、TPOT、队列长度、GPU 显存占用、GPU 利用率和成本。延迟指标要按 p50/p95 分位统计，而不是只看平均值，因为尾延迟往往是最先出问题的地方。
指标选择可以参考 Google SRE 的「四个黄金信号」：延迟、流量、错误、饱和度，详见 SRE Book 的监控章节。四个信号分别对应「用户等多快」「来多少请求」「失败多少」「还有多少余量」，是推理服务告警的最小集合。尾延迟用分位数而非均值的原因在于：均值会被大量快速请求拉低，而 p95 反映的是「最慢的 5% 用户体验」，这正是 SLO 通常用分位数表述的原因。
为每次请求关联一个 request ID，贯穿接入层、调度器、推理引擎和日志，这样任何一条异常请求都能端到端回溯。request ID 是监控与日志对账的锚点，没有它，分布式环境下的排障会退化成猜谜。
把指标导出到统一的可观测平台，并针对关键指标设置告警阈值：例如 p95 TTFT 超过目标、错误率突增、队列持续增长、显存接近上限。告警要能区分「需要立即处理」和「仅需观察」，避免告警疲劳。基于 SLO 的告警应围绕「错误预算」而非单一阈值：错误预算 = 1 − 目标可用率，可用率越高留给异常的时间越少，告警应在这个预算被烧光前触发，相关推导见 SRE Workbook 的错误预算章节。
指标层次¶
服务层关注可用性与延迟：请求量、成功率、错误率、TTFT、TPOT、并发度。这一层回答「用户现在体验如何」，是最直接的服务健康信号。
推理层关注 token 吞吐与 cache：输入/输出 token/s、prefill 与 decode 各自耗时、KV Cache 命中率、调度队列长度、抢占次数。这一层回答「推理引擎是否高效」，是定位延迟和吞吐问题的入口。TTFT 与 TPOT 的拆分、吞吐口径的区分可参考 kubernetes-sigs/inference-perf 的指标定义，用统一的量纲让不同引擎、不同平台的数字可比。
硬件层关注利用率与错误：GPU 利用率、显存占用、功耗、温度、网卡与存储的吞吐、以及硬件报错。这一层回答「机器是否健康」，也是成本核算的基础数据。GPU 利用率要结合显存占用一起看：利用率高但显存不足时，瓶颈可能是 KV Cache 而非算力。
质量层关注拒答与格式失败：输出为空、格式解析失败、越界输出、工具调用错误的占比。这一层回答「生成内容是否可用」，与延迟、吞吐同样重要，却容易被只盯性能的团队忽略。质量指标常被拆成「有效完成请求 / 总请求」的形式，即 goodput，可参考 inference-perf 的 goodput 定义。
案例¶
某服务 p95 TTFT 上升，团队同时查看了排队 token 数、prefill 吞吐和新版本发布比例。发现排队 token 上升、prefill 吞吐下降，同时有新版本正在灰度发布，但 GPU 利用率反而下降。
进一步排查定位到不是模型变慢，而是新版本的前置数据或路由配置出了问题，导致请求被错误分发或数据加载变慢。这说明单看 GPU 利用率下降时，不应直接下「模型变慢」的结论，而要结合排队、prefill 和版本信息交叉判断。
修复后重新观察各层指标，确认 p95 TTFT 回落、prefill 吞吐恢复。结论是监控必须分层并支持交叉下钻，单点指标不足以定位推理服务的复杂故障。