掐指一算这几年我经手的昇腾服务器没有十台也有八台了几乎每一次在新环境里排查问题第一件事都是敲那行npu-smi info。说实话刚接触华为昇腾 NPU 那会儿我也觉得这命令不就是看看芯片温度和显存占用嘛比nvidia-smi还简单。但后来在机房里蹲了几回把输出里每个字段都抠了一遍才发现这条命令的信息密度比我想象中大得多芯片健康状态、内存带宽使用、AI Core 占用、电源功耗、甚至训练进程挂在哪颗芯片上全都能在几行文本里看出来。这篇文章我不打算讲花活就老老实实把npu-smi info从字段含义、常用参数、巡检脚本到配合 Prometheus 做监控、踩过的坑一条一条捋清楚。适合刚接手昇腾服务器的运维同学也适合做 AI 训练平台、推理服务部署的人顺手把监控能力补上。1. 别看不起一条命令为什么NPU监控要从npu-smi开始1.1 昇腾NPU监控的现状与痛点很多从 GPU 阵营转过来的朋友第一反应是找dcgm-exporter或者nvidia-smi dmon这类工具去采集昇腾 NPU 指标。但昇腾的软件栈跟 CUDA 完全不同官方提供的最基础、最通用、最容易上手的监控入口就是npu-smi。它的定位相当于nvidia-smi 一部分nvidia-smi dmon的能力能拿到芯片温度、内存、算力使用率、电源功耗、PCIe 链路状态这些关键信息。昇腾 NPU 监控的难点在于AI 训练场景下芯片数量多、指标杂而且很多异常不是直接报错而是性能慢慢劣化。比如某颗芯片的 HBM 温度高了训练 Loss 不会立刻起飞但过一会就会开始周期性变慢。再比如多卡训练时如果有一张卡的 AI Core 使用率一直偏低那多半是数据加载或者通信同步出了问题。这些都得靠监控数据暴露出来而不是等用户报障后再上机器瞎猜。1.2 npu-smi info 在监控体系中的定位npu-smi info这个名字看起来只是“查看信息”但它其实是整个昇腾可观测性体系的地基。华为官方有采集昇腾芯片指标的 exporter社区也有各种二次开发的方案但底层数据来源大多绕不开npu-smi提供的接口。就算你要上 Grafana 大屏、接告警平台最后也得有一个 Agent 定期去执行npu-smi info并解析输出。所以我的建议是先把npu-smi info吃透。你只有理解每条输出代表什么才能知道哪些指标该采集、告警阈值该设多少也才能在 exporter 出问题或者数据对不上的时候用最原始的命令手工验证。打个比方npu-smi info就是 NPU 监控的“听诊器”高端仪器可以慢慢配但这玩意儿你得先会用。2. npu-smi info 命令全景拆解输出字段与指标含义2.1 一条命令装进脑子标准输出逐段解读在昇腾服务器上直接执行npu-smi info输出通常分为两级设备级和芯片级。设备级就是物理上的一张卡比如 Atlas 300I 推理卡或者 Atlas 800 训练服务器里的一张 NPU芯片级则是这张卡里的计算芯片。多芯片形态下一张卡可能包含两颗甚至更多芯片所以看输出时要先分清楚你是在看“卡”还是看“芯”。拿最常见的 Atlas 800T A2 训练服务器来说执行命令后大致会显示这些内容Chip Count设备里的芯片总数比如 1 或 2。如果做分布式训练这里能看到物理拓扑。Version固件和驱动版本。训练跑着跑着出诡异问题先看这里和训练镜像里的配套版本是否一致。Chip Name芯片型号比如Ascend 910B。不同型号的算力规格、显存大小、功耗天花板都不一样的。Temperature芯片当前温度。昇腾芯片的测温点比较多这个一般是最高温度点。HBM Memory片上高带宽内存也就是常说的 NPU 显存。它跟 AI Core 一样是训练时最容易触顶的资源。AI Core计算核心的使用率。注意这个使用率一般指“忙的时间占比”不是瞬时频率。AI CPU负责控制、调度以及部分算子的 CPU 使用率。它经常被人忽略但实际上一旦跑满整个芯片的任务下发也会被卡住。DDR有些型号会显示板载 DDR 内存做数据预取或者临时缓冲用。Power电源相关的电压、电流、功耗。功耗能直接反映芯片是不是在“重负载”如果模型在跑但功耗很低说明大概率在等数据。第一次看输出的人容易头晕其实只要抓住三个核心温度、显存、算力使用率。这三个指标能回答 90% 的日常问题——芯片热不热、显存够不够、算力吃满了没。2.2 这些指标才是真正的“生死线”温度Temperature昇腾 910B 这类芯片满载运行时温度在 70~90 摄氏度都算正常范围。如果长时间超过 95 度甚至接近 100 度大概率是散热出了问题比如风扇转速异常、机房空调不给力、或者硅脂老化。温度高不会立刻烧卡但会触发降频训练速度肉眼可见地变慢。HBM 内存使用率训练大模型时显存占用高很正常但如果长期逼近 100%就容易出现内存申请失败、进程被 OOM 杀掉的情况。这里要留个心眼显存占用率跟“已用显存/总显存”有关但昇腾有内存碎片和预留内存的概念所以有时候显示 90% 多实际还能挤一点空间。AI Core 使用率这是衡量芯片算力是否被有效利用的关键。推理场景下AI Core 使用率可能只有 20%~50%因为瓶颈在数据搬运。训练场景下如果稳态运行时 AI Core 使用率能到 90% 以上说明计算和通信的流水线打得比较好如果长期低于 60%就要考虑是不是数据加载太慢、通信同步太频繁、或者算子实现有瓶颈。AI CPU 使用率很多人不看这行但它往往揭示了“隐形问题”。曾经遇到过一个模型AI Core 使用率只有 30%但 AI CPU 使用率超过了 90%一查发现是某个动态 shape 算子在 CPU 上做 shape 推导和内存分配把调度线程拖死了。这种情况下提高数据并行度没用得换算子实现或者固定输入 shape。2.3 -t 参数按主题查询各类硬件信息npu-smi info不带头参数时展示的是综合信息适合快速看一眼。但做深度巡检时我会按主题去查-t参数就是干这个的。常用的主题包括common通用信息包括芯片名称、固件版本、芯片 ID 等。board单板信息包括 PCB 版本、传感器信息、板卡在位状态。memoryHBM 内存的详细使用情况按芯片粒度展示。usagesAI Core 和 AI CPU 的使用率也就是综合输出里那两行。power电源信息包括电压、电流、功率。process当前占用 NPU 的进程列表能看到进程 PID、使用的芯片 ID、显存占用。pciePCIe 链路信息包括链路速率、宽度。多卡通信异常时这个非常关键。p2p芯片间的 P2P 通信信息分布式训练用到 HCCS / PCIe P2P 时值得关注。ddr、emmc板载 DDR 和存储介质的信息运维排查时偶尔会用到。比如要查看进程在 NPU 上的占用情况可以执行npu-smi info -t process输出里会列出类似PID、Chip ID、Process Type、Memory Size这样的字段。这个功能在排查“显存被谁占了”时特别管用。你可以根据 PID 去ps里反查是哪个容器或进程在跑不用再靠猜。再比如查看某颗芯片的电源功耗npu-smi info -t power -i 0 -c 0-i 0指定设备 ID-c 0指定芯片 ID。对于多卡服务器这种按设备、按芯片的精确查询比看全量输出清爽很多。注意不同版本的昇腾驱动和固件npu-smi的参数和输出格式可能会有细微差别。如果参数敲下去报错先执行npu-smi info -h看看当前版本支持哪些主题不要死记硬背命令。3. 实战场景与操作要点从人工巡检到自动采集3.1 快速巡检三板斧实时刷新、定时快照、进程定位第一板斧实时刷新。手动刷命令看变化最土但最有效watch -n 1 npu-smi info每秒刷一次在压测或者跑训练的时候可以直观看到温度、功耗、算力使用率的变化趋势。注意watch -n 1不是说每秒都能刷得出来npu-smi info本身有一定耗时如果机器负载很高刷新间隔会拉长到两三秒可以接受。第二板斧定时快照。长时间跟踪场景下我通常写一个简单的 shell 脚本把npu-smi info的输出定时保存下来留作事后分析。比如#!/bin/bash # npu_monitor.sh while true; do timestamp$(date %Y%m%d_%H%M%S) npu-smi info /data/npu_log/npu_${timestamp}.log sleep 30 done这里sleep 30比较好既能反映趋势又不会像 1 秒一次那样产生大量日志、把磁盘打满。真出现故障的时候30 秒粒度足够你对定位出一个大致窗口了。如果需要在故障瞬间保存现场可以配合npu-smi info -t process一起落盘。第三板斧进程定位。看到显存高但不知道是哪个任务在跑时npu-smi info -t process拿到 PID 之后去ps -ef | grep pid确认或者直接cat /proc/pid/cgroup看它属于哪个容器。生产环境里这一步特别有用因为很多时候用户会同时起好几个任务资源抢占在你毫不知情的时候就发生了。3.2 采集脚本怎么写npu-smi Prometheus Grafana光靠命令行巡检只能用于故障排查做不到“趋势预警”。真正要形成监控闭环还是得把指标采集出来打到 Prometheus 里。搭建过程不复杂就三步采集指标、暴露端口、配 Grafana 面板。采集指标这一步最省事的方式是直接用社区或华为官方提供的 exporter。但如果想完全掌控指标格式也可以自己写一个小脚本。核心就是解析npu-smi info -t usages和-t memory这两个命令的文本输出转成 Prometheus 的 metrics 格式。举个例子用 Python 解析npu-smi info -t usages的输出输出类似# 伪代码实际解析要根据你的npu-smi版本文本格式调整 import subprocess import re output subprocess.check_output([npu-smi, info, -t, usages]).decode() # 假设输出里能按行匹配到每颗芯片的 AI Core 使用率 for line in output.splitlines(): match re.search(rchip\s(\d).*?AI Core.*?\|\s*(\d)%, line) if match: chip_id match.group(1) utilization int(match.group(2)) print(fnpu_ai_core_utilization{{chip\{chip_id}\}} {utilization})实际部署时可以把这个脚本用prometheus_client库暴露成 HTTP 端口再在prometheus.yml里加上scrape_configs指向它。Grafana 侧只需要建面板把npu_ai_core_utilization、npu_temperature_celsius、npu_memory_used_bytes这类指标拖进去即可。这里有个容易踩的坑不要用太短的抓取间隔去轮询npu-smi。每次执行npu-smi info都会在驱动层做一次状态查询频率太高会无谓占用系统资源。我的经验是Prometheus 抓取间隔设 15 到 30 秒就足够了NPU 指标是缓变值用不着 1 秒刷新。3.3 多卡分布式训练时的监控技巧多卡训练场景比如 Atlas 800 系列的 8 卡服务器最容易出现“一卡忙七卡等”的情况。这个时候单看平均使用率没用必须每颗芯片单独看。我的做法是先抓一次全量快照npu-smi info然后重点看每一行的AI Core是否都在 80% 以上。如果某颗芯片使用率明显低于其他卡大概率是数据并行时DataLoader某个 worker 挂了或者集合通信中有慢卡拖后腿。这时候可以进一步查看npu-smi info -t p2p确认芯片间的 P2P 链路是否正常。曾经遇到过一次训练速度越来越慢的问题查到最后是 HCCS 链路降速P2P 带宽从 392GB/s 掉到了半速训练吞吐直接对半砍。多卡监控的另一要点是功耗轮询不能太频繁。8 张卡同时满载时电源余量本来就不充裕频繁查询功耗会导致瞬时负载叠加反而影响训练稳定性。我一般只在怀疑电源有问题时才去连续采集平时巡检只看温度和算力使用率。4. 常见故障与排查技巧实录4.1 故障速查表下面这个表格是我实际故障排查中整理出来的遇到问题可以先对号入座。现象可能原因排查命令解决思路芯片温度长期超过 95°C散热模组故障、机房温度过高、风扇转速异常npu-smi info -t board检查风扇、清理灰尘、调整机房空调HBM 内存使用率 100%进程被杀模型内存超卖、碎片严重npu-smi info -t memory调小 batch size、优化内存复用AI Core 使用率偏低功耗也很低数据加载瓶颈、算子执行序列化npu-smi info -t usages-t power排查 DataLoader、升级 CANN 版本AI CPU 使用率飙高动态 shape 算子过多、调度问题npu-smi info -t usages固定输入 shape、替换算子某卡显示Status: Stopped芯片异常挂掉、驱动异常npu-smi info看完整状态尝试恢复或重启驱动多卡训练时某卡 AI Core 明显低于其他卡通信慢卡、CPU 分配不均npu-smi info -t p2p 对比各卡 usages检查 HCCS 链路、调整进程绑核4.2 两个实战排查案例温度飙高与 AI Core 利用率异常案例一温度飙高到 100°C有一回训练任务跑了半小时后开始周期性掉帧每次掉帧持续几十秒。我上机器一看温度已经冲到 100°C 边缘AI Core 使用率却只有 40% 多。拿起npu-smi info -t board一看风扇转速信息异常低判断是风扇策略没有跟着负载走。后来确认是服务器 BMC 固件版本的问题在高温环境下风扇 PID 调节不及时刷了新 BMC 固件后恢复正常。这里要说一句看到温度高先不要急着换卡先看风扇转速和 BMC 日志。案例二AI Core 利用率只有 30%另一次是推理服务上线后单卡吞吐一直上不去AI Core 只有 30%CPU 使用率也不高功耗更是低得可疑。排查路径是这样的先看npu-smi info -t process确认推理进程确实跑在昇腾芯片上再看-t usages确认 AI Core 确实没被吃满接着看-t memory显存占用也没问题。最后定位到是模型推理时张量 shape 一直动态变化导致 CANN 在图编译阶段反复触发 AOE 调优真正执行算子的时间被大幅压缩。尝试固定输入尺寸后AI Core 使用率直接翻到 75% 以上问题解决。这类案例的启发是NPU 监控数据不能孤立看要联合温度、功耗、内存、算力使用率一起分析才能还原现场。一个指标异常往往只是导火索真正的原因藏在一堆指标的组合关系里。4.3 多卡芯片状态异常的处理顺序遇到某颗芯片显示异常或者进程无法申请显存我建议按这个顺序操作先通过npu-smi info -t process找到占用进程看是不是业务进程没退出导致显存泄漏再检查驱动日志/var/log/npu/下的报错尝试用npu-smi set -t reset -i 设备ID -c 芯片ID恢复芯片状态。如果还是不行最后一招就是重启驱动或重启服务器。这套处理顺序可以避免一上来就重启整个节点的尴尬也能最大程度缩短业务中断时间。注意npu-smi set -t reset会重置对应芯片的显存和计算状态属于比较重的操作。执行之前必须确认该芯片上没有正在跑的任务否则会把训练进程直接打断。5. 监控体系化建设路线从一条命令到整套告警平台5.1 一条命令到一套监控系统的演进npu-smi info能做到的是“看到现状”但生产环境需要的是“预见风险”。所以我会建议团队里按下面三个阶段逐步建设监控体系。阶段一命令行巡检 定时脚本。先解决“有没有数据”的问题。这个阶段不需要引入额外系统靠 shell 脚本 cron 定时保存快照就能在出故障时拿出事发的状态。阶段二Prometheus Grafana。把指标采集标准化接入可视化平台。这一步能极大缩短定位问题的平均时长因为你可以回看趋势图而不是只盯一眼某一个瞬间。建议优先接入温度、HBM 内存、AI Core 使用率、AI CPU 使用率和功耗五个指标。阶段三告警规则 工单联动。有了历史数据后阈值就可以定得更精确。告警要分层比如温度 85°C 时发 Warning95°C 时发 Critical别一上来就全部 P0 轰炸。告警渠道可以是钉钉、企业微信或者飞书机器人Prometheus Alertmanager 都能原生支持。5.2 告警阈值怎么定才不“狼来了”告警阈值设置是一门平衡艺术。设太松出了问题没人管设太紧天天有告警最后大家都麻木了真出事反而没人看。我一般参考这个逻辑温度Warning 85°CCritical 95°C。因为 90°C 以上就开始有降频风险95°C 以上就该人工介入。HBM 内存使用率Warning 85%Critical 95%。但这里要配合进程数据看因为有些模型就是设计为“能塞满就塞满”。AI Core 使用率这个不太适合直接告警更适合做“下限告警”。比如训练任务正在跑但某颗卡 AI Core 长期低于 20%说明任务异常而不是“使用率太低”需要告警。功耗只在超过额定功耗或者接近电源上限时告警。告警规则最好是配完以后观察一到两周根据历史数据再去微调阈值。我见过太多人第一天就把阈值拉得很满结果第二天就被告警轰炸第三天就关掉告警这样就完全失去了监控的意义。一开始宁可少配几个核心指标的告警也不要贪多求全。5.3 可观测性的持续优化方向等到指标、告警、面板都跑通之后还可以考虑把 NPU 监控跟训练任务的元数据打通。比如在指标里带上模型名称、训练框架版本、数据集版本这些标签方便训练失败时回溯是“模型代码改动”还是“服务器硬件异常”导致的性能劣化。更进一步还可以把监控数据和日志系统联动。npu-smi info能告诉我们“发生了什么”但“为什么发生”往往需要看 CANN 日志、算子日志、甚至业务日志。我当时踩过一个坑某个算子在特定 shape 下触发编译异常芯片状态看起来很健康但训练任务一直失败。如果只盯npu-smi这个问题永远不会暴露必须结合日志链路才能定位。6. 个人踩坑总结关于npu-smi的几点实务心得6.1 先确认驱动版本再谈参数解析不同版本的 CANN 和驱动npu-smi的输出格式并不完全一样。早期版本里 HBM 内存可能显示为DDR后来才拆出更细的分类。解析脚本里最忌讳的就是写死文本格式一旦驱动升级采集程序就挂。稳妥的做法是在脚本启动时先跑一遍npu-smi info并缓存输出再做字符串匹配匹配不到时打印完整原始输出方便快速排查而不是静默失败。6.2 巡检记录要留痕别嫌日志占磁盘我见过不少运维同学习惯“看一眼没问题就走了”。但对于 NPU 这种高功耗、高发热的设备很多故障是缓慢劣化的。今天 80°C明天 85°C后天 90°C如果不留痕根本看不出趋势。哪怕只是每天定时跑一次npu-smi info把日志丢进对象存储或者归档目录一个月后再回看很多异常都有迹可循。6.3 用npu-smi info -t process反查业务容器少走很多弯路生产环境里NPU 显存被占满、芯片被烧高往往是因为有人起了多个任务而不自知。我养成了一个习惯只要看到显存占用率异常第一件事就是执行npu-smi info -t process把进程列表和预期任务对照一遍。很多时候所谓“卡死了”“芯片坏了”其实就是两个任务在抢同一颗芯片的资源把显存挤爆了。这个排查步骤通常十秒钟就能完成但能省下后面一大堆查日志的时间。6.4 别把 AI Core 使用率当成唯一的健康度指标AI Core 使用率很高不代表任务很健康。如果模型在跑一个很低效的算子实现AI Core 可能也能跑到 90%但整体吞吐就是上不去。反之AI Core 使用率低也不一定就是故障可能有数据预取、图编译等阶段占据大量时间。监控的时候一定要结合功耗、内存、温度、任务耗时一起看才能对芯片状态有一个完整的判断。7. 最后补一点小技巧把npu-smi info“喂”给自动化运维平台如果你们团队已经有自研的运维平台或者用 Ansible、SaltStack 这类工具做批量运维不要忽略npu-smi info这个数据源的接入价值。批量巡检 100 台服务器时逐台登录执行命令显然不可取但把采集逻辑写成一个被调用的脚本或者 Agent 插件然后聚合所有服务器的输出到统一视图效率和体验都会完全不同。我曾经帮一个平台团队做过一个很小的工具通过 SSH 批量执行npu-smi info -t usages再把结果解析成 JSON 推到消息队列最后在前端页面渲染成一张集群资源热力图。投入不大但一下子解决了他们“几百张卡有多少在空转、多少在跑任务”的痛点。这里的核心思想是npu-smi info是原始数据源但它的价值要靠二次加工才能完全释放。另外一个小提醒批量执行npu-smi的时候不要用同一个用户并发起几十上百个进程同时跑这会让驱动层的锁变得非常严重反而拖垮被管理节点。建议加上节流控制每个节点最多一两个并发查询间隔拉开到几十秒这样数据既够用又不会对业务产生可见影响。