0
0

昇腾 NPU 监控工具选型：从 npu-smi 到 nputop 与集群可观测性

2026-10-17
工程实践与复盘

整理窗口：北京时间 2026-09-15 06:00—2026-09-16 06:00。来源是本次可访问到的聊天索引与公开资料，不是完整聊天导出。

问题起点

北京时间 2026-09-15 22:08 左右，你问：昇腾 NPU 有没有类似 nvtop 的便捷工具？

答案是有相近选择，但应按“临时查看、交互式单机监控、集群长期监控”三层选工具，而不是寻找一个在所有场景都完全等价于 nvtop 的程序。

第一层：原生基线工具 npu-smi

npu-smi info 是最稳妥的设备状态入口，适合先确认驱动是否识别设备，并查看健康、温度、功耗、AI Core 利用率、内存/HBM 等基本状态。它在定位体系中的角色更接近 nvidia-smi，而不是完整的交互式 TUI。

官方命令参考中存在专门的持续监测模式：

npu-smi info watch

它可查询所有设备/芯片的功耗、温度、AI Core、AI CPU、Ctrl CPU、Memory、Memory BW 等动态指标；也可按设备或芯片进一步限定，例如：

npu-smi info watch -i 0
npu-smi info watch -i 0 -c 0 -d 5 -s ptaicmb

具体 watch_type、设备/芯片 ID 以及命令支持范围与产品形态、驱动版本和权限有关，应以目标机器上的 npu-smi -h 与对应版本命令参考为准。昇腾 npu-smi：查询所有芯片监测数据 昇腾 npu-smi：查询指定芯片监测数据

如果当前 910C/A3 环境的 info watch 子命令行为与文档不同，保守 fallback 是：

watch -n 1 npu-smi info

它只是周期性重跑 npu-smi info，能力不等同于 npu-smi info watch，但兼容性通常更容易确认。

第二层：类似 nvtop 的交互式工具

方案 A：原版 nvtop 的 Ascend backend

一个容易忽略的变化是：新版开源 nvtop 已经加入 Huawei Ascend 支持。其 Ascend backend 通过 DCMI API 获取设备数据；上游 README 明确写明测试平台为 Atlas 800（910B）、DCMI 6.0.0，并指出当前 DCMI 可暴露的数据仍有限，例如部分 PCIe 信息、TX/RX throughput、最大功耗等指标可能缺失。Syllo/nvtop

这意味着“昇腾有没有真正的 nvtop”这个问题现在可以分成两个答案：

  • 从软件本体看：有，原版 nvtop 已有 Ascend backend。
  • 从当前 910C/A3 的工程可用性看：仍需本机编译/安装验证，因为上游公开测试基线主要写的是 910B，而不是你的 910C 环境。

方案 B：nputop / ascend-nputop

youyve/nputop 是专门面向 Ascend 的交互式进程查看器，支持实时利用率、内存、温度、功耗、进程、多 NPU，以及 Driver/CANN 版本展示；项目当前声明支持 Ascend 910 系列并改进了 Atlas A3 兼容性。youyve/nputop

推荐安装的是这个项目在 PyPI 上发布的 ascend-nputop：

python3 -m venv /tmp/nputop-venv
source /tmp/nputop-venv/bin/activate
pip install ascend-nputop
nputop

这里要注意包名歧义：PyPI 还存在另一个名为 nputop 的包，因此实际安装前应核对 Homepage/Repository/maintainer，避免只根据命令名安装错项目。ascend-nputop PyPI

方案 C：npu-top 等轻量第三方 TUI

raids-lab/npu-top 是更小型的 Python TUI，实现思路是调用和解析 npu-smi，展示利用率、显存、温度、功耗、时钟、历史曲线与进程，并支持多卡网格布局。raids-lab/npu-top

这种工具的优点是代码短、容易审查和二次修改；缺点是项目成熟度、版本适配、异常输出解析能力通常不如维护更久的工具。对生产服务器，仍建议先审查源码、固定版本，并避免给交互式“kill process”能力过高权限。

第三层：多机集群与长期观测

当目标从“盯一台 8 卡机器”变成“观察多台 910C 推理集群”，TUI 不再够用。更合适的路径是每节点部署 NPU Exporter，将指标交给 Prometheus，再用 Grafana 做时间序列、告警和跨节点对比。

MindCluster 的 NPU Exporter 并不是简单包装 npu-smi：官方实现说明中，它会通过 DCMI 获取芯片信息、通过 hccn_tool 获取网络信息，并从 K8s CRI 获取容器信息，再暴露 Prometheus/Telegraf 指标。MindCluster NPU Exporter 原理

官方指标文档当前覆盖的类别包括 NPU、利用率、Network、HCCS、PCIe、RoCE、SIO、UB 等；具体字段是否出现仍取决于设备形态和底层 HDK/DCMI/HCCN 接口支持。NPU Exporter Prometheus Metrics

应重点监控：

  • 设备健康、温度、功耗与潜在降频迹象
  • AI Core 利用率以及跨卡负载不均衡
  • HBM 已用量、增长趋势与 OOM 风险
  • 进程/容器到 NPU 的映射
  • HCCS/HCCN、RoCE 等互联侧异常与吞吐变化
  • 推理服务层的 TTFT、TPOT、吞吐、队列长度和失败率

NPU 利用率高低不能单独解释性能。利用率低可能来自 CPU 调度、通信、数据搬运、同步等待或请求不足；利用率高也可能伴随尾延迟恶化。设备指标必须和 vLLM-Ascend 服务指标、日志及 profiling 时间线一起看。

一个更通用的可观测性分层模型

可以把昇腾推理观测拆成四层：

  1. 设备健康层：npu-smi、nvtop、nputop。回答“卡是否正常、是否忙、HBM 是否够”。
  2. 持续监控层：NPU Exporter + Prometheus + Grafana。回答“过去一段时间发生了什么、哪台节点/哪张卡长期异常”。
  3. 服务性能层：推理框架的 TTFT、TPOT、吞吐、并发、队列、失败率。回答“用户体验和系统吞吐为什么变化”。
  4. Profiler/时间线层：昇腾 profiling 工具、算子时间线、通信事件。回答“时间具体耗在什么算子、同步或数据搬运上”。

这四层不能互相替代。nvtop/nputop 很适合发现异常，但无法仅凭一个 utilization 数字证明瓶颈来自算力、HBM、通信还是 Host；Profiler 能做归因，但不适合替代 7×24 小时监控。工程上应该先用监控缩小范围，再用 profiling 做根因定位。

针对当前 8 卡 910C 场景的建议

  1. 日常登录排障：优先试 npu-smi info watch；若当前 910C/A3 版本行为不符合预期，再退回 watch -n 1 npu-smi info。
  2. 希望获得 nvtop 式体验：先在隔离环境试 ascend-nputop，再测试新版原生 nvtop Ascend backend；把设备编号、双 Die 映射、进程和 HBM 数值与 npu-smi 交叉核验。
  3. 多节点 GLM-5.3-Flash 性能与稳定性分析：部署 NPU Exporter + Prometheus + Grafana，并把服务端 TTFT、TPOT、吞吐、并发和失败率纳入同一观测面。
  4. 深入定位算子与通信瓶颈时，TUI/Exporter 只负责发现异常，根因归因仍需结合 profiling 时间线、算子耗时和通信事件。

与现有知识的连接

这篇笔记是“设备是否健康、资源是否繁忙”的观测入口。网络与 HCCL 检查可继续参考 NPU 网络检查：hccn_tool、/30 子网与 HCCL 连通性；设备层级和双 Die 映射参考 读懂昇腾 A3 的设备层级：双 Die、davinci 节点与空闲 HBM 排查。