Linux服务器从零配置PyTorch GPU环境：驱动、conda与CUDA版本全攻略

有的朋友拿到一台Linux服务器，第一件事不是装PyTorch，而是先犯了难：驱动装没装、Python用哪个版本、CUDA到底该选哪个、pip装完怎么一import就报错。配环境这件事看着简单，实际坑不少，尤其是服务器上多个用户共用、GPU型号新旧不一、之前的人装过乱七八糟依赖的情况。我在实验室和公司线下机器上折腾过很多次，这篇就把Linux服务器上从零配好PyTorch环境的完整过程、版本取舍、实测踩坑点全部写清楚。

这篇内容适合这几类人看：刚接触服务器的新手、需要给团队统一配置深度学习环境的人、以及明明照网上教程装完却跑不起来的老哥。我会用到Linux常用命令、conda环境管理、CUDA与驱动的对应关系，尽量把每个环节的“为什么”也讲透，避免你只会照抄命令，换个版本就抓瞎。

1. 动手前先摸底：确认服务器硬件与驱动，决定PyTorch版本

很多教程上来就让你pip install torch，结果装完发现torch.cuda.is_available()返回 False，问题就出在开头没做服务器摸底。这一节非常重要，属于那种“省了会返工、做了能保命”的步骤。

1.1 查看系统版本、架构、显卡与驱动

登录服务器后，先把这几条命令挨个敲一遍，确认底子是什么样：

# 操作系统版本 cat /etc/os-release # CPU架构（x86_64还是ARM，这个影响后面选安装包） uname -m # 内核版本 uname -r # 显卡型号与驱动信息 nvidia-smi # 如果nvidia-smi不存在，先看有没有NVIDIA显卡硬件 lspci | grep -i nvidia

这里重点说下nvidia-smi的输出。它会直接告诉你两件事：显卡驱动版本，以及驱动支持到的最高CUDA版本。比如我见过很多新手的服务器显示CUDA Version: 12.1，这句话的意思是当前驱动最多能兼容到 CUDA 12.1，不代表你已经装好了 CUDA 12.1。PyTorch 的 GPU 版本安装包里自带 CUDA runtime，只要它要求的CUDA版本小于等于驱动支持的版本，通常就能运行。

所以看到nvidia-smi里的CUDA版本是12.1，再去看 PyTorch 官网，选cu118或cu121的安装包都是没问题的。如果你的服务器比较老，显示CUDA Version: 11.4，那你就别死磕最新版 PyTorch，老老实实找 CUDA 11.x 对应的旧版本安装包，越新版本越容易报driver too old的错误。

1.2 理解CUDA、cuDNN、PyTorch三者的关系，减少版本焦虑

这里我得花点篇幅讲清楚一个很多新手搞混的概念。在 PyTorch 环境里，有三样东西和“GPU加速”有关：

• NVIDIA显卡驱动：运行在系统底层，负责和显卡硬件通信；
• CUDA Toolkit：包含编译器和运行库，PyTorch 需要它提供的库函数来调用GPU；
• cuDNN：深度神经网络的加速库，PyTorch 默认会捆绑一个版本。

而实际安装 PyTorch 时，你做的操作是什么？用pip install torch装的那个大包里面，其实已经包含了一套 CUDA runtime 和 cuDNN，不需要你再手动去系统层面装一套 CUDA Toolkit。这也是为什么我只强调“看驱动支持的最高CUDA版本，再反推选择哪个PyTorch安装包”，而不是叫你去单独下载CUDA安装包的原因。

当然有些场景确实需要完整安装 CUDA Toolkit，比如你要编译自定义的CUDA算子、用nvcc编译扩展，这时才需要去官网下载和驱动版本匹配的 Toolkit 装到系统里。但对于绝大多数跑深度学习模型场景，直接用 PyTorch 自带的 CUDA runtime 就足够了，还能避免系统里装多个CUDA版本导致的环境混乱。

1.3 确认已装NVIDIA驱动，必要时手动安装驱动

很多服务器拿到手，系统是别人装的，可能根本没有NVIDIA驱动。验证方法就是跑nvidia-smi，如果提示command not found，先别急，看看/dev/nvidia*设备节点是否存在：

ls /dev/nvidia*

如果设备节点存在，只是命令不在系统 PATH 里，说明驱动可能装了，需要添加环境变量或者安装nvidia-utils之类的工具包。如果设备节点根本不存在，那大概率是驱动没装或者内核模块加载失败，这种情况就得先处理驱动。

以 Ubuntu/Debian 系为例，装驱动最稳妥的方式是通过包管理器安装，而不是去NVIDIA官网下载.run文件硬装：

# 先查看推荐的新驱动版本 ubuntu-drivers devices # 一键安装推荐驱动（会同时安装 nvidia-driver-xxx） sudo apt update sudo apt install -y nvidia-driver-535 sudo reboot

装完重启再跑nvidia-smi，看到类似下面的输出就说明驱动工作了：

+---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.154.05 Driver Version: 535.154.05 CUDA Version: 12.2 | +---------------------------------------------------------------------------------------+

如果是 CentOS/Rocky Linux 这类系统，装驱动会稍微麻烦点，通常需要先把内核开发包和 gcc 装好，再借助dkms安装。这种情况下建议直接参考发行版官方文档，或者请运维同事协助，别自己在生产服务器上乱搞内核模块。

小节要点：服务器配置 PyTorch 环境，第一步不是装 PyTorch，而是查驱动。nvidia-smi驱动的CUDA版本决定你能选的PyTorch版本上限；没有驱动一切免谈。

2. 构建Python隔离环境：为什么我推荐Miniconda而不是直接pip装

服务器上通常不止跑一个项目，如果每个项目都直接把依赖装到系统 Python 里，很快就会遇到“A项目要 torch1.13，B项目要 torch2.1”的惨案。更麻烦的是系统很可能同时存在 Python 3.8 和 3.10，不同软件依赖不同Python版本，直接乱套。

2.1 virtualenv/venv与conda的选型对比

有人会问，我用python3 -m venv不也能隔离环境吗？能，但不推荐在服务器上作为主力方案，原因有几个：

• venv 创建的环境默认不隔离 CUDA 相关的系统库，配置GPU环境时容易和系统 Python 纠缠；
• conda 不光能管理 Python 环境，还能管理 CUDA Toolkit、cuDNN、MKL 这些非 Python 依赖，这对深度学习环境非常有用；
• conda 在安装大型二进制包（比如 torch、cudnn）时会自动处理依赖冲突，venv 做不到。

对比表格一下：

所以在服务器这种“要长期跑、多项目并存、需要GPU加速”的场景，我个人的习惯是：一律用 Miniconda 管理所有Python环境。不管你是做PyTorch、TensorFlow，还是单纯写点数据处理脚本，都放进conda环境里。

2.2 Miniconda安装的完整过程与目录规划

到 Miniconda 官网或国内镜像站下载对应架构的安装脚本。服务器如果是 x86_64 架构，选Miniconda3-latest-Linux-x86_64.sh；如果是ARM架构（比如华为鲲鹏服务器），选Miniconda3-latest-Linux-aarch64.sh。

这里有个实际经验：别把conda装到/root目录下，更别一路默认回车装在~目录后就完事。服务器上通常多个用户共用，装到/opt/anaconda这类公共目录更合适。但前提是当前用户有权限写这个目录，或者用sudo执行安装：

# 以root身份安装到/opt目录，允许所有用户使用 sudo sh Miniconda3-latest-Linux-x86_64.sh -b -p /opt/miniconda3

解释一下参数：-b表示静默安装，不交互；-p指定安装路径。装完之后，把conda初始化到全局环境变量里，让所有用户登录就能直接使用：

# 在/etc/profile.d/下新建一个脚本，写入环境变量 echo 'export PATH="/opt/miniconda3/bin:$PATH"' | sudo tee /etc/profile.d/miniconda.sh # 让配置立即生效 source /etc/profile.d/miniconda.sh # 验证成功 conda --version

接着执行conda init把conda基础环境写进每个用户的shell配置里，不然以后每次登录还得手动source：

conda init bash

这里注意一点：如果你安装时用的是sudo，conda init可能只对root用户生效。其他用户要使用conda，要么登录后手动source /etc/profile.d/miniconda.sh，要么在各自的~/.bashrc里加上路径。更好的做法是在/etc/skel/.bashrc里也写上初始化代码，这样以后新建用户时shell配置会自动包含conda路径。

2.3 conda加速配置：更换国内镜像源

服务器在国内的话，一定要换conda源，不换的话创建环境、安装包时速度真的能让你崩溃。网上有一堆换源教程，这里给出我实际在用的.condarc配置，存放在用户目录下：

cat > ~/.condarc << 'EOF' channels: - defaults show_channel_urls: true default_channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud EOF

这个配置对 conda-forge 和 pytorch 频道也做了镜像映射，之后直接用conda install pytorch torchvision torchaudio -c pytorch时，速度会快很多。

特别提醒：如果你用sudo执行 conda 命令，~/.condarc指的是 root 用户目录下的配置。普通用户使用conda时则会读取各自的~/.condarc。所以换源要对每个实际使用环境的用户都做一遍，或者直接把配置放到/etc/conda/.condarc全局路径下。

2.4 创建PyTorch专用虚拟环境，锁定Python版本

conda装好、源也配好了，接下来就是创建环境。这一步推荐隔离出一个独立的pytorch环境，不要用 conda 自带的 base 环境跑项目。原因很简单：base环境里你可能会装各种工具，依赖一多就容易和项目依赖打架，比如 base 里的OpenSSL版本变了，某个老项目就编译不过去了。

# 创建名为pytorch的环境，指定Python版本 conda create -n pytorch python=3.10 -y # 激活环境 conda activate pytorch

Python版本怎么选？我的经验是：

• PyTorch 2.x 官方全面支持 Python 3.9-3.12，选 3.10 或 3.11 最稳妥；
• 不要一上来就选最新的 Python 3.12，哪怕官方说支持，也可能有些老项目第三方库没跟上；
• 尽量不要选 EOL 的 Python 3.7 及以下，现在很多包已经不提供对应版本的轮子了。

另外建议在conda create时就把Python锁死，后面再用conda install python=3.11升级的话，容易触发大量依赖重装，得不偿失。

激活环境后，用python --version和which python确认一下，应该指向/opt/miniconda3/envs/pytorch/bin/python，这就说明隔离成功了。

3. PyTorch安装实操：CPU版还是GPU版，pip还是conda

环境创建好之后，重头戏来了：安装PyTorch。这一步的选择题很多：装CPU版还是GPU版、用pip装还是conda装、加哪个--index-url、要不要单独装CUDA Toolkit。下面我一个一个拆开讲。

3.1 区分CPU版与GPU版，避免白忙一场

先明确一个最常见的误区：pip install torch默认安装的是哪个版本？在没有额外指定--index-url的情况下，PyPI 上的torch包默认是包含 CUDA 支持的，也就是说装下来的是GPU版。但在某些平台或某些特殊索引源上，默认可能变成CPU版。

怎么确认装的是CPU版还是GPU版？方法很简单，进入环境后跑一句：

python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())"

如果输出类似2.1.0+cu121，说明是带CUDA的GPU版；如果输出2.1.0+cpu或根本没有+cu后缀，说明装的是CPU版。再配合torch.cuda.is_available()：

• 返回True：GPU版并且能正常识别到显卡；
• 返回False：要么装成了CPU版，要么驱动/版本不匹配。

如果你的服务器只是用来做数据处理、普通模型推理，或者没有NVIDIA显卡，那直接用CPU版就行，省心还不占空间。但正常训练模型的话，CPU版跑起来会让人怀疑人生，一定得用GPU版。

3.2 PyTorch官网安装命令的隐藏信息量

打开 PyTorch 官网（pytorch.org），首页会给你一个命令生成器，选择你的系统、包管理器、CUDA版本，自动生成安装命令。界面示例：

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

很多人直接复制这条命令去装，装完也能用，但这里有几个细节值得注意：

• --index-url指定的是 PyTorch 官方 wheel 源，不是默认的 PyPI。cu121表示这个源上都是 CUDA 12.1 对应版本的包；
• torchvision是视觉库，torchaudio是音频库。如果你只做CV，可以不装 torchaudio；只做NLP，也可以只装 torch 一个包。按需安装能省不少磁盘空间；
• cu121中的版本号要和nvidia-smi显示的驱动CUDA版本对应起来。比如驱动显示CUDA Version: 12.1，那选cu121或cu118都能用；如果驱动只支持到 11.4，那官网生成的默认命令大概率装完跑不起来。

3.3 为什么我更推荐用pip而不是conda装PyTorch

网上很多教程让用conda install pytorch torchvision torchaudio -c pytorch，我一开始也是这么干的，后来踩过几次坑，现在统一改用pip。原因主要有三个：

第一，版本同步速度。PyTorch 出新版的速度非常快，pip 的 PyPI 源基本当天就能跟上，但 conda 频道经常慢半拍，有时候一两个星期过去，conda上的torch还是旧版本。

第二，依赖控制更清晰。conda 安装 big packages 时需要做 SAT solver 依赖解析，经常会为了一个不相关的依赖把整个环境的包升降级，有时候还把Python版本给带偏了。pip 的行为相对简单直接，基本是“缺什么装什么”，很少出现那种装完一堆东西之后环境被改得面目全非的情况。

第三，国内下载速度。pip 可以直接指定镜像源，比如用清华源或阿里源，速度远比 conda 从官方频道拉包快。特别是 PyTorch 和 torchvision 这种几个GB的大包，用pip配镜像源基本能拉满带宽。

给出一份我实际用的安装命令，直接把 CUDA 版本和镜像源都指定好：

# 激活环境 conda activate pytorch # 用清华源安装PyTorch 2.1.0 + CUDA 12.1（GPU版） pip install torch==2.1.0 torchvision==0.16.0 torchaudio==2.1.0 \ --index-url https://download.pytorch.org/whl/cu121 \ --extra-index-url https://pypi.tuna.tsinghua.edu.cn/simple

解释一下：--index-url指定 PyTorch 官方源，确保拿到的是带CUDA的GPU包；--extra-index-url加上清华源是为了让 torch 的依赖（比如 numpy、pillow、sympy 这些）能快速下载。如果不用--extra-index-url，你会发现主包下载飞快，但依赖包去官方源一个个拉，慢得离谱。

如果服务器没有外网访问条件（某些内网环境），你需要提前在同事电脑上把.whl文件下载好，再传到服务器上用pip install /path/to/torch.whl离线安装。这种方式我试过很多次，只要版本选对，效果和在线装完全一样。

3.4 安装完成后进行实用验证

装完不要急着欢呼，先把验证跑一遍。我一般会用一条命令字符串一起测：

python - << 'EOF' import torch print("PyTorch 版本:", torch.__version__) print("CUDA 是否可用:", torch.cuda.is_available()) if torch.cuda.is_available(): print("GPU 名称:", torch.cuda.get_device_name(0)) print("当前显存使用:", torch.cuda.memory_allocated() / 1024**2, "MB") x = torch.rand(3, 3).cuda() y = torch.rand(3, 3).cuda() print("GPU 矩阵运算结果:", x + y) EOF

如果输出中 CUDA 可用，并且矩阵运算没有报错，说明 PyTorch 的 GPU 链路已经通了。另外建议再用nvidia-smi实时看一眼进程的显存占用，确认程序真的把显存用起来了。很多时候torch.cuda.is_available()返回 True，但实际没跑在GPU上，一查发现是环境变量没配好，这种情况我在后面问题排查章节细说。

4. 远离开发困境：VSCode远程开发与Jupyter Lab的服务器连接

PyTorch 环境配好了，接下来就是日常开发。服务器上直接在终端里跑python train.py当然可以，但你要调试代码、查看变量、可视化数据，总不可能在纯命令行里硬凑。这里推荐两种主流方式：VSCode Remote SSH 和 Jupyter Lab。

4.1 VSCode Remote SSH打造本地写码远端训练的工作流

VSCode 的 Remote-SSH 扩展是现在服务器开发的事实标准。安装方法：本地VSCode装好Remote - SSH扩展后，按Ctrl+Shift+P打开命令面板，输入Remote-SSH: Connect to Host，填入你服务器的SSH连接信息，比如ssh user@192.168.1.100，回车即可登录。

第一次连接后，VSCode 会在服务器上自动安装一个 server 端组件。如果服务器是内网环境，可能下不动这个组件，这时候需要在本地下载 VSCode Server 压缩包，手动传到服务器指定目录解压，具体路径是~/.vscode-server/bin/<commit-id>/。这个问题在网络受限环境时很常见，手动传一次后续就不用了。

连接之后，最关键的一步是让 VSCode 使用 conda 里的 Python 解释器。打开一个.py文件，按Ctrl+Shift+P，选择Python: Select Interpreter，然后选/opt/miniconda3/envs/pytorch/bin/python即可。选完之后，调试、代码补全、终端激活环境都会自动使用正确解释器。

再说说免密登录，这个对体验影响很大。每次输密码虽然不麻烦，但频繁重连的时候很烦。配置方式：

# 本地生成密钥（没有的话先执行） ssh-keygen -t rsa -b 4096 # 把公钥拷贝到服务器，让服务器端信任你 ssh-copy-id user@192.168.1.100

执行完上述操作之后，再连接服务器就不用输密码了。同时你还可以在VSCode的配置文件~/.ssh/config里给服务器起个简短别名：

Host my_server HostName 192.168.1.100 User admin Port 22

之后连接时直接输my_server就行，不用记IP、用户名和端口。

4.2 Jupyter Lab的远程启动与访问密码配置

VSCode 适合写完整项目，但遇到需要看着数据可视化边改边跑的活儿，Jupyter Lab 更顺手。在 conda 环境里装好 Jupyter 后，启动时注意几个关键参数：

conda activate pytorch # 生成jupyter配置文件（首次运行） jupyter lab --generate-config # 设置访问密码（会写入~/.jupyter/jupyter_server_config.json） jupyter server password

然后修改配置文件~/.jupyter/jupyter_server_config.py：

c.ServerApp.ip = '0.0.0.0' # 允许所有IP访问（按需修改） c.ServerApp.port = 8888 c.ServerApp.open_browser = False c.ServerApp.allow_remote_access = True

启动：

jupyter lab --no-browser

本地浏览器打开http://服务器IP:8888，输入之前设置的密码就能进入。这里有个安全提醒：允许远程访问后，等于给服务器开了一个明文端口，建议使用密码加密并且不要把端口暴露到公网。如果你在云服务器上，记得在安全组里限制访问来源IP，只放行你自己的IP。

4.3 多用户场景下的conda环境共享与权限管理

服务器不像个人电脑，经常有多个人一起用。有时候我用pytorch环境，同事也用，但大家装包的习惯不一样，容易把环境搞乱。我比较推荐的做法是：

• 让管理员统一创建环境并安装基础依赖；
• 普通用户只通过conda activate使用，不轻易往里装新包；
• 如果确实需要装新包，优先在当前项目目录用pip install --user或者单独建环境，避免污染公共环境。

另外，多个用户使用同一个 conda 安装目录时，如果都用同一个pytorch环境，有个注意点：conda环境的写权限归属于创建者。如果普通用户想往公共环境里装包，得让管理员用conda run -n pytorch pip install xxx执行，或者给环境目录设置用户组写权限：

# 给pytorch环境目录递归设置用户组写权限 sudo chgrp -R developers /opt/miniconda3/envs/pytorch sudo chmod -R g+w /opt/miniconda3/envs/pytorch

这样developers组的成员就能共同维护这个环境了。如果只想让少数几个特定用户有权修改，也可以把developers组替换成实际的用户组或用户名。

5. 常见问题与排查技巧实录：从驱动到环境变量逐个击破

这部分内容是我在配置各种 Linux 服务器过程中积攒下来的问题清单，基本覆盖 80% 以上的踩坑场景。遇到报错时，建议按下面思路一步步排查，而不是盲目卸载重装。

5.1 import torch 报 libtorch_cuda.so 错误

这是一个非常典型的问题，报错信息大概长这样：

ImportError: libtorch_cuda.so: cannot open shared object file: No such file or directory

出现这个问题的原因通常有两种：

• 你装的是 GPU 版 PyTorch，但系统的动态库加载路径里找不到 PyTorch 自带的.so文件；
• 某些系统库的版本和 PyTorch 自带的库不兼容。

排查第一步，用ldd查看 torch 扩展模块依赖了哪些动态库：

python -c "import torch; print(torch.__file__)" # 进入torch安装目录，找到lib目录 ldd /opt/miniconda3/envs/pytorch/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so | grep "not found"

如果看到一堆not found，很大概率是系统缺少某些CUDA相关的库，或者路径没有正确包含。这时检查环境变量：

echo $LD_LIBRARY_PATH

如果为空，把 CUDA 库路径补上试试：

export LD_LIBRARY_PATH=/opt/miniconda3/envs/pytorch/lib/python3.10/site-packages/torch/lib:$LD_LIBRARY_PATH

如果这样能解决，那就把这条加到~/.bashrc里。但注意：如果是正常通过conda环境跑，一般不需要手动设LD_LIBRARY_PATH，设了反而可能干扰其他软件。这个解法只是临时手段。

5.2 torch.cuda.is_available() 返回 False 的最全排查看板

这个问题的原因不像上面那么直接，我把可能的原因按频率排序：

其中有个很容易忽略的坑：你明明之前装过 CPU 版的 torch，后来用 pip 安装了 GPU 版，结果pip install torch时发现“已安装”而不重新覆盖。这种时候进程列出已安装版本，强制重新安装：

pip list | grep torch pip install --force-reinstall torch==2.1.0 --index-url https://download.pytorch.org/whl/cu121

另一类坑是 conda 环境恢复了旧状态。如果你用了conda install装东西，conda 可能会把 torch 回滚到 CPU 版本，因为 conda 在解析依赖时会重新评估所有包版本，很有可能在某个步骤悄悄把包版本变掉。所以装完 PyTorch 后，如果再用 conda 安装其他库，建议装完后再验证一次torch.cuda.is_available()，我踩过好几次这种坑。

5.3 网络下载慢或者超时的应对策略

服务器在国内的话，直接从 PyPI 或者 PyTorch 官方源下载大包，速度随缘，还经常超时。没有好网络环境的时候，我的办法有三个：

第一，pip 使用清华源或者阿里源作为主要下载源：

pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple pip config set global.extra-index-url https://download.pytorch.org/whl/cu121

这样 pip 默认走清华源，同时保留 PyTorch 官方源作为补充。不过要注意，如果两个源里存在同名包，pip 有可能会从任意一个源拉取，这会导致 GPU 版和 CPU 版混用。稳妥做法还是前面提过的：安装 torch 主包时用--index-url显式指定官方源，其他依赖走镜像。

第二，使用wget提前下载 wheel 包再本地安装。比如想装 torch 2.1.0 + cu121，先用迅雷或者其他下载工具把对应的.whl文件拉下来，再在服务器上执行：

pip install ./torch-2.1.0+cu121-cp310-cp310-linux_x86_64.whl

这种方法最适合大包。我每次搭环境都习惯先把包下载好，再传到服务器装，避免反复超时。

第三，如果是在虚拟环境里遇到Collecting torch卡住不动，有些情况不是网速问题，而是 DNS 解析慢。可以临时指定使用公共 DNS：

sudo vim /etc/resolv.conf # 添加 nameserver 223.5.5.5

5.4 conda init 后 shell 仍不识别 conda 命令

有时候装完 conda，却提示conda: command not found。最常见原因是安装时用了sudo -s切换到 root，但 conda 初始化写入的是 root 的.bashrc，其他用户没有执行路径。

排查流程：

# 确认conda是否真的装好 ls /opt/miniconda3/bin/conda # 手动执行一次 /opt/miniconda3/bin/conda --version # 如果正常，补上环境变量 echo 'export PATH="/opt/miniconda3/bin:$PATH"' >> ~/.bashrc source ~/.bashrc

另外，conda init默认只对当前 shell 用户的 rc 文件生效。如果是新创建的用户，需要复制/etc/skel里的配置，或者在新用户 shell 里手动执行conda init bash。这点在多用户服务器上特别要注意。

5.5 显存不足与多进程冲突，不要全赖在环境头上

环境配好之后开始跑程序，报CUDA out of memory或者RuntimeError: CUDA error: out of memory，很多人第一反应是“显存不够”。确实，如果模型很大、显存很小，那是硬伤。但很多时候是你忘了释放之前的显存，或者多个进程同时占用了同一块卡。

排查方法：

# 查看当前哪些进程在占用GPU nvidia-smi # 查看具体是哪个python进程占了显存 fuser -v /dev/nvidia*

如果是自己之前的残留进程，直接kill掉。如果多人共用服务器，最好在代码里指定用哪张卡：

CUDA_VISIBLE_DEVICES=0 python train.py

这样即使旁边的人把你的两张卡都占了，你只要指定空闲的卡，就不会互相影响。也可以在代码开头写：

import os os.environ['CUDA_VISIBLE_DEVICES'] = '0,1' # 指定使用第0、1号GPU

另外还有一个常见的“坑”，就是 PyTorch 的缓存机制。即使程序退出，某些情况下显存不会立刻释放，尤其是有 CUDA 异步操作时。这时候过几分钟再nvidia-smi看看，或者直接重启一下相关服务，能解决很多奇怪的问题。

5.6 cuDNN相关的启动报错

报错信息类似：

RuntimeError: cuDNN error: CUDNN_STATUS_NOT_INITIALIZED

这个一般有三个原因：

• GPU驱动版本过旧，和 cuDNN 要求不匹配；
• PyTorch 自带的 cuDNN 和驱动冲突；
• 系统里手动安装了旧版 cuDNN，污染了环境。

前面说过，正常用 pip 安装的 PyTorch 自带 cuDNN，不需要单独装。如果你曾经给系统手动装过 cuDNN，建议检查一下/usr/local/cuda里的版本，必要时用 conda 环境变量把库路径强制指向 conda 环境内的版本。如果还是不行，就升级 NVIDIA 驱动到官方要求的最低版本。

我遇到过一次特别诡异的情况：同一份代码，在A服务器（驱动535）上跑正常，在B服务器（驱动470）上报 cuDNN 错误，最后排查发现B服务器驱动版本太老，PyTorch 2.1 自带的 cuDNN 需要新驱动支持。解决办法很简单，升级驱动到535以上，或者把 PyTorch 换成老版本。遇到跨服务器的环境迁移问题时，最好先看一眼两台机器的驱动版本，能省很多排查功夫。

6. 关于环境迁移与复现：把conda环境固定成可交付的状态

环境配好、代码能跑了，这只是第一步。过两个月后再来一个新同事，或者换一台训练机器，总不能让人家再从头踩一遍坑吧？所以环境和依赖的“可复现性”非常重要，这里分享几个实用做法。

6.1 用environment.yml与requirements.txt双重固定

PyTorch 相关项目通常用两个文件同时管理依赖：

第一个是 conda 环境的environment.yml，记录主要依赖和 Python 版本：

name: pytorch channels: - defaults dependencies: - python=3.10 - pip - pip: - torch==2.1.0 - torchvision==0.16.0 - torchaudio==2.1.0 - numpy - pandas - scikit-learn

创建环境时：

conda env create -f environment.yml

第二个是精确到哈希的requirements.txt，方便在别人已有 conda 环境里精确恢复版本：

pip freeze > requirements.txt

恢复：

pip install -r requirements.txt

pip freeze会把所有依赖及其精确版本记录下来，甚至包括一些通过镜像源安装的包。这个文件基本能做到“还原现场”。

6.2 conda-pack打包整个环境离线迁移

有时候目标机器没有外网，连镜像源都访问不到，环境文件装不了。这种场景我推荐用conda-pack，把整个环境压缩成一个压缩包，拷贝过去直接解压就能用。使用方法：

# 源机器上 conda install conda-pack -c conda-forge conda pack -n pytorch -o pytorch_env.tar.gz # 拷贝到目标机器，解压后直接作为python目录使用 mkdir -p /opt/pytorch_env tar -xzf pytorch_env.tar.gz -C /opt/pytorch_env source /opt/pytorch_env/bin/activate

这里注意：conda-pack 打包的是 Python 环境和相关库，不包含 NVIDIA 驱动。目标机器的驱动和 CUDA 版本仍然要满足 PyTorch 的要求。所以迁移完之后，第一件事还是跑一遍分快验证，确定torch.cuda.is_available()正常。

6.3 定时备份环境清单，让团队环境随时可重建

我个人的习惯是，每次给项目配好环境之后，立即把以下三样东西保存到项目仓库里：

• environment.yml
• requirements.txt
• 一段简短的 README，写清楚服务器驱动版本、CUDA 版本、conda 环境名

这样任何人拿到项目代码，先按 README 里的说明配环境，十几分钟就能复现，不用再猜“之前用的哪个版本”。团队协作时，这算是省心省力的基础操作。

7. 写在最后的几条实用经验

PyTorch 环境配置这件事，说难不难，说简单也不简单。折腾过几十次之后，我形成了一套固定的操作顺序，这里分享给大家：

第一，不要贪新。新版本的 PyTorch、新版本的 Python、新版本的CUDA，看起来很美，但你可能要花大量时间填别人踩过的坑。服务器是拿来跑实验的，不是拿来追新版本的。稳定优先，等新版本过了半年、大家用的人都多了，再考虑升级。

第二，配置文件做好注释。.condarc、~/.bashrc、jupyter_server_config.py这些文件，建议把关键配置项后面的作用写清楚。不然三个月后你自己回来看，完全想不起来当时为什么这么写。

第三，装完环境立刻验证，别攒到项目启动才跑。每次装完 PyTorch，哪怕只是执行一句python -c "import torch; print(torch.cuda.is_available())"，也能把80%的问题提前暴露出来。我见过太多人装完直接开训练，跑了半天才报CUDA错误，白等。

第四，服务器上尽量少用 root 跑日常训练。创建一个普通用户，让代码和文件都属于普通用户，能避免很多误操作。如果真的要装系统级软件，用 sudo 临时提权就够了。

最后分享一个我自己的小习惯：每次配完环境都会在项目根目录放一个check_env.sh，内容就是打印torch版本、CUDA是否可用、GPU卡号、驱动信息。后期如果遇到“为什么我的训练变慢了”“为什么某天开始就报错”这种问题，先跑一遍这个脚本，很多环境变更都能快速发现。配置环境不算难，但把它配得明明白白、可维护可复制，才是真正给后面的工作省时间。