📚 课程目录第3章环境准备

3. 环境准备

3.1 操作系统选择：从“能用”到“好用”的决策

AI训练与推理集群的底层操作系统选择，直接决定了后续驱动兼容性、容器运行时稳定性以及运维效率。在真实生产环境中，Ubuntu Server 22.04 LTS 是当前最主流的选择，原因有三：其一，NVIDIA官方驱动与CUDA工具链对Ubuntu LTS版本的验证最充分；其二，Docker、Kubernetes、Slurm等集群组件在Ubuntu上的社区支持与故障案例最丰富；其三，内核版本（5.15+）对GPU直通、NVMe over Fabric等特性支持良好。

相比之下，CentOS Stream 9或Rocky Linux 9适合已有RHEL运维体系的企业，但需注意其驱动包与CUDA仓库的更新节奏略慢于Ubuntu。对于纯推理场景，也可考虑轻量化的Ubuntu Server Minimal，减少不必要的桌面组件与后台服务，降低安全攻击面。无论选择哪个发行版，务必确认内核版本 ≥ 5.4，否则部分A100/H100等新架构GPU可能无法被正确识别。

选型建议：若集群规模在4节点以内且以开发验证为主，直接选用Ubuntu 22.04 LTS；若为生产集群且已有Ansible/SaltStack运维体系，优先Rocky Linux 9并锁定小版本更新。

3.2 NVIDIA驱动安装：从识别GPU到加载内核模块

驱动安装的核心目标是让操作系统能够通过PCIe总线正确枚举GPU，并加载对应的内核模块nvidia、nvidia_uvm、nvidia_drm等。安装前必须先确认GPU型号与当前内核版本，避免盲目安装导致模块加载失败。

# 查看GPU硬件信息
lspci | grep -i nvidia

# 查看当前内核版本
uname -r

# 检查是否已安装过驱动
nvidia-smi   # 若提示command not found，则未安装

推荐使用NVIDIA官方runfile安装包或apt仓库安装两种方式。runfile方式可控性最强，适合需要自定义安装参数（如禁用nouveau、不安装OpenGL库）的场景；apt方式则便于后续通过apt upgrade统一维护。以下为runfile安装的标准流程：

# 1. 禁用系统自带的开源驱动nouveau
sudo bash -c "echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist-nvidia.conf"
sudo bash -c "echo 'options nouveau modeset=0' >> /etc/modprobe.d/blacklist-nvidia.conf"
sudo update-initramfs -u
# 重启后确认nouveau未加载：lsmod | grep nouveau 应无输出

# 2. 安装编译依赖
sudo apt update
sudo apt install -y gcc make linux-headers-$(uname -r)

# 3. 执行runfile安装（以NVIDIA-Linux-x86_64-550.54.15.run为例）
sudo chmod +x NVIDIA-Linux-x86_64-550.54.15.run
sudo ./NVIDIA-Linux-x86_64-550.54.15.run --no-opengl-files --silent

# 4. 加载内核模块并验证
sudo modprobe nvidia
nvidia-smi

安装完成后，nvidia-smi应能显示GPU型号、显存容量、驱动版本以及当前功耗与温度。若输出No devices were found，则需检查PCIe链路是否正常（lspci -v查看Kernel driver in use是否为nvidia）。

3.3 CUDA与cuDNN安装：版本匹配是成败关键

CUDA（Compute Unified Device Architecture）是GPU计算的并行编程平台，而cuDNN（CUDA Deep Neural Network library）则是针对深度学习算子（卷积、池化、归一化等）的加速库。两者与驱动版本之间存在严格的兼容矩阵，安装前务必查阅NVIDIA官方文档。

以当前主流组合为例：驱动550.54.15 + CUDA 12.4 + cuDNN 8.9.7，该组合支持PyTorch 2.3+、TensorFlow 2.16+。安装CUDA时，建议使用runfile方式而非deb包，因为runfile可以自定义安装路径（如/usr/local/cuda-12.4），便于多版本共存与切换。

# 下载并安装CUDA 12.4 runfile
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_550.54.15_linux.run
sudo sh cuda_12.4.0_550.54.15_linux.run --toolkit --silent --override

# 配置环境变量
echo 'export PATH=/usr/local/cuda-12.4/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

# 验证CUDA编译器
nvcc --version

cuDNN的安装相对简单，只需将解压后的头文件与库文件复制到CUDA目录即可：

# 解压cuDNN压缩包（需从NVIDIA官网下载，需登录账号）
tar -xzvf cudnn-linux-x86_64-8.9.7.29_cuda12-archive.tar.xz

# 复制头文件与库文件
sudo cp cudnn-*-archive/include/cudnn*.h /usr/local/cuda-12.4/include/
sudo cp -P cudnn-*-archive/lib/libcudnn* /usr/local/cuda-12.4/lib64/

# 设置库文件权限
sudo chmod a+r /usr/local/cuda-12.4/include/cudnn*.h
sudo chmod a+r /usr/local/cuda-12.4/lib64/libcudnn*

# 更新动态链接库缓存
sudo ldconfig

版本陷阱：切勿直接使用pip install nvidia-cudnn-cu12替代系统级cuDNN安装。pip包仅适用于Python虚拟环境内的运行时调用，无法被TensorRT或自定义C++算子链接。若集群中同时运行PyTorch与TensorFlow，务必确保两者依赖的cuDNN版本一致，否则会出现libcudnn.so.8: cannot open shared object file错误。

3.4 验证安装：从命令检查到实际计算

验证工作分为三个层级：驱动层验证、CUDA层验证、深度学习框架层验证。仅执行nvidia-smi远远不够，因为该命令只证明驱动已加载，无法确认CUDA运行时与cuDNN库是否真正可用。

验证层级	命令/方法	预期结果	失败排查方向
驱动层	`nvidia-smi`	显示GPU型号、驱动版本、显存	检查`dmesg \| grep nvidia`内核日志
CUDA运行时	`nvcc --version`	显示CUDA编译版本12.4	确认PATH与LD_LIBRARY_PATH配置
CUDA设备查询	`deviceQuery`（位于/usr/local/cuda-12.4/extras/demo_suite/）	返回Result = PASS，列出所有GPU	检查`/dev/nvidia*`设备节点权限
cuDNN库链接	`ldconfig -p \| grep cudnn`	显示libcudnn.so.8路径	确认复制时使用了`-P`参数保留软链接
框架实际计算	PyTorch执行矩阵乘法	GPU利用率上升，结果正确	检查CUDA_VISIBLE_DEVICES环境变量

最可靠的端到端验证是运行一个真实的深度学习算子测试。以下代码可同时验证CUDA与cuDNN是否被PyTorch正确调用：

import torch
import torch.nn as nn

# 检查CUDA是否可用
print("CUDA available:", torch.cuda.is_available())
print("GPU count:", torch.cuda.device_count())
print("GPU name:", torch.cuda.get_device_name(0))

# 执行卷积操作（依赖cuDNN）
conv = nn.Conv2d(3, 64, kernel_size=3, padding=1).cuda()
input_tensor = torch.randn(16, 3, 224, 224).cuda()
output = conv(input_tensor)
print("Conv output shape:", output.shape)

# 验证反向传播
loss = output.sum()
loss.backward()
print("Backward pass successful")

若输出CUDA available: True且卷积计算正常，说明驱动、CUDA、cuDNN三层均已正确安装。若torch.cuda.is_available()返回False，则需检查PyTorch版本是否与CUDA版本匹配（如pip install torch==2.3.0+cu124）。

3.5 常见误区与复盘

  误区一：驱动版本越新越好。实际生产中，最新驱动可能引入未知内核兼容问题。建议选择NVIDIA官方长期支持分支（Long Term Support），如550系列，而非最新短周期分支。

  误区二：忽略Secure Boot设置。若服务器启用了UEFI Secure Boot，未签名的NVIDIA内核模块将无法加载，导致nvidia-smi报错NVML: Driver not loaded。解决方案是在BIOS中禁用Secure Boot，或使用mokutil --import导入NVIDIA公钥。

  误区三：多版本CUDA共存时环境变量混乱。当同时安装CUDA 11.8与12.4时，若LD_LIBRARY_PATH同时包含两个版本的lib64目录，运行时可能加载错误版本的libcudart.so。建议使用module load或容器化方式隔离环境。

复盘一次真实排障案例：某训练节点在重启后nvidia-smi报错No devices were found，排查过程发现dmesg日志中提示NVRM: GPU at 0000:3b:00.0 has fallen off the bus。最终定位为GPU供电不足导致PCIe链路断开，而非驱动问题。这提醒我们：驱动安装成功不代表硬件链路稳定，在集群批量部署时，应通过nvidia-smi -q -d POWER检查所有节点的功耗与温度基线，并利用gpustat或DCGM工具建立监控告警。

最后，建议在完成所有节点安装后，编写一个集群级验证脚本，批量执行nvidia-smi、nvcc --version与PyTorch卷积测试，并将输出汇总为JSON报告。该脚本应纳入CI/CD流程，确保每次系统更新或驱动升级后都能快速回归验证，避免“装完即忘”导致的隐性故障。