先说一个我最近实际遇到的场景。某台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-releaselspci | 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-cCUDA安装器后续会自己校验。2.2 nouveau的三种屏蔽手段与正确组合nouveau是内核自带的开源NVIDIA驱动它对Blackwell架构支持极差而且在某些内核上加载时会占用设备导致闭源驱动无法绑定显卡。所以屏蔽nouveau是必做项。官方推荐的做法是写modprobe配置cat /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF第二种方式是通过grubby追加内核启动参数grubby --update-kernelALL --argsrd.driver.blacklistnouveaugrubby是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不至于重装系统。然后切换默认targetsystemctl 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下载完先校验SHA256NVIDIA官网会给出哈希值再给执行权限。这一步很多教程不会提但企业级安装环境里下载源内容被替换的事确实发生过。多花几秒钟值得。3.2 安装命令逐项解读与预期输出纯命令行环境最稳妥的执行方式chmod x NVIDIA-Linux-x86_64-570.xxx.xx.run ./NVIDIA-Linux-x86_64-570.xxx.xx.run --no-questions --uinone--no-questions表示全程不交互遇到询问一律采用默认值--uinone表示不用图形界面安装器这在无显示器的服务器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固件默认开启还是关闭这是新架构驱动里值得单独说的话题。GSPGPU System Processor是显卡内部的一个独立管理处理器从某几代架构开始成为默认设备管理主体Blackwell全面采用这一设计。默认情况下新驱动会自动启用GSP固件把显存管理、上下文切换、虚拟化辅助都交给GSP处理。绝大多数专业场景下GSP开启是正确的内存管理更干净、多进程隔离更好、虚拟化功能更完整。只有两类情况才考虑关掉GSP做特殊的大规模虚拟化透传实验且遇到了与GSP相关的设备复位问题对GPU调用延迟做极端测试希望尽量绕开GSP层关闭方式echo options nvidia NVreg_EnableGSP0 /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 1Persistence mode让显卡保持初始化状态驱动常驻任务队列延迟大幅降低。代价是空闲功耗比完全休眠高一些对个人工作站无所谓对大型机房集群就要多考虑功耗预算。还有一个可选项是锁频nvidia-smi --lock-gpu-clocks最高频率 nvidia-smi --lock-memory-clocks最高频率锁频适合基准测试和要稳定不要节能的重负载场景。日常训练如果任务本来就长时间满载锁不锁差异不大如果任务断断续续锁频反而浪费电。结论优先用persistence mode锁频按需开。4.3 systemd自启服务与巡检命令Persistence mode在重启后会失效所以最好注册成systemd服务。我提供一个结构清晰的unit文件[Unit] DescriptionNVIDIA GPU Persistence Mode Aftermulti-user.target [Service] Typeoneshot ExecStart/usr/bin/nvidia-smi -pm 1 ExecStop/usr/bin/nvidia-smi -pm 0 RemainAfterExityes [Install] WantedBymulti-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-gpuname,driver_version,temperature.gpu,utilization.gpu --formatcsv第三条命令批量统计多卡状态时特别好用输出是干净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驱动定义的一类错误代码不同编号对应不同原因。我列几个高频出现的Xid码常见场景优先排查方向79GPU fallen off the bus供电、PCIe插槽接触、机箱散热48显存访问异常显存压力、ECC状态、温度过高56应用越界导致CUDA context异常CUDA与驱动版本匹配、应用侧内存访问43因前序错误导致GPU停止处理结合前序Xid码一起看排错思路是从错误码出发先查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模块注册进DKMSdkms 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章的准备工作做得比安装本身更仔细。这一篇踩过的弯路你可以直接绕着走。 
长河君 · 2026/10/17 4:40:50 · 阅读 1.2k AlmaLinux 9.7部署Blackwell NVIDIA驱动与CUDA环境
先说一个我最近实际遇到的场景。某台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-releaselspci | 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-cCUDA安装器后续会自己校验。2.2 nouveau的三种屏蔽手段与正确组合nouveau是内核自带的开源NVIDIA驱动它对Blackwell架构支持极差而且在某些内核上加载时会占用设备导致闭源驱动无法绑定显卡。所以屏蔽nouveau是必做项。官方推荐的做法是写modprobe配置cat /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF第二种方式是通过grubby追加内核启动参数grubby --update-kernelALL --argsrd.driver.blacklistnouveaugrubby是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不至于重装系统。然后切换默认targetsystemctl 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下载完先校验SHA256NVIDIA官网会给出哈希值再给执行权限。这一步很多教程不会提但企业级安装环境里下载源内容被替换的事确实发生过。多花几秒钟值得。3.2 安装命令逐项解读与预期输出纯命令行环境最稳妥的执行方式chmod x NVIDIA-Linux-x86_64-570.xxx.xx.run ./NVIDIA-Linux-x86_64-570.xxx.xx.run --no-questions --uinone--no-questions表示全程不交互遇到询问一律采用默认值--uinone表示不用图形界面安装器这在无显示器的服务器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固件默认开启还是关闭这是新架构驱动里值得单独说的话题。GSPGPU System Processor是显卡内部的一个独立管理处理器从某几代架构开始成为默认设备管理主体Blackwell全面采用这一设计。默认情况下新驱动会自动启用GSP固件把显存管理、上下文切换、虚拟化辅助都交给GSP处理。绝大多数专业场景下GSP开启是正确的内存管理更干净、多进程隔离更好、虚拟化功能更完整。只有两类情况才考虑关掉GSP做特殊的大规模虚拟化透传实验且遇到了与GSP相关的设备复位问题对GPU调用延迟做极端测试希望尽量绕开GSP层关闭方式echo options nvidia NVreg_EnableGSP0 /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 1Persistence mode让显卡保持初始化状态驱动常驻任务队列延迟大幅降低。代价是空闲功耗比完全休眠高一些对个人工作站无所谓对大型机房集群就要多考虑功耗预算。还有一个可选项是锁频nvidia-smi --lock-gpu-clocks最高频率 nvidia-smi --lock-memory-clocks最高频率锁频适合基准测试和要稳定不要节能的重负载场景。日常训练如果任务本来就长时间满载锁不锁差异不大如果任务断断续续锁频反而浪费电。结论优先用persistence mode锁频按需开。4.3 systemd自启服务与巡检命令Persistence mode在重启后会失效所以最好注册成systemd服务。我提供一个结构清晰的unit文件[Unit] DescriptionNVIDIA GPU Persistence Mode Aftermulti-user.target [Service] Typeoneshot ExecStart/usr/bin/nvidia-smi -pm 1 ExecStop/usr/bin/nvidia-smi -pm 0 RemainAfterExityes [Install] WantedBymulti-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-gpuname,driver_version,temperature.gpu,utilization.gpu --formatcsv第三条命令批量统计多卡状态时特别好用输出是干净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驱动定义的一类错误代码不同编号对应不同原因。我列几个高频出现的Xid码常见场景优先排查方向79GPU fallen off the bus供电、PCIe插槽接触、机箱散热48显存访问异常显存压力、ECC状态、温度过高56应用越界导致CUDA context异常CUDA与驱动版本匹配、应用侧内存访问43因前序错误导致GPU停止处理结合前序Xid码一起看排错思路是从错误码出发先查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模块注册进DKMSdkms 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章的准备工作做得比安装本身更仔细。这一篇踩过的弯路你可以直接绕着走。