📚 课程目录第4章关键监控指标

4. 关键监控指标

云端AI部署与普通Web服务最大的差异在于：AI系统的性能不仅取决于基础设施是否健康，更取决于模型行为是否符合预期。一个CPU利用率100%的节点可能是负载过高，也可能是死循环；一个错误率从0.1%跳到0.3%可能是流量突增，也可能是输入数据分布发生了偏移。因此，我们需要建立一套分层监控指标体系，从服务性能、资源消耗和模型质量三个维度全面观测系统状态。

4.1 延迟（Latency）：用户体验的第一道门槛

延迟衡量的是从客户端发起请求到收到完整响应所经历的时间。在AI推理场景中，延迟通常被拆解为三个部分：网络传输时间、排队等待时间和模型推理时间。其中模型推理时间又包含预处理（如文本分词、图像缩放）、张量计算和后处理（如softmax、阈值过滤）三个阶段。

监控延迟时，不能只关注平均值。由于AI推理的算力波动和批处理机制，延迟分布往往呈现长尾特征。建议同时跟踪以下分位数：

P50（中位数）：反映典型用户体验，用于容量规划。
P95 / P99：反映最差情况下的体验，用于SLO告警。
P99.9：捕捉极端异常，如GC停顿、GPU时钟降频等。

此外，还需区分端到端延迟与模型推理延迟。前者包含API网关、负载均衡、序列化等开销，后者仅指模型计算本身。当端到端延迟升高而推理延迟正常时，问题往往出在网络或中间件层；反之，则需检查模型输入尺寸、批处理大小或GPU利用率。

# 典型延迟监控指标（Prometheus示例）
ai_inference_duration_seconds{model="resnet50", quantized="false"}
ai_inference_duration_seconds{quantile="0.5"}
ai_inference_duration_seconds{quantile="0.99"}

实践建议：为每个模型版本单独记录延迟指标，并标注model_version标签。模型升级后，通过对比新旧版本的P99延迟，可以快速判断性能回退是否由代码变更引起。

4.2 吞吐量（Throughput）：衡量系统的处理能力

吞吐量指单位时间内系统成功处理的请求数（QPS）或推理样本数。在GPU推理服务中，吞吐量通常以每秒处理的样本数（samples/s）或每秒推理次数（inferences/s）表示。吞吐量与延迟存在内在矛盾：一味追求低延迟会限制批处理大小，降低吞吐；而增大批处理虽能提升吞吐，却会推高单请求延迟。

监控吞吐量时，需要关注两个层面：

入口吞吐量：API网关接收到的请求速率，反映业务流量大小。
出口吞吐量：模型服务实际完成的推理速率，反映系统真实处理能力。

当入口吞吐量持续大于出口吞吐量时，队列会不断积压，最终导致超时雪崩。因此，建议将队列积压深度作为辅助指标一并监控。

4.3 错误率（Error Rate）：故障的显性信号

错误率是AI服务最直接的“健康晴雨表”。但错误不能一概而论，需要按类型细分：

错误类型	典型原因	处理策略
4xx 客户端错误	请求参数格式错误、缺少必填字段	通常无需告警，可统计占比用于API设计优化
5xx 服务端错误	模型推理异常、依赖服务不可用	立即告警，触发自动重试或降级
超时错误	推理耗时超过客户端超时阈值	检查延迟指标，可能需要扩容或优化模型
模型质量错误	推理结果置信度过低、输出为NaN	需结合模型漂移指标分析

除了HTTP状态码，AI服务还应监控推理结果异常率。例如，图像分类模型返回的类别概率全部低于0.1，或文本生成模型输出为空字符串，这些情况HTTP状态码仍为200，但业务上属于失败。

4.4 资源利用率：CPU/GPU/内存的精细观测

资源利用率监控需要区分节点级和进程级。节点级指标反映整个虚拟机的健康状态，进程级指标则精确到模型容器。对于GPU推理服务，以下指标尤为关键：

GPU利用率（%）：SM（流式多处理器）的忙碌程度。注意，GPU利用率低不一定代表空闲，可能是内存带宽瓶颈或kernel启动开销过大。
GPU显存使用量：监控显存占用和显存带宽。显存溢出会导致OOM（Out of Memory）崩溃。
CPU利用率：关注数据预处理、后处理线程的CPU消耗。当GPU利用率高而CPU利用率低时，说明预处理效率不足，GPU在等待数据。
内存使用量：包括堆内存和非堆内存。Java/Python服务需特别关注GC（垃圾回收）频率和停顿时间。

# GPU监控关键指标（DCGM示例）
dcgm_gpu_utilization{gpu_id="0"}          # GPU利用率
dcgm_fb_used{gpu_id="0"}                  # 显存已用量（MB）
dcgm_sm_clock{gpu_id="0"}                 # SM时钟频率（MHz）
dcgm_mem_copy_utilization{gpu_id="0"}     # 显存带宽利用率

常见误区：仅监控GPU利用率而忽略显存带宽利用率。某些模型（如Transformer）是显存带宽密集型，SM利用率可能只有40%，但显存带宽已接近饱和。此时增加GPU数量无法提升性能，需要优化模型结构或使用量化。

4.5 模型漂移指标：AI监控的独特维度

模型漂移（Model Drift）指模型在生产环境中的表现与训练时不一致的现象。漂移分为两类：数据漂移（输入分布变化）和概念漂移（输入与输出的映射关系变化）。监控漂移需要定期计算统计量：

PSI（Population Stability Index，群体稳定性指数）：衡量特征分布的变化程度。PSI < 0.1 表示稳定，0.1~0.25 表示轻度漂移，> 0.25 表示显著漂移。
KL散度 / JS散度：衡量当前输入分布与训练集分布的差异。
预测置信度均值：如果模型对近期请求的平均置信度持续下降，可能遇到了分布外（OOD）数据。
标签分布变化：对于有延迟标签的场景（如点击率预测），对比预测标签与回传真实标签的分布差异。

# 漂移检测伪代码
def compute_psi(expected_dist, actual_dist, buckets=10):
    psi = 0
    for i in range(buckets):
        expected_pct = expected_dist[i] + 1e-6
        actual_pct = actual_dist[i] + 1e-6
        psi += (actual_pct - expected_pct) * math.log(actual_pct / expected_pct)
    return psi

4.6 监控指标关联分析：从孤岛到全景

单一指标无法定位问题根因，必须建立指标间的关联分析能力。下图展示了AI推理服务中各类监控指标的关联关系与故障传播路径：

上图揭示了几个关键关联模式：

延迟升高 + GPU利用率低：可能原因包括数据加载瓶颈、CPU预处理不足或网络I/O阻塞。
错误率升高 + 显存增长：可能发生了显存泄漏，需要检查推理框架的内存管理。
吞吐量下降 + 漂移指标升高：模型可能遇到了分布外数据，导致推理路径变慢（如触发更多条件分支）。

4.7 案例复盘：一次GPU利用率“假饱和”的排查

某团队部署的BERT问答服务出现P99延迟从80ms升至300ms的异常。初步监控显示GPU利用率达到95%，团队第一反应是“算力不足”，准备扩容。但进一步查看显存带宽利用率后发现仅为30%，且SM活跃线程数远低于预期。

通过 profiling 工具定位，发现罪魁祸首是动态形状输入：由于请求文本长度差异极大，模型每次推理都需要重新编译CUDA kernel，导致大量时间消耗在kernel编译上而非实际计算。解决方案是将输入按长度分桶（bucketing），相同长度范围的请求共享同一kernel，P99延迟降至110ms。

  复盘要点：GPU利用率高并不等于GPU“忙得有效率”。必须结合kernel编译次数、显存带宽、SM占用率等多维指标综合判断。建议为每个模型建立资源画像基线，当指标偏离基线20%以上时触发详细分析。

4.8 监控指标配置清单

综合上述分析，一个生产级AI推理服务的监控指标配置应至少包含以下内容：

延迟：P50、P95、P99、P99.9（按模型版本和API端点拆分）。
吞吐量：QPS、推理样本数/秒、批处理大小分布。
错误率：HTTP 4xx/5xx比例、超时率、推理结果异常率（如NaN输出）。
资源：CPU利用率、内存使用量、GPU利用率、显存使用量、显存带宽、GPU温度。
漂移：PSI（每周计算）、预测置信度均值（每小时）、标签分布差异（每日）。
业务辅助：队列深度、端到端调用链追踪ID采样率。

告警阈值建议采用动态基线而非固定值。例如，P99延迟的告警阈值应基于过去7天同时间段的统计值，设置为基础线的1.5倍或绝对值增加200ms（取两者中较大值）。对于漂移指标，PSI超过0.25时触发黄色告警，超过0.3且持续2小时触发红色告警，并自动冻结当前模型版本，回滚至上一个稳定版本。

最后需要强调的是，监控指标本身不是目的，而是手段。每增加一个指标，都应明确其对应的决策动作：这个指标异常时，团队应该做什么？是扩容、回滚、降级还是通知业务方？只有将指标与行动预案绑定，监控体系才能真正发挥价值。