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-smiNPU 集群的听诊器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/Vectornpu-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 错误。ECCError 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 管理有 bugnpu-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\--modelparallel\--duration10# 生成分析报告msprof--export--input./profiling_data--formatcsv输出一个按时间线展开的算子视图时间线 (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 → 总计 ~200msPipeBarrier 耗时 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_ID0# 指定推理用卡 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--typefw--version1.76.22.3.310--device0# 回滚到上一个版本如果升级后出问题asc-dmi rollback--typefw--device0# 查询所有设备的固件一致性集群运维必查asc-dmi info--all|grepFirmware 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--repeat1000# 不开 Profiling延迟数据才是生产环境真实的# 两次的数据不能混着用# Profiling 数据 → 找算子瓶颈哪个算子最慢# Benchmark 数据 → 报线上延迟P50/P99踩坑三容器化部署的 NPU 设备映射Ascend Docker Runtime 把 NPU 设备映射到容器内。映射方式有两种--device指定卡号和--npuAscend 专用参数。错误映射# 用 --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--runtimeascend\--npu0,1\# 映射卡 0 和卡 1-eASCEND_DEVICE_ID0\my_inference_image# --runtimeascend 自动处理# - /dev/davinciN 字符设备映射# - /dev/davinci_manager 管理设备# - /usr/local/Ascend/driver 驱动文件挂载# - 容器内的权限配置如果容器需要升级固件通常不应该——固件升级在宿主机上做还需要加--privileged参数——但生产环境不建议给容器特权。asc-tools 的价值在问题发生时才能体现。开发阶段所有代码都跑得通上线后 HBM 漏了、ECC 报了、延迟涨了、固件过时了——这些问题的排查靠的就是 npu-smi、msprof、asc-dmi 这几个工具。运维和开发是两个完全不同的技能树asc-tools 是两棵树之间的桥。
昇腾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-smiNPU 集群的听诊器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/Vectornpu-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 错误。ECCError 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 管理有 bugnpu-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\--modelparallel\--duration10# 生成分析报告msprof--export--input./profiling_data--formatcsv输出一个按时间线展开的算子视图时间线 (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 → 总计 ~200msPipeBarrier 耗时 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_ID0# 指定推理用卡 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--typefw--version1.76.22.3.310--device0# 回滚到上一个版本如果升级后出问题asc-dmi rollback--typefw--device0# 查询所有设备的固件一致性集群运维必查asc-dmi info--all|grepFirmware 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--repeat1000# 不开 Profiling延迟数据才是生产环境真实的# 两次的数据不能混着用# Profiling 数据 → 找算子瓶颈哪个算子最慢# Benchmark 数据 → 报线上延迟P50/P99踩坑三容器化部署的 NPU 设备映射Ascend Docker Runtime 把 NPU 设备映射到容器内。映射方式有两种--device指定卡号和--npuAscend 专用参数。错误映射# 用 --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--runtimeascend\--npu0,1\# 映射卡 0 和卡 1-eASCEND_DEVICE_ID0\my_inference_image# --runtimeascend 自动处理# - /dev/davinciN 字符设备映射# - /dev/davinci_manager 管理设备# - /usr/local/Ascend/driver 驱动文件挂载# - 容器内的权限配置如果容器需要升级固件通常不应该——固件升级在宿主机上做还需要加--privileged参数——但生产环境不建议给容器特权。asc-tools 的价值在问题发生时才能体现。开发阶段所有代码都跑得通上线后 HBM 漏了、ECC 报了、延迟涨了、固件过时了——这些问题的排查靠的就是 npu-smi、msprof、asc-dmi 这几个工具。运维和开发是两个完全不同的技能树asc-tools 是两棵树之间的桥。
