去年有个昇腾推理项目压在我手里模型在 Atlas 300I 上跑得好好的一到晚上就卡顿日志打出来全是超时。排查一圈定位到最后才发现是板卡温度长期顶在 85 度以上触发降频保护AI Core 频率被拉低推理延迟自然就上去了。从那次之后我养成了一个习惯每次训练和推理任务出问题第一件事就是打开终端敲npu-smi info先看温度、再看功耗、再看进程把硬件状态摸清楚再谈算法。这套命令就是华为昇腾 NPU 自带的监控工具官方名叫 npu-smi全称是 NPU System Management Interface功能对标 NVIDIA 的nvidia-smi。不管你用的是 Atlas 训练卡、推理卡还是 Atlas 800/900 整机服务器只要是昇腾系列芯片基本都靠它来查看 NPU 状态、芯片温度、AI Core 占用率、HBM 显存用量、功耗数据以及进程占用情况。这篇文章我把自己在实战里积累的解读方法和踩坑记录全部整理出来从命令格式、输出字段含义到温度阈值判断、显存排查、进程清理再到如何写一个简单的轮询监控脚本一步步讲清楚。适合刚接手昇腾设备的算法工程师、运维同学还有做模型部署的研发至少能少走一半弯路。1. 为什么必须学会 npu-smi它到底解决什么问题1.1 昇腾 NPU 监控工具的定位与生态背景昇腾 NPU 不像 GPU 那样在消费市场普及很多团队拿到手之后第一反应是装上驱动跑模型很少有人认真研究监控工具。但恰恰是这种心态最容易埋雷。昇腾芯片本身散热设计和功耗管理有自己的逻辑驱动层面也有一套完整的状态上报机制npu-smi 就是这套机制的对外入口。它由华为自研的驱动框架和 CANN 工具链提供默认随驱动一起安装路径通常在/usr/local/Ascend/driver/tools/下不需要额外部署。我在实际工作里把 npu-smi 的用途总结成三类第一类用于日常状态巡检比如开机后确认芯片是否正常识别、温度是否在安全区间第二类用于性能问题定位当训练变慢、推理超时、显存报错的时候用它来确认是不是硬件资源出现瓶颈第三类用于多卡环境管理在 Atlas 800 这类八卡服务器上快速确认哪张卡在跑什么任务、哪张卡处于空闲状态任务调度就方便很多。1.2 从三个维度读懂硬件健康温度、显存、进程我个人的习惯是所有排查都按温度、显存、进程三个维度来拆。温度决定硬件能否稳定运行在满血状态任何芯片都有热设计功耗TDP和工作温度上限超过阈值轻则降频、重则直接触发保护性关机显存是模型运行的物理基础HBM 被占满会导致分配失败或 OOM这个比 CUDA 报错还难查进程回答的是谁在占用 NPU这个问题特别是在多人共用一台服务器的时候抢卡、残留进程、僵尸任务全靠它来定位。这三个维度的数据在npu-smi info的输出里都能直接或者间接拿到。学会解读这块输出基本就掌握了昇腾设备监控的七成内容。2. npu-smi info 输出逐行拆解看懂每个字段的实际含义2.1 命令入口版本差异和基本用法先明确一点npu-smi 的功能是跟随驱动版本走的。如果你装的是比较新的 CANN 版本比如 6.x 之后npu-smi info的输出排版和字段名称可能和旧版有细微差异。很多网上教程直接贴老版本的截图照抄就踩坑。拿到任何一台昇腾机器我建议先跑一条npu-smi -v或者npu-smi info -v看看版本号再去对照输出理解字段。基础命令格式如下# 查看所有NPU设备的基础信息 npu-smi info # 查看详细帮助列出所有可用选项 npu-smi info -h # 查看指定设备和指定芯片的信息 npu-smi info -i 0 -c 0其中-i参数后面跟的是设备编号也就是第几张卡-c参数后面跟的是芯片编号单张卡上如果有多个芯片用这个区分通常从 0 开始。在单卡推理设备比如 Atlas 300I 上一般-i 0 -c 0就是唯一的选择但在 Atlas 800 训练服务器上8 张卡对应-i 0到-i 7必须用参数区分。2.2 设备列表区NPU Name、Health、Power、Temp 字段解读我们直接看一段模拟典型 Atlas 800 训练服务器的输出实际内容和你的版本可能不会完全一致但字段逻辑是通用的-------------------------------------------------------------------------------------- | npu-smi 23.0.0 Driver Version: 23.0.0 | ------------------------------------------------------------------------------------ | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)| | Chip | Bus-Id | AICore(%) Memory-Usage(MB) HBM-Usage(MB) | | 0 910A | OK | 264.3 78 0 / 1024 | | 0 | 0000:01:00.0 | 78 1024 / 0 30720 / 32768 | ------------------------------------------------------------------------------------ | 1 910A | OK | 179.8 62 0 / 1024 | | 1 | 0000:02:00.0 | 35 0 / 0 16384 / 32768 | ------------------------------------------------------------------------------------第一行npu-smi 23.0.0 Driver Version: 23.0.0是工具版本和驱动版本出现不匹配通常意味着驱动安装有问题需要重新装。接着每两张行描述一个 NPU 设备第一行是 NPU 级信息NPU Name是芯片型号比如 910A、310P 等Health标记健康状态正常值是OK如果出现Warning或者Error说明芯片已经处于异常状态需要查日志Power(W)是当前实时功耗单位瓦Temp(C)是芯片当前的结温单位摄氏度Hugepages-Usage(page)显示的是大页内存的占用情况这个字段主要跟驱动和内存管理相关一般排查显存问题时少观察它重点看 HBM。第二行是 Chip 级信息Bus-Id是设备在 PCIe 总线上的地址在系统里做设备映射时会用到AICore(%)是 AI Core 计算单元的实时利用率这个值代表芯片内部专门用来跑矩阵运算的 AI 计算核心占用比例是最直观的负载指标Memory-Usage(MB)和HBM-Usage(MB)看起来都是内存实际上前者偏设备侧管理内存后者才是真正给模型用的高带宽显存HBM 的数值对模型部署更有参考价值。好多第一次接触 npu-smi 的朋友会问为什么又 Memory 又 HBMNVIDIA 的卡不是直接显存吗解释一下昇腾设备的内存体系分两部分一部分是芯片内部控制、驱动、调度用的系统内存一部分是专门为张量数据设计的高带宽存储 HBM可以直接理解为显存。模型参数、激活值、中间缓冲区都存在 HBM 里所以判断显存够不够看 HBM-Usage 那两列就对了。2.3 字段之间的关系功耗、温度和负载的联动逻辑实战里最容易忽略的就是 Power、Temp、AICore 之间的联动关系。AI Core 利用率高了计算单元大量运转功耗自然上升温度随之爬升温度突破某个阈值后芯片会主动降频AI Core 利用率虽然显示很低但任务速度反而变慢。这个曲线就是典型的降频保护现象。举个例子我遇到过一次任务特别慢的情况npu-smi info显示 AI Core 占用只有 12%温度却飙到 88 度。当时第一反应是任务没跑起来后来看了一圈发现是服务器风道堵了散热效率下降芯片为了保证不损坏自己把主频往下压算力严重缩水。所以单独看某一个字段都没用要把三者放到一起判断如果 AICore 低、温度高、功耗也不低优先怀疑散热如果 AICore 高、温度高、功耗高那是正常重负载需要控制并发或者加散热如果 AICore 高但任务速度依然慢那就要看是不是已经降频。3. 温度监控实战判断是否过热不只看绝对数字3.1 昇腾芯片正常温度范围与报警阈值设置先说结论性的经验值。昇腾 310P、910A 等常见型号正常工作温度通常在 0 到 85 度之间我自己一般是这么分档的50 度以下非常健康50 到 70 度属于正常负载区间70 到 80 度需要开始注意散热和机房温度超过 85 度就要立即排查超过 95 度基本意味着已经降频或者接近保护阈值了。需要注意不同型号的散热设计目标不同910A 这类大算力训练芯片在满载时功耗可达 300 瓦上下温度到 80 度并不稀奇310P 推理卡功耗低很多如果温度长期超过 80 度那大概率是环境问题。在命令行里可以用以下方式查看指定芯片的温度数据这个-t temp参数比直接看 info 主界面的数据更聚焦npu-smi info -t temp -i 0 -c 0服务器上如果有多张卡可以循环查看所有芯片的温度。我在巡检脚本里就是这么写的for i in 0 1 2 3 4 5 6 7 do npu-smi info -t temp -i $i -c 0 | tail -n 8 done3.2 温度异常排查从环境到负载的递进式定位温度异常如果出现不要立刻觉得是硬件坏了。我自己总结了一个排查顺序依照优先级从环境、散热、负载三个层面递进。第一步检查机房环境和机柜通风。这听起来像废话但实实在在出现过因为机柜门没关好、通风口被线缆挡住导致的温度飙升。用手背贴在服务器进风口和出风口感受一下温差如果风量明显变小或者吹出来的风是滚烫的先解决气流问题再说。第二步看设备风扇状态。昇腾服务器一般有管理接口可以查风扇转速也可以通过npu-smi info -t board查看单板信息确认传感数据是否异常。风扇老化、转速掉下来温度必然压不住。第三步看负载是否过大。用npu-smi info看 AI Core 利用率如果多个任务同时在跑并发推理请求特别高芯片持续满载运行温度高其实是正常物理现象。这种时候要么限流要么做任务调度错峰硬件本身没毛病。我特别想提一个细节温度读数不是恒定不变的它会上下抖动。有些朋友看到温度瞬间到 82 度就草木皆兵其实不必。我更建议做 5 分钟到 10 分钟的持续性观察看趋势而不是看瞬时值。如果温度在持续爬升那才是真正需要介入的信号如果是周期性波动说明温控系统在工作。3.3 高温降频的识别与规避策略降频是芯片自我保护的一种机制。昇腾芯片内部有温度传感器当温度超过一定阈值硬件管理单元会主动调低 AI Core 和整芯片的主频降低发热量。这个过程是自动的但代价就是你的训练或者推理任务变慢。识别降频有一个比较直接的办法同时观察功耗曲线和任务耗时。正常情况下跑同样的数据量每轮迭代耗时应该基本稳定如果温度升高之后单轮耗时显著拉升同时功耗反而回落那基本可以确定降频了。我在一个 NLP 模型训练任务里遇到过类似情况正常单步 0.8 秒温度到 90 度后直接变成 2.1 秒性能劣化超过一倍排查才发现散热风扇被机房保洁不小心关了一个。规避高温降频的策略不外乎三种一是优化机房散热空调温度调低、确保风道顺畅二是在任务调度上做削峰填谷把大规模训练任务挪到夜间环境温度低的时候跑三是适当降低芯片的功耗上限牺牲一点极致性能换取稳定性。第三种可以通过npu-smi set -t pwr-max来实现比如把最大功耗限制到 250 瓦温度通常能压下来几度适合对延迟不太敏感的后台训练场景。4. 进程管理实操定位谁在占用 NPU4.1 一次性看懂进程列表输出npu-smi info的主输出里面其实不直接展示进程而是需要通过带参数的子命令查询。按照官方文档和我的使用经验进程信息实时查询最常用的是下面这条npu-smi info -t proc这个命令会列出所有 NPU 设备上正在运行的进程包含进程 ID、进程名称、所在设备编号以及显存占用。下面的示例输出展示了典型的多进程共存场景----------------------------------------------------------------------------------------- | Process id | Process name | Device | Memory Usage(MB) | AICore Usage(%) | | 123456 | python3 | 0 | 2048 | 56 | ----------------------------------------------------------------------------------------- | 234567 | python3 | 0 | 8192 | 45 | ----------------------------------------------------------------------------------------- | 345678 | python3 | 1 | 4096 | 12 | -----------------------------------------------------------------------------------------如果你只想看某一个设备的进程可以加上设备和芯片编号减少无关信息干扰npu-smi info -t proc -i 0 -c 0这个输出和 NVIDIA 的nvidia-smi在进程维度的显示逻辑几乎一致。看到python3同时出现在多个进程里不用惊讶深度学习框架一般会有主进程和多个子进程只要 PID 不同就是正常的多进程模式。4.2 显存占用排查OOM 问题的第一现场HBM 显存不够用是最常见的错误之一。昇腾框架在跑模型的时候如果显存分配失败通常会给出明确报错但有时候报错信息被上层包装得乱七八糟比如显示Memory allocation failed而没有具体提示这时候直接到npu-smi info里看 HBM 总容量和已用容量一眼就能判断是不是显存爆炸。举个例子我的 HBM 是 32GB某次测试推理服务发现所有请求都报错光看日志死活找不到原因。执行npu-smi info -t proc -i 0 -c 0之后发现问题很清晰有一个残留的 python3 进程占了 24GB 显存没释放新的服务根本申请不到空间。用kill -9 123456把残留进程清掉服务立刻恢复。这个场景在多人共用服务器时尤其常见别人跑完任务没有正常退出进程挂在后台持续占用显存后来的人在不知情的情况下疯狂踩坑。清理紧张显存的思路我建议分两步走第一步先找到占用最高的进程确认是否还有价值第二步再选择优雅退出还是强制清理。如果进程是你自己的优先在代码里加上正常退出逻辑比如使用torch_npu或相关框架时确保session正确 close如果是别人的残留进程需要先通过ps -ef | grep 123456确认归属再决定是否联系对方还是直接清理避免误杀正在跑的训练任务。4.3 结合 ps 和 top 做集成排查npu-smi 只能看到进程号和显存占用但它回答不了这个进程的 CPU 占用高不高这个进程是谁启动的这类问题。所以我会把 npu-smi 和系统命令结合起来做交叉确认。典型的做法是用ps -ef | grep [PID]查询进程的启动命令和归属用户再用top -p [PID]观察该进程的系统资源占用。如果是多进程并行训练pstree -p [PID]可以展示这个进程派生了哪些子进程方便理清任务的整体结构。举一个多人共用服务器的实际排查案例。服务器上挂了 4 个训练任务其中一个明显变慢但 AI Core 占用只有 20%。我用npu-smi info -t proc查出所有进程的显存占用再用ps -ef确认其中一个进程来自另一个部门的同事他启动了一个大数据集预处理任务把 CPU 和磁盘 IO 全部占满训练任务虽然抢到了 NPU 算力但数据供给跟不上整体表现为卡在数据加载环节。这个问题的根因在系统层面单看 NPU 监控完全找不到答案。所以我的建议是把 NPU 监控当作整个服务器监控的一个环节而不是唯一环节。5. 常见问题排查与实战速查表5.1 Health 状态异常排查Health字段显示非OK是我最不愿意看到的它意味着设备层面已经检测到问题。实际出现过的状态有Warning和Error两种。前者一般对应温度偏高、电压不稳等情况是软性预警后者则对应硬件故障比如芯片通信异常、HBM 校验出错等严重问题。遇到 Health 异常第一步不要慌赶紧收集现场信息。用npu-smi info -t log -i 0 -c 0查看设备日志路径昇腾驱动一般会把日志写到/var/log/npu/或者/home/data/log/下。重点看slog目录下的驱动日志和plog目录下的进程日志里面有详细的错误码和上下文信息。如果日志看不懂最直接的办法是联系设备供应商或者华为的技术支持提供npu-smi info的输出和日志压缩包。千万不要在不确定的情况下直接重启设备有时候重启反而会丢失关键的现场日志。如果问题只是温度导致的 Warning把负载降下来、温度恢复正常Health 通常会自动回到OK。5.2 npu-smi 命令执行报错的常见原因npu-smi 报错本身也是排查对象。最容易遇到的错误是命令找不到也就是command not found。出现这个情况大概率是环境变量没配好或者驱动没装完全。昇腾的驱动工具有时候不会自动加入全局 PATH需要手动指定绝对路径/usr/local/Ascend/driver/tools/npu-smi info如果还是不行检查驱动是否正常加载用npu-smi info -t common -i 0 -c 0看设备信息是否能够正常上报。还有一个高发问题是权限不足。普通用户执行npu-smi某些 set 操作时会报Permission denied例如设置功耗阈值、复位设备、更新固件等。这些操作需要 root 权限用sudo前缀跑一下就好了。我自己的建议是给运维账号配置好必要的权限组让日常巡检任务能通过普通的只读命令完成而把写操作类命令严格限制在管理员权限内避免误操作。5.3 监控速查表为了日常使用方便我把自己常用的命令整理成了一张表粘贴到服务器上的帮助文档里团队成员都可以直接查监控需求推荐命令关键字段查看所有NPU概况npu-smi infoHealth, Power, Temp, AICore, HBM查看指定芯片温度npu-smi info -t temp -i 0 -c 0Temp查看AI Core利用率npu-smi info -t usages -i 0 -c 0AICore查看HBM显存占用npu-smi info -t memory -i 0 -c 0HBM, Memory查看功耗npu-smi info -t power -i 0 -c 0Power查看设备进程npu-smi info -t proc -i 0 -c 0PID, Memory, AICore查看设备基础信息npu-smi info -t common -i 0 -c 0型号, 固件, 总线查看单板与风扇信息npu-smi info -t board -i 0 -c 0单板状态, 风扇转速查看日志路径npu-smi info -t log -i 0 -c 0日志目录另外还有一个细节-t后面接不同参数表示查询不同类型的信息在旧版本里部分参数可能不兼容遇到Unsupported报错时先确认一下工具版本不一定是你命令敲错了。6. 进阶玩法用 npu-smi 写一个轻量监控脚本6.1 巡检脚本设计思路前面讲的都是手动执行命令实际运维中我更建议把状态采集自动化。没必要上一套重量级的监控平台比如 Prometheus Grafana刚开始完全可以用 shell 写一个十分钟级别的巡检脚本把 NPU 状态定时记录到日志文件里一旦温度或者显存超过阈值就往指定渠道发送告警。脚本设计的核心是解析npu-smi info的文本输出。因为不同版本的输出排版有差异最保守的做法是用grep和awk按关键字抓数据。比如某次任务里我想抓取每个芯片的温度和功耗就写了这样一段轮询逻辑#!/bin/bash # 简单的 NPU 状态巡检脚本记录温度、功耗、显存 log_file/var/log/npu_monitor.log THRESHOLD_TEMP85 while true do for device_id in 0 1 2 3 4 5 6 7 do # 通过 -t temp 查询温度抓取实际读数 temp_info$(npu-smi info -t temp -i $device_id -c 0 2/dev/null | grep Chip Temperature | awk {print $NF}) # 通过 -t power 查询功耗 power_info$(npu-smi info -t power -i $device_id -c 0 2/dev/null | grep Power | awk {print $NF}) echo $(date %Y-%m-%d %H:%M:%S) device_$device_id temp${temp_info} power${power_info} $log_file # 简单告警判断 if [ -n $temp_info ] [ $temp_info -gt $THRESHOLD_TEMP ]; then echo $(date %Y-%m-%d %H:%M:%S) WARNING: device_$device_id temp too high: ${temp_info} $log_file fi done sleep 600 done实际执行时要根据你设备管理权限决定脚本放在哪、用哪个用户跑、日志写到哪里。这套脚本虽然简单但足以支撑一周甚至一个月的硬件状态回溯我用它在业务报障的时候快速定位过好几次非模型层面的基础设施问题。6.2 从命令行到平台化监控的平滑过渡当服务器数量多了shell 脚本就会显得很单薄。昇腾生态本身提供了一些被集成能力比如通过管理面接口上报指标或者配合 Prometheus 生态做指标采集。但我个人的经验是先从小处着手把你最关心的温度、显存、功耗、AI Core 四个指标通过脚本记录起来运行两周形成基线数据。有了基线你才能知道这台机器的正常温度是多少、波动范围多大后续再做阈值告警准确性会高很多。不要一上来就追求可视化大屏。真正排查问题的时候一个能跑、能存、能告警的脚本有时候比一个漂亮的面板更实用。等团队规模到需要多人同时监控设备的时候再考虑迁移到平台化方案把npu-smi info的原始输出作为数据源接入统一监控这样底层还是同一个数据源上层能力逐步叠加过渡起来非常平滑。我在实际使用中发现很多看似离奇的训练变慢、推理超时问题追到根上都是硬件状态没看到位。真心建议每一个用昇腾设备的人都把 npu-smi 用熟特别是温度曲线和显存占用这两块关键时候能救大命。最后再分享一个小技巧养成每次跑大任务前先敲一次npu-smi info存个当前状态快照的习惯任务结束之后再拍一张对比两张图之间的差异往往就是问题藏身的地方。