没有监控的推理服务，就像没有仪表盘的飞机
2026年，大多数AI团队部署完推理服务后，就以为"万事大吉"了。但模型不是"部署完就完了"——它会衰退。
模型衰退的三种表现：
- 性能衰退： 输出质量随时间下降（因为数据分布变化）
- 延迟衰退： KV Cache碎片化导致推理越来越慢
- 成本失控： 某个"坏"请求导致GPU利用率异常
没有监控，你不知道模型正在"悄悄变蠢"。 直到用户投诉"AI变差了"，你才意识到问题——但此时已经流失了大量用户。
我们在2026年设计了一套完整的推理监控体系，覆盖了4个层面的监控。
层面1：基础设施监控（Infrastructure）
这是最基础的监控——GPU还活着吗？
关键指标：
- GPU利用率（%）：应该在70-85%。低于50%说明GPU在"摸鱼"，高于95%说明GPU过载。
- 显存使用量（GB）：应该在80%以内。超过90%说明有OOM风险。
- GPU温度（°C）：应该在70°C以内。超过80°C会触发降频保护。
- 功耗（W）：应该在额定功率的80%以内。
工具： nvidia-smi + Prometheus Node Exporter + DCGM Exporter
告警规则： GPU利用率<30%持续10分钟 → 告警；GPU温度>80°C → 告警；显存使用>90% → 告警。
层面2：推理服务监控（Service）
推理服务是否正常运行？
关键指标：
- 请求数（QPS）：每秒处理的请求数
- 延迟（P50/P95/P99）：TTFT和TPOT的分布
- 错误率（%）：500错误、超时、OOM错误
- 吞吐量（tokens/s）：每秒生成的token数
工具： vLLM metrics endpoint + Prometheus + Grafana
告警规则： P99延迟 > 1秒 → 告警；错误率 > 1% → 告警；吞吐量下降30% → 告警。
层面3：模型质量监控（Quality）
这是最容易被忽略的监控——模型的输出质量如何？
关键指标：
- 输出质量评分：用GPT-5自动评分（每天抽样100条），1-5分
- 拒绝率（%）：模型拒绝回答的比例。如果拒绝率突然升高，说明安全对齐过强，模型"不敢说话"
- 输出长度分布：平均输出长度。如果突然变长或变短，说明模型行为异常
- 幻觉率（%）：用事实核查工具检测幻觉
工具： 自建的质量评分Pipeline + GPT-5 API + LangSmith/LangFuse
告警规则： 输出质量评分连续下降1周 → 告警；拒绝率变化超过20% → 告警；幻觉率超过5% → 告警。
层面4：用户反馈监控（Feedback）
用户是否满意？
关键指标：
- 用户满意度评分（👍/👎比例）
- 用户投诉率（%）
- 任务完成率（用户是否完成了任务）
- 重复提问率（用户是否因为不满意而重新提问）
告警规则： 用户满意度评分下降10% → 告警；投诉率上升50% → 告警。
监控的"黄金信号"
Google SRE的"四个黄金信号"同样适用于推理服务：
- 延迟（Latency）： P50/P99 TTFT和TPOT
- 流量（Traffic）： QPS、吞吐量
- 错误（Errors）： 错误率、OOM率
- 饱和度（Saturation）： GPU利用率、显存使用率
四个黄金信号 + 模型质量评分 = 完整的推理监控体系。
监控数据的"故事"
监控数据不是"数字"，而是"故事"。 一个好的监控系统，应该能告诉你：“昨天晚上8点，模型延迟突然飙升，因为有一个用户提交了一个100K tokens的超长prompt，导致KV Cache碎片化，P99延迟从200ms飙升到5000ms。”
这需要：监控数据 + 关联分析 + 根因定位。
工具推荐： Grafana + Prometheus + Loki（日志）+ Tempo（链路追踪），四件套可以覆盖所有监控需求。
结语：监控是"保险"，不是"负担"
监控不是"又一项工作"，而是"为你的推理服务买保险"。 没有监控，模型在"悄悄变蠢"，用户在被"悄悄流失"。当你发现问题时，已经晚了。
推理监控的最低要求：GPU利用率 + 延迟 + 错误率 + 模型质量评分。 四个指标，一个Grafana Dashboard，就能覆盖80%的监控需求。
数据来源：Google SRE Book，Prometheus/Grafana文档，作者团队推理监控实践（2026年）。