ais_bench 实测 OM 推理性能：安装、参数与结果解读（ResNet18 / 910B3）

一句话让Agent变成昇腾专家，昇腾任务轻松搞定。评测入口：请按这个开源仓接入昇腾图谱 https://gitcode.com/agent0/kg-tools

上一篇实验的结尾，ATC 转换一次通过，产出了 23.7 MB 的 resnet18_bs1.om。但转换成功只说明"能跑"——一帧多快、吞吐多少、数值和参考实现对不对齐，都得实测才有数。做这件事的官方工具是 ais_bench。

本篇（实验 02）一条主线：装好工具 → 纯推理拿性能分布 → 换真实数据顺手验精度，最后把输出的每个数字逐项读懂。全程一条命令一个日志，可直接照抄。

一、先认清工具，再装

动手前先排掉两个真实的坑。

坑一：名字撞车。 搜 “AISBench” 首先撞上的是大模型评测框架（ais-bench-benchmark，刷模型榜单那套），和本文毫无关系。本文的 ais_bench 是 OM 离线模型推理评测工具，住在 Gitee ascend/tools 仓的 ais-bench_workload 目录下——认准路径再搜。

坑二：入口迁移。 老教程里常见 msit benchmark --om-model xxx.om 的写法；实测本机 msit 8.2.0 的 CLI 已经没有 benchmark 子命令（只剩 debug/install 等），该组件拆成了独立的 whl 包。别在旧入口上耗，直接装包。

安装（官方 README 口径，两个包）： aclruntime 是 ACL 推理接口的 Python 绑定（真正碰硬件的底层），ais_bench 是评测程序本体。按本机 Python 与架构选包（此处 Python 3.10 / aarch64）：

pip3 install https://aisbench.obs.myhuaweicloud.com/packet/ais_bench_infer/0.0.2/ait/aclruntime-0.0.2-cp310-cp310-linux_aarch64.whl
pip3 install https://aisbench.obs.myhuaweicloud.com/packet/ais_bench_infer/0.0.2/ait/ais_bench-0.0.2-py3-none-any.whl

一个诚实的提示，来自 README 原文：出包流水恢复中，whl 包非最新版本、官方不推荐用于正式环境；0.0.2 跑评测完全够用，需要新特性可走源码编译。运行前置只有一条：机器已装 CANN，并先 source 环境（本机为 /usr/local/Ascend/cann-9.0.0-beta.2/bin/set_env.sh）。

实验环境（与实验 01 同机，本次用 device 0）：

组件	版本 / 规格
NPU	Ascend 910B3 × 2（npu-smi info 实测；本实验占 device 0）
CPU / 架构	鲲鹏-920 / aarch64
系统 / Python	Ubuntu 22.04 LTS / 3.10（conda）
CANN	9.0.0-beta.2
aclruntime / ais_bench	0.0.2 / 0.0.2

二、一条命令跑纯推理

主命令长这样：

python3 -m ais_bench --model resnet18_bs1.om --output ./ais_bench_result --loop 20

不带 --input 就是官方说的纯推理场景：工具自动构造输入数据（默认全 0，--pure_data_type random 换随机），不走文件 IO，专测计算性能——测吞吐就用这个形态。

常用参数一张表（依据本机 --help 实测与官方 README，完整版以 python3 -m ais_bench --help 为准，全量 help 已存 scripts/ais_bench_help.txt）：

参数	作用	默认
--model / -m	OM 模型路径，必填	—
--input / -i	真实输入的文件/目录，支持 NPY/BIN，多个用逗号分隔；不填 = 纯推理	无（纯推理）
--output / -o	输出根目录；每次运行生成时间戳子目录，并在旁边落一个 <时间戳>_summary.json	无（不落盘）
--outfmt	输出文件格式 NPY / BIN / TXT	BIN
--loop / -l	纯推理的推理次数	1
--device / -d	NPU 卡号（0~255），多卡逗号分隔如 1,2	0
--pure_data_type	纯推理构造的数据：zero / random	zero
--warmup_count	计时前预热次数	1
--display_all_summary	控制台连 H2D/D2H 拷贝耗时一起打印	关
--profiler / --dump	Profiling / 精度数据落盘开关（配 profiler 时 loop 建议 1）	关
--batchsize	输入 tensor 的 batch	—
--dymBatch / --dymHW / --dymDims / --dymShape	动态分档 OM 指定实际档位，与 ATC 的 --dynamic_* 系列一一对应	—

三、结果解读：每个数字什么意思

主命令的完整输出（截取关键行，全量见 scripts/ais_bench_run.log）：

[INFO] load model resnet18_bs1.om success
[INFO] try get model batchsize:1
[INFO] warm up 1 done
[INFO] -----------------Performance Summary------------------
[INFO] NPU_compute_time (ms): min = 0.24500274658203125, max = 0.38700103759765625,
       mean = 0.25715065002441406, median = 0.2504997253417969, percentile(99%) = 0.3621102142333983
[INFO] throughput 1000*batchsize.mean(1)/NPU_compute_time.mean(0.25715065002441406): 3888.7710371529656
[INFO] ------------------------------------------------------

逐项拆：

batchsize 从 OM 里读，不用你填。 try get model batchsize:1——转换时 --input_shape 定的 1，工具加载模型后自己查出来，吞吐公式里用的就是它。

warm up 在计时之外。 warm up 1 done 之后才开始统计，所以下面的分布不含首次加载的冷启动。

NPU_compute_time 是纯设备侧计算耗时，看分布别只看均值。 20 次推理：min 0.245 ms 是稳态、max 0.387 ms 是偶发毛刺、median 0.250、P99 0.362、mean 0.257。单发毛刺到 0.39 属正常调度抖动——这正是要 --loop 20 的原因：默认 --loop 1 只采一发，本机实测单发 0.431 ms / 2320 fps——比 20 次均值 0.257 慢了近七成。报性能报分布（稳态 + P99），单发数字没有代表性。

throughput 是折算值，公式就写在日志里： 1000 × batchsize / NPU_compute_time.mean，即 1000 × 1 / 0.2572 ≈ 3889 帧/秒（bs1）。注意它只除以 NPU 计算时间——不含 H2D/D2H 拷贝和 host 侧调度。这两项在 summary.json 里另有统计（本机 H2D 0.204 ms / D2H 0.032 ms），端到端逐张实拍实测帧率会低于 3889。数字绑环境（CANN 版本、驱动、卡的状态），拿去横向对比时要连环境一起报。

产物两份。 时间戳子目录（纯推理也会落一份输出 pure_infer_data_0.bin，全 0 输入的推理结果，看一眼可删）+ <时间戳>_summary.json——后者是脚本化取数的抓手：args 回显完整命令、filesinfo 记输入输出文件、NPU_compute_time / H2D_latency / D2H_latency 三组统计、npu_compute_time_list 存逐次原始值、throughput 一个浮点。做回归对比，读它比 grep 控制台稳。

四、换真实数据：顺手验精度

性能测完，把同一份 OM 换成真实输入跑一发，验证 NPU 输出没漂。三行生成输入（与实验 01 同一套种子体系，参考结果应为 top1 238）：

import numpy as np
np.random.seed(0)
np.random.randn(1, 3, 224, 224).astype("float32").tofile("ais_bench_input/input_0.bin")

python3 -m ais_bench --model resnet18_bs1.om --input ais_bench_input \
    --output ./ais_bench_result --outfmt NPY

实测：单发 NPU 计算耗时 0.394 ms；输出 input_0_0.npy，shape (1, 1000) float32。与 onnxruntime（CPU）同输入对比：top1 两边都是 238，最大绝对误差 2.543e-03。这个数比实验 01 里 onnxruntime vs PyTorch 的 4.05e-06 大三个量级——不是问题：那次是同机同 CPU，这次换了硬件，卷积/矩阵乘的切分与归约顺序都不同，fp32 下 1e-3 量级是跨硬件的正常水平，top1 一致即可放心（那个 0.394 ms 也是单发口径，单发偏慢的规律和纯推理一致）。反过来说，测吞吐时别带 --input：真实数据模式按文件逐个推理，没有 --loop 那样的循环统计，文件读写还占端到端时间——测性能用纯推理，验数值用真实数据，各干各的。

五、收尾：基线立起来了

三步串成完整链路：导出（实验 01，数值对齐 4.05e-06）→ ATC 转换（23.7 MB OM）→ 本篇评测。这台 910B3 上 ResNet18 bs1 的参照系从此有数：稳态单帧 ~0.25 ms、吞吐 ~3890 fps、精度偏差 1e-3 量级、top1 一致。以后任何针对这个模型的优化（换精度模式、加 AIPP、调 batch），跑同一条 ais_bench 命令、对着 summary.json 比分布就行。

下一篇按上一篇的预告走结构侧：看这份 OM 的算子清单经过图融合后还剩几种——和 ONNX 侧的 49 节点 7 种算子对账。

本文涉及的安装来源、参数语义与默认值、纯推理/真实数据两种场景口径、summary.json 产物结构、msit benchmark 子命令迁移，均经昇腾知识图谱（ascend.wiki）的 msit benchmark README 与 CLI 示例节点核实，并与 Gitee ascend/tools 仓 ais-bench_workload 官方 README 交叉印证；性能与精度数字全部为本机实测。运行日志（ais_bench_run.log / ais_bench_input_run.log）、全量 help（ais_bench_help.txt）、输入数据（ais_bench_input/）与三次运行结果（ais_bench_result/ 含 summary.json 与 NPY 输出）见仓库 blogs/scripts/ 目录。接入昇腾知识图谱 https://gitcode.com/agent0/kg-tools