GPU 监控体系与性能分析——从 nvidia-smi 到 DCGM

一、为什么需要 GPU 监控在前面的学习中我们了解了 GPU 的三个核心性能指标显存容量Memory Capacity决定模型和数据能否装入 GPU。显存带宽Memory Bandwidth决定数据在显存与计算单元之间搬运的速度。计算能力Compute Performance决定 GPU 执行计算任务的速度。同时多 GPU 训练还涉及 GPU 之间的通信带宽例如 NVLink、PCIe 等互联技术。但这些指标更多描述的是 GPU 的理论能力。实际运行任务时我们还需要回答几个问题GPU 是否正在执行计算任务GPU 当前运行的是计算任务还是通信任务GPU 的计算资源是否得到了充分利用GPU 性能为什么没有达到预期多 GPU 训练中是否存在某些 GPU 长时间等待其他 GPU 的情况这些问题都需要通过 GPU 监控来解决。GPU 监控不仅是查看利用率和显存占用更重要的是通过多个维度的指标分析 GPU 的实际运行状态发现性能瓶颈。核心思想GPU 利用率高不一定代表计算效率高GPU 显存占用高也不一定代表 GPU 正在进行计算。二、GPU 监控的三大工具在 NVIDIA GPU 监控体系中常用的工具主要有三类工具核心作用适用场景nvidia-smi查看 GPU 实时状态临时检查、故障定位nvitop持续监控 GPU 和进程开发调试、多人共享 GPUDCGM Prometheus Grafana集群级监控与历史数据分析生产环境、AI 数据中心1. nvidia-smiGPU 基础监控工具nvidia-smi 是 NVIDIA 驱动提供的命令行管理工具可以查看 GPU 的基本运行状态。执行命令nvidia-smi它可以显示GPU 型号及编号GPU 温度GPU 功耗显存使用情况GPU 利用率GPU 性能状态GPU 上运行的进程常用命令# 查看 GPU 当前状态 nvidia-smi # 每秒刷新一次 nvidia-smi -l 1 # 查看 GPU 进程 nvidia-smi --query-compute-appspid,process_name,used_memory --formatcsv # 查看 GPU 关键指标 nvidia-smi --query-gpuname,temperature.gpu,utilization.gpu,memory.used,memory.total,power.draw,power.limit --formatcsv # 查看 GPU 拓扑关系 nvidia-smi topo -m其中nvidia-smi topo -m对多 GPU 服务器尤其重要可以查看 GPU 之间通过 NVLink、PCIe 等方式建立的拓扑关系。nvidia-smi 重点指标解析指标含义作用GPU NameGPU 型号判断硬件规格TempGPU 温度判断散热状态PerfGPU 性能状态判断当前性能运行状态Pwr/Cap当前功耗/功耗上限判断能耗和负载情况Memory-Usage显存使用量判断显存资源占用GPU-UtilGPU 利用率判断 GPU 是否有任务执行ECC错误校验信息监控显存及硬件错误Compute M.计算模式查看 GPU 进程共享模式几个容易混淆的指标1Perf性能状态NVIDIA GPU 使用 P-State 表示性能状态。P0最高性能状态。P1、P2 等其他性能状态。P8通常对应低负载或空闲状态。需要注意P-State 并不直接代表 GPU 的实际利用率也不能仅凭 P-State 判断是否发生了降频。2Pwr功耗例如Pwr: 287W / 350W表示 GPU 当前功耗为 287W功耗上限为 350W。功耗可以辅助判断 GPU 是否处于高负载状态但不同 GPU、不同工作负载的功耗特征存在差异不能简单认为功耗越高计算效率就越高。3Memory-Usage显存使用量例如27963MiB / 46068MiB表示当前显存使用约为 27.3 GiB总显存约为 45 GiB。需要注意PyTorch 使用缓存分配器管理显存。显存被 PyTorch 申请后不一定会立即归还给 CUDA 驱动。因此nvidia-smi 显示的显存占用不完全等于模型当前实际使用的张量显存。可以使用 PyTorch 接口进一步查看import torch # 当前活跃张量实际占用的显存 print(torch.cuda.memory_allocated() / 1024**3) # PyTorch 缓存分配器管理的显存 print(torch.cuda.memory_reserved() / 1024**3) # 当前 GPU 可用显存 print(torch.cuda.mem_get_info())2. nvitop持续监控 GPU 运行状态nvitop 是基于 Python 开发的 GPU 监控工具界面类似 Linux 中的 htop。安装pip install nvitop启动nvitop相比 nvidia-sminvitop 更适合持续观察 GPU 运行状态。主要功能实时刷新 GPU 利用率、温度、功耗和显存占用。查看每张 GPU 对应的进程。查看进程占用的显存和相关计算指标。展示 GPU 指标的历史变化趋势。辅助定位 GPU 资源被哪个进程占用。在多人共享 GPU 服务器的环境中nvitop 特别有用。例如一台服务器有 8 张 GPU多个用户同时运行训练任务可以通过进程信息快速定位哪个进程占用了 GPU 0哪个进程占用了大量显存哪张 GPU 利用率异常偏低是否存在进程占用显存但没有持续计算的情况3. DCGM企业级 GPU 监控体系DCGM 全称 Data Center GPU Manager是 NVIDIA 提供的数据中心 GPU 管理和监控组件。在生产环境中单纯依靠 nvidia-smi 和 nvitop 很难满足集群级监控需求。例如如何保存过去 30 天的 GPU 利用率如何查看整个 GPU 集群的平均功耗如何发现某张 GPU 长时间异常如何在 GPU 故障或训练任务异常时自动告警这时就需要 DCGM 监控体系。典型架构NVIDIA GPU | v DCGM / DCGM Exporter | v Prometheus | v Grafana | 监控大盘与告警各组件的作用组件主要职责DCGMNVIDIA GPU 管理、监控指标采集DCGM Exporter将 GPU 指标暴露为 Prometheus 可采集的格式Prometheus定期采集、存储时序监控数据Grafana数据可视化、监控大盘和告警展示在 Kubernetes 环境中DCGM Exporter 通常可以通过 DaemonSet 部署。DaemonSet 能够保证符合条件的 GPU 工作节点运行对应的监控 Pod从而实现集群范围内的 GPU 指标采集。三种工具的定位nvidia-smi解决单机实时查看问题。nvitop解决实时监控和进程定位问题。DCGM 监控体系解决长期监控、集群管理和告警问题。三、GPU 利用率最容易被误解的指标GPU 利用率GPU-Util是 GPU 监控中最常见的指标但也是最容易被误解的指标。1. GPU-Util 的定义GPU-Util 表示在一个采样周期内GPU 至少有一个 Kernel 正在执行的时间占比。可以表示为其中()采样周期内至少有一个 GPU Kernel 执行的时间。()GPU 监控的采样周期。Kernel 是运行在 GPU 上的一段计算程序也称为核函数。例如假设采样周期为 1 秒其中 GPU 有 Kernel 执行的时间为 0.9 秒那么这表示 GPU 在 90% 的采样时间内有 Kernel 执行。但是这并不意味着 GPU 的计算单元使用率达到了 90%。2. 为什么 GPU 利用率高不代表算力跑满GPU 内部有大量 SMStreaming Multiprocessor流式多处理器。SM 是 GPU 的核心计算单元负责执行线程束Warp等计算任务。一个 Warp 通常由 32 个线程组成是 NVIDIA GPU 的基本调度单位。GPU-Util 只关心有没有 Kernel 执行并不关心有多少个 SM 正在工作SM 是否被充分利用Tensor Core 是否参与计算GPU 是否正在等待数据当前 Kernel 的计算规模有多大因此可能出现GPU-Util98% SM 活跃程度较低 功耗较低这意味着 GPU 上一直存在 Kernel 执行但实际计算资源没有得到充分利用。这种情况可以理解为 GPU 的一种低效运行状态也就是常说的「假忙」。四、GPU-Util 和 SM 利用率有什么区别理解这两个指标是分析 GPU 性能的重要基础。指标主要含义关注点GPU-Util采样周期内存在 Kernel 执行的时间比例GPU 是否有任务执行SM ActiveSM 活跃程度SM 是否参与执行工作SM Occupancy活跃 Warp 数量与最大可驻留 Warp 数量的比例SM 的线程资源占用情况Tensor Core ActiveTensor Core 活跃程度矩阵计算单元是否参与工作注意SM Active 和 SM Occupancy 不是同一个概念不能混用。在 nvitop 中还可能看到进程级 SM% 指标。它与 GPU 卡级利用率并不是完全相同的统计口径。具体含义需要结合工具版本、字段定义和底层采集接口判断。例如GPU 3 GPU-Util85% 进程 SM%67%这说明卡级 GPU-Util 与进程级 SM 指标存在差异可能意味着 Kernel 执行时间较长但计算资源并没有被充分利用。不过不能直接将两者相减作为严格的「算力浪费比例」因为它们的采样窗口和统计口径可能不同。五、三个核心指标利用率、功耗、显存判断 GPU 是否真正发挥性能不能只看一个数字。需要综合观察GPU 利用率GPU-UtilGPU 功耗Power UsageGPU 显存占用Memory Usage1. 三个指标分别代表什么指标反映的问题GPU-UtilGPU 是否持续有 Kernel 执行Power UsageGPU 当前能耗水平Memory UsageGPU 显存资源占用情况其中利用率高不代表计算效率高。功耗高不代表计算效率一定高。显存占用高不代表 GPU 正在执行计算。三个指标需要结合工作负载、GPU 型号和运行阶段进行判断。2. 典型运行状态分析GPU-Util功耗显存可能的运行状态高高高可能处于正常训练负载高低高可能存在轻量 Kernel、等待或低效计算低低高模型已加载但当前计算较少低低低GPU 可能处于空闲状态低高高可能存在其他负载、显存访问或特殊计算阶段需要强调这些只是初步判断模式并不是绝对的故障结论。例如GPU 进行访存密集型计算时功耗可能低于矩阵乘法密集型任务但依然可能具有较高的计算效率。3. 如何识别 GPU 假忙假设某张 GPU 显示GPU-Util98% Power250W Memory70GB虽然 GPU 利用率接近 100%但是功耗相对较低。这时需要进一步分析Kernel 是否过于轻量是否存在大量小算子CPU 是否无法及时提供数据GPU 是否在等待其他 GPU 完成通信Tensor Core 是否得到充分利用不能直接判断 GPU 性能异常而应该进一步检查计算单元活跃度和任务执行情况。六、多 GPU 训练中的性能瓶颈在 AI 集群中多 GPU 训练经常采用数据并行DP、张量并行TP和流水线并行PP等方式。多个 GPU 不仅要执行计算还需要进行数据交换和通信。其中一个典型操作就是 AllReduce。1. 什么是 AllReduce在数据并行训练中不同 GPU 会分别处理不同的数据并计算各自的梯度。为了保持模型参数一致需要将各 GPU 的梯度进行汇总再将结果同步给所有 GPU。这个过程通常使用 AllReduce 实现。简化过程GPU 0计算梯度 GPU 1计算梯度 GPU 2计算梯度 GPU 3计算梯度 | v AllReduce | v 梯度汇总与同步 | v 所有 GPU 获得同步后的梯度AllReduce 可以通过 NCCL 等通信库实现。在多 GPU 训练中通信效率会直接影响整体训练速度。2. 为什么通信会影响 GPU 利用率假设 4 张 GPU 同时训练GPU 0 完成计算较快。GPU 1 完成计算较慢。GPU 2 和 GPU 3 需要等待同步。所有 GPU 最终需要完成梯度通信。这时部分 GPU 可能出现计算等待。如果通信效率不高就可能导致GPU 利用率下降。SM 活跃程度下降。GPU 功耗下降。单次训练迭代时间增加。因此多 GPU 训练不能只关注单张 GPU 的计算能力还要关注 GPU 之间的通信效率。这也是 AI 数据中心网络需要重点解决的问题。七、GPU 利用率低一定是异常吗答案是不一定需要区分训练和推理两种场景。1. 训练场景训练任务通常需要持续执行大量计算。如果训练期间 GPU 利用率长期偏低可能存在CPU 数据预处理速度不足。DataLoader 数据加载速度较慢。CPU 与 GPU 之间的数据传输瓶颈。GPU 间通信效率不足。Batch Size 太小。算子执行效率低。GPU 资源分配不合理。这时需要结合训练迭代时间、数据加载时间、通信时间和 GPU 计算指标进行分析。2. 推理场景推理服务与训练任务不同。推理服务通常根据用户请求动态执行计算。当没有请求时GPU 处于空闲状态是正常现象。因此推理场景除了 GPU 利用率还应该重点关注指标作用QPS每秒处理请求数量TTFT首 Token 响应时间TPOT每个输出 Token 的平均生成时间Latency请求整体响应延迟KV Cache推理过程中的键值缓存占用GPU MemoryGPU 显存占用情况例如如果 GPU 利用率只有 20%但 QPS 较低、响应延迟正常那么不一定需要优化。如果 GPU 利用率长期接近 100%同时响应延迟持续升高就需要考虑是否存在容量不足的问题。八、GPU 监控与故障排查思路实际工作中GPU 监控的价值不只是查看数据而是根据指标定位问题。可以建立下面这套排查流程第一步检查 GPU 基础状态nvidia-smi重点检查GPU 是否正常识别温度是否异常显存是否接近上限功耗是否正常是否存在异常进程是否存在 ECC 错误第二步检查 GPU 实时变化nvitop重点观察GPU 利用率是否持续波动是否存在显存占用高但利用率低的情况多张 GPU 的负载是否均衡是否有进程异常占用 GPU第三步检查训练任务结合训练框架和日志检查Batch Size 是否合理DataLoader 是否成为瓶颈CPU 是否存在资源不足每次迭代耗时是否异常GPU 是否频繁等待数据第四步检查 GPU 通信多 GPU 训练时进一步检查NCCL 通信是否正常AllReduce 是否耗时过长GPU 间互联是否正常NVLink、PCIe 带宽是否满足需求网络是否存在丢包、拥塞或带宽瓶颈第五步建立长期监控生产环境可以采用DCGM Exporter | v Prometheus | v Grafana | v GPU 集群监控与告警通过长期指标分析可以发现 GPU 利用率异常、功耗异常、显存不足以及集群负载不均衡等问题。九、今日知识总结本节主要学习了 GPU 监控体系及其性能分析方法。1. 三大监控工具nvidia-smi查看 GPU 当前状态。nvitop持续观察 GPU 运行状态和进程。DCGM Prometheus Grafana实现 GPU 集群级监控、历史数据存储和告警。2. GPU 核心指标GPU-Util反映采样周期内 GPU 有 Kernel 执行的时间比例。SM Active反映 SM 的活跃程度。Power Usage反映 GPU 当前功耗。Memory Usage反映显存占用情况。P-State反映 GPU 当前性能状态。3. 重要认知GPU 利用率高不代表 GPU 算力已经跑满。判断 GPU 是否真正发挥性能需要结合利用率、功耗、显存占用、SM 活跃度和 Tensor Core 活跃度进行分析。4. AI 集群中的重要问题多 GPU 训练不仅需要计算能力还需要高效的 GPU 间通信。当 AllReduce 等通信操作成为瓶颈时即使 GPU 本身计算能力很强也可能因为等待通信而无法充分发挥性能。