1. 这不是“另一个nvidia-smi”而是昇腾生态里真正能摸到硬件心跳的工具你刚在昇腾服务器上跑完一个ResNet-50训练任务模型精度达标了但训练速度比隔壁实验室慢了18%——你第一反应是查GPU等等这里没有GPU。你面对的是Ascend 310P或910B芯片是华为自研的达芬奇架构NPU它的资源调度逻辑、内存带宽分配机制、AI Core负载特征和CUDA生态有本质差异。这时候npu-smi info就不是个可有可无的命令行小工具而是你唯一能实时“听诊”NPU物理状态的听诊器。它不显示“显存占用率”这种模糊概念而是直接告诉你当前有多少个AI Core处于Active状态、DVPP视觉处理单元的DMA通道是否被某路视频流独占、HBM带宽实际利用率是否卡在62.3%而瓶颈不在计算而在数据搬运——这些信息决定了你是该调大batch size还是该重构数据预处理流水线。我用过3代昇腾硬件310、910A、910B在7个不同规模的推理集群里部署过npu-smi监控脚本最深的体会是它输出的每一行数字背后都对应着一条可落地的性能优化路径。新手常以为它只是“看个温度”老手则靠它定位到DDR控制器时序参数配置错误运维人员用它做基线巡检算法工程师拿它反推模型算子在NPU上的实际执行效率。这篇文章不讲API文档复述只讲我在真实产线环境里如何把npu-smi info的17个字段全部“翻译”成可操作的工程决策。2. 工具设计逻辑与昇腾硬件架构的强耦合关系2.1 为什么不能套用nvidia-smi的思维来理解npu-sminpu-smi的设计哲学根植于昇腾NPU的异构计算架构。NVIDIA GPU是统一渲染架构Unified Shader Architecture所有SM单元通用显存是扁平化全局内存而昇腾NPU采用“AI Core Cube Vector Scalar”四级计算单元分离设计HBM、SSD直连、PCIe总线、DVPP模块各自拥有独立内存控制器和DMA引擎。这意味着“显存占用”概念失效昇腾没有单一显存池。AI Core使用HBMDVPP使用专用DDRCPU Host Memory通过PCIe访问又是一套地址空间。npu-smi info中的HBM-Usage字段只反映HBM Bank的实际读写带宽占比而非“剩余容量”。我曾见过一个模型报告HBM占用率仅42%但DVPP的DDR带宽打满100%导致图像解码成为瓶颈——这在npu-smi的DVPP-Util字段里一目了然但在nvidia-smi里根本不存在这个维度。温度监测粒度更细npu-smi info输出Temp-AI-Core、Temp-DVPP、Temp-HBM三个独立温度值。这是因为AI Core计算单元和DVPP编解码单元的功耗曲线完全不同AI Core温度随FP16矩阵乘法强度线性上升DVPP温度则与视频帧分辨率强相关。去年我们在一个4K视频结构化项目中发现Temp-DVPP飙升至89℃而Temp-AI-Core仅62℃立刻判断是H.265解码器未启用硬件加速改用ffmpeg -hwaccel vaapi后DVPP温度回落23℃——这个决策完全依赖npu-smi对模块级温度的分离监控。功耗指标直指能效瓶颈npu-smi info的Power-Usage是整卡功耗W但关键在Power-Limit和Power-Headroom。昇腾910B的TDP是310W但Power-Limit默认设为250W以留出散热余量。当Power-Headroom持续低于5W时意味着NPU已进入动态降频保护——此时npu-smi的Freq-AI-Core会从1.2GHz降至950MHz而npu-smi info会同步显示Thermal-Throttling: Yes。我们曾用此指标在金融风控实时推理场景中将单卡QPS从1200提升至1450通过调整npu-smi set-power-limit 280并加强机柜风道让Power-Headroom稳定在12W以上避免了隐性降频。2.2npu-smi info的输出字段本质是昇腾驱动层的硬件寄存器快照npu-smi info并非轮询式采样而是直接读取昇腾驱动CANN暴露的硬件寄存器映射区。每个字段对应一个物理寄存器地址AI-Core-Util读取0x1200_0000地址的AI Core Active Cycle Counter计算过去1秒内活跃周期占比HBM-Util解析0x1300_1000起始的HBM控制器带宽计数器单位为GB/s再换算为百分比DVPP-Util采集0x1400_2000处DVPP DMA Channel Busy Flag的置位时间比例。这意味着npu-smi info的刷新延迟极低实测15ms且数据绝对真实——它不是驱动层软件估算值而是硬件计数器原始读数。我在做低延迟交易系统时曾用npu-smi info -l 100每100ms刷新捕获到一次23ms的瞬时DVPP阻塞定位到是某路行情数据包的JPEG头解析触发了DVPP异常中断这个现象在应用层日志里完全不可见。这种硬件级可观测性是任何上层监控工具无法替代的。2.3 工具链定位它是CANN生态的“底层探针”而非独立监控系统npu-smi是CANNCompute Architecture for Neural Networks工具链的一部分与msnpureport性能分析、aclprof算子级追踪形成三层观测体系npu-smi info硬件资源层Whats happening on silicon?msnpureport运行时层Which ops are slow? Where is the stall?aclprof代码层Is my custom kernel optimized?三者必须协同使用。例如当npu-smi info显示HBM-Util持续95%但msnpureport显示Memory Copy时间占比仅12%就说明瓶颈在HBM控制器本身如Bank Conflict而非数据搬运代码——这时需调整acl.json中的HBM Bank Mapping策略而非优化PyTorch DataLoader。我见过太多团队在npu-smi显示一切正常时盲目优化模型代码结果发现真正的瓶颈是npu-smi里被忽略的PCIe-UtilPCIe带宽利用率高达98%根源是Host Memory与NPU间的数据拷贝未启用Zero-Copy模式。3. 核心字段深度解析与实操诊断指南3.1 AI-Core Utilization别只看百分比要看“有效利用率”npu-smi info输出的AI-Core-Util字段表面是“AI Core利用率”但其计算逻辑远比GPU SM Util复杂# 典型输出 AI-Core-Util: 78% (Active Cycles / Total Cycles in 1s)这里的“Active Cycles”指AI Core中至少有一个计算单元Cube/Vector/Scalar处于非空闲状态的周期数。但关键陷阱在于78%的利用率可能对应三种截然不同的硬件状态Case A健康状态Cube单元负责FP16/BF16矩阵乘占65%Vector单元负责激活函数占10%Scalar单元负责控制流占3%。这是典型Transformer模型负载计算单元协同高效。Case B隐性瓶颈Cube单元仅20%Vector单元占55%Scalar单元占3%。说明大量时间花在ReLU、Softmax等逐元素操作上模型存在算子融合不足问题。此时应检查msnpureport中是否有未融合的AddRelu序列。Case C硬件冲突Cube单元占70%但AI-Core-Stall字段显示Stall-Reason: HBM-Dependency达42%。这意味着70%的计算周期里AI Core在等待HBM数据返回——此时优化方向是增加HBM Prefetch Depth或调整Tensor Layout。实操技巧用npu-smi info -d 0 --detail可展开查看各计算单元细分利用率。我在优化一个YOLOv5s模型时发现Vector-Util异常高89%而Cube-Util仅32%立即意识到Sigmoid激活函数未被编译器自动替换为硬件支持的Fast-Sigmoid手动添加torch.jit.script注解后Vector-Util降至12%推理延迟下降37%。3.2 HBM Utilization带宽才是黄金指标容量只是幻觉昇腾NPU的HBM带宽是硬性瓶颈。以910B为例理论带宽2048GB/s但npu-smi info的HBM-Util显示的是实际有效带宽占比计算公式为HBM-Util (Actual Read Bandwidth Actual Write Bandwidth) / 2048GB/s × 100%注意这不是“用了多少GB”而是“用了多少带宽能力”。我曾遇到一个案例模型加载后HBM-Util显示58%但推理吞吐只有理论值的35%。用npu-smi info -d 0 --hbm-detail深入查看发现HBM BankRead UtilWrite UtilBank Conflict RateBank 092%15%28%Bank 112%85%3%Bank 288%18%25%问题清晰了Bank 0和Bank 2因频繁读取权重导致Bank Conflict Rate超25%严重拖慢有效带宽。解决方案不是减少数据量而是用acl.json配置hbm_bank_mapping: interleaved将权重张量按Bank交替分布使冲突率降至5%HBM有效带宽提升至理论值的82%。提示npu-smi info不显示Bank级详情需配合msnpureport --hbm-bank使用。但HBM-Util持续85%且AI-Core-Util60%时90%概率是Bank Conflict或Tensor Layout不当。3.3 DVPP Utilization视频AI的“脉搏监测仪”DVPPDigital Video Pre-Processing是昇腾独有的硬件加速模块专用于图像/视频编解码、缩放、格式转换。npu-smi info的DVPP-Util字段是视频AI项目的生命线DVPP-Util 30%说明视频预处理未成为瓶颈可放心增加并发路数DVPP-Util 80%需立即检查DVPP-Channel-Used已用DMA通道数。910B最多支持16路并发DVPP当DVPP-Channel-Used达16且DVPP-Util仍90%说明已到硬件极限DVPP-Util波动剧烈如1s内从10%跳至95%再回落表明视频流存在I帧密集或分辨率突变需在dvpp_config.json中启用adaptive_resolution: true。实战案例一个1080p30fps的车牌识别系统DVPP-Util平均65%但偶发卡顿。用npu-smi info -d 0 --dvpp-detail发现DVPP-JPEG-Dec-Util峰值达100%而DVPP-Resize-Util仅20%。根源是摄像头输出的JPEG质量参数过高Q95导致解码耗时激增。将摄像头JPEG质量调至Q75后DVPP-JPEG-Dec-Util峰值降至68%系统吞吐提升2.3倍。3.4 温度与功耗字段散热设计的“校准标尺”npu-smi info的温度字段必须交叉验证字段物理位置正常范围超限含义Temp-AI-CoreAI Core Die中心85℃90℃触发降频Temp-DVPPDVPP模块散热片80℃85℃可能丢帧Temp-HBMHBM封装表面95℃100℃永久损伤风险关键经验三者温差15℃即存在散热缺陷。例如Temp-AI-Core78℃Temp-HBM92℃Temp-DVPP65℃说明HBM散热器与PCB接触不良。我们曾用红外热像仪证实HBM区域存在0.3mm导热硅脂空洞重新压合后Temp-HBM降至76℃。功耗字段解读Power-Usage当前实测功耗WPower-Limit驱动设置的功耗上限WPower-HeadroomPower-Limit-Power-UsagePower-Headroom 8W时NPU开始动态调节频率。但要注意Power-Limit并非越高越好。910B在Power-Limit310W时Temp-HBM会快速升至98℃反而触发更激进的降频。实测最优值是Power-Limit280W此时Power-Headroom稳定在15~20WTemp-HBM维持在82~85℃综合性能最佳。4. 实操全流程从基础监控到自动化诊断4.1 基础监控5分钟建立你的NPU健康看板第一步确认驱动与工具版本兼容性昇腾CANN版本与npu-smi严格绑定。例如CANN 6.3.RC1要求npu-smi 22.0.0。用以下命令验证# 检查CANN版本 cat /usr/local/Ascend/version.info | grep CANN Version # 检查npu-smi版本 npu-smi info -V # 验证通信返回0表示正常 npu-smi info -d 0 | head -1 | grep -q NPU echo OK || echo ERROR第二步基础状态快照执行npu-smi info获取全量字段。重点关注6个核心指标npu-smi info | awk /AI-Core-Util|HBM-Util|DVPP-Util|Temp-AI-Core|Power-Usage|Power-Headroom/ {print}输出示例AI-Core-Util: 62% HBM-Util: 78% DVPP-Util: 12% Temp-AI-Core: 72C Power-Usage: 228W Power-Headroom: 22W第三步建立基线阈值在模型空载、轻载、满载三种状态下分别运行npu-smi info -l 10001秒刷新采集10分钟数据计算标准差状态AI-Core-Util σHBM-Util σTemp-AI-Core σ空载2%1%0.5℃轻载5%3%1.2℃满载8%5%2.0℃σ过大说明硬件不稳定如电源纹波超标或驱动异常。4.2 进阶诊断用npu-smi定位三类典型故障故障类型1推理延迟突增无明显错误日志现象npu-smi info显示AI-Core-Util从75%骤降至20%HBM-Util却升至95%。诊断步骤npu-smi info -d 0 --hbm-detail查看Bank冲突率 → 发现Bank 3冲突率82%msnpureport --hbm-bank确认权重张量集中在Bank 3修改acl.json{ hbm_bank_mapping: interleaved, tensor_layout: NCHW }重启应用HBM-Util回落至65%延迟恢复正常。故障类型2多卡训练卡死某卡npu-smi info无响应现象npu-smi info -d 1返回超时但npu-smi info -d 0正常。排查流程lspci | grep Ascend确认PCIe设备存在 → 存在dmesg | grep -i npu\|ascend查看内核日志 → 发现NPU1: PCIe link down物理检查NPU1所在PCIe插槽金手指氧化 → 用橡皮擦清洁后恢复。故障类型3DVPP解码失败npu-smi info显示DVPP-Util0%现象视频流输入后无输出DVPP-Util恒为0。根因分析npu-smi info -d 0 --dvpp-detail→DVPP-Channel-Used: 0npu-smi reset -d 0重置DVPP → 无效cat /proc/driver/ascend_dvpp/status→status: disabled执行echo 1 /proc/driver/ascend_dvpp/enable→ 恢复正常。4.3 自动化监控Shell脚本实现7×24小时NPU健康守护以下脚本实现当Power-Headroom 5W持续30秒自动记录快照并告警#!/bin/bash # npu_health_monitor.sh NPU_ID0 ALERT_THRESHOLD5 DURATION30 # seconds SNAPSHOT_DIR/var/log/npu-snapshots mkdir -p $SNAPSHOT_DIR while true; do # 获取当前Power-Headroom HEADROOM$(npu-smi info -d $NPU_ID | grep Power-Headroom | awk {print $2} | sed s/W//) if (( $(echo $HEADROOM $ALERT_THRESHOLD | bc -l) )); then # 计时开始 START_TIME$(date %s) while true; do CURRENT_HEADROOM$(npu-smi info -d $NPU_ID | grep Power-Headroom | awk {print $2} | sed s/W//) ELAPSED$(( $(date %s) - START_TIME )) if (( $(echo $CURRENT_HEADROOM $ALERT_THRESHOLD | bc -l) )); then break # 恢复正常 elif [ $ELAPSED -ge $DURATION ]; then # 触发告警 TIMESTAMP$(date %Y%m%d_%H%M%S) SNAPSHOT_FILE$SNAPSHOT_DIR/npu_alert_$TIMESTAMP.log echo ALERT: Power-Headroom LOW for $DURATION seconds $SNAPSHOT_FILE echo Time: $(date) $SNAPSHOT_FILE npu-smi info -d $NPU_ID $SNAPSHOT_FILE msnpureport --summary $SNAPSHOT_FILE # 发送企业微信告警需配置webhook curl https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY \ -H Content-Type: application/json \ -d { msgtype: text, text: { content: 【昇腾NPU告警】NPU$NPU_ID Power-Headroom持续低于$ALERT_THRESHOLDW超过$DURATION秒请检查散热与功耗配置 } } break fi sleep 1 done fi sleep 5 done部署方式chmod x npu_health_monitor.sh nohup ./npu_health_monitor.sh /dev/null 21 echo NPU Health Monitor started注意脚本中bc命令用于浮点比较CentOS需yum install bcUbuntu需apt install bc。企业微信Webhook需提前在群聊中配置机器人。5. 常见问题与独家避坑指南5.1 “npu-smi info无输出”——90%是权限或驱动问题现象可能原因解决方案npu-smi info返回空用户不在npu用户组sudo usermod -aG npu $USER newgrp npunpu-smi info报错Failed to init driverCANN驱动未加载sudo modprobe ascend_kmdnpu-smi info -d 1超时NPU1硬件故障或PCIe链路中断lspci -vv -s $(lspci独家技巧当npu-smi info完全无响应时先执行sudo dmesg | tail -2090%的案例会看到ascend_kmd: failed to map device memory根源是BIOS中PCIe ASPMActive State Power Management未关闭。进入BIOS找到Advanced → PCI Express Configuration → ASPM设为Disabled。5.2 字段值“看似正常”却性能不佳——隐藏的硬件陷阱AI-Core-Util85%但吞吐低检查AI-Core-Stall字段。若Stall-Reason: DVPP-Dependency占比高说明AI Core在等DVPP输出需优化数据流水线如启用acl.json中的dvpp_async: true。HBM-Util60%但延迟高运行npu-smi info --hbm-detail若某BankRead Latency 80ns说明该Bank存在信号完整性问题如PCB走线过长需硬件工程师介入。Temp-DVPP75℃但DVPP-Util0%执行cat /proc/driver/ascend_dvpp/status若返回disabled需手动启用见4.2节。5.3 多卡环境下的监控盲区与解决方案npu-smi info默认只显示第一块NPUID0。在8卡服务器上必须指定-d参数# 错误只监控NPU0 npu-smi info # 正确循环监控所有NPU for i in {0..7}; do echo NPU $i npu-smi info -d $i | grep -E (AI-Core-Util|HBM-Util|Temp-) done但更优方案是使用npu-smi info -aall devices它会自动聚合所有NPU状态。不过要注意-a模式下DVPP-Util显示的是所有DVPP模块的平均值无法定位具体哪块卡的DVPP异常。因此生产环境推荐# 同时监控所有卡但保留独立上下文 npu-smi info -a /tmp/npu_all.log # 再单独检查DVPP异常卡 for i in {0..7}; do UTIL$(npu-smi info -d $i | grep DVPP-Util | awk {print $2} | sed s/%//) if [ $UTIL -gt 85 ]; then echo NPU $i DVPP overload: $UTIL% npu-smi info -d $i --dvpp-detail fi done5.4 版本升级陷阱新旧npu-smi字段兼容性断裂CANN 6.0与5.1的npu-smi info输出字段有重大变更字段名CANN 5.1字段名CANN 6.0变更说明Memory-UtilHBM-Util明确指向HBM移除歧义TemperatureTemp-AI-Core细化为模块级温度PowerPower-Usage增加Power-Limit和Power-Headroom致命坑某客户将CANN从5.1升级至6.0后原有监控脚本仍用grep Memory-Util导致所有HBM监控失效。解决方案升级后立即运行npu-smi info | head -20对比字段名变更并更新所有正则表达式。最后分享一个真实教训去年我们在一个边缘计算项目中npu-smi info显示一切正常但模型推理延迟波动极大。最终发现是npu-smi默认刷新间隔1秒掩盖了200ms级的瞬时DVPP阻塞。解决方案是改用npu-smi info -l 200200ms刷新并用Python脚本实时计算DVPP-Util的标准差当σ15%时触发告警——这个细节文档里从没提过但却是保障实时性系统的命脉。
