拿到一块 Blackwell 架构的 RTX PRO 6000 工作站显卡，想在 AlmaLinux 9.7 上把驱动跑起来，第一反应往往是“这不就是老流程嘛，屏蔽 nouveau、装官方 .run、重启”。但新一代架构对驱动版本、内核编译环境、Secure Boot 签名都有了更严格的要求，我实际踩下来花了不少时间，网上资料又大多集中在消费级 RTX 50 系列和 Ubuntu 上，RHEL 系发行版的完整流程反而比较分散。这篇文章就完整记录我从零到一在 AlmaLinux 9.7 上装通 PRO 6000 驱动过程中验证过的每个环节、参数和避坑点，适合需要在 RHEL 系发行版上部署 Blackwell 专业卡的朋友参考。
1. Blackwell 架构与 PRO 6000 系列定位分析
1.1 Blackwell 给驱动安装带来了哪些变化
Blackwell 架构是 NVIDIA 面向 AI 计算和高性能图形推出的新一代 GPU 架构，相比上一代 Ada Lovelace，它的计算单元规模、显存带宽和互联能力都有明显升级，显存也换成了 GDDR7，PCIe 通道升级到 Gen5。这些硬件层面的变化直接映射到了驱动要求上：新架构需要新驱动分支支持，老的 470、535 这些稳定分支根本不认识 Blackwell，从装驱动这一步开始就和旧卡不同。
我最初在网上查资料时，默认按老经验去找驱动版本，结果安装程序报出 unsupported GPU 的提示。后来我才确认，PRO 6000 这类 Blackwell 专业卡需要搭载 570 及以上的生产分支驱动，而且建议配合 CUDA 12.8+ 使用。这意味着在选择驱动时不能只看“最新版本号”，还得确认它是否对 Blackwell 架构做了正式支持。
另外，Blackwell 架构对系统侧的依赖也更敏感。比如内核版本太老、缺少新版 GCC、没有启用 UEFI 固件里的 Resizable BAR，都有可能在驱动加载阶段出现意想不到的问题。很多朋友在安装时习惯沿用旧教程直接跑 .run 文件，遇到问题后才发现前置条件没满足。
1.2 PRO 6000 与前代专业卡的区别
PRO 6000 系列是 Blackwell 架构下的工作站旗舰，代替的是此前的 RTX 6000 Ada 系列。两者在驱动安装上有本质区别：RTX 6000 Ada 用旧驱动分支就能跑，而 PRO 6000 则必须使用 Blackwell 支持版本。如果手头有多个型号混插，还需要查清楚每块卡对应的驱动分支，确保驱动版本在所有设备之间兼容。
我在实际准备过程中做了个简单对比，方便理解 PRO 6000 的位置：
| 对比项 | Ada 架构 RTX 6000 | Blackwell 架构 PRO 6000 |
|---|---|---|
| 显存类型 | GDDR6（部分为 GDDR6X） | GDDR7 |
| PCIe 接口 | PCIe 4.0 级别 | PCIe 5.0 级别 |
| 驱动分支 | 535/550 及更新 | 570 及更新 |
| CUDA 支持 | CUDA 11.x/12.x 均可 | 建议 CUDA 12.8+ |
| 典型工作场景 | 传统工作站图形渲染 | AI 推理、大显存训练、实时渲染 |
这个对比表不需要当作绝对参数，硬件规格以官方发布为准。我列出来的意义在于说明一个关键判断：驱动版本不再是一个“能用就行”的选项，它直接决定了 GPU 能否被系统正确识别。在开始安装之前，建议先去 GPU 页面确认 Handled Models 中是否包含 PRO 6000 的设备 ID。
1.3 为什么选用 AlmaLinux 9.7
AlmaLinux 是 RHEL 9.7 的免费克隆版本，内核版本、软件包仓库和 RHEL 保持一致，适合跑 CUDA 计算和长时间运行的推理服务。相比 Ubuntu 系，RHEL 系的软件包更新节奏更保守，驱动编译依赖方面的兼容性问题相对少一些，这也是很多数据中心工作站选择它的原因。
9.7 版本在安全更新和硬件兼容上有较好表现，而且会随 RHEL 同步更新到较新的内核分支。对 Blackwell 来说，一个足够新、带补丁的内核意味着更稳定的 DMA 管理和更完整的 framebuffer 支持。如果你打算长期稳定跑 PRO 6000，而不是每隔几个月就重装系统，AlmaLinux 9.7 是个合适的基础系统。
2. 安装前的系统检查与基础环境
2.1 硬件识别与固件设置
装驱动不是拿到显卡就开跑，先把系统环境确认清楚能省掉后面一大半的精力。开机前先确认显卡供电接口插到位，PRO 6000 这类工作站旗舰功耗不低，供电不足会导致驱动加载后设备消失。
进入系统后第一步是确认硬件识别情况，执行：
lspci | grep -i nvidia正常情况下能看到 NVIDIA 相关设备的 VGA Controller 或 3D Controller 输出。如果这里没有任何输出，先检查 PCIe 插槽和供电，再去排查 BIOS 设置。注意区分两块卡的时候可以用lspci -vnn查看完整设备 ID，后面核对驱动支持列表时用得上。
接下来进入固件设置界面，确认几个关键项：
- 启动模式设置为 UEFI，避免 CSM 兼容模式下的中断路由异常
- 启用 Above 4G Decoding / Resizable BAR，Blackwell 架构对 BAR 空间需求较高，没开容易导致显存映射失败
- 关闭板载 VGA 输出优先选项，防止系统默认从集显启动
我第一次装的时候跳过了 Resizable BAR 设置，驱动能装上，但显存读写带宽明显不正常，跑大模型时性能波动很厉害。回 BIOS 打开 Above 4G Decoding 之后才稳下来。这个问题在兼容性检查单里平时不容易注意到，但对新架构影响挺大。
2.2 屏蔽 nouveau 开源驱动
在 RHEL 系系统上，nouveau 会默认加载，它和 NVIDIA 官方驱动同时存在必然冲突，表现为 nvidia-smi 找不到设备，或者系统启动后画面撕裂。Blackwell 架构下 nouveau 的初始化能力本来就不完整，所以屏蔽操作必须做，而且要做得干净。
创建屏蔽配置文件：
sudo tee /etc/modprobe.d/blacklist-nouveau.conf << EOF blacklist nouveau options nouveau modeset=0 EOF然后重建 initramfs：
sudo dracut --force这里有个容易忽略的点：改完配置后不要马上装驱动，先重启一次，确认 nouveau 彻底不加载了再继续。用lsmod | grep nouveau验证，如果还有输出，说明 initramfs 里还残留了 nouveau，需要重新执行 dracut 并再次重启。我见过不少人在这个环节直接跳过验证，结果驱动链路问题一直到最后才暴露。
2.3 安装编译依赖与开发工具链
NVIDIA 官方驱动在安装时会编译内核模块，这意味着系统里必须有完整的编译工具链和内核头文件。缺少任何一个依赖，安装程序都会在接近尾声时抛错，处理起来比开始前装好依赖麻烦得多。
执行：
sudo dnf groupinstall "Development Tools" sudo dnf install kernel-devel kernel-headers gcc make dkms elfutils-libelf-devel重点关注 kernel-devel 的版本是否和当前内核完全匹配：
uname -r rpm -q kernel-devel两个命令的输出版本必须一致。如果系统刚做完内核更新，kernel-devel 可能还停留在旧版本，那就先重启进入最新内核，再检查一次。
这一步还要确认 GCC 版本。Blackwell 较新的驱动对 GCC 版本比较敏感，安装时会检查编译器版本是否在支持范围内。如果 GCC 过新或过旧，安装程序可能中断，需要留意安装日志里提到的 CC version check 提示。我实际使用中比较稳妥的方案是保持系统自带的 GCC 版本，不要随意从第三方源拉取高版本编译器。
另外一个容易被忽略的小细节：安装 dkms 后，内核模块可以在后续内核升级时自动重新编译，省去手动维护的成本。强烈建议在跑驱动安装之前就把 dkms 装好，后面更新内核时你会感谢这个决定。
3. 驱动安装完整流程实操
3.1 驱动版本选择与下载方式
PRO 6000 的驱动不能直接在系统默认仓库里找到，需要从官网或 CUDA 仓库获取。最直接的两种方式是对比 .run 安装包和 CUDA 仓库 rpm 安装。我用的是官方 .run 安装包，理由是它提供了对 Secure Boot 签名和 dkms 的完整控制，适合单机工作站场景。
版本选择上，不要只看数字大小，要确认驱动分支是否支持 Blackwell 架构。建议直接用官方搜索页筛选 PRO 6000 系列，下载对应 Linux 64-bit 版本。需要留意新功能分支和生产分支的区别：新功能分支对最新硬件支持最积极，生产分支则偏稳定。工作站机器建议先评估实际用途，如果是跑长周期 AI 训练，生产分支更稳妥。
不同安装方式的适用场景对比：
| 安装方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 官方 .run | 可控性强、支持 Secure Boot 签名 | 不自动更新、依赖手动处理 | 单机工作站、临时测试机 |
| CUDA 仓库 rpm | 可随系统仓库升级 | 仓库配置多一层依赖 | 批量部署、统一环境管理 |
| 发行版默认仓库 | 简单 | 基本不会有新架构支持 | 老显卡、非专业用途 |
个人建议：如果你不是要部署几十台机器，就用官方 .run 安装包，至少它直接暴露了日志、参数和签名流程，出问题的时候排查路径短。
3.2 Secure Boot 驱动签名流程
现在不少工作站在买回来时就预装了带 Secure Boot 的系统，AlmaLinux 9.7 也不例外。在 Secure Boot 开启状态下，系统只加载经过签名的内核模块，而 NVIDIA 驱动自带的模块默认没有签名，如果不处理，重启后会出现加载失败。
处理方式是在装驱动前先生成自己的密钥并导入 MOK（Machine Owner Key）。整个流程并不复杂：
生成密钥和证书：
openssl req -new -x509 -newkey rsa:2048 \ -keyout mok.key -out mok.pem \ -nodes -days 3650 -subj "/CN=My MOK Key/"把证书导入 MOK 列表：
sudo mokutil --import mok.pem此时系统会提示设置一次性密码。之后重启，在蓝色界面中选择 Enroll MOK，输入刚才设置的密码确认。完成后 Secure Boot 会信任这把密钥。
接下来安装驱动时需要指定签名参数。面向 NVIDIA .run 安装器，可以这样执行：
sudo ./NVIDIA-Linux-x86_64-570.xx.run \ --dkms \ --module-signing-secret-key=/path/to/mok.key \ --module-signing-cert=/path/to/mok.pem这样做的好处是：驱动模块每次编译完成后，安装程序都会用你的密钥自动签名。如果没有指定这个参数，也可以等驱动装完再手动对 .ko 文件签名，但那样流程多一步，而且内核一更新就要重复操作，不如上面指令省心。
如果你用的不是 .run 安装包，而是 rpm 方式，签名流程会稍有不同，需要借助sign-file对内核模块签名之后再加载。个人经验是，先装 .run 把整个链路跑通，再考虑 rpm 批量方案。
3.3 关闭图形界面并执行安装脚本
RHEL 系系统默认可能带着图形登录界面，运行 NVIDIA 驱动安装程序前最好先切到纯文本模式，避免 X 进程占用 GPU 设备。执行以下命令切换到多用户目标：
sudo systemctl isolate multi-user.target确认图形界面不占内存后，登录终端执行安装。安装脚本支持交互式与静默模式，完整运行参数示例如下：
sudo ./NVIDIA-Linux-x86_64-570.xx.run --dkms --silent第一次跑的时候不要加--silent，直接用交互模式逐步确认，可以看到它检测到 Blackwell 设备、编译内核模块的过程。安装完成后屏幕上会提示是否更新 X 配置文件，工作站环境下选择不更新即可，命令行验证主要靠 nvidia-smi。
安装完成后先不要急着重启，直接执行：
sudo nvidia-smi如果输出能看到 NVIDIA-SMI 版本和 GPU 信息，那说明基础驱动已经工作。如果这里报错，先检查 Secure Boot 签名和 initramfs 是否残留了旧的驱动模块。确认没问题后再重启，重启后再次执行 nvidia-smi，确保加载流程正常。
3.4 验证驱动与 CUDA 环境
驱动装好之后，还要确认 CUDA 运行环境是否完整。PRO 6000 的价值在于计算能力，没有 CUDA 工具链的话很多应用根本跑不起来。可以先用 nvidia-smi 查看驱动支持的 CUDA 版本范围，再来决定安装哪个 CUDA 工具包。
安装 CUDA 时可以选择从 NVIDIA CUDA 仓库装，也可以直接用 pip 安装 PyTorch 自带的 CUDA 运行库。纯驱动场景下，nvidia-smi 已经会显示 CUDA 版本，但它只是驱动支持的版本号，不等于系统已安装完整 CUDA 工具链。如果你只是要跑深度学习框架，用框架自带的 CUDA 调度即可；如果你需要自己编译 CUDA 代码，那就需要安装完整的 CUDA Toolkit，它的版本不能高于 nvidia-smi 显示的 CUDA 版本号。
这一步容易被搞混：驱动编译时依赖的是内核开发环境，而应用层依赖的是 CUDA Toolkit。两者的版本不需要严格相等，只要驱动版本不低于 Toolkit 要求即可。
4. 常见问题与排查实录
4.1 Secure Boot 导致驱动模块加载失败
我装完后第一次重启，发现系统能正常进入，但 nvidia-smi 输出显示No devices were found。当时第一反应是驱动没装好，查看内核日志：
journalctl -k | grep -i nvidia日志里明确出现了Operation not permitted或Key was rejected by service相关提示，这就是典型的签名校验失败。问题根源就是我之前做驱动签名时，MOK 密钥没有真正导入成功。
排查时不要急着重装驱动。先用mokutil --list-enrolled检查当前已导入的密钥是否包含自己生成的那把。如果没有，重新执行sudo mokutil --import mok.key，并在重启后进入 MOK 管理界面确认导入。这样一个操作能省掉重装驱动的十几分钟。
有个细节要注意：MOK 支持导入 PEM 格式公钥，但在导入前确认文件名和路径没有中文字符或乱目录，导入过程偶尔会因为路径问题卡住。
4.2 编译失败与 GCC、内核版本不匹配
安装过程中最常见的退出原因就是内核模块编译失败，错误信息类似unable to load kernel module或failed to compile module symbol versions。这种问题多数不是驱动本身的问题，而是编译环境混乱。
排查路径按顺序走：
- 确认
uname -r和kernel-devel版本一致 - 确认 GCC 版本在驱动支持范围内
- 确认没有其他第三方内核模块干扰编译
我之前在 9.6 上升级过内核但没重启，导致 running kernel 还是旧的，kernel-devel 却是新的，编译时符号表对不上，驱动模块一直无法载入。解决方式很简单：重启一次，让系统运行在最新内核下，再重装驱动。加了 dkms 之后，这类问题基本不会再出现，因为它会在内核更新后自动重编译模块。
如果是 GCC 版本问题，不建议直接加--no-cc-version-check跳过检查，我试过，虽然能装上，但运行某些 CUDA 应用时会有不稳定表现。优先考虑安装系统仓库支持范围内的 GCC 版本。
4.3 供电不足与 PCIe Gen5 协商失败
PRO 6000 满载运行时功耗接近 600W 级别，如果电源或 PCIe Gen5 辅助供电接口不够规格，驱动能装上，但 GPU 在负载下会周期性掉卡。现象是nvidia-smi时有时无，或者跑推理程序时 GPU 利用率瞬间掉到 0。
先用nvidia-smi -q -d POWER查看电源读数，如果能正常显示功耗信息，再检查 PCIe 链路状态：
sudo lspci -vv -s 01:00.0 | grep -E "LnkSta|LnkCap"如果协商速度只有 PCIe x8，甚至 Gen3，说明实际没有跑在目标带宽。这时候除了检查主板 BIOS 中 PCIe 插槽拆分方式，还要确认显卡供电线有没有插到位。工作站机箱里有多张卡时，尤其容易因为拆分的 PCIe 槽位导致带宽减半。
我遇到过一次因为供电线缆端子老化，导致开机自检能识别设备、进入系统就掉卡。当时完全没想到是供电问题，结果换了一条正规 12VHPWR 线缆就恢复了。遇到无法解释的掉卡问题，优先考虑供电链路。
4.4 问题排查速查表
| 现象 | 可能原因 | 排查命令/手段 | 解决办法 |
|---|---|---|---|
| nvidia-smi 找不到设备 | Secure Boot 签名未导入 | journalctl -k 查签名报错 | 导入 MOK 并重启确认 |
| 编译中断 | kernel-devel 版本不一致 | rpm -q kernel-devel | 重启到最新内核再装 |
| 负载下掉卡 | 电源供电不足 | nvidia-smi -q -d POWER | 更换供电线/电源 |
| 带宽跑不满 | Resizable BAR 未开启 | lspci 查看 BAR 范围 | BIOS 开启 Above 4G Decoding |
| 图形界面黑屏 | nouveau 未正确屏蔽 | lsmod 查 nouveau | 重建 initramfs 并重启 |
5. 性能验证与后续使用技巧
5.1 使用基准工具验证 GPU 状态
驱动装完只能说明加载成功，真正确保 PRO 6000 发挥 Blackwell 架构算力，还需要跑一次实际负载验证。我习惯先看基础状态：
nvidia-smi正常输出中，驱动版本、CUDA 版本、显存容量和当前功耗都应显示正确。此时 GPU 利用率应该为低负载状态，风扇如果存在则保持安静。
接着用简单的 CUDA 样例做设备枚举：
/usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery如果没有编译样例，直接用 PyTorch 验证更省事：
python3 -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"如果这里输出 False，问题基本不在驱动，而是 PyTorch 自带的 CUDA 版本和驱动不匹配。检查nvidia-smi显示的 CUDA 版本，安装对应版本的 PyTorch 即可。
跑通这些之后，再做一个实际的推理任务验证显存分配和功耗波动。比如加载一个 7B 参数模型，观察显存占用稳定和利用率变化。这一步能同时验证显存映射、持久化模式和散热是否正常。
5.2 驱动与 CUDA 日常维护建议
驱动装完只是开始，后续做成稳定的工作环境，有几个建议值得提前做。
开启持久化模式：
sudo nvidia-smi -pm 1持久化模式让 GPU 保持低功耗待机状态，避免频繁初始化，对多任务切换的场景特别有用。如果想永久生效，可以写成一个 systemd 服务，也可以在工作站启动脚本里调用一次。
内核更新前后记得检查 dkms 状态：
sudo dkms status如果某些模块显示 disappeared，说明重编译没有自动完成，需要手动sudo dkms install一次。这个问题只有在升级内核后重启才能发现，趁重启前检查一遍能省事不少。
如果后续要用 Docker 或容器跑 AI 工作负载，还需要安装 NVIDIA Container Toolkit，并在/etc/docker/daemon.json中加入nvidiaruntime。驱动层面不用额外改动，容器直接复用宿主机的 NVIDIA 内核模块。这个配置和驱动安装是独立的两个环节，但经常有人把容器里报 CUDA 不可用误判成驱动问题。
5.3 个人踩坑与扩展方向
这次在 AlmaLinux 9.7 上装 PRO 6000 驱动，最大的教训就是别照搬消费级显卡的教程。工作站专业卡的驱动分支、签名流程、固件设置都有差异，每一样都直接关系到最终能否稳定跑起来。我在实际使用中发现，Blackwell 架构显卡在深度学习工作负载下的表现确实值得折腾，但同时它的前置条件更多，需要一块健康的供电链路和一个完整更新的系统环境。
这个机器后续我计划再接入多卡互联测试，验证一下 Blackwell 架构在多卡并行训练时的表现。到时候如果需要同步更新驱动，只用把 dkms 模块维护好，基本不用担心系统层面出错。如果你也是第一次在 RHEL 系上部署 Blackwell 专业卡，希望你这次能少踩我踩过的坑。
