1. 项目概述为什么你需要这份nvidia-smi指南如果你是第一次在服务器上敲下nvidia-smi这个命令看到那一大堆表格和数字可能会有点懵。GPU利用率、显存占用、功耗、温度、进程ID……这些信息到底在说什么哪个数字高了需要警惕哪个进程在偷偷占用我的显卡这几乎是每一个刚接触GPU计算、深度学习或者高性能计算的开发者都会遇到的问题。nvidia-smiNVIDIA System Management Interface是NVIDIA官方提供的命令行工具它是我们与GPU硬件“对话”的窗口是监控、管理和诊断GPU健康状况的瑞士军刀。但官方文档往往过于庞杂而网上的资料又零散不全。我从业十多年从早期的Tesla到现在的A100、H100见证了GPU监控需求的演变也踩过无数因为误读监控信息而导致的坑。比如曾经因为没看懂“FB Memory Usage”和“Bar1 Memory Usage”的区别误判了显存瓶颈也遇到过因为忽略了“GPU-Util”和“Memory-Util”的差异导致模型训练效率低下。这份汇总就是把我这些年高频使用、反复验证的命令和解读经验整理成一份即查即用的“实战手册”。它不追求面面俱到但确保你看到的每一个解释都是经过生产环境检验的、能直接指导你行动的关键信息。无论你是运维工程师、算法研究员还是需要管理GPU资源的学生这份指南都能帮你从“看个大概”进化到“精准诊断”。2. nvidia-smi核心输出内容深度解析当你直接输入nvidia-smi并回车屏幕上会弹出一个刷新着的界面默认每1秒刷新一次。这个标准输出界面信息密度极高我们可以把它拆解成几个核心区域来理解。2.1 头部摘要信息GPU集群的全局快照输出最顶部通常是驱动版本、CUDA版本以及一个所有GPU的摘要表格。这个表格是你的第一眼仪表盘。----------------------------------------------------------------------------- | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | 0 NVIDIA A100 80G... On | 00000000:3B:00.0 Off | 0 | | N/A 34C P0 71W / 300W | 0MiB / 81920MiB | 0% Default | | | | N/A | ---------------------------------------------------------------------------GPU: GPU的索引号从0开始。在多卡服务器上这是你定位具体显卡的关键ID。Name: GPU型号如A100 80GB PCIe。这是确认硬件配置的基础。Persistence-M: 持久化模式。On表示已启用GPU在无计算任务时也会保持部分电源状态使后续任务启动延迟更低但会消耗少量待机功耗通常10W左右。对于服务器建议开启sudo nvidia-smi -pm 1。Fan, Temp, Perf: 风扇转速N/A表示由系统自动控制、GPU核心温度摄氏度、性能状态。性能状态从P0最高性能到P12最低功耗P0-P2是活跃状态。实操心得训练时GPU温度通常在70-85℃之间是正常的若持续超过90℃则需要检查散热。如果看到Perf状态长期不在P0可能是遇到了功耗墙Power Cap或温度墙Thermal Throttling。Pwr:Usage/Cap: 当前功耗 / 最大功耗墙。例如“71W / 300W”表示当前功耗71W该卡允许的最大功耗是300W。这个“Cap”值是可以调整的用-pl参数但不得超过硬件上限。Memory-Usage:这是最关键的指标之一。格式为“已用显存 / 总显存”。例如“0MiB / 81920MiB”。这里显示的是“FB Memory”即帧缓存显存是Tensor、模型参数、梯度等主要存放的地方。注意事项这个值不一定等于你所有CUDA Tensor占用的总和因为CUDA上下文、内核函数等也会占用一部分。如果它接近总容量程序很可能会因“Out of Memory”而崩溃。GPU-Util: GPU利用率。这是一个采样周期内GPU核心SM上有任意一个流处理器Streaming Multiprocessor在执行指令的时间百分比。重要解读这个值高如90%通常表示计算密集但低也不一定代表空闲。如果模型数据预处理是瓶颈CPU到GPU的数据传输慢GPU可能会“饿着”利用率呈现锯齿状一会儿高一会儿低。而像推理任务可能是突发性的高利用率然后等待。Compute M.: 计算模式。Default表示多进程可共享GPU。其他模式如Exclusive_Process独占进程或Prohibited禁止计算可以通过nvidia-smi -c设置。2.2 进程信息表格谁在占用我的GPU在GPU摘要表格下方通常跟着一个进程表格----------------------------------------------------------------------------- | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | || | 0 N/A N/A 12345 C ...python3.8 7695MiB | | 0 N/A N/A 23456 C .../my_app 512MiB | -----------------------------------------------------------------------------这个表直接告诉你每个GPU上正在运行的进程。PID: 进程ID。可以用kill -9 PID来强制结束失控的进程。Type: 进程类型C表示Compute计算进程G表示Graphics图形进程在服务器上少见CG表示两者兼有。Process name: 进程名称通常能帮你识别出是哪个训练脚本或应用。GPU Memory Usage: 该进程当前占用的FB显存。排查技巧当你发现显存被占满但ps命令找不到明显进程时可能是之前的进程崩溃后未彻底释放显存。此时可以尝试先kill掉这些残留进程如果无效则可能需要重启GPU驱动风险操作需谨慎sudo rmmod nvidia_uvm nvidia_modeset nvidia sudo nvidia-smi但更安全的方法是重启服务器。2.3 其他关键指标解读在标准输出或使用详细查询命令时你还会遇到一些重要指标Volatile Uncorr. ECC: 易失性ECC错误计数。ECC是显存的错误校验与纠正功能。这个数字如果不是0且在增长说明遇到了无法纠正的显存错误这是硬件故障的红色警报需要尽快报修。BAR1 Memory Usage: BAR1是PCIe BARBase Address Register的一种是CPU可以直接访问的GPU内存窗口。一些大数据传输如DMA会用到。如果这个值异常高可能预示着PCIe数据传输成为了瓶颈。Power Draw / Power Limit: 同前述Pwr:Usage/Cap。Clocks: 包括显卡核心时钟Graphics clock和显存时钟Memory clock。在P0状态下它们会运行在加速频率Boost Clock上。3. 高频实用命令详解与实战场景nvidia-smi的强大远不止于默认输出。通过不同的查询选项和参数我们可以进行精准监控和故障排查。3.1 基础监控与信息查询nvidia-smi -L(List GPUs)命令解释列出系统中所有NVIDIA GPU的简要信息。输出示例GPU 0: NVIDIA A100-PCIE-80GB (UUID: GPU-xxxxxx) GPU 1: NVIDIA A100-PCIE-80GB (UUID: GPU-yyyyyy)实战场景快速确认服务器上有几块卡以及每块卡的基本型号。UUID是全局唯一标识符在容器化环境或集群管理中比GPU索引更可靠。nvidia-smi -q(Query)命令解释显示所有GPU的详细信息报告。信息量巨大包括温度、功耗、时钟、ECC、PCIe信息、进程等所有可查询属性。常用子选项nvidia-smi -q -d TEMPERATURE, POWER只查询温度和功耗信息。nvidia-smi -q -i 0只查询GPU 0的详细信息-i指定GPU索引。实操心得当需要向运维或NVIDIA技术支持提交问题报告时nvidia-smi -q的输出是最全面的诊断信息之一务必包含。nvidia-smi -i gpu_id --formatcsv -q命令解释以CSV格式输出指定GPU的详细信息。这对于自动化脚本监控极其有用因为CSV格式易于用awk,grep或Python的pandas进行解析。实战场景写一个监控脚本定期如每分钟执行此命令将功耗、温度、利用率、显存使用率记录到文件或时序数据库中如InfluxDB用于绘制长期监控图表。3.2 实时监控与日志记录watch -n 1 nvidia-smi命令解释使用Linux的watch命令每1秒刷新一次nvidia-smi的输出。这是最常用的实时监控方式。变体与技巧watch -n 0.5 -d nvidia-smi每0.5秒刷新并且高亮显示两次输出之间的变化-d参数便于观察动态。如果你只想关注关键指标可以结合grepwatch -n 1 “nvidia-smi | grep -A 1 ‘Fan Temp’”但这可能会破坏格式。nvidia-smi -l seconds(Loop)命令解释nvidia-smi自带的循环监控模式。例如nvidia-smi -l 5会每5秒刷新一次输出。与watch的区别watch是通用工具nvidia-smi -l是内置功能。后者在输出稳定性上可能更好但watch的-d高亮变化功能更直观。我个人更习惯用watch。nvidia-smi -lms 500 --query-gputimestamp,power.draw,temperature.gpu --formatcsv -f monitor.log命令解释这是一个强大的组合命令用于将监控数据记录到文件。-lms 500: 每500毫秒0.5秒采样一次。--query-gpu...: 指定要查询的指标用逗号分隔。timestamp时间戳、power.draw当前功耗、temperature.gpuGPU温度。--formatcsv: 输出为CSV格式。-f monitor.log: 将输出重定向追加到monitor.log文件。实战场景在运行一个不确定是否稳定的长期训练任务前启动这个命令记录功耗和温度。如果中途发生宕机可以通过分析日志看是否在崩溃前出现了功耗飙升或温度过高的现象。3.3 设备管理与状态控制nvidia-smi -pm 1(Persistence Mode)命令解释为所有GPU启用持久化模式。需要sudo权限。启用后GPU驱动会在无任务时也保持加载状态下次任务启动延迟可降低到毫秒级。对于服务器环境建议启用。nvidia-smi -pl power_limit(Power Limit)命令解释设置GPU的功耗墙。例如sudo nvidia-smi -i 0 -pl 250将0号GPU的最大功耗限制在250瓦。实战场景节能在推理服务器上可能不需要GPU跑在满血状态适当降低功耗墙可以节省电费同时性能下降可能很小。散热与稳定在散热不佳的机箱内降低功耗墙是控制温度、防止降频的有效手段。注意事项设置的值必须在GPU允许的范围内见Pwr:Cap。重启后设置会失效如需持久化需要写入启动脚本。nvidia-smi -r或nvidia-smi -gpu-reset命令解释重置GPU。这是一个高风险命令当GPU驱动无响应如nvidia-smi命令卡住、显存被死锁进程占用无法释放时可以尝试。它可能导致系统不稳定或需要重启。避坑指南永远不要在生产环境或运行重要任务的机器上轻易尝试。首先尝试kill -9相关进程。如果无效尝试sudo systemctl restart nvidia-persistenced。重置是最后的手段。nvidia-smi -e 0/1(ECC)命令解释切换ECC错误校验与纠正功能的开关。-e 0禁用-e 1启用。需要sudo权限。原理解读ECC会占用一部分显存带宽和容量例如A100 80G启用ECC后可用容量约为81.9G但会划出一部分做校验。在追求极致计算性能和对数据错误零容忍的HPC场景通常开启。在一些对性能极度敏感且能容忍极低概率软错误的深度学习训练中有时会关闭以获得约2%的性能提升和全部显存容量但这会增大因宇宙射线等导致静默数据错误的风险。4. 高级查询与自动化监控脚本当管理成百上千块GPU时命令行交互就不够了我们需要可编程的、自动化的方式。4.1 使用--query-gpu进行精准指标提取这是nvidia-smi最强大的功能之一它允许你像数据库查询一样只获取你关心的特定字段。基本语法nvidia-smi --query-gpu[查询字段1],[查询字段2],... --formatcsv,noheader,nounits--formatcsv,noheader,nounits: 输出为纯CSV没有表头没有单位纯数字最适合脚本处理。常用查询字段举例name: GPU型号index: GPU索引utilization.gpu: GPU利用率百分比utilization.memory: 显存带宽利用率百分比memory.total: 总显存MiBmemory.used: 已用显存MiBmemory.free: 空闲显存MiBtemperature.gpu: GPU温度摄氏度power.draw: 当前功耗瓦power.limit: 功耗限制瓦clocks.current.graphics: 当前核心时钟频率MHzclocks.max.graphics: 最大核心时钟频率MHz实战示例1获取所有GPU的利用率和显存使用率nvidia-smi --query-gpuindex,utilization.gpu,memory.used,memory.total --formatcsv输出0, 45 %, 10240 MiB, 24576 MiB 1, 0 %, 512 MiB, 24576 MiB实战示例2编写一个简单的Bash监控脚本#!/bin/bash # monitor_gpu.sh while true; do clear echo GPU监控 (刷新时间: $(date %H:%M:%S)) # 查询关键指标使用nounits方便计算 nvidia-smi --query-gpuindex,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw --formatcsv,noheader,nounits | while IFS, read -r index name util used total temp power; do # 计算显存使用百分比 mem_pct$(( used * 100 / total )) printf GPU %s (%s): Util %3s%%, Mem %3s%% (%4s/%4s MB), Temp %2s°C, Power %4s W\n \ $index $name $util $mem_pct $used $total $temp $power done sleep 2 done这个脚本会每2秒清屏并刷新一次以更友好的格式显示信息。4.2 结合pynvml(Python Bindings) 进行程序化控制对于更复杂的监控、告警或集成到Python应用如训练框架中动态调整任务NVIDIA Management Library (NVML) 的Python绑定pynvml是更佳选择。它提供了完整的API。安装pip install pynvml基础使用示例import pynvml pynvml.nvmlInit() # 获取GPU数量 device_count pynvml.nvmlDeviceGetCount() print(f找到 {device_count} 个GPU设备) for i in range(device_count): handle pynvml.nvmlDeviceGetHandleByIndex(i) # 获取设备名称 name pynvml.nvmlDeviceGetName(handle) # 获取内存信息 mem_info pynvml.nvmlDeviceGetMemoryInfo(handle) total_mem mem_info.total / 1024**2 # 转换为MB used_mem mem_info.used / 1024**2 free_mem mem_info.free / 1024**2 # 获取利用率 util pynvml.nvmlDeviceGetUtilizationRates(handle) gpu_util util.gpu mem_util util.memory # 获取温度 temp pynvml.nvmlDeviceGetTemperature(handle, pynvml.NVML_TEMPERATURE_GPU) # 获取功耗 power pynvml.nvmlDeviceGetPowerUsage(handle) / 1000.0 # 转换为瓦 power_limit pynvml.nvmlDeviceGetEnforcedPowerLimit(handle) / 1000.0 print(fGPU {i} ({name}):) print(f 显存: {used_mem:.0f}/{total_mem:.0f} MB ({used_mem/total_mem*100:.1f}%)) print(f 利用率: GPU {gpu_util}%, Mem {mem_util}%) print(f 温度: {temp}°C) print(f 功耗: {power:.1f} / {power_limit:.1f} W) pynvml.nvmlShutdown()优势pynvml让你可以在Python程序中灵活地查询、控制GPU并基于这些数据做出决策例如在显存不足时自动清理缓存或在温度过高时暂停任务。5. 常见问题排查与性能调优实战掌握了命令和指标最终目的是解决问题和优化性能。下面是一些典型场景的排查思路。5.1 显存已满但nvidia-smi看不到对应进程现象nvidia-smi显示显存占用很高例如 78G/80G但下面的进程列表是空的或者显示的进程占用总和远小于显存使用量。可能原因与解决方案CUDA上下文残留某个进程如Python解释器崩溃后其分配的显存没有被驱动正确释放。这通常发生在使用某些深度学习框架时。排查尝试使用fuser -v /dev/nvidia*命令查看哪些进程打开了NVIDIA设备文件。找到可疑PID后kill -9。终极方案重启GPU驱动sudo rmmod nvidia_uvm nvidia_modeset nvidia_drm nvidia然后sudo nvidia-smi会重新加载或直接重启服务器。这是最彻底的方法。内核模块或容器占用如果使用了GPU虚拟化如MIG或容器Docker显存可能在父进程或容器运行时被分配。排查在宿主机上运行nvidia-smi看到的是全局视图。进入容器内部再运行nvidia-smi看到的才是容器内的视图。确保你在正确的环境查看。5.2 GPU利用率GPU-Util很低但任务跑得很慢现象训练或推理脚本运行但GPU-Util长期在0%-30%徘徊任务耗时远超预期。诊断思路这通常是CPU/IO瓶颈或内核启动开销过大的典型表现。GPU在等待数据。步骤1检查CPU和磁盘。使用htop或top查看CPU是否有一个或几个核心跑满。使用iotop或iostat查看磁盘读写是否繁忙。深度学习中的数据加载和预处理如图像解码、增强是常见的CPU瓶颈。步骤2检查数据加载。如果是PyTorch可以尝试使用torch.utils.data.DataLoader的num_workers参数增加数据加载子进程并使用pin_memoryTrue加速CPU到GPU的数据传输。步骤3检查Batch Size和模型。过小的Batch Size会导致GPU无法充分并行计算大量时间花在内核启动和同步上。尝试增大Batch Size。另外模型本身如果过于简单计算量小也可能无法“喂饱”强大的GPU。步骤4使用Profiler工具。像PyTorch Profiler、NVIDIA Nsight Systems 可以生成详细的时间线清晰地展示是数据加载、CPU预处理还是GPU计算是瓶颈。5.3 如何监控多卡训练时的负载均衡现象使用多张GPU进行数据并行训练但有的卡利用率高有的卡利用率低。排查方法使用watch -n 0.5 nvidia-smi观察直观查看每张卡的GPU-Util和Memory-Usage是否大致相同。程序内监控在训练代码中每隔一定迭代记录每张卡的实际批处理数据量。不均匀可能是数据分配逻辑有问题。检查PCIe拓扑使用nvidia-smi topo -m命令查看GPU间的互联拓扑如NVLink、PCIe。如果卡间通信频繁如模型并行连接带宽低的卡可能会成为瓶颈导致等待和利用率低。常见原因数据加载到不同GPU的速度不一致可能因为CPU核心绑定或NUMA架构、模型参数同步All-Reduce耗时差异等。5.4 功耗和温度异常升高现象GPU温度持续超过90°C或功耗持续接近甚至达到功耗墙。应对策略检查散热服务器风扇是否正常工作风道是否被遮挡散热片积灰是否严重调整环境调低机房或服务器所在机柜的环境温度。软件限频降低功耗墙使用sudo nvidia-smi -pl 较低值。这会强制GPU在更低功耗下运行性能会下降但温度和功耗会立刻降低。降低核心频率使用nvidia-smi -lgc 频率需特定条件和支持。这是一个更精细的控制但一般用户较少使用。优化代码检查训练脚本是否存在计算浪费例如不必要的频繁数据拷贝、未使用混合精度训练等。使用Tensor Cores的混合精度训练AMP通常能显著降低功耗和提升性能。5.5 自动化告警脚本示例结合前面提到的查询技巧我们可以写一个简单的健康检查脚本定时运行并通过邮件或即时通讯工具发送告警。#!/bin/bash # gpu_health_check.sh THRESHOLD_TEMP85 # 温度阈值摄氏度 THRESHOLD_MEM_PCT95 # 显存使用率阈值百分比 LOG_FILE/var/log/gpu_health.log # 获取所有GPU索引 gpu_indices$(nvidia-smi --query-gpuindex --formatcsv,noheader) for i in $gpu_indices; do # 查询单个GPU的指标 query_result$(nvidia-smi -i $i --query-gputemperature.gpu,memory.used,memory.total --formatcsv,noheader,nounits) IFS, read -r temp used total $query_result # 计算显存使用率 mem_pct$(( used * 100 / total )) alarm_msg # 检查温度 if [ $temp -ge $THRESHOLD_TEMP ]; then alarm_msgGPU $i 温度过高: ${temp}°C fi # 检查显存 if [ $mem_pct -ge $THRESHOLD_MEM_PCT ]; then alarm_msg$alarm_msg\nGPU $i 显存即将用尽: ${mem_pct}% (${used}/${total} MiB) fi # 如果有告警信息记录日志并发送通知这里以写入日志为例可替换为sendmail等 if [ -n $alarm_msg ]; then echo [$(date)] ALARM: $alarm_msg $LOG_FILE # 此处可以集成发送邮件或Webhook例如 # curl -X POST -H Content-Type: application/json -d {\text\:\$alarm_msg\} YOUR_WEBHOOK_URL fi done # 检查是否有GPU掉卡或无响应nvidia-smi命令本身是否成功 if [ $? -ne 0 ]; then echo [$(date)] CRITICAL: nvidia-smi command failed! GPU may be down. $LOG_FILE fi可以将此脚本加入crontab每5分钟执行一次实现基本的GPU健康监控。