最近团队的一台训练服务器又闹脾气了一个同事跑着跑着模型突然报显存不足但nvidia-smi习惯性动作一看GPU明明没占满。问题出在哪这台机器上除了GPU还有好几张华为昇腾NPU卡而NPU的占用他一无所知。其实只要敲一条命令——npu-smi info就能看到昇腾卡的状态、温度和进程占用。这条命令我基本每天都要用排查问题、分卡调度、看温度全靠它。这篇就专门写透npu-smi info的用法和输出解读干货直接拉满适合刚接触昇腾NPU、或者已经在用但对监控命令不熟的工程师参考。1. 为什么盯NPU比盯GPU更需要专门的姿势先聊点背景。昇腾NPU和NVIDIA GPU不一样它不是一个插上就能跑的设备。昇腾卡上跑的是torch_npuPyTorch的NPU适配层任务通过CANN华为的计算架构下发到设备。因为整体工具链相对封闭很多从GPU切过来的工程师第一反应是用nvidia-smi结果发现这机器上根本没这个命令或者敲了也不知道看哪里。另一个容易踩的坑是昇腾服务器的NPU数量多比如Atlas 800T训练服务器有8卡甚至更多每张卡上又可能挂多个芯片Chip。如果你只敲一条不带参数的npu-smi info只能看到最粗粒度的概览。真要排查谁占了我的卡哪块卡温度异常得学会带参查询。1.1 从一次真实的卡顿事故说起我之前维护过一台Atlas 800推理服务器某天业务方反馈线上推理的P99延迟从20ms涨到200ms但CPU和内存占用都不高。我第一反应是NPU卡过热降频了于是跑了一条npu-smi info -t board -i 0 -c 0结果发现芯片温度已经到102度满负载运行且机房空调坏了触发了降频保护。后来把业务流量切到另一台机器温度回落才恢复正常。这事说明一个道理在昇腾平台上不了解温度就无从谈起稳定性和性能。1.2 npu-smi 工具到底从哪来npu-smiNPU System Management Interface是随昇腾驱动一起安装的命令行工具安装好CANN包和驱动后一般位于/usr/local/Ascend/driver/tools/下装完会软链到/usr/bin/npu-smi。它和NVIDIA的nvidia-smi定位完全一样——管理、监控、诊断NPU设备。如果你在机器上敲npu-smi提示找不到命令先别急检查两方面驱动是否安装成功ls /usr/local/Ascend/driver环境变量是否生效source /usr/local/Ascend/ascend-toolkit/set_env.sh解决完环境问题就可以开始真正的监控实战了。2. 首条命令上手npu-smi info到底输出了什么先看最常用的无参命令npu-smi info我挑一个典型输出做示例不同驱动版本字号布局会略有差异但字段大类一致------------------------------------------------------------------------------------ | npu-smi 24.1.rc1 Version: 24.1.rc1 | ------------------------------------------------------------------------------------ | NPU Name Health Power Temperature | | Chip Product Name Status (W) (C) | ------------------------------------------------------------------------------------ | 0 910B OK 312.0 78 | | 0 910B OK 312.0 78 | ------------------------------------------------------------------------------------ | AICore Usage (%) HBM Usage (%) HBM Used (MB) HBM Total (MB) | ------------------------------------------------------------------------------------ | 0.0 50.2 16384 32672 | | 0.0 50.2 16384 32672 | ------------------------------------------------------------------------------------2.1 表格里每一列的关键含义直接判断健康状态先看三个指标字段含义排查优先级Health Status设备是否OK异常时显示Error或Warning最高Temperature芯片当前温度摄氏度高Power当前功耗瓦中AICore UsageAI Core计算单元利用率高判断任务是否在跑HBM Usage / Used / Total显存使用率、已用、总量高排查显存不足注意输出里有两行一样的这是因为一张板卡上有两颗芯片比如Atlas 300I Duo、910B等双芯片产品。每一行对应一个芯片但NPU列显示的是板卡号。理解这个层级关系是后续带参查询的基础。2.2 一眼定位问题的阅读顺序很多新手看到一张大表会懵老手其实遵循固定顺序先看Health Status不是OK就立刻处理再看Temperature超过90度就要警惕超过100度基本是降频状态然后看HBM Used判断显存水位最后看AICore Usage为0说明任务没跑起来或者卡死了。这套顺序我称之为健康-温度-显存-算力四步法。遇到任何NPU相关异常我都是按这个顺序过一遍。3. 带参查询用-t board挖出温度、电压、功耗的细节不带参数的info只能看到聚合值真要精确定位到某个芯片必须用-ttype指定查询类型用-i指定NPU板卡ID用-c指定芯片ID。3.1 查询单颗芯片的完整板载信息npu-smi info -t board -i 0 -c 0这里-i 0是NPU卡0-c 0是芯片0。-t board会返回比info更细致的板卡级数据包括芯片名称、PCB版本、Firmware版本温度多路温度芯片温度、PCB温度、散热器温度等电压核心电压、IO电压等功耗当前功耗、最大功耗芯片的AICore频率3.2 常见输出字段的合理区间参考字段典型范围说明Chip Temperature空载40-55满载75-95不同型号有差异超过100务必干预PCB Temperature略低于芯片温度长期过高说明风道有问题Core Voltage0.75V-0.85V随型号变化异常偏低可能供电不稳Current Power空载20-40W满载几百瓦训练卡如910B满载可达400W注意以上数值是常见参考区间不同型号和散热方案差异很大具体阈值以华为官方规格为准。我见过刚开机温度就85度的卡也能稳定跑业务重点是看趋势而非绝对值。3.3 为什么温度监控特别重要深度学习任务往往长时满负载运行芯片温度会直接影响AICore频率。温度过高时芯片会主动降频保护表现就是训练踩油门但速度上不去。而风扇策略一般由BMC带外管理系统控制你如果发现温度曲线持续爬升先检查机房空调和服务器风道不要急着怀疑代码。4. 进程级监控找出是哪路进程在占显存排查显存不足、任务抢占光看板卡总用量是不够的。npu-smi提供了进程级查询npu-smi info -t process输出一般长这样---------------------------------------------------------------------- | NPU Chip PID Process Name Memory Used (MB) | ---------------------------------------------------------------------- | 0 0 12345 python 16384 | | 0 0 12346 python 2048 | | 1 0 23456 python 32672 | ----------------------------------------------------------------------4.1 每个字段的使用技巧PID进程号拿到后立刻用ps -fp 12345看它是什么任务、跑了多久、命令行参数是什么Process Name通常是进程名但不一定看得出手动还是训练关键是结合PID排查Memory Used显存占用这个是排查OOM的第一证据。排查显存不够的标准流程先跑npu-smi info -t process找到哪个进程把显存吃满了再ps -fp PID确认是不是自己的任务如果是别人的就去沟通如果是自己的那就优化batch size或者换卡。4.2 组合排查让进程和板卡对上号有时候进程显示占用了某块卡但你想知道这块卡整体负载如何可以用npu-smi info -t usagesusages类型会输出每块芯片的AICore利用率、HBM利用率比info多一项算力使用率。很多线上问题其实是显存没满但AICore打满从而造成延迟升高usages就是确认这个问题的利器。4.3 一个避免踩坑的提醒npu-smi info -t process在某些驱动版本下如果进程崩了但显存没释放会出现进程列表中看不到PID但显存占用居高不下的情况。我实测遇到过一次训练被OOM杀掉后HBM Used还剩8GB没释放。这种时候跑npu-smi info -t process是查不到的进程已死只能靠重启容器或者重新初始化设备来释放。5. 连续监控操作从敲命令到心里有数单次查询只能看当下性能排查往往需要看趋势。我平时会用几种方式做连续监控。5.1 用watch实现定时刷新watch -n 2 npu-smi info每2秒刷新一次适合在跑训练任务时实时观察温度上升和显存变化。按CtrlC退出。-n后面跟的是间隔秒数别设太短比如0.1秒npu-smi本身有查询开销频繁调用会影响性能。5.2 把监控输出落盘做趋势分析短时间用watch够了长时间监控则建议重定向输出再配合时间戳while true; do echo $(date %F_%H:%M:%S) npu_monitor.log npu-smi info -t board -i 0 -c 0 npu_monitor.log sleep 60 done这个简单脚本会把每1分钟的温度、功耗写入日志方便事后复盘。排查什么时候开始降频哪段时间温度飙升靠日志比靠记忆靠谱得多。5.3 生产环境的可选增强方向如果只是运维几台机器上面的脚本够了。如果管几十台建议走带外监控如BMC带出来的IPMI信息或者在容器内通过npu-smi配合Prometheus采集。不要一开始就上重型方案先用最轻量的方式把数据记录下来再逐步加组件。6. 实战排障从现象到定位三个高频问题复盘最后分享几个真实案例让大家看到npu-smi怎么和实际问题串起来。6.1 训练卡死AICore利用率突然归零现象训练loss停止更新但进程还在CPU占用正常。我先是npu-smi info看Health Status是OK的再看温度正常最后看usages发现AICore利用率变成0。这说明NPU没有在算但任务也没退出——典型的算子执行卡死。处理方式是记录PID后kill -9杀掉检查日志里的执行报错。6.2 多用户抢占两个任务都觉得自己卡现象两位同事同时跑训练互相感觉对方抢了卡。用npu-smi info -t process发现两个任务都落在了同一张卡的不同芯片上但其中一个大batch任务把AICore占满了小任务只能排队。这不是设备故障而是调度问题。解决办法是约定按卡分任务或者用昇腾的容器化隔离能力。6.3 跑模型报错npu is selected as device, but torch_npu is not available这是一个非常常见的环境错误。npu-smi用于设备级排查而这个问题通常出在软件栈先敲python -c import torch_npu确认是否导入成功不行就检查CANN与torch_npu版本是否匹配环境变量是否source如果npu-smi info本身正常那就说明硬件没问题焦点放在软件依赖链上。6.4 排查流程小结无论哪种问题我的排查顺序都是固定的npu-smi info看硬件健康状态npu-smi info -t board -i X -c Y看温度、功耗细节npu-smi info -t process看进程占用npu-smi info -t usages看AICore/HBM利用率结合日志和版本信息定位软件问题。这五步走完百分之八九十的NPU问题都能定位到方向。最后再分享一个小习惯每次跑长任务前我会先记录每张NPU卡的初始温度和空闲显存。任务跑起来后每隔一段时间扫一眼温度曲线。已经不止一次靠这个习惯提前发现机房空调故障——温度数据不会说谎等到业务方报障再处理往往已经晚了。npu-smi命令就这么几条用熟了比花里胡哨的监控平台还顺手。