监控围绕四类指标
推理服务的监控不必面面俱到，但四类必须齐：延迟（首 token 延迟、单 token 输出时间与分位值）、吞吐（统一口径的每秒输出 token 数与请求数）、资源（KV 水位、显存占用与计算单元利用率）、健康（错误率、超时率与重启次数）。每类钉一个面板加一条告警，值班时才有可用的线索。
四类指标
| 类别 | 代表指标 | 用途 |
|---|---|---|
| 延迟 | 首 token 延迟、单 token 输出时间、分位值 | 衡量体验与对照服务目标 |
| 吞吐 | 每秒输出 token 数、每秒请求数 | 容量规划与成本核算的输入 |
| 资源 | KV 水位、显存占用、计算单元利用率 | 决定扩容与调参方向 |
| 健康 | 错误率、超时率、重启次数 | 判断服务是否稳定 |
每类钉一个动作
| 延迟 | 面板看分位曲线，告警看尾延迟是否超过约定阈值 |
|---|---|
| 吞吐 | 固定统计口径，否则与历史数据不可比 |
| 资源 | 看 KV 水位与等待请求数的组合含义 |
| 健康 | 按状态码分类统计，客户端错误与服务端错误分开算 |
核对指标的入口
核对指标的入口
# 引擎侧指标端点（以实际实现为准，通常在内网端口）
curl -s http://127.0.0.1:8000/metrics | head -20
# 硬件侧：显存与利用率的结构化输出
nvidia-smi --query-gpu=index,memory.used,utilization.gpu --format=csv,noheader,nounits
# 网关侧：状态码分布与时延统计看访问日志典型使用场景
- 容量规划：用吞吐与 KV 水位两条曲线判断何时需要扩容
- 上线验证：灰度期间对比新旧版本的延迟分位，决定是否继续放量
- 故障止损：错误率与超时率突增时先看面板再决定摘实例还是回滚
- 成本核算：以稳定态吞吐作为每百万 token 成本的输入
- 复盘取证：保留变更时间轴，让指标突刺能对应到具体改动
指标不在多，在于能对应处置动作：一条告警如果值班看到后不知道该做什么，它带来的价值很有限，还会造成告警疲劳。
监控端点默认面向内网：指标会暴露内部拓扑与容量信息，绑定的监听地址、防火墙与网关鉴权要三层收口。