8.1 AI 系统可观测性：Prometheus 与 GPU 指标
文档摘要
8.1 AI 系统可观测性：Prometheus 与 GPU 指标 一个推理服务上线后，第一个问题是「它正常吗」——GPU 在算吗、延迟多少、有没有请求堆积、模型效果有没有掉？可观测性是回答这些问题的眼睛。AI 系统的可观测性比传统 Web 服务复杂，因为它要同时盯系统指标、模型指标、业务指标三层。 8.1.1 可观测性的三大支柱 可观测性（Observability）的经典定义是「通过外部输出推断系统内部状态的能力」。它的三大支柱： Metrics（指标）：数值化的时序数据，如 CPU 利用率、请求数、延迟。 Logs（日志）：离散的事件记录，如错误日志、请求日志。 Traces（追踪）：请求在分布式系统中的完整路径。
8.1 AI 系统可观测性：Prometheus 与 GPU 指标
一个推理服务上线后，第一个问题是「它正常吗」——GPU 在算吗、延迟多少、有没有请求堆积、模型效果有没有掉？可观测性是回答这些问题的眼睛。AI 系统的可观测性比传统 Web 服务复杂，因为它要同时盯系统指标、模型指标、业务指标三层。
8.1.1 可观测性的三大支柱
可观测性（Observability）的经典定义是「通过外部输出推断系统内部状态的能力」。它的三大支柱：
- Metrics（指标）：数值化的时序数据，如 CPU 利用率、请求数、延迟。
- Logs（日志）：离散的事件记录，如错误日志、请求日志。
- Traces（追踪）：请求在分布式系统中的完整路径。
AI 系统的可观测性同样基于这三大支柱，但每个支柱都有 AI 特有的内容：
| 支柱 | 传统 Web 服务 | AI 系统 |
|---|---|---|
| Metrics | CPU/内存/QPS/延迟 | + GPU 利用率/显存/TTFT/TPOT/模型质量 |
| Logs | 访问日志、错误日志 | + 训练日志、推理日志、Prompt 日志 |
| Traces | 请求链路 | + Pipeline 步骤、模型推理子步骤 |
本节聚焦 Metrics（指标），因为它是 AI 系统可观测性的核心，也是扩缩容（8.2 节）与稳定性（8.3 节）的基础。
8.1.2 Prometheus + Grafana：事实标准
Prometheus 是 CNCF 的指标采集与存储系统，是云原生可观测性的事实标准。它的核心模型：
- Pull 模型：Prometheus 主动从目标（target）的
/metrics端点拉取指标。 - 时序数据库：拉到的指标按时间序列存储。
- PromQL：查询语言，支持聚合、计算、过滤。
- Alertmanager：告警组件，基于规则触发告警。
Grafana 是数据可视化平台，与 Prometheus 深度集成，把指标渲染成仪表盘（dashboard）。
AI 系统的典型监控栈：
8.1.3 DCGM Exporter：GPU 指标采集
AI 系统与传统服务最大的差别是「GPU」。DCGM Exporter（Data Center GPU Manager Exporter） 是 NVIDIA 提供的 Prometheus exporter，专门采集 GPU 指标。
DCGM Exporter 提供的关键 GPU 指标：
| 指标 | 含义 | 用途 |
|---|---|---|
DCGM_FI_DEV_GPU_UTIL |
GPU 计算利用率（%） | 衡量算力使用 |
DCGM_FI_DEV_MEM_COPY_UTIL |
显存带宽利用率（%） | 衡量带宽使用 |
DCGM_FI_DEV_FB_USED |
已用显存（MB） | 监控显存压力 |
DCGM_FI_DEV_FB_FREE |
空闲显存（MB） | 调度决策 |
DCGM_FI_DEV_GPU_TEMP |
GPU 温度 | 硬件健康 |
DCGM_FI_DEV_POWER_USAGE |
功耗（W） | 能效与成本 |
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE |
Tensor Core 利用率 | 算力是否真正用于矩阵乘 |
💡 判读：GPU 利用率是最常被误读的指标——「GPU_UTIL 100%」只表示「GPU 在执行某个 kernel」，并不意味着「算力被充分利用」。真正反映算力使用的是「Tensor Core 利用率」（DCGM_FI_PROF_PIPE_TENSOR_ACTIVE）。许多推理服务 GPU_UTIL 高但 Tensor Core 利用率低，意味着 GPU 在等内存而非算数学——这是典型的 Decode 阶段瓶颈（回顾第 6 章 6.2 节）。
8.1.4 AI 系统的三层指标体系
AI 系统的指标要按「系统 → 模型 → 业务」三层组织，每层关注不同问题：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 380" font-family="sans-serif" font-size="12"> <text x="360" y="22" text-anchor="middle" font-size="15" font-weight="bold">AI 系统三层指标体系</text> <!-- 系统层 --> <rect x="40" y="50" width="640" height="90" rx="8" fill="#dbeafe" stroke="#2563eb"/> <text x="60" y="75" font-weight="bold" fill="#1e40af">系统层（Infrastructure）</text> <text x="60" y="95" font-size="11">问题：硬件资源够不够、健康不健康</text> <text x="60" y="115" font-size="11">指标：CPU、内存、GPU 利用率、显存、温度、功耗、网络 IO、磁盘 IO</text> <text x="60" y="132" font-size="11" fill="#64748b">采集：Node Exporter、DCGM Exporter、cAdvisor</text> <!-- 模型层 --> <rect x="40" y="155" width="640" height="90" rx="8" fill="#fce7f3" stroke="#db2777"/> <text x="60" y="180" font-weight="bold" fill="#9d174d">模型层（Model Performance）</text> <text x="60" y="200" font-size="11">问题：模型推理快不快、吞吐够不够</text> <text x="60" y="220" font-size="11">指标：TTFT、TPOT、吞吐（tokens/s）、batch 大小、队列深度、缓存命中率</text> <text x="60" y="237" font-size="11" fill="#64748b">采集：vLLM/TGI Metrics、自定义 exporter</text> <!-- 业务层 --> <rect x="40" y="260" width="640" height="90" rx="8" fill="#dcfce7" stroke="#16a34a"/> <text x="60" y="285" font-weight="bold" fill="#15803d">业务层（Business Quality）</text> <text x="60" y="305" font-size="11">问题：用户满意不满意、模型效果好不好</text> <text x="60" y="325" font-size="11">指标：用户满意度、点击率、转化率、模型精度、数据漂移、安全违规率</text> <text x="60" y="342" font-size="11" fill="#64748b">采集：业务埋点、A/B 实验、漂移检测工具（Evidently、WhyLabs）</text> </svg>
RED 与 USE 方法论
两个经典的可观测性方法论：
- RED（Rate, Errors, Duration）：面向服务，关注「请求速率、错误率、延迟」。
- USE（Utilization, Saturation, Errors）：面向资源，关注「利用率、饱和度、错误」。
AI 系统两者都用——推理服务用 RED（请求视角），GPU/网络用 USE（资源视角）。
8.1.5 LLM 推理的专属指标
LLM 推理比传统 ML 多了一组专属指标，反映其自回归生成的特性：
| 指标 | 含义 | SLO 参考 |
|---|---|---|
| TTFT（Time To First Token） | 首 token 延迟 | < 500ms（聊天）、< 2s（批量） |
| TPOT（Time Per Output Token） | 每输出 token 延迟 | < 50ms（流畅） |
| 总延迟 | 完整响应时间 | 取决于生成长度 |
| 吞吐（tokens/s） | 单卡每秒生成 token 数 | 模型与硬件相关 |
| 队列深度 | 等待处理的请求数 | < 阈值（防超时） |
| KV Cache 利用率 | KV Cache 占用比例 | < 90%（防 OOM） |
| Prefix Cache 命中率 | 前缀缓存命中比例 | 越高越好（RAG 场景） |
| GPU 利用率 | 算力利用率 | 70%-90%（健康） |
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 280" font-family="sans-serif" font-size="12"> <text x="360" y="22" text-anchor="middle" font-size="15" font-weight="bold">LLM 推理请求的时序与关键指标</text> <!-- 时间轴 --> <line x1="40" y1="200" x2="680" y2="200" stroke="#475569" stroke-width="1.5"/> <!-- 请求到达 --> <circle cx="60" cy="200" r="6" fill="#2563eb"/> <text x="60" y="225" text-anchor="middle" font-size="10">请求到达</text> <!-- 排队 --> <line x1="60" y1="200" x2="180" y2="200" stroke="#f59e0b" stroke-width="3"/> <text x="120" y="190" text-anchor="middle" font-size="10" fill="#f59e0b">排队时间</text> <!-- Prefill --> <line x1="180" y1="200" x2="280" y2="200" stroke="#dc2626" stroke-width="4"/> <text x="230" y="190" text-anchor="middle" font-size="10" fill="#dc2626">Prefill</text> <!-- 首 token --> <circle cx="280" cy="200" r="6" fill="#16a34a"/> <text x="280" y="225" text-anchor="middle" font-size="10">首 token</text> <!-- TTFT 标注 --> <line x1="60" y1="160" x2="280" y2="160" stroke="#16a34a" stroke-width="2" stroke-dasharray="3,2"/> <text x="170" y="150" text-anchor="middle" font-size="11" font-weight="bold" fill="#16a34a">TTFT</text> <!-- Decode --> <line x1="280" y1="200" x2="620" y2="200" stroke="#9333ea" stroke-width="4"/> <text x="450" y="190" text-anchor="middle" font-size="10" fill="#9333ea">Decode（每步 TPOT）</text> <!-- 完成 --> <circle cx="620" cy="200" r="6" fill="#475569"/> <text x="620" y="225" text-anchor="middle" font-size="10">完成</text> <!-- 总延迟 --> <line x1="60" y1="260" x2="620" y2="260" stroke="#475569" stroke-width="2"/> <text x="340" y="275" text-anchor="middle" font-size="11" fill="#475569">总延迟 = 排队 + Prefill + N × TPOT</text> </svg>
💡 判读：TTFT 与 TPOT 是 LLM 服务的「用户体感」指标。TTFT 决定「多久开始回话」，TPOT 决定「回复流得多快」。聊天场景对二者都敏感；批量场景对吞吐敏感。监控要把它们作为 SLO 的核心。
8.1.6 模型质量与漂移监控
模型上线后，模型质量监控 是 MLOps 区别于 DevOps 的关键（回顾第 4 章 4.1 节）：
- 数据漂移（Data Drift）：输入数据的分布发生变化（如用户群体变化、季节变化）。
- 概念漂移（Concept Drift）：输入与输出的关系发生变化（如市场规律变了）。
- 预测漂移（Prediction Drift）：模型预测的分布发生变化（漂移的间接信号）。
漂移检测的常见方法：
- 统计距离：用 KL 散度、PSI（Population Stability Index）等度量分布变化。
- 置信度监控：模型置信度均值/方差变化。
- 基线对比：与基线数据集的统计量对比。
漂移检测工具：
- Evidently：开源，支持多种漂移检测。
- WhyLabs：商业，专业 AI 可观测性。
- Arize、Fiddler：商业，企业级模型监控。
⚠️ LLM 漂移的特殊性：LLM 的「漂移」更难监控——输出是开放式文本，没有明确的「分布」可言。常见做法是监控：Prompt 分布变化、输出长度分布、安全违规率、用户反馈率（点踩率）。LLM 的漂移监控仍是开放问题。
8.1.7 告警分级与 SLO
监控的目的是「发现问题并告警」。一个健康的告警体系要分级：
| 级别 | 触发条件 | 响应 | 通知方式 |
|---|---|---|---|
| P0（紧急） | 服务完全不可用、数据丢失 | 立即响应、全员 oncall | 电话 + 短信 |
| P1（严重） | SLO 严重违反、关键指标劣化 | 30 分钟内响应 | 即时通讯 |
| P2（警告） | 指标接近阈值、容量预警 | 工作日内响应 | 邮件 + 日报 |
| P3（提示） | 信息性指标、趋势变化 | 周期性回顾 | 仪表盘 |
告警设计的核心原则是「少而准」——告警泛滥（alert fatigue）会让团队麻木，错过真正重要的告警。建议：
- 只对「需要人工干预」的情况告警，自动恢复的不告。
- 设定合理的阈值（基于历史数据，避免误报）。
- 告警要包含「问题、影响、建议」三要素，便于快速处置。
SLO（Service Level Objective）
SLO（服务等级目标） 是可观测性与稳定性的「契约」。LLM 推理服务的典型 SLO：
| 指标 | SLO 目标 |
|---|---|
| 可用性 | 99.9%（每月停机 < 43 分钟） |
| TTFT P99 | < 1 秒 |
| TPOT P99 | < 100 毫秒 |
| 错误率 | < 0.1% |
| 队列等待 P99 | < 5 秒 |
SLO 一旦设定，就要配套 错误预算（Error Budget）——如 99.9% 可用性对应每月 43 分钟的「允许停机」。错误预算耗尽前可以激进迭代，耗尽后必须停止新功能、专注稳定性。这是 SRE 的核心实践。
8.1.8 Grafana 仪表盘设计
Grafana 仪表盘是可观测性的「门面」。一个优秀的 AI 仪表盘应包含：
- 顶部概览：关键 SLO（可用性、TTFT、TPOT、QPS）。
- 系统层：GPU 利用率、显存、网络、存储。
- 模型层：吞吐、batch 大小、队列深度、缓存命中率。
- 业务层：错误率、用户满意度、漂移指标。
- 历史趋势：与上周/上月对比，识别长期变化。
- 告警状态：当前活跃告警列表。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 360" font-family="sans-serif" font-size="12"> <text x="360" y="22" text-anchor="middle" font-size="15" font-weight="bold">LLM 推理服务仪表盘布局</text> <!-- 顶部 SLO --> <rect x="20" y="40" width="680" height="60" rx="6" fill="#dcfce7" stroke="#16a34a"/> <text x="40" y="65" font-weight="bold">SLO 概览：</text> <text x="40" y="85" font-size="11">可用性 99.95% | TTFT P99 0.8s | TPOT P99 45ms | QPS 1.2k | 错误率 0.05%</text> <!-- 左：系统层 --> <rect x="20" y="115" width="335" height="100" rx="6" fill="#dbeafe" stroke="#2563eb"/> <text x="40" y="140" font-weight="bold">系统层</text> <text x="40" y="160" font-size="11">GPU 利用率：78%</text> <text x="40" y="178" font-size="11">显存使用：65/80 GB</text> <text x="40" y="196" font-size="11">网络 IO、温度、功耗</text> <!-- 右：模型层 --> <rect x="365" y="115" width="335" height="100" rx="6" fill="#fce7f3" stroke="#db2777"/> <text x="385" y="140" font-weight="bold">模型层</text> <text x="385" y="160" font-size="11">吞吐：4500 tokens/s</text> <text x="385" y="178" font-size="11">队列：12 请求</text> <text x="385" y="196" font-size="11">缓存命中率：85%</text> <!-- 底：业务层 --> <rect x="20" y="230" width="680" height="100" rx="6" fill="#fef9c3" stroke="#ca8a04"/> <text x="40" y="255" font-weight="bold">业务层</text> <text x="40" y="275" font-size="11">用户满意度：4.6/5</text> <text x="40" y="293" font-size="11">漂移指标：PSI 0.08（正常）</text> <text x="40" y="311" font-size="11">安全违规：0.02%</text> </svg>
💡 判读：仪表盘设计的核心是「层次清晰、一目了然」——顶部 SLO 回答「服务正常吗」，中间各层回答「哪里出问题」，底部业务回答「用户感受如何」。一个糟糕的仪表盘有几百个面板但找不到关键信息；一个优秀的仪表盘一屏就能看清整体状态。
8.1.9 可观测性的工程实践
落地可观测性的几个工程实践：
- 指标先行：上线前先定义好关键指标与 SLO，再开发业务。
- 红色仪表盘：异常指标用红色突出，正常用绿色，让仪表盘「会说话」。
- 告警去噪：定期 review 告警，删除长期不触发的、合并相似的。
- 关键路径追踪：推理请求的完整链路（网关→推理引擎→模型）要有 trace。
- 业务方仪表盘：给业务方单独的仪表盘（他们不关心 GPU 利用率，只关心业务指标）。
- 历史对比：所有指标都支持「与上周/上月对比」，识别长期趋势。
- 混沌测试：定期模拟故障，验证监控能及时发现。
本节小结
- 可观测性三大支柱：Metrics（指标）、Logs（日志）、Traces（追踪），AI 系统每层都有 AI 特有内容。
- Prometheus + Grafana 是云原生可观测性事实标准，Pull 模型 + 时序数据库 + PromQL + Alertmanager。
- DCGM Exporter 采集 GPU 指标：GPU_UTIL（粗）、Tensor Core 利用率（细，反映真实算力使用）。
- AI 系统三层指标：系统层（CPU/GPU/网络）、模型层（TTFT/TPOT/吞吐/队列）、业务层（满意度/漂移/安全）。
- RED 方法（服务视角：速率/错误/延迟）与 USE 方法（资源视角：利用率/饱和度/错误）。
- LLM 专属指标：TTFT（首 token 延迟）、TPOT（每 token 延迟）、KV Cache 利用率、Prefix Cache 命中率。
- 模型质量监控：数据漂移、概念漂移、预测漂移；工具 Evidently/WhyLabs/Arize；LLM 漂移监控是开放问题。
- 告警分级 P0-P3，原则「少而准」，避免 alert fatigue。
- SLO + 错误预算是稳定性契约，99.9% 对应每月 43 分钟停机。
- 仪表盘设计：层次清晰（顶部 SLO、中间各层、底部业务），一屏看清整体状态。
下一节《8.2 自动扩缩容：HPA、VPA 与 KEDA》将讲清如何基于这些指标自动扩缩推理服务。