一个人习惯用nvidia-smi看显卡状态的人突然对着 AMD GPU 是会懵的。我经历过这个场景从云厂商租了一台配了 AMD Instinct MI210 的机器PyTorch 训练脚本已经跑起来了loss 在降但我连最基本的显卡利用率是多少、温度多少、显存还剩多少都答不上来。网上教程铺天盖地都是nvidia-smi搜 AMD 相关的有人说用rocm-smi装完新版本 ROCm 之后系统又提示这个命令已经弃用让我改用amd-smi。绕了一圈才发现AMD 生态里真正对应nvidia-smi的工具就是 AMD SMI也就是命令行下的amd-smi以及老版本里的rocm-smi。这篇东西就把 AMD SMI 从安装确认、字段解读、指标含义、调优配置到实际排查问题的完整链路讲清楚。适合三种人看刚租了 AMD GPU 云服务器准备跑深度学习的人、公司内部有 AMD 显卡集群需要做日常运维的人、以及在 PyTorch/其他框架里跑训练时被 GPU 性能问题折磨的人。读完之后你至少不会再对着amd-smi的输出发呆也知道该用哪个字段判断显卡是否真的在满负荷干活。1. 为什么你需要一个AMD版nvidia-smiAMD GPU监控工具的来龙去脉1.1 我为什么会写这个话题一次PyTorch训练卡顿的排查经历先说那次让我窝火的排查。模型是常规的 Transformer 结构数据加载也没什么幺蛾子但训练速度就是上不去。我习惯性地敲nvidia-smi结果告诉我命令不存在。这台机器只有 AMD GPU。那就用rocm-smi吧结果终端里直接打出一行提示这个工具已经标记为废弃请使用amd-smi。那一刻我才意识到AMD 的这套东西已经经历过一次工具更替网上大量教程写的是老玩法。更麻烦的是不同教程里给出的命令参数还不一样有的说加--showtemp有的说加--json我拿到的版本全都报未知参数。到最后还是老老实实amd-smi --help逐项看的。这件事给我的教训是**在接触 AMD GPU 之前先把监控工具链彻底搞清楚而不是拿 nvidia-smi 的使用惯性硬套。**这也是我想写这篇内容的最直接动机。1.2 amd-smi、rocm-smi 与 nvidia-smi 到底是什么关系把三个工具放在一起看就清楚了。nvidia-smi是 NVIDIA 官方的系统管理接口工具它同时承担了状态查询、参数设置、进程监控三大职责地位已经是事实标准。AMD 这边历史上有两代工具工具所属生态状态特点rocm-smiROCm 早期版本已弃用部分发行版仍保留兼容基于 PythonREADME 里命令多输出样式老amd-smiROCm 6.x 起主推当前推荐C 实现子命令体系清晰支持 JSON 输出nvidia-smiNVIDIA 驱动长期维护生态成熟事实标准amd-smi和rocm-smi不是完全等价的关系。rocm-smi是早期用 Python 写的脚本命令风格扁平比如rocm-smi --showtemp、rocm-smi --showuse。amd-smi是后来用 C 重新实现的一套工具把功能拆成了monitor、static、metric、set、reset这些子命令。有些发行版为了兼容会在安装 ROCm 时附带rocm-smi甚至把一个兼容脚本软链到amd-smi上所以你会看到敲 rocm-smi 却输出 amd-smi 风格的怪现象。还需要注意一点**AMD SMI 并不支持所有 AMD 显卡。**它主要面向 RadeonRDNA 架构和 InstinctCDNA 架构系列。比较老的 GCN 架构卡或者某些 APU 的核显能拿到的指标会少很多甚至直接不支持。所以拿到一台机器第一步不是看命令怎么敲而是先确认你的卡在不在支持列表里。工具所在的路径也有讲究。正常情况下ROCm 装好后amd-smi在/opt/rocm/bin/下面如果你的环境变量没把/opt/rocm/bin加进 PATH直接敲amd-smi是会命令找不到的。这种情况下的排查命令是ls -l /opt/rocm/bin/amd-smi /opt/rocm/bin/amd-smi --version确认工具存在之后再继续后面的操作。2. 上手第一件事amd-smi基础命令与输出字段逐行拆解2.1 安装与版本确认环境的三个前置问题先回答三个问题工具在哪、版本是多少、驱动认不认卡。**工具在哪。**如果你是装了完整 ROCm 的直接查/opt/rocm/bin/。如果找不到可能是你的发行版把 amd-smi 打成了独立软件包比如 Debian/Ubuntu 体系下的名字类似amd-smi或rocm-smi-libFedora 系也有对应包。用系统自带的包管理器搜一下amd-smi关键词就能看到。**版本是多少。**ROCm 版本和 amd-smi 版本强相关。ROCm 5.x 时期你大概率拿到的是rocm-smiROCm 6.x 才正式把amd-smi作为主推工具。版本差异会导致参数不完全一致所以我后面给的命令你执行前最好都先看一眼本机amd-smi --help的实际输出。**驱动认不认卡。**这一步最容易被忽略。amd-smi底层依赖内核里的 amdgpu 驱动驱动没正确加载工具自然报错。在 Linux 上可以先看lspci -nn | grep -i display\|vga\|advanced micro devices能看到 AMD 的显卡设备再确认amdgpu模块已经加载lsmod | grep amdgpu没有输出的话说明驱动模块没加载成功这时候先去查驱动加载失败的原因而不是调 amd-smi 的参数。2.2 默认输出怎么看一张表理解所有字段直接执行amd-smi monitor你会看到类似下面这种逐屏刷新的输出不同版本字段名会略有出入但核心都在GPU socket VRAM GTT GPU TEMP POWER PERF FAN used used used util usage 0 pci:1:00.0 10.1G 3.4G 65% 67C 214W auto 35% 1 pci:41:00.0 8.2G 1.1G 42% 58C 143W auto 28%新手最容易盯住GPU util一列看但对排障来说其他几列信息量更大。逐个拆解字段含义排障时的作用GPU设备编号从 0 开始配合HIP_VISIBLE_DEVICES定位进程跑在哪张卡上socketPCIe 总线位置判断卡插在哪个槽位多卡互联时看拓扑VRAM used显存使用量判断 batch size 是否过大/过小是否显存溢出GTT used借用系统内存的量数值持续增长说明显存可能不够用正在走内存换页GPU util采样窗口内有内核执行的占比低不一定差高也不一定好结合功耗一起看TEMP当前温度与结温Junction配合判断是否过热降频POWER当前功耗接近 TBP 说明卡在努力干活很低但有负载则要查降频PERF性能等级auto/low/high/manual卡死 low 时基本等于摸鱼FAN风扇转速百分比温度高、风扇低时查风扇策略或硬件故障其中GTT used是 AMD 生态里很有存在感的指标。GTT 全称 Graphics Translation Table简单理解就是显卡驱动把系统内存划给 GPU 做备用显存用的映射。当你的 VRAM 不够装下所有张量和中间结果时驱动不会直接报错而是把一部分数据放到系统内存里运行时再通过 PCIe 搬运。这个数据搬运极其消耗带宽训练速度会断崖式下跌。所以看到GTT used长期占着几个 G就要去考虑调小 batch size、减小序列长度或者开启更多的显存复用策略。2.3 最常用的三个子命令monitor、static、metricamd-smi monitor适合交互式观察它会持续刷新。如果你只想拿到某个时刻的快照尤其想顺手存进日志文件就应该用另外两个子命令。**static 子命令只看不变的硬件信息。**包括显卡型号、BIOS 版本、PCIe 信息、最大功耗、最大显存、支持的性能等级范围。这些参数在运行期基本不会变适合在训练前做一次环境确认。amd-smi static**metric 子命令读取当前指标。**侧重频率、功耗、温度、电压、风扇这些实时变化的量。和 monitor 的最大区别是输出更结构化更接近我要把这个值取出来做判断的需求。amd-smi metric这两个命令在多数版本里都支持 JSON 输出具体参数用amd-smi static --help和amd-smi metric --help查一下。我实际使用中比较喜欢 JSON 输出因为脚本解析起来不会因为终端配色或者表格对齐出问题。还有一个交互场景的万能组合watch -n 2 amd-smi monitorwatch -n 2让输出每两秒刷新一次训练时挂在旁边终端比反复敲命令省事。这个组合在高负载排查时几乎是标准操作。3. 监控信息的细节深挖从利用率到功耗这些指标到底怎么看3.1 GPU 利用率不等于算力利用率这是 AMD SMI 使用中最大的认知误区也直接影响你排查问题的正确性。GPU util这个数字并不是计算单元被填充了多少比例而是在采样窗口内GPU 上是否有至少一个内核在执行的时间占比。翻译成大白话它只看你忙不忙不看你忙得有多饱和。举个例子。一个 kernel 只启动了很少的线程但每个线程要跑很久GPU 上的计算单元大部分时间在空转等数据可采样器看到的却是有内核在执行于是给你报 100%。反过来如果你的代码里 kernel 之间夹杂了大量 CPU 端的数据处理或同步操作GPU 会频繁进入空闲再启动的循环采样器看到的是有很多窗口没有内核执行于是利用率报得很低但实际计算负载并不小。所以当你看到GPU util 100% 但训练吞吐上不去不要急着怀疑工具先问问自己这个 workload 是纯计算密集吗如果是再去看功耗。计算密集型任务在 GPU 满负荷时功耗通常也会顶到接近 TBP典型功耗上限。如果 util 100% 但功耗只有 TBP 的一半大概率是计算单元并没有被填满比如线程块配置太小、访存模式太差、或者 kernel 之间有严重的依赖等待。判断算力是否真正吃满我习惯用利用率功耗温度三个指标一起看而不是只盯一个 util。3.2 显存占用规律为什么显存没满但训练很慢很多跑 PyTorch 的人有个直觉显存没满 显存不是瓶颈。但 AMD GPU 上有个反向场景显存看着还有剩训练却越来越慢。这种情况的元凶往往是 GTT。PyTorch 在分配显存时用的是缓存分配器它会在显存里预留一部分池子减少频繁向驱动申请释放的开销。当你的实际使用量逼近物理显存或者碎片化严重时新分配请求可能落到系统内存的 GTT 区域。此时你看到的VRAM used可能没有满但训练速度已经因为 PCIe 搬运数据而严重劣化。排查方法持续观察amd-smi monitor里的GTT used列。如果它随着 step 数稳定增长基本可以断定显存已经在超卖边缘。另外看VRAM used的变化曲线如果曲线不是平滑上升而是频繁出现尖峰说明存在反复申请释放大块显存的行为这也是隐性的性能杀手。举一个我实际遇到的案例用变长序列做微调数据 padding 得很随意导致每个 batch 的显存需求波动巨大。从 amd-smi 看显存经常在 70% 到 95% 之间跳。后来把 padding 策略改成按 batch 内最大长度动态计算并统一截断峰值显存稳定下来训练快了大约 18%。这个优化完全是在 amd-smi 的监控数据指导下完成的。3.3 温度传感器的三个读数Edge、Junction、MemoryAMD GPU 的温度读数比 NVIDIA 更绕。amd-smi里你通常能看到三类温度Edge Temperature边缘温度、Junction Temperature结温、Memory Temperature显存温度。Edge 是 GPU 芯片边缘的温度传感器读数平时最低。Junction 是芯片上发热最严重的热点的温度专业叫法叫结温可以理解为这张卡上最烫的点的温度。显存温度则是显存颗粒附近的传感器读数。**判断降频要看哪个看 Junction。**显卡的功耗管理和降频策略都是以热点温度为依据的。很多人在 AMD 卡上看到 Edge 只有 60 度觉得散热没问题其实 Junction 可能已经冲到 100 度以上风扇狂转频率也在不断下调。不同卡的结温阈值不同数据中心卡比如 Instinct 系列长期跑在 100 度以上才算危险区消费级 Radeon 卡的阈值会保守一些。但有一点是通用的如果你发现Junction TEMP和Edge TEMP的差值长期超过 30 度说明散热器或者导热介质可能出现了问题比如硅脂干了、热管失效、或者风扇转速策略异常。这时候不是程序员的锅是硬件的锅。3.4 功耗、频率与性能状态搞清楚卡为什么摸鱼amd-smi输出里的PERFperformance level是判断卡是否正常工作的关键线索。它通常有 auto、low、high、manual 等档位。auto 表示驱动根据负载自动调频如果强制设成 low卡的频率会被锁死在一个很低的水平。我见过一次特别典型的隐性降频机器原来被人做过功耗限制TBP 被设成了默认的一半。结果训练时 GPU util 永远报 100%功耗也顶着限制跑但频率明显上不去训练吞吐量只有正常水平的六成。这种问题只看 util 是看不出来的必须对照amd-smi metric里的当前频率和POWER列才能发现。所以每次接到一台新的 AMD GPU 机器我都会在训练前刷一遍amd-smi static # 看最大功耗、频率范围 amd-smi metric # 看当前频率、功耗、温度拿到基线之后再启动训练对比负载状态下的真实数值。4. 不只是看amd-smi 的配置管理与性能调优能力4.1 set 命令功耗上限、性能等级与手动风扇amd-smi的set子命令可以修改显卡的可调参数最常见的三个用途是设置功耗上限、设置性能等级、手动控制风扇。设置功耗上限在一些需要控制机房功耗预算的场景非常有用。比如机柜总功率有限4 张卡同时满负荷会跳闸就可以把每张卡的上限压低一点amd-smi set -g 0 --power-cap 220不同卡支持的上限范围不同具体用amd-smi set --help查。注意这类设置通常需要 root 权限且在重启后大概率失效需要写进开机脚本或者服务里才能持久化。性能等级可以手动指定amd-smi set -g 0 --perf-level high但这东西在绝大多数场景下是个坑。手动锁 high 可能让卡长时间处于高频状态温度飙升锁 low 则直接性能腰斩。我建议普通用户保持 auto 不动只有当你确认驱动自动调频有问题时才去手动干预。4.2 reset 命令什么时候才需要复位 GPUamd-smi reset -g 0是把指定 GPU 恢复到默认状态的操作包括清掉功耗上限、性能等级这些修改某些情况下也会对驱动中的错误状态做复位。这个命令的使用场景很窄。训练进程异常退出、显存泄漏导致驱动里的资源没释放干净时重置确实能救急。但我要提醒一点reset 之前必须确认没有其他进程正在使用这块卡否则会直接干掉别人的任务。在多卡共享的集群机器上操作前先用amd-smi monitor看一眼显存占用和进程情况再决定动不动手。4.3 多卡互连与拓扑先看再调别让数据搬运卡脖子多卡场景下卡与卡之间的数据交换效率往往比单卡算力更影响整体性能。AMD 的数据中心卡支持 xGMI 互连多张卡可以通过高速总线直接交换数据不走 PCIe延迟更低、带宽更大。amd-smi可以查看互连拓扑信息具体字段在不同版本里位置不一样但一般能找到链路类型和带宽。排查多卡训练慢的问题时先确认卡间是否真的走了 xGMI。如果两张卡明明支持 xGMI却因为是不同 PCIe switch 下的组合导致实际走了 PCIe 通道那 All-Reduce 通信就会成为瓶颈。实际操作中还有一个容易踩的坑**SMI 工具显示正常但你没发现卡被分到了不同的 NUMA node。**GPU 和 CPU 之间的数据拷贝如果跨 NUMA性能损耗非常明显。这种情况要用lstopo或者amd-smi的拓扑信息交叉验证然后通过绑定线程的 affinity 来优化。4.4 JSON 输出与脚本化把 amd-smi 接进自己的监控体系想要长期记录 GPU 状态靠人眼盯着是不现实的。amd-smi支持结构化输出你可以在子命令里加上 JSON 相关的参数把结果变成可解析的格式。下面是一个最小可用的采集脚本思路#!/bin/bash # gpu_monitor.sh while true; do echo $(date) gpu_metrics.log amd-smi metric --json gpu_metrics.log sleep 60 done跑起来之后每隔一分钟落一条带时间戳的指标记录。需要定位某个时间段的速度下降问题时直接查这个日志文件对比功耗、温度、频率曲线很快能定位是降频、功耗限制还是外部抢占。如果团队里已经有一套 Prometheus Grafana 的可观测体系也可以写一个文本采集器把amd-smi的 JSON 输出转成 Prometheus 的文本格式交给 node_exporter 的 textfile collector 去拉取。这样就不用另外起 agent纯靠标准组件就能把 GPU 指标接进现有大盘。5. 实战场景PyTorch训练与集群监控中的amd-smi正确用法5.1 训练之前的检查清单别等跑起来才发现环境不对用 AMD GPU 跑 PyTorch 和用 NVIDIA GPU 最大的区别在于**你装的 PyTorch 必须是 ROCm 版本。**如果装的是默认的 CUDA 版本torch.cuda.is_available()永远返回 False程序会安静地跑在 CPU 上你从amd-smi也看不出 GPU 有任何负载。在启动训练前我固定的检查顺序是# 1. 确认 ROCm 工具链可用 amd-smi version # 2. 确认 PyTorch 识别到 HIP 后端 python -c import torch; print(torch.version.hip); print(torch.cuda.is_available())torch.version.hip返回的是 PyTorch 内置的 HIP 版本号。如果这个属性不存在或者为空说明你装的 PyTorch 不是 ROCm 版后面所有的 GPU 优化都是空谈。torch.cuda.is_available()在 ROCm 版 PyTorch 里会检查 HIP 后端返回 True 才说明框架真的连上了 GPU。接下来不要急着跑完整训练先跑一个小测试确认哪张卡在工作python -c import torch print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0)) x torch.randn(1000, 1000, devicecuda) y torch.matmul(x, x) print(y.sum().item()) 屏幕上能看到显卡型号矩阵乘法能算出结果环境才算真的通了。5.2 训练中实时观察的正确姿势把三个指标串起来看训练跑起来之后我最常用的动作是开一个独立终端执行watch -n 2 amd-smi monitor然后一边看输出一边回答自己三个问题**第一GPU util 有没有周期性掉到零**如果每个 step 之间 GPU 都有明显的空闲窗口说明 CPU 在拖后腿。数据加载、预处理、Python 侧的张量搬运都可能造成这种间隙。此时优先检查 DataLoader 的num_workers是否够大prefetch 机制是否生效。**第二功耗是不是顶着上限**功耗长期贴着 TBP 运行说明 GPU 在努力工作。如果利用率高但功耗只有一半我会上amd-smi metric查当前频率判断是否因温度或功耗限制被压频。**第三温度有没有进入降频区间**Junction 温度如果逼近 100 度并伴随频率同步下调那就是散热问题需要检查机柜风道、风扇转速、或者考虑降功耗上限。把这三个问题串起来看大部分GPU 利用率看着正常但训练不快的疑问都能初步定位到方向。5.3 多卡与集群环境轮询采集与统一画面多卡节点上amd-smi monitor默认会显示所有显卡8 卡机的输出就是 8 行。但集群环境里通常有几十上百张卡靠 SSH 到每台机器上去敲命令完全不现实这时候需要一个统一的采集视角。我的做法是给每台机器部署一个最小化的采集脚本把amd-smi的 JSON 输出推送到中心的时序数据库或者日志服务。脚本本身不复杂核心就是定时执行命令、格式化数据、发送出去。真正的坑在于轮询频率。之前见过有人把采集间隔设成 1 秒每个采集周期都去解析一次 JSON几十台机器同时这么干反而给驱动和 PCIe 总线增加了不必要的负担。实际经验是日常监控 30 秒一次足够出问题时再临时加密到 1 秒。另外一个容易被忽略的点是进程归属。当你发现某张卡负载异常需要第一时间知道是哪个用户在跑什么任务。amd-smi在新版本里提供了进程查询能力可以查看当前 GPU 上有哪些进程在占用命令可能因为版本不同叫process或者ps具体执行amd-smi --help确认。对于共享集群来说这一步能省去大量扯皮时间。5.4 遇到占用都不高但卡的排查路径gpu cpu 内存占用都不高但卡这个现象听着诡异其实在 AMD GPU 环境里有几条非常具体的排查路径。我梳理了一个固定顺序照着做基本能把问题定位到 80%。**第一步看 PERF 和频率。**先跑amd-smi metric看 performance level 是不是被锁在 low。如果是检查有没有人在之前手动改过性能等级或者某个软件把功耗上限设置得极低。这是所有指标都不高但卡的第一嫌疑。第二步看 GTT。GTT used如果持续增长且很大说明显存可能在超卖数据在通过 PCIe 来回搬运。表现就是 CPU、GPU 利用率都不高但整体任务很慢因为都在等数据传输。**第三步看温度与频率的关系。**如果 Junction 温度刚好卡在降频阈值附近频率会呈现锯齿状波动升到某个值就跳水再升再跳。这种微妙的状态从利用率上看不出来但amd-smi metric里的频率曲线会非常典型。**第四步查内核日志。**AMD 驱动的问题会在dmesg里留下痕迹。重点搜amdgpu、reset、timeout等关键词。如果看到 GPU hang 或者 reset 相关记录说明驱动层面已经出过问题这时候软件层怎么调参都救不回来先解决驱动状态。dmesg | grep -i amdgpu | tail -n 50这套流程走完绝大多数占用不高但卡的问题都能定位到具体环节。剩下的 20% 就可能需要升级内核、换驱动版本或者直接联系硬件厂商的技术支持了。6. 踩坑记录多卡环境、权限问题与监控脚本的常见陷阱6.1 权限问题为什么普通用户读取不到功耗和风扇转速amd-smi放在系统目录里不代表普通用户能拿到所有指标。我在一台新机器上遇到过这种情况用普通用户执行amd-smi monitorGPU util 和显存都能看到但温度、功耗、风扇转速全部显示为不可读取或直接为空。原因有两层。一是内核 amdgpu 驱动对某些系统级传感器属性做了权限限制二是工具的某些功能需要访问受限设备节点。解决办法不复杂把用户加进video组不同发行版组名可能不一样常见的是video或者rendersudo usermod -aG video $USER重新登录后绝大多数指标就能正常读取了。如果还不行再检查/dev/kfd、/dev/dri/*这些设备节点的权限。集群环境里这些最好在装机时就让管理员配好而不是等用户跑训练时才发现读不了数据。这里还附带一个安全建议**不要因为权限问题就习惯性sudo amd-smi。**查看监控可以 sudo 一下没问题但set、reset这类写操作一定要谨慎明确知道自己在改什么才动手。在生产集群上一个随手敲错的--perf-level low就能让别人的训练任务慢一半还极难排查。6.2 rocm-smi 与 amd-smi 的差异别把老教程的命令照抄网上很多讲 AMD GPU 监控的教程还停留在rocm-smi时代。你照抄一个世纪前的命令在 ROCm 6.x 版本上大概率看到的就是deprecated或者unknown option。举个具体差异rocm-smi 时代用rocm-smi --showtemp能直接看到温度rocm-smi --showpower看功耗rocm-smi --showmeminfo vram看显存。这些参数在 amd-smi 里全部不存在你需要改用amd-smi metric、amd-smi static、amd-smi monitor这套子命令体系。我的建议很简单**新机器一律用 amd-smi遇到老教程里的命令先--help确认再执行。**如果你在一台老机器上被迫继续用 rocm-smi也至少要明白它和 amd-smi 的区别别把两套命令混着用。我之前见过有人在脚本里rocm-smi --showtemp和amd-smi monitor连着用输出格式完全对不上解析逻辑直接崩掉。6.3 消费级显卡与数据中心显卡的监控差异同样跑amd-smiRadeon 消费卡和 Instinct 数据中心卡拿到的信息丰富度完全不同。数据中心卡面向长期高负载温度传感器更全功耗管理更精细xGMI 互连、ECC 内存状态这些信息都暴露给工具消费级卡则有些信息会缺失比如部分非公版卡的风扇是接到主板上的不受 GPU 驱动直接控制amd-smi里的 FAN 列就是空的。另外一个现实问题是功耗上限的可调范围。数据中心卡允许你在很大范围内调整功耗上限方便做整机功耗规划消费级卡的可调范围很小甚至某些型号直接禁止调整。所以你在网上看到用 amd-smi set 把功耗压低的教程在消费级卡上照做可能会失败这不是你操作问题是硬件本身不支持。这就引出一个实际建议**租云 AMD GPU 实例前先确认是 Instinct 还是 Radeon。**如果是跑训练、微调大模型这类长时间高负载任务优先选 Instinct用 Radeon 也不是不行但要接受监控信息不完整、调优手段有限的事实。6.4 脚本里别踩的坑空输出、退出码与轮询频率最后聊几个写监控脚本时容易踩的坑都是我亲测遇到的。第一个坑空输出。amd-smi在某些异常状态下会返回空字符串但退出码仍然是 0。如果你的脚本直接拿去解析会发现所有字段都解析失败。稳妥做法是解析前先判断输出是否为空字符串为空就记一条异常日志而不是让脚本静默失败。**第二个坑轮询频率过高。**前面提过这里再强调一次。对驱动和硬件的状态查询也是要消耗资源的1 秒一次的采样会无谓增加系统负载还可能加剧输出缓冲的竞争。日常监控 30 秒一次紧急排查再加密。**第三个坑多 GPU 机器的超时。**在多卡密集的机器上查询某些指标可能因为驱动内部锁竞争而变慢导致脚本的单次执行时间超过预期。如果你的采集间隔是 30 秒但一次查询就耗了 20 秒数据时间轴就乱了。给脚本加上单次执行超时控制超时后跳过本轮采样是比较实用的写法。**第四个坑显式指定 GPU。**多卡机器上写采集脚本时尽量在命令里显式指定 GPU 范围不要依赖默认输出顺序。因为某些条件下驱动汇报的设备顺序可能变化比如某张卡掉线重连后编号会变。显式指定能避免数据串行。# 只采集 GPU 0 和 GPU 1 amd-smi monitor -g 0,1 --json gpu_metrics.log具体参数以本机--help为准但思路是对的范围明确数据才可靠。最后再分享一个我长期用的五秒检查法。不管多复杂的 GPU 问题上去先执行amd-smi monitor看三样东西PERF 是不是 auto、Junction 温度是不是逼近阈值、POWER 有没有贴着上限跑。这三个指标能过滤掉八成的基础性问题。剩下的疑难杂症再上amd-smi metric看频率曲线和功耗曲线基本就无所遁形了。AMD SMI 这套工具看起来不起眼但把它的输出读明白你的 AMD GPU 才算真正握在自己手里。