昇腾CANN asc-tools：NPU 运维诊断工具的实战手册

asc-tools 是 CANN 的运维诊断工具包——不在开发阶段用，在部署和运维阶段用。NPU 集群跑了几个月突然性能下降、某张卡频现 ECC 错误、推理延迟从 50ms 涨到 200ms——这些生产环境的问题，asc-tools 帮你定位。

asc-tools 包含哪些工具

asc-tools/ ├── npu-smi # NPU 系统管理接口（类似 nvidia-smi） ├── asc-dmi # 设备管理接口（固件升级/降级/状态查询） ├── ascend-docker-runtime # 容器化部署运行时 ├── msprof # 性能分析器（Profiling） ├── adc # 算子调试编译器 └── npu-proc # 进程级 NPU 监控

六个工具覆盖运维的完整生命周期：部署 → 监控 → 诊断 → 优化。

npu-smi：NPU 集群的听诊器

npu-smi 是最常用的工具——查 NPU 状态、显存占用、温度、功耗、进程列表。和 nvidia-smi 类似，但增加了昇腾特有的字段。

# 基本状态查询npu-smi info# 输出示例（8 卡 Atlas 300I Duo）：# +---+---------------------------+---------------------------+# | 0 | NPU Name: Ascend 910B | NPU Name: Ascend 910B |# | | BusId: 0000:01:00.0 | BusId: 0000:02:00.0 |# | | Temp: 52°C | Temp: 48°C |# | | Power: 280W / 350W | Power: 265W / 350W |# | | HBM: 32768 / 65536 MB | HBM: 28416 / 65536 MB |# | | ECC: 0 errors | ECC: 3 errors ⚠️ |# +---+---------------------------+---------------------------+# | 2 | Temp: 55°C | Temp: 51°C |# | | HBM: 65536 / 65536 MB 💀 | HBM: 10240 / 65536 MB |# | | OOM Count: 7 | |# +---+---------------------------+---------------------------+# 详细信息npu-smi info-tboard-i0# 卡 0 的板卡信息（固件版本/序列号）npu-smi info-tusages-i2# 卡 2 的资源使用率（HBM/Cube/Vector）npu-smi info-tecc-i1# 卡 1 的 ECC 错误详情# 进程级查询npu-smi info-tproc-i2# 卡 2 上正在跑的进程列表# PID Name HBM_Used Start_Time# 28431 python3 51200MB 2026-05-22 10:23# 28455 profiler 1024MB 2026-05-22 10:45

实战案例：ECC 错误定位

卡 1 出现 3 次 ECC 错误。ECC（Error Correction Code）是显存的自纠错机制——1-bit 错误能自动纠正，2-bit 错误无法纠正会导致数据损坏。3 次 ECC 说明这张卡的 HBM 已经开始老化。

# 第一步：查 ECC 错误详情npu-smi info-tecc-i1# Single Bit Errors: 3# Double Bit Errors: 0# Memory Page Offlined: 1 ← 有一个物理页被隔离了# 第二步：查固件版本（旧固件的 ECC 管理有 bug）npu-smi info-tboard-i1# Firmware Version: 1.76.22.3.220# 推荐升级到 1.76.22.3.310+（修复了 ECC 隔离页的回收策略）# 第三步：决策# 如果 Single Bit Errors 持续增长 → 硬件故障前兆# 建议标记为「不跑关键任务」，在维护窗口期更换

msprof：性能分析的显微镜

msprof 是 CANN 的性能分析工具——对一次推理或训练过程做全链路 Profiling，输出每个算子的耗时、HBM 读写量、Cube/Vector 利用率。

# 对推理过程做 profilingmsprof--application="./infer_demo"\--output="./profiling_data"\--model="parallel"\--duration=10# 生成分析报告msprof--export--input="./profiling_data"--format=csv

输出一个按时间线展开的算子视图：

时间线 (ms) → 0────5────10────15────20────25────30────35────40 [DataCopy] ████████ HBM→L1 搬运 [MatMul] ████████████████ Cube 计算 [Softmax] ██████ Vector 计算 [DataCopy] ████████ L1→HBM 写回 [PipeBarrier] ██ 同步等待 [MatMul] ████████ 下一层

从这个时间线可以看出：DataCopy 和 MatMul 没有重叠——双缓冲没生效，NPU 的流水线是串行的。

实战案例：推理延迟从 50ms 涨到 200ms

线上推理服务的 P99 延迟突然从 50ms 涨到 200ms，但 QPS（每秒请求数）没变。用 msprof 抓了一次 Profiling：

正常状态（50ms）： [DataCopy] 5ms → [MatMul] 20ms → [Softmax] 3ms → [DataCopy] 2ms → 总计 ~50ms 异常状态（200ms）： [DataCopy] 5ms → [MatMul] 20ms → [PipeBarrier] 175ms → [Softmax] 3ms → 总计 ~200ms

PipeBarrier 耗时 175ms——正常应该 <1ms。根因：另一张卡上跑了一个大 batch 的训练任务，两张卡共享 HBM 带宽，训练任务的频繁 HBM 读写把推理任务的 HBM 请求挤到了等待队列里。

# 确认：查两张卡的 HBM 带宽使用npu-smi info-tusages-i0# 推理卡# HBM Bandwidth Util: 85%npu-smi info-tusages-i1# 训练卡# HBM Bandwidth Util: 95%# 修复：推理任务绑到独占的 NPUexportASCEND_DEVICE_ID=0# 指定推理用卡 0# 训练任务用卡 1-7，不再和推理共享带宽

asc-dmi：固件和驱动管理

asc-dmi 负责 NPU 的固件升级、降级、驱动状态查询。固件版本决定了 NPU 的行为（算子调度策略、ECC 管理策略、功耗管理策略）。

# 查询当前固件版本asc-dmi info# Driver Version: 1.76.22.3.220# Firmware Version: 1.76.22.3.220# 升级固件（需要 root 权限，会短暂中断 NPU 服务）asc-dmi upgrade--type=fw--version=1.76.22.3.310--device=0# 回滚到上一个版本（如果升级后出问题）asc-dmi rollback--type=fw--device=0# 查询所有设备的固件一致性（集群运维必查）asc-dmi info--all|grep"Firmware Version"# Card 0: 1.76.22.3.310# Card 1: 1.76.22.3.220 ← 版本不一致！# Card 2: 1.76.22.3.310

踩坑一：npu-smi 显示 HBM 满了但找不到进程

卡 2 的 HBM 显示 65536/65536 MB（满了），但npu-smi info -t proc -i 2显示没有进程在使用。

根因：进程异常退出（被 SIGKILL 或 OOM Killer 杀掉），没有执行 NPU 资源释放的清理逻辑。HBM 里的模型权重和数据没有被释放——成了「僵尸占用」。

修复：

# 第一步：查是否有僵尸进程psaux|grep-iascend|grep-vgrep# 没有相关进程# 第二步：查 NPU 设备状态npu-smi info-tproc-i2# 无进程# 第三步：强制释放 HBM（需要 root）# 重置 NPU 设备npu-smiset-tdevice-reset-i2# 注意：这会清掉卡 2 上所有 HBM 数据# 其他正常运行的卡不受影响# 验证npu-smi info-i2|grepHBM# HBM: 0 / 65536 MB ← 已释放

踩坑二：msprof 本身影响推理延迟

msprof 的 Profiling 机制是在每个算子执行前后插入时间戳钩子。这些钩子有额外开销——被 Profiling 的推理过程比正常运行慢 5-15%。

问题：线上用 msprof 抓 Profiling 时，延迟数据不可信——Profiling 开销本身被计入了延迟。

正确做法：分两次跑——一次 Profiling（分析性能），一次不 Profiling（测真实延迟）。

# 第一次：Profiling 模式（只看算子级别的瓶颈）msprof--application="./infer_demo"--output="./profiling_data"# 第二次：正常模式（测真实 P99 延迟）./infer_demo--benchmark--repeat=1000# 不开 Profiling，延迟数据才是生产环境真实的# 两次的数据不能混着用：# Profiling 数据 → 找算子瓶颈（哪个算子最慢）# Benchmark 数据 → 报线上延迟（P50/P99）

踩坑三：容器化部署的 NPU 设备映射

Ascend Docker Runtime 把 NPU 设备映射到容器内。映射方式有两种：--device（指定卡号）和--npu（Ascend 专用参数）。

错误映射：

# 用 --device 映射 NPUdockerrun--device=/dev/davinci0--device=/dev/davinci_manager\--device=/dev/devmm_svm--device=/dev/hisi_hdc\my_inference_image# 问题：/dev/davinci0 是字符设备，映射进容器后权限可能不对# 容器内的进程读不到 NPU 固件版本# 报错：Failed to get firmware version, permission denied

正确映射：

# 用 Ascend Docker Runtime 的 --npu 参数dockerrun--runtime=ascend\--npu0,1\# 映射卡 0 和卡 1-eASCEND_DEVICE_ID=0\my_inference_image# --runtime=ascend 自动处理：# - /dev/davinciN 字符设备映射# - /dev/davinci_manager 管理设备# - /usr/local/Ascend/driver 驱动文件挂载# - 容器内的权限配置

如果容器需要升级固件（通常不应该——固件升级在宿主机上做），还需要加--privileged参数——但生产环境不建议给容器特权。

asc-tools 的价值在问题发生时才能体现。开发阶段所有代码都跑得通，上线后 HBM 漏了、ECC 报了、延迟涨了、固件过时了——这些问题的排查靠的就是 npu-smi、msprof、asc-dmi 这几个工具。运维和开发是两个完全不同的技能树，asc-tools 是两棵树之间的桥。