1. 从一张看不懂的监控截图说起第一次在昇腾服务器上敲下npu-smi info的时候我盯着满屏的表格愣了好一会儿。左边一列是 NPU 编号右边跟着一堆HBM、AICore、Chip、Health、Power、Temp之类的字段数字密密麻麻看着像那么回事但真要我判断这块卡现在到底健不健康、有没有在干活、瓶颈在哪说实话心里没底。后来带团队做推理服务压测问题就来了业务侧反馈吞吐上不去日志里也没报错模型加载正常进程也活着。这时候能救命的只有npu-smi info——它相当于昇腾 NPU 的体检报告单把芯片利用率、显存占用、功耗、温度、健康状态一次性摊在你面前。问题是这张报告单你得会读。读错了你会把正常待机当成卡死了也会把显存泄漏当成业务量太大。这篇内容就是把我这几年在昇腾环境里读npu-smi info的经验完整拆一遍。它适合刚接触昇腾 NPU 的算法工程师、负责推理服务运维的 SRE、以及做国产化算力适配的开发者。核心就一件事把npu-smi info每一列指标的含义、正常范围、异常特征、以及它和真实业务性能之间的对应关系讲透让你下次看到这张表能像看自己体检报告一样一眼抓住重点。需要先说明一点npu-smi是昇腾提供的一套命令行管理工具info只是它众多子命令中的一个负责输出设备与芯片的实时状态快照。它不依赖任何额外的监控组件装好驱动和固件就能用这也是它成为排查第一入口的原因。下面所有内容都围绕这个命令展开涉及的具体数值范围基于常见昇腾型号的公开资料和实际观察不同型号、不同固件版本会有差异请以你手头设备的实际表现为准。2. npu-smi info 到底打印了什么2.1 输出结构三层信息从粗到细npu-smi info的输出不是一张表而是分区块的。理解它的结构比记住某个数字更重要。典型输出大致分三块第一块是设备级概览通常以NPU为行标识给出每张卡的编号、健康状态、功耗、温度、以及整体资源占用。这一块回答的是这张卡活着吗、烫不烫、费不费电。第二块是芯片级明细以Chip为行标识把一张卡上的多个芯片比如昇腾 910 系列一颗封装里可能有多个 die分别列出给出AICore利用率、HBM使用率等更细的指标。这一块回答的是算力用起来了吗、显存够不够。第三块是进程级信息通过npu-smi info -t proc-mem之类的子参数可以拉出每个进程占用的显存。这一块回答的是到底是谁在吃显存。很多人只盯着第一块看觉得卡在、温度正常就万事大吉结果显存被某个僵尸进程占满新任务死活起不来。所以读这张表必须三层一起看。2.2 为什么是这些指标而不是别的你可能会问为什么npu-smi info偏偏选了 AICore、HBM、功耗、温度这几个维度这背后是 NPU 的工作模型决定的。NPU 和 CPU 最大的区别在于它是数据流驱动的大量矩阵乘加运算在 AICoreAI 计算核心里并行跑而支撑这种高并发计算的是 HBM高带宽显存它负责把权重和激活值以极高带宽喂给计算单元。所以AICore 利用率反映计算单元忙不忙是算力是否被榨干的核心指标HBM 使用率反映显存够不够直接决定你能开多大 batch、能不能多实例共存功耗和温度是这两个高密度部件工作的副产品也是稳定性的先行指标。换句话说这四个指标构成了一个闭环算力在跑 → 吃显存 → 发热耗电。任何一个环节异常都会在另外几个上留下痕迹。理解了这层因果你读表就不是死记数字而是顺着逻辑推。2.3 一个容易被忽略的前提驱动与固件版本在解读任何指标之前先确认一件事npu-smi的输出版本和你的驱动、固件版本是匹配的。不同版本的npu-smi字段名和排列顺序会有微调比如早期版本可能把某些信息合并显示新版本拆得更细。实操建议拿到一台新机器先跑npu-smi info看能不能正常出表再跑npu-smi -v看工具版本对照官方文档确认字段含义。如果npu-smi info直接报错或者输出残缺八成是驱动没装好或者设备没被识别这时候纠结指标没意义先把环境弄干净。提示npu-smi info是快照式输出执行一次打印一次。想看连续变化得配合watch或者写脚本循环采集这一点后面会专门讲。3. 逐列拆解每个数字背后的含义与正常区间3.1 NPU 编号与 Health先确认人在不在输出最左边通常是NPU编号从 0 开始递增。多卡机器上这个编号就是你后续指定设备时用的 ID比如ASCEND_RT_VISIBLE_DEVICES0,1里的 0 和 1 就对应这里。紧挨着的是Health字段一般显示OK或Alarm、Warning之类。这是第一优先级要看的字段。如果这里不是 OK后面所有性能指标都不用看了先处理硬件告警。常见的非 OK 状态包括温度过高触发降频、ECC 显存错误累积、供电异常等。我踩过的一个坑有次压测中途吞吐突然掉一半npu-smi info里 Health 显示Warning但业务日志毫无异常。后来查出来是某颗芯片温度触顶硬件自动降频保护。如果当时只看 AICore 利用率它确实降了很容易误判成业务代码效率低方向就全错了。Health 是总开关先看它。3.2 AICore 利用率算力到底用了几成AICore这一列有的版本叫AICore(%)或Utilization是大家最关心的。它表示在采样周期内AI 计算核心处于忙碌状态的时间占比。正常区间怎么理解分场景场景AICore 典型值说明空闲待机0% ~ 5%没有任务或任务在 CPU 侧准备数据推理服务正常40% ~ 80%有稳定请求计算与数据搬运交替训练/压测满载85% ~ 99%计算密集接近算力上限长期 100%需警惕可能是死循环或异常任务占满这里有个反直觉的点AICore 不是越高越好。推理场景下如果它长期贴着 100%往往说明数据预处理在 CPU 上做跟不上或者 batch 设置不合理导致计算单元空转等待。真正健康的推理服务AICore 应该在一个区间内波动而不是钉死在顶部。另一个坑npu-smi info的 AICore 是瞬时采样值不是累计平均值。你执行命令那一瞬间它可能正好在等数据显示 20%但实际平均利用率有 70%。所以单次采样不可信必须连续看。我一般会watch -n 1 npu-smi info盯上一两分钟看它的波动形态。3.3 HBM 使用率显存是硬约束HBM这一列可能显示为HBM-Usage或Memory-Usage给出显存已用容量和总量通常格式是已用 / 总量单位 MB 或 GB。显存是 NPU 上最刚性的资源因为它不像 CPU 内存可以 swap。一旦 HBM 打满新任务直接 OOM 失败没有任何缓冲余地。所以这一列要重点盯两个东西绝对值还剩多少余量。如果余量低于模型单次推理的峰值需求随时可能崩。增长趋势是不是在缓慢爬升。稳定服务的显存占用应该是平的如果看到它像楼梯一样一级级往上走基本可以判定显存泄漏。显存泄漏是推理服务里最阴险的问题之一。它不会立刻报错而是跑几个小时甚至几天后突然 OOM。定位方法就是定期采集npu-smi info的 HBM 数值画成曲线。一旦发现单调上升再配合npu-smi info -t proc-mem找到具体是哪个进程在涨问题就锁定了。3.4 功耗与温度稳定性的先行指标Power功耗单位 W和Temp温度单位 ℃这两列经常被忽略但它们是最早发出预警的信号。功耗方面昇腾 NPU 有明确的 TDP热设计功耗上限。正常满载时功耗会接近但不超过这个值。如果发现功耗异常低比如满载任务下只有标称的一半可能是芯片被降频了原因通常是温度或供电。如果功耗异常高且波动剧烈要排查是不是有异常任务在反复申请释放资源。温度方面一般芯片结温在 80℃ 以下算安全超过 85℃ 就要警惕接近 90℃ 硬件会主动降频。温度问题往往是环境问题机箱风道堵塞、机房空调故障、相邻卡互相烘烤。我遇到过一台 8 卡服务器中间两张卡温度比边缘高 15℃原因是风道设计导致中间散热差最后靠调整卡的排布和加导风罩解决。把功耗和温度、AICore 放一起看能推出很多结论。比如 AICore 高但功耗低可能是降频AICore 低但温度高可能是散热坏了或者有别的热源。3.5 一张速查表指标、正常范围与异常含义为了让你现场排查时能快速对照我把核心指标整理成下面这张表。再次强调具体数值因型号而异这里给的是经验区间。指标正常范围异常表现可能原因HealthOKAlarm/Warning温度、ECC、供电异常AICore场景相关40%~99%长期 0% 或长期 100%任务未启动 / 数据瓶颈或死循环HBM有余量且平稳接近满载或持续上升batch 过大 / 显存泄漏Power接近但不超过 TDP异常低或剧烈波动降频 / 异常任务Temp 85℃ 85℃ 并持续散热问题这张表建议截图存手机里现场排查时比翻文档快得多。4. 把静态快照变成动态监控4.1 为什么单次 npu-smi info 会骗你前面反复提到单次采样不可信这里展开说清楚原因。npu-smi info打印的是执行那一瞬间的状态。而 NPU 上的负载是高度动态的一个推理请求进来数据从 Host 搬到 DeviceAICore 开始算算完结果搬回去这中间 AICore 有大量时间在等数据。你随机采样可能正好采到等待期看到 10%也可能采到计算期看到 95%。同一个健康服务两次采样能差出十倍。所以判断一个服务是否健康靠的是一段时间的统计特征而不是某个点。具体要看均值、峰值、波动幅度、以及趋势。这些都得靠连续采集才能得到。4.2 用 watch 做快速观察最简单的动态观察方式就是watchwatch -n 1 npu-smi info这会让命令每秒刷新一次你盯着看一两分钟就能对波动形态有个直观感受。适合快速判断这卡到底在不在干活。但watch有个缺点它把整张表刷来刷去你很难对比历史值。而且它不落盘看完就没了。所以它只适合临时快速观察不适合长期监控。4.3 写脚本采集时序数据要做真正的监控得把数据采下来存起来。npu-smi info支持一些机器可读的输出格式具体参数因版本而异常见的有指定输出字段的选项可以配合脚本解析。思路是这样的定时执行npu-smi info把关键字段NPU 编号、AICore、HBM、Power、Temp抽出来带上时间戳写进日志或时序数据库。伪代码大概长这样while true; do timestamp$(date %Y-%m-%d %H:%M:%S) # 解析 npu-smi info 输出提取关键字段 # 具体解析逻辑依赖你的 npu-smi 版本和输出格式 echo $timestamp, $npu_id, $aicore, $hbm, $power, $temp npu_metrics.log sleep 5 done采集频率建议 5 到 10 秒一次。太密了日志膨胀快太疏了抓不到瞬时尖峰。5 秒是个比较平衡的值。采下来的数据可以喂给 Prometheus Grafana 这类通用监控栈也可以先用最简单的文本 脚本画图。关键不是工具多高级而是你得有历史数据可回溯。出问题时能翻出过去几小时的曲线定位效率完全不是一个量级。4.4 采集时容易踩的三个坑第一个坑采集脚本本身消耗资源。如果采集频率过高、解析逻辑太重脚本自己会占 CPU间接影响业务。所以解析逻辑要轻能用 shell 就别上重型语言。第二个坑多卡机器上字段错位。多卡输出里每张卡占几行解析时如果按固定行号取一旦某张卡状态变化导致行数变化就会错位。稳妥做法是按 NPU 编号做锚点解析而不是按行号。第三个坑忽略时间同步。如果采集脚本跑在多台机器上时间没同步事后对齐曲线时会发现对不上。上 NTP 是基本操作。5. 从指标异常到根因几条实战排查链路5.1 吞吐上不去AICore 却不高这是最典型的看起来没瓶颈其实有瓶颈的场景。业务反馈 QPS 上不去你一看 AICore 只有 30%第一反应可能是算力没用满加并发。但加了并发还是上不去为什么因为瓶颈不在 NPU而在数据供给。NPU 算得再快数据从 CPU 内存搬到 HBM 的速度跟不上AICore 就得饿着。这时候 AICore 低是结果不是原因。排查链路先看 AICore 波动形态如果是高一下、低很久的锯齿状基本确认是数据搬运瓶颈。然后去查 Host 侧的预处理代码——是不是在做耗时的图像解码、tokenize、或者同步 IO。优化方向是把预处理并行化、用更高效的库、或者做数据预取。我做过一个图像推理服务AICore 死活上不去最后发现是 Python 的 PIL 解码成了瓶颈换成更快的解码库后 AICore 直接从 30% 拉到 70%QPS 翻倍。NPU 监控指标低不代表 NPU 是瓶颈这点一定要记住。5.2 显存缓慢上涨服务几天后 OOM前面提过显存泄漏这里给完整排查链路。第一步确认是泄漏而不是正常波动。正常服务的 HBM 占用应该是平的有小的起伏但不会单调上升。采集几小时数据画曲线如果斜率稳定为正基本确认泄漏。第二步定位进程。用npu-smi info -t proc-mem拉出每个进程的显存占用对比不同时间点看是哪个进程在涨。第三步定位代码。常见泄漏点包括推理框架的缓存没清理、动态 shape 导致反复申请显存、异常分支里忘了释放 tensor。昇腾的框架一般有显存池机制如果池子配置不当也会表现为占用只增不减。第四步验证修复。改完后重新压测盯 HBM 曲线至少跑够原来出问题的时间长度确认平稳才算修好。5.3 温度告警引发的性能雪崩温度问题的特点是连锁反应温度升高 → 硬件降频 → AICore 利用率下降 → 业务吞吐下降 → 但业务侧只看到变慢了看不到温度。排查链路先看npu-smi info的 Temp 和 Health。如果 Temp 偏高且 Health 有告警基本锁定。然后查环境机房温度、机箱风道、风扇转速、相邻卡温度。很多时候不是单卡问题而是整机散热设计问题。处理方式分两层短期可以限制负载、错峰调度长期要解决散热比如调整卡间距、加导风罩、改善机房空调。温度问题不解决性能永远上不去而且会缩短硬件寿命。5.4 功耗异常被忽视的线索功耗异常有两种典型表现。一种是满载任务下功耗偏低说明芯片没跑满可能被降频了去查温度和供电。另一种是空闲时功耗偏高说明有后台任务在偷偷跑去查进程列表。功耗这个指标单独看意义不大但和 AICore、Temp 组合看能快速区分真忙和假忙。真忙是 AICore 高、功耗高、温度高假忙是 AICore 高但功耗低降频或者 AICore 低但功耗高异常任务。6. 几个只有踩过才知道的细节6.1 多芯片封装下的卡与芯片不是一回事昇腾有些型号一颗封装里有多个芯片dienpu-smi info会分别列出。这时候一张卡和一个计算单元不是一一对应的。做资源调度时如果按卡分配可能出现一张卡里某个芯片满载、另一个空闲的情况利用率统计也会失真。实操建议调度粒度尽量细到芯片级监控时也按芯片维度采集别只看卡级平均。卡级平均会把芯片间的不均衡掩盖掉。6.2 容器环境里的可见性问题在容器里跑npu-smi info看到的可能是宿主机全部设备也可能是被限制后的子集取决于容器怎么挂载设备。如果发现容器里看到的卡数和预期不符先查设备挂载配置别急着怀疑驱动。另外容器里跑npu-smi有时需要额外的权限或挂载/dev下的设备节点。这些环境配置问题会伪装成监控工具坏了实际是权限没给够。6.3 采样时机对判断的影响前面说过单次采样不可信这里补充一个细节采样时机要避开业务启动和停止的瞬间。服务刚启动时模型加载会瞬间吃满显存和算力这时候采样会看到异常高的值服务停止时资源释放又会让指标骤降。这些瞬态不代表稳态性能。判断稳态性能要在服务跑稳之后、持续压测期间采样。我一般会等服务起来后先跑 5 分钟预热再开始正式采集。6.4 别把 npu-smi 当唯一真相npu-smi info很强但它只是硬件视角。业务性能问题可能出在框架层、通信层、甚至网络层。NPU 指标正常不代表服务没问题NPU 指标异常也不一定就是 NPU 的锅。正确的姿势是把 NPU 指标和业务指标、系统指标放一起看。NPU 的 AICore 对应业务的 QPSNPU 的 HBM 对应框架的显存日志NPU 的 Temp 对应机房的温度监控。多源数据交叉验证才能快速定位真正的根因。7. 我个人的使用习惯最后分享几个我日常用下来觉得最省事的习惯。第一新机器上手先跑一遍基线。空载状态下把npu-smi info的输出存一份记下空闲时的功耗、温度、显存占用。以后任何异常先和基线比差异一目了然。第二压测时必开连续采集。不管问题最后出在哪有历史曲线在手排查至少省一半时间。我现在的习惯是任何压测都挂一个采集脚本数据留着哪怕当时没问题事后复盘也用得上。第三Health 字段永远第一个看。养成肌肉记忆看到非 OK 就先处理硬件别在软件层瞎折腾。第四温度问题优先怀疑环境。芯片本身很少无缘无故过热八成是散热环境的问题。先查机房、查风道比查代码快得多。npu-smi info这个命令看着简单但真把它读透能省下大量盲猜的时间。它给的是硬件最原始的信号而排查问题的本质就是把这些原始信号翻译成业务语言。翻译得越准定位越快。这套东西没有捷径就是多看、多采、多对比看多了自然就有感觉了。