企业官网建设流程全解析

前阵子单位一台麒麟服务器要跑AI推理任务，新采购的机器配了RTX 5080。当时心想，显卡驱动不是装上就行的事吗，结果真正操作起来才发现，Linux服务器装N卡驱动跟Windows完全是两个世界，尤其是在麒麟这种有自己软件仓库的发行版上。从最初的识别不到显卡，到编译报错、模块加载失败，前前后后折腾了两天才算稳定跑通CUDA。这篇文章把整个过程完整记录下来，包括怎么识别系统分支、怎么准备离线依赖、具体的安装命令，以及我踩过的几个比较隐蔽的坑，希望能给同样在麒麟服务器上装NVIDIA 5080显卡驱动的朋友提供一份可以直接照做的参考。

1. 方案选型：为什么必须用570+驱动，以及runfile为什么最稳

1.1 先分清你的麒麟是哪个“派系”

麒麟服务器操作系统V10这套东西，覆盖了好几种底子，不同SP版本之间差别非常大。有些版本底层是RHEL系，包管理用yum/dnf；有些版本底层是Debian/Ubuntu系，包管理用apt。这个差别如果一开始没搞清楚，后面的所有操作都会跑偏。

判断方法很简单，两行命令的事：

cat /etc/os-release cat /etc/kylin-release

重点看ID和VERSION_ID这两行。如果系统里同时存在/etc/redhat-release或者ID字段带redhat、centos、anolis、openeuler字样，那基本就是RHEL系。如果出现ubuntu或debian字样，则是apt系。我见过有人拿着基于Ubuntu的麒麟V10，非要硬套yum命令装依赖，结果卡在源配置上几个小时，最后换了思路才跑通。

这个区分为什么这么关键？因为NVIDIA驱动的runfile安装包在编译内核模块时，需要找内核头文件和编译工具链，不同派系对应不同的依赖包名称，搞错一个字母都装不上。另外，麒麟系统为了保持自身稳定性，软件仓库里的包版本往往比上游发行版保守，尤其显卡驱动这种跟内核强绑定的包，仓库里大概率是旧版本，这也是后文说为什么不要轻易用系统源装驱动的原因。

1.2 RTX 5080对驱动版本有硬性要求

RTX 5080用的是Blackwell架构，GPU代号GB203，流处理器对应的计算能力是sm_120。这对Linux驱动提出了一个硬性要求：驱动版本必须达到570系列以上。

一开始我是直接从麒麟软件源里搜索nvidia，结果把仓库里现有的rpm包装上去，重启后执行nvidia-smi，系统直接报“No devices were found”。查了一圈才发现，麒麟仓库里的NVIDIA驱动停留在535/545这个级别，这些是为Ada Lovelace架构也就是RTX 40系准备的，根本不认Blackwell的新卡。显卡插在PCIe槽上，系统NVIDIA驱动装好了，但驱动不认识显卡硬件，等于白装。后来查NVIDIA官方Release Note，Blackwell桌面显卡从570.86.16才开始有正式支持，CUDA Toolkit版本要求12.8及以上。所以驱动选型的标准非常明确：版本号必须570+，且优先选择当时官方发布的最新稳定版。

这里有一个很容易被忽略的点：即使你用的不是5080，而是3090或者4090，驱动也不一定可以通用。每个大版本驱动有自己支持的GPU列表，选U前顺手看一下Release Notes里的“Supported Products”列表，别拿570驱动去装老卡，也别拿535去装5080，省得来回折腾。

1.3 三种常见安装方式的取舍

NVIDIA驱动在Linux上有几种装法，我实际试用下来，总结如下：

• 系统源安装（yum/dnf/apt）：优点是简单，但麒麟源里的NVIDIA包版本通常很旧，大概率只支持到RTX 30系或40系。对5080来说，这条路基本走不通。
• CUDA Toolkit捆绑安装：NVIDIA官网的CUDA安装包会附带一个匹配的驱动。这种方式适合确定要装CUDA的场景，但要注意安装包里的驱动版本不一定是最新的，且一次装完两个大件，出问题的时候不好定位。
• 官网runfile安装：这种方式是我最终采用的。runfile是NVIDIA官方提供的独立驱动安装包，体积一百多MB，包含了完整的驱动程序和安装脚本，不依赖特定发行版仓库，也不污染系统包管理器，安装、卸载都清晰可控。

最终的结论是：服务器内网部署、要支持新卡，runfile是最稳妥、最可控的方案。下面整个流程也是围绕runfile展开的。

2. 动手前的基础准备：依赖、内核、nouveau一次搞定

2.1 安装编译依赖与内核头文件

runfile安装驱动时会在本地编译一个内核模块，这个过程需要gcc、make和当前内核对应的开发包。很多人在这一步就栽了，最常见的报错是“Unable to find the kernel source tree”，本质就是内核开发包没装或版本不匹配。

RHEL系麒麟执行：

yum install -y gcc make kernel-devel-$(uname -r) kernel-headers-$(uname -r) elfutils-libelf-devel libglvnd-devel

基于Ubuntu的麒麟执行：

apt install -y build-essential linux-headers-$(uname -r) pkg-config libglvnd-dev

这里有几个细节需要特别注意。第一，uname -r输出的内核版本号必须和kernel-devel的版本完全一致，比如当前内核是4.19.90-25.10.v2101.ky10.x86_64，那kernel-devel也必须是同版本。第二，如果系统里装了多个内核，一定要确认当前启动的是哪一个，别给旧内核装了驱动，重启进新内核还是识别不了。第三，编译工具链的版本不要太新也不要太旧，麒麟V10自带的gcc一般是7.x或8.x，编译570驱动完全够用，没必要手动升级gcc。

如果服务器在内网，yum源又是离线的，这部分依赖包可以通过挂载麒麟ISO镜像做本地源来解决，或者在能联网的机器上用yum install --downloadonly --downloaddir=/tmp/deps把rpm包全部下载下来，再拷贝到服务器上执行本地安装。注意下载依赖的机器架构必须是x86_64，否则包不通用。

2.2 禁用nouveau：不然后面一定报错

nouveau是Linux内核自带的NVIDIA开源驱动，虽然性能不行，但确实存在。NVIDIA官方驱动安装脚本在检测到nouveau在运行时，会直接拒绝继续安装。就算用--no-nouveau-check强行跳过，装完也容易出现花屏、黑屏、系统卡死这类问题。所以禁用nouveau是必须做的一步。

创建黑名单文件：

cat > /etc/modprobe.d/blacklist-nouveau.conf << EOF blacklist nouveau options nouveau modeset=0 EOF

然后重建initramfs。RHEL系麒麟用：

dracut --force

基于Ubuntu的麒麟用：

update-initramfs -u

执行完后必须重启，重启后验证一下：

lsmod | grep nouveau

如果输出为空，说明nouveau已经彻底禁用了，可以继续下一步。如果还有输出，大概率是initramfs没有重建成功，或者系统里还有其他地方引用了nouveau模块，需要检查/etc/modprobe.d/目录下是不是有多个配置文件冲突。

2.3 清理旧驱动和内核模块

如果这台服务器之前装过NVIDIA驱动，不管是曾经失败过还是成功过，都要先清理干净，否则新旧驱动混在一起，会出现“NVML Driver/library version mismatch”这种让人摸不着头脑的报错。

一种典型场景是之前用发行版源装过驱动，可以用包管理器卸载：

yum remove nvidia* # RHEL系 apt remove nvidia* # Debian系

如果之前是runfile装的，使用自带的卸载脚本：

nvidia-uninstall

卸载之后，再去检查一下内核模块目录里有没有残留的nvidia相关文件：

ls /lib/modules/$(uname -r)/kernel/drivers/video/

看到nvidia*.ko就把它们删掉。这个步骤很多人会忽略，但恰恰是最容易留坑的地方。老模块残留在initramfs里，新驱动装完重启，内核可能会先加载旧模块，导致新工具链和旧内核模块接口对不上，报错信息五花八门，排查起来非常浪费时间。

2.4 内网环境下怎么凑齐离线安装包

麒麟服务器部署在内网是常态，依赖包和驱动文件都得提前备好。我的经验是准备两样东西：

一是编译依赖的rpm包。在有外网的机器上执行：

yum install --downloadonly --downloaddir=/tmp/deps gcc make kernel-devel-$(uname -r) kernel-headers-$(uname -r) elfutils-libelf-devel libglvnd-devel

然后把/tmp/deps整个目录拷贝到服务器，服务器上执行：

yum localinstall /tmp/deps/*.rpm

最后取消这个本地rpm包的缓存，避免污染系统源。

二是NVIDIA驱动runfile本身。这个文件是完整的离线包，不需要在线下载其他内容。我自己习惯在内网机器上建一个/opt/nvidia目录，专门放驱动和之后要用的CUDA Toolkit安装包，方便统一管理、多台机器复用。同时建议把驱动版本号写进文件名，比如NVIDIA-Linux-x86_64-570.124.06.run，时间一长你就知道哪个文件对应哪个版本，不然隔几个月再回来看，一堆run文件完全分不清。

另一个重要提醒是装完驱动后，不要急着升级内核。runfile驱动默认不会自动注册到DKMS，每次内核升级后都必须手动重新编译安装。如果确实需要升级内核，建议先把驱动卸载、升级内核、再重装驱动，顺序反了模块就废了。

3. 驱动安装全流程实操记录

3.1 下载驱动并校验文件完整性

浏览器直接访问NVIDIA官网驱动下载页面，选择Linux、x86_64、生产分支，会得到一个类似NVIDIA-Linux-x86_64-570.124.06.run的文件。下载后建议做一次MD5校验，防止传输过程中文件损坏：

md5sum NVIDIA-Linux-x86_64-570.124.06.run

从官网页面复制一下官方MD5值，能对上再继续。这一步看似多余，实际很有必要，我从网盘下载过一份损坏的驱动，安装到一半突然报“corrupted installer, cannot continue”，又重新传了一遍才解决。在跨网络传输大文件时，文件完整性校验就是省时间的关键。

3.2 切换运行级别并执行安装

如果服务器上有图形界面，必须先切到纯命令行模式，否则安装脚本检测到X Server正在运行，会直接报“The X server is running”。切换命令统一用：

systemctl isolate multi-user.target

或者传统一点用init 3。切完之后按Ctrl+Alt+F2进到字符终端，确认没有图形进程再用。

接下来执行安装：

chmod +x NVIDIA-Linux-x86_64-570.124.06.run sudo sh NVIDIA-Linux-x86_64-570.124.06.run --no-opengl-files --dkms

这里我用了两个关键参数，它们的作用值得说明一下。--no-opengl-files的意思是不要安装OpenGL相关的库文件。在纯计算、AI训练推理、无头服务器场景下，这个参数能避免NVIDIA的OpenGL库和系统自带的Mesa/OpenGL实现产生冲突，减少桌面环境出问题的概率。但如果你的服务器将来要做GPU渲染、硬件编解码或远程虚拟桌面，那OpenGL库还是需要的，这时候就不要加这个参数。--dkms是把内核模块注册到DKMS，以后内核升级时DKMS会自动帮助重新编译驱动模块，对服务器长期运维来说是刚需。不过使用--dkms前需要系统已安装dkms包，麒麟仓库里一般有，先执行yum install dkms或者apt install dkms装上即可。

安装脚本运行过程中会问几个问题，比如是否接受许可协议、是否安装32位兼容库等。接受协议、选Yes即可。整个编译过程大概五到十分钟，取决于CPU性能。看到“Installation done”说明驱动已经装好。我很建议这一步骤结束后仍然重启一次机器，因为虽然理论上装完直接加载模块也能用，但让新模块彻底替换旧环境最稳。我第一次装完图省事不重启，直接跑nvidia-smi发现3D加速没有真正生效，重启后一切正常。

3.3 验证驱动与CUDA可用性

重启后执行：

nvidia-smi

正常会看到类似这样的输出：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 570.124.06 Driver Version: 570.124.06 CUDA Version: 12.8 | |-------------------------------+----------------------+----------------------+ | 0 NVIDIA GeForce RTX 5080 ... | +-----------------------------------------------------------------------------+

看到显卡型号和驱动版本都正确列出来，说明驱动安装成功了。这里需要强调一个很多人都会误解的点：nvidia-smi输出的“CUDA Version”表示的是当前驱动支持的最高CUDA运行时版本，并不代表你已经安装了CUDA Toolkit。要跑CUDA程序，还需要单独安装CUDA Toolkit，版本必须低于或等于驱动支持的版本。对于5080，最低要求是CUDA 12.8，如果你要跑的框架（比如PyTorch）需要更高版本，同样要确认驱动是否支持。

4. 安装中最容易翻车的问题与排查实录

4.1 “kernel source tree not found”基本是依赖没对

这个报错算是runfile安装中最常见的一道坎。完整信息一般是这样：

The kernel build path is /lib/modules/4.19.90-25.10.v2101.ky10.x86_64/build but this directory does not exist

原因很明确：内核开发包没装，或者装错了版本。解决路径如下：

uname -r yum list installed | grep kernel-devel

如果kernel-devel没装上，用2.1节的命令补装。如果装了但版本跟uname -r对不上，那就重新安装对应版本：

yum reinstall kernel-devel-$(uname -r)

还有一种情况是/lib/modules/$(uname -r)/build这个软链接断了，需要手动重建：

ln -s /usr/src/kernels/$(uname -r) /lib/modules/$(uname -r)/build

这个报错排查起来不难，但很耗耐心，尤其是麒麟系统自带多个内核版本的时候。建议固定一个内核启动，用grub2-set-default 0指定默认启动项，避免驱动和内核反复失配。

4.2 nvidia-smi报NVML mismatch：新旧模块打架

症状是执行nvidia-smi时报错：

NVML Driver/library version mismatch

这几乎都是因为没有卸载干净旧驱动。旧NVIDIA内核模块还挂在内存里，新工具链已加载新模块，两者接口对不上，就会出这个提示。最快的处理办法是重启，让系统干净地加载新模块。如果重启后依旧报错，需要重建initramfs：

dracut --force

或者：

update-initramfs -u

再做一次新旧模块的彻底替换。这个问题在升级驱动时特别容易出现，所以升级前一定要把旧驱动完全清理干净，别想着直接覆盖安装。

4.3 Secure Boot让模块加载失败

新版服务器主板默认开启Secure Boot时，NVIDIA内核模块因为没有签名会无法加载。症状是nvidia-smi报告找不设备，dmesg里能看到类似permission denied的错误日志。

解决办法有两个。最省事的是进BIOS关闭Secure Boot。很多服务器的BMC远程控制台就能操作，不用跑到机房按电源键。另一种是用mokutil对驱动模块签名，这个方案非常麻烦，涉及密钥生成、导入、重启确认等多个环节，在内网环境性价比极低，除非有硬性合规要求，否则直接关Secure Boot就好。这个操作只影响启动时的签名校验，不影响系统安全性和业务运行。

4.4 双显卡环境下的驱动冲突与处理

服务器上如果有两块不同型号的N卡，或者N卡加Intel集显的组合，装驱动也容易出问题。最常见的现象是集显输出画面的机器，N卡驱动装完后显示器没输出。这不一定代表驱动装坏了，很多时候是因为N卡没有连接显示器，系统图形输出完全由集显承担，N卡被当作纯计算卡使用，这是正常状态。用nvidia-smi -L确认GPU是否被系统识别，只要能看到显卡，驱动就是正常的。

多卡场景还要注意电源供电。5080这个级别功耗不低，服务器电源如果带不动，或者PCIe供电线没插好，驱动装完GPU也会显示在PCIe列表里，但跑计算直接掉卡或性能大降。这时候先查BMC日志看功耗和传感器，别急着重装驱动。

对于N卡+A卡这样的跨厂商异构环境，两个驱动可以共存，但要注意kernel module的加载顺序。实际踩坑下来，建议先禁用nouveau和amdgpu的自动加载，再用rungile安装各自的官方驱动，最后重启。这样做冲突概率最低。

4.5 常见错误速查表

这里的每一类问题我在实际安装过程中几乎都遇到过，尤其是“No devices were found”这个提示，背后原因最多，一定要从驱动版本、nouveau状态、硬件供电三个方向分别排查，不要再重装无用功。

这套流程后面我又在另外几台机器上验证过，只要把系统分支认准、依赖备齐、旧驱动清干净，RTX 5080在麒麟服务器上装驱动其实是比较流畅的。最后再说两个小技巧：如果你之后要装CUDA Toolkit，一定先把驱动装好，再去装CUDA，顺序反了CUDA很可能会把驱动覆盖成旧版本，导致显卡再次失联；另外，NVIDIA的runfile支持--update参数，紧急情况下可以只更新驱动而不动CUDA，这在排查环境问题时很实用。记住这两点，能少走不少弯路。