E 层部署指南

一页读懂这一部分：它不是"一层"，是贯穿所有层的一套方法。 核心目标只有一个：拿到一个报错，能判断它属于哪一层。 会了这个，市面上 90% 的教程就帮不上你了 —— 因为大部分教程只教到"怎么装成功"。

本指南是 E 部分 4 课的浓缩版（E1 报错定位法 / E2 日志在哪里 / E3 官方案例库用法 / E4 报错码速查）， 只保留"用哪个工具、什么时候用、怎么用、怎么算成了"。

一、这一部分是什么（职能）

项	内容
层号	无 —— 排障是贯穿 A–G 每一层的
一句话职责	拿到一个报错，判断它属于哪一层。
⭐ 为什么它是整个体系的灵魂	A–D 只教到"怎么装"，真到现场"④之后全是报错了不知道找谁"。
它的验收标准	给你一个报错，你能说出该去查哪一层、先敲哪条命令
它的四个工具	定位法 / 日志 / 案例库 / 码表

⭐ 一句话记住这四件工具的分工：

工具	什么时候用	一句话
定位法（E1）	第一时间	先定位层，再找原因
日志（E2）	需要证据时	去看真实发生了什么
案例库（E3）	有特征词时	去看别人遇到过没有
码表（E4）	拿到码时	判断这个码能不能自己修

二、工具一 · 报错定位法（E1）

2.1 ⭐ 先看清：一条报错由 5 块组成

拿到一条报错，先把它拆成 5 块 —— 这是本部分最基础的一步：

#	块	例子	告诉你什么
①	级别	`[ERROR]`	严重程度（`INFO` / `WARNING` / `ERROR`）—— 别把 WARNING 当 ERROR 修
②	模块	`ASCENDCL`	⭐ 哪个组件报的 —— 这一块最能定层
③	位置	`runtime/feature/src/device.cc:312`	源码文件 + 行号。搜案例时最好用
④	错误码	`ErrCode=507033`	⭐ 最重要的一块 —— 看第一位数字
⑤	补充	`desc=[driver]`	⭐ 它自己已经告诉你答案了：`driver` = 驱动层

2.2 ⭐ 错误码：看第一位数字就够了

码段	官方定义	自己能修吗
`1XXXXX`	环境异常 / 代码逻辑错误	✅ 改环境或代码
`2XXXXX`	资源不足（Stream / 内存）／参数与硬件不匹配	✅ 合理用资源
`3XXXXX`	业务功能异常（队列满 / 空）	✅
`5XXXXX`	软硬件内部异常 / Device 执行失败	❌ 收日志反馈，别死磕
`500000`	无法识别的错误	❌

⭐ 这一条的价值：先看第一位数字，就知道"这事我能不能修" —— 5 开头别花一小时去翻自己的代码。

2.3 ⭐ 三步定位法（本部分的核心方法）

第 1 步：先看有没有直接答案
        （报错的「补充」块、日志的 desc 字段，经常直接写了 component / driver 这类词）

第 2 步：用错误码确认
        （看第一位数字，判断能不能自己修）

第 3 步：特征词反查官方案例库
        （把报错去具体化后去搜 —— 见工具三）

⭐⭐ 一条铁律：先定位层，再找原因；不要从上层往下瞎试。

三、工具二 · 日志（E2）

3.1 三处日志（按"在哪查"分）

#	日志	管什么	在谁那
①	应用类日志	你最常看的：应用自己打印的	Host 上（`${HOME}/ascend/log`）
②	推理服务日志（MindIE）	用了 MindIE 才看	`~/mindie/log`（+ `/debug` `/security`）
③	Device 侧系统类日志	底层问题才看	⚠️ 在 Device 上，Host 上找不到

⚠️ 第 ③ 处的关键点： Device 侧日志在物理机上根本没有 —— 要用 msnpureport 把它导到 Host 上来。

3.2 怎么用（收一次日志的八步）

① 先定问题：这是哪一层的错
② 看最便宜的一处：应用类日志
③ 锁时间窗与进程：缩到一个 pid、一段报错前后
④ 不够细就调级别重跑：把日志级别调到 DEBUG
⑤ 看服务层那一处：MindIE 日志
⑥ 查设备号：搬 Device 日志前先把「设备号」查准
⑦ 搬 Device 日志：msnpureport
⑧ 收口：出证据，也诚实标出拿不到的部分

命令　npu-smi info -l

含义：先拿到设备编号 —— 第 ⑥ 步的前提拆解：-l（list，列出所有设备）用法：npu-smi info -l 期望：列出设备列表和各自的 NPU ID 不过会怎样：列表为空 → 驱动没挂载好（回 A 层） ⭐ 记法：这里查出的 NPU ID，就是导日志时 -d 要填的值

命令　msnpureport -f

含义：把 Device 侧日志一次性导出到 Host 拆解：-f（导出全部）用法：msnpureport -f 期望：当前目录下生成以时间命名的文件夹 不过会怎样： - 不导出 → 底层问题无从查起 - ⚠️ 官方对导出目录有两处口径（「当前路径下生成时间命名文件夹」vs「默认存放在 /var/log/npu/report」） → 以实际执行目录与回显为准 ⚠️ 完整参数以官方《msnpureport 工具使用指南》为准

命令　export ASCEND_GLOBAL_LOG_LEVEL=<级别>

含义：调日志级别（第 ④ 步要用）拆解：export 定义环境变量，只在当前终端有效（传给子进程）用法：调高 DETAIL 级别重跑，拿到更细的日志期望：日志更详细 不过会怎样：忘了这是进程级设置 → 新开终端就失效

⚠️ 一个官方注意事项：asys 可以一键收集所有故障信息，但官方明确「集群 / 容器 / 虚机 / 云不支持」。

四、工具三 · 官方案例库（E3）

4.1 ⭐ 案例库是"填好一格的表" —— 正文固定四格

格	内容
现象	别人看到的是什么
原因分析	⭐ 先看这一格
排查步骤	怎么一步步查到的
解决措施	最后怎么修的

⭐ 为什么先看「原因分析」别直接抄「解决措施」： 别人环境的解决措施，在你环境里可能不适用 —— 看懂原因，才知道自己这情况算不算同一个问题。

4.2 两个入口（官方给了两个，别只知道一个）

入口	说明
社区案例库	公开可查
计算产品案例查询助手	官方注明仅对伙伴 / 工程师开放

案例链接规则：https://www.hiascend.com/document/caselibrary/detail/<案例编号>

案例编号的前缀 = 来源模块（如 aclcase_ / dvppcase_ / ptacase_ / topic_）。

4.3 ⭐⭐ 去具体化（最容易做错的一步）

搜索前，先把报错里"属于你这台机器"的东西擦掉：

擦掉	留下
路径 / 进程号 / 时间戳 / 设备号 / 容器 ID	错误码 / 英文短语 / 库名 / 模块名

⚠️ 但有一个例外：容器 这个词要保留 —— 它是"场景类别"，不是你这台机器的身份证（去掉了就搜不到容器类问题）。

实测对照：

搜索词	结果
`Acl open device`	1 条
`507033`	2 条
`davinci5`（带你自己的设备号）	0 条 ⚠️

⭐ 这就是"去具体化"的价值：带着自己的设备号搜，永远搜不到。

4.4 怎么用（八步）

① 抄报错  →  ② 去具体化（在搜之前！）
③ 本机自动搜案例（不用开浏览器）
④ 人工进库再搜一遍（两条通道互为补充）
⑤ 读四格  →  ⑥ 对号入座（最值钱的两步）
⑦ 落地验证：改一步，验一步
⑧ 收口 + 诚实

⚠️ 一个针对容器环境的提醒： 别照抄案例标题里的 device 0 ✗ —— 容器里的设备号可能不是 0（一律用 npu-smi info -l 查出来的那个）。 也别照着物理机教程动驱动 ✗ —— 容器里驱动在宿主机 / 平台预装。

五、工具四 · 报错码速查（E4）

5.1 ⭐⭐ 最重要的一条：错误码不是一套体系，是好几套并存

体系	码长什么样	谁产生的
AscendCL 通用返回码	`100000` / `200000` / `300000` / `500000`	AscendCL 对外接口
Runtime 返回码	`107000` / `207000` / `507000`	Runtime 运行时
GE 图引擎返回码	`145000` / `245000` / `345000` / `545000`	Graph Engine
算子库 aclnn 返回码	`161001` / `361001` / `561xxx`	单算子 aclnn 接口
打屏资源码 / 内部码	`EE1023` / `retCode=0x7020023`	Runtime→Driver 硬件调度
安装器 / 驱动码	`0x0091`（十六进制）	驱动与安装器

⭐ 所以拿到一个码，第一件事不是查表，是问：这是哪一套的码？ ⚠️ 它们的规则不一样 —— 比如 1/2/3/5 分段是 AscendCL 的规则，安装器另有体系。

5.2 一行三码：根因常在最内层

官方案例里的真实形态：

ErrCode=207005   desc=...   InnerCode=0x7020023

→ 一行里有三个码，外层是"表现"，InnerCode 才更接近根因。

5.3 怎么用（拿到一个码的顺序）

① 先判断这是哪一套码（看它长什么样：数字？十六进制？EE 开头？）
② 数字码 → 看第一位数字，判断能不能自己修（1/2/3 能，5 不能）
③ 十六进制 / EE 码 → 官方没有成文总表，只能"按现象搜案例库"
④ 一行多码 → 往内层看（InnerCode 更接近根因）
⑤ 收口：把码 + 模块 + 位置一起拿去搜

⚠️ 诚实标注：安装器 / 驱动的十六进制码（如 0x0091）官方没有成文错误码总表 —— 只能靠现象搜案例库 + 查安装日志（/var/log/ascend_seclog/ascend_install.log）。

命令　grep -n "<错误码>" <日志文件>

含义：在日志里按码定位到那一行 拆解：grep（找含关键词的行）＋ -n（显示行号）用法：grep -n "0x5000BB0" /var/log/ascend_seclog/ascend_install.log 期望：打印出行号 + 那一行内容 不过会怎样：没有输出 → 这个码不在这个日志里，换日志或换码

六、怎么算学会了（验收）

#	判据	通过标准
①	能拆报错的 5 块	拿到一条报错，能指出级别 / 模块 / 位置 / 码 / 补充
②	能看码段定"能不能修"	`1/2/3` 开头 → 自己能修；`5` 开头 → 收日志反馈
③	能找到三处日志	应用类 / MindIE / Device 侧都知道在哪、怎么导
④	会去具体化	不带自己的设备号、路径、pid 去搜
⑤	能判断码属于哪一套	不拿安装器的码去套 AscendCL 的规则

七、三个最容易踩的坑

#	坑	症状	怎么办
1	从上层往下瞎试	花了很久，改了不该改的	先定位层（三步定位法）
2	拿带自己设备号的报错去搜	一条都搜不到	先去具体化
3	把所有码当成一套规则	套错了规则，结论反了	先问"这是哪一套码"

⚠️ 还有一条：desc=[driver] / desc=[component] 这类补充块，常常直接告诉你答案 —— 先看它，再动手。

附 · 报错 → 该回哪一层（这一节最省时间）

你看到	大概率在哪一层	先查什么
`npu-smi: command not found`	L0 硬件	驱动装了吗
`ls /dev/davinci*` 没有	L0	驱动 / 容器挂载
`$ASCEND_HOME_PATH` 为空	L1 基础软件	有没有 `source set_env.sh`
`check driver compatibility failed`	L1	驱动与 CANN 版本配套
`Failed to load the libdcmi.so`	L0 / L1	驱动、动态库路径
`No module named 'torch'`	L2 框架	框架没装
`No module named 'torch_npu'`	L2	插件没装 / PyTorch 装错版本
`.npu()` 报错	L0 / 容器	卡在不在、挂进容器了吗
算子相关报错	L1	ops 包型号对不对
端口起不来	L3 服务	看日志第一条报错
`Service is not available`	L3	未就绪，等
返回 200 但内容为空	L3	空补全不算成功
`5XXXXX` 开头	底层	收日志反馈，别死磕

⭐ 归根结底一句话：先定位层，再找原因。

附 · 命令速查（复制即用）

# ① 拆报错（先看这几块）
#   [ERROR] ASCENDCL runtime/feature/src/device.cc:312 ErrCode=507033 desc=[driver]

# ② 定位（三处日志）
ls ${HOME}/ascend/log                    # 应用类日志
ls ~/mindie/log ~/mindie/log/debug       # MindIE 日志
npu-smi info -l                          # 先拿设备号（导日志要用）

# ③ 搬 Device 日志
msnpureport -f                           # 导出到 Host
#   ⚠️ 完整参数以官方《msnpureport 工具使用指南》为准

# ④ 调级别重跑
export ASCEND_GLOBAL_LOG_LEVEL=<级别>     # 只在当前终端有效

# ⑤ 在日志里按码定位
grep -n "0x5000BB0" /var/log/ascend_seclog/ascend_install.log

# ⑥ 一键收（⚠️ 集群/容器/虚机/云不支持）
asys

⭐ 三个判据速记： - 码第一位是 5 → 别死磕，收日志反馈 - 搜之前先去具体化 → 否则一条都搜不到 - 先问"这是哪一套码" → 六套规则不一样

本部分浓缩自：昇腾部署课件_E1_报错定位法 / _E2_日志在哪里 / _E3_官方案例库用法 / _E4_报错码速查 上一层：D 层 · L3 服务　下一部分：F 部分 · 场景实战

E 层部署指南 · 排障