Linux深度学习环境搭建：7年测试工程师的排障实战

　　我原以为装个CUDA驱动就能跑通PyTorch，结果第七次重装系统时，nvidia-smi能认卡、nvcc能编译、python import torch不报错——可一跑train.py，GPU显存就卡在1024MB不动，loss死活不降，tensor全在CPU上算，连torch.cuda.is_available()都返回True。

　　那天是2026年9月17号下午，我盯着jtop里那个纹丝不动的GPU利用率曲线，手边咖啡凉了两回。运维小张从隔壁工位探头问：“是不是没export CUDA_VISIBLE_DEVICES=0？”我摆摆手，这句我背得比生日还熟，第八次装环境前就贴在显示器边框上了。

　　我试过重装驱动（535.129.03）、换conda环境（py38/py39/py310全躺过）、删掉.nv/目录、甚至把/etc/modprobe.d/blacklist-nouveau.conf里的blacklist nouveau改成blacklist nouveau_bak再重命名回来……都没用。反正最后发现，只要一启动JupyterLab，那1024MB显存就钉死；但直接python train.py —— 显存蹭一下冲到8G，训练也动了。

　　我就蹲在终端前看日志，一行行grep，手指按着键盘Ctrl+C Ctrl+V像抽搐。直到看见那行被吞掉半截的warning：[W cuda.cpp:XXX] Warning: CUDA driver is outdated. This may cause unexpected behavior (Triggered on device 0)。我查了下驱动版本号，535.129.03——没错啊，官网写着支持CUDA 12.2，而nvcc -V显示12.2.2，PyTorch 2.3.1也明确说兼容CUDA 12.2……

　　我也不知道为啥偏偏只在Jupyter里出问题。后来翻到一个埋得极深的issue：Jupyter kernel启动时会多调一次cudaGetDeviceCount，而某个驱动微版本和CUDA runtime的交互bug会导致它偷偷触发fallback path，把所有后续分配都打回CPU。不是不识别GPU，是GPU在那儿站军姿，一声令下才动——可Jupyter的指令永远不来。

　　改了~/.jupyter/jupyter_notebook_config.py，在c.NotebookApp.kernel_spec_manager_class = 'jupyter_client.kernelspec.KernelSpecManager'下面硬加了一句os.environ['CUDA_LAUNCH_BLOCKING'] = '1'，重启notebook……还是1024MB。我又试了c.NotebookApp.nbserver_extensions = {'jupyter_tensorboard': True}，结果tensorboard一开，GPU显存反而涨到3G，但训练仍不走GPU——就像你敲门喊“开工”，屋里人听见了，点个头，继续嗑瓜子。

　　最后是小张甩给我一条命令：sudo nvidia-modprobe -u -m -c=0。他说他上周修另一台机器时发现，modprobe加载顺序错一毫秒，nv_peer_mem模块就抢在nvidia-uvm前注册，而Jupyter kernel恰好依赖这个顺序。我执行完，reboot，进notebook跑一行x = torch.randn(1000,1000).cuda()——显存跳到了4800MB，top -H一看，果然有CUDA线程在跑。

　　（窗外桂花开了，甜得发腻，我其实过敏，打了一下午喷嚏）

　　我笃定一件事：驱动没崩、CUDA没断、PyTorch没撒谎，只是它们三者握手的时候，中间漏听了半句暗号。至于暗号具体藏在哪一层、哪个寄存器、哪次PCIe transaction里……我也不知道。反正现在跑起来了，loss开始掉了，但我心里空落落的——就像考试卷子对了答案，却忘了自己怎么算的。

文章配图，仅供参考

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!