第一次接到这种“从零到一”的任务时我其实挺兴奋的——一台全新的Aarch64服务器官方指定装OpenEuler系统AI芯片是昇腾910B机房还是隔离网络外网一概不通。兴奋完了就是头疼因为这意味着每一个依赖、每一个软件包都得提前在联网环境里准备好再一点点搬进去。这篇博文就记录了我从空机器到能跑通离线推理任务的全过程包括方案设计、版本选型、离线依赖收集、驱动和CANN安装、推理框架搭建以及踩过的各种坑。如果你也要在国产化平台上搭昇腾推理环境尤其是处在纯内网环境这篇应该能帮你少走很多冤枉路。1. 项目背景与整体方案设计1.1 为什么是Aarch64 OpenEuler 昇腾910B组合在国产服务器上做AI推理现在基本绕不开这套组合。Aarch64架构的典型代表是鲲鹏920处理器单颗64核起步整机柜部署时功耗和密度都有优势很多机房新建的信创资源池就是这种形态。OpenEuler是开源的Linux发行版系统本身对多架构支持得不错尤其对鲲鹏和昇腾做了不少内核级适配so、编译器和容器生态都跟着调整过跑AI负载会比CentOS更省心。昇腾910B则是目前出货量比较大的AI加速卡训练和推理都能干显存叫HBM带宽高、容量大跑大模型推理时优势明显。这三样东西放到一起基本就是一套国产化AI基础设施的标准底座。我在项目里遇到的情况是业务方要求算法模型全部部署到这种国产平台上但机房是物理隔离的没有外网也没法从公网拉包。所以整个环境构建策略必须从“在线安装”换成“离线搬运”先把所有东西准备好再一次性拷进去。这也决定了后面每一步都要比平时多想一层这个包有没有依赖那个.so会不会版本不对如果不提前规划好现场会非常狼狈。1.2 离线环境的核心难点在于依赖收集有人可能会觉得离线安装不就是把安装包拷进去吗其实难点不在安装本身而在依赖收集。昇腾软件栈分三层底层是板卡固件和驱动中间是CANN异构计算架构上层是PyTorch、MindSpore这类AI框架。每一层都有依赖而且各层的版本必须严格对齐。驱动版本不匹配CANN版本跑起来就是算子报错CANN版本不匹配torch_npu版本import的时候直接崩。更麻烦的是系统层面的依赖也得一起准备。比如装驱动的时候需要gcc、make、内核头文件装CANN需要python3-devel、cmake跑PyTorch还需要一堆Python包。这些在联网机器上敲一条命令就装好了在离线机器上就得逐个rpm包收集好、拷过去、再统一安装。关键是你不知道哪个包会缺所以最好一次把常见依赖全部拉齐。1.3 整体流程先在心里过一遍动手之前我把整个流程拆成了六步系统安装与基础配置、离线依赖准备、驱动和固件安装、CANN部署、推理框架搭建、模型验证。前两步解决“机器能开机、能装软件”的问题中间两步解决“NPU能被系统识别、能跑算子”的问题最后两步解决“模型能跑出结果”的问题。实际操作中我准备了一台有网的中间机器操作系统和目标机器保持一致都是Aarch64的OpenEuler。所有rpm包、run包、Python wheel包全部在这台中间机上提前下载整理成目录后一起拷贝到离线机。拷贝方式我用的是U盘加内网共享目录如果你有内网HTTP服务也可以用wget下载逻辑一样。2. 系统安装与基础依赖准备2.1 OpenEuler系统安装的几个关键点装系统本身不难去OpenEuler官网下载对应Aarch64的ISO镜像刻录或挂载虚拟光驱引导就行。我选的版本是openEuler 22.03 LTS SP3这是一个长期支持版本稳定性有保障。安装界面默认是英文注意选择“Server”环境并且在软件选择里勾上开发工具组不然后面连gcc都找不到还得手动补装。装完系统第一件事是配静态IP。数据中心机房一般不允许设备自动获取IP我用nmcli命令手动配置nmcli connection modify eth0 ipv4.method manual ipv4.addresses 192.168.10.20/24 ipv4.gateway 192.168.10.1 ipv4.dns 192.168.10.1 nmcli connection up eth0这里接口名不一定是eth0建议用ip a先看一下实际网卡名。配好之后ping一下网关确认网络通再关闭防火墙和SELinux避免后面装软件和容器时遇到不必要的权限拦路systemctl disable --now firewalld sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config改完SELinux需要重启才生效我一般系统装好就顺手做了免得后面忘。2.2 用本地ISO搭一个离线yum源这步是离线环境的一个隐藏神器。OpenEuler的ISO镜像本身是完整的软件仓库把ISO挂载后直接把它配置成本地yum源很多基础软件包就能直接从光盘装不需要从外网拉。命令很简单mount -o loop openEuler-22.03-LTS-SP3-aarch64-dvd.iso /mnt cat /etc/yum.repos.d/local.repo EOF [local] namelocal repo baseurlfile:///mnt enabled1 gpgcheck0 EOF dnf clean all dnf makecache这样就能直接dnf install gcc gcc-c make cmake python3-devel unzip net-tools了。比从中间机逐个收集rpm省事得多而且版本和系统自带的内核完全匹配不容易出兼容问题。这个技巧我强烈建议离线装机先做。注意如果你需要装的软件包里ISO里没有比如docker-ce这种非系统仓库的包那还是得走中间机收集rpm的路子或者在联网的Aarch64机器上把对应的repo源包下载下来再带进内网。2.3 OpenEuler单用户模式与应急维护离线环境最怕系统配置改动后起不来或者root密码忘记。OpenEuler和大多数systemd系统一样提供了单用户模式作为应急通道。开机到GRUB菜单时按e进入编辑界面找到以linux开头的那一行在末尾追加rd.break然后按Ctrlx引导。进入紧急环境后系统根目录默认是只读挂载的需要先重新挂载mount -o remount,rw /sysroot chroot /sysroot passwd root改完密码执行touch /.autorelabel再退出重启SELinux标签就会自动修复。这个方法在系统维护时很有用尤其是远程机房没有控制台的时候掌握它能救命。3. 昇腾910B驱动与固件离线安装3.1 驱动固件版本匹配与下载昇腾驱动和固件是不同的东西需要分别下载。固件负责板卡底层逻辑驱动负责内核态和用户态的设备访问。910B对应的文件一般是Ascend-hdk-910b-npu-firmware_*.run和Ascend-hdk-910b-npu-driver_*.run在昇腾社区的“软件中心”可以找到选择Aarch64对应的包下载。这里有一个非常关键的坑版本必须和CANN版本匹配。比如CANN 7.0.RC1对应的是某个驱动固件版本CANN 8.0.RC1又是另一套。我的习惯是在下载前先把整个版本矩阵确认好列成表格再逐个下载。版本不匹配导致的错误非常隐蔽经常是编译安装时报错或者npu-smi能识别但跑模型时算子崩溃。我在这个项目里用的组合是CANN 7.0.RC1 配套驱动固件 PyTorch 2.1.0 torch_npu 2.1.0.post5。这个组合当时是官方兼容列表里的稳定组合你也可以根据自己手上的模型和对框架的要求去昇腾官网查最新的兼容矩阵。3.2 离线安装驱动和固件驱动和固件都是.run文件安装顺序有讲究先装固件再装驱动最后重启。全程用root执行不要用普通用户跑否则会提示权限不足。安装命令chmod x Ascend-hdk-910b-npu-firmware_*.run ./Ascend-hdk-910b-npu-firmware_*.run --full ./Ascend-hdk-910b-npu-driver_*.run --full reboot--full参数是完整安装会执行编译内核模块、安装用户态工具等全套流程。如果内核头文件缺失这一步就会报错所以前面用本地ISO yum源把make、gcc、kernel-devel装齐很重要。安装过程通常需要几分钟日志会打印在屏幕上也会写入/usr/local/Ascend/driver下的日志目录。我建议全程录屏或者把输出重定向到文件万一出错后面排查有据可查。3.3 验证驱动是否正常工作重启之后第一件事就是验证NPU是否被系统识别。昇腾驱动自带工具叫npu-smi执行npu-smi info正常情况会列出设备列表包括板卡型号、HBM容量、AI Core状态、温度、功耗等信息。能看到设备就说明驱动和固件层面基本没问题了。如果提示找不到设备先别慌按这个顺序排查先看硬件有没有被PCIe识别执行lspci | grep -i ascend有输出说明板卡在总线上再看内核模块有没有加载执行lsmod | grep drv_pcie没加载就手动modprobe drv_pcie_dev最后看驱动日志通常在/usr/local/Ascend/driver/tools下里面有系统诊断工具。日志里面的错误信息一般能直接指出问题。4. CANN工具包与AI推理框架部署4.1 CANN Toolkit离线安装CANN是昇腾的计算架构地位类似于CUDA所有跑在昇腾上的算子最终都通过它调度。CANN有多种安装包形态离线推理环境我选的是Toolkit完整包下载文件名类似Ascend-cann-toolkit_7.0.RC1_linux-aarch64.run。安装前注意创建好昇腾用户和用户组这是官方推荐做法。一般我直接用root安装装这个包时加--install-for-all参数这样所有用户都能使用CANN环境不用每个用户单独配权限。命令./Ascend-cann-toolkit_*_linux-aarch64.run --install --install-for-all默认安装在/usr/local/Ascend/ascend-toolkit下安装过程纯粹是拷贝和解压没有编译步骤几分钟就完。装完把环境变量写进用户配置文件否则每次开新终端都要手动sourceecho source /usr/local/Ascend/ascend-toolkit/set_env.sh ~/.bashrc source ~/.bashrc4.2 PyTorch torch_npu 离线安装昇腾上跑PyTorch需要装一个插件叫torch_npu它类似CUDA版的PyTorch插件让模型通过.to(npu)就能把计算调度到昇腾卡上。版本匹配表我列一下我当时用的组合组件版本CANN7.0.RC1PyTorch2.1.0torch_npu2.1.0.post5torchvision0.16.0torch_npu和PyTorch的版本号是一一对应的不能混装。在联网的Aarch64中间机上用pip下载时注意指定平台参数否则可能下到x86_64的包pip download torch2.1.0 --platform linux_aarch64 --only-binary:all: -d /data/python_packages pip download torchvision0.16.0 --platform linux_aarch64 --only-binary:all: -d /data/python_packages pip download torch_npu2.1.0.post5 --platform linux_aarch64 --only-binary:all: -d /data/python_packages--only-binary:all:保证只下载编译好的wheel包--platform linux_aarch64确保架构正确。离线机上执行pip install /data/python_packages/*.whl即可。这种方式会连带下载所有Python层面的依赖比在离线环境里逐个补包高效得多。4.3 验证CANN和torch_npu是否能正常调用装完以后写个最简脚本验证环境python -c import torch; import torch_npu; print(torch.__version__); print(torch.npu.is_available()); print(torch_npu.npu.device_count())能看到True和至少1个设备号就说明CANN和torch_npu的链路是通的。如果import torch_npu报错最常见原因是CANN环境变量没有生效解决办法是先source set_env.sh再执行Python。还有一次我遇到的是libascend_acl.so找不到后来发现是驱动和CANN版本不一致重新装配套版本才解决。5. 离线推理任务的完整验证5.1 用ResNet50跑通一个图像分类样例环境搭完不能只停留在“能import”要跑真实模型才算数。我拿ResNet50做验证因为模型结构简单、pth权重好找适合验证NPU链路是否真的能跑算子。权重文件记得提前在联网机器上下载好不然离线环境里没法下载。推理脚本基本就是标准PyTorch流程唯一区别是把模型和输入搬到NPU上。大概几十行代码就能完成加载模型、加载图片、预处理、推理、输出top-k结果。关键代码片段import torch import torch_npu from torchvision import models, transforms from PIL import Image model models.resnet50(weightsNone) model.load_state_dict(torch.load(resnet50.pth, map_locationcpu)) model model.to(npu) model.eval() img Image.open(test.jpg).convert(RGB) transform transforms.Compose([ transforms.Resize(256), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) input_tensor transform(img).unsqueeze(0).to(npu) with torch.no_grad(): output model(input_tensor) pred output.argmax(dim1).item() print(pred)第一次跑通时看到正常的分类结果输出整个环境才算真正完成。建议把这份脚本和权重文件留在目标机器上后面每次改系统配置或换硬件都先跑一遍确认环境没问题。5.2 用npu-smi观察推理时的性能表现跑推理的时候别光盯着终端输出另开一个终端执行npu-smi info可以看到NPU的实时利用率、HBM占用率、温度和功耗。我第一次跑ResNet50时AI Core利用率一直在40%左右原因是batch size设成了1单张图推理时间太短算子之间的调度开销占了大头。把batch size调到32或者做并发推理后利用率能跑到80%以上。多卡场景下还需要注意HCCL环境变量的设置比如HCCL_CONNECT_TIMEOUT和HCCL_IF_INTERFACE否则组网通信容易超时。离线环境里网络拓扑是固定的建议把通信超时调大一点避免大模型分布式推理时因为握手超时而频繁失败。5.3 容器化部署的补充说明现场环境如果需要用容器跑推理昇腾有自己的容器运行时支持。离线机器上安装docker社区版一般也是在联网中间机上下载docker-ce相关的rpm包再搬进去。跑容器时要把NPU设备映射进容器需要在docker启动命令里加--device /dev/davinci0同时挂载驱动和CANN相关目录。容器方案我一开始没打算引入但客户现场明确要求“应用全部容器化”所以补了一步。如果你有同样的需求提前确认好镜像里的CANN版本和宿主机驱动版本一致否则容器内即使能启动一旦调用NPU也会报版本错误。6. 常见问题与排查技巧实录6.1 离线环境搭建问题速查表现象可能原因解决办法npu-smi info 找不到设备驱动未装或未重启固件和驱动版本不匹配按“先固件后驱动再重启”顺序重新安装import torch_npu 报错提示libascend_*.so找不到CANN环境变量未生效source /usr/local/Ascend/ascend-toolkit/set_env.sh驱动安装时提示缺少内核头文件kernel-devel未装用本地ISO yum源安装kernel-devel注意内核版本必须一致pip install 后import报CPU指令集错误下载到了x86_64的wheel包重新用--platform linux_aarch64下载docker容器内无法使用NPU未映射设备或驱动未挂载加--device /dev/davinci0并挂载CANN和驱动目录系统重启后NPU失效内核模块未自动加载检查/etc/rc.local或systemd服务手动modprobe drv_pcie_dev这张表是现场排障的真实汇总。最典型的坑就是版本不匹配我遇到过好几次每次排查到最后都是某两个组件的版本对不上。6.2 我的三个独家避坑经验第一版本矩阵一定要在动手前确认好。我后来给自己定了个规矩每次搭环境前先在Excel里列一张版本表驱动、固件、CANN、PyTorch、torch_npu全部写清楚安装时严格按表执行不临时改版本。第二离线依赖收集要以“需求清单”为抓手。不要想到什么装什么先把要装的软件列出来然后逐个确认依赖再在中间机上一次性收集。这个习惯能帮你省下大量来回拷贝的时间。第三日志是排障的起点而不是终点。昇腾的日志体系其实非常完整驱动日志在/var/log/npuCANN的报错会打印在Python的traceback里docker容器日志在/var/lib/docker/containers下。遇到问题先认真读日志一般都能定位到缺失的库或版本不匹配。6.3 最后分享一点个人体会这套环境我前后搭过不止一次第一次最痛苦后面就顺畅多了。整个流程做下来最大的感受是离线环境比在线环境更容易暴露问题因为所有依赖都必须提前想清楚没有“临时装一下”的机会。但也正因如此搭完一次之后你对整个软件栈的理解会比在线安装深刻得多。如果你正好也在搭类似的离线推理环境希望这篇记录能给你省点时间。