1. 从一张截图说起为什么我开始盯上 npu-smi info第一次在昇腾服务器上跑完一个ResNet50的推理任务我习惯性地敲下npu-smi info屏幕上刷出来一大片表格密密麻麻的数字和缩写。当时我的反应和大多数人一样——能看懂个大概知道哪块是显存、哪块是利用率但真要问“这个AICore百分比到底代表什么”“HBM-Usage和Memory-Usage有什么区别”“为什么我的卡利用率只有30%但任务跑得慢得要命”我答不上来。后来带团队做推理服务调优被这些问题反复折磨才逼着自己把npu-smi info的每一个字段都啃了一遍。这篇文章就是那段时间的踩坑记录和整理目标很明确让你拿到任意一台昇腾设备的npu-smi info输出能逐行读懂、能定位瓶颈、能判断异常。不管你是刚接触NPU的算法工程师还是负责推理服务运维的后端开发这些内容都能直接拿去用。npu-smi info是昇腾生态里最基础也最核心的监控命令地位相当于NVIDIA体系里的nvidia-smi。它读取的是NPU驱动暴露出来的设备状态信息涵盖芯片温度、功耗、显存占用、计算单元利用率、进程级资源消耗等维度。很多人只把它当成一个“看一眼显存够不够”的工具实际上它承载的信息量远超想象——前提是你知道每个数字背后的含义。2. npu-smi info 输出结构全拆解2.1 整体布局一张表里藏了多少信息先看一个典型的输出以Ascend 910B为例不同型号字段略有差异------------------------------------------------------------------------------------------------ | 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 | 92.3 45 0 / 0 | | 0 | 0000:81:00.0 | 0 0 / 0 1024 / 65536 | ---------------------------------------------------------------------------------------------- | 1 910B | OK | 88.7 43 0 / 0 | | 0 | 0000:82:00.0 | 0 0 / 0 2048 / 65536 | ----------------------------------------------------------------------------------------------这张表分上下两个半区。上半区是芯片级信息NPU编号、型号名称、健康状态、功耗、温度、大页内存使用。下半区是Chip级信息所属NPU、Bus-Id、AICore利用率、Memory-Usage、HBM-Usage。注意一个容易混淆的点一台物理NPU卡上可能有多个Chip比如910B是单卡双芯设计所以你会看到NPU 0下面挂着Chip 0NPU 1下面也挂着Chip 0。这个层级关系在排查问题时非常关键——功耗和温度是NPU级别的而AICore和显存是Chip级别的。2.2 芯片级字段Health、Power、Temp、HugepagesHealth字段是最先要看的。正常状态显示OK出现异常时会显示具体错误码或告警信息。我遇到过的情况包括Alarm温度过高触发降频、Critical硬件故障需要报修。这个字段是判断设备是否可用的第一道门槛如果Health不是OK后面的性能数据都没有参考意义。Power(W)是当前芯片的实时功耗单位瓦特。910B的TDP大约在300W-350W区间具体取决于型号和散热方案。这个值的意义在于如果你的推理任务功耗长期在50W以下说明计算单元根本没跑起来瓶颈大概率在数据加载或CPU侧预处理。反过来如果功耗贴着TDP上限跑同时温度也在飙升就要关注散热和降频问题了。Temp(C)是芯片结温。昇腾NPU的正常工作温度范围一般在0-85°C超过阈值会触发降频保护。实测中风冷环境下满载温度通常在60-75°C液冷可以压到50°C左右。温度这个指标要结合功耗一起看——同样的功耗下温度异常偏高可能是散热硅脂老化或风道堵塞。Hugepages-Usage(page)是大页内存的使用情况格式是已用/总量单位是页通常每页2MB。这个字段在跑大规模分布式训练时才需要重点关注推理场景下一般不会成为瓶颈。但如果你的模型需要大量 pinned memory 做数据预取这个值会明显上升。2.3 Chip级字段AICore、Memory-Usage、HBM-UsageAICore(%)是大家最关心的指标代表AI计算核心的利用率。但这里有个坑AICore利用率高不代表任务跑得快利用率低也不一定就是浪费。它反映的是在采样周期内AICore有百分之多少的时间在执行计算指令。如果模型存在大量非计算操作比如动态shape导致的编译、频繁的Host-Device拷贝AICore利用率就会偏低。Memory-Usage(MB)和HBM-Usage(MB)是两个不同的东西很多人会搞混。Memory-Usage指的是Chip上的DDR内存也叫片上内存容量较小主要存放指令队列和中间数据。HBM-Usage指的是高带宽显存也就是模型权重和激活值真正待的地方。910B单Chip的HBM容量通常是64GB65536MB你在部署模型时算显存够不够看的是HBM-Usage这一栏。注意Memory-Usage和HBM-Usage的格式都是已用/总量。如果HBM-Usage的已用值接近总量说明显存快满了继续加载模型或增大batch size会直接OOM。2.4 进程级信息谁在占用你的NPUnpu-smi info默认只显示设备级汇总信息。要看到具体哪个进程占了多少显存需要加-t参数或者用npu-smi info -t proc-memnpu-smi info -t proc-mem -i 0 -c 0输出会列出每个进程的PID、进程名、使用的HBM大小。这个功能在多人共用一台推理服务器时特别有用——发现显存被占满但不知道是谁干的一条命令就能定位。另外npu-smi info -t usages可以看到更细粒度的利用率数据包括AICore、AICPU、HBM带宽等分项指标。这些数据在调优时比单一的AICore百分比更有指导意义。3. 关键指标背后的原理与判读逻辑3.1 AICore利用率高不等于好低不一定差AICore利用率的采样机制是周期性的默认采样窗口大约1秒。它统计的是在这个窗口内AICore实际执行计算指令的时钟周期占比。听起来很直观但实际判读时有几个陷阱。第一个陷阱算子下发间隙。深度学习模型是由一个个算子串起来的算子之间有调度开销。如果模型算子粒度小、数量多AICore在算子切换时会空转利用率自然上不去。这种情况下即使用利用率只有40%也不代表算力浪费——而是调度开销吃掉了时间。第二个陷阱动态Shape编译。昇腾NPU对静态shape的算子执行效率最高。如果模型输入shape频繁变化每次都要触发算子编译AICore会大量时间花在等待编译结果上。表现就是利用率忽高忽低像心电图一样。第三个陷阱Host-Device拷贝瓶颈。如果数据预处理在CPU侧做得很慢NPU经常处于“等数据”的状态AICore利用率也会偏低。这时候该优化的是数据管道而不是NPU本身。我的一般判读原则是先看功耗再看利用率。功耗上去了说明计算单元确实在干活功耗上不去但利用率高可能是空转或小算子密集执行功耗和利用率都低瓶颈一定在NPU之外。3.2 HBM-Usage显存规划的核心依据HBM显存是NPU上最稀缺的资源之一。以910B 64GB单Chip为例一个7B参数的模型用FP16加载权重占大约14GB加上KV Cache、激活值、框架开销实际占用可能在20-30GB。如果你要跑batch size 16的推理显存需求会线性增长。计算显存需求的粗略公式总显存 模型权重 KV Cache 激活值 框架预留模型权重 参数量 × 精度字节数。FP16是2字节INT8是1字节INT4是0.5字节。 KV Cache 2 × 层数 × 注意力头数 × head_dim × 序列长度 × batch_size × 精度字节数。 激活值跟模型结构和batch size相关通常用框架的memory profiler实测。实测中我习惯在HBM-Usage达到总量80%时就发出预警。因为推理过程中会有临时显存分配比如中间张量留20%的余量能避免突发OOM。3.3 功耗与温度被忽视的性能信号很多人监控NPU只看利用率和显存忽略了功耗和温度。实际上这两个指标是判断“NPU是否在健康状态下工作”的关键。功耗的判读逻辑910B的TDP大约300W。如果推理任务满载功耗只有100W说明计算密度太低可能是batch size太小或者模型太轻量。如果功耗频繁触碰TDP上限然后掉下来说明在反复触发功耗墙性能会周期性抖动。温度的判读逻辑温度超过80°C就要警惕超过85°C基本会触发降频。降频的表现是功耗突然下降、AICore利用率不变但吞吐量下降。这时候需要检查散热环境——机房温度、风扇转速、散热片积灰情况。我遇到过最隐蔽的一次性能问题一台服务器的NPU温度长期在82°C功耗被限制在250W导致推理吞吐比同配置机器低了15%。清理散热片积灰后温度降到68°C功耗恢复到300W吞吐量直接拉满。3.4 Memory-Usage与HBM-Usage的区分这两个字段的命名确实容易让人混淆。简单记Memory-Usage是片上DDRHBM-Usage是显存。片上DDR的容量很小通常几GB主要存放算子指令、标量数据和通信缓冲区。它的带宽和延迟都比HBM差但胜在灵活。一般情况下Memory-Usage不会成为瓶颈除非你在跑非常复杂的控制流模型。HBM才是模型权重和激活值的家。它的带宽极高910B的HBM带宽大约1.6TB/s但容量有限。所有显存优化手段——量化、梯度检查点、ZeRO——都是在省HBM。提示如果发现Memory-Usage异常高但HBM-Usage很低可能是某个进程在往片上DDR里塞大量数据需要检查代码中是否有不当的Host-Device拷贝或控制流逻辑。4. 实操从监控到定位问题的完整流程4.1 环境准备与命令速查在开始之前确认你的环境已经安装了昇腾驱动和CANN工具包。npu-smi命令位于/usr/local/Ascend/driver/tools/目录下通常已经加入PATH。常用命令速查表命令作用使用场景npu-smi info查看设备汇总信息日常巡检、快速摸底npu-smi info -t usages查看详细利用率性能调优npu-smi info -t proc-mem查看进程显存占用多人共用环境排查npu-smi info -t temp查看温度详情散热问题排查npu-smi info -t power查看功耗详情功耗异常排查npu-smi info -t health查看健康状态故障诊断npu-smi info -l列出所有设备多卡环境这些命令可以组合使用比如npu-smi info -t usages -i 0只看0号设备的利用率详情。4.2 一次完整的性能排查记录分享一个真实的排查案例。背景团队在一台8卡910B服务器上部署了一个LLM推理服务发现吞吐量只有预期的一半。第一步看全局npu-smi info输出显示8张卡的Health都是OK温度在55-60°C功耗在180-220W之间波动。AICore利用率在35%-50%之间跳动HBM-Usage每张卡大约40GB/64GB。初步判断功耗没跑满TDP 300W利用率偏低但显存充足。瓶颈不在显存。第二步看详细利用率npu-smi info -t usages -i 0发现AICore利用率45%但AICPU利用率高达80%。AICPU是NPU上的通用计算单元负责处理非矩阵运算的逻辑。AICPU利用率高说明模型中有大量控制流或标量计算在拖后腿。第三步定位代码检查模型代码发现有一处动态shape的逻辑每次推理时根据输入长度重新计算attention mask这个计算在AICPU上执行且没有做批处理优化。改成预计算mask并缓存后AICPU利用率降到15%AICore利用率升到70%吞吐量翻倍。第四步验证再次运行npu-smi info功耗稳定在280W左右温度65°CAICore利用率70%-75%吞吐量达到预期。这个案例的教训是AICore利用率低的时候不要只盯着AICore看要查AICPU和整体数据流。4.3 多卡场景下的监控要点多卡环境下npu-smi info的输出会很长。几个关注重点卡间一致性所有卡的Health应该都是OK温度差异不应超过10°C。如果某张卡温度明显偏高可能是散热风道问题或该卡负载过重。显存均衡在数据并行训练中各卡HBM-Usage应该接近。如果差异大可能是数据分发不均或某张卡上有残留进程。功耗分布训练时各卡功耗应该接近TDP。如果某张卡功耗明显偏低检查是否被分配了较少的计算任务。可以用watch -n 1 npu-smi info做实时监控观察指标随时间的变化趋势。趋势比单次快照更有诊断价值。4.4 自动化监控脚本示例手动敲命令适合排查问题但日常运维需要自动化。下面是一个简单的Python脚本定期采集npu-smi info数据并记录到日志import subprocess import re import time from datetime import datetime def parse_npu_smi(): result subprocess.run([npu-smi, info], capture_outputTrue, textTrue) lines result.stdout.strip().split(\n) metrics [] for line in lines: if re.match(r\|\s*\d\s\d, line): parts [p.strip() for p in line.split(|) if p.strip()] if len(parts) 6: metrics.append({ npu: parts[0].split()[0], health: parts[1], power: parts[2].split()[0] if parts[2] else N/A, temp: parts[3].split()[0] if parts[3] else N/A, aicore: parts[4].split()[0] if parts[4] else N/A, hbm: parts[5] if len(parts) 5 else N/A }) return metrics while True: timestamp datetime.now().strftime(%Y-%m-%d %H:%M:%S) for m in parse_npu_smi(): print(f{timestamp} NPU{m[npu]} Health{m[health]} fPower{m[power]}W Temp{m[temp]}C fAICore{m[aicore]}% HBM{m[hbm]}) time.sleep(10)这个脚本每10秒采集一次输出格式化的监控日志。你可以把它改成写入CSV或推送到监控系统。注意解析逻辑要根据你的实际输出格式做调整不同版本的npu-smi输出列可能有差异。5. 常见问题与排查技巧实录5.1 利用率上不去任务却跑得慢这是最高频的问题。排查顺序建议如下先看功耗功耗低于TDP的50%说明计算单元没吃饱。检查batch size是否太小、模型是否太轻量。再看AICPUnpu-smi info -t usages看AICPU利用率。如果AICPU高说明控制流或标量计算拖后腿需要优化代码逻辑。检查数据管道用npu-smi info -t proc-mem看是否有进程在频繁申请释放显存这通常意味着数据加载不稳定。检查动态shape如果模型输入shape不固定每次推理都触发编译AICore会大量空转。尽量固定shape或使用动态shape缓存。5.2 显存泄漏的发现与处理显存泄漏的表现是HBM-Usage持续上升即使推理任务已经结束也不释放。用npu-smi info -t proc-mem可以定位到具体进程。常见原因包括PyTorch/TensorFlow的缓存机制没有正确清理、自定义算子中申请了显存但没有释放、多进程环境下进程退出时没有清理NPU资源。处理方式在代码中显式调用torch.npu.empty_cache()PyTorch或对应的清理接口。如果进程已经异常退出但显存没释放需要手动kill残留进程。5.3 温度异常与降频判断温度问题的排查路径单卡温度高检查该卡对应的散热风扇和风道。多卡温度都高检查机房环境温度建议18-27°C和机箱进风温度。温度正常但功耗上不去可能是功耗墙设置问题用npu-smi info -t power查看功耗限制配置。降频的判断依据功耗突然从TDP附近掉到50%以下同时AICore利用率不变但任务吞吐量下降。这时候npu-smi info的Temp字段通常会显示80°C以上。5.4 常见问题速查表现象可能原因排查命令解决方向AICore利用率低数据管道瓶颈npu-smi info -t usages优化数据预处理AICore利用率低动态shape编译检查模型输入固定shape或缓存AICore利用率低小算子调度开销查看算子数量算子融合HBM-Usage持续上升显存泄漏npu-smi info -t proc-mem清理缓存或kill进程温度超过80°C散热不良npu-smi info -t temp清理散热片、检查风扇功耗低于TDP 50%batch size太小检查推理配置增大batch sizeHealth非OK硬件故障npu-smi info -t health联系运维报修多卡显存不均数据分发不均对比各卡HBM检查数据并行逻辑5.5 几个容易踩的坑坑一把AICore利用率当成唯一指标。前面反复说了利用率要结合功耗、AICPU、数据管道一起看。单看利用率容易误判。坑二忽略Memory-Usage。虽然它通常不是瓶颈但如果你的模型有复杂的控制流片上DDR可能会成为隐形瓶颈。特别是跑Transformer类模型时attention mask的处理如果放在片上DDR可能会拖慢整体速度。坑三不同版本的npu-smi输出格式不同。CANN版本升级后字段名称和排列可能有变化。写自动化脚本时要做好版本适配不要硬编码列位置。坑四多卡环境下用错设备编号。npu-smi info -i 0中的-i指定的是NPU编号不是Chip编号。如果要指定Chip需要加-c参数。搞错了会看到错误的设备数据。坑五忘记看进程级信息。多人共用服务器时设备级汇总信息可能显示显存被占满但不知道是谁占的。养成用-t proc-mem的习惯能省很多沟通成本。6. 把监控变成习惯我的日常巡检清单最后分享我自己的日常巡检流程。每天早上到工位第一件事就是跑一遍这套检查npu-smi info看全局Health是否全OK温度是否正常功耗是否在合理区间。npu-smi info -t proc-mem看进程有没有异常进程占用显存有没有残留的僵尸进程。对比昨天的监控日志HBM-Usage是否有异常增长趋势温度是否有缓慢上升。如果发现异常用npu-smi info -t usages深入看AICore和AICPU的分布。这套流程走下来不到两分钟但能提前发现80%的潜在问题。很多硬件故障和性能退化都是有前兆的——温度缓慢上升、显存逐渐泄漏、功耗慢慢偏离正常范围。定期巡检比出了问题再排查要省事得多。另外建议把npu-smi info的输出接入现有的监控系统比如Prometheus Grafana。昇腾提供了npu-exporter工具可以把NPU指标暴露成Prometheus格式。这样你就能看到历史趋势图而不是每次都要手动敲命令。我搭了一套之后团队里再也没人问“NPU现在什么状态”这种问题了——看板上一目了然。监控这件事工具是次要的关键是理解每个指标背后的含义知道什么值是正常的、什么值是异常的、异常了该往哪个方向查。npu-smi info看起来简单但真正吃透它能帮你省下大量排查时间。