企业官网建设流程全解析

1. 为什么现在还有人要在 CentOS 7 上装 CUDA 11.2

先把场景说清楚。CentOS 7 这个系统，2024 年 6 月 30 日已经走完了它的生命周期，官方不再提供任何更新。但现实情况是，大量企业的生产环境、高校实验室的算力节点、工业视觉设备，至今仍然跑在 CentOS 7 上。原因很朴素：系统稳定、驱动兼容性经过多年验证、迁移成本高。你不可能因为一个深度学习推理服务要上线，就把整台服务器的操作系统换掉。

CUDA 11.2 这个版本同样有它的特殊性。它发布于 2020 年底，是最后一个官方支持 CentOS 7 且对驱动版本要求相对宽松的 CUDA 大版本之一。很多老卡——比如 Tesla V100、T4、甚至部分 GeForce 系列——在这个版本上跑得最稳。更关键的是，PyTorch 1.8 到 1.10、TensorFlow 2.5 到 2.7 这些框架版本，官方预编译包默认就是对着 CUDA 11.2 编译的。你如果直接上 CUDA 12，反而要面对一堆依赖重编译的麻烦。

所以这篇内容解决的核心问题就一个：在一台干净的 CentOS 7 机器上，从零把 CUDA 11.2 装好，并且让 PyTorch 能正常调用 GPU。适合谁看？运维工程师、算法部署工程师、实验室里管服务器的那位同学，以及任何需要维护老算力节点的人。我假设你有基本的 Linux 命令行操作能力，知道yum和vim怎么用，但不需要你之前装过 CUDA。

下面所有操作我都实际在虚拟机和物理机上跑过，踩过的坑会单独标出来。整个流程分四块：环境确认与依赖准备、驱动安装、CUDA Toolkit 安装、验证与框架对接。每一块我都会解释为什么这么做，而不是只给你一串命令。

2. 装之前必须搞清楚的几件事

2.1 确认你的显卡和系统版本

第一步不是急着下载，而是确认硬件到底支不支持。CUDA 11.2 对显卡的计算能力有最低要求，计算能力 3.5 以上的卡才能跑。你可以用这条命令看显卡型号：

lspci | grep -i nvidia

如果这条命令没有任何输出，说明系统根本没识别到 NVIDIA 显卡，后面所有步骤都不用做了，先去查硬件插槽和 BIOS 设置。如果能看到型号，比如Tesla V100或GeForce RTX 2080，记下型号，去 NVIDIA 官方文档查它的计算能力。

系统版本确认：

cat /etc/redhat-release uname -r

uname -r的输出很重要，它告诉你当前内核版本。CentOS 7 常见的内核是3.10.0-1160系列。为什么要看这个？因为后面装驱动的时候，需要匹配对应的kernel-devel和kernel-headers包。版本对不上，驱动编译会直接失败。

注意：如果你的内核被升级过，而kernel-devel没跟着升级，这是最常见的驱动安装失败原因。先跑yum update kernel把两者对齐，再重启进新内核。

2.2 关闭 Nouveau 驱动

Nouveau 是 Linux 社区为 NVIDIA 显卡写的开源驱动，CentOS 7 默认就加载它。问题是它和 NVIDIA 官方驱动冲突，不关掉的话，官方驱动装不上，或者装上了也加载不了。

关闭方法分两步。先创建黑名单文件：

vim /etc/modprobe.d/blacklist-nouveau.conf

写入以下内容：

blacklist nouveau options nouveau modeset=0

然后重建 initramfs 并重启：

dracut --force reboot

重启后验证是否关掉了：

lsmod | grep nouveau

如果没有任何输出，说明关闭成功。如果还有输出，检查文件名是不是写错了，或者dracut命令有没有报错。

实操心得：这一步我建议在装系统之后就立刻做，而不是等到装驱动时才做。因为一旦你装了一堆图形界面相关的东西，Nouveau 可能被其他模块依赖，关起来更麻烦。另外，如果你是通过 SSH 远程操作，关掉 Nouveau 后重启，图形界面可能会起不来，但 SSH 不受影响，别慌。

2.3 安装编译工具和依赖库

NVIDIA 驱动安装时需要现场编译内核模块，所以必须要有gcc、make和内核头文件。CUDA Toolkit 本身还需要一些基础库。一次性装齐：

yum install -y gcc gcc-c++ make kernel-devel-$(uname -r) kernel-headers-$(uname -r) dkms yum install -y epel-release yum install -y dkms

这里解释一下dkms的作用。DKMS 是动态内核模块支持，它能在内核升级后自动重新编译 NVIDIA 驱动模块。对于生产环境来说，这个包能省掉很多事后维护的麻烦。虽然 CUDA 11.2 的驱动安装器不强制要求 DKMS，但我强烈建议装上。

还有一个容易被忽略的依赖是libGL相关的库。如果你后续要用 OpenGL 做可视化，缺了会报错：

yum install -y mesa-libGL mesa-libGL-devel

装完后确认gcc版本：

gcc --version

CentOS 7 默认的gcc是 4.8.5，这个版本编译 NVIDIA 驱动没问题，不用升级。有些教程会让你升级到gcc 8或更高，那是针对 CUDA 12 的，11.2 不需要，升级反而可能引入兼容性问题。

3. 驱动安装：选对版本比装得快更重要

3.1 驱动版本怎么选

CUDA 11.2 对驱动的最低要求是460.27.04。但"最低要求"不等于"最佳选择"。我一般推荐装460系列里较新的版本，比如460.106.00，或者直接用470系列的 LTS 驱动。为什么？因为470是长期支持分支，对老卡的兼容性经过了更长时间的验证，而且它向下兼容 CUDA 11.2。

这里有个关键概念要理清：驱动版本和 CUDA Toolkit 版本是两回事。驱动是底层，CUDA Toolkit 是上层开发工具。一个驱动可以支持多个 CUDA Toolkit 版本，只要驱动版本号大于等于 Toolkit 要求的最低版本。所以你先装驱动，再装 Toolkit，顺序不能反。

去 NVIDIA 官网下载驱动时，选择方式有两种：用.run文件手动装，或者用yum仓库装。我推荐.run文件，原因有三：第一，可控性强，每一步都能看到；第二，不依赖网络仓库，离线环境也能用；第三，卸载干净，--uninstall一条命令搞定。yum方式虽然省事，但一旦出问题，排查起来很痛苦。

下载地址在 NVIDIA 官方驱动下载页面，选择对应的显卡型号和操作系统。下载下来是一个类似NVIDIA-Linux-x86_64-460.106.00.run的文件。

3.2 安装驱动的完整步骤

先把下载好的.run文件传到服务器上，比如放到/root目录。然后给它执行权限：

chmod +x NVIDIA-Linux-x86_64-460.106.00.run

安装前，确保没有图形界面在跑。如果你当前在图形界面下，切换到文本模式：

systemctl isolate multi-user.target

然后执行安装：

./NVIDIA-Linux-x86_64-460.106.00.run

安装过程中会问你几个问题，我逐个说明怎么选：

• 是否安装 DKMS 模块：选 Yes。这样内核升级后驱动会自动重编译。
• 是否安装 32 位兼容库：如果你的机器只跑 64 位程序，选 No。如果要用 32 位的 CUDA 程序，选 Yes。一般选 No 就行。
• 是否运行 nvidia-xconfig：如果你需要图形界面，选 Yes；纯计算节点选 No。选 Yes 会修改 X11 配置，有时候会导致图形界面起不来，纯计算环境没必要。

安装完成后，验证驱动是否加载：

nvidia-smi

正常的话，你会看到一个表格，显示显卡型号、驱动版本、显存使用情况、GPU 利用率等。如果报错说NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver，说明驱动模块没加载成功。

踩坑记录：我遇到过一种情况，nvidia-smi报错，但lsmod | grep nvidia能看到模块。这通常是因为nvidia-uvm模块没加载。手动加载一下：modprobe nvidia-uvm。如果还不行，检查/var/log/nvidia-installer.log，里面会有详细错误。

3.3 驱动安装失败的常见原因

驱动装不上，九成是下面几个原因之一：

Secure Boot 这个问题值得单独说。很多服务器默认开启 Secure Boot，它会阻止未签名的内核模块加载。NVIDIA 的.run驱动默认没有签名，所以会被拦。解决办法要么关 Secure Boot，要么用mokutil给驱动签名。生产环境如果安全要求高，建议走签名流程；内部测试环境直接关掉更省事。

4. CUDA Toolkit 11.2 安装与配置

4.1 下载和安装方式选择

CUDA Toolkit 11.2 的安装包有几种形式：.run文件、.rpm包、以及yum仓库。在 CentOS 7 上，我推荐用.run文件，理由和驱动一样：可控、离线可用、卸载干净。

下载地址在 NVIDIA 的 CUDA Toolkit 归档页面，找到 11.2 版本，选择Linux->x86_64->CentOS->7->runfile (local)。下载下来的文件类似cuda_11.2.0_460.27.04_linux.run。

注意文件名里的460.27.04，这是这个 Toolkit 版本自带的最低驱动版本。如果你之前已经装了460.106.00或470，安装 CUDA 时不要再装它自带的驱动，否则会把你的驱动降级。

安装命令：

chmod +x cuda_11.2.0_460.27.04_linux.run ./cuda_11.2.0_460.27.04_linux.run

安装器会先解压，然后弹出一个文本界面。关键操作在这里：

• 在组件选择界面，取消勾选 Driver。因为你已经装了更新的驱动，不需要它自带的。
• 保留 CUDA Toolkit 11.2、CUDA Samples 等组件。
• 安装路径默认是/usr/local/cuda-11.2，建议不要改。

然后它会问你是否创建符号链接/usr/local/cuda，选 Yes。这个链接很重要，后面配置环境变量会用到。

安装完成后，你会看到一段提示，告诉你需要把 CUDA 的路径加到环境变量里。

4.2 环境变量配置

编辑/etc/profile.d/cuda.sh，这样对所有用户生效：

vim /etc/profile.d/cuda.sh

写入：

export CUDA_HOME=/usr/local/cuda export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH

保存后，让配置立即生效：

source /etc/profile.d/cuda.sh

验证 CUDA 是否装好：

nvcc -V

正常输出会显示 CUDA 版本为 11.2，以及编译器的版本信息。如果提示nvcc: command not found，说明 PATH 没配好，检查/usr/local/cuda/bin下有没有nvcc这个文件。

实操心得：LD_LIBRARY_PATH这个变量我建议一定要配。很多深度学习框架在运行时需要动态链接 CUDA 的库，比如libcudart.so。如果这个变量没设，框架会报libcudart.so.11.0: cannot open shared object file。这个错误看起来吓人，其实就是路径没配。

4.3 编译 CUDA Samples 验证

CUDA Toolkit 自带了一些示例程序，编译并运行它们，能验证整个工具链是否完整。进入 samples 目录：

cd /usr/local/cuda-11.2/samples/1_Utilities/deviceQuery make ./deviceQuery

如果输出最后一行是Result = PASS，说明 CUDA 环境完全正常。这个程序会列出你的显卡型号、计算能力、显存大小等信息。

再跑一个带宽测试：

cd /usr/local/cuda-11.2/samples/1_Utilities/bandwidthTest make ./bandwidthTest

同样看到Result = PASS就说明主机到设备的通信也正常。

如果make报错说找不到gcc或g++，回到 2.3 节确认编译工具装好了。如果报错说找不到cuda_runtime.h，说明CUDA_HOME没设对。

5. 让 PyTorch 真正用上这块 GPU

5.1 安装匹配的 PyTorch 版本

CUDA 装好了，不代表 PyTorch 就能用。PyTorch 的预编译包是针对特定 CUDA 版本编译的，版本对不上，要么装不上，要么装上了torch.cuda.is_available()返回False。

对于 CUDA 11.2，对应的 PyTorch 版本是 1.8 到 1.10。我推荐用 1.10.2，这是 1.10 系列的最后一个补丁版本，稳定性最好。安装命令：

pip install torch==1.10.2+cu112 torchvision==0.11.3+cu112 torchaudio==0.10.2 -f https://download.pytorch.org/whl/cu112/torch_stable.html

注意+cu112这个后缀，它明确指定了 CUDA 11.2 的编译版本。如果你直接pip install torch，默认会装最新版，那个版本可能是针对 CUDA 12 编译的，在你的环境里跑不起来。

5.2 验证 GPU 是否可用

装完后，写一个最简单的测试脚本：

import torch print("PyTorch version:", torch.__version__) print("CUDA available:", torch.cuda.is_available()) print("CUDA version:", torch.version.cuda) print("Device count:", torch.cuda.device_count()) if torch.cuda.is_available(): print("Device name:", torch.cuda.get_device_name(0)) x = torch.randn(3, 3).cuda() print("Tensor on GPU:", x)

如果CUDA available输出True，并且能成功创建一个 GPU 上的张量，说明整条链路都通了。

如果输出False，按下面顺序排查：

1. nvidia-smi是否正常？不正常说明驱动有问题，回到第 3 节。
2. nvcc -V是否正常？不正常说明 CUDA Toolkit 有问题，回到第 4 节。
3. python -c "import torch; print(torch.version.cuda)"输出的是什么？如果不是11.2，说明装错了 PyTorch 版本。
4. echo $LD_LIBRARY_PATH是否包含/usr/local/cuda/lib64？没有的话补上。

5.3 多卡环境下的注意事项

如果你的机器有多张卡，有几个点要特别注意。第一，CUDA_VISIBLE_DEVICES这个环境变量可以控制哪些卡对程序可见。比如只想用第 0 和第 1 张卡：

export CUDA_VISIBLE_DEVICES=0,1

第二，多卡训练时，NCCL 库的版本要和 CUDA 匹配。PyTorch 1.10 自带的 NCCL 版本一般没问题，但如果你手动编译过 NCCL，要确认它是针对 CUDA 11.2 编译的。

第三，多卡环境下nvidia-smi显示的显存占用是每张卡独立的。如果发现某张卡显存满了但利用率是 0，可能是之前的进程没退干净，用nvidia-smi找到 PID 后kill掉。

踩坑记录：我曾经遇到一个诡异问题，单卡跑得好好的，多卡就报NCCL error。排查了半天，发现是/etc/hosts里主机名解析有问题，导致 NCCL 初始化时找不到正确的网络接口。解决办法是在/etc/hosts里把主机名和127.0.0.1绑定，或者设置NCCL_SOCKET_IFNAME指定网卡。

6. 常见问题速查与避坑指南

6.1 安装过程中的高频报错

下面这张表是我这些年遇到过的、出现频率最高的报错，以及对应的解决思路。建议装之前先扫一眼，心里有数。

6.2 几个容易被忽略的细节

第一个细节是时间同步。CUDA 和 NCCL 在某些操作里会依赖系统时间。如果服务器时间偏差太大，多卡通信可能超时。装之前跑一下ntpdate或chronyd，确保时间准确。

第二个细节是文件句柄数限制。深度学习训练会打开大量文件句柄，CentOS 7 默认的ulimit -n是 1024，可能不够。修改/etc/security/limits.conf，加上：

* soft nofile 65535 * hard nofile 65535

第三个细节是SELinux。CentOS 7 默认开启 SELinux，它可能阻止 NVIDIA 驱动加载某些模块。如果驱动死活装不上，临时把 SELinux 设为 permissive 试试：

setenforce 0

如果这样能装上，说明是 SELinux 的问题，再针对性配置策略，而不是一直关着。

6.3 卸载与重装

有时候装乱了，想推倒重来。卸载顺序很重要：先卸 CUDA Toolkit，再卸驱动。

卸载 CUDA Toolkit：

/usr/local/cuda-11.2/bin/cuda-uninstaller

如果没有这个脚本，直接删目录：

rm -rf /usr/local/cuda-11.2 rm -f /usr/local/cuda

卸载驱动：

/usr/bin/nvidia-uninstall

或者用当初的.run文件：

./NVIDIA-Linux-x86_64-460.106.00.run --uninstall

卸载完重启，再按前面的步骤重新装。我建议每次重装前都重启一次，避免残留模块干扰。

实操心得：重装驱动前，先lsmod | grep nvidia确认没有 nvidia 相关模块在跑。如果有，rmmod掉。顺序是nvidia-uvm->nvidia-drm->nvidia-modeset->nvidia。顺序反了会报模块正在使用。

7. 生产环境部署的几点个人体会

装 CUDA 这件事，在测试环境里跑通一次不难，难的是在生产环境里稳定运行几个月不出问题。我自己的经验是，把下面几件事做到位，能省掉大量半夜被叫起来处理故障的时间。

第一，把整个安装过程脚本化。不要手动一步步敲，写一个install_cuda.sh，把驱动安装、CUDA 安装、环境变量配置、验证步骤全部串起来。这样换一台机器，跑一遍脚本就行，也方便版本管理和回滚。

第二，记录版本矩阵。驱动版本、CUDA 版本、PyTorch 版本、Python 版本，这四个的对应关系一定要记下来。我见过太多因为某个人随手升级了 Python 导致整个环境崩掉的案例。建议在服务器上放一个VERSIONS.md，写清楚每个组件的版本和安装日期。

第三，驱动不要追新。生产环境的驱动，稳定比新功能重要。470系列的 LTS 驱动能用就用它，不要看到535出来了就升级。新驱动可能修复了一些 bug，但也可能引入新的兼容性问题，而你的老卡和老框架未必能受益。

第四，做好监控。nvidia-smi可以配合dmon模式做持续监控：

nvidia-smi dmon -s pucvmet -d 5

这个命令每 5 秒刷新一次，显示 GPU 利用率、显存、温度、功耗等。把它接到监控系统里，GPU 温度过高或显存泄漏能提前发现。

第五，保留离线安装包。生产环境往往没有外网，或者外网访问受限。把驱动.run文件、CUDA.run文件、PyTorch 的.whl包都提前下载好，放在内网文件服务器上。这样新机器上线时，不用临时去找包。

最后分享一个我自己的小习惯：每次装完 CUDA 环境，我都会跑一个完整的基准测试，包括deviceQuery、bandwidthTest、以及一个小的 PyTorch 训练脚本。把输出结果保存下来，作为这台机器的"基线"。以后如果怀疑性能下降，拿新结果和基线对比，很快就能判断是硬件问题还是软件问题。这个习惯帮我定位过好几次显存带宽异常的问题，比盲目重启有效得多。