1. 昇腾NPU监控的起点为什么npu-smi info是绕不开的第一课搞昇腾NPU开发或者运维的人迟早会碰到一个场景模型跑在昇腾卡上训练速度不对劲或者推理延迟忽高忽低但你看了一眼系统CPU和内存都挺正常GPU那套监控工具又完全用不上。这时候你需要的就是昇腾生态里最基础也最核心的一个命令行工具——npu-smi info。这个命令看起来简单敲下去就出一屏信息但真正能把这一屏信息读透、读准并且据此定位性能瓶颈的人其实并不多。我见过不少刚接触昇腾的开发者跑完npu-smi info之后只知道看个温度其他字段一概略过等到出了问题再回头翻文档效率极低。这篇文章就是要把这个命令的每一个字段、每一种用法、以及它背后对应的硬件状态和性能含义彻底讲清楚。npu-smi全称是NPU System Management Interface是华为昇腾提供的一套命令行管理工具功能定位类似于NVIDIA的nvidia-smi。它能做的事情包括查看NPU基本信息、监控实时状态、查询和设置功耗与频率、管理ECC错误、查看进程占用、甚至做一些固件和驱动的维护操作。而npu-smi info是其中使用频率最高的子命令没有之一。这篇文章适合谁看如果你是刚拿到昇腾开发环境、准备跑第一个模型的算法工程师这篇能帮你建立对NPU运行状态的基本认知如果你是负责推理服务部署的运维人员这篇能帮你快速定位卡级别的问题如果你已经在用昇腾做训练但性能始终调不到预期这篇能帮你从监控数据里找到调优的切入点。我不打算只罗列命令参数而是把每个字段背后的硬件逻辑和性能含义都拆开讲让你看完之后能真正“读懂”这块卡在干什么。2. npu-smi info输出的逐字段拆解每个数字背后是什么2.1 整体输出结构长什么样在终端敲下npu-smi info你会看到类似下面这样的输出不同版本和型号会有差异但结构基本一致------------------------------------------------------------------------------------------------ | npu-smi 23.0.3 Version: 23.0.3 | ---------------------------------------------------------------------------------------------- | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)| | Chip | Bus-Id | AICore(%) Memory-Usage(MB) | | 0 910B | OK | 92.3 45 0 / 0 | | 0 | 0000:81:00.0 | 0 0 / 65536 | | 1 910B | OK | 89.7 43 0 / 0 | | 0 | 0000:82:00.0 | 0 0 / 65536 | 这个表格的信息密度很高但很多人只扫一眼温度和显存就过去了。实际上每一列都值得细看。2.2 NPU编号与Chip编号一张卡不一定只有一个“芯”最左边两列是NPU和Chip。NPU是设备编号从0开始递增代表系统识别到的第几张NPU卡。Chip是芯片编号这个字段容易被忽略但它很重要——部分昇腾型号比如910B系列在一张物理卡上可能集成多个芯片Die每个芯片独立报告自己的状态。这意味着什么如果你看到NPU 0下面有Chip 0和Chip 1两行那说明这张卡上有两个计算单元它们各自有独立的温度、功耗和显存。你在分配任务的时候如果只按NPU编号来分配可能会让两个芯片一个满载一个空闲资源利用率直接打对折。正确的做法是在代码或调度层面同时指定NPU编号和Chip编号确保负载均衡。2.3 Health状态不只是“OK”和“Not OK”的区别Health列显示的是芯片的健康状态常见值有OK、Warning、Alarm、Critical等。大部分人看到OK就放心了看到非OK就慌了。但实际情况比这复杂。OK表示当前没有检测到硬件层面的异常。但注意这只代表硬件自检通过不代表你的任务跑得好。我遇到过Health显示OK但实际计算吞吐只有理论值30%的情况原因后面会讲。当Health显示Warning时通常是温度偏高、功耗接近上限、或者ECC纠错计数在增长。这时候不一定要立刻停机但必须开始关注。Alarm和Critical则意味着需要立即介入继续跑任务可能导致硬件损伤或数据错误。提示Health状态是周期性刷新的不是实时变化的。如果你刚跑完一个高负载任务建议等几秒再查一次让状态稳定下来。2.4 Power和Temp功耗与温度的联动关系Power(W)是当前芯片的实时功耗单位瓦特。Temp(C)是芯片结温单位摄氏度。这两个数据必须结合起来看。昇腾910B的典型热设计功耗TDP在300W到400W之间具体取决于型号和散热方案。如果你看到功耗长期贴着TDP上限跑同时温度也在85度以上那说明散热系统已经在极限工作了。这时候即使Health还显示OK你也应该考虑降低负载或者改善散热否则降频迟早会发生。反过来如果你看到功耗只有几十瓦温度也很低但任务跑得特别慢那问题可能不在硬件层面而是软件调度或者模型本身的问题。这时候盯着npu-smi info看是看不出答案的需要往下查进程和内存。2.5 AICore利用率最容易被误读的指标AICore(%)是AI核心的利用率这个数字是整篇输出里最容易被误读的。很多人以为它像CPU利用率一样越高越好低了就是有问题。实际上不是这么回事。AICore利用率反映的是在采样周期内AI核心有多少时间处于“活跃”状态。注意是“活跃”不是“高效”。一个任务如果频繁在AI核心和主机内存之间搬运数据AI核心可能看起来很忙利用率高但实际计算吞吐很低因为大部分时间花在等数据上了。更关键的是npu-smi info默认的采样周期比较粗它给出的AICore利用率是一个瞬时快照不是一段时间内的平均值。你连续敲几次命令可能会看到数字在0%和90%之间跳。这不一定代表有问题可能只是采样时机不巧。要真正评估计算效率不能只看AICore利用率还要结合显存带宽、数据搬运量、以及模型本身的计算密度来综合判断。这个后面会展开讲。2.6 Memory-Usage显存占用的两个数字Memory-Usage(MB)显示的是已用/总量单位是MB。昇腾910B单芯片通常有64GB HBM显存不同型号有差异所以你会看到类似0 / 65536这样的数字。这里有个细节显存占用包括模型权重、激活值、梯度、优化器状态、以及框架自身的开销。很多人算显存需求的时候只算模型权重大小结果跑起来发现OOMOut of Memory。以训练为例一个10亿参数的模型FP16权重约2GB但加上梯度、优化器状态Adam的话是权重的2倍、激活值实际占用可能是权重的4到6倍。所以看到显存快满了先别急着换卡算一下是不是自己的显存估算方法有问题。另外显存释放不是即时的。任务结束后框架可能还持有显存不释放这时候npu-smi info会显示显存仍然被占用。如果你确认任务已经退出但显存没释放可以查一下是否有残留进程。2.7 Hugepages-Usage大页内存的使用情况Hugepages-Usage(page)这一列显示的是大页内存的使用量。大页内存对NPU计算很重要因为它能减少TLBTranslation Lookaside Buffer缺失提高数据搬运效率。如果这一列显示0 / 0说明系统没有配置大页内存或者当前任务没有使用大页内存。对于高性能训练和推理场景建议配置大页内存。具体配置方法后面会讲。这里先记住一点大页内存没配好数据搬运效率可能下降10%到20%这个损失在规模化训练中非常可观。3. 从info到调优用npu-smi的其他子命令定位性能瓶颈3.1 npu-smi info -t 系列按需查询特定信息npu-smi info给的是概览但调优的时候你需要更细的数据。npu-smi info -t后面可以跟不同的参数来查询特定类型的信息。常用的有npu-smi info -t usages -i 0查看指定NPU的详细使用率包括AICore、内存带宽、HBM利用率等。npu-smi info -t temp -i 0查看温度详情包括各传感器的读数。npu-smi info -t power -i 0查看功耗详情包括当前功耗、功耗上限、以及功耗封顶的原因。npu-smi info -t memory -i 0查看显存详情包括各进程的显存占用。这些子命令的输出比概览详细得多。比如-t usages会给出AICore利用率、HBM带宽利用率、以及L2缓存命中率等数据。HBM带宽利用率是判断是否遇到“内存墙”的关键指标——如果AICore利用率不高但HBM带宽利用率很高说明瓶颈在数据搬运不在计算。3.2 npu-smi info -t proc谁在占用NPUnpu-smi info -t proc -i 0可以查看指定NPU上运行的进程信息包括进程ID、进程名、以及该进程占用的显存。这个命令在排查“显存被谁吃了”的时候特别有用。我遇到过一种情况训练任务异常退出但显存没有释放导致后续任务无法启动。用npu-smi info -t proc一查发现有一个僵尸进程还挂着。直接kill掉之后显存就释放了。如果没有这个命令你可能得重启整个节点那代价就大了。3.3 npu-smi info -t eccECC错误统计ECCError Correcting Code错误是硬件层面的内存纠错。npu-smi info -t ecc -i 0可以查看ECC错误的统计信息包括可纠正错误Correctable Error和不可纠正错误Uncorrectable Error的计数。可纠正错误偶尔出现一两次问题不大硬件会自动纠正。但如果计数在持续增长说明显存颗粒可能在老化或者散热有问题。不可纠正错误则意味着数据已经损坏必须立即停止任务并检查硬件。注意ECC错误计数是累积的不会自动清零。你需要记录基线值然后观察增量。如果增量在短时间内明显上升那就是预警信号。3.4 用npu-smi做功耗和频率的实时监控npu-smi info -t power -i 0可以查看当前功耗和功耗上限。但如果你想做实时监控可以配合watch命令watch -n 1 npu-smi info -t power -i 0这样每秒刷新一次功耗数据。你可以一边跑任务一边观察功耗曲线。如果功耗频繁触顶然后掉下来说明芯片在反复降频这时候需要考虑降低batch size或者优化数据加载流程。频率信息可以通过npu-smi info -t freq -i 0查看部分版本支持。如果发现频率低于标称值且温度正常那可能是功耗墙限制需要调整功耗上限。4. 实战调优从监控数据到具体优化动作4.1 场景一AICore利用率低但任务跑得慢这是最常见的性能问题。你跑一个训练任务npu-smi info显示AICore利用率只有30%到40%但任务就是快不起来。这时候按下面的顺序排查第一步查数据加载。用npu-smi info -t usages -i 0看HBM带宽利用率。如果带宽利用率也很低说明NPU在等数据。这时候问题大概率出在数据加载管道上——可能是磁盘IO慢、可能是数据预处理在CPU上成了瓶颈、也可能是DataLoader的worker数量不够。解决办法包括增加DataLoader的num_workers、把数据预处理放到NPU上做、或者用更快的存储介质。第二步查batch size。batch size太小会导致每次计算的数据量不足以填满AI核心的并行度。昇腾910B的AI核心规模很大batch size太小的话核心利用率自然上不去。可以尝试逐步增大batch size观察AICore利用率是否上升。但注意不要超过显存容量。第三步查算子效率。如果数据加载和batch size都没问题但AICore利用率还是低那可能是模型里有一些算子在NPU上效率不高。这时候需要用昇腾的性能分析工具如Ascend Profiler来定位具体是哪些算子拖了后腿。4.2 场景二显存够但OOM报错有时候npu-smi info显示显存还有不少空闲但任务就是报OOM。这种情况通常有几个原因一是显存碎片化。长时间运行的任务反复申请和释放显存可能导致碎片化虽然总空闲量够但没有连续的大块显存可用。解决办法是尽量复用显存避免频繁的动态申请。二是框架的显存预分配策略。有些框架会一次性预分配一大块显存即使实际用量没那么多npu-smi info也会显示已占用。这时候需要看框架的显存管理配置调整预分配比例。三是多进程共享显存时的配额问题。如果多个进程共享一张NPU每个进程能用的显存可能有限制。需要检查是否有显存配额配置。4.3 场景三温度过高导致降频昇腾NPU在温度超过一定阈值后会自动降频以保护硬件。如果你发现任务跑着跑着突然变慢同时npu-smi info显示温度在85度以上那基本可以确认是降频了。解决办法分几个层面散热层面检查服务器风扇是否正常运转、散热片是否积灰、机房环境温度是否过高。这些是物理层面的问题但往往最容易被忽略。功耗层面用npu-smi info -t power -i 0查看功耗上限如果功耗上限设得过高可以适当调低。功耗降下来温度自然也会降。具体命令是npu-smi set -t power-limit -i 0 -d value需要管理员权限。任务层面降低batch size或者增加梯度累积步数减少单位时间内的计算量也能降低温度。4.4 场景四多卡训练时负载不均衡多卡训练时如果npu-smi info显示有的卡AICore利用率90%有的卡只有50%那说明负载不均衡。常见原因包括数据并行时如果数据分配不均匀某些卡分到的数据多某些卡分到的少。解决办法是确保数据切分是均匀的并且使用正确的分布式采样器。模型并行时如果模型切分不合理某些卡上的计算量大某些卡上的计算量小。这时候需要重新设计模型切分策略尽量让各卡的计算量均衡。还有一种情况是通信瓶颈。如果卡间的通信带宽不够某些卡可能在等通信完成导致利用率上不去。这时候需要检查通信拓扑和通信库的配置。5. 那些文档里不会写的实操经验5.1 npu-smi的输出会“骗人”npu-smi info给出的AICore利用率是瞬时值不是平均值。这意味着你看到的数字可能具有很大的偶然性。我建议的做法是连续采样多次取平均值或者看趋势。可以用简单的shell脚本实现for i in $(seq 1 10); do npu-smi info -t usages -i 0 | grep AICore sleep 1 done这样你能看到AICore利用率在10秒内的变化情况比单次快照靠谱得多。5.2 大页内存配置的坑前面提到大页内存对性能有影响但配置大页内存有几个坑第一大页内存是在系统启动时预留的运行中不能动态调整。所以如果你发现需要大页内存得修改GRUB配置并重启系统。第二大页内存的大小要合理。配得太少不够用配得太多浪费内存。一般建议根据模型大小和并发任务数来估算。第三不是所有框架都默认使用大页内存。有些框架需要显式配置才能启用。具体配置方法要看框架的文档。5.3 进程残留导致显存不释放这个问题在调试阶段特别常见。你的训练脚本因为bug崩了但显存没有释放。npu-smi info显示显存还被占着但你已经找不到那个进程了。这时候用npu-smi info -t proc -i 0查看进程列表。如果列表里有进程但你已经kill过了可能是僵尸进程。用ps -ef | grep pid确认进程状态必要时用kill -9强制终止。如果进程列表是空的但显存仍然被占用那可能是驱动层面的问题。这时候只能尝试重置NPUnpu-smi set -t reset -i 0或者重启节点。5.4 不同版本的npu-smi输出格式有差异昇腾的软件栈更新比较频繁不同版本的npu-smi输出格式可能有差异。比如有些版本把AICore利用率放在第一行有些版本放在第二行。有些版本有Hugepages-Usage列有些版本没有。这意味着你不能把解析npu-smi输出的脚本写死。建议用grep和awk做模糊匹配而不是按固定位置截取。比如要提取AICore利用率可以用npu-smi info -t usages -i 0 | grep -i aicore | awk {print $NF}这样即使格式有变化只要关键字还在脚本就能正常工作。5.5 监控频率不要太密有些人为了实时监控把npu-smi的调用频率设得很高比如每0.1秒一次。这样做有两个问题一是npu-smi本身会消耗一定的CPU资源频率太高会影响任务性能二是高频采样得到的数据噪声很大反而不好分析。我的经验是日常监控1秒一次足够了性能分析时可以到0.5秒一次但不要更密。如果需要更细粒度的数据应该用昇腾提供的性能分析工具而不是靠npu-smi。6. 把npu-smi info纳入日常运维流程6.1 建立基线数据在系统稳定运行、任务正常的时候记录一组npu-smi info的基线数据。包括空闲时的功耗和温度、典型负载下的AICore利用率和显存占用、ECC错误计数等。有了基线数据后面出问题的时候就有了参照。比如你发现温度比基线高了10度那说明散热可能出了问题ECC错误计数比基线增长得快那说明显存可能有隐患。6.2 写一个简单的监控脚本不需要复杂的监控系统一个简单的shell脚本就能覆盖大部分日常需求#!/bin/bash LOG_FILE/var/log/npu_monitor.log while true; do TIMESTAMP$(date %Y-%m-%d %H:%M:%S) INFO$(npu-smi info | grep -E ^\| [0-9]) echo $TIMESTAMP $INFO $LOG_FILE sleep 60 done这个脚本每分钟记录一次NPU状态输出到日志文件。出问题的时候翻日志就能看到状态变化的时间线。6.3 设置告警阈值基于基线数据设置合理的告警阈值。比如温度超过80度告警、功耗持续超过TDP的90%告警、ECC可纠正错误计数在1小时内增长超过10次告警。告警方式可以很简单比如在监控脚本里加一个判断超过阈值就发邮件或者写系统日志。关键是要有告警不能等问题严重了才发现。6.4 定期检查固件和驱动版本npu-smi info的第一行会显示npu-smi的版本号这个版本号通常和固件、驱动版本是对应的。昇腾会不定期发布固件和驱动更新修复已知问题、提升性能、增加新功能。建议定期检查版本如果发现有更新评估后再决定是否升级。升级前一定要看release notes确认新版本没有引入你不兼容的变更。7. 从单卡监控到集群级可观测性单张卡的npu-smi info能解决的问题是有限的。当你管理的是一个几十卡甚至上百卡的集群时逐台登录执行npu-smi就不现实了。这时候需要把npu-smi的输出采集起来汇聚到统一的监控平台。常见的做法是在每台节点上跑一个采集agent定期执行npu-smi并把输出解析成结构化数据比如JSON格式然后推送到时序数据库如Prometheus或者日志平台如Elasticsearch。然后在Grafana之类的可视化工具里做仪表盘展示集群级别的NPU利用率、温度分布、功耗趋势等。这样做的好处是你能一眼看到整个集群的健康状况快速定位到异常的节点或卡。比如某个节点的温度明显高于其他节点那可能是那个节点的散热有问题某个卡的AICore利用率长期偏低那可能是任务分配不均衡。采集频率建议不要太密集群规模大的话每分钟一次就足够了。解析npu-smi输出的时候要注意版本兼容性不同节点的npu-smi版本可能不一致解析逻辑要能兼容多种格式。另外集群级监控还要考虑数据的保留策略。原始数据保留多长时间、聚合数据保留多长时间、什么时候做降采样这些都需要根据实际需求来定。一般来说原始数据保留一周到一个月聚合数据保留半年到一年是比较常见的做法。我在实际运维中发现集群级监控最大的价值不是“看当前状态”而是“回溯问题”。当某个训练任务失败或者性能不达标时你能翻出当时的历史数据看看是哪个节点、哪张卡、在什么时间点出现了异常。这种回溯能力是单卡npu-smi给不了的。