简介：一份面向Linux初学者与PyTorch入门者的环境搭建实战文档，系统讲解在Ubuntu上从零配置深度学习开发环境的核心流程。内容覆盖阿里云/清华镜像源替换、基础构建工具安装、Anaconda的下载安装与卸载、多用户权限授予、CUDA与显卡驱动部署、conda虚拟环境创建、PyTorch及其常用依赖库安装，并对安装过程中的典型报错给出排查思路，同时补充了PyCharm的安装方式和Jupyter Notebook的启动方法。全文以具体命令行操作和界面临界步骤为主线，关键环节配有截图辅助，适合具备一定Linux命令基础但希望快速搭建可用环境的开发者参考。资源为单份PDF文档，体积3.05MB，内容梳理成章便于按步骤翻阅；已有277人学习，对于需要独立完成GPU版PyTorch配置的科研与工程场景具有实用参考价值。
1. 别急着 pip install torch，Linux 上 PyTorch 的版本矩阵才是关键
刚拿到一台 Linux 服务器时，最容易产生的一个错觉是：PyTorch 装不上是网络问题。实际上多数失败发生在版本矩阵上——Anaconda 的 Python 版本、显卡驱动支持的 CUDA 上限、PyTorch 编译时绑定的 CUDA runtime，以及 PyCharm 和 Jupyter 选中的解释器，这四者经常各说各话。尤其是pip install torch只从 PyPI 装 CPU 版，而 GPU 版必须走官方指定索引；conda 和 pip 对 CUDA 依赖的解析又完全不同。这篇文章从 Anaconda 创建隔离环境开始，逐步把 CUDA 版本对齐、PyCharm 解释器配置和 Jupyter kernel 绑定讲清楚。适合刚接手 Linux 服务器、想从 Windows 深度学习开发栈切换过来的人。读完你至少能在十分钟内判断出环境到底坏在哪一层。
2. 用 Anaconda 在 Linux 上创建 PyTorch 独立环境
2.1 为什么不用系统 Python 直接跑 PyTorch
Linux 发行版自带的python3通常和包管理器深度绑定：Debian/Ubuntu 上 apt 依赖它，CentOS 上 yum 也依赖它。如果你直接把 PyTorch、numpy、opencv 装进系统 Python，很容易覆盖掉系统需要的依赖版本，最坏的结果是apt或图形界面都开始报错。深度学习项目对依赖版本非常敏感，同一个环境里跑两个项目时，一个要 numpy 1.x，另一个要 numpy 2.x，冲突几乎无法调和。
Anaconda 的价值不是它自带多少科学计算包，而是它把整个 Python 运行时放在$HOME/anaconda3/envs下，每个环境互不可见。你可以conda create -n pytorch python=3.11创建一个 GPU 训练专用环境，再创建python=3.12环境跑最新脚本，两个环境之间不存在覆盖关系。常见的做法是给每个项目单独建环境，而不是所有项目共用base。
提示：
base环境别装 PyTorch。base 一坏，所有 conda 子环境的管理都会受影响。宁可每次手动激活，也不要图方便全塞在 base 里。
2.2 Linux 下 Anaconda 安装脚本的正确打开方式
在 Linux 上安装 Anaconda，我一般不会用包管理器，而是直接从 Anaconda 官网下载.sh安装脚本。下载前先确认是 Linux x86_64 版本，ARM 服务器要选对应版本，否则安装脚本会在第一步直接报错或不兼容。下载完的脚本放在家目录，不要放在/tmp，部分服务器对/tmp有noexec挂载选项，会导致安装器没有执行权限。
先做一次校验和检查，网络中断产生的半截文件是最浪费时间的坑：
sha256sum Anaconda3-*-Linux-x86_64.sh # 输出一串 64 位哈希，去 Anaconda 官网比对 Digest 值确认无误后执行安装。交互式安装全程按回车即可，最后会问是否执行conda init，一定选 yes。如果你不想安装过程被交互打断，也可以用静默安装：
bash Anaconda3-*-Linux-x86_64.sh -b -p $HOME/anaconda3 # -b 表示静默安装 # -p 指定安装目录，建议放在 home 盘，避免跨分区问题 source $HOME/anaconda3/bin/activate参数说明：-b是无提示模式，适合脚本化部署；-p把安装路径固定下来，之后 conda env 都会创建到这个目录下的envs/里。安装完成后重新登录终端，或者source ~/.bashrc，再用conda --version验证。我通常马上执行conda config --set auto_activate_base false，这样终端不会一打开就自动进入 base，避免整个 shell 环境被 Python 影响。
2.3 创建环境时锁定 Python 版本和 PyTorch 下载源
创建 PyTorch 专用环境时，不要直接conda create -n pytorch，那样默认 Python 版本经常不是你想要的。PyTorch 官方在编译 wheel 时对 Python 版本有范围限制，比如 2.x 系列通常支持 3.8 到 3.12。我会显式锁定一个主流版本，例如 3.11：
conda create -n pytorch python=3.11 -y conda activate pytorch python --version # 确认当前环境是 Python 3.11.x-n pytorch是环境名，python=3.11是要求 conda 解析器精确定位 Python 3.11 系列，-y跳过确认提示。这个解析过程会做一次完整依赖回溯，国内网络慢时容易卡住，常见做法是先配置 conda 镜像源再创建环境。不过环境创建成功后，我建议安装 PyTorch 时绕过 conda，直接用 pip 走官方 wheel 索引：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这段命令里--index-url是核心：它让 pip 去 PyTorch 官方索引而不是 PyPI 拉取 GPU 版 wheel。默认 PyPI 的torch在 Linux 上是 CPU 版，很多人装完才发现torch.cuda.is_available()一直是 False，原因就是没带这个参数。cu121表示 wheel 内部绑定了 CUDA 12.1 runtime，和依赖一起打包，不需要你系统里已经装好 CUDA toolkit。
下表是我常用的 conda 环境管理命令，初学阶段记住这几个就够：
| 命令 | 作用 | 使用场景 |
|---|---|---|
conda env list | 列出所有环境及路径 | 确认环境是否创建成功 |
conda activate pytorch | 激活指定环境 | 每个终端开工前第一步 |
conda deactivate | 退出当前环境 | 切回系统 shell |
conda list | grep torch | 查看环境中 torch 相关包 | 排查装错包 |
conda env remove -n pytorch | 删除整个环境 | 环境坏了重来 |
conda clean -a | 清理所有缓存 | 缓存损坏或磁盘不足时 |
3. CUDA 版本对齐：先查驱动，再装 PyTorch，最后补 cuDNN
3.1 nvidia-smi 显示的是驱动支持上限，不表示系统已装 CUDA
Linux 下查 GPU 一定先用nvidia-smi，没有这个命令说明 NVIDIA 驱动根本没装好，后面 CUDA 和 cuDNN 都无从谈起。执行后你会看到两个关键数字：Driver Version和CUDA Version。很多新手的误区是看到右上角写着 CUDA 12.4，就以为系统里已经装好了 CUDA 12.4。
其实那个值表示当前显卡驱动最高能支持的 CUDA 版本，它是驱动 API 级别的上限，不等同于/usr/local/cuda里存在可用的 toolkit。PyTorch 通过 wheel 带来的 CUDA runtime 是用户态库，只要驱动版本不低于它要求的版本就能跑。
我一般会这样检查：
nvidia-smi # Driver Version: 550.54.15 CUDA Version: 12.4 nvcc --version # 如果 command not found，说明系统没有 CUDA toolkit，或没加入 PATH如果nvcc找不到，但 PyTorch 能正常用 GPU，这反而是正常现象：因为 PyTorch 自带了一套完整的 CUDA runtime，不需要外部 toolkit。nvcc只在你想自己编译 CUDA 扩展、或从源码重新编译 PyTorch 时才必须存在。
3.2 pip wheel 自带的 CUDA runtime 与系统 toolkit 怎么区分
PyTorch 官方发布的 GPU wheel 内部包含libcudart、libcublas、libcudnn等库，安装后放在torch/lib目录里。所以对于 90% 跑模型训练和推理的人来说，不需要预先单独安装 CUDA toolkit 或 cuDNN。
如果你用 conda 额外执行conda install cudatoolkit=11.7，反而可能出现两套 CUDA runtime 同时生效的情况：PyTorch 库内部加载它自带的那套，而某些自定义 C++ 扩展使用系统那套，版本不一致直接导致undefined symbol。这个报错在 Linux 上非常典型，网上搜索的时候经常和cuda迁移一起出现。
常见做法的建议是：跑纯 PyTorch 模型，不要手动装 cudatoolkit；只有在编译torchvision的 CUDA extension、RAPIDS 或需对接 TensorRT 时才需要完整的 toolkit。如果你确实要装，用系统包：
export CUDA_HOME=/usr/local/cuda export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH这几行把 CUDA toolkit 的bin和lib64暴露给编译器。LD_LIBRARY_PATH最关键，漏掉它后nvcc -o编译出的程序运行时找不到libcudart.so。
3.3 多版本 CUDA 的切换：不要动 /usr/local/cuda 软链接
很多服务器已经装了 CUDA 11.8 又装了 12.1，两个目录同时存在于/usr/local下。千万不要随手删掉其中一个，因为你不知道当前跑着的 PyTorch 到底链接到哪套库。正确做法是查看现有版本：
ls -l /usr/local/ | grep cuda # lrwxrwxrwx 1 root root 21 /usr/local/cuda -> cuda-12.1系统里的/usr/local/cuda是一个软链接，指向当前默认版本。如果只影响自己当前 shell，直接修改CUDA_HOME和 PATH 即可；如果想改系统默认，再切换软链接：
sudo rm /usr/local/cuda sudo ln -s /usr/local/cuda-11.8 /usr/local/cuda export CUDA_HOME=/usr/local/cuda export PATH=$CUDA_HOME/bin:$PATH缺点是每次都要 export。我会把这两行 export 写进~/.bashrc，不同项目需要不同 CUDA 时再用一个函数按项目动态设置。PyTorch 对多版本 CUDA 的容忍度很高，因为它在运行时不读取CUDA_HOME，只加载自带 runtime；但只要你编译扩展，环境变量就必须和 PyTorch 的 CUDA 版本一致。
3.4 cuDNN 不是必须装的，但版本必须可查
pip 安装的 PyTorch 自带 cuDNN，但 cuDNN 版本不一定和 PyTorch 的 CUDA 版本严格对应，所以验证环境时优先查运行时实际加载的 cuDNN：
import torch print(torch.backends.cudnn.version())输出是一串整数，比如 8902 表示 cuDNN 8.9.2。这个数值是二进制 ABI 的一种标记，网上说的 cuDNN 版本不匹配，通常是指代码里引用了比你系统安装版本更高的符号，而 pip wheel 自带 cuDNN 恰好避免了这个问题。
如果你的应用确实需要系统级 cuDNN，比如编译 TensorRT 或源码编译 TVM，用 conda 安装会更省事：
conda activate pytorch conda install cudnn -c conda-forge不指定版本号让 conda 自己解析时，它会选与当前环境 CUDA 兼容的默认版本。如果安装过程中报gzip: stdin: invalid compressed>conda activate pytorch jupyter notebook
这样新建的 notebook 就是 PyTorch 环境，最简单直接。但有时你会想从 base 或 JupyterHub 启动，再切换 kernel，这时就需要手动注册：
conda activate pytorch python -m ipykernel install --user --name pytorch --display-name "PyTorch GPU" jupyter kernelspec list这里--name pytorch是 kernel 的内部标识，--display-name "PyTorch GPU"是 Jupyter 界面下拉菜单里显示的名字。--user把 kernel 注册到当前用户的~/.local/share/jupyter/kernels，不需要 sudo。注册完刷新 Jupyter 页面，在Kernel | Change Kernel里就能看到新选项。
如果在 Jupyter 里import torch后torch.cuda.is_available()返回 False，但终端里返回 True，先确认sys.executable：
import sys print(sys.executable)路径里如果不是anaconda3/envs/pytorch/bin/python，说明 notebook 还在用旧的 kernel，而不是显卡坏了。
PyCharm 常见报错及应对：
| 现象 | 原因 | 处理方式 |
|---|---|---|
| 运行按钮和 Terminal 结果不一致 | Debug 配置解释器与 Terminal 激活环境不同 | 检查 interpreter 是否指向envs/pytorch/bin/python |
No module named torch | 解释器指向系统 python | 在 Settings 里切换到 conda env |
| CUDA unavailable after PyCharm run | PyCharm 环境变量没有继承 bashrc | 为运行配置添加CUDA_VISIBLE_DEVICES=0临时验证 |
5. 安装完成后先跑这五个探针，再开始训练
环境搭得好不好，不要在训练脚本里试错。我会先准备一个探针脚本，把 PyTorch 版本、CUDA 构建版本、GPU 可用性、设备数量、cuDNN 版本一次性打出来：
python - <<'EOF' import torch print("torch:", torch.__version__) print("cuda build:", torch.version.cuda) print("cuda available:", torch.cuda.is_available()) print("device count:", torch.cuda.device_count()) if torch.cuda.is_available(): print("device name:", torch.cuda.get_device_name(0)) print("cudnn version:", torch.backends.cudnn.version()) x = torch.randn(1024, 1024, device="cuda") y = torch.mm(x, x) torch.cuda.synchronize() print("gpu compute ok") EOF最后两步torch.mm和torch.cuda.synchronize()不可省略：torch.cuda.is_available()为 True 只能说明驱动和 runtime 能握手，真正做一次矩阵运算后才能确认 cuDNN 和显存管理链路正常。synchronize()让 CPU 等待 GPU 运算结束，避免异步执行下的假通过。
确认训练能跑起来后，再开一个终端执行watch -n 1 nvidia-smi，观察显存和利用率是否变动。如果显存持续增长而不释放，也要在探针里加入torch.cuda.empty_cache()手动清理。另一个排查技巧是查看「谁在占显卡」：
nvidia-smi --query-compute-apps=pid,used_memory --format=csv fuser -v /dev/nvidia*第一行列出正在占用 GPU 的进程 PID 和显存，第二行能直接看到 PID 对应的命令行。这是排查多用户服务器上显存不足最快的手段，比ps aux | grep python准确得多。
这套探针我会写成一个check_env.py放在项目根目录，每台新机器第一件事就是跑它。它替你回答了一个最经典的问题：驱动版本够不够、PyTorch 是否 GPU 版、cuDNN 是否可用。在这三点确认前，不要开始写模型训练代码，那样只会让你在报错里反复怀疑人生。把探针结果和nvidia-smi驱动版本放在一起对比，能解决 Linux 下 PyTorch 环境 80% 以上的"装完跑不了"问题。
本文还有配套的精品资源，点击获取
