WSL2搭建CUDA 11.8深度学习环境：libtinfo5缺失问题实战解法

1. 这块需求到底是怎么回事：为什么要在WSL2里折腾CUDA

1.1 标题背后的典型使用场景

先说结论：如果你手头是一台Windows机器，又不想为了跑深度学习模型去装双系统或整台换成Linux，那WSL2几乎是目前最舒服的折中方案。标题里的“自用版”三个字很关键，说明这不是一篇面向服务器集群的部署文档，而是给个人开发者、研究生、算法工程师这类“我就想在本机赶紧把环境跑起来”的人准备的。

我碰到的实际场景是这样的：本机Windows 11，显卡是NVIDIA的，需要跑一些基于PyTorch的视觉模型，框架底层依赖CUDA。在Windows原生环境里，PyTorch对CUDA的支持虽然近几年好了很多，但很多老牌工具链、自定义算子、编译型扩展模块，在Linux环境下要顺滑得多。于是最自然的路径就是：Windows上开一个WSL2，装Ubuntu 22.04，再在Ubuntu里装CUDA 11.8。

这套组合之所以烂大街，是因为它兼顾了三个需求：日常办公和IDE留在Windows侧，深度学习训练跑在WSL2里，两边通过文件系统互相访问也算方便。而且WSL2不是虚拟机那种重资源方案，它共享Windows内核，启动快，内存和CPU的调度损耗低，用来跑中等规模的训练任务完全扛得住。

1.2 为什么选WSL2而不是双系统或纯Linux

很多人第一次知道WSL2时会问一个问题：既然都上Linux环境了，为什么不干脆装个双系统，或者直接换Ubuntu桌面？这个问题我每年都会被问几次，我的回答取决于对方的使用习惯。

如果你平时离不开Office全家桶、依赖微信和钉钉、要打游戏，或者公司强制要求使用Windows域环境，那双系统切换成本很高。每次重启切换系统既费时间又容易打断思路，更不用说双系统下显卡驱动、引导修复这些问题能把人折腾到怀疑人生。

WSL2的核心优势在于它是“Windows里的Linux子系统”，不需要重启，直接在Windows桌面上打开终端就能进入Ubuntu环境。对比传统虚拟机（比如VMware或VirtualBox），WSL2基于微软的轻量化虚拟化技术，底层跑的是真正的Linux内核，不是翻译层模拟，所以在CPU密集和I/O密集的任务上性能损耗非常小。GPU方面，WSL2支持GPU直通（GPU Passthrough），Linux侧可以直接调用Windows的NVIDIA驱动，这意味着CUDA程序在WSL2里跑，性能和原生Linux差距基本可以忽略。

当然也有不适合WSL2的场景：如果你要做内核模块开发、需要直接操作硬件设备、或者对GPU性能有极致的追求，那还是老老实实用原生Linux。但就“在Windows上跑PyTorch训练模型”这个典型需求来说，WSL2是目前综合体验最好的路线。

1.3 为什么锁定CUDA 11.8这个版本

先说清楚一个概念：我们常说的“安装CUDA”，实际上包含两个层面。一个是NVIDIA显卡驱动，这个驱动负责操作系统和GPU硬件之间的通信；另一个是CUDA Toolkit，这是一套开发工具链，包含编译器（nvcc）、运行时库、数学库（cuBLAS、cuDNN等）。在WSL2场景下有个非常重要的特性：你不需要在Linux侧单独安装NVIDIA驱动，而是复用Windows侧已安装的驱动。这个后面我会详细展开，很多人在这里踩坑。

那为什么是CUDA 11.8而不是更新版本？因为截至我写这篇博文时，PyTorch官方稳定版对CUDA 11.8的支持非常成熟。深度学习场景里，框架和CUDA的版本匹配往往比“最新”更重要。很多自定义算子库、老项目、复现论文代码，都明确写了“CUDA 11.x tested”，你硬上新版CUDA 12.x，很可能在编译层面遇到API变动导致的不兼容。而且Turing、Ampere等较新的架构在CUDA 11.8下已经完美支持，没有版本焦虑的必要。

当然，如果你的项目明确要求CUDA 12.x，那安装流程大同小异，只是下载链接和版本号换一下就行。这篇博文以11.8为主线，但方法本身可以平移到其他版本。

2. WSL2环境准备：Ubuntu 22.04的干净安装

2.1 安装前的前置条件检查

动手之前先花两分钟检查系统状态，这能帮你避免大部分“装到一半发现不行”的尴尬。首先是Windows版本要求：WSL2依赖Windows 10版本2004及以上，或者Windows 11。如果你还在老版本上，先去Windows Update把系统更新到位。其次是确保BIOS里开启了虚拟化功能（Intel VT-x或AMD-V），这个不开的话WSL2会直接报错。

另外有一点很多人忽略：如果你机器上装了第三方杀毒软件或系统优化工具，建议安装WSL前暂时退出，部分安全软件会拦截WSL的功能组件注册，导致安装后无法正常启动。我见过好几个案例，症状就是WSL命令行能跑，但一进Ubuntu就黑屏闪退，排查到最后发现是安全软件把虚拟化平台组件给禁用了。

检查完毕，打开PowerShell（管理员模式），执行以下命令确认当前版本信息：

powershell复制# 查看Windows版本
winver

# 查看当前WSL状态
wsl --status

如果wsl命令不存在，说明系统还没装WSL基础组件，直接进入下一步。

2.2 使用wsl --install快速部署WSL2

从Windows 10 2004版本开始，微软提供了极简安装命令，直接在管理员PowerShell里执行：

powershell复制# 启用WSL功能并安装默认Ubuntu发行版
wsl --install

这条命令会做四件事：启用“适用于Linux的Windows子系统”功能，启用“虚拟机平台”功能，下载并安装WSL2内核，然后默认安装Ubuntu发行版。执行完之后重启电脑。

重启后第一次启动Ubuntu，会提示你创建一个Linux用户名和密码。这里注意：这个用户名和Windows用户名不需要一致，密码输入时屏幕不会显示，这是正常的终端行为，别以为键盘坏了。创建完用户后，系统会自动把这个用户加到sudo组，日常操作需要管理员权限时用sudo提权。

如果你的机器上网络下载比较慢，或者公司内网环境有限制，wsl --install下载发行版镜像可能失败。备选方案是去微软官方文档找WSL2内核更新包手动安装，再用wsl --import导入离线下载的Ubuntu 22.04 rootfs镜像。不过对大多数个人开发者来说，默认命令就够了。

安装完成后，建议先做两步基础配置。第一步，更新软件源和软件包，这一步很重要，因为默认源在国外，国内网络环境下速度感人：

bash复制# 进入Ubuntu终端后执行
sudo apt update
sudo apt upgrade -y

如果apt update速度太慢，可以把软件源替换为国内镜像源（比如清华源、阿里源），具体方法网上非常成熟，这里不展开。第二步，检查WSL版本，确保跑的是WSL2而不是WSL1，因为WSL1不支持GPU直通：

powershell复制# PowerShell里执行
wsl -l -v

如果看到VERSION列是2，那就对了。如果显示1，说明你安装的是旧版WSL1，执行wsl --set-version Ubuntu-22.04 2转换一下。

2.3 让WSL2用起来更顺手的几个配置

很多人在WSL2里用一段时间后会遇到的几个痛点，我提前帮你解决掉。

第一个痛点是内存限制。WSL2默认最多使用宿主机50%的内存，如果训练模型时发现系统卡顿，可以用Windows用户目录下的.wslconfig文件来调整。在C:\Users\你的用户名\下新建或编辑.wslconfig文件，内容示例：

ini复制[wsl2]
memory=16GB
processors=8
swap=8GB

保存后重启WSL2生效（wsl --shutdown再重新进入）。

第二个痛点是Windows和Linux文件互访乱走。记住一个原则：Linux侧的代码和项目文件放Linux文件系统里（家目录下），Windows侧的文件挂载在/mnt/c/下面。跨文件系统读写性能差异很大，如果你把训练数据集放在Windows的D盘，然后直接在WSL2里跨盘读取，IO性能会打骨折。正确做法是把数据拷到Linux文件系统里再跑训练。

第三个痛点是VSCode远程开发。在Windows侧安装VSCode，然后安装“WSL”扩展插件，在WSL2里进入项目目录执行code .，VSCode会自动以远程模式连进WSL2，编辑代码和调试非常丝滑。这对日常开发体验的提升是革命性的，强烈推荐。

3. CUDA 11.8安装全流程：从驱动验证到编译环境

3.1 先搞懂WSL2的GPU直通机制：为什么不用在Linux里装驱动

这一步是整个过程中最容易出问题的地方，也是理解后续安装步骤的前提。先记下一个结论：在WSL2里安装CUDA时，不需要安装NVIDIA Linux驱动，只需安装CUDA Toolkit本身。

原理是这样的：WSL2的GPU直通机制把Windows显卡驱动的能力“透传”给了Linux用户态，Linux侧的程序通过NVIDIA提供的用户态驱动库（libcuda.so等）与GPU通信，而这些库实际调用的是Windows侧的内核态驱动。所以你在WSL2里执行nvidia-smi看到的驱动版本，其实就是Windows侧的驱动版本。

这就导致了一个非常容易误解的现象：在WSL2里用nvidia-smi查询，显示的CUDA Version往往和Windows驱动信息里的一致，而不是你后来安装的CUDA Toolkit版本。很多人在这里以为自己“驱动没装对”，其实一切正常。记住：CUDA Toolkit的版本是给编译器用的，驱动版本是给GPU Runtime用的，两者可以不一致，但要满足驱动版本 >= Toolkit最低要求。

官方对WSL2+CUDA的支持方案叫“WSL-Ubuntu”，对应的安装包命名里通常会带“WSL-Ubuntu”字样，比如cuda-toolkit-11-8这类包。下载时千万别下成普通Linux桌面版的安装包，否则装完你会发现根本用不了。

3.2 验证Windows侧驱动是否满足要求

进入CUDA安装前，先确认Windows侧驱动是否满足CUDA 11.8的最低版本要求。一般要求是Windows侧NVIDIA驱动版本不低于520系列，因为我实测下来520之前的版本对CUDA 11.8的支持不太完善，容易在编译或运行时出现莫名奇妙的错误。

在Windows侧打开PowerShell，执行：

powershell复制nvidia-smi

如果提示找不到命令，说明你的驱动没装好或者Path没配好。去NVIDIA官网下载GeForce Game Ready驱动或Studio驱动重新安装即可。能看到显卡信息后，看右上角“CUDA Version”字段，这个数字只要不低于11.8就行。

如果你用的是笔记本，而且显卡是双显卡（核显+独显），记得在Windows的“图形设置”里，把WSL2或相关程序设置为“高性能”，否则可能会出现独显不工作但你还不知道的情况。

3.3 下载并安装CUDA Toolkit 11.8

这一步推荐使用NVIDIA官方提供的apt源安装方式，好处是后续升级和卸载都方便，不用手动清理文件。在Ubuntu终端里按顺序执行：

bash复制# 下载CUDA 11.8的安装源配置文件
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600

# 添加NVIDIA官方软件源
sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/3bf863cc.pub
sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/ /"

在添加完软件源之后，先执行一次sudo apt update，确认源生效。然后有一个关键选择：安装完整工具链还是仅安装运行时。

如果你是开发人员，需要编译CUDA代码，那就装完整版：

bash复制sudo apt install cuda-toolkit-11-8

这个包会包含编译器、运行时库、GPU计算库（cuBLAS、cuDNN）、Nsight调试工具等，体积有几个GB，下载需要一些耐心。如果你只是想在已有环境里跑现成的模型，不自己写CUDA代码，那可以精简安装：

bash复制sudo apt install cuda-runtime-11-8

我建议第一次配置时直接装完整版，省得后面发现缺这个缺那个再来补。安装过程中如果网络中断导致包下载失败，重新执行一遍sudo apt install cuda-toolkit-11-8，apt会断点续传，不用太担心。

3.4 配置环境变量并验证安装

安装完成后，CUDA Toolkit默认装在/usr/local/cuda-11.8目录下，同时会创建一个/usr/local/cuda软链接指向最新版本。你需要把相关的bin目录和lib目录加到环境变量里。

编辑~/.bashrc文件，在末尾追加：

bash复制export PATH=/usr/local/cuda-11.8/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export CUDA_HOME=/usr/local/cuda-11.8

保存后执行source ~/.bashrc让环境变量立即生效。然后验证：

bash复制# 查看nvcc编译器版本
nvcc --version

# 查看GPU状态
nvidia-smi

nvcc --version能显示Cuda compilation tools版本号，说明编译工具链OK。nvidia-smi能显示显卡型号和驱动版本，说明GPU直通正常。这两个命令都正常，CUDA 11.8的核心安装就算完成了。

这里有个让我印象深刻的坑：很多人执行nvcc --version时提示command not found，第一反应是CUDA没装好，其实很可能只是环境变量没生效。记得source ~/.bashrc或者重新打开终端。另外，如果你用的是zsh而不是bash，对应的配置文件是~/.zshrc，别改错文件了。

4. libtinfo5缺失问题的完整解决方案：最硬核的拦路虎

4.1 这个报错到底是怎么来的

当你把CUDA Toolkit装好，兴冲冲地开始跑第一个深度学习训练脚本时，很可能撞上一个莫名其妙的报错：

code复制error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

或者类似这样的变体：

code复制/lib/x86_64-linux-gnu/libncursesw.so.5: undefined reference to `tputs'

这个报错和CUDA本身的关系不大，真正的元凶是系统依赖库版本的脱节。Ubuntu 22.04默认提供的是libtinfo6，而一些旧版本工具链（包括部分CUDA相关组件、老版本的compiler、某些符号调试工具）链接的却是libtinfo5。CUDA Toolkit的某些老组件，比如Nsight系列、部分nvcc插件，依赖的是后者。

简单类比一下：libtinfo是终端处理函数库，6和5是两个大版本，二进制接口不兼容。Ubuntu 22.04升级到了6，但CUDA 11.8的部分组件还停留在这个5的时代，两边对不上，运行时就崩了。这不是你装错了什么，纯粹是软件供应链上下游版本衔接的问题。

4.2 方案一：从Ubuntu 20.04仓库下载libtinfo5安装（最推荐）

既然Ubuntu 22.04没有现成的libtinfo5包，那最直接的思路就是从还在提供它的Ubuntu 20.04仓库里拿现成的包。deb包本身是向下兼容的，你不需要为了一个运行库去重装系统。

在WSL2的Ubuntu终端里执行：

bash复制# 添加Ubuntu 20.04的focal仓库（临时添加，获取libtinfo5包）
sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu focal main universe"

# 更新软件源
sudo apt update

# 安装libtinfo5
sudo apt install libtinfo5

装完之后，顺手把这个临时添加的focal源移除，避免以后系统更新时出现版本混乱的风险：

bash复制# 移除focal源
sudo add-apt-repository --remove "deb http://archive.ubuntu.com/ubuntu focal main universe"
sudo apt update

这个方法我实测下来是最稳的，因为它直接通过包管理器安装了符合标准的deb包，库文件路径、权限、符号链接都是正确的，不会出现手动放置文件导致的权限问题。如果你在安装过程中遇到依赖解析错误，可以在install命令后面加--allow-downgrades强制安装，但一般情况下不需要。

4.3 方案二：手动下载deb包离线安装

如果你所在网络环境下访问archive.ubuntu.com非常慢，或者公司网络屏蔽了这外网地址，可以改用离线下载的方式。在你本机的Windows浏览器里，访问Ubuntu软件包官方查询网站，搜索libtinfo5，然后选择focal（20.04）版本，找到amd64架构的deb包直接下载。

下载完成后，把deb包放到WSL2里，执行：

bash复制# cam为下载的deb文件名，按实际文件调整
sudo dpkg -i libtinfo5*.deb

如果dpkg提示依赖缺失，可以先执行sudo apt --fix-broken install修复依赖再重新安装。这个方法的好处是不需要永久添加旧源，适合一次性解决问题。

4.4 方案三：用软链接方式绕过（应急方案）

如果你既不想加源，又不想下载deb包，还有一种取巧的办法，通过软链接把libtinfo6伪装成libtinfo5。具体操作如下：

bash复制# 找到系统中的libtinfo6库路径
ls /lib/x86_64-linux-gnu/libtinfo.so.6

# 创建软链接
sudo ln -s /lib/x86_64-linux-gnu/libtinfo.so.6 /lib/x86_64-linux-gnu/libtinfo.so.5

这个方案的好处是速度快、不用下载任何东西，但它有一个隐患：如果某个程序调用的是libtinfo5里而不存在于libtinfo6的新增函数接口，运行时会直接报undefined symbol错误，也就是表面上链接成功了，但在调用具体函数时才暴露。所以我把这个方案定位为“应急”，适合临时跑一下小项目，不建议作为长期方案。

4.5 三个方案的取舍建议

这三个方案其实对应了不同的使用场景，我整理一下选择逻辑：

从我个人的经验来看，方案一最好用，方案二适合网络不给力的人，方案三是实在没办法时的保底手段。如果你装完libtinfo5之后还遇到其他库缺失，思路完全一样，搜索对应的库名，找到合适的deb包来源安装即可。

另外提醒一句，装完libtinfo5之后，如果之前训练脚本因为缺库挂掉，记得重新启动一下终端或者重新打开WSL2会话，让动态链接库的加载器重新扫描一遍。有些情况下，忘了刷新环境会导致明明装好了还报错，白折腾很久。

5. 常见问题与故障排查实录：一天踩三回，回回不重样

5.1 问题速查对照表

我把实践中最常遇到的几个问题整理成速查表，方便你遇到问题时快速对照：

5.2 深度排查案例：装上CUDA但PyTorch还是找不到显卡

有一个问题我几乎每周都会被问一次：明明ncvv能用了，nvidia-smi也正常，但PyTorch训练时就是报CUDA not available。这个问题的排查思路比问题本身更重要。

先用排除法。第一步检查PyTorch版本是否支持你装的CUDA版本。PyTorch有CPU版和GPU版，如果你当初用pip安装时选错了版本，或者使用了默认的PyTorch安装命令，很可能装成了CPU版。验证方法：

bash复制python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available())"

如果torch.version.cuda是None，说明你装的是CPU版PyTorch。需要到PyTorch官网选择对应的CUDA版本重新安装。这里额外提示一点：PyTorch官方对CUDA 11.8的支持，在pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118这一行命令里。

第二步排除WSL2环境变量干扰。WSL2里如果你把LD_LIBRARY_PATH设置得太激进，比如把某些不兼容的CUDA运行时路径设为最高优先级，可能导致PyTorch加载错误的库。建议先清空或精简LD_LIBRARY_PATH再试。

第三步检查驱动版本。如果Windows侧驱动是470系列或者更早，那就太老了，CUDA 11.8要求的驱动支持不满足，必须升级驱动。这种情况的典型特征就是nvidia-smi能显示，但一跑CUDA程序就报错。

5.3 性能调优：让WSL2里的训练速度接近原生Linux

装好环境之后，很多人关心的一个问题就是：WSL2里跑训练，性能和原生Linux差多少？这个问题的答案取决于你的使用姿势。

如果你把数据和代码放在Linux文件系统里（比如/home/yourname/下），性能损耗大约在5%以内，基本察觉不到差异。但如果你的代码在Linux侧，数据集在Windows侧，然后代码用/mnt/c/...路径读取数据，那训练速度可能腰斩。这是因为WSL2的跨文件系统IO走的是9P协议，协议本身带来了额外开销，大量小文件读取时尤为明显。

现在NVIDIA在WSL2里的CUDA实现，已经非常接近原生性能，计算密集型的算子基本没有损耗。真正的瓶颈就出现在数据IO上。所以我的建议是：把项目、数据集、虚拟环境全部放到Linux文件系统里，Windows侧只保留IDE和数据备份。这是一个性价比极高的优化。

如果你要和宿主机共享GPU显存，WSL2本身没有独立的显存概念，它直接使用Windows侧驱动管理的显存，所以大模型的显存占用情况和原生Windows下是基本一致的。

5.4 环境维护与版本隔离：省心省力的关键

最后分享一个我的个人经验：在一个环境里反复换CUDA版本，很容易把系统搞乱。我的做法是使用conda作为环境管理工具，为不同的项目建立独立的conda环境，在环境里分别安装对应版本的PyTorch和CUDA运行时。

bash复制# 安装miniconda后创建新环境
conda create -n torch118 python=3.10
conda activate torch118

# 在当前环境安装GPU版PyTorch
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

这种做法的好处有两个：一是当你需要在CUDA 11.8和CUDA 12.x之间切换时，不同环境互不干扰；二是在系统层面只需要维护一套CUDA Toolkit即可满足开发编译需求，运行时的版本完全由conda环境隔离控制。条件允许的话，也可以直接使用/cu118这个索引地址对应的PyTorch版本，绕过系统CUDA的版本依赖。

踩过几次坑之后，我的体会是：WSL2 + Ubuntu 22.04 + CUDA 11.8这套组合的难点不在某个单一环节，而是整个链路中每一步都可能遇到版本不匹配的微妙问题。把系统级工具链和项目级依赖分开管理，是最能降低心智负担的办法。如果你是第一次接触这套环境，建议按本文顺序走一遍，不要跳步，遇到问题回到对应的章节去排查。