GPU 指标语义：利用率的真相与多租户归因
“GPU 利用率 97%”是一句没有信息量的话：在你补齐另外两个数字之前，它既可能是“忙而无效”，也可能是“带宽满载的健康态”。
阅读位置：上一章《可观测与计量：十个问题》 · 下一章《基准、验收与容量规划》。
可观测与计量一章给出了平台必须回答的十个问题；本章为其中最容易被误读的部分，即利用率与归因，提供字段级语义。它是故障模式手册的前置，也是微架构两个屋顶在监控层的直接应用。
GPU-Util 到底测的是什么
nvidia-smi 的“GPU-Util”（DCGM 字段 1001）的精确定义：
采样周期内，“至少有一个 kernel 在 GPU 上运行”的时间占比。
它不表示：用了多少 SM、跑了多少 FLOPS、带宽吃没吃满、活干得好不好。一个只来回搬运数据的循环也能让它显示 100%。它的正确用途只有一个：“这台卡有没有东西在跑”。
必须同看的三件套
| 字段 | 测的是什么 | 回答的问题 |
|---|---|---|
| 1001 GPU_UTIL | 有 kernel 驻留的时间占比 | 有没有东西在跑 |
| 1002 SM_ACTIVE | 平均多少比例的 SM 在工作 | 用了多少“机器” |
| 1005 DRAM_ACTIVE | 显存带宽利用率 | 带宽是不是瓶颈 |
三个数字放在一起才能读出负载状态。三个标准签名：
| 1001 | 1002 | 1005 | 诊断 |
|---|---|---|---|
| 高 | 低 | 高 | 解码型推理的正常态（带宽满、算力闲，见推理物理层），不要再加租户 |
| 高 | 高 | 低/中 | 训练/预填充（算力型），健康 |
| 高 | 低 | 低 | 小 kernel 风暴或纯搬运，即“忙但没干活” |
| 低 | 低 | 低 | 真空闲，或主机侧卡住（见 eBPF 一节） |
配套字段：1003（SM 占用率，kernel 配置健康度）、功耗/时钟/降频原因（共享场景的隐形干扰源，见微架构的功耗墙）。dcgm-exporter 默认只导出 1001 类指标。把 1002/1005 加进 gpu-metrics ConfigMap，是“把监控从假变真”的第一个动作。
采样看不见尾延迟
1 秒采样的 1001 是“这一秒有没有 kernel”，对 p99 的信息量为零：一个租户的解码步每秒被同卡邻居切断数次，在任何平均指标上都是不可见的。因此监控必须分层：
- 常驻（零成本）：三件套 + 功耗降频 + 引擎指标（TTFT/ITL、KV 水位、前缀命中率）；
- 触发式（低成本）：由告警自动抓取 10 秒级的追踪快照（nsys / torch profiler）。GPU 问题几乎无法事后复现，证据必须当场留；
- 事故级（高成本）：单 kernel 深度剖析。注意此类工具会重放 kernel、串行化设备，禁止对生产流量使用。
多租户归因的四条路径
“哪个 Pod 用了多少 GPU”没有原生答案，四条路径各有盲区：
| 路径 | 原理 | 盲区 |
|---|---|---|
nvidia-smi pmon | 驱动按进程采样 SM/显存 | 需自制 pid→Pod 映射；MPS 下全记在服务进程头上 |
| 软切分监控（如 HAMi monitor） | 采样 + 设备 cgroup 映射成 Pod | 采样平均，看不见尾延迟；口径是配额口径 |
| MIG 实例指标 | 按实例天然分离 | 只有切了 MIG 的节点有 |
| 引擎指标 | 推理引擎按请求记账（TTFT/TPOT/前缀命中） | 只覆盖引擎内流量 |
分层结论：计费看配额计数器，排障看追踪，SLO 看引擎指标，不要用采样平均的“利用率”回答“谁用了多少”。归因口径与配额口径的对账（软切分账本 vs 设备真值）应作为周期任务，偏差是配额体系失信任的第一信号（见HAMi）。
eBPF 边界观测：把 GPU 延迟连回主机原因
eBPF 看不到 GPU 内部，但能看到边界：CUDA 运行时/驱动 API 调用（uprobes）、设备节点上的 ioctl（内核探针）、以及主机侧事件（cgroup 限流、调度迁移、网络重传）。把三者按时间戳与进程关联，就能构建因果链：“推理延迟尖刺 ← kernel 发射停顿 ← launch 线程被 cgroup 限流 ← 嘈杂的 sidecar”。
这类工具（如开源的 Ingero 等）填补的是传统 GPU 工具的反向盲区：Nsight 回答“GPU 做了什么”，eBPF 回答“主机为什么让 GPU 这么做”。对共享节点上的排障（谁拖慢了谁）、分布式训练的 straggler 定位（哪个 rank 因主机原因变慢）价值最大，且开销低（边界采样而非设备内省），适合常驻。
告警的语义化
把告警从计数器移到语义，是可观测层最划算的改进。三个示例：
DRAM_ACTIVE > 85%持续 5 分钟（推理节点）→ 该节点带宽接近满，冻结新的解码型负载调度；- TTFT/ITL p99 连续越线 → 触发自动追踪快照 + 通知（而不是等工单）；
- XID 79 级错误 → 节点隔离 + 硬件工单（见故障模式）。
常见误区
| 误区 | 真相 |
|---|---|
| 利用率 30% 说明还有富余 | 30% 的什么？带宽 90% 时加租户就是事故 |
| 平均没问题就是没问题 | 尾延迟在平均里消失；采样窗口 ≥ 突发周期时全盲 |
| pmon 能看到每个容器 | 是每个进程，且 MPS 下失真 |
| 显存 100% 是泄漏 | 先分清框架缓存（reserved）与真实张量（allocated），见显存管理 |
| 深度剖析工具挂上去看看 | 会重放 kernel、串行化设备，生产禁止 |
总结
指标语义层的三个纪律：利用率必须三件套同读（否则既会误判健康也会误判故障）；SLO 与归因不依赖采样平均（追踪与引擎指标才是依据）；告警挂在语义上（带宽满载、SLO 越线、账实偏差），而不是挂在百分比上。它们与基准与验收共同构成“从能跑到可交付”的观测闭环。