企业官网建设流程全解析

先说一个我最近实际遇到的场景。某台AlmaLinux 9.7的工作站，插上Blackwell架构的PRO 6000专业卡之后，开机直接黑屏，或者进系统后nvidia-smi报无法和NVIDIA驱动通信。这不是个例——Blackwell架构对驱动版本、GSP固件、CUDA版本的依赖，和以前的Turing、Ampere、Ada完全不同，照搬老经验的人大概率要折腾一下午。

这篇文章就是一条完整的部署链路：从AlmaLinux 9.7的基线检查、关闭nouveau、处理Secure Boot，到runfile手动安装驱动、CUDA环境配置、持久化设置，再到重启之后的验证与排错。我按实际动手顺序来写，该先做的检查、该避开的坑、每一条命令为什么这么用，都会拆开讲。如果你正好要让Blackwell架构专业卡在RHEL系发行版上老老实实跑起来，跟着走能省下很多时间。

1. Blackwell架构的时代差异与AlmaLinux环境基线

1.1 为什么PRO 6000不能照搬老显卡驱动思路

先说一个认知层面的坑。以前装NVIDIA驱动，网上最常见的就是三步教程：禁用nouveau、下载.run文件、回车安装，然后重启。这套流程在Turing、Ampere时代确实没问题，但到了Blackwell架构，事情变得不一样了。

Blackwell架构的PRO 6000有几个直接影响安装的特征。第一，新版驱动默认启用GSP固件，显卡内部的管理处理器接管了大量传统上由内核模块负责的调度工作；第二，老驱动分支（比如R470、R525）完全没有对应硬件支持，强行装老驱动，编译阶段就可能报unknown chip；第三，它对系统工具链和运行库的版本要求明显高了一个台阶。换句话说，显卡很新，系统准备必须跟得上，不能再抱着"反正都是NVIDIA驱动，装上就行"的想法。

另一个容易被忽略的点是：AlmaLinux 9.7这类RHEL系发行版，内核相对保守，默认组件里不会为最新硬件做完整适配。你不能指望装完系统再装个驱动就能直接用，必须手动把内核构建路径、模块签名、运行库依赖全部捋顺。整体框架还是"下载驱动—编译—安装"没错，但框架里的每一步都有了新细节。

1.2 装机前用三条命令确认硬件与系统状态

动手之前，我习惯先确认三件事：卡有没有被识别、当前内核是什么、系统是哪个版本。三条命令就能搞定。

lspci | grep -i nvidia uname -r cat /etc/redhat-release

lspci | grep -i nvidia用来确认系统能不能看到这块卡。如果输出里没有NVIDIA字样，先别急着装驱动，回头查PCIe插槽有没有插紧、供电线是不是没接好、BIOS里PCIe设备枚举是否正常。有些主板默认关闭了部分PCIe槽位，或者CSM模式下手动指定了显卡输出，这些都会导致系统层面完全看不到卡。

uname -r给出当前内核版本，比如5.14.0-503.el9.x86_64。这个版本号在后面找kernel-devel的时候要精确到每一个字符，版本对不上，编译阶段就会报错。

cat /etc/redhat-release用来确认系统版本。AlmaLinux 9.7本质上是RHEL 9系的二进制兼容发行版，所以能用RHEL 9的软件源，也能用EPEL 9。这一点后续加CUDA仓库时会反复用到。

接着还要查旧驱动痕迹：

lsmod | grep nvidia rpm -qa | grep -i nvidia dkms status

如果有输出，说明机器上可能留过旧驱动或旧模块。这一步很关键——旧的nvidia模块和新的Blackwell驱动同时存在时，开机加载的可能是旧模块，随后出现无法初始化显卡的报错，症状非常隐蔽。我建议只要有输出就一律清理干净，不要幻想"覆盖安装"能解决一切。

1.3 Secure Boot：最容易忽视的第一道卡点

AlmaLinux 9.7安装时默认是UEFI模式，而UEFI模式下很多镜像默认开启了Secure Boot。Secure Boot的本意是防止引导加载器和内核模块被篡改，但它带来的直接后果是：NVIDIA runfile安装器现场编译出来的nvidia.ko没有经过签名，内核拒绝加载。

判断方式就一条命令：

mokutil --sb-state

输出SecureBoot enabled就得处理，输出disabled则直接跳过这一小节。

处理方式取决于使用场景。个人工作站、开发测试机，直接进BIOS关闭Secure Boot是最省事的路。产线环境如果必须开Secure Boot，就走MOK签名流程：先生成密钥，再给nvidia.ko签名，然后用mokutil --import导入公钥，重启后进入MOK管理界面确认。这个流程本身不复杂，但后续每次内核升级、驱动升级都要重新签一次，工作量会一直跟着你。

我的实际建议是：首次部署先关掉Secure Boot把驱动跑通，等整个环境稳定之后再考虑补安全签名。很多人一上来就搞MOK，结果驱动还没跑明白，先被签名流程整崩溃了。

提示：如果你是把旧版AlmaLinux升级到9.7再装驱动，还要注意BIOS里的安全启动状态可能和系统判断的不一致。一切以mokutil --sb-state的输出为准，不要只看BIOS界面。

2. 系统准备：nouveau、依赖、initramfs一次搞定

2.1 开发工具链与kernel-devel的版本匹配

NVIDIA runfile在安装时不是把编好的内核模块直接拷进去，而是现场编译。这意味着目标机上必须有完整的编译工具链，还有和当前内核精确匹配的kernel-devel。

我见过最多的失败场景，不是缺gcc也不是缺make，而是kernel-devel版本和内核版本对不上。比如系统内核升级到了5.14.0-503.el9，但kernel-devel还停留在旧版本，编译的时候头文件路径不对，安装器就会报一个含糊的Unable to find the kernel source tree。

先把两个包安装到位：

dnf groupinstall "Development Tools" dnf install kernel-devel kernel-headers dkms

装完立刻核验：

rpm -q kernel-devel uname -r

两组输出必须完全一致。如果不一致，要么升级kernel-devel到当前内核版本，要么重启到kernel-devel对应的新内核。这一步不校准，后面全部白搭。

还有两个容易被忽略的细节。如果计划用EPEL里的辅助工具，先执行dnf install epel-release。如果计划装CUDA，注意CUDA对gcc版本有硬性要求，老版本gcc编译新CUDA会报unsupported GNU version。先装好标准gcc和gcc-c++，CUDA安装器后续会自己校验。

2.2 nouveau的三种屏蔽手段与正确组合

nouveau是内核自带的开源NVIDIA驱动，它对Blackwell架构支持极差，而且在某些内核上加载时会占用设备，导致闭源驱动无法绑定显卡。所以屏蔽nouveau是必做项。

官方推荐的做法是写modprobe配置：

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

第二种方式是通过grubby追加内核启动参数：

grubby --update-kernel=ALL --args="rd.driver.blacklist=nouveau"

grubby是RHEL系管理引导参数的标准工具，比手动编辑grub.cfg安全得多。它能一次性给所有内核条目追加参数，不用自己逐项改。

第三种是朴素但有效的黑名单强化：

echo "alias nouveau off" >> /etc/modprobe.d/blacklist-nouveau.conf

实际部署经验告诉我：不要只选一种，把modprobe黑名单和grubby启动参数同时做好，才是最稳的组合。原因在于initramfs阶段和启动后的模块加载阶段是两个不同的模块解析入口，只拦一个，另一个仍可能把nouveau拉起来。

2.3 重建initramfs与切换命令行target

修改了模块黑名单之后，旧initramfs里可能还存着nouveau模块。如果不重新生成initramfs，重启时内核会从initramfs里恢复nouveau，你在modprobe.d写的黑名单直接失效。

建议重建之前先备份：

cp -a /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

多说一句备份的原因。dracut重建过程中，如果某些驱动配置有误，生成的initramfs可能损坏，导致机器无法引导。有备份在，顶多引导时手动选旧initramfs，不至于重装系统。

然后切换默认target：

systemctl set-default multi-user.target

这个动作的意思是下次开机直接进入多用户命令行模式，不启动图形界面。原因很实际：图形显示管理器（gdm、sddm）会在驱动模块加载之前尝试初始化GPU，而新驱动还没装好、nouveau又被屏蔽的阶段，图形界面极易崩溃或黑屏。先把图形界面放到一边，等驱动彻底跑通了再决定切不切回去。

准备工作做完，重启一次。重启之后别急着装驱动，先确认没有nouveau残留：

lsmod | grep nouveau

如果还能看到nouveau，说明黑名单没生效，回到2.2重新检查，不要带着nouveau往下走。

3. runfile安装驱动：版本选择、参数含义与GSP固件

3.1 驱动分支选择的底层逻辑

标题里的PRO 6000是Blackwell架构显卡，它需要的驱动分支和旧卡完全不同。原因不复杂：新架构的特性（GSP固件、新的显存管理、新的链路拓扑）都需要对应驱动提供支持，驱动版本太老，硬件特性识别不了，零性能可谈。

选择版本的逻辑应该是：在稳定分支里找你需要的功能是否齐全，再看它和CUDA的匹配关系。专业卡装在生产力机器上，稳定压倒一切，不要看到BETA版就图新鲜往下装。

对Blackwell架构的PRO 6000，建议选570系列或更新的稳定分支。下载到的文件一般是这种格式：

NVIDIA-Linux-x86_64-570.xxx.xx.run

下载完先校验SHA256（NVIDIA官网会给出哈希值），再给执行权限。这一步很多教程不会提，但企业级安装环境里，下载源内容被替换的事确实发生过。多花几秒钟，值得。

3.2 安装命令逐项解读与预期输出

纯命令行环境最稳妥的执行方式：

chmod +x NVIDIA-Linux-x86_64-570.xxx.xx.run ./NVIDIA-Linux-x86_64-570.xxx.xx.run --no-questions --ui=none

--no-questions表示全程不交互，遇到询问一律采用默认值；--ui=none表示不用图形界面安装器，这在无显示器的服务器SSH会话里是必须的。两个参数凑齐，安装器就能在纯文本环境一路跑完。

有人习惯加--no-opengl-files，我建议谨慎。这个参数会把OpenGL相关库排除掉，适合桌面环境已存在完整OpenGL栈且需要严格维护的场景；但在RHEL系服务器上，默认图形栈本来就精简，盲目排除OpenGL文件反而可能导致后续渲染相关功能缺失。我倾向不加，除非你明确知道自己在干什么。

安装器会自动检测X图形服务是否在运行。如果检测到，会要求你先停掉它。我们上一章把默认target切到multi-user，就是为了避免这一步被打断。如果它仍然检测到X服务，可以手动执行：

systemctl isolate multi-user.target

然后重新跑安装器。

编译nvidia.ko的过程会持续几秒到几分钟。看到nvidia.ko installed这样的输出，说明编译和模块安装都成功了。如果这一步报错，优先怀疑kernel-devel版本不一致或编译依赖缺失，回到2.1解决，不要重复跑安装器硬碰硬。

3.3 GSP固件：默认开启还是关闭

这是新架构驱动里值得单独说的话题。GSP，GPU System Processor，是显卡内部的一个独立管理处理器，从某几代架构开始成为默认设备管理主体，Blackwell全面采用这一设计。

默认情况下，新驱动会自动启用GSP固件，把显存管理、上下文切换、虚拟化辅助都交给GSP处理。绝大多数专业场景下，GSP开启是正确的：内存管理更干净、多进程隔离更好、虚拟化功能更完整。

只有两类情况才考虑关掉GSP：

• 做特殊的大规模虚拟化透传实验，且遇到了与GSP相关的设备复位问题
• 对GPU调用延迟做极端测试，希望尽量绕开GSP层

关闭方式：

echo "options nvidia NVreg_EnableGSP=0" > /etc/modprobe.d/nvidia-gsp.conf

之后重建initramfs并重启。

我不建议普通用户碰这个开关。默认开着就好，GSP不是性能瓶颈，很多质疑来自早期固件版本的问题，新固件已经改善很多。

3.4 安装后的文件与模块自检

装完先别急着重启，检查几个关键产物：

ls /usr/bin/nvidia-smi ls /usr/lib64/libnvidia-ml.so* ls /usr/lib/modules/$(uname -r)/nvidia.ko 2>/dev/null || echo "check dkms" dkms status

如果驱动走DKMS安装的，模块文件在/var/lib/dkms/nvidia/下，不直接放在内核模块目录，这是正常现象。重点是确认nvidia-smi存在，以及DKMS状态正常。

这里我想强调一个常见的误判点：很多人装完驱动马上执行nvidia-smi，发现报错就怀疑安装失败。实际上，驱动模块要等新内核引导完成后才会加载新版本，旧内核里仍然是旧状态。所以不用慌，直接重启，重启后再验证。"重启前误判"这个坑，我见过太多人踩。

4. CUDA环境与显卡持久化配置

4.1 dnf方式安装CUDA 12.x

驱动装完之后，系统只是能识别和使用显卡了，真正让PRO 6000发挥计算价值的是CUDA计算栈。Blackwell架构对CUDA版本有下限要求，标题这个场景建议直接上CUDA 12.8及以上版本。

RHEL系装CUDA有两种主流方式：runfile和dnf仓库。服务器上我优先推荐dnf仓库，理由很简单——依赖管理交给系统，升级、卸载都干净，不会留一堆手动装的文件。

先加CUDA仓库：

dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo dnf clean all dnf install cuda-toolkit-12-8

仓库地址里的rhel9对AlmaLinux 9同样适用，因为AlmaLinux就是RHEL 9的二进制兼容发行版。

安装完成后，CUDA工具链在/usr/local/cuda-12.8，需要设置环境变量：

cat > /etc/profile.d/cuda.sh <<'EOF' export PATH=/usr/local/cuda-12.8/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH EOF source /etc/profile.d/cuda.sh nvcc --version

看到nvcc版本信息，CUDA工具链就绪。注意如果你装的是其他小版本，把路径里的12-8替换成对应版本就行。

CUDA大版本内部还有小版本区别，驱动小版本的要求也可能不同。装完CUDA之后，先跑一个最简单的向量相加或者直接nvidia-smi，都能提前暴露版本匹配问题，别等到跑大负载才发现。

4.2 persistence mode与锁频取舍

新驱动装完后，GPU默认不工作在持续模式。对单次提交的大任务影响不大，但对频繁小任务来说，每次任务间的降频、升频开销会浪费不少时间。

开启持续模式：

nvidia-smi -pm 1

Persistence mode让显卡保持初始化状态，驱动常驻，任务队列延迟大幅降低。代价是空闲功耗比完全休眠高一些，对个人工作站无所谓，对大型机房集群就要多考虑功耗预算。

还有一个可选项是锁频：

nvidia-smi --lock-gpu-clocks=最高频率 nvidia-smi --lock-memory-clocks=最高频率

锁频适合基准测试和"要稳定不要节能"的重负载场景。日常训练如果任务本来就长时间满载，锁不锁差异不大；如果任务断断续续，锁频反而浪费电。结论：优先用persistence mode，锁频按需开。

4.3 systemd自启服务与巡检命令

Persistence mode在重启后会失效，所以最好注册成systemd服务。我提供一个结构清晰的unit文件：

[Unit] Description=NVIDIA GPU Persistence Mode After=multi-user.target [Service] Type=oneshot ExecStart=/usr/bin/nvidia-smi -pm 1 ExecStop=/usr/bin/nvidia-smi -pm 0 RemainAfterExit=yes [Install] WantedBy=multi-user.target

保存到/etc/systemd/system/nvidia-persistenced.service之后：

systemctl daemon-reload systemctl enable --now nvidia-persistenced

日常巡检命令也不复杂，我最常用的三连：

nvidia-smi dmesg | grep -i nvidia | tail -n 30 nvidia-smi --query-gpu=name,driver_version,temperature.gpu,utilization.gpu --format=csv

第三条命令批量统计多卡状态时特别好用，输出是干净CSV，可以直接喂给监控脚本或者拼进运维面板。

5. 装完之后的验证链路与故障排错

5.1 nvidia-smi与dmesg的完整验证序列

驱动安装完成并重启之后，第一件事就是验证。我建议按固定顺序执行：

nvidia-smi lsmod | grep -E "^nvidia" modinfo nvidia | head -n 5 dmesg | grep NVRM

正常的nvidia-smi输出会有完整表头，包含驱动版本、CUDA版本、显卡型号、显存大小、当前温度和功耗。如果这一步看到ERROR提示，直接跳转到下面两条命令定位。

lsmod能看到nvidia、nvidia_uvm、nvidia_drm、nvidia_modeset这些模块，说明内核模块加载成功。如果nvidia_uvm缺失，CUDA应用会无法启动。确认缺失时可以手动加载一次modprobe nvidia_uvm，看看具体报什么错，再做下一步。

dmesg里的NVRM开头的行最能说明问题。正常情况能看到：

NVRM: loading NVIDIA UNIX x86_64 Kernel Module

并且没有紧跟的Error或Fail。如果出现Xid相关的行，说明运行期出过故障，这就是5.3要展开的内容了。

5.2 黑屏和开机卡住的真实根因

重启后黑屏、卡在引导、或者进入命令行后屏幕无输出，是NVIDIA驱动部署最常见的"惨案"。我排过很多次这类问题，核心原因通常集中在两点。

第一点，nouveau没有彻底关闭。你确实写了blacklist，但initramfs没重建，或者重建时把nouveau又拉回去了。排查方法是用journalctl看上一次引导的内核日志：

journalctl -b -1 -k | grep -i -E "nouveau|nvidia|drm"

如果还能看到nouveau的加载记录，回到第2章把黑名单、grubby参数、dracut重建整体做一遍，不要漏任何一步。

第二点，显示管理器抢跑。gdm或sddm在GPU驱动还没初始化完成时就试图切到图形界面，导致显示器无信号或系统卡死。这也是我在准备阶段就建议把默认target切到multi-user的原因。驱动装好之后，先保持在命令行模式验证完，再手动systemctl start graphical.target，不要一上来就改回graphical.target。

此外还有一类硬件层面的黑屏原因：主板BIOS里主显示输出设置错误、供电功率不足、PCIe链路协商失败。这些在日志里往往表现为更早期的错误，可以先用dmesg | grep -i pcie做辅助判断。如果驱动日志干净但依然黑屏，回头查硬件状态。

5.3 Xid错误码的初步定位思路

当GPU在高负载运行中突然挂掉，日志里看到的往往是Xid错误。Xid是NVIDIA驱动定义的一类错误代码，不同编号对应不同原因。

我列几个高频出现的：

排错思路是从错误码出发，先查NVIDIA官方Xid说明，再结合自己的负载特征缩小范围。不要一看到错误就重装驱动，那会浪费大量时间。

我强烈建议，高负载验证阶段同时开一个终端持续跟踪内核日志：

dmesg -w

这样一旦出现Xid错误，至少能知道大致发生的时间和上下文，排查效率提升很多。裸跑大任务然后事后翻日志，往往只能看到一个孤零零的错误码，很难定位到是哪一个阶段出的问题。

6. 内核升级后的驱动保持与最终建议

6.1 DKMS：让驱动跟随内核自动重建

RHEL系滚动更新内核的节奏不慢，而runfile装的驱动模块默认只绑定安装时的内核。内核一升级，重启后nvidia-smi就失效，这种"驱动莫名其妙消失"的体验，用过几次就知道有多折腾。

解决办法就是DKMS机制。最理想的时间点是安装驱动时直接加--dkms参数：

./NVIDIA-Linux-x86_64-570.xxx.xx.run --dkms

如果驱动已经装完，可以手动把nvidia模块注册进DKMS：

dkms add -m nvidia -v 570.xxx.xx dkms build -m nvidia -v 570.xxx.xx dkms install -m nvidia -v 570.xxx.xx

注册之后，每次内核升级，DKMS都会自动用新内核重新编译nvidia.ko。前提是kernel-devel版本与新内核匹配，所以"kernel-devel和内核版本一致"这条铁律依旧成立。

很多人不知道的是：内核升级后驱动挂了，不要第一时间重跑runfile，先查dkms status和kernel-devel有没有跟上。多数情况下，手动执行一次dkms install就能把驱动救回来，比重装一遍快得多。

6.2 最终的建议与注意事项

整套部署走下来，我想把最重要的话放在最后：驱动安装出问题，绝大多数不是NVIDIA安装器的问题，而是系统准备工作没做干净。

具体来说就是三件事：nouveau是否彻底屏蔽、initramfs是否重建、kernel-devel是否和内核对齐。这三件任何一个不到位，后面的安装和验证都会以各种诡异方式失败。把准备工作做扎实之后，后面基本就是一路顺畅。

另外一个长期有用的习惯是：遇到问题先看日志再动手。nvidia-smi的报错、dmesg里的NVRM行、journalctl里的Xid错误，都是比重装一遍驱动更有价值的线索。日志里藏着答案，重装只是碰运气。

Blackwell架构的PRO 6000在AlmaLinux 9.7上按这套流程完整走一遍之后，nvidia-smi输出正常、CUDA计算任务稳定、重启后驱动也能持久生效。如果你正在处理类似部署，建议把第2章的准备工作做得比安装本身更仔细。这一篇踩过的弯路，你可以直接绕着走。