上周末接了个排障需求一台 Atlas 800型号9000服务器板载昇腾910A加速卡操作系统是 ARM 架构的 openEuler 22.03 LTS。客户说 CANN 8.5.0 装不上装上也用不了npu-smi 查不到设备atc 转模型一直报 soc version 非法。我把这台机器从前到后过了一遍从安装报错到模型转换失败能踩的坑基本都踩了一遍。这篇就记录这次的完整排障过程先说清楚这套硬件和软件组合哪里容易出问题再讲为什么 C ANN 8.5.0 在 910A / ARM 上会有兼容性风险最后给出一份可以直接照着做的排查流程和常见报错速查表。正在做昇腾部署的算法工程师、运维同学可以参考至少能少熬一个通宵。1. 先把环境和问题看清楚1.1 这是一台什么机器先别急着装包先把标题里的每个关键词拆开看。CANN 8.5.0 是昇腾的软件栈版本910A 是昇腾芯片型号Atlas 800型号9000是服务器整机形态ARM 是服务器 CPU 的指令集架构。这四个词单独拿都很好理解但拼在一起就是一套完整的软硬件匹配关系。Atlas 800型号9000这类服务器配的是鲲鹏920 处理器跑的是 aarch64 指令集也就是我们通常说的 ARM 机器。和 x86 服务器最大的区别在于整个软件生态都要按 aarch64 重新选包驱动包要选 aarch64固件包要选 aarch64CANN Toolkit 也要选 aarch64连 Python 虚拟环境里要装的第三方包都得注意架构标签。很多人在这里就栽了第一个跟头。910A 也要单独说。昇腾 910 系列里面有 910A、910B 等不同型号驱动和算子库并不完全通用。CANN 8.5.0 安装包对应的是多个 soc_version 集合不是只有一个 Ascend910而是有 Ascend910、Ascend910A、Ascend910B 这一串型号。910A 的卡在工具链里要写作 Ascend910A不能含糊。整套软件栈的层次关系也需要说清楚。最下层是跑在鲲鹏920 上的 Linux 操作系统往上是昇腾 HDK也就是驱动和固件再往上是 CANN Toolkit 和运行时库最上层才是 PyTorch、TensorFlow 这类深度学习框架。标题里只提到了一个 CANN 8.5.0实际排障时任何一层变了都会导致上层不可用。所以我给客户排查时从不只盯着 Toolkit而是先把这套五层结构从头到尾看一遍。1.2 兼容性问题到底长什么样这次遇到的故障现象从安装阶段到运行阶段都有。第一类安装包直接跑不起来。在 ARM 机器上执行下载下来的 .run 包提示”exec format error“。这是新手最容易碰到的问题本质上是把 x86_64 的安装包装到了 aarch64 系统上。Linux 会检查可执行文件 ELF header 里的机器类型架构不匹配就直接拒绝执行不会有任何友好提示。第二类安装能完成但驱动加载失败。安装脚本跑完之后npu-smi info 却看不到设备或者提示模块没有加载。这种情况通常是因为驱动包编译内核模块时系统里缺 kernel-devel 和 gcc或者是内核升级过导致模块的 vermagic 和当前内核不一致。第三类驱动正常了运行库又出问题。atc 命令敲下去提示 error while loading shared librariesPython 里 import te 也报 ModuleNotFoundError。这类问题一半原因是环境变量没 source另一半是 Python 版本和 CANN Toolkit 要求的版本对不上。第四类能转换模型但报 soc version 非法比如 ATC 报 EI0003。这基本是把 Ascend910A 写成了 Ascend910或者跑的是示例脚本脚本里默认是 910B 的 soc_version。第五类设备初始化失败。一切就绪后调用 ACL 接口acl.rt.set_device 返回非 0 错误码比如 500002 这类和设备初始化相关的错误。这通常指向驱动、固件和 CANN 的版本组合不配套。这些现象表面看各不相同根源基本都指向同一件事平台架构、版本矩阵和安装顺序没有对齐。下一节把这三个原因逐个拆开讲。2. 为什么会在 ARM 上翻车根因拆解2.1 版本矩阵这件事怎么强调都不过分昇腾的软件栈不是装一个 CANN 就结束了至少由四部分组成操作系统、驱动、固件、CANN Toolkit。驱动负责把 NPU 设备暴露给操作系统固件负责芯片内部微码CANN Toolkit 负责上层算子编译和运行时它们之间有一份严格的配套表。拿 CUDA 来类比CUDA 12 要求 NVIDIA 驱动不低于某个版本版本低就装不上。昇腾比这更严格驱动和固件本身要匹配Toolkit 又要求在指定的驱动版本范围内运行。CANN 8.5.0 的发布说明中会明确列出它验证过的驱动和固件版本版本差一点都可能出现怪问题比如 npu-smi 报错、算子编译失败、一跑推理就崩。所以排障第一步建议先把版本基线表做出来格式大概是这样组件命名示例说明操作系统openEuler 22.03 LTS aarch64必须用 aarch64 系统驱动Ascend-hdk-910-npu-driver_xxx_linux-aarch64.run具体版本以配套表为准固件Ascend-hdk-910-npu-firmware_xxx_linux-aarch64.run与驱动严格配套CANN ToolkitAscend-cann-toolkit_8.5.0_linux-aarch64.run官方下载页选择 aarch64表格里的 xxx 不是让你猜是让你打开昇腾社区官网上《CANN 8.5.0 软件包与固件驱动版本配套表》把对应版本号填进去。我在社区里看过很多类似提问”CANN 8.5.0 为什么在 910A 上跑不起来“再一问驱动版本不在配套表里问题到这里就已经结束了。装好后怎么确认当前版本是否对齐可以用下面这条命令npu-smi info cat /usr/local/Ascend/ascend-toolkit/latest/aarch64-linux/version.cfgnpu-smi info 能看到驱动和固件版本version.cfg 里是 Toolkit 自身的版本信息。两个都对上了再继续往下排查。2.2 ARM 平台的三类经典坑第一类坑架构选错。昇腾官方下载页面同一个版本会同时提供 linux-x86_64 和 linux-aarch64 两种安装包文件名后缀写得很清楚。问题往往出在习惯操作上比如直接从 x86 服务器拷贝一个离线安装包过来或者下载页面点了默认跳转的 x86 版本。解决很简单安装前先执行 arch 确认是 aarch64再核对安装包文件名里的平台字段。第二类坑内核模块编译与加载。昇腾驱动安装到 ARM 平台时需要针对当前内核版本编译内核模块。系统里没有 kernel-devel、gcc、make 的话安装过程会直接报错如果内核升级过模块编出来是旧内核的 vermagic加载时会被拒绝。openEuler 上尤其常见因为内核更新比较频繁。装驱动前先查内核版本装 kernel-devel 时尽量选与当前内核一致的版本。第三类坑系统库和 Python 环境。ARM 平台上的 glibc、libstdc 版本和 x86 不完全一致一些在 x86 上正常的 conda 环境搬到 ARM 上就会行为异常。CANN 对 Python 版本有明确要求超出支持范围会出现 import te 失败或者 torch_npu 编译不过。pip 装包时也要选支持 aarch64 的版本不能闭眼装一个 manylinux x86_64 的 wheel。如果你习惯用 conda 建虚拟环境有个细节要注意创建环境时最好指定平台变量比如 CONDA_SUBDIRlinux-aarch64否则 conda 可能去拉取 x86_64 的包。我在 ARM 机器上踩过这个坑环境建好后一装 torch 就报错最后发现是 conda 默认平台变量不对。2.3 910A 与新一代芯片的适配差异标题里特意写了 910A不是没原因的。昇腾 910 系列中910A 和 910B 虽然都带”910“这个名字但算子库、驱动固件、soc_version 的命名都有差异。CANN 8.5.0 对不同 soc_version 的支持是分别列出的910A 能用的算子集合和 910B 并不完全相同。实操中一个典型错误是拿面向 910B 的模型转换命令直接跑 910A 的卡结果 atc 报 soc version 非法。反过来把 910A 的 soc_version 写成 Ascend910某些版本下也能出结果但转出来的 om 在 910A 上推理时性能和稳定性都可能有异常。我自己转换前一定先用 npu-smi 确认芯片型号再对照配套表定 soc_version。各类芯片的 soc_version 写法建议直接按对应关系来芯片型号soc_version 常见写法对应平台昇腾 910AAscend910Aaarch64昇腾 910BAscend910Baarch64昇腾 310PAscend310Px86 / aarch64910A 毕竟是上市更早的平台新版本 CANN 对它的算子优化覆盖不像新一代芯片那么全。如果遇到某个算子编译失败先不要怀疑板子坏了先查这个算子在当前 soc_version 下是否在白名单里。这种信息在 Toolkits 安装目录的算子支持列表文档中都能查到。3. 一步步排查并解决实录3.1 第一步核对硬件与系统基线拿到机器后我做的第一件事是建环境台账。命令很简单lscpu uname -m arch cat /etc/os-release npu-smi infolscpu 看 CPU 型号和核数uname -m 确认是不是 aarch64cat /etc/os-release 看系统发行版和版本号。npu-smi info 这一步如果驱动没装会提示找不到设备如果驱动正常可以直接看到板卡列表、芯片型号、驱动版本和固件版本。这一步最大的意义是避免在错误环境上反复试错。比如系统是 openEuler 22.03内核大版本是 5.10那下载驱动时就要注意能不能找到匹配内核版本的安装包。如果当前系统根本不在 CANN 8.5.0 的支持列表里后面再怎么重装也没有意义。3.2 第二步把旧环境彻底清理干净客户机器之前装过别版本的 CANN我不建议直接覆盖安装而是先把旧环境清干净。清理顺序是 Toolkit、Driver、Firmware最后再清残留目录。# 卸载旧 Toolkit /usr/local/Ascend/ascend-toolkit/latest/aarch64-linux/bin/uninstall.sh # 或者用原安装包卸载 ./Ascend-cann-toolkit_xxx_linux-aarch64.run --uninstall # 卸载旧驱动 /usr/local/Ascend/driver/tools/uninstall.sh --uninstall # 清理残留目录和动态库缓存 rm -rf /usr/local/Ascend rm -rf /var/log/npu rm -rf /root/ascend rm -f /etc/ld.so.conf.d/ascend.conf ldconfig实操中经常碰到 uninstall.sh 路径不对或报错的情况。一个更省事的办法如果还留着当时的 .run 安装包直接用 --uninstall 参数卸载因为它知道自己装了哪些文件卸得比较干净。没有原包就只能手动找 uninstall.sh路径通常在 /usr/local/Ascend 下。清理完成后建议 reboot 一次。旧的内核模块可能还驻留在内存里不重启的话新驱动加载时很容易出现新旧模块共存导致的冲突。3.3 第三步按配套表装驱动、固件和 CANN环境清完后下一步是安装。安装顺序一定不能乱先驱动再固件再 CANN Toolkit。为什么先驱动再固件固件烧录依赖驱动提供的与设备通信的通道。如果先烧固件后装驱动等于驱动程序还没起来就要向设备发指令失败概率很高。不少安装报错都是顺序问题。命令示例实际版本号请以配套表为准# 安装驱动 ./Ascend-hdk-910-npu-driver_24.1.rc1_linux-aarch64.run --full --install # 安装固件 ./Ascend-hdk-910-npu-firmware_24.1.rc1_linux-aarch64.run --full --install # 安装 CANN Toolkit ./Ascend-cann-toolkit_8.5.0_linux-aarch64.run --install # 配置环境变量 source /usr/local/Ascend/ascend-toolkit/set_env.sh这里的 --full --install 是昇腾 HDK 安装包常见的全量安装参数会一并处理依赖和默认配置。CANN Toolkit 的 --install 是默认安装。如果你需要自定义路径可以加 --install-path 参数但我建议在没把握之前都用默认路径不然环境变量和 PATH 很容易乱。装完以后执行 npu-smi info 验证。正常情况下会看到芯片数量、芯片名称名称栏里会显示 Ascend910A同时还有驱动版本、固件版本和运行状态。如果显示设备存在但状态异常先看 /var/log/npu/ 下的日志再考虑是否重启。还有一个小细节source 完环境变量后执行一下echo $ASCEND_TOOLKIT_HOME确认路径指向 /usr/local/Ascend/ascend-toolkit/latest。如果显示空说明 set_env.sh 路径不对或者 Toolkit 没装到位。3.4 第四步模型转换验证驱动正常后我习惯先用一个小 ONNX 模型跑一次 ATC 转换把算子编译链路验证一遍。atc --modeltest.onnx \ --framework5 \ --outputtest \ --soc_versionAscend910A \ --input_shapedata:1,3,224,224framework5 表示输入是 ONNX 模型。soc_version 必须和芯片型号严格一致这里是 Ascend910A。转换成功后会生成 test.om 文件并且输出一段编译完成的信息。如果这里报 EI0003基本可以断定是 soc_version 写错了。如果算子编译环节提示某个算子不支持先查这个算子在 910A 下的支持情况再决定是换算子实现还是升级配套版本。转换目录里还会生成 fusion_result.json 之类的中间文件这些是排查算子问题的线索别急着删。另外记得确认 /usr/local/Ascend/ascend-toolkit/latest 下确实有 aarch64-linux 目录。如果装的是 x86_64 包ATC 可能装上了但跑起来一定会出错因为动态库路径根本不匹配。3.5 第五步运行阶段验证与权限细节模型转换通过后我还会写一个简短的 Python 脚本验证 ACL 接口确保设备初始化、Context 创建、内存申请都没问题。import acl ret acl.init() assert ret 0 ret acl.rt.set_device(0) assert ret 0 context, ret acl.rt.create_context(0) assert ret 0 # 申请 16MB 设备内存做验证 size 16 * 1024 * 1024 ptr, ret acl.rt.malloc(size, 2) assert ret 0 print([OK] ACL init and device memory alloc success)跑这个脚本前先确认当前用户的权限。驱动和固件建议用 root 安装但业务运行用普通用户更安全。普通用户要加入昇腾设备对应的用户组具体组名因驱动版本而异常见是 HwHiAiUser 所在组。同时要确认环境变量 LD_LIBRARY_PATH 里包含 /usr/local/Ascend/ascend-toolkit/latest/aarch64-linux/lib64。缺了这些前置条件脚本要么报 No module named acl要么 import 成功但 set_device 出错。如果 set_device 返回非 0 错误码先看 npu-smi info 里设备是否 online再看驱动固件是否和配套表一致最后查 dmesg。设备初始化失败八成以上是驱动固件不匹配而不是业务代码写错。4. 典型报错速查与独家避坑心得4.1 一条典型的排障路径这次从”安装包跑不起来“一路修到”能转模型、能跑推理“表面看步骤不少其实就是环境台账、清理环境、按配套表重装、链路验证四步。下面这张表是高频报错速查遇到问题先对号入座。现象可能原因快速处理安装时报 exec format error用了 x86_64 安装包换成 linux-aarch64 后缀的包npu-smi info 提示模块未加载驱动未正确安装或内核变了重装驱动并 rebootatc 报 error while loading shared libraries环境变量未 source执行 source set_env.shpython 报 No module named teToolkit 未安装或 Python 版本不对检查 Toolkit 安装并调整 Pythonacl.rt.set_device 返回非 0驱动固件不配套或设备未就绪按配套表重装驱动固件ATC 报 EI0003 soc version invalidsoc_version 写错改为 Ascend910A算子编译失败算子在 910A 上不在白名单内查算子支持列表或调整配套版本dmesg 报 version magic mismatch内核升级后没重编驱动装配套内核并重装驱动这张表覆盖了我遇到过的九成问题。剩下的一成大多和具体业务代码有关但排查思路相同先确认硬件和驱动正常再往上层怀疑。4.2 几条用时间换来的心得第一不要在 x86 和 ARM 机器之间复用安装脚本。看起都是 Linux 命令但安装包二进制格式不同系统库版本要求也不同一个通用脚本往往带来一串新问题。第二安装顺序比我一开始想象的重要。第一次处理昇腾驱动时我也觉得”先驱动后固件“只是个约定。直到有一次先刷固件npu-smi 直接报烧录失败才意识到固件依赖驱动通道是实打实的技术限制。第三日志比报错信息有用得多。CANN 日志一般在 /var/log/npu/ 和 /root/ascend/log/ 下安装日志在 /var/log/ascend_install.log。看到报错先去翻日志往往能看到更具体的错误链而不是停留在第一层表象。第四普通用户跑业务前先检查用户组。把用户加进设备对应的组再 source 环境变量看起来是小事实际能避免”代码一样、权限不同、结果不同“的诡异问题。第五每次安装和卸载都保留原 .run 包。卸载时用原包 --uninstall 参数比手动清理可靠得多重装时也省了重新下载的时间。4.3 求助前要准备什么如果排到这一步还没解决就别硬扛了。求助前把信息准备齐环境清单操作系统版本、内核版本、CANN 版本、驱动固件版本、CPU 架构。输出结果npu-smi info 完整输出、dmesg 里与 npu/ascend 相关的日志、安装日志、报错界面截图。最小复现一个有问题的命令或脚本并写明它在哪一步失败。把这些整理成一份文档再拿去社区或提工单处理效率会高很多。最怕只丢一个”atc 报错“的截图没有环境信息双方来回确认就会耗费大量时间。我个人在实际操作中的体会是CANN 8.5.0 在 910A / Atlas 800型号9000/ ARM 这套组合上真正的问题不是”昇腾软件做不了 ARM“而是整套组合的版本基线必须一次对齐。平台架构、驱动、固件、Toolkit 四个变量哪个动了其他三个都要重新确认。我后来把每次装机的环境基线都做成配置表上板之前按顺序核对一遍几乎没有再因为兼容性问题熬夜。最后再分享一个小技巧在 ARM 机器上看到 .run 包报 exec format error第一反应不要改权限先看文件名里有没有 linux-aarch64这一个检查能省至少半小时。