昇腾NPU监控实战：npu-smi命令详解与性能调优指南

1. 昇腾NPU监控的底层逻辑与npu-smi定位1.1 为什么NPU监控不能照搬GPU那套经验刚接触昇腾NPU的兄弟十有八九是从GPU阵营转过来的。习惯性地敲个nvidia-smi结果发现根本不认。昇腾NPU有自己的管理工具链核心命令就是npu-smi。这不是简单的命令替换问题而是整个监控思路需要重新建立。昇腾NPU的硬件架构和GPU有本质区别。它采用达芬奇架构核心计算单元是AI Core、Vector Core和Cube Unit的组合。npu-smi info输出的信息维度跟nvidia-smi完全不是一回事。GPU监控主要看显存占用、GPU利用率、温度、功耗这几个维度但昇腾NPU需要关注的是AI Core利用率、HBM使用情况、片内内存占用、以及各芯片之间的互联状态。我踩过的第一个坑就是用GPU的思维去理解NPU的监控数据。比如GPU的显存概念在昇腾上对应的是HBM高带宽内存但昇腾还有一层片内缓存L2 Buffer这个在GPU上是不太需要单独关注的。如果你只看HBM占用率可能会忽略片内缓存的瓶颈导致模型推理性能上不去还找不到原因。npu-smi这个工具本身是驱动包的一部分安装完NPU驱动后会自动带上。它的定位类似于GPU生态里的nvidia-smi但功能更偏向于设备管理和状态查询不像nvidia-smi那样直接暴露那么多性能计数器。想要做深度性能分析还需要配合msprof等工具一起用。1.2 npu-smi info到底能告诉你什么npu-smi info是最基础也是最常用的命令没有之一。它的输出信息量很大但很多人只扫一眼利用率就走了浪费了大量有价值的诊断信息。这个命令的核心输出分为几个板块首先是NPU设备的整体概况包括设备编号、健康状态、功耗、温度然后是每个芯片的详细信息包括AI Core利用率、HBM使用量、HBM带宽利用率最后还有进程级别的信息能看到哪些进程占用了NPU资源。我实测下来npu-smi info最实用的场景有三个第一是快速判断NPU是否被正常识别和驱动加载第二是排查模型推理时的性能瓶颈比如AI Core利用率低但HBM带宽跑满了说明是内存带宽瓶颈而不是算力瓶颈第三是监控多卡训练时的负载均衡情况看各芯片的利用率是否均匀。注意npu-smi info的输出格式在不同版本的CANNCompute Architecture for Neural Networks工具包中会有差异。CANN 5.0和CANN 6.0的输出字段名称和排列方式就不太一样。建议先确认自己的CANN版本再对照官方文档看字段含义。1.3 监控体系的全景认知单靠npu-smi info做监控是不够的。完整的昇腾NPU监控体系应该包含三个层次第一层是设备级监控用npu-smi系列命令完成关注的是硬件健康状态、温度、功耗、利用率这些宏观指标。这一层的目的是确保硬件在正常工作范围内没有过热、掉卡、驱动异常等问题。第二层是进程级监控需要结合npu-smi info -t proc或者npu-smi info -t proc-mem来查看具体进程的资源占用。这一层解决的是谁在用什么资源的问题多用户共享NPU服务器时特别重要。第三层是算子级和模型级性能分析这就需要上msprof工具了。msprof能采集到每个算子的执行时间、AI Core的指令流水、内存搬运的详细数据。这一层是性能调优的核心战场但前提是第一层和第二层没有明显异常。很多兄弟一上来就想用msprof做深度调优结果发现基础监控都没做对采集出来的数据根本没法分析。我的建议是先把npu-smi info用熟确保设备状态正常、资源分配合理再往深了走。2. npu-smi info命令的完整拆解与实操2.1 基础用法与输出字段逐项解读先看最基本的用法npu-smi info这个命令不带任何参数时输出的是所有NPU设备的概览信息。输出内容大致长这样以CANN 6.0为例------------------------------------------------------------------------------------------------ | npu-smi 23.0.rc1 Version: 23.0.rc1 | ---------------------------------------------------------------------------------------------- | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)| | Chip | Bus-Id | AICore(%) Memory-Usage(MB) HBM-Usage(MB) | | 0 910B | OK | 72.5 45 0 / 0 | | 0 | 0000:81:00.0 | 0 0 / 0 1024 / 65536 | ----------------------------------------------------------------------------------------------逐项拆解一下关键字段Health设备健康状态。正常是OK如果出现Warning或Alarm就要立刻排查。常见的不健康状态包括温度过高、功耗超限、HBM ECC错误等。Power(W)当前功耗。910B的TDP一般在300W-350W之间具体取决于型号。如果功耗长期贴着TDP跑说明计算负载很重需要关注散热。Temp(C)芯片温度。正常范围在30-80摄氏度之间。超过85度就要警惕了长期高温会触发降频保护性能直接打折。AICore(%)AI Core利用率。这是最核心的性能指标。但要注意这个利用率是瞬时值不是平均值。单次采样可能不准需要多次采样取平均。Memory-Usage(MB)片内内存使用量。这个指的是DDR内存不是HBM。昇腾NPU的片内DDR主要用于存放模型权重和中间计算结果。HBM-Usage(MB)HBM使用量。HBM是NPU的主内存容量大、带宽高。模型推理时输入数据、中间激活值、输出结果都放在HBM里。实操心得npu-smi info默认只输出一次快照。如果你想持续监控可以用watch -n 1 npu-smi info每秒刷新一次。但注意频繁调用npu-smi本身会消耗少量CPU资源在高负载场景下建议把刷新间隔调到2-5秒。2.2 进阶参数按需过滤与详细模式npu-smi info支持不少参数用好了能大幅提升排查效率。查看指定设备npu-smi info -i 0只查看0号NPU设备的信息。多卡服务器上特别有用不用在一堆输出里找目标设备。查看进程级信息npu-smi info -t proc这个命令会列出所有占用NPU资源的进程包括进程ID、进程名、使用的设备编号、占用的内存量。排查谁把NPU占满了这种问题时这个命令是首选。查看进程内存详情npu-smi info -t proc-mem -i 0查看0号设备上各进程的内存占用明细。输出会区分HBM占用和片内DDR占用对于定位内存泄漏问题很有帮助。查看设备拓扑npu-smi info -t topo这个命令展示多卡之间的互联拓扑结构。昇腾NPU之间通过HCCSHuawei Cache Coherent System互联拓扑信息能帮你判断多卡通信是否走了最优路径。如果发现跨卡通信走了PCIe而不是HCCS那多卡训练的通信瓶颈就找到了。查看ECC错误统计npu-smi info -t ecc -i 0HBM的ECC错误计数。如果ECC错误数持续增长说明HBM硬件可能有问题需要尽快报修。这个指标在长时间训练任务中要定期检查。查看固件版本npu-smi info -t version -i 0输出驱动版本、固件版本、CANN版本等信息。排查兼容性问题时第一步就是确认版本信息。2.3 输出信息的实时监控与日志留存npu-smi info默认是一次性输出但在实际运维中我们需要的是持续监控和历史数据。方案一watch命令轮询watch -n 2 -d npu-smi info-n 2表示每2秒刷新一次-d表示高亮显示变化的部分。这个方案简单直接适合临时观察。方案二脚本采集写入日志#!/bin/bash LOG_FILE/var/log/npu_monitor.log INTERVAL5 while true; do echo $(date %Y-%m-%d %H:%M:%S) $LOG_FILE npu-smi info $LOG_FILE echo $LOG_FILE sleep $INTERVAL done这个脚本每5秒采集一次追加写入日志文件。适合长时间运行的任务事后可以分析性能趋势。方案三结合Prometheus做可视化监控如果你们团队有Prometheus监控体系可以写一个exporter把npu-smi info的输出解析成metrics格式推送到Prometheus再用Grafana做可视化面板。这个方案适合生产环境能实现告警和趋势分析。我个人的经验是临时排查用方案一单机长期任务用方案二集群化部署必须上方案三。别小看日志留存很多性能问题都是事后分析日志才找到根因的。2.4 多卡环境下的批量监控技巧多卡服务器上逐卡执行npu-smi info -i N效率太低。可以用循环批量采集#!/bin/bash NPU_COUNT$(npu-smi info -l | grep Total Count | awk {print $NF}) for i in $(seq 0 $((NPU_COUNT - 1))); do echo NPU $i npu-smi info -i $i | grep -E AICore|HBM-Usage|Temp|Power done这个脚本先获取NPU总数然后逐卡采集关键指标。输出精简适合快速巡检。更进一步可以把关键指标提取成CSV格式方便导入Excel或做趋势图#!/bin/bash echo timestamp,npu_id,aicore,hbm_used,hbm_total,temp,power while true; do TIMESTAMP$(date %Y-%m-%d %H:%M:%S) npu-smi info | grep -E ^\| [0-9] | while read line; do NPU_ID$(echo $line | awk {print $2}) AICORE$(echo $line | awk {print $8}) HBM$(echo $line | awk {print $10}) TEMP$(echo $line | awk {print $6}) POWER$(echo $line | awk {print $4}) echo $TIMESTAMP,$NPU_ID,$AICORE,$HBM,$TEMP,$POWER done sleep 10 done注意不同CANN版本的输出字段位置可能不同上面的awk字段编号需要根据实际输出调整。建议先用npu-smi info | head -20确认字段位置再写脚本。3. 基于npu-smi的性能调优实战3.1 从监控数据定位性能瓶颈npu-smi info给出的数据核心用途是定位性能瓶颈。我总结了一个简单的判断逻辑现象可能瓶颈排查方向AICore利用率低HBM带宽高内存带宽瓶颈检查数据搬运是否频繁考虑算子融合AICore利用率高HBM带宽低计算瓶颈检查算子实现考虑量化或模型剪枝AICore利用率低HBM占用高但带宽低内存容量瓶颈检查是否有内存泄漏优化batch size温度和功耗正常但利用率上不去调度或通信瓶颈检查多卡通信、CPU预处理速度温度过高触发降频散热问题检查机房温度、风扇转速、散热片积灰这个表是我在实际调优中反复验证过的。举个例子之前跑一个ResNet50推理任务发现AICore利用率只有30%左右但HBM带宽跑到了80%。第一反应是内存带宽瓶颈后来用msprof一查发现是数据预处理在CPU上耗时太长NPU经常在等数据。把预处理搬到NPU上之后AICore利用率直接拉到75%以上。所以npu-smi info给的是线索不是结论。看到异常指标后要结合具体业务逻辑去分析根因。3.2 温度与功耗的联动调优昇腾NPU的温度和功耗是强相关的。功耗越高发热越大温度越高。当温度超过阈值时NPU会自动降频性能下降。npu-smi info输出的功耗和温度数据可以用来判断是否触发了降频。具体做法是在任务运行期间持续采集功耗和温度如果发现功耗突然下降而任务负载没变大概率是触发了温度保护。控制温度的手段有几个调整风扇转速部分昇腾服务器支持通过BMC调整风扇策略。把风扇转速调高散热能力增强但噪音和功耗也会增加。优化机房环境机房温度控制在22-25摄氏度比较理想。如果机房温度超过30度NPU温度很难压住。调整任务调度如果多卡同时满负载运行导致温度过高可以适当错峰调度或者降低单卡的负载强度。功耗封顶通过npu-smi set -t power-limit -i 0 -d 250可以把0号卡的功耗上限设为250W。功耗降下来温度自然就下来了但性能也会相应下降。这个参数需要根据实际散热能力和性能要求来权衡。实操心得功耗封顶是个双刃剑。我试过把910B的功耗从300W封到250W温度降了8度左右但推理吞吐量下降了约15%。如果散热条件允许不建议轻易封顶。优先解决散热问题而不是限制性能。3.3 内存与HBM的优化策略HBM是昇腾NPU最宝贵的资源之一。npu-smi info输出的HBM使用量直接反映了模型对内存的需求。优化HBM使用有几个方向减小batch size最直接的方法。batch size减半HBM占用大概能降40%左右不是严格线性关系因为还有模型权重等固定开销。使用混合精度FP16相比FP32内存占用直接减半。昇腾NPU对FP16的支持很好大部分推理场景都可以用FP16。算子融合把多个小算子融合成一个大算子减少中间结果的存储需求。CANN工具链里有自动算子融合的优化选项开启后能省不少HBM。及时释放无用内存PyTorch和MindSpore都有内存管理机制但有时候需要手动调用torch.npu.empty_cache()或类似接口来释放缓存。我遇到过一个典型问题模型训练过程中HBM占用持续增长最后OOM。用npu-smi info -t proc-mem一看发现是数据加载器的缓存没有释放。把num_workers调小、加上pin_memoryFalse之后内存增长曲线就平稳了。3.4 多卡负载均衡的监控与调整多卡训练时最怕的就是负载不均。一张卡跑满其他卡闲着整体性能被最慢的卡拖累。npu-smi info可以快速查看各卡的AICore利用率。如果发现某张卡的利用率明显低于其他卡说明负载不均衡。造成负载不均的原因通常有几个数据并行时batch分配不均如果总batch size不能被卡数整除最后几张卡分到的数据少利用率就低。解决办法是调整batch size让它能被卡数整除。模型并行时切分不合理模型并行需要把模型切分到不同卡上如果切分点选得不好某些卡的计算量会明显大于其他卡。这个需要结合模型结构仔细设计切分策略。通信瓶颈多卡之间需要同步梯度或中间结果如果通信走了低速链路等待时间就会拉长。用npu-smi info -t topo检查拓扑确保通信走了HCCS而不是PCIe。CPU预处理瓶颈如果数据预处理在CPU上做CPU核心数不够时NPU会等数据。这时候需要增加CPU核心数或者把预处理放到NPU上。我的一般做法是先用npu-smi info看各卡利用率找出异常卡然后用npu-smi info -t topo看拓扑最后结合训练框架的日志看是否有通信等待或数据加载等待。4. 常见问题排查与避坑指南4.1 npu-smi命令报错的典型场景报错一npu-smi: command not found这是最常见的问题。原因通常是驱动没装好或者环境变量没配。排查步骤确认驱动是否安装ls /usr/local/Ascend/driver/确认环境变量echo $PATH | grep Ascend如果驱动装了但命令找不到手动source环境变量source /usr/local/Ascend/driver/bin/setenv.sh报错二npu-smi info输出为空或显示No NPU found原因可能是驱动加载失败、NPU硬件故障、或者PCIe链路问题。排查步骤检查内核模块lsmod | grep drv检查PCIe设备lspci | grep -i huawei检查dmesg日志dmesg | grep -i npu如果硬件没问题尝试重新加载驱动rmmod drv modprobe drv报错三npu-smi info卡住不返回通常是NPU处于异常状态或者有进程死锁占用了NPU。排查步骤用ps aux | grep npu查看是否有僵尸进程尝试npu-smi info -t proc看是否能返回进程信息如果都卡住可能需要重启NPU设备或整机注意重启NPU设备有一定风险可能导致正在运行的任务中断。生产环境操作前务必确认没有关键任务在跑。4.2 监控数据异常时的排查思路AICore利用率始终为0如果任务在跑但AICore利用率一直是0说明任务根本没用到NPU。可能原因模型没有正确迁移到NPU上还在CPU上跑设备指定错误指定了不存在的设备编号框架版本和CANN版本不兼容HBM占用持续增长不释放典型的资源泄漏。用npu-smi info -t proc-mem定位到具体进程然后检查代码中是否有未释放的tensor或缓存。温度异常高但功耗不高可能是散热系统故障。检查风扇是否正常运转、散热片是否积灰、机房温度是否过高。ECC错误计数增长HBM硬件可能有问题。如果错误数增长很快建议尽快报修。如果只是偶尔增长一两个可以继续观察。4.3 性能调优的常见误区误区一只看AICore利用率忽略其他指标AICore利用率高不代表性能好。如果HBM带宽跑满了AICore再高也没用因为数据供不上。要综合看多个指标。误区二盲目增大batch sizebatch size增大确实能提高AICore利用率但HBM占用也会增加。如果HBM不够反而会触发OOM或频繁的内存交换性能更差。误区三忽略CPU和IO的影响NPU再快如果CPU预处理慢、数据加载慢整体性能还是上不去。监控NPU的同时也要关注CPU利用率和磁盘IO。误区四不做基线测试就直接调优调优前先跑一个基线记录各项指标。没有基线你根本不知道调优有没有效果。4.4 常见问题速查表问题现象可能原因快速排查命令解决方案npu-smi命令找不到驱动未安装或环境变量未配置ls /usr/local/Ascend/driver/安装驱动并source环境变量显示No NPU found驱动加载失败或硬件故障lspci | grep -i huawei重新加载驱动或检查硬件AICore利用率低数据瓶颈或调度问题npu-smi info -t proc优化数据预处理或调整batch sizeHBM占用过高batch size过大或内存泄漏npu-smi info -t proc-mem减小batch size或修复泄漏温度过高散热不良或功耗过高npu-smi info看Temp字段改善散热或设置功耗封顶多卡负载不均数据分配不均或通信瓶颈npu-smi info -t topo调整batch分配或优化通信ECC错误增长HBM硬件问题npu-smi info -t ecc观察或报修命令卡住不返回进程死锁或设备异常ps aux | grep npu清理僵尸进程或重启设备5. 监控体系的工程化落地5.1 从手动命令到自动化监控手动敲npu-smi info只适合临时排查。生产环境需要自动化监控体系。我的做法是分三步走第一步采集层。写一个Python脚本定期调用npu-smi info解析输出提取关键指标写入时序数据库如InfluxDB或推送到Prometheus。第二步展示层。用Grafana做可视化面板展示各卡的AICore利用率、HBM使用率、温度、功耗等指标的历史趋势。第三步告警层。设置阈值告警比如温度超过80度、AICore利用率持续低于10%、HBM使用率超过90%等触发告警通知。这套体系搭起来之后NPU的运行状态一目了然不用再手动敲命令了。5.2 日志留存与事后分析性能问题往往不是实时发现的而是事后分析日志才找到根因。所以日志留存很重要。我建议至少保留7天的监控日志关键任务保留30天。日志格式要结构化方便后续用脚本分析。一个简单的日志分析脚本示例import re from collections import defaultdict def parse_npu_log(log_file): metrics defaultdict(list) with open(log_file, r) as f: for line in f: match re.search(rNPU (\d).*AICore\(%\)\s(\d).*HBM-Usage\(MB\)\s(\d)/(\d), line) if match: npu_id int(match.group(1)) aicore int(match.group(2)) hbm_used int(match.group(3)) hbm_total int(match.group(4)) metrics[npu_id].append({ aicore: aicore, hbm_used: hbm_used, hbm_total: hbm_total }) return metrics def analyze_metrics(metrics): for npu_id, data in metrics.items(): avg_aicore sum(d[aicore] for d in data) / len(data) max_hbm max(d[hbm_used] for d in data) print(fNPU {npu_id}: 平均AICore利用率{avg_aicore:.1f}%, 峰值HBM使用{max_hbm}MB) if __name__ __main__: metrics parse_npu_log(/var/log/npu_monitor.log) analyze_metrics(metrics)这个脚本能快速算出各卡的平均利用率和峰值内存使用适合做初步分析。5.3 多机多卡场景的监控挑战单机多卡用npu-smi就够了但多机多卡场景下每台机器都要单独登录去查效率太低。解决方案是搭建一个中心化的监控平台。每台机器上跑一个采集agent把数据汇总到中心服务器。中心服务器统一做展示和告警。这个方案的难点在于不同机器的CANN版本可能不同npu-smi输出格式有差异解析脚本需要做兼容。我的做法是抽象出一个解析层根据版本号选择不同的解析规则。另外多机场景下网络通信的监控也很重要。NPU之间的跨机通信走的是RoCE或InfiniBand如果网络有问题多机训练的扩展效率会大打折扣。这时候需要结合网络监控工具一起分析。5.4 监控指标的正常范围参考最后给出一份我实际运维中总结的指标正常范围参考供大家对照指标正常范围警告范围危险范围温度30-75°C75-85°C85°C功耗80% TDP80-95% TDP95% TDPAICore利用率60-90%30-60%或90%10%HBM使用率50-85%85-95%95%ECC错误0偶尔增长持续快速增长这些范围不是绝对的不同型号的NPU、不同的业务场景会有差异。但作为一个快速判断的参考还是很有用的。我在实际运维中最大的体会是监控不是目的调优才是。npu-smi info给的是数据怎么解读数据、怎么根据数据做决策才是真正考验功力的地方。多跑任务、多观察、多记录慢慢就能建立起对NPU运行状态的直觉。