昇腾910B单机8卡环境配置全流程：从驱动安装到hccl-test运行

昇腾910B单机八卡环境实战：从零搭建到集群通信验证

最近在实验室部署一台搭载了八颗昇腾910B处理器的训练服务器，整个过程就像是在组装一台精密的仪器，每一个环节的严丝合缝都决定了最终的性能表现。对于从事大规模模型训练的研究员和工程师来说，一个稳定、高效的硬件环境是开展一切工作的基石。昇腾910B作为国产AI计算芯片的代表，其强大的算力和集群通信能力，尤其适合需要高带宽、低延迟数据交换的分布式训练场景。这篇文章，我将以第一视角，带你完整走一遍单机八卡环境的配置、调试与验证流程，其中会穿插不少我实际踩过的“坑”和总结出的技巧，目标不仅仅是让环境“跑起来”，更是要让它“跑得稳”、“跑得快”。

这篇文章面向的是已经具备一定Linux系统管理经验，并计划在昇腾910B平台上进行深度学习开发或性能调优的开发者。我们将不局限于简单的安装命令罗列，而是深入每个步骤背后的原理、常见问题的排查思路，以及如何通过hccl-test这样的工具来定量评估多卡间的通信性能，为后续的大模型训练打下坚实基础。

1. 环境准备与系统基石

在接触任何硬件驱动和软件栈之前，确保操作系统环境符合要求是避免后续无数诡异报错的关键。昇腾的软件生态对系统内核、用户权限等有特定依赖，这一步的细致程度直接决定了整个流程的顺畅度。

1.1 操作系统与内核版本确认

我使用的服务器预装了Ubuntu 20.04 LTS，这是一个长期支持版本，社区资源丰富，兼容性也较好。但昇腾驱动对内核版本有明确要求。经过多次尝试，我发现内核版本5.4.0-26-generic是一个经过广泛验证的稳定版本。使用其他版本，例如更新的5.15内核，极有可能在驱动安装阶段遭遇模块编译失败或加载错误。

如何查看和确认当前内核版本？打开终端，执行：

uname -r

如果输出不是5.4.0-26-generic，你需要进行内核版本切换。这里有个小技巧：不要盲目升级或降级，可以先查看系统已安装的内核镜像列表。

dpkg --list | grep linux-image

然后使用apt安装指定版本的内核：

sudo apt update sudo apt install linux-image-5.4.0-26-generic linux-headers-5.4.0-26-generic

安装完成后，需要更新GRUB引导配置并重启系统：

sudo update-grub2 sudo reboot

重启后再次使用uname -r确认版本已切换成功。这一步看似简单，却是整个流程中第一个也是最重要的“拦路虎”，务必确保无误。

1.2 专用用户与用户组创建

出于安全和管理规范考虑，昇腾的相关服务（如Device Manager）不建议直接使用root账户运行。创建一个专用的用户和用户组是官方推荐的做法。

sudo groupadd HwHiAiUser sudo useradd -g HwHiAiUser -d /home/HwHiAiUser -m HwHiAiUser -s /bin/bash

这里解释一下参数：

• -g HwHiAiUser: 指定主用户组。
• -d /home/HwHiAiUser: 设置家目录。
• -m: 如果家目录不存在则创建。
• -s /bin/bash: 指定默认shell。

创建完成后，可以为该用户设置一个密码，方便后续可能需要su切换操作：

sudo passwd HwHiAiUser

注意：后续部分操作（如驱动安装时的--install-for-all选项）仍然需要root权限，但运行测试和部分工具时，使用HwHiAiUser账户可以避免一些权限问题。

2. 驱动、固件与CANN工具链安装

这是与昇腾硬件直接对话的核心软件层。驱动负责操作系统与NPU之间的基础通信，固件是运行在NPU芯片上的底层软件，而CANN（Compute Architecture for Neural Networks）则是昇腾异构计算架构，包含了算子库、编译器等关键组件。

2.1 获取正确的软件包

首先，你需要前往昇腾社区官网的驱动与固件下载页面。选择对应的产品型号至关重要。对于Atlas 800训练服务器（型号9010）搭配昇腾910B处理器，你需要筛选：

• 产品类型: 训练系列
• 产品型号: Atlas 800 训练服务器 (型号 9010)
• AI处理器型号: Ascend 910
• CANN版本: 选择一个稳定的发布版本（如8.0.RC3），不建议直接使用最新的Alpha/Beta版用于生产环境。
• 驱动版本: 选择与CANN版本配套推荐的版本。

下载通常包含两个文件：

• 驱动安装包: 例如Ascend-hdk-910-npu-driver_23.0.2_linux-x86-64.run
• 固件安装包: 例如Ascend-hdk-910-npu-firmware_7.1.0.4.220.run

同时，在“软件”下载区域，找到对应版本的CANN Toolkit，例如Ascend-cann-toolkit_8.0.RC3.alpha001_linux-x86_64.run。

将这三个文件通过SCP或SFTP工具上传到服务器的某个工作目录，例如~/ascend_packages/。

2.2 安装驱动与固件

进入存放安装包的目录，首先赋予可执行权限：

chmod +x ./Ascend-hdk-910-npu-driver_*.run chmod +x ./Ascend-hdk-910-npu-firmware_*.run

安装驱动时，我强烈推荐使用--full和--install-for-all参数。--full表示完整安装，--install-for-all确保所有用户（包括刚创建的HwHiAiUser）都能访问NPU设备。

sudo ./Ascend-hdk-910-npu-driver_*.run --full --install-for-all

安装过程会输出大量日志，注意观察是否有“FAILED”或“ERROR”字样。成功后，通常会提示需要重启系统或加载内核模块。接着安装固件：

sudo ./Ascend-hdk-910-npu-firmware_*.run --full

固件安装通常较快。安装完成后，强烈建议重启系统，以确保所有内核模块和驱动正确加载。

重启后，可以通过以下命令验证驱动和芯片状态：

npu-smi info

这个命令类似于NVIDIA的nvidia-smi，会输出一个表格，显示所有NPU卡的基本信息（如芯片温度、功耗、内存占用等）。如果能看到8张卡的信息，说明驱动和固件安装成功，硬件已被系统识别。

2.3 安装CANN Toolkit

CANN Toolkit是开发的核心，它包含了AI框架适配器（如PyTorch、TensorFlow插件）、编译器、调试工具和hccl-test等测试工具。

chmod +x ./Ascend-cann-toolkit_*.run sudo ./Ascend-cann-toolkit_*.run --install

安装程序会交互式地询问安装路径，默认是/usr/local/Ascend/ascend-toolkit/latest/，保持默认即可。安装过程会持续几分钟，因为它要解压和配置大量库文件。

安装完成后，需要将CANN的库路径加入到系统环境变量中。最方便的方法是使用CANN自带的脚本：

source /usr/local/Ascend/ascend-toolkit/latest/bin/setenv.sh

为了让环境变量永久生效，可以将这行命令添加到~/.bashrc（对当前用户）或/etc/profile（对所有用户）文件中。

echo "source /usr/local/Ascend/ascend-toolkit/latest/bin/setenv.sh" >> ~/.bashrc source ~/.bashrc

现在，你可以测试一下基础环境是否就绪，例如检查编译器版本：

ascendcl --version

3. 编译与部署通信库：HCCL与OpenMPI

单机多卡训练的核心在于卡与卡之间高效的数据通信。昇腾使用HCCL（Huawei Collective Communication Library）来实现多NPU间的集合通信操作，其作用类似于NVIDIA的NCCL。而hccl-test正是基于HCCL库的一个性能测试工具。为了在多进程间调度这个测试，我们需要一个并行运行时库，这里选择OpenMPI。

3.1 可选：从源码编译HCCL

CANN Toolkit中已经包含了预编译的HCCL库，对于绝大多数用户，直接使用即可，无需自行编译。但在某些特定场景下，比如你需要修改HCCL的源码进行定制化开发，或者需要针对特定网络拓扑进行优化时，才需要从源码编译。

如果需要编译，步骤如下：

git clone https://gitee.com/ascend/cann-hccl.git cd cann-hccl # 切换到与CANN Toolkit匹配的分支，这一点非常重要！ git checkout v0.4-8.0.RC3.alpha003 ./build.sh --nlohmann_path /home/HwHiAiUser/include

编译过程需要一些时间。编译完成后，生成的库文件会输出到指定目录，你需要用它们替换或链接到CANN Toolkit中的原有库。对于初次部署和验证，我强烈建议跳过此步骤，直接使用Toolkit自带的库，以减少复杂度。

3.2 安装OpenMPI

OpenMPI是一个开源的MPI（Message Passing Interface）实现，hccl-test通过它来启动多个进程，每个进程绑定到一张NPU卡上。

我们选择安装一个稳定版本，如4.1.6：

wget https://download.open-mpi.org/release/open-mpi/v4.1/openmpi-4.1.6.tar.gz tar -zxf openmpi-4.1.6.tar.gz cd openmpi-4.1.6

配置编译选项。--prefix指定安装路径，安装到/usr/local下方便系统级调用。

./configure --prefix=/usr/local/openmpi-4.1.6

然后进行编译和安装。-j参数指定并行编译的线程数，可以根据你的CPU核心数调整（如-j24），以加快速度。

make -j24 all sudo make install

安装完成后，同样需要将OpenMPI的二进制路径和库路径加入环境变量：

echo 'export PATH=/usr/local/openmpi-4.1.6/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/openmpi-4.1.6/lib:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc

验证OpenMPI安装是否成功：

mpirun --version

4. 编译、运行与解读hccl-test

一切准备就绪，现在进入验证环节。hccl-test是检验多卡通信链路是否通畅、性能是否达标的最直接工具。

4.1 定位源码与编译

hccl-test的源码位于CANN Toolkit的安装目录中：

cd /usr/local/Ascend/ascend-toolkit/latest/tools/hccl_test

查看目录结构，你会看到Makefile和源代码文件。编译前，需要设置两个关键的环境变量：

• INSTALL_DIR: 指向CANN Toolkit的安装根目录。
• MPI_HOME: 指向OpenMPI的安装目录。

使用make命令进行编译：

export INSTALL_DIR=/usr/local/Ascend/ascend-toolkit/latest make MPI_HOME=/usr/local/openmpi-4.1.6 ASCEND_DIR=${INSTALL_DIR}

编译过程如果顺利，会在当前目录下生成bin/all_reduce_test等可执行文件。如果遇到关于hccl.h头文件或libhccl.so库找不到的错误，请确认source setenv.sh已执行，并且ASCEND_DIR路径设置正确。

4.2 运行测试并理解输出

最激动人心的时刻到了：启动八卡测试。我们使用mpirun命令启动8个进程（-n 8），并通过--allow-run-as-root参数允许以root身份运行（如果你的当前用户是root）。每个进程会自动绑定到一张可用的NPU卡上。

mpirun --allow-run-as-root -n 8 ./bin/all_reduce_test -b 8K -e 64M -f 2 -d fp32 -o sum -p 8

让我拆解一下这个命令的参数：

• -b 8K: 测试的起始数据大小（最小字节数），这里是8KB。
• -e 64M: 测试的结束数据大小（最大字节数），这里是64MB。
• -f 2: 每次迭代数据大小翻倍的倍数（因子为2）。
• -d fp32: 测试数据类型为单精度浮点数（float32）。
• -o sum: 集合通信操作类型为求和（AllReduce操作）。
• -p 8: 使用的进程数（即NPU卡数），这里必须与-n参数一致。

运行后，终端会打印出一个表格，如下所示（数据为示例）：

the minbytes is 8192, maxbytes is 67108864, iters is 20, warmup_iters is 5 data_size(Bytes): | aveg_time(us): | alg_bandwidth(GB/s): | check_result: 8192 | 649.85 | 0.01261 | success 16384 | 515.75 | 0.03177 | success 32768 | 509.05 | 0.06437 | success 65536 | 505.00 | 0.12977 | success 131072 | 505.10 | 0.25950 | success 262144 | 501.70 | 0.52251 | success 524288 | 789.70 | 0.66391 | success 1048576 | 1454.90 | 0.72072 | success 2097152 | 3141.60 | 0.66754 | success 4194304 | 6769.45 | 0.61959 | success 8388608 | 13935.30 | 0.60197 | success 16777216 | 27919.90 | 0.60091 | success 33554432 | 55862.55 | 0.60066 | success 67108864 | 111805.80 | 0.60023 | success

4.3 性能数据深度分析

这个输出表格蕴含了丰富的信息，不仅仅是“success”这个结果。

1. 正确性验证：每一行的check_result都是success，这首先证明了从软件驱动、HCCL库到硬件链路的所有环节工作正常，多卡之间的数据通信和计算结果是正确的。这是环境可用的最基本保证。

2. 通信带宽分析：alg_bandwidth(GB/s)是算法带宽，它反映了在当前数据大小下，执行AllReduce操作的有效吞吐量。

   • 观察趋势：从8KB到64MB，带宽并非线性增长。在数据量较小时（如8KB-256KB），带宽较低，因为通信启动开销（Latency）占主导。随着数据量增大，带宽迅速上升并逐渐达到一个平台期（本例中大约在1MB到64MB之间，带宽稳定在~0.60 GB/s）。
   • 平台带宽值：这个稳定值可以近似看作你当前单机八卡环境下，AllReduce操作能达到的峰值通信带宽。它是评估分布式训练效率的关键指标之一。在后续的真实模型训练中，如果发现通信耗时占比过高，可以与此数值进行对比，判断是否存在配置问题或性能瓶颈。

3. 时延观察：aveg_time(us)是平均耗时。小数据包时的耗时直观反映了通信的时延。这个值对于参数同步频繁的同步训练模式（如AllReduce every step）影响很大。

为了更直观地对比不同数据规模下的性能，我们可以将关键指标整理如下：

提示：hccl-test还可以测试其他集合通信操作，如AllGather,Broadcast,ReduceScatter等。只需修改-o参数即可。在复杂的模型并行或流水线并行策略中，这些操作的性能同样重要。

5. 进阶配置与故障排查指南

环境跑通只是第一步，要让它在长期高负荷训练中稳定工作，还需要一些进阶配置和知道如何排查问题。

5.1 环境变量调优

除了基本的setenv.sh，一些环境变量可以微调系统行为：

• HCCL_WHITELIST_DISABLE=1: 在某些版本中，禁用设备白名单检查，可能解决一些卡无法识别的问题。
• HCCL_ALGO=ring: 指定集合通信算法为环算法，这是一个稳定通用的选择。
• ASCEND_SLOG_PRINT_TO_STDOUT=0和ASCEND_GLOBAL_LOG_LEVEL=3: 控制日志输出级别，在调试时可以设为更详细（如level=1），生产环境设为警告或错误级别以减少I/O开销。

可以将这些变量添加到你的训练启动脚本或~/.bashrc中。

5.2 常见故障与解决方案

1. npu-smi info看不到卡或卡状态异常

   • 检查驱动: 运行dmesg | grep npu查看内核日志是否有驱动加载错误。
   • 检查权限: 确认/dev/davinci*设备文件的权限，确保HwHiAiUser有读写权限。ls -l /dev/davinci*
   • 重启服务: 尝试重启昇腾设备管理服务sudo systemctl restart ascend_device.

2. hccl-test编译失败，提示找不到头文件或库

   • 确认source /usr/local/Ascend/ascend-toolkit/latest/bin/setenv.sh已执行。
   • 检查ASCEND_HOME或ASCEND_DIR环境变量是否指向正确的CANN目录。
   • 手动指定库路径：export LD_LIBRARY_PATH=/usr/local/Ascend/ascend-toolkit/latest/lib64:$LD_LIBRARY_PATH

3. mpirun运行时报错，如ORTE was unable to start...

   • 这通常是OpenMPI环境问题。确保OpenMPI的bin和lib路径已在环境变量PATH和LD_LIBRARY_PATH中。
   • 尝试使用--prefix明确指定OpenMPI路径：mpirun --prefix /usr/local/openmpi-4.1.6 ...

4. hccl-test运行结果中check_result为failed

   • 这通常是严重的通信错误。首先检查是否所有卡都被其他进程独占占用。
   • 尝试减少进程数（如-n 4）测试，排除是否是某张特定卡的问题。
   • 检查服务器内部NPU卡的硬件连接（如RoCE网卡、线缆）是否牢固。

5.3 性能基线建立与监控

在完成首次成功的hccl-test后，建议将输出结果保存下来，作为该服务器的性能基线。以后任何时候怀疑系统性能下降（如温度过高导致降频、线缆松动等），都可以重新运行相同的测试命令，对比带宽和时延数据，快速定位是否是硬件或底层通信环境出了问题。

此外，结合npu-smi命令进行长期监控也是个好习惯。可以写一个简单的脚本，定期记录每张卡的温度、功耗和内存利用率，这对于预防因过热导致的训练中断至关重要。

#!/bin/bash while true; do date >> npu_monitor.log npu-smi info >> npu_monitor.log echo "-------------------" >> npu_monitor.log sleep 60 # 每分钟记录一次 done

整个环境搭建和验证的过程，就像是在为一场大型交响乐调试每一件乐器。当hccl-test的八张卡协同奏出“success”的乐章，并且带宽曲线稳定在预期的高位时，那种成就感是实实在在的。这意味着你拥有了一块坚实、可靠的计算画布，接下来，无论是预训练百亿参数的大模型，还是进行复杂的多模态任务训练，这套环境都将是你最得力的伙伴。记住，好的开始是成功的一半，在深度学习的世界里，一个稳健的基础设施就是那最重要的一半。如果在后续的模型训练中遇到任何与硬件或通信相关的问题，不妨再回到这里，用hccl-test这把尺子，先量一量基础的通信性能是否依旧如初。