2. GPU基础与驱动：GPU架构简介、NVIDIA驱动安装与验证

2.1 GPU架构核心概念：为什么它适合并行计算

在进入驱动安装之前，必须先理解GPU与CPU在架构设计上的根本差异。CPU由少量高性能核心（通常4~64个）组成，每个核心拥有巨大的缓存和复杂的控制单元，擅长处理串行、分支密集的逻辑任务。而GPU（以NVIDIA为例）采用大规模并行架构，由数千个简单计算核心组成，遵循“单指令多线程（SIMT）”模型——同一时刻，大量线程执行相同的指令，但作用于不同的数据。

以NVIDIA Ampere架构（A100/A30等）为例，其层级结构自上而下为：

  • GPU芯片：包含多个图形处理簇（GPC）；
  • GPC：内部包含多个流式多处理器（SM）；
  • SM：核心计算单元，包含CUDA核心、Tensor Core（张量核心）、共享内存、寄存器堆等；
  • CUDA核心：执行浮点/整数运算的最小单元。

这种层级设计决定了GPU程序优化的关键：线程调度以“线程束（Warp）”为单位（通常32个线程为一束），SM以Warp为单位进行创建、调度和切换。因此，编写GPU程序时，应尽量让同一Warp内的线程执行相同指令路径，避免分支发散，否则会造成计算资源浪费。

关键认知：GPU的并行度来自“大量线程 + 硬件级快速切换”，而非单个核心的时钟频率。驱动的作用之一，就是将这些硬件资源抽象为操作系统可见的设备，并管理线程调度、显存分配与上下文切换。
NVIDIA GPU 架构层级与驱动栈关系 CPU（主机端） 少量高性能核心 NVIDIA 用户态驱动 libcuda.so / libnvidia-ml.so 内核态驱动 nvidia.ko / nvidia-uvm.ko GPU 硬件 PCIe 设备 BAR 空间 GPU 内部硬件层级（以 Ampere 架构为例） GPC（图形处理簇） SM 0 CUDA 核心 ×64 Tensor Core ×4 共享内存 128KB Warp 调度器 SM 1 CUDA 核心 ×64 Tensor Core ×4 共享内存 128KB Warp 调度器 … GPC（图形处理簇） SM 2 CUDA 核心 ×64 Tensor Core ×4 共享内存 128KB Warp 调度器 SM 3 CUDA 核心 ×64 Tensor Core ×4 共享内存 128KB Warp 调度器 … 显存控制器（HBM2e） 带宽可达 2TB/s 以上 全局显存（VRAM） A100 40GB / 80GB 驱动栈：应用程序 → CUDA Runtime → 用户态驱动 → 内核态驱动 → GPU 硬件

2.2 NVIDIA驱动安装：方法与流程

NVIDIA驱动分为两种主要安装方式：RPM包管理器安装（适用于Red Hat/CentOS/Rocky等）和runfile安装（官方通用安装包）。在容器化环境中，宿主机驱动是基础，容器内通常不需要重复安装驱动，而是通过挂载宿主机的/dev/nvidia*设备节点和驱动库进入容器。

以下以Rocky Linux 9 + NVIDIA A100为例，展示标准安装流程：

步骤一：确认硬件与系统环境

# 查看PCIe设备是否识别到GPU
lspci | grep -i nvidia

# 确认系统已安装gcc、make、kernel-devel等编译工具
yum install -y gcc make kernel-devel-$(uname -r)

# 检查nouveau开源驱动是否加载（必须禁用）
lsmod | grep nouveau

步骤二：禁用nouveau驱动

nouveau是Linux内核自带的NVIDIA开源驱动，性能差且与官方驱动冲突。创建黑名单文件：

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

# 重新生成initramfs并重启
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
dracut /boot/initramfs-$(uname -r).img $(uname -r)
reboot

步骤三：安装NVIDIA驱动

# 方法A：使用RPM仓库（推荐生产环境）
dnf install -y epel-release
dnf install -y kmod-nvidia-latest

# 方法B：使用runfile（适用于特殊定制场景）
chmod +x NVIDIA-Linux-x86_64-550.54.14.run
./NVIDIA-Linux-x86_64-550.54.14.run --silent --dkms
建议：生产环境优先使用发行版官方仓库或NVIDIA官方CUDA仓库中的驱动包，便于后续升级和依赖管理。runfile方式适合需要自定义安装路径或内核模块参数的场景。

2.3 驱动验证：从基础到进阶

驱动安装完成后，必须进行系统化验证，确保GPU设备、驱动版本、CUDA运行时均正常工作。以下是推荐的验证清单：

验证层级 命令/工具 预期结果
设备识别 lspci | grep -i nvidia 显示NVIDIA设备型号
驱动加载 lsmod | grep nvidia nvidia、nvidia-uvm等模块已加载
驱动版本 nvidia-smi 显示驱动版本、CUDA版本、GPU利用率
设备节点 ls -l /dev/nvidia* 存在/dev/nvidia0、/dev/nvidiactl等
CUDA运行时 nvcc --version 显示CUDA编译器版本
计算功能 deviceQuery（CUDA示例） 返回设备属性，显示Compute Capability

最核心的验证命令是nvidia-smi，它输出GPU型号、驱动版本、显存使用、温度、功耗等关键信息。一个典型的输出示例如下：

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  NVIDIA A100 80GB    On   | 00000000:3B:00.0 Off |                    0 |
| N/A   32C    P0    45W / 300W |      0MiB / 81920MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

2.4 容器环境中的驱动映射

在Docker或Kubernetes环境中，宿主机驱动安装完成后，容器内需要显式暴露GPU设备。NVIDIA提供了NVIDIA Container Toolkit（nvidia-docker2）来自动完成设备映射。其核心原理是：

  1. 通过libnvidia-container库检测宿主机驱动版本；
  2. 将/dev/nvidia*设备节点挂载到容器；
  3. 将宿主机驱动库（如libcuda.so.1）映射到容器内；
  4. 设置环境变量NVIDIA_VISIBLE_DEVICES控制可见GPU。

安装与验证命令如下：

# 安装NVIDIA Container Toolkit
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.repo | \
  sudo tee /etc/yum.repos.d/nvidia-docker.repo
sudo dnf install -y nvidia-container-toolkit

# 重启Docker服务
sudo systemctl restart docker

# 验证容器内GPU可见性
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi
常见误区：不要在容器内重新安装NVIDIA驱动。容器共享宿主机内核，驱动必须与宿主机内核版本匹配。容器内只需安装CUDA Toolkit（用于编译）或CUDA Runtime（用于运行），驱动始终来自宿主机。

2.5 排障案例：驱动安装后nvidia-smi报错

现象：安装驱动后执行nvidia-smi，提示NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver。

排查路径：

  1. 检查内核模块是否加载：lsmod | grep nvidia，若无输出，执行modprobe nvidia；
  2. 检查Secure Boot：若BIOS启用了Secure Boot，驱动模块需要签名。查看dmesg | grep -i nvidia，若出现Operation not permitted，需在BIOS中关闭Secure Boot或使用mokutil --import导入签名；
  3. 检查内核头文件版本：驱动编译需要与当前内核完全匹配的kernel-devel包，执行uname -r确认版本；
  4. 查看日志：journalctl -xe | grep -i nvidia，定位具体错误码。

解决方案：最常见的原因是内核更新后驱动模块未重新编译。使用DKMS（Dynamic Kernel Module Support）可自动适配新内核：

# 安装DKMS并重新构建模块
dnf install -y dkms
dkms autoinstall
reboot

2.6 误区与复盘

核心复盘：驱动安装不是“一次性”工作，而是需要与内核版本、CUDA版本、容器运行时版本三方协同。建议在部署GPU节点时，锁定内核版本并启用DKMS，避免系统自动更新内核导致驱动失效。
  • 误区一：认为驱动版本越高越好。实际上，驱动版本需与CUDA版本兼容。例如，CUDA 12.x需要驱动版本≥525.60.13，而CUDA 11.x需要≥450.80.02。使用nvidia-smi右上角显示的CUDA Version即为该驱动支持的最高CUDA版本。
  • 误区二：忽略Persistence Mode。默认情况下，GPU在无任务时会进入低功耗状态，导致首次调用延迟。建议开启：nvidia-smi -pm 1，或通过systemd服务持久化设置。
  • 误区三：在容器中运行nvidia-smi看到“No devices were found”，但宿主机正常。这通常是因为容器缺少--gpus all参数，或NVIDIA Container Toolkit未正确安装。

最后，建议将驱动安装过程固化为自动化脚本或Ansible Playbook，并在每次内核更新后自动触发DKMS重建，确保GPU节点长期稳定运行。

← 上一章 📖 返回目录 下一章 →