GPU 利用率 100%，
计算单元就都忙了吗？

图里把三个指标放进同一个窗口，只是为了方便比较。真实的 GPU_UTIL 来自驱动自己的采样窗口，profiling 字段各有一段采集区间，和 Prometheus 抓取的那一刻未必对得上。这里的公式也做了简化：时钟固定，每个 SM 一样忙。所以别拿线上的 GPU_UTIL 反推 SM_ACTIVE。另外，profiling 的比率原值通常是 0–1，图里乘了 100；GPU_UTIL 本身就是 0–100。

PIPE_TENSOR_ACTIVE、PIPE_FP16_ACTIVE、PIPE_FP32_ACTIVE 和 PIPE_FP64_ACTIVE 反映的是对应管线有多活跃，归一化用的是硬件定义的周期口径，所以 100% 在不同架构、不同管线上未必是同一件事。Tensor Core 能跑低精度矩阵运算，但 FP16 管线指标不含 HMMA 矩阵指令。这几个数不能直接相加，更不能拿它乘上标称 TFLOPS，当成实际吞吐。真要算有效 FLOP/s，还得知道运算次数、精度、指令类型和耗时。

真实 SM 能驻留多少 warp，要看 GPU 架构。实际 occupancy 还会被 block 大小、寄存器和共享内存卡住。图里的八个槽位只是拿来显示比例；occupancy 高，不代表跑得更快。

MEM_COPY_UTIL 是驱动采样窗口里，显存被读或被写的时间占比。它既不是显存用量百分比，也不专指主机和 GPU 之间的复制。DRAM_ACTIVE 则是 profiling 给出的显存接口周期活动比例。两者来源和归一化方式都不一样，读数对不上很正常。

实测带宽就是传输字节数除以时间。带宽利用率，就是拿实测带宽除以同方向、同单位、同口径的参考带宽。别用 DRAM_ACTIVE 去乘显存标称带宽，那算不出真实带宽。另外，这里按 1 GiB = 1024 MiB 换算，exporter 输出的 FB_USED 单位是 MiB。算容量占比时先把单位统一，再想清楚分母用 FB_TOTAL，还是扣掉驱动保留空间后的可用容量。

PCIe 的 profiling 速率把协议头和数据一起算进去。NVLink 的 profiling 指南描述的是不含协议头的速率，API 字段页的措辞又略有出入，用之前最好对着自己的部署版本和后端核一遍。图里没有把这两个数当成同口径的有效载荷吞吐来比。

TX 和 RX 各有各的方向上限；多链路加起来的总速率，要和同样链路数的总带宽比。两张 GPU 通信也不一定走 NVLink，也可能绕道 PCIe。较新的 *_BYTES_TOTAL 字段只有在 exporter 里按 counter 导出时才该用 rate()，这些原始累积字段本图不展开。

DCGM 先采集、缓存字段，exporter 再输出，Prometheus 再按自己的间隔来抓。这三层的时间间隔并不一样。计数器复用可能留下采样空隙或零值，profiling 暂停时会返回 BLANK。字段不支持、没权限、没采到样本，再加上真的等于零，这四种情况得分开处理，别一律补零。异常大的特殊值同样不能当有效读数。

MIG（多实例 GPU）会把一张物理 GPU 切成多个实例。哪些字段支持、归一化范围多大，都要看具体的实体和设备。聚合之前先核对 UUID、GPU/实例标签和时间戳；别把整卡序列和实例序列加在一起，也别把整卡读数复制给每个共用这张 GPU 的 Pod，当成它们的独占用量。

dcgmi profile -l -i 0

在目标 GPU 上跑一下这条命令，看看哪些指标组能同时采集，再对一遍 exporter 的 counters 配置。文档里写着某个字段，不代表你手上的 GPU 和配置就一定会导出它。