华为NPU监控实战：解读npu-smi info命令输出的关键指标
1. 初识npu-smi：华为NPU的"健康体检仪"
第一次接触华为Atlas服务器的朋友可能会好奇，这个黑乎乎的盒子里装的NPU芯片到底在忙些什么？就像我们平时用任务管理器看电脑CPU状态一样，npu-smi就是专门为华为NPU设计的"体检报告单"。我在实际运维中就遇到过这样的情况：某天深夜算法团队突然反馈模型训练速度下降，打开npu-smi info一看，某个NPU的温度已经飙到90多度——原来机房空调故障导致散热不良。
这个命令行工具的输出看似简单，其实藏着很多关键信息。举个例子，当看到AICore%长期维持在95%以上，就像汽车发动机一直处于红线转速，这时候就该考虑是不是有进程在"霸占"NPU资源。我习惯把npu-smi info比作NPU的"体检仪"，它能实时显示：
- 核心负荷（AICore%）：相当于NPU的"心跳频率"
- 温度指标（Temp）：就像人体的体温
- 内存状况（Memory-Usage）：类似血液检查报告
- 进程清单：好比当前正在进行的"体力活动"
2. 逐项拆解：npu-smi info的指标密码
2.1 设备基础信息：NPU的"身份证"
每次执行npu-smi info，最先看到的就是设备概要信息。有次我们机房新到一批Atlas 300V Pro卡，就是靠这些字段快速确认设备型号和健康状况：
NPU Chip: 0 Name: 310P3 Device: 0 Health: OK Bus-Id: 0000:01:00.0- NPU Chip和Device：当服务器插着多张加速卡时，这个编号就是定位问题的GPS坐标。曾经有张卡频繁报错，通过编号快速定位到是PCIe插槽接触不良
- Health：这个"OK"字样看着简单，但要是变成"Error"就得立即行动。建议在监控系统设置该字段告警
- Bus-Id：这个PCIe总线地址在排查硬件冲突时特别有用，记得有次和GPU混插时就靠它理清拓扑关系
2.2 核心指标：NPU的"生命体征"
真正决定NPU工作效率的是这几个动态指标：
AICore(%): 33 Temp(C): 84 Memory-Usage(MB): 18308/21527 Hugepages-Usage(page): 8222/8222- AICore%：这个百分比就像汽车转速表，常规训练任务建议保持在30-70%之间。突然冲到100%可能是进程死循环，长期低于10%则可能配置有问题
- Temp：84°C看起来吓人，但其实NPU耐高温能力比CPU强。不过超过95°C就要警惕了，我们曾用
npu-smi set -t 85 -i 0手动设置温度阈值 - Memory-Usage：前一个数是已用量，后一个是总量。当使用量持续接近总量时，会出现OOM错误。有个取巧的办法：
watch -n 1 "npu-smi info | grep Memory"实时监控 - Hugepages：大页内存对性能影响很大，如果使用量总是满的，可能需要调整
/etc/sysctl.conf的vm.nr_hugepages参数
3. 实战诊断：从数据到解决方案
3.1 温度异常排查手册
上周就遇到个典型案例：某台服务器的NPU温度持续在89°C高位运行。通过npu-smi info配合其他工具，我们这样排查：
- 先看温度分布：
npu-smi info -t显示所有卡的温度 - 检查散热：
ipmitool sensor list查看机箱风扇转速 - 分析进程：发现有个python进程长期占用90% AICore
- 最终定位：原来是数据预处理代码错误，导致NPU持续处理无效数据
这种情况下的临时解决方案是：
npu-smi kill -t python -i 0 # 强制结束问题进程 npu-smi reset -i 0 # 重置NPU设备3.2 内存泄漏追踪技巧
内存泄漏是另一个常见问题。有次客户报告训练到后期总是崩溃，我们这样用npu-smi诊断：
- 建立内存基线：训练开始时记录Memory-Usage
- 定期采样监控：每10分钟记录一次内存增长量
- 关联进程分析：发现某个C++进程的内存占用每小时增长约200MB
- 最终发现：第三方库的tensor缓存没有正确释放
关键的命令组合：
watch -n 600 "npu-smi info | grep -A 10 Process"4. 进阶技巧：让监控更高效
4.1 自动化监控脚本
对于多卡服务器，我习惯写个简易监控脚本保存为npu_monitor.sh：
#!/bin/bash while true; do clear echo "====== $(date) ======" npu-smi info sleep 5 done还可以用颜色高亮关键信息：
npu-smi info | grep --color=always -E "AICore|Temp|Memory"4.2 与Prometheus集成
在生产环境推荐用telegraf采集npu-smi数据：
[[inputs.exec]] commands = ["/usr/bin/npu-smi info -l"] timeout = "10s" data_format = "influx"配合Grafana可以做出漂亮的监控看板，重点监控：
- 各卡AICore负载均衡情况
- 温度随时间变化曲线
- 内存使用率水位线
5. 避坑指南：那些年踩过的雷
在Atlas 900集群维护中，有几个经验教训值得分享：
- 不要忽视Health字段：有次硬件故障早期只表现为间歇性Health状态波动，等变成常驻Error时已影响业务
- 跨卡负载不均衡：当看到某张卡的AICore%长期比其他卡高20%以上，可能是PCIe带宽分配不均
- Hugepages用尽：会导致性能骤降，建议预留10%缓冲空间
- 进程残留问题：有些被kill的进程仍占用内存，需要reset NPU才能彻底释放
有个特别有用的调试命令组合：
npu-smi info | tee npu_status.log # 保存当前状态 npu-smi dump -i 0 -f debug.log # 导出详细诊断信息记得有次排查随机卡顿，就是靠对比多个时间点的npu_status.log，发现温度升高前总有特定的进程组合出现。