新机器到手Ubuntu 装好敲下nvidia-smi看到显卡型号的那一刻心里踏实了一半紧接着pip install torch一行import torch; torch.cuda.is_available()甩回来一个False剩下那一半踏实也没了。这个场景我见过太多次自己也踩过不止一遍。Ubuntu 配置深度学习环境TensorFlow 和 PyTorch看起来只是几条安装命令的事真正耗时间的地方全在版本矩阵、环境隔离以及那些互相矛盾的搜索结果上——有人说必须装系统 CUDA有人说完全不用有人坚持用 conda有人说 pip 才是正路。这篇内容面向刚拿到 Linux 机器、或者准备把训练环境从 Windows 搬到 Ubuntu 的人也适合已经装完但一直没跑顺、想搞清楚为什么这么配的读者。我会把驱动、CUDA、conda 环境、TensorFlow 与 PyTorch 各自的安装路径、验证方法和高频报错串成一条完整链路每一步都说清楚背后的取舍而不是丢一堆复制粘贴的命令给你。1. 先把Ubuntu这层地基摸清楚版本、显卡与虚拟机的三条岔路装环境之前有些决定是一次性的选错了后面返工成本极高。这一节先解决三件最容易被忽略的事装哪个 Ubuntu、显卡到底有没有被系统认出来、以及要不要在虚拟机里干这件事。1.1 选LTS还是追新版以及桌面版和Server版的取舍我的建议很直接优先选 LTS 版本。写这篇文章的时候22.04 LTS 和 24.04 LTS 都是稳妥选择前者生态更老练、各种教程和第三方包的踩坑记录最全后者内核和驱动源更新对新显卡比如 40 系之后的新架构支持更省心。中间那些非 LTS 的短期版本问题往往出在内核太新上NVIDIA 驱动需要 DKMS 在本地重新编译内核模块内核一升级就可能编译失败然后你就得对着黑屏或TTY里的一堆日志排查。用 LTS 不等于守旧而是把和驱动较劲这件事的概率降到最低。桌面版还是 Server 版取决于这台机器最终干什么。自己桌面上边写代码边看结果桌面版更舒服中文输入法、浏览器、截图工具都是现成的纯粹的训练机、放机房里只通过 SSH 连Server 版更干净没有图形界面意味着显存不会被桌面环境吃掉一块也不会有休眠、自动更新这类打断训练的行为。有个细节值得提一句Server 版默认没有图形界面装 NVIDIA 驱动时反而少了很多和显示管理器冲突的麻烦。提示如果你打算长期用这台机器安装系统时就考虑好磁盘分区。conda 环境和数据集非常吃空间把/分区分大一点或者单独挂一块盘给环境目录后面会省很多事。1.2 确认显卡真的被系统看见了这一步很多人跳过直接开始装驱动结果驱动装完了发现根本检测不到卡。三条命令足够确认lspci | grep -i -E nvidia|vga nvidia-smi ls /dev/nvidia*第一条列出 PCI 设备能查到 NVIDIA 的型号说明硬件层面没问题第二条如果报command not found说明驱动还没装这是正常的第三条在没装驱动时通常什么都不返回装完之后应该能看到/dev/nvidia0、/dev/nvidiactl、/dev/nvidia-uvm这些设备节点。真正需要警惕的是lspci里显示的是NVIDIA Corporation ... (rev a1)但nvidia-smi报No devices were found。这种情况十有八九是开源驱动 nouveau 还占着设备或者主板 BIOS 里显卡模式设置有问题比如笔记本的混合显卡模式。另一个隐蔽的坑是uEFI 安全启动没处理驱动模块没签名加载被拒绝表现同样是看不到设备——这个后面单独说。如果是笔记本双显卡Intel 核显 NVIDIA 独显机器可能默认走核显输出独显处于省电关闭状态。装完驱动后nvidia-smi能看到卡就算正常prime-select那套切换逻辑主要影响的是图形输出对跑训练没影响别被网上必须切到独显模式的说法带偏。1.3 虚拟机里跑深度学习的现实预期热词里虚拟机安装 Ubuntu出现频率很高这里必须说清楚预期。VMware、VirtualBox 这类常规虚拟机无法把物理显卡直通给 guest 系统你在里面装 NVIDIA 驱动是装不上的就算强行装了也用不了。所以虚拟机里搭出来的环境只能是 CPU 版本的 TensorFlow 和 PyTorch——用来学语法、跑跑小模型、验证代码逻辑完全够用但别指望它训练。判断自己是不是处在这个状态两条命令就够import torch print(torch.cuda.is_available()) # 虚拟机里基本是 False import tensorflow as tf print(tf.config.list_physical_devices(GPU)) # 基本是 []想要 GPU 直通得走 KVM VFIO 那条路需要主板支持 IOMMU、两块显卡一块给宿主机输出、一块直通给虚拟机配置门槛不低而且直通后的显卡在宿主机上就不能用了。真要用 GPU物理机装 Ubuntu、或者用双系统性价比远高于折腾直通。虚拟机的价值在于试错——分区、安装流程、驱动步骤都可以先在虚拟机里走一遍熟练了再上真机这个用法我是推荐的。2. 驱动与CUDA的版本矩阵为什么现在只需要装驱动这一节是我认为整篇文章里最值得读的部分。因为过去几年这个领域最大的变化就是pip 安装的 PyTorch 和 TensorFlow 已经把 CUDA 运行库打包进 wheel 了系统层面只需要一个足够新的显卡驱动。很多人还在按五年前的老流程装系统级 CUDA Toolkit然后把自己绕进系统一份 CUDA、conda 一份 cudatoolkit、wheel 里又带一份的三方混战里。2.1 显卡驱动安装的三条路以及nouveau的干扰Ubuntu 上装驱动大致三种方式我按推荐度排序。第一种用发行版仓库里的驱动最省心ubuntu-drivers devices # 看推荐版本 sudo ubuntu-drivers autoinstall # 或者手动指定 sudo apt install nvidia-driver-550好处是驱动包会跟着内核更新自动重建模块不用你操心缺点是仓库里的版本相对保守新卡可能要多等一段时间才有对应版本。第二种加 NVIDIA 官方 CUDA 仓库能拿到更新的驱动分支。第三种下载官网.run安装脚本手动执行——我不推荐这条路除非你有非常明确的理由。它不注册进包管理系统内核一升级就得重新手动装一遍卸载还容易残留网上大量装完驱动进不去系统的案例都出自这里。无论走哪条路装之前先确认 nouveau 被禁用。检查一下lsmod | grep nouveau有输出说明开源驱动还在加载。Ubuntu 的nvidia-driver-*包通常会自动写入 blacklist 文件到/etc/modprobe.d/但如果你之前手动折腾过最好确认nouveau已经被拉黑并且内核启动参数里没有强制启用它的内容。装完驱动之后必须重启nvidia-smi才有输出这点没有例外。2.2 Secure Boot与MOK重启之后进不去系统的元凶安全启动这一关我在不止一台机器上见过翻车。现象是apt install nvidia-driver-*装完重启卡在厂商 logo 界面或者直接掉进黑屏也进不去图形界面。原因很简单开 Secure Boot 时内核只加载有签名的模块。NVIDIA 的专有驱动模块在 DKMS 编译出来之后没有签名被拒绝加载而图形界面又依赖它于是卡死。正确的处理方式是在安装驱动的过程中就完成签名登记。执行安装命令后终端会弹出一个蓝底或灰底的全屏界面提示你设置一个MOK 密码Machine Owner Key这一步一定要停下来设置别直接回车跳过。设置完重启屏幕上会出现 MOK Manager 界面按顺序选择Enroll MOK-Continue-Yes输入刚才设置的密码然后Reboot。走完这套流程模块才被信任。注意如果已经跳过这一步导致进不去系统别慌也别急着重装。开机时进 GRUB 菜单在内核启动参数末尾加上nomodeset或module_blacklistnvidia先进系统把驱动卸掉或者补做 MOK 登记再重启就恢复了。重装系统是最后手段不是第一步。如果你完全不需要双系统、也不用 Secure Boot那在 BIOS 里关掉它是最省事的选择。但既然要保留 Windows 双系统就老老实实做完 MOK 登记。2.3 驱动版本、CUDA版本与框架版本的真实约束关系现在讲最核心的版本矩阵。有个概念要先说清楚系统里装不装 CUDA Toolkit和框架能不能用 GPU是两件不直接相关的事。框架需要的是 CUDA 运行时库libcudart、libcublas、cuDNN这些而这些库现在可以随 wheel 一起安装到你的 conda 环境里。真正卡住你的只有一件事——驱动版本够不够新。驱动与 CUDA 运行时之间是向下兼容的新版驱动能跑旧版 CUDA 运行时反之不行。下面是常见的对应关系具体以 NVIDIA 官方兼容性表为准驱动分支支持的最高 CUDA 运行时47011.452512.053512.255012.4560 及以上12.6 及以上另一张表是显卡算力它决定框架的预编译内核能不能在你的卡上跑显卡架构算力GTX 1080 TiPascalsm_61RTX 2080 Ti / T4Turingsm_75A100Amperesm_80RTX 3090Amperesm_86RTX 4090Adasm_89H100Hoppersm_90算力表有什么用当torch.cuda.is_available()返回True但一跑算子就报no kernel image is available for execution on the device时就是这个卡的算力不在当前 PyTorch 版本的预编译列表里——通常是卡太新、装的框架太旧。解决办法只有一个升级框架版本而不是去折腾驱动。还有一个容易被忽略的点驱动只往上兼容跨大版本有下限。比如 CUDA 12.x 的运行时要求驱动不低于 525 那一档。你如果拿着 470 的驱动去跑 PyTorch 的 cu121 版本会看到CUDA driver version is insufficient for CUDA runtime version这句话的字面意思就是驱动太老了升级驱动即可重装框架没用。3. 用conda把TensorFlow和PyTorch关进各自的房间驱动搞定之后就进入软件环境搭建阶段。这里我的态度很明确TensorFlow 和 PyTorch 一定要分环境不要装在一起。这不是洁癖是实打实会出问题的。3.1 为什么强烈建议两个框架分环境深度学习框架的依赖树里有一批钉子户numpy、protobuf、typing-extensions、ml-dtypes、absl-py。这些包同时被 TensorFlow 和 PyTorch 依赖但对版本的要求经常不一致。举几个我实际遇到过的例子。TensorFlow 2.15 及更早的版本要求numpy2而 PyTorch 2.3 之后已经适配了 NumPy 2.xprotobuf的版本要求两家也长期不同步一个要 3.20.x一个要 4.x。装在一个环境里pip 求解器会按后装的那个去调整结果就是先装的框架被降级或者直接坏掉——典型症状是import tensorflow报一堆cannot import name之类的错误或者 PyTorch 能 import 但一跑就算错。分环境还有个隐性好处依赖清单干净。哪天环境崩了删掉重建只需要几分钟不用担心我上次是不是还装了什么别的包。我的习惯是把每个项目甚至每个框架单独建环境环境名带上用途比如pt-train、tf-serve。3.2 Miniconda安装与conda的基本调优Anaconda 完整版带了一堆你可能永远不用的科学计算包几个 GB 体积。我更推荐Miniconda只有 conda 和基础依赖几百 MB。wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3 $HOME/miniconda3/bin/conda init bash exec $SHELL装完之后有两件事建议马上做。第一件把包缓存和环境目录挪到大盘上。conda 的包缓存pkgs_dirs会因为版本迭代迅速膨胀环境目录envs_dirs每个也要几个 GB两个加起来占满/home是常见事故conda config --add pkgs_dirs /data/conda/pkgs conda config --add envs_dirs /data/conda/envs第二件确认求解器。现在较新的 conda 默认用 libmamba 求解器速度比老版本快一个数量级。如果你的 conda 版本比较老遇到依赖求解卡住十几分钟的情况升级 conda 或者装conda-libmamba-solver都能解决。3.3 PyTorch环境的搭建pip和conda怎么选PyTorch 官方提供两条安装路径我给出的结论是默认走 pip。conda create -n pt python3.11 -y conda activate pt pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121用 pip 的理由有这么几条。第一官方 wheel 里已经打包了所需的 CUDA 运行库会作为nvidia-cublas-cu12、nvidia-cudnn-cu12这类独立包出现在pip list里不依赖系统 CUDA也不依赖 conda 的cudatoolkit。第二版本发布节奏快新卡支持通常先到 pip。第三装的路径是死的出问题时你打开pip list一眼就能看到它带了哪些 CUDA 库排查容易。conda 那条路长这样conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia它的优势是依赖求解更严格适合企业内网或者需要连同一套环境一起固化下来的场景。但要注意一个高频错误别把 conda 的cudatoolkit和 pip 的 wheel 混装。前者会往环境里塞一份 CUDA 库后者也带一份两个版本不一致时运行时加载哪一个取决于链接顺序报错信息会非常难懂。要么全 conda要么全 pip别脚踩两条船。选择 Python 版本时3.10 和 3.11 是目前兼容性最好的两档。3.12 在部分框架和第三方库上偶有轮子缺失的情况除非有明确需求没必要冒险。3.4 TensorFlow环境的搭建2.16之后的变化TensorFlow 这边有个分水岭值得单独说。2.16 版本之后pip 安装的 TensorFlow 也开始自带 CUDA 运行库也就是同样会拉入nvidia-*系列依赖包。这意味着新版本的 TensorFlow 只需要驱动够新不需要系统里预装 CUDA 和 cuDNN。conda create -n tf python3.11 -y conda activate tf pip install tensorflow[and-cuda]那个[and-cuda]后缀很关键它会同时安装 GPU 支持所需的 NVIDIA 依赖包。如果你装的是裸的pip install tensorflow有可能拿到不带 GPU 支持的版本tf.config.list_physical_devices(GPU)直接返回空列表。而 2.15 及更早的版本是另一套规则需要系统里装好对应版本的 CUDA 和 cuDNN还需要把路径配到LD_LIBRARY_PATH里。这条路对新手极不友好——cuDNN 需要注册账号下载版本还得和 CUDA 严格对应。所以我的建议是能用新版本就用新版本别为了配合某个老项目把自己绕回旧流程里。真的需要跑老版本 TensorFlow优先考虑 Docker 镜像而不是在裸机上拼凑。4. 装完不算完两个框架的验收与共存检查pip install成功只代表包下载完了不代表能用。装完就跑到数据集上开训跑到一半发现用的是 CPU这种亏我吃过所以现在每次装完环境都会做一套固定动作的验证。4.1 PyTorch的三步验证设备、算力、真算一次第一步看版本和 CUDA 编译信息import torch print(torch.__version__) print(torch.version.cuda) # 如果是 None说明装的是 CPU 版 print(torch.cuda.is_available()) print(torch.cuda.device_count())torch.version.cuda是这里最值得看的一项。它是None说明这个 wheel 是 CPU 版本的无论驱动装得多好都用不了 GPU。这是新手最容易卡住的地方——is_available()返回False时第一反应是去查驱动其实先看一眼这个值更高效。第二步核对算力和预编译内核print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0)) # 例如 (8, 9) 表示 sm_89 print(torch.cuda.get_arch_list()) # 当前轮子支持哪些算力把第二行的结果拼成sm_89这种形式看看它在不在第三行的列表里。不在就是前面说的no kernel image问题的前兆。第三步让它真算一次。这一步非常重要因为is_available()只检查了运行时能不能初始化没真正执行过 kernelimport torch, time a torch.randn(8192, 8192, devicecuda) b torch.randn(8192, 8192, devicecuda) torch.cuda.synchronize() t0 time.time() for _ in range(10): c a b torch.cuda.synchronize() print(10 次矩阵乘耗时:, time.time() - t0)synchronize()不能省。CUDA 是异步执行不加同步的话计时得到的只是把任务丢进队列的时间看起来快得离谱其实什么都没算完。这个矩阵乘的时间也可以粗略用来估算机器的实际算力水平和你预期差太多时说明可能跑在降频或者低功耗模式下。4.2 TensorFlow的验证物理设备列表与显存增长TensorFlow 这边import tensorflow as tf print(tf.__version__) gpus tf.config.list_physical_devices(GPU) print(gpus) if gpus: for g in gpus: tf.config.experimental.set_memory_growth(g, True)list_physical_devices(GPU)返回空列表是最常见的现象原因和 PyTorch 类似装的是 CPU 版、驱动太老、或者版本矩阵对不上。那段显存增长的设置建议写进每个脚本的开头。TensorFlow 默认会一次性申请几乎全部显存即使你的模型只需要 2GB。这在共享机器上是灾难——你跑一个 demo别人的训练直接 OOM。开了 memory growth它会按需增长。也可以通过环境变量全局设置export TF_FORCE_GPU_ALLOW_GROWTHtrue想确认某个算子究竟落在哪块设备上加上这行调试语句运行时会打印每个操作的设备分配tf.debugging.set_log_device_placement(True)4.3 同一台机器上两个环境来回切换的姿势两个环境都验证通过之后日常使用是这样切换的conda activate tf # 跑 TensorFlow conda activate pt # 跑 PyTorch有几个习惯值得养成。首先不要在 base 环境里装框架base 只留着管 conda 本身出了问题好收拾。其次写一个几行的自检脚本check_env.py放在家目录切完环境随手跑一下确认这次激活的确实是你想要的那个环境而不是因为忘了激活而用了系统 Python。第三注意 shell 提示符前缀——conda 激活后通常会在行首显示环境名但如果你改过.bashrc或者用 zsh这个提示可能被覆盖掉那就只能靠which python来判断了。5. 报错现场还原几个高频坑的排查链路这一节我把几个反复出现的报错按现象 - 原因 - 怎么查 - 怎么修的顺序还原一遍。直接给答案意义不大能复现排查思路才有用。5.1 libcudart缺失与两个CUDA打架现象是import torch直接失败ImportError: libcudart.so.11.0: cannot open shared object file或者ImportError: libcublas.so.11: cannot open shared object file。第一反应不该是去找这个文件下载下来而是先判断这个环境里到底有几套 CUDA 库。排查链路是这样走的pip list | grep -i nvidia echo $LD_LIBRARY_PATH ls -l /usr/local/ | grep cuda三种典型情况。情况一pip list里没有任何nvidia-*包说明装的是 CPU 版轮子重装 GPU 版本即可。情况二pip list里有nvidia-*包但报错找的是.so.11.0这种老版本号说明环境里的 wheel 是新版CUDA 12而某个第三方库是按 CUDA 11 编译的属于依赖混装最干净的解法是重建环境。情况三也是最有意思的一种LD_LIBRARY_PATH指向了/usr/local/cuda/lib64系统里那份 CUDA 被优先加载和 wheel 里的那份版本不一致于是各种奇怪的符号找不到。处理办法是二选一别都要。要么完全依赖 wheel 自带的库把LD_LIBRARY_PATH里跟 CUDA 相关的路径清掉要么彻底走系统 CUDA 那条路卸载 wheel 带的nvidia-*包。我推荐前者因为可控性好。顺便说一句把 CUDA 路径塞进.bashrc的LD_LIBRARY_PATH是很多老教程推荐的做法但在今天这个wheel 自带运行库的时代它反而成了故障源我早就不这么干了。5.2 NumPy 2.x 带来的编译接口变化报错长得很有辨识度A module that was compiled using NumPy 1.x cannot be run in NumPy 2.x意思是某个扩展模块在编译时链接的是 NumPy 1.x 的 ABI而你环境里的 NumPy 已经是 2.x 了接口对不上。触发场景通常是装完框架之后又装了某个数据分析或者图像处理库pip 顺手把 NumPy 升到了 2.x把之前的框架依赖搞坏了。pip install numpy2大多数情况下这一条就能压住。但如果框架版本本身已经支持 NumPy 2那更合理的做法是反向升级框架而不是把 NumPy 钉在老版本上——长期钉着会让你在后面装别的库时不断遇到新冲突。判断依据是看框架的发行说明里对 NumPy 的支持范围。顺带提醒一个陷阱conda 和 pip 在同一环境里混用会悄悄换掉依赖。我用conda list和pip list分别导一遍依赖清单两边对不上的包就是风险点。这也是我前面强调一个环境里只用一种包管理器装框架的原因。5.3 cannot allocate memory in static TLS block这个报错比较隐蔽ImportError: cannot allocate memory in static TLS block它跟显存、内存都没关系。原因是某些库典型的是 OpenMP 相关的libgomp在进程启动早期占用了固定大小的线程局部存储空间如果torch或者别的库在后面才加载需要申请 TLS 空间时就不够了。触发条件通常是import顺序问题你在import torch之前先import cv2或者某个模块在导入时提前拉起了 OpenMP。验证方法和解决办法是在脚本最开头调整导入顺序import torch # 放在最前面 import cv2如果调顺序解决不了可以用预加载绕过去LD_PRELOAD/usr/lib/x86_64-linux-gnu/libgomp.so.1 python your_script.py提示这类报错和实际原因完全不在一个维度上的问题排查时最容易浪费时间。我的经验是遇到 ImportError 先别去搜报错原文先看这个包的版本和依赖链八成的根因在版本不匹配上。5.4 显存被占满与幽灵进程现象是训练脚本报CUDA out of memory但你确信自己没在跑别的任务。先看nvidia-smi fuser -v /dev/nvidia*nvidia-smi会列出占用显存的进程 PID。如果那个 PID 对应的进程已经不存在ps -p PID查不到就是幽灵进程通常是之前脚本被CtrlC打断或者kill -9之后内核模块里的上下文没释放干净。这种情况没有立刻见效的温和解法重启机器是最快的。如果进程还在就是真占用按情况处理。共享机器上先看一眼进程的启动用户和命令确认不是别人的训练在跑再决定要不要沟通。另一个坑不在幽灵上而在泄漏上PyTorch 的 DataLoader 在多进程模式下如果中途异常退出worker 占用的显存可能没被回收跑几轮之后显存曲线一路往上爬。养成习惯把训练循环包进try/finally在finally里显式释放import torch, gc # ...训练代码... finally: torch.cuda.empty_cache() gc.collect()empty_cache()释放的是 PyTorch 缓存的空闲显存不是正在用的显存理解这一点很重要别指望它能把别人占的显存抢过来。6. 从能跑到好用远程、编辑器与多卡环境跑通只是及格线。真正每天用起来还有几件事值得花点时间配好这些配置的收益是长期的。6.1 SSH与Jupyter的远程访问姿势训练机通常不在手边通过 SSH 操作是常态。Jupyter 想远程访问最安全的做法是端口转发而不是把服务直接暴露出去# 服务器端 jupyter lab --no-browser --port8888 # 本地机器 ssh -N -L 8888:localhost:8888 userserver-ip然后本地浏览器打开localhost:8888就行。这种做法的好处是 Jupyter 只监听本地回环外部扫不到坏处是断线后要重连。配置文件在~/.jupyter/jupyter_server_config.py可以设置监听端口、根目录和访问密码。密码用jupyter server password生成哈希不要用明文。至于直接--ip0.0.0.0暴露到公网的玩法除非前面挂了正经的反向代理和鉴权否则别碰。SSH 连不上是另一个高频问题排查顺序基本固定先在服务器本地确认sshd服务在跑systemctl status ssh再确认防火墙放行sudo ufw status最后检查客户端和服务器是否在同一网段。热词里SSH 无法连接多半卡在防火墙或网段这两步上。6.2 VSCode Remote-SSH与解释器选择我现在基本不用本地编辑器写训练代码了VSCode 的 Remote-SSH 插件直接连到服务器上编辑路径、终端、断点调试全部在服务器侧不用同步文件。装好插件连上之后有个必须注意的点VSCode 不会自动激活你的 conda 环境。它会拿一个系统默认的 Python 当解释器于是你在编辑器里跑代码报找不到 torch而在终端里明明好好的。解决办法是手动指定解释器CtrlShiftP - Python: Select Interpreter - 选择 ~/miniconda3/envs/pt/bin/python更省事的做法是在工作区设置里写死{ python.defaultInterpreterPath: ~/miniconda3/envs/pt/bin/python }另外集成终端里的 conda 提示符有时不显示conda activate pt之后可以which python确认一下路径避免出现编辑器用的是 A 环境、终端用的是 B 环境这种最难查的错乱。6.3 多卡与共享机器的礼貌用法单机多卡最基础的用法是限制可见设备CUDA_VISIBLE_DEVICES0,1 python train.py这条命令的语义是只让进程看见 0 和 1 号卡进程内部的编号会重排成 0 和 1。多组实验并行时这个技巧很好用——开两个终端一组用CUDA_VISIBLE_DEVICES0一组用1互不干扰。共享机器上有几条不成文的规矩值得遵守。先nvidia-smi看谁在用、用了多少再决定自己要哪张卡申请显存时留出余量别把卡占满不要在生产共享机上随便apt upgrade显卡驱动一次升级可能让所有人的环境失效这种事要挑维护窗口做。这些不是技术问题但踩一次就够难受的。6.4 环境备份与迁移别等崩了才想环境跑顺之后马上导出清单这是我用血换来的习惯conda env export --no-builds env_pt.yml conda activate pt pip freeze pip_pt.txt--no-builds的作用是去掉具体的构建编号让跨机器的版本匹配宽松一些避免因为某个包的 build 号不同就装不上。另外单独记录几个关键版本号——PyTorch 版本、CUDA 版本、Python 版本这三项决定了重建时该找哪一套。想整份环境搬走直接打包环境目录也行但要注意 conda 默认用硬链接节省空间打包时需要加参数把文件实体化conda pack -n pt -o pt_env.tar.gz多台机器之间同步环境比 Docker 更轻量但迁移性不如容器。如果团队里机器多、又需要严格一致的版本那就直接上容器把镜像标签里的驱动要求写清楚这是另一条更工程化的路线。最后分享一个我自己的小习惯每次配好一台新机器我会把这次用到的所有命令按顺序整理成一个setup.sh注释里写清楚每一步为什么这么做、当时驱动是什么版本。看起来是额外工作但下台机器要装的时候这份脚本能省掉整整一个下午的重新摸索也比任何收藏夹里的教程都靠谱——因为它是你自己验证过、和你的硬件对得上的那一份。