可观测性¶
AI Infra 的可观测目标是：从一次请求或训练 step 的异常，快速下钻到模型进程、collective、Pod、节点、GPU、网络或存储，并用相同时间线关联证据。
信号分工¶
OpenTelemetry 将 telemetry 信号分为 traces、metrics、logs、baggage 等。实战中：
| 信号 | 最擅长回答 | AI Infra 示例 |
|---|---|---|
| Metrics | 系统总体发生了什么、趋势如何 | TTFT P99、queue depth、SM active、step time |
| Traces | 单次请求经过了哪些阶段 | gateway → scheduler → prefill → decode |
| Logs | 具体事件和上下文是什么 | OOM、NCCL timeout、模型加载失败 |
| Profiles | 哪段代码/内核消耗资源 | CPU 火焰图、CUDA kernel timeline |
关键是统一 resource attributes：service、cluster、namespace、pod、node、model、revision、GPU UUID 等，避免同一对象在不同系统里叫不同名字。
分层指标¶
用户与业务层¶
- 请求率、错误率、E2E latency、TTFT、TPOT、goodput。
- input/output tokens、取消、超时、拒绝、质量/安全降级。
调度与模型层¶
- waiting/running requests 或 sequences。
- batched tokens、KV Cache 使用与抢占、prefix cache 命中。
- 模型加载时间、warmup、revision、实例健康。
- 训练 loss、learning rate、tokens/s、step time、checkpoint 时长。
GPU 与节点层¶
- SM/Tensor/DRAM 活跃、显存占用、功耗、温度、时钟。
- PCIe/NVLink 吞吐与错误、ECC、Xid、健康状态。
- CPU、内存、NUMA、磁盘/文件系统、NIC throughput/drop/retransmit。
NVIDIA DCGM 面向数据中心 GPU 提供持续 telemetry、健康诊断、配置、拓扑和作业统计，是 GPU 集群监控的常见数据源。
Metric 类型¶
Prometheus 客户端的四种核心类型：
- Counter：只增不减（除重启归零），如请求总数、错误总数；通常用
rate()看速率。 - Gauge：可增可减，如当前队列深度、显存占用。
- Histogram：把观测值放入 bucket，可跨实例聚合并计算分位数，常用于时延与 token 数。
- Summary：客户端计算滑动窗口 quantile，跨实例聚合困难，使用前明确边界。
控制 cardinality
不要把 request ID、user ID、原始 URL、prompt 或任意模型输入作为 metric label。高基数会让时间序列数量和内存成本失控；这些细节放到采样 trace 或受控日志。
SLI 与 SLO 示例¶
可用性不应只定义为 HTTP 200。LLM 服务可以定义：
在输入 ≤ 2k token、输出 ≤ 512 token 的标准交互流量中，99% 已接纳请求 TTFT < 2s，且 TPOT P95 < 80ms；5 分钟窗口内服务端错误率 < 0.5%。
把工作负载边界写进 SLO，否则用户可用超长 prompt 改变指标语义。goodput 可定义为同时满足延迟与正确性条件的请求/单位时间。
告警原则¶
- 症状告警优先：SLO burn rate、错误、延迟、goodput。
- 原因告警辅助：GPU Xid、存储错误、NCCL timeout、队列积压。
- 避免仅凭高 GPU utilization 报警；高利用率可能是健康高效状态。
- 告警包含 runbook、dashboard、版本和 owner，确保可执行。
- 多窗口 burn-rate 比单阈值更适合控制误报和漏报。
仪表盘布局¶
- Overview：SLO、流量、错误、TTFT/TPOT、goodput、成本。
- Queue & Scheduler：队列、batch、token、KV Cache、reject。
- Model Workers：revision、实例、加载、吞吐、显存。
- GPU/Node：DCGM、CPU、内存、网络、存储、故障事件。
- Drill-down：trace、profile、相关日志与部署事件。
仪表盘要标注模型发布、配置变更、扩缩和节点维护事件，帮助区分相关性。