海光DCU在AI服务器上的驱动安装与验证步骤
海光DCU是国产GPGPU加速卡,在AI服务器上使用前必须先完成驱动和软件栈配置,否则系统只能看到一块PCIe设备,无法进行任何计算。
本文按“系统检查—驱动安装—运行时配置—框架验证”的顺序,讲清每一步该做什么、做到什么程度算成功,以及出错时先查哪里。
开始之前要确认的三件事
装驱动之前先把环境摸清楚,能省掉后面大量返工。
- 确认操作系统版本:海光DCU的驱动和软件栈对内核版本有明确要求,主流支持的是特定版本的CentOS、Ubuntu或麒麟等信创系统。用
cat /etc/os-release和uname -r记录系统版本与内核版本,再对照厂商发布的兼容列表,不要凭经验直接装。 - 确认卡已被系统识别:执行
lspci | grep -i hyd或查看厂商文档给出的设备标识,能看到对应设备条目说明硬件连接正常。如果这里就是空的,先查插槽、供电和BIOS里的Above 4G Decoding等选项,不要急着装驱动。 - 准备厂商软件包:驱动、运行时库(类似ROCm的软件栈)和容器工具通常需要从海光官方渠道获取对应版本的安装包。版本要匹配,驱动与运行时库版本不一致是后面很多报错的根源。
驱动与运行时库的安装顺序
海光DCU的软件栈一般分两层:内核态驱动负责让系统识别并管理设备,用户态运行时库负责给上层框架提供计算接口。
顺序不能颠倒。
安装内核驱动时,先确认已安装对应版本的内核头文件(如 kernel-devel 或 linux-headers),否则编译会失败。
以常见的rpm包为例,进入安装包目录后执行:
sudo rpm -ivh dcu-driver-*.rpm
deb系系统则用 sudo dpkg -i dcu-driver-*.deb。
安装完成后加载模块并检查:
lsmod | grep -i hyd
能看到相关模块说明驱动已加载。
如果模块没出现,用 dmesg | tail -50 查看内核日志里的报错,常见原因是内核版本不匹配或Secure Boot未关闭导致模块签名被拒。
驱动正常后再安装运行时库,同样按官方包执行安装。
运行时库装完后需要把相关路径加入环境变量,通常在 /etc/profile.d/ 下创建脚本或在用户profile中追加,把库路径和可执行文件路径写进去,然后 source 生效。
这一步漏掉的话,后面框架会报找不到设备或找不到库。
用hy-smi确认设备状态
海光提供的 hy-smi 工具相当于NVIDIA的 nvidia-smi,是判断配置是否成功的第一道关卡。
安装完运行时库后执行:
hy-smi
正常情况下会列出所有DCU卡、显存占用、温度、功耗和驱动版本。
重点看三项:卡数量是否与物理安装一致、驱动版本是否与安装包对应、有没有异常状态提示。
如果 hy-smi 提示找不到设备或命令不存在,
按这个顺序排查:
确认运行时库路径已加入 PATH、
确认驱动模块已加载、
确认当前用户有访问设备的权限(设备节点通常在 /dev 下,
权限问题可用 ls -l 查看)。
容器环境下让DCU可用
现在多数AI任务跑在容器里,需要把DCU设备透传进容器。
海光一般提供对应的容器运行时工具,安装后通过指定参数把设备挂载给容器。
启动容器时使用厂商文档给出的设备挂载参数,并在容器内再次执行 hy-smi 验证。
容器内能看到卡,才说明透传配置正确。
这一步最容易出的问题是宿主机驱动版本与容器内运行时库版本不一致。
原则是容器内运行时版本不高于宿主机驱动支持的版本,否则会出现初始化失败。
框架层面的可用性验证
设备能被识别,不等于框架能正常调用。
用厂商适配过的深度学习框架版本跑一个最小示例,比如打印设备信息、做一次简单的矩阵运算或张量加法,确认返回结果正确。
如果框架报“找不到可用设备”或初始化报错,先核对框架版本是否与运行时库匹配,再看环境变量是否完整。
验证通过的标准是:hy-smi 能稳定列出设备,最小计算示例能跑出正确结果,容器内外行为一致。
三者都满足,才算完成基础配置。
几个容易踩的坑
- Secure Boot没关:导致内核模块无法加载,表现为驱动装了但设备不工作。
- 驱动与运行时版本混搭:随便拿不同版本的包组合安装,运行时报错难定位,务必成套使用。
- 环境变量只在一个终端生效:写进profile文件而不是临时export,避免重启或新会话后失效。
- 容器内直接用宿主机的库:路径挂载混乱导致版本冲突,按官方推荐方式透传设备即可。
配置完成后建议记录当前驱动、运行时库和框架的具体版本,后续升级或排错时这是最直接的对照信息。