企业官网建设流程全解析

1. 昇腾NPU监控的起点：为什么npu-smi info是绕不开的第一课

搞昇腾NPU开发或者运维的人，迟早会碰到一个场景：模型跑在昇腾卡上，训练速度不对劲，或者推理延迟忽高忽低，但你看了一眼系统，CPU和内存都挺正常，GPU那套监控工具又完全用不上。这时候你需要的，就是昇腾生态里最基础也最核心的一个命令行工具——npu-smi info。

这个命令看起来简单，敲下去就出一屏信息，但真正能把这一屏信息读透、读准，并且据此定位性能瓶颈的人，其实并不多。我见过不少刚接触昇腾的开发者，跑完npu-smi info之后只知道看个温度，其他字段一概略过，等到出了问题再回头翻文档，效率极低。这篇文章就是要把这个命令的每一个字段、每一种用法、以及它背后对应的硬件状态和性能含义，彻底讲清楚。

npu-smi全称是NPU System Management Interface，是华为昇腾提供的一套命令行管理工具，功能定位类似于NVIDIA的nvidia-smi。它能做的事情包括：查看NPU基本信息、监控实时状态、查询和设置功耗与频率、管理ECC错误、查看进程占用、甚至做一些固件和驱动的维护操作。而npu-smi info是其中使用频率最高的子命令，没有之一。

这篇文章适合谁看？如果你是刚拿到昇腾开发环境、准备跑第一个模型的算法工程师，这篇能帮你建立对NPU运行状态的基本认知；如果你是负责推理服务部署的运维人员，这篇能帮你快速定位卡级别的问题；如果你已经在用昇腾做训练，但性能始终调不到预期，这篇能帮你从监控数据里找到调优的切入点。我不打算只罗列命令参数，而是把每个字段背后的硬件逻辑和性能含义都拆开讲，让你看完之后能真正“读懂”这块卡在干什么。

2. npu-smi info输出的逐字段拆解：每个数字背后是什么

2.1 整体输出结构长什么样

在终端敲下npu-smi info，你会看到类似下面这样的输出（不同版本和型号会有差异，但结构基本一致）：

+------------------------------------------------------------------------------------------------+ | npu-smi 23.0.3 Version: 23.0.3 | +-------------------+-----------------+----------------------------------------------------------+ | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)| | Chip | Bus-Id | AICore(%) Memory-Usage(MB) | +===================+=================+==========================================================+ | 0 910B | OK | 92.3 45 0 / 0 | | 0 | 0000:81:00.0 | 0 0 / 65536 | +===================+=================+==========================================================+ | 1 910B | OK | 89.7 43 0 / 0 | | 0 | 0000:82:00.0 | 0 0 / 65536 | +===================+=================+==========================================================+

这个表格的信息密度很高，但很多人只扫一眼温度和显存就过去了。实际上每一列都值得细看。

2.2 NPU编号与Chip编号：一张卡不一定只有一个“芯”

最左边两列是NPU和Chip。NPU是设备编号，从0开始递增，代表系统识别到的第几张NPU卡。Chip是芯片编号，这个字段容易被忽略，但它很重要——部分昇腾型号（比如910B系列）在一张物理卡上可能集成多个芯片（Die），每个芯片独立报告自己的状态。

这意味着什么？如果你看到NPU 0下面有Chip 0和Chip 1两行，那说明这张卡上有两个计算单元，它们各自有独立的温度、功耗和显存。你在分配任务的时候，如果只按NPU编号来分配，可能会让两个芯片一个满载一个空闲，资源利用率直接打对折。正确的做法是在代码或调度层面同时指定NPU编号和Chip编号，确保负载均衡。

2.3 Health状态：不只是“OK”和“Not OK”的区别

Health列显示的是芯片的健康状态，常见值有OK、Warning、Alarm、Critical等。大部分人看到OK就放心了，看到非OK就慌了。但实际情况比这复杂。

OK表示当前没有检测到硬件层面的异常。但注意，这只代表硬件自检通过，不代表你的任务跑得好。我遇到过Health显示OK但实际计算吞吐只有理论值30%的情况，原因后面会讲。

当Health显示Warning时，通常是温度偏高、功耗接近上限、或者ECC纠错计数在增长。这时候不一定要立刻停机，但必须开始关注。Alarm和Critical则意味着需要立即介入，继续跑任务可能导致硬件损伤或数据错误。

提示：Health状态是周期性刷新的，不是实时变化的。如果你刚跑完一个高负载任务，建议等几秒再查一次，让状态稳定下来。

2.4 Power和Temp：功耗与温度的联动关系

Power(W)是当前芯片的实时功耗，单位瓦特。Temp(C)是芯片结温，单位摄氏度。这两个数据必须结合起来看。

昇腾910B的典型热设计功耗（TDP）在300W到400W之间（具体取决于型号和散热方案）。如果你看到功耗长期贴着TDP上限跑，同时温度也在85度以上，那说明散热系统已经在极限工作了。这时候即使Health还显示OK，你也应该考虑降低负载或者改善散热，否则降频迟早会发生。

反过来，如果你看到功耗只有几十瓦，温度也很低，但任务跑得特别慢，那问题可能不在硬件层面，而是软件调度或者模型本身的问题。这时候盯着npu-smi info看是看不出答案的，需要往下查进程和内存。

2.5 AICore利用率：最容易被误读的指标

AICore(%)是AI核心的利用率，这个数字是整篇输出里最容易被误读的。很多人以为它像CPU利用率一样，越高越好，低了就是有问题。实际上不是这么回事。

AICore利用率反映的是在采样周期内，AI核心有多少时间处于“活跃”状态。注意，是“活跃”不是“高效”。一个任务如果频繁在AI核心和主机内存之间搬运数据，AI核心可能看起来很忙（利用率高），但实际计算吞吐很低，因为大部分时间花在等数据上了。

更关键的是，npu-smi info默认的采样周期比较粗，它给出的AICore利用率是一个瞬时快照，不是一段时间内的平均值。你连续敲几次命令，可能会看到数字在0%和90%之间跳。这不一定代表有问题，可能只是采样时机不巧。

要真正评估计算效率，不能只看AICore利用率，还要结合显存带宽、数据搬运量、以及模型本身的计算密度来综合判断。这个后面会展开讲。

2.6 Memory-Usage：显存占用的两个数字

Memory-Usage(MB)显示的是已用/总量，单位是MB。昇腾910B单芯片通常有64GB HBM显存（不同型号有差异），所以你会看到类似0 / 65536这样的数字。

这里有个细节：显存占用包括模型权重、激活值、梯度、优化器状态、以及框架自身的开销。很多人算显存需求的时候只算模型权重大小，结果跑起来发现OOM（Out of Memory）。以训练为例，一个10亿参数的模型，FP16权重约2GB，但加上梯度、优化器状态（Adam的话是权重的2倍）、激活值，实际占用可能是权重的4到6倍。所以看到显存快满了，先别急着换卡，算一下是不是自己的显存估算方法有问题。

另外，显存释放不是即时的。任务结束后，框架可能还持有显存不释放，这时候npu-smi info会显示显存仍然被占用。如果你确认任务已经退出但显存没释放，可以查一下是否有残留进程。

2.7 Hugepages-Usage：大页内存的使用情况

Hugepages-Usage(page)这一列显示的是大页内存的使用量。大页内存对NPU计算很重要，因为它能减少TLB（Translation Lookaside Buffer）缺失，提高数据搬运效率。如果这一列显示0 / 0，说明系统没有配置大页内存，或者当前任务没有使用大页内存。

对于高性能训练和推理场景，建议配置大页内存。具体配置方法后面会讲。这里先记住一点：大页内存没配好，数据搬运效率可能下降10%到20%，这个损失在规模化训练中非常可观。

3. 从info到调优：用npu-smi的其他子命令定位性能瓶颈

3.1 npu-smi info -t 系列：按需查询特定信息

npu-smi info给的是概览，但调优的时候你需要更细的数据。npu-smi info -t后面可以跟不同的参数来查询特定类型的信息。常用的有：

• npu-smi info -t usages -i 0：查看指定NPU的详细使用率，包括AICore、内存带宽、HBM利用率等。
• npu-smi info -t temp -i 0：查看温度详情，包括各传感器的读数。
• npu-smi info -t power -i 0：查看功耗详情，包括当前功耗、功耗上限、以及功耗封顶的原因。
• npu-smi info -t memory -i 0：查看显存详情，包括各进程的显存占用。

这些子命令的输出比概览详细得多。比如-t usages会给出AICore利用率、HBM带宽利用率、以及L2缓存命中率等数据。HBM带宽利用率是判断是否遇到“内存墙”的关键指标——如果AICore利用率不高但HBM带宽利用率很高，说明瓶颈在数据搬运，不在计算。

3.2 npu-smi info -t proc：谁在占用NPU

npu-smi info -t proc -i 0可以查看指定NPU上运行的进程信息，包括进程ID、进程名、以及该进程占用的显存。这个命令在排查“显存被谁吃了”的时候特别有用。

我遇到过一种情况：训练任务异常退出，但显存没有释放，导致后续任务无法启动。用npu-smi info -t proc一查，发现有一个僵尸进程还挂着。直接kill掉之后显存就释放了。如果没有这个命令，你可能得重启整个节点，那代价就大了。

3.3 npu-smi info -t ecc：ECC错误统计

ECC（Error Correcting Code）错误是硬件层面的内存纠错。npu-smi info -t ecc -i 0可以查看ECC错误的统计信息，包括可纠正错误（Correctable Error）和不可纠正错误（Uncorrectable Error）的计数。

可纠正错误偶尔出现一两次问题不大，硬件会自动纠正。但如果计数在持续增长，说明显存颗粒可能在老化或者散热有问题。不可纠正错误则意味着数据已经损坏，必须立即停止任务并检查硬件。

注意：ECC错误计数是累积的，不会自动清零。你需要记录基线值，然后观察增量。如果增量在短时间内明显上升，那就是预警信号。

3.4 用npu-smi做功耗和频率的实时监控

npu-smi info -t power -i 0可以查看当前功耗和功耗上限。但如果你想做实时监控，可以配合watch命令：

watch -n 1 npu-smi info -t power -i 0

这样每秒刷新一次功耗数据。你可以一边跑任务一边观察功耗曲线。如果功耗频繁触顶然后掉下来，说明芯片在反复降频，这时候需要考虑降低batch size或者优化数据加载流程。

频率信息可以通过npu-smi info -t freq -i 0查看（部分版本支持）。如果发现频率低于标称值，且温度正常，那可能是功耗墙限制，需要调整功耗上限。

4. 实战调优：从监控数据到具体优化动作

4.1 场景一：AICore利用率低但任务跑得慢

这是最常见的性能问题。你跑一个训练任务，npu-smi info显示AICore利用率只有30%到40%，但任务就是快不起来。这时候按下面的顺序排查：

第一步，查数据加载。用npu-smi info -t usages -i 0看HBM带宽利用率。如果带宽利用率也很低，说明NPU在等数据。这时候问题大概率出在数据加载管道上——可能是磁盘IO慢、可能是数据预处理在CPU上成了瓶颈、也可能是DataLoader的worker数量不够。解决办法包括：增加DataLoader的num_workers、把数据预处理放到NPU上做、或者用更快的存储介质。

第二步，查batch size。batch size太小会导致每次计算的数据量不足以填满AI核心的并行度。昇腾910B的AI核心规模很大，batch size太小的话，核心利用率自然上不去。可以尝试逐步增大batch size，观察AICore利用率是否上升。但注意不要超过显存容量。

第三步，查算子效率。如果数据加载和batch size都没问题，但AICore利用率还是低，那可能是模型里有一些算子在NPU上效率不高。这时候需要用昇腾的性能分析工具（如Ascend Profiler）来定位具体是哪些算子拖了后腿。

4.2 场景二：显存够但OOM报错

有时候npu-smi info显示显存还有不少空闲，但任务就是报OOM。这种情况通常有几个原因：

一是显存碎片化。长时间运行的任务反复申请和释放显存，可能导致碎片化，虽然总空闲量够，但没有连续的大块显存可用。解决办法是尽量复用显存，避免频繁的动态申请。

二是框架的显存预分配策略。有些框架会一次性预分配一大块显存，即使实际用量没那么多，npu-smi info也会显示已占用。这时候需要看框架的显存管理配置，调整预分配比例。

三是多进程共享显存时的配额问题。如果多个进程共享一张NPU，每个进程能用的显存可能有限制。需要检查是否有显存配额配置。

4.3 场景三：温度过高导致降频

昇腾NPU在温度超过一定阈值后会自动降频以保护硬件。如果你发现任务跑着跑着突然变慢，同时npu-smi info显示温度在85度以上，那基本可以确认是降频了。

解决办法分几个层面：

散热层面：检查服务器风扇是否正常运转、散热片是否积灰、机房环境温度是否过高。这些是物理层面的问题，但往往最容易被忽略。

功耗层面：用npu-smi info -t power -i 0查看功耗上限，如果功耗上限设得过高，可以适当调低。功耗降下来，温度自然也会降。具体命令是npu-smi set -t power-limit -i 0 -d <value>（需要管理员权限）。

任务层面：降低batch size或者增加梯度累积步数，减少单位时间内的计算量，也能降低温度。

4.4 场景四：多卡训练时负载不均衡

多卡训练时，如果npu-smi info显示有的卡AICore利用率90%，有的卡只有50%，那说明负载不均衡。常见原因包括：

数据并行时，如果数据分配不均匀，某些卡分到的数据多，某些卡分到的少。解决办法是确保数据切分是均匀的，并且使用正确的分布式采样器。

模型并行时，如果模型切分不合理，某些卡上的计算量大，某些卡上的计算量小。这时候需要重新设计模型切分策略，尽量让各卡的计算量均衡。

还有一种情况是通信瓶颈。如果卡间的通信带宽不够，某些卡可能在等通信完成，导致利用率上不去。这时候需要检查通信拓扑和通信库的配置。

5. 那些文档里不会写的实操经验

5.1 npu-smi的输出会“骗人”

npu-smi info给出的AICore利用率是瞬时值，不是平均值。这意味着你看到的数字可能具有很大的偶然性。我建议的做法是：连续采样多次，取平均值或者看趋势。可以用简单的shell脚本实现：

for i in $(seq 1 10); do npu-smi info -t usages -i 0 | grep AICore sleep 1 done

这样你能看到AICore利用率在10秒内的变化情况，比单次快照靠谱得多。

5.2 大页内存配置的坑

前面提到大页内存对性能有影响，但配置大页内存有几个坑：

第一，大页内存是在系统启动时预留的，运行中不能动态调整。所以如果你发现需要大页内存，得修改GRUB配置并重启系统。

第二，大页内存的大小要合理。配得太少不够用，配得太多浪费内存。一般建议根据模型大小和并发任务数来估算。

第三，不是所有框架都默认使用大页内存。有些框架需要显式配置才能启用。具体配置方法要看框架的文档。

5.3 进程残留导致显存不释放

这个问题在调试阶段特别常见。你的训练脚本因为bug崩了，但显存没有释放。npu-smi info显示显存还被占着，但你已经找不到那个进程了。

这时候用npu-smi info -t proc -i 0查看进程列表。如果列表里有进程但你已经kill过了，可能是僵尸进程。用ps -ef | grep <pid>确认进程状态，必要时用kill -9强制终止。

如果进程列表是空的但显存仍然被占用，那可能是驱动层面的问题。这时候只能尝试重置NPU（npu-smi set -t reset -i 0），或者重启节点。

5.4 不同版本的npu-smi输出格式有差异

昇腾的软件栈更新比较频繁，不同版本的npu-smi输出格式可能有差异。比如有些版本把AICore利用率放在第一行，有些版本放在第二行。有些版本有Hugepages-Usage列，有些版本没有。

这意味着你不能把解析npu-smi输出的脚本写死。建议用grep和awk做模糊匹配，而不是按固定位置截取。比如要提取AICore利用率，可以用：

npu-smi info -t usages -i 0 | grep -i "aicore" | awk '{print $NF}'

这样即使格式有变化，只要关键字还在，脚本就能正常工作。

5.5 监控频率不要太密

有些人为了实时监控，把npu-smi的调用频率设得很高，比如每0.1秒一次。这样做有两个问题：一是npu-smi本身会消耗一定的CPU资源，频率太高会影响任务性能；二是高频采样得到的数据噪声很大，反而不好分析。

我的经验是：日常监控1秒一次足够了，性能分析时可以到0.5秒一次，但不要更密。如果需要更细粒度的数据，应该用昇腾提供的性能分析工具，而不是靠npu-smi。

6. 把npu-smi info纳入日常运维流程

6.1 建立基线数据

在系统稳定运行、任务正常的时候，记录一组npu-smi info的基线数据。包括：空闲时的功耗和温度、典型负载下的AICore利用率和显存占用、ECC错误计数等。

有了基线数据，后面出问题的时候就有了参照。比如你发现温度比基线高了10度，那说明散热可能出了问题；ECC错误计数比基线增长得快，那说明显存可能有隐患。

6.2 写一个简单的监控脚本

不需要复杂的监控系统，一个简单的shell脚本就能覆盖大部分日常需求：

#!/bin/bash LOG_FILE="/var/log/npu_monitor.log" while true; do TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") INFO=$(npu-smi info | grep -E "^\| [0-9]+") echo "$TIMESTAMP $INFO" >> $LOG_FILE sleep 60 done

这个脚本每分钟记录一次NPU状态，输出到日志文件。出问题的时候翻日志，就能看到状态变化的时间线。

6.3 设置告警阈值

基于基线数据，设置合理的告警阈值。比如：温度超过80度告警、功耗持续超过TDP的90%告警、ECC可纠正错误计数在1小时内增长超过10次告警。

告警方式可以很简单，比如在监控脚本里加一个判断，超过阈值就发邮件或者写系统日志。关键是要有告警，不能等问题严重了才发现。

6.4 定期检查固件和驱动版本

npu-smi info的第一行会显示npu-smi的版本号，这个版本号通常和固件、驱动版本是对应的。昇腾会不定期发布固件和驱动更新，修复已知问题、提升性能、增加新功能。

建议定期检查版本，如果发现有更新，评估后再决定是否升级。升级前一定要看release notes，确认新版本没有引入你不兼容的变更。

7. 从单卡监控到集群级可观测性

单张卡的npu-smi info能解决的问题是有限的。当你管理的是一个几十卡甚至上百卡的集群时，逐台登录执行npu-smi就不现实了。这时候需要把npu-smi的输出采集起来，汇聚到统一的监控平台。

常见的做法是：在每台节点上跑一个采集agent，定期执行npu-smi并把输出解析成结构化数据（比如JSON格式），然后推送到时序数据库（如Prometheus）或者日志平台（如Elasticsearch）。然后在Grafana之类的可视化工具里做仪表盘，展示集群级别的NPU利用率、温度分布、功耗趋势等。

这样做的好处是：你能一眼看到整个集群的健康状况，快速定位到异常的节点或卡。比如某个节点的温度明显高于其他节点，那可能是那个节点的散热有问题；某个卡的AICore利用率长期偏低，那可能是任务分配不均衡。

采集频率建议不要太密，集群规模大的话，每分钟一次就足够了。解析npu-smi输出的时候要注意版本兼容性，不同节点的npu-smi版本可能不一致，解析逻辑要能兼容多种格式。

另外，集群级监控还要考虑数据的保留策略。原始数据保留多长时间、聚合数据保留多长时间、什么时候做降采样，这些都需要根据实际需求来定。一般来说，原始数据保留一周到一个月，聚合数据保留半年到一年，是比较常见的做法。

我在实际运维中发现，集群级监控最大的价值不是“看当前状态”，而是“回溯问题”。当某个训练任务失败或者性能不达标时，你能翻出当时的历史数据，看看是哪个节点、哪张卡、在什么时间点出现了异常。这种回溯能力，是单卡npu-smi给不了的。