Linux深度学习环境搭建：13年老兵的排障实录

　　凌晨三点半，三台机器的CUDA驱动集体抽风——我盯着屏幕上的“NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver”，泡面汤在键盘缝里凝成油膜。开发在群里@我：“环境又挂了，模型跑不起来，你上次搭的到底行不行？”我原以为用conda隔离环境就能万事大吉，结果这破玩意儿跟系统驱动掐得死去活来，conda list里CUDA版本显示11.8，nvidia-smi却报11.4，合着它俩活在不同次元？

　　上周刚给新来的运维讲过“别用apt直接装驱动”，结果今天查日志发现，开发偷偷在测试机跑了sudo apt install nvidia-driver-535——他倒痛快了，留我一地鸡毛。我原以为13年的经验能让我一眼看出问题，结果这次栽在“混合安装”上：conda自己编译的CUDA库、系统自带的驱动、开发手欠装的deb包，三股势力在/usr/local里打群架，ldconfig输出乱得像被猫挠过的毛线团。更绝的是，其中一台机器的/etc/modprobe.d/里居然混着三年前写的blacklist.conf，把nouveau和nvidia-uvm全禁了，我查了半天才发现这行注释掉的老配置——机房空调吹得我后颈发凉，可后背早被冷汗浸透了。

　　跟开发吵到第四轮时，他甩过来一句：“你搭的环境怎么比我们本地还难搞？”我差点把键盘砸了——他本地是Windows+WSL2，驱动是微软包办的，系统库是封闭的，当然没这些破事儿。可Linux深度学习环境呢？驱动要跟内核版本对，CUDA要跟cuDNN对，PyTorch要跟CUDA对，conda还要跟所有包对，稍有个版本差池就报错，报错信息还全是“undefined symbol”这种玄学玩意儿。我翻出三年前的笔记，当时在另一家公司搭环境，光是解决“libcudart.so.11.0找不到”就花了两天，现在倒好，历史重演，只不过这次是libcudnn.so.8.2.1。其实这些坑我早踩过，可每次新机器、新驱动、新框架出来，总得重新踩一遍——优胜劣汰？淘汰的是我这种记不住所有版本号的运维吧。

文章配图，仅供参考

　　后来怎么解决的？我直接把三台机器全格式化了，从零开始装Ubuntu 22.04 LTS，驱动用runfile手动装，CUDA用官方deb包，conda环境单独挂载到/opt，所有环境变量全写进/etc/environment，.bashrc里只留最基础的提示符修改。装完测了五轮，nvidia-smi、nvcc --version、python -c "import torch; print(torch.__version__)"全正常，才敢让开发上机。可我知道，这不过是暂时的平静——下个月NVIDIA出新驱动，PyTorch更新版本，或者开发又要装什么奇奇怪怪的包，环境肯定还得崩。其实优胜劣汰在这行特别明显：不会排障的运维，早晚被环境逼疯；不会沟通的开发，早晚把运维逼疯；而像我这种既得排障又得沟通的，只能一边骂娘一边继续搭环境。

　　现在我坐在工位上，盯着新搭好的三台机器，突然想起上周值夜班时，老张跟我说：“你这环境搭得再稳，也架不住开发手欠。”我当时还反驳他，说“规范能解决90%的问题”，结果现在发现，剩下的10%才是最要命的——那些“正常操作”、那些历史遗留配置、那些开发自以为是的“优化”，才是环境崩溃的真正元凶。其实这事本来能避免：如果开发不偷偷装驱动，如果我能早点发现blacklist.conf，如果环境变量管理更严格一点……可哪有那么多如果？我叹了口气，打开终端，准备给新来的运维写份《Linux深度学习环境避坑指南》——虽然我知道，他看完该踩的坑，一个都不会少。

（编辑：站长网）

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