外观
监控与可观测性
一句话定义：监控（monitoring）是对生产推理服务的指标、日志、追踪做持续采集与告警，并在模型失效前发现它——可观测性让"模型有没有在好好干活"从玄学变成数据。
行业洞察：监控模型比监控普通服务难得多，因为普通服务的故障特征是"代码不动、行为不变"；而模型的"代码"（权重）也是不动，但数据会变——用户习惯变了、推荐热点变了、输入的文本风格变了，模型的效果就在无声中下滑。等业务方反馈"最近推荐越来越不准"时，往往已经滑了一两周。业界的共识是：推理服务的监控要同时看"系统健康"和"模型健康"两本账——系统挂了要马上知道（分钟级），模型变差了要尽早发现（小时~天级，靠漂移检测 + 效果回捞）。
一、为什么模型监控更难
text
普通服务： 代码 ──► 行为（不变） 故障 = 代码/基础设施坏了，重启/回滚即恢复
模型服务： 代码 + 权重（不变）──► 行为（随数据漂移）
输入分布 ──► 效果（可能渐变恶化）模型监控必须回答三类问题：
- 系统层面：服务还活着吗？够快吗？还有资源吗？
- 数据层面：输入分布变了吗（数据漂移）？目标概念变了吗（概念漂移）？
- 效果层面：模型指标（AUC/点击率/翻译质量）下滑了吗？
二、四类黄金指标（USE Method）
经典的四类黄金指标（RED/Latency 流派）在推理服务里同样适用：
| 类别 | 指标示例 | 告警经验值 |
|---|---|---|
| 延迟（Latency） | P50/P99/P999、TTFT/TPOT | P99 超 SLO 阈值即告警；连续 5 分钟 |
| 流量（Traffic） | QPS、并发、输入 bytes | 突增/突降 5 倍以上要查 |
| 错误（Errors） | 5xx 率、超时率、OOM 数 | 错误率 > 1% 即 P1 |
| 饱和度（Saturation） | GPU 利用率、队列深度、显存水位 | 队列深度持续增长 / 显存 > 85% |
USE 方法在 GPU 服务的用法
对推理服务，饱和度用两个指标：GPU 利用率（SM%）与显存占用。但注意推理多为带宽受限，SM% 低不等于空闲——真正要看的是"排队等待数"是否在涨。详见 性能优化与容量规划。
三、ML 特有的监控：漂移检测
1. 数据漂移（feature drift）vs 概念漂移（concept drift）
| 类型 | 定义 | 例子 | 后果 |
|---|---|---|---|
| 数据漂移 | 输入特征分布变了 | 新用户激增、天气突变、文本风格变化 | 模型见过/没见过的分布比例失衡 |
| 概念漂移 | 输入分布没变，但"输入→标签"的关系变了 | 用户口味整体转向；汇率政策变化 | 模型学到的规律过时了 |
区分两者的意义在于对策不同：数据漂移 → 重采样训练数据、加强归一化；概念漂移 → 重新训练模型。
2. 检测手段
| 方法 | 适用 | 阈值经验值 |
|---|---|---|
| PSI（Population Stability Index） | 单维特征的分布偏移 | PSI > 0.2 告警（0.1~0.2 关注，<0.1 正常） |
| KS 检验（Kolmogorov-Smirnov） | 两分布是否显著不同 | p < 0.05 认为有漂移 |
| Embedding 分布距离（MMD、KL） | 高维语义分布 | 相对基线设定 |
| 预测分布监控 | 输出概率分布变化 | 常是概念漂移的早期信号 |
python
# PSI 计算示意（按分箱统计）
def psi(expected, actual, bins=10):
# 把两分布按同一分位点切 10 箱
# psi += (actual_ratio - expected_ratio) * ln(actual_ratio / expected_ratio)
# 经验：>0.2 视为显著漂移
return psi_value漂移检测的两个陷阱
- 监控什么特征：只监控"模型真正依赖且线上会变的特征"，全量监控只会刷屏；
- 基线要定期更新：把"上月"当基线，漂移检测才有意义；拿"训练集"当永久基线，正常的产品演进也会触发告警。
3. 效果回捞：漂移检测的补充
漂移检测是"代理指标"，最终要落到效果指标上。做法：
- 在线 A/B 或影子打分（shadow scoring）持续记录模型输出与真实反馈（如点击率）；
- 抽样人工标注（如翻译质量、审核准确率）；
- 周期性离线评估（batch scoring），对生产数据跑评估集。
四、可观测性三支柱
| 支柱 | 工具 | 推理服务的关注点 |
|---|---|---|
| 指标（Metrics） | Prometheus + Grafana | 黄金指标、漂移指标、GPU 指标 |
| 日志（Logs） | 结构化日志 + Loki/ELK | 请求级 detail、错误堆栈、特征快照 |
| 追踪（Traces） | OpenTelemetry + Jaeger/Tempo | 一次推理请求跨网关/服务/模型的完整链路 |
三支柱在推理服务的落地要点：
- 追踪必须带上模型版本与输入概要：查问题时"这个请求用的是 v2 模型还是 v3"是最高频问题；
- 结构化日志：JSON 格式、带
trace_id、model_version、latency_ms字段，方便聚合； - 请求采样：全量日志成本高，P99 慢请求全量记录 + 正常请求 1% 采样是常用组合。
完整落地方法见 可观测性落地。
五、告警设计：SLO 燃烧率与分级
1. SLO 燃烧率（burn rate）
Google SRE 的告警框架：按"多快会耗尽错误预算"来告警。若 SLO 是"30 天 P99 < 100ms 达标率 99.9%"：
- 燃烧率 = 实际错误率 ÷ 允许错误率（0.1%）；
- 燃烧率 ≥ 14.4 持续 1 小时 → 页面告警（因为 14.4×1h ≈ 30 天的 2% 错误预算被烧光）；
- 燃烧率 ≥ 6 持续 6 小时 → 告警。
2. 分级告警，避免告警疲劳
| 级别 | 含义 | 例子 | 响应 |
|---|---|---|---|
| P1 | 服务不可用/严重 | 推理服务 5xx > 5%、GPU 掉卡 | 立即 On-call |
| P2 | 功能受损 | 漂移告警、P99 持续超标 | 工作时间内处理 |
| P3 | 潜在风险 | 显存水位 80%、错误预算剩余 10% | 记录跟进 |
告警疲劳是真实事故
告警太多 → 没人认真看 → 真 P1 也被忽略。经验法则：每名 On-call 每周被分页唤醒不应超过 1~2 次。超过就调阈值或删指标。
六、模型上线后的监控清单（前 30 天）
新模型上线后的监控重点与成熟模型不同，前 30 天重点看：
| 时间窗 | 重点 | 原因 |
|---|---|---|
| 第 1 天 | 加载/预热是否成功、首小时延迟分布 | 扩容、缓存未热，最容易暴露配置问题 |
| 第 1 周 | P99 稳定性、错误率、显存水位 | 排查资源估算偏差 |
| 第 2 周 | 特征分布 vs 训练分布、效果指标基线 | 上线时的分布代差显现 |
| 第 30 天 | 与旧版本做全量 A/B 效果对比 | 决定是否回滚或固化新版本 |
与 MLOps 的关联：上线与回滚流程见 发布策略：灰度与回滚，完整流水线见 MLOps 部署流水线。
权衡与取舍
| 决策点 | 选项 | 怎么选 |
|---|---|---|
| 指标数量 | 精简 vs 全量 | 黄金指标打底，每加一个指标都要有用途 |
| 采样 vs 全量 | 省钱 vs 完整 | 慢请求全量、正常请求采样 |
| 漂移检测频率 | 实时 vs 小时级 | 在线高价值场景实时；一般场景小时级够 |
| 告警阈值 | 敏感 vs 宽松 | 以"每周唤醒 ≤1~2 次"倒推 |
| 自建 vs 托管 | 自己搭栈 vs SaaS | 团队规模与预算决定，工具见 资源 |
一句话总结：推理服务要同时盯系统健康与模型健康两本账——黄金指标保"活着"，漂移检测保"还有效"，三支柱提供追查能力，分级告警保证有人响应。
延伸阅读
- 可观测性落地 —— 三支柱从零搭建的实操指南
- MLOps 部署流水线 —— 监控在流水线中的关卡位置
- 性能优化与容量规划 —— 饱和度指标与容量核算
- 常见陷阱与反模式 —— 监控缺失导致的经典事故
- 安全、隐私与合规 —— 监控日志的隐私边界