SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsascend-dmi

ascend-dmi

Deployment & operations

View repository

Updated 10-15 17:19

About this skill

Ascend DMI Tool Usage Guide

Ascend DMI (Ascend Device Management Interface) is a management and diagnostic tool for Huawei Ascend NPU devices.

You must strictly follow the steps in this document in order. Do not skip steps, and do not invent alternative solutions on your own. Each step has clear pass conditions. If a step does not pass, you cannot proceed to the next step. This is not a reference document; it is an operating procedure that you must follow.

Quick decision: choose a path based on the type of operation

用户请求
  │
  ├─ 信息查询（-v/-i/-c/-h）或眼图测试（--sq）
  │   → 【快速路径】检查 ascend-dmi → 确认参数 → 构建命令 → 直接执行 → 解读输出
  │
  ├─ 性能测试（--bw/-f/-p）或 healthCheck/performanceCheck
  │   → 【标准路径】检查 ascend-dmi + CANN → 确认参数 → 构建命令 → 告知风险并确认 → 执行 → 解读输出
  │
  └─ 压力测试（--dg -s）或 NPU 恢复（-r）
      → 【高风险路径】检查 ascend-dmi + CANN → 确认参数 → 构建命令 → 二次确认 → 检查设备占用 → 执行 → 解读输出

Note: Both the standard path and the high-risk pathmust complete the CANN checkbefore executing commands. See Step 2.

Step 1: Remote or local?

  • Local(the user did not mention a remote IP/hostname): execute directly on the current server ascend-dmi commands

  • Remote(the user mentioned an IP address, hostname, or "remote server"):You must first call the remote-server-guide skill to establish a connection, and do not try SSH yourself. Reason: directly using ssh cannot enter a password in a non-interactive environment and will fail authentication. remote-server-guide will securely handle password input through tmux and other methods. After the connection is established, execute the subsequent steps remotely.

    Prohibited behavior: Do not directly execute ssh user@host "command". This will definitely fail in the Claude environment (cannot enter a password).

Step 2: Environment check

The environment check consists of two parts.You must complete both parts in order before executing commands。

2a. Check ascend-dmi

which ascend-dmi && ascend-dmi -v

If unavailable:

source /usr/local/Ascend/toolbox/set_env.sh
which ascend-dmi

If it is still unavailable, read [references/environment-setup.md] and follow the steps to install MindCluster ToolBox.

2b. Check CANN (required for performance testing, diagnostics, and stress testing)

Bandwidth test (--bw), compute test (-f), power test (-p), health check (--dg), and stress test (-s) all depend on the CANN environment.Executing these commands without completing the CANN check will definitely fail, with no exceptions.

Verification command (use this command repeatedly throughout the process to determine whether CANN is available):

python3 -c "import acl; print(acl.get_soc_name())"
  • Output the chip model (such as Ascend910B) = CANN available ✓ → proceed to Step 3
  • Any error (ModuleNotFoundError, ImportError, etc.) = CANN unavailable ✗ → execute the repair process below

Repair process when CANN is unavailable (must be executed in the order 1→2→3→4, without skipping steps):

1. Ask the user first. Ask the user: "What path is CANN installed in?" Then wait for the user's reply.

  • The user provides a path → source <路径>/set_env.sh → run the verification command → if it passes, proceed to Step 3; if it fails, tell the user that the path is unavailable and continue to Step 2
  • The user says they do not know → proceed to Step 2

2. After obtaining the user's consent, search automatically. First ask the user, "May I automatically search for the CANN path?" After receiving consent, follow the priority order belowone by oneAttempt (CANN 8.5.0+ directory name is cann, older versions use ascend-toolkit）：

Priority Attempted command
② source /usr/local/Ascend/ascend-toolkit/set_env.sh → Verify
① source /usr/local/Ascend/cann/set_env.sh → Verify
① source /home/miniconda3/Ascend/cann/set_env.sh → Verify
③ find /home -path "*/Ascend/cann/set_env.sh" -o -path "*/Ascend/ascend-toolkit/set_env.sh" 2>/dev/null, for each path found source → Verify

Each priority is handled in exactly the same way:

source <路径>/set_env.sh → python3 -c "import acl; print(acl.get_soc_name())"
  ├─ 验证通过（输出芯片型号）→ 成功，进入第 3 步
  └─ 验证失败（任何报错）→ 放弃这个路径，尝试下一优先级

"Seeing that the directory exists" is not the same as "CANN is available." The directory existing, the file existing, and set_env.sh being sourceable cannot replace the verification command. Only python3 -c "import acl; print(acl.get_soc_name())" succeeding counts as CANN being available. If verification fails, abandon that path immediately. If the following file does not exist under the directoryset_env.sh, also abandon that path immediately.

3. If all fail → stop. Tell the user "automatic CANN discovery failed, please provide the exact CANN installation path", thenstop operations and wait for the user's reply. Do not continue executing the ascend-dmi command.

The following behaviors are prohibited because they will cause environment damage or command execution errors:

  • ✗ Skipping step 1 and searching directly (the user may know the path directly, and searching is a waste of time)
  • ✗ Using export PATH=...、export PYTHONPATH=...、export LD_LIBRARY_PATH=... to manually piece together the environment
  • ✗ After verification fails, repeatedly trying to fix things on the same path (switching python versions, installing pip packages, changing permissions, etc.)
  • ✗ Seeing that /usr/local/Ascend/ascend-toolkit or /usr/local/Ascend/cann directory exists and assuming it has been found, without running the verification command
  • ✗ Continuing to execute the ascend-dmi test command after all paths have failed

Step 3: Confirm test parameters

Before building the command, first confirm the specific test parameters with the user. The user's request may already include some parameters; only the missing parts need to be filled in.If the user has already explicitly specified all parameters in the request, there is no need to ask again.

First execute npu-smi info to obtain the list of available devices, so that the available options can be shown to the user.

Parameters to confirm for each test type

Bandwidth test：

  • Test mode: h2d / d2h / d2d / p2p (multiple selections allowed)
  • Which cards to test (device IDs), or all cards?
  • Whether to specify the data size (-s)? Note: D2D does not support -s
  • Whether P2P specifies source/destination devices (-ds/-dd)? If not specified, the full matrix between all devices is tested

Computing power test：

  • Data type: fp16 / fp32 / int8 / bf16 / hf32 (default fp16; different products support different types, see [references/constraints.md] for details)
  • Which cards to test (-d), or the whole machine (--all)? The two are mutually exclusive
  • Whether to adjust the number of executions (--et, default 60, unit: hundred thousand)?

Power consumption test：

  • Test type: edp (estimated design power) or tdp (thermal design power)?
  • Test duration (--dur, default 600 seconds)

Health check / performance specifications：

  • Which cards to test, or all cards?

Stress test：

  • Test items: aicore / hbm (on-chip memory) / bandwidth (P2P) / edp / tdp / aicpu?
  • Which cards to test? Note: aicpu must be executed separately and cannot be combined with other items

NPU recovery：

  • Which card to recover? (must specify -d）

Eye diagram test：

  • Test type: pcie / hbm / roce / all?
  • Which cards to test?

Step 4: Build the command

Based on the parameters confirmed by the user, build the command according to the table below.

Command quick reference

Operation Command template Risk
Version ascend-dmi -v None
Device status ascend-dmi -i [-b|--dt] None
Compatibility check ascend-dmi -c None
Eye diagram test ascend-dmi --sq -t pcie|hbm|roce|all [-d ID] None
Bandwidth test ascend-dmi --bw -t h2d|d2h|d2d|p2p [-d ID] [-s SIZE] [-q] Medium
Compute power test ascend-dmi -f -t fp16|fp32|int8|bf16|hf32 [-d ID] [--all] [-q] Medium
Power consumption test ascend-dmi -p [-pt edp|tdp] [--dur SEC] [-q] Medium
Health check ascend-dmi --dg --se healthCheck [-d ID] [-q] Medium
Performance specifications ascend-dmi --dg --se performanceCheck [-d ID] [-q] Medium
Stress test ascend-dmi --dg --se stressTest [-d ID] [-q] or -s -i ITEM High
NPU recovery ascend-dmi -r -d ID [-q] High

For the complete command and parameter combinations, see [references/command-cheatsheet.md]. For detailed parameter descriptions, see the files under [references/parameters/].

Notes

  • -q parameter: For medium/high-risk operations, after user confirmation add -q to skip the command-line interactive prompt

Step 5: Risk confirmation and execution

No-risk operations (information queries, eye diagram test)

Execute directly, no additional confirmation required.

Medium-risk operations (bandwidth/compute power/power consumption tests, health check, performance specifications)

These operations will exclusively occupy the NPU device, interrupting running training or inference tasks. Before execution:

  1. Inform the user of the impact: "This test will exclusively occupy the NPU, and running training/inference tasks will be interrupted"
  2. Execute after obtaining user confirmation
  3. Add -q parameter to skip the command-line interactive prompt

High-risk operations (stress test, NPU recovery)

These operations may cause prolonged high load, hardware overheating, or temporary NPU unavailability. Before execution:

  1. Clearly inform of the specific risks (e.g., "the stress test will run under high load for several hours and may trigger hardware protection mechanisms")
  2. Check device occupancy:fuser -v /dev/davinci*
  3. Require the user to confirm a second time: confirm that related services have been stopped and that the risks are understood
  4. Add -q parameter

For the detailed risk matrix, see [references/risk-assessment.md].

Step 6: Interpret the output

After execution is complete, extract the key metrics and give a conclusion:

Bandwidth test: Focus on the Bandwidth(GB/s) value. Typical reference: H2D 20-28 GB/s, D2H 25-30 GB/s, D2D 760-800 GB/s, P2P 25-55 GB/s. Note: On A2/A3, the D2D transfer size is determined by AI Core and does not support the -s parameter; when P2P does not specify -ds/-dd , the output is the inter-device matrix.

Compute power test: Focus on the TFLOPS/TOPS value. Note the distinction between test modes: when using --all , TFLOPS isthe total compute power of all cards in the entire machine, not the compute power of a single card; without --all is the single-card computing power. When determining whether it meets the standard, it must correspond to the correct specification (whole-machine specification = single-card specification × number of cards). If it is significantly lower than the product specification, it may be that the temperature is too high and triggering frequency reduction.

Power Consumption Test: Pay attention to Power(W) and Temperature(°C). The temperature should be below 90°C.

Diagnostic Test: PASS = normal, FAIL = needs handling, SKIP = not supported by the current product, WARN = warning level requiring attention.

For detailed result interpretation methods, see [references/output-interpretation.md].

Resource Index

When needed read
Install/configure ascend-dmi or CANN [references/environment-setup.md]
View complete commands and parameters [references/command-cheatsheet.md] + [references/parameters/]
Detailed risk assessment [references/risk-assessment.md]
In-depth interpretation of test results [references/output-interpretation.md]
Usage constraints and limitations [references/constraints.md]
Command template examples [scripts/templates/]
Test report template [assets/report-template.md]