折腾过深度学习环境的朋友都知道环境配置这件事往往是“跑通之前想砸电脑跑通之后一身轻”。这几年因为项目需要我在Windows 11/10 平台上反反复复装过不少次深度学习环境最后固定下来的一套组合就是Windows侧只装显卡驱动计算环境全部丢到WSL2里的Ubuntu 20.04再在虚拟机内部配置CUDA工具链和PyTorch。这套方案最大的好处是既保住了Windows日常办公、玩游戏、剪视频的便利又拿到了接近原生Linux的开发体验而且GPU直通调用CUDA基本无感。这篇文章我会把完整的配置过程、每一步背后的原理、还有我踩过的坑一次性讲清楚。不管你是刚接触WSL2的新手还是想在Windows上搞深度学习又不想装双系统的老手照着这套流程走完大概率能把你自己的PyTorch环境跑起来。注意我讲的是Windows 11/10下WSL2 Ubuntu 20.04的组合这是一套经过大量用户验证的稳定搭配版本细节我会在文中随时点明。1. 为什么要折腾WSL2方案取舍与适用场景1.1 WSL2和双系统、传统虚拟机的恩怨先说说我为什么放着双系统不用非要绕道WSL2。三年前我第一次在Windows上配深度学习环境老老实实装了虚拟机软件里面塞了一个Ubuntu桌面版。结果显卡直通配置折腾了将近一周虚拟机里跑出来的帧率还不到本机的三分之一那次经历直接让我对传统虚拟机方案产生了心理阴影。后来接触到了WSL2才意识到虚拟机方案的问题在于图形化和硬件模拟的额外开销太多而WSL2走的是轻量级虚拟化路线它本质上是一个运行在轻量级虚拟机里的完整Linux内核但和Windows宿主机共享了整个生态。双系统当然也能用但每天来回重启切换系统实在太伤了。尤其是写代码写到一半需要去Windows侧查个资料、回个微信、用一下Windows下的专用软件来回切换的成本在真实开发节奏里高到难以忽视。WSL2则把Windows和Linux揉在了同一台机器里文件可以互相访问网络共享天然打通启动一个Ubuntu终端只需要几秒钟这种无缝体验是双系统给不了的。很多人会担心WSL2是不是“阉割版Linux”怕跑不了GPU任务。这个担心在早期确实成立但自从微软和NVIDIA联手做了GPU加速支持之后WSL2里已经可以直接访问宿主机显卡CUDA、cuDNN这些深度学习底层的库都能正常工作。我现在跑PyTorch训练、推理、甚至一些轻量级模型微调都在WSL2里完成效率上和我以前用过的纯Linux服务器没有明显差别。1.2 什么人适合这套方案根据我的经验下面这几类人是最适合用WSL2 Ubuntu 20.04这套组合的。第一类是学生和科研人员日常主力是Windows笔记本偶尔需要跑一些课程实验、论文复现不想为了一个实验去装双系统。第二类是在企业办公场景下工作的开发者公司电脑上锁定了各种Windows办公软件没法随意更换系统WSL2可以在不违反管理规定的前提下拥有一套Linux开发环境。第三类是游戏开发、图形学相关从业者需要在Windows上跑游戏引擎同时又要用Linux工具链做构建和调试。当然也有不适合的。比如你手头的显卡本身不支持CUDA或者你是Apple Silicon芯片的Mac用户那这套方案完全不适用。再比如你要做大规模的分布式训练需要多机多卡集群调度那还是老老实实用纯Linux服务器更合理WSL2毕竟跑在个人电脑上资源上限就摆在那里。2. Windows侧环境准备与WSL2落地2.1 版本与硬件前置检查动手之前先花五分钟做个检查能省掉后面对着一堆看不懂报错的时间。系统层面Windows 10必须升级到2004版以上Windows 11则没有太大的版本限制但最好保持最新补丁状态。检查方法是在“运行”窗口输入“winver”回车弹出来的窗口里能看到具体版本号如果低于2004就先更新再往后走。CPU要求是支持虚拟化现在市面上绝大多数处理器都没问题AMD和Intel都行。关键点是必须确保BIOS里开启了虚拟化技术Intel对应的叫VT-xAMD叫SVM一般在BIOS的高级设置里能找到。如果没开启WSL2安装后会提示“请启用虚拟机平台”。另外虚拟化功能”这一项。显卡方面NVIDIA显卡是刚需而且必须是支持CUDA的型号。怎么判断去NVIDIA官网对照一下自己的显卡型号是否在CUDA支持列表里。我用过几款不同的NVIDIA卡从入门级到中高端都能在WSL2里正常调用所以只要不是太老的麦克斯韦架构之前的卡问题都不大。AMD显卡理论上也有对应的方案但生态远不如NVIDIA成熟不建议作为主力开发环境。内存和硬盘也得稍微惦记一下。WSL2的虚拟机内存默认会占到宿主机内存的50%左右如果你只有8GB内存跑大模型会非常吃力建议至少16GB起步。硬盘建议SSD因为Ubuntu的文件系统是放在一个虚拟磁盘文件里的机械硬盘的随机读取性能会明显拖慢包管理器安装和数据处理的速度。2.2 启用WSL与虚拟机平台环境检查完之后开始正式安装。最简单的方法是直接以管理员身份打开PowerShell执行下面的命令wsl --install这条命令在Windows 10 2004以上和Windows 11上都会自动启用需要的Windows功能组件包括“适用于Linux的Windows子系统”和“虚拟机平台”然后默认安装Ubuntu发行版。不过这里有个坑默认安装的Ubuntu往往是最新版本而我这次目标是Ubuntu 20.04所以更推荐分步手动操作。第一步在PowerShell里手动启用两个Windows功能dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart命令执行完会提示重启电脑这时候老老实实重启一次别想着省事往下走我就是因为当时懒得重启直接继续结果后面WSL一直起不来排查了半天才发现是功能没生效。重启回来后把WSL2设置为默认版本。这一步非常关键因为WSL1和WSL2在系统架构上完全是两回事WSL1通过系统调用翻译层兼容Linux程序不支持真正的Linux内核也不支持GPU直通。执行wsl --set-default-version 2 wsl --version执行第二条命令是为了确认WSL本身的版本如果你看到的WSL版本号是类似于1.x或者显示“WSL 1”说明内核组件还有缺失。遇到这种情况直接去微软官方渠道下载并安装最新的WSL更新包即可装完再执行一次wsl --version确认。2.3 安装并初始化Ubuntu 20.04基础组件就绪后开始安装Ubuntu 20.04。打开微软商店搜索“Ubuntu 20.04”找到后点击安装。没有商店访问权限的话也可以用命令行方式直接拉取wsl --install -d Ubuntu-20.04安装完成后第一次启动Ubuntu终端系统会要求设置一个Linux用户名和密码。注意这个用户名和Windows用户名完全无关是独立的Linux账户之后用sudo提权都是基于这个账户。密码输入时屏幕上不会显示任何字符别慌正常输入然后回车就行。第一次初始化的时候Ubuntu会执行一些解包和配置的脚本需要等个几分钟。这个过程中我遇到过网络不良导致安装卡住的情况如果长时间没有反应可以关掉终端重新启动再不行就检查一下Windows防火墙是否拦截了WSL的网络访问。初始化完成后第一件事就是更新软件包源和系统组件sudo apt update sudo apt upgrade -y sudo apt install -y build-essentialbuild-essential里面包含了gcc、g、make这些编译工具链虽然安装PyTorch的时候通常不需要本地编译但后面折腾一些自定义算子、编译CUDA扩展时就会用到属于必须自带的基础装备。2.4 用.wslconfig控制资源占用到这里WSL2已经能正常使用了但还有一件事我建议你早点做就是创建.wslconfig配置文件。这个文件放在Windows用户目录下例如C:\Users\你的用户名\.wslconfig用来限制WSL2虚拟机对宿主机资源的占用。为什么需要限制因为WSL2默认会使用宿主机50%的内存以及所有CPU核心。如果你跑着内存吃紧的开发工具、浏览器开了一堆标签页WSL2再占掉一半内存Windows这边很容易卡成幻灯片。我的配置文件是这样写的[wsl2] memory12GB processors6 swap8GB localhostForwardingtruememory字段限制WSL2最大内存processors限制CPU核心数swap指定交换分区大小localhostForwarding保持默认开启就好它保证WSL2里的服务可以通过localhost被Windows侧访问比如你在Ubuntu里启动了Jupyter NotebookWindows浏览器直接访问http://localhost:8888就能打开。改完.wslconfig后需要彻底重启WSL2才能生效。在PowerShell里执行wsl --shutdown执行完等几秒钟再重新进入Ubuntu终端内存限制就生效了。资源限制这件事一定要在安装重型工具之前做不然等你把CUDA、PyTorch都装完了才发现内存不够用排查起来特别费劲。3. NVIDIA显卡驱动与CUDA工具链3.1 WSL2的GPU驱动机制很多第一次在WSL2里配CUDA的人会下意识地跑到Ubuntu内部去下载NVIDIA的Linux版本显卡驱动。这里我要重点提醒千万不要在WSL2里安装Linux版本的NVIDIA驱动这一步踩坑的人太多了。WSL2的GPU驱动机制和原生Linux不一样。在WSL2里显卡驱动安装在Windows宿主机一侧WSL2内部的Ubuntu是通过微软提供的GPU直通接口访问Windows驱动。换句话说NVIDIA显卡驱动只需要在Windows侧安装一份WSL2内部不需要、也不能再装一遍Linux驱动。如果你强行在WSL2里装了Linux版驱动轻则驱动加载失败重则直接把WSL2的GPU访问搞崩画面就是nvidia-smi要么报错要么显示找不到设备。所以正确的驱动检查方式是在Windows侧确保已经安装了从NVIDIA官网下载的显卡驱动版本尽量保持较新。然后在WSL2的终端里执行nvidia-smi如果一切正常你会看到和Windows侧几乎一模一样的显卡信息输出包括驱动版本和CUDA版本号。这里有个关键点WSL2里nvidia-smi显示的CUDA版本是Windows驱动内置支持的CUDA运行时版本并不是你在Ubuntu里安装的CUDA Toolkit版本两者不能混淆。很多人看到驱动里的CUDA版本是12.x就以为CUDA Toolkit已经装好了其实还差得远。3.2 安装CUDA Toolkit的正确打开方式驱动共享机制搞清楚之后就明白在WSL2里我们只需要安装CUDA Toolkit。CUDA Toolkit是一整套开发库和编译器工具PyTorch在编译和运行时依赖的是Toolkit提供的库文件而不是Windows驱动里自带的那份CUDA运行时。NVIDIA官方为WSL2提供了专用的CUDA Toolkit安装包源安装方式比原生Linux还要简单。首先要给apt添加NVIDIA的软件源。打开Ubuntu终端依次执行下面的命令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 wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt update这几步做的事分别是下载一个固定NVIDIA软件包优先级的配置文件把它放到apt的preferences目录里确保NVIDIA的包不会和Ubuntu默认源里的同名包发生版本冲突然后安装CUDA的密钥包让apt能验证NVIDIA仓库的签名最后更新软件源。之后就可以安装CUDA Toolkit了。NVIDIA官方仓库里会有不同小版本的CUDA比如12.4、12.6等我配置时用的是12.4因为它和当时PyTorch官方预编译包的CUDA版本对应得比较舒服sudo apt-get -y install cuda-toolkit-12-4这里想多啰嗦一句不要无脑安装cuda这个总包那个包会拉取一大堆不必要的组件包括驱动相关的内容白白占掉好几个GB的空间。指定小版本号只装cuda-toolkit-12-4装的是编译和运行所需的库、头文件和工具干净得多。安装完CUDA Toolkit后需要在~/.bashrc文件里配置环境变量。用vim或nano打开这个文件export PATH/usr/local/cuda-12.4/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH export CUDA_HOME/usr/local/cuda-12.4保存后执行source ~/.bashrc让变量生效。这里有个小细节/usr/local/cuda通常是指向/usr/local/cuda-12.4的软链接路径写/usr/local/cuda更稳以后切换CUDA版本不用改环境变量直接用软链接调整目标就行。我自己实际也是这么干的。3.3 验证CUDA与驱动对齐环境变量配置好之后验证CUDA是否安装成功nvcc --version输出信息里应该能看到Cuda compilation tools的版本号说明编译器已经就绪。接着执行nvidia-smi再对比一下之前看到的驱动信息。正常情况下nvcc显示的CUDA版本是你刚装的Toolkit版本而nvidia-smi显示的CUDA版本是Windows驱动自带的版本。这两个版本可以不一致只要满足一个条件nvcc的版本不高于nvidia-smi显示的版本。因为驱动内置的CUDA运行时负责和显卡硬件交互Toolkit版本比驱动版本新可能会因为缺少对应的驱动ABI而不兼容。我见过有人死磕一定要让两个版本一致其实完全没必要。你只需要确保驱动版本足够新然后再装一个不高于驱动CUDA版本的工具链就行。比如驱动显示CUDA Version 12.4那装CUDA 12.4或更低的版本都没问题但如果驱动只支持11.8却装了12.4的Toolkit大概率跑起来会报版本不匹配的错误。4. 配置PyTorch环境并实测跑分4.1 Python环境选型与创建CUDA工具链就绪后接下来给Python搭建一个干净的环境。我强烈建议用Miniconda而不是系统自带的Python来管理环境和依赖原因很简单PyTorch版本更新频繁不同的项目可能需要不同版本的PyTorch或者不同版本的CUDAconda的虚拟环境隔离能做到互不干扰。你也不想因为A项目把PyTorch升到了2.2B项目就彻底跑不起来吧。安装Miniconda的方式是老一套wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装脚本运行过程中会问几个问题一般全选默认值就行。脚本结束时问是否要自动初始化conda选yes这样终端每次启动都会自动激活conda基础环境。装完重新打开终端会看到命令行前缀多了(base)字样。接着创建独立的PyTorch环境conda create -n pytorch python3.10 -y conda activate pytorch为什么选Python 3.10因为根据当时的兼容性状况PyTorch各版本对Python 3.10的支持很全面而且PyTorch 2.x在3.10上的编译优化做得比较成熟。Python 3.11和3.12的兼容性也越来越好但如果你不想折腾3.10是稳妥之选。4.2 安装PyTorch并匹配CUDA版本PyTorch测试版和生产版建议通过PyTorch官方源安装。打开PyTorch官网的安装页面选择对应的操作系统、安装方式它会自动给出适合你系统的安装命令强烈建议以此为准。我这里以当时比较流行的CUDA 12.1版本为例安装命令大致是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这条命令里的--index-url参数指定了PyTorch专门为不同CUDA版本预编译好whl包的源。默认的pip源也有一份PyTorch但默认源里的是CPU版本装完才发现不能用还得卸载重来非常浪费时间。所以一定要用带CUDA标识的index-url。这里会引申出一个选择困难同样一份PyTorch有cu118版本、cu121版本、cu124版本到底选哪个选择逻辑很简单看你刚才安装的CUDA Toolkit版本和Windows驱动的CUDA版本。取两者的较低值然后选择不高于这个值的PyTorch CUDA版本。比如你驱动显示CUDA 12.4Toolkit装的是12.4那可以选cu121或cu124如果你的驱动是老版本只支持11.8那只能选cu118。安装完成后跑一个验证脚本确认一切就绪python -c import torch; print(PyTorch版本:, torch.__version__); print(CUDA可用:, torch.cuda.is_available()); print(GPU名称:, torch.cuda.get_device_name(0) if torch.cuda.is_available() else N/A)输出里如果显示CUDA可用: True并且GPU名称正确识别为你的显卡型号恭喜你环境已经打通了。4.3 验证GPU可用性与算力评估光看CUDA可用还不够我建议再做一次真实的张量运算验证确保GPU和CPU之间数据搬运也没问题。最简单的方式是跑一次矩阵乘法和一次梯度计算import torch x torch.randn(1024, 1024, devicecuda) y torch.randn(1024, 1024, devicecuda) z x y print(GPU矩阵乘法结果形状:, z.shape) print(显存占用:, torch.cuda.memory_allocated() / 1024**2, MB) linear torch.nn.Linear(256, 256).cuda() optimizer torch.optim.SGD(linear.parameters(), lr0.01) loss linear(torch.randn(64, 256, devicecuda)).sum() loss.backward() print(反向传播完成梯度正常)如果这几行代码都顺畅跑通说明底层的CUDA库、cuDNN和GPU通信都正常。我第一次跑这个验证脚本时矩阵乘法那一步直接卡死没反应最后排查下来发现是Windows侧驱动版本太旧。这里想说的是如果遇到卡死或报错先检查驱动再检查Toolkit版本顺序不要反过来。到这一步环境配置部分已经全部完成了。整套操作下来大概需要一两个小时其中大部分时间都花在下载安装包和网络等待上真正需要动脑子的地方其实不多。但实际操作中总有一些意外情况比如仓库连不上、驱动更新后WSL2里突然不识别GPU等等我接着把这些年遇到过的高频问题整理一张排查表。5. 常见问题与排查技巧实录5.1 nvidia-smi不可用这是我在各个技术社区里看到最多的问题也是我自己第一次配的时候遇到的。现象是在WSL2终端里执行nvidia-smi要么提示找不到命令要么报错说无法访问NVIDIA设备。遇到这个情况先分清是哪一种如果是command not found说明CUDA Toolkit安装时没把nvidia-smi这个工具放到PATH里或者是没安装对应的工具包。解决方式是检查/usr/lib/wsl/lib目录下有没有nvidia-smi如果有手动把它链接到/usr/local/bin下sudo ln -s /usr/lib/wsl/lib/nvidia-smi /usr/local/bin/nvidia-smi在较新版本的WSL2里/usr/lib/wsl/lib是Windows驱动映射到Linux的文件系统路径NVIDIA相关工具都在那里。如果这个目录下连nvidia-smi都没有问题就出在Windows侧驱动没有正确安装回Windows检查一下设备管理器里显卡是否正常识别。另一种情况是nvidia-smi提示NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver这说明Linux侧找不到驱动通信接口大概率是你在WSL2内部装了Linux版驱动导致冲突。处理办法是在WSL2里卸载掉所有nvidia相关的包然后重启WSL2sudo apt purge *nvidia* wsl --shutdown重启后再进入一般就能恢复正常。5.2 libcuda.so.1缺失或符号链接问题有时PyTorch的torch.cuda.is_available()返回Falsenvidia-smi也正常就非常诡异。打开Python手动加载一下CUDA时会看到类似于libcuda.so.1: cannot open shared object file的报错。这个错误的核心原因是Python进程运行时需要在动态链接库路径里找到libcuda.so.1而这个库是WSL2特有的通常位于/usr/lib/wsl/lib。我用的解决方法是把WSL的库目录加到LD_LIBRARY_PATHecho export LD_LIBRARY_PATH/usr/lib/wsl/lib:$LD_LIBRARY_PATH ~/.bashrc source ~/.bashrc另一种情况是libcuda.so.1存在但指向的版本文件缺失比如系统中的libcuda.so.1是一个悬空的软链接。这时候去/usr/lib/wsl/lib目录下看看实际的so文件名比如libcuda.so.1.1然后手动重建软链接sudo ln -sf /usr/lib/wsl/lib/libcuda.so.1.1 /usr/lib/wsl/lib/libcuda.so.1这个操作有点底层了建议谨慎进行确保你备份了原有的链接。5.3 内存、磁盘与性能类问题WSL2的性能问题大部分和资源上限直接相关。如果你发现训练时显存占用正常但内存跑满导致系统卡顿优先去调.wslconfig里的memory参数不要让WSL2无限吞噬宿主机内存。根据我的经验分配固定大小的内存比让系统自适应更稳定比如memory8GB跑中小模型完全够用。磁盘方面有个容易被忽视的点WSL2的虚拟磁盘文件默认只会增长不会缩减。如果你往里装了又卸载了很多大软件磁盘空间被占用但不会自动释放看起来像是“空间谜之消失”。可以用Windows侧的工具压缩虚拟磁盘但更省心的方式是平时注意不要往WSL2里乱装大型软件能用conda管理环境的就不往系统里塞。还有一个常见的性能陷阱把训练数据放在Windows文件系统路径下然后在WSL2里跨文件系统读取。比如直接把数据放到/mnt/c/...路径WSL2通过9P协议访问Windows文件系统I/O性能比原生Linux文件系统慢不少。我的建议是训练数据一定要拷贝到Linux一侧比如~/data目录跨文件系统访问只适合传输小文件。5.4 重装驱动或升级后的坑Windows显卡驱动升级是日常操作但升级后WSL2里偶尔会出现GPU访问失效或者CUDA版本不匹配的问题。原因是驱动版本变了驱动内置的CUDA运行时版本也随之改变如果你之前安装的CUDA Toolkit版本比新驱动能支持的最高版本还高就会出现不兼容。我的习惯是升级Windows驱动后第一时间进WSL2跑一下nvidia-smi看一眼驱动显示支持的CUDA版本有没有变化。如果发现WSL2内部GPU访问异常最快的修复方法是执行wsl --shutdown彻底重启WSL2而不是在Windows里反复重启。绝大多数升级后的GPU失效问题都能靠这个操作解决。另外如果Windows大版本更新后WSL2整个消失了检查Windows功能面板里“适用于Linux的Windows子系统”和“虚拟机平台”是否被关闭重新勾选并重启即可。这种情况在我用Win10期间遇到过两次Win11上反而稳定很多。6. 一些可以再说说的经验写到最后分享一点我个人用这套环境跑了快两年的体会。第一点是环境配置这件事最重要的是理清“Windows驱动、CUDA Toolkit、PyTorch”这三层的关系。很多人配置失败是因为把这三层混为一谈搞不清楚每一层解决什么问题、应该装在哪个系统里。只要把这个逻辑理清了哪怕以后某个软件版本更新频繁你自己也能判断该怎么调整。第二点是尽量保持软件版本“跟随主流”。我不是说新版本一定好而是PyTorch、CUDA这种生态里的软件社区主流的版本组合往往是踩坑最少、教程最多、兼容性最好的组合。比如我当时选CUDA 12.1加PyTorch 2.1的组合就是因为在社区里看到大量人在用遇到问题随便搜都能找到答案。非要追求最新版本出了问题可能连错误资料都搜不到性价比很低。最后一个小技巧把这篇文章里用到的命令和配置模板保存成一个单独的笔记文件下次换电脑或者重装系统时直接照着操作五分钟内就能把环境重新拉起来。配置深度学习环境这个事第一次做的时候会觉得信息量巨大但熟悉了整套流程之后它其实完全是最简单、最不需要创造力的部分真正有价值的永远是你拿着这套环境之后要做的事情。祝你一次跑通少走弯路。 Windows下用WSL2配置Ubuntu+PyTorch深度学习环境全攻略
折腾过深度学习环境的朋友都知道环境配置这件事往往是“跑通之前想砸电脑跑通之后一身轻”。这几年因为项目需要我在Windows 11/10 平台上反反复复装过不少次深度学习环境最后固定下来的一套组合就是Windows侧只装显卡驱动计算环境全部丢到WSL2里的Ubuntu 20.04再在虚拟机内部配置CUDA工具链和PyTorch。这套方案最大的好处是既保住了Windows日常办公、玩游戏、剪视频的便利又拿到了接近原生Linux的开发体验而且GPU直通调用CUDA基本无感。这篇文章我会把完整的配置过程、每一步背后的原理、还有我踩过的坑一次性讲清楚。不管你是刚接触WSL2的新手还是想在Windows上搞深度学习又不想装双系统的老手照着这套流程走完大概率能把你自己的PyTorch环境跑起来。注意我讲的是Windows 11/10下WSL2 Ubuntu 20.04的组合这是一套经过大量用户验证的稳定搭配版本细节我会在文中随时点明。1. 为什么要折腾WSL2方案取舍与适用场景1.1 WSL2和双系统、传统虚拟机的恩怨先说说我为什么放着双系统不用非要绕道WSL2。三年前我第一次在Windows上配深度学习环境老老实实装了虚拟机软件里面塞了一个Ubuntu桌面版。结果显卡直通配置折腾了将近一周虚拟机里跑出来的帧率还不到本机的三分之一那次经历直接让我对传统虚拟机方案产生了心理阴影。后来接触到了WSL2才意识到虚拟机方案的问题在于图形化和硬件模拟的额外开销太多而WSL2走的是轻量级虚拟化路线它本质上是一个运行在轻量级虚拟机里的完整Linux内核但和Windows宿主机共享了整个生态。双系统当然也能用但每天来回重启切换系统实在太伤了。尤其是写代码写到一半需要去Windows侧查个资料、回个微信、用一下Windows下的专用软件来回切换的成本在真实开发节奏里高到难以忽视。WSL2则把Windows和Linux揉在了同一台机器里文件可以互相访问网络共享天然打通启动一个Ubuntu终端只需要几秒钟这种无缝体验是双系统给不了的。很多人会担心WSL2是不是“阉割版Linux”怕跑不了GPU任务。这个担心在早期确实成立但自从微软和NVIDIA联手做了GPU加速支持之后WSL2里已经可以直接访问宿主机显卡CUDA、cuDNN这些深度学习底层的库都能正常工作。我现在跑PyTorch训练、推理、甚至一些轻量级模型微调都在WSL2里完成效率上和我以前用过的纯Linux服务器没有明显差别。1.2 什么人适合这套方案根据我的经验下面这几类人是最适合用WSL2 Ubuntu 20.04这套组合的。第一类是学生和科研人员日常主力是Windows笔记本偶尔需要跑一些课程实验、论文复现不想为了一个实验去装双系统。第二类是在企业办公场景下工作的开发者公司电脑上锁定了各种Windows办公软件没法随意更换系统WSL2可以在不违反管理规定的前提下拥有一套Linux开发环境。第三类是游戏开发、图形学相关从业者需要在Windows上跑游戏引擎同时又要用Linux工具链做构建和调试。当然也有不适合的。比如你手头的显卡本身不支持CUDA或者你是Apple Silicon芯片的Mac用户那这套方案完全不适用。再比如你要做大规模的分布式训练需要多机多卡集群调度那还是老老实实用纯Linux服务器更合理WSL2毕竟跑在个人电脑上资源上限就摆在那里。2. Windows侧环境准备与WSL2落地2.1 版本与硬件前置检查动手之前先花五分钟做个检查能省掉后面对着一堆看不懂报错的时间。系统层面Windows 10必须升级到2004版以上Windows 11则没有太大的版本限制但最好保持最新补丁状态。检查方法是在“运行”窗口输入“winver”回车弹出来的窗口里能看到具体版本号如果低于2004就先更新再往后走。CPU要求是支持虚拟化现在市面上绝大多数处理器都没问题AMD和Intel都行。关键点是必须确保BIOS里开启了虚拟化技术Intel对应的叫VT-xAMD叫SVM一般在BIOS的高级设置里能找到。如果没开启WSL2安装后会提示“请启用虚拟机平台”。另外虚拟化功能”这一项。显卡方面NVIDIA显卡是刚需而且必须是支持CUDA的型号。怎么判断去NVIDIA官网对照一下自己的显卡型号是否在CUDA支持列表里。我用过几款不同的NVIDIA卡从入门级到中高端都能在WSL2里正常调用所以只要不是太老的麦克斯韦架构之前的卡问题都不大。AMD显卡理论上也有对应的方案但生态远不如NVIDIA成熟不建议作为主力开发环境。内存和硬盘也得稍微惦记一下。WSL2的虚拟机内存默认会占到宿主机内存的50%左右如果你只有8GB内存跑大模型会非常吃力建议至少16GB起步。硬盘建议SSD因为Ubuntu的文件系统是放在一个虚拟磁盘文件里的机械硬盘的随机读取性能会明显拖慢包管理器安装和数据处理的速度。2.2 启用WSL与虚拟机平台环境检查完之后开始正式安装。最简单的方法是直接以管理员身份打开PowerShell执行下面的命令wsl --install这条命令在Windows 10 2004以上和Windows 11上都会自动启用需要的Windows功能组件包括“适用于Linux的Windows子系统”和“虚拟机平台”然后默认安装Ubuntu发行版。不过这里有个坑默认安装的Ubuntu往往是最新版本而我这次目标是Ubuntu 20.04所以更推荐分步手动操作。第一步在PowerShell里手动启用两个Windows功能dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart命令执行完会提示重启电脑这时候老老实实重启一次别想着省事往下走我就是因为当时懒得重启直接继续结果后面WSL一直起不来排查了半天才发现是功能没生效。重启回来后把WSL2设置为默认版本。这一步非常关键因为WSL1和WSL2在系统架构上完全是两回事WSL1通过系统调用翻译层兼容Linux程序不支持真正的Linux内核也不支持GPU直通。执行wsl --set-default-version 2 wsl --version执行第二条命令是为了确认WSL本身的版本如果你看到的WSL版本号是类似于1.x或者显示“WSL 1”说明内核组件还有缺失。遇到这种情况直接去微软官方渠道下载并安装最新的WSL更新包即可装完再执行一次wsl --version确认。2.3 安装并初始化Ubuntu 20.04基础组件就绪后开始安装Ubuntu 20.04。打开微软商店搜索“Ubuntu 20.04”找到后点击安装。没有商店访问权限的话也可以用命令行方式直接拉取wsl --install -d Ubuntu-20.04安装完成后第一次启动Ubuntu终端系统会要求设置一个Linux用户名和密码。注意这个用户名和Windows用户名完全无关是独立的Linux账户之后用sudo提权都是基于这个账户。密码输入时屏幕上不会显示任何字符别慌正常输入然后回车就行。第一次初始化的时候Ubuntu会执行一些解包和配置的脚本需要等个几分钟。这个过程中我遇到过网络不良导致安装卡住的情况如果长时间没有反应可以关掉终端重新启动再不行就检查一下Windows防火墙是否拦截了WSL的网络访问。初始化完成后第一件事就是更新软件包源和系统组件sudo apt update sudo apt upgrade -y sudo apt install -y build-essentialbuild-essential里面包含了gcc、g、make这些编译工具链虽然安装PyTorch的时候通常不需要本地编译但后面折腾一些自定义算子、编译CUDA扩展时就会用到属于必须自带的基础装备。2.4 用.wslconfig控制资源占用到这里WSL2已经能正常使用了但还有一件事我建议你早点做就是创建.wslconfig配置文件。这个文件放在Windows用户目录下例如C:\Users\你的用户名\.wslconfig用来限制WSL2虚拟机对宿主机资源的占用。为什么需要限制因为WSL2默认会使用宿主机50%的内存以及所有CPU核心。如果你跑着内存吃紧的开发工具、浏览器开了一堆标签页WSL2再占掉一半内存Windows这边很容易卡成幻灯片。我的配置文件是这样写的[wsl2] memory12GB processors6 swap8GB localhostForwardingtruememory字段限制WSL2最大内存processors限制CPU核心数swap指定交换分区大小localhostForwarding保持默认开启就好它保证WSL2里的服务可以通过localhost被Windows侧访问比如你在Ubuntu里启动了Jupyter NotebookWindows浏览器直接访问http://localhost:8888就能打开。改完.wslconfig后需要彻底重启WSL2才能生效。在PowerShell里执行wsl --shutdown执行完等几秒钟再重新进入Ubuntu终端内存限制就生效了。资源限制这件事一定要在安装重型工具之前做不然等你把CUDA、PyTorch都装完了才发现内存不够用排查起来特别费劲。3. NVIDIA显卡驱动与CUDA工具链3.1 WSL2的GPU驱动机制很多第一次在WSL2里配CUDA的人会下意识地跑到Ubuntu内部去下载NVIDIA的Linux版本显卡驱动。这里我要重点提醒千万不要在WSL2里安装Linux版本的NVIDIA驱动这一步踩坑的人太多了。WSL2的GPU驱动机制和原生Linux不一样。在WSL2里显卡驱动安装在Windows宿主机一侧WSL2内部的Ubuntu是通过微软提供的GPU直通接口访问Windows驱动。换句话说NVIDIA显卡驱动只需要在Windows侧安装一份WSL2内部不需要、也不能再装一遍Linux驱动。如果你强行在WSL2里装了Linux版驱动轻则驱动加载失败重则直接把WSL2的GPU访问搞崩画面就是nvidia-smi要么报错要么显示找不到设备。所以正确的驱动检查方式是在Windows侧确保已经安装了从NVIDIA官网下载的显卡驱动版本尽量保持较新。然后在WSL2的终端里执行nvidia-smi如果一切正常你会看到和Windows侧几乎一模一样的显卡信息输出包括驱动版本和CUDA版本号。这里有个关键点WSL2里nvidia-smi显示的CUDA版本是Windows驱动内置支持的CUDA运行时版本并不是你在Ubuntu里安装的CUDA Toolkit版本两者不能混淆。很多人看到驱动里的CUDA版本是12.x就以为CUDA Toolkit已经装好了其实还差得远。3.2 安装CUDA Toolkit的正确打开方式驱动共享机制搞清楚之后就明白在WSL2里我们只需要安装CUDA Toolkit。CUDA Toolkit是一整套开发库和编译器工具PyTorch在编译和运行时依赖的是Toolkit提供的库文件而不是Windows驱动里自带的那份CUDA运行时。NVIDIA官方为WSL2提供了专用的CUDA Toolkit安装包源安装方式比原生Linux还要简单。首先要给apt添加NVIDIA的软件源。打开Ubuntu终端依次执行下面的命令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 wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt update这几步做的事分别是下载一个固定NVIDIA软件包优先级的配置文件把它放到apt的preferences目录里确保NVIDIA的包不会和Ubuntu默认源里的同名包发生版本冲突然后安装CUDA的密钥包让apt能验证NVIDIA仓库的签名最后更新软件源。之后就可以安装CUDA Toolkit了。NVIDIA官方仓库里会有不同小版本的CUDA比如12.4、12.6等我配置时用的是12.4因为它和当时PyTorch官方预编译包的CUDA版本对应得比较舒服sudo apt-get -y install cuda-toolkit-12-4这里想多啰嗦一句不要无脑安装cuda这个总包那个包会拉取一大堆不必要的组件包括驱动相关的内容白白占掉好几个GB的空间。指定小版本号只装cuda-toolkit-12-4装的是编译和运行所需的库、头文件和工具干净得多。安装完CUDA Toolkit后需要在~/.bashrc文件里配置环境变量。用vim或nano打开这个文件export PATH/usr/local/cuda-12.4/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH export CUDA_HOME/usr/local/cuda-12.4保存后执行source ~/.bashrc让变量生效。这里有个小细节/usr/local/cuda通常是指向/usr/local/cuda-12.4的软链接路径写/usr/local/cuda更稳以后切换CUDA版本不用改环境变量直接用软链接调整目标就行。我自己实际也是这么干的。3.3 验证CUDA与驱动对齐环境变量配置好之后验证CUDA是否安装成功nvcc --version输出信息里应该能看到Cuda compilation tools的版本号说明编译器已经就绪。接着执行nvidia-smi再对比一下之前看到的驱动信息。正常情况下nvcc显示的CUDA版本是你刚装的Toolkit版本而nvidia-smi显示的CUDA版本是Windows驱动自带的版本。这两个版本可以不一致只要满足一个条件nvcc的版本不高于nvidia-smi显示的版本。因为驱动内置的CUDA运行时负责和显卡硬件交互Toolkit版本比驱动版本新可能会因为缺少对应的驱动ABI而不兼容。我见过有人死磕一定要让两个版本一致其实完全没必要。你只需要确保驱动版本足够新然后再装一个不高于驱动CUDA版本的工具链就行。比如驱动显示CUDA Version 12.4那装CUDA 12.4或更低的版本都没问题但如果驱动只支持11.8却装了12.4的Toolkit大概率跑起来会报版本不匹配的错误。4. 配置PyTorch环境并实测跑分4.1 Python环境选型与创建CUDA工具链就绪后接下来给Python搭建一个干净的环境。我强烈建议用Miniconda而不是系统自带的Python来管理环境和依赖原因很简单PyTorch版本更新频繁不同的项目可能需要不同版本的PyTorch或者不同版本的CUDAconda的虚拟环境隔离能做到互不干扰。你也不想因为A项目把PyTorch升到了2.2B项目就彻底跑不起来吧。安装Miniconda的方式是老一套wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装脚本运行过程中会问几个问题一般全选默认值就行。脚本结束时问是否要自动初始化conda选yes这样终端每次启动都会自动激活conda基础环境。装完重新打开终端会看到命令行前缀多了(base)字样。接着创建独立的PyTorch环境conda create -n pytorch python3.10 -y conda activate pytorch为什么选Python 3.10因为根据当时的兼容性状况PyTorch各版本对Python 3.10的支持很全面而且PyTorch 2.x在3.10上的编译优化做得比较成熟。Python 3.11和3.12的兼容性也越来越好但如果你不想折腾3.10是稳妥之选。4.2 安装PyTorch并匹配CUDA版本PyTorch测试版和生产版建议通过PyTorch官方源安装。打开PyTorch官网的安装页面选择对应的操作系统、安装方式它会自动给出适合你系统的安装命令强烈建议以此为准。我这里以当时比较流行的CUDA 12.1版本为例安装命令大致是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这条命令里的--index-url参数指定了PyTorch专门为不同CUDA版本预编译好whl包的源。默认的pip源也有一份PyTorch但默认源里的是CPU版本装完才发现不能用还得卸载重来非常浪费时间。所以一定要用带CUDA标识的index-url。这里会引申出一个选择困难同样一份PyTorch有cu118版本、cu121版本、cu124版本到底选哪个选择逻辑很简单看你刚才安装的CUDA Toolkit版本和Windows驱动的CUDA版本。取两者的较低值然后选择不高于这个值的PyTorch CUDA版本。比如你驱动显示CUDA 12.4Toolkit装的是12.4那可以选cu121或cu124如果你的驱动是老版本只支持11.8那只能选cu118。安装完成后跑一个验证脚本确认一切就绪python -c import torch; print(PyTorch版本:, torch.__version__); print(CUDA可用:, torch.cuda.is_available()); print(GPU名称:, torch.cuda.get_device_name(0) if torch.cuda.is_available() else N/A)输出里如果显示CUDA可用: True并且GPU名称正确识别为你的显卡型号恭喜你环境已经打通了。4.3 验证GPU可用性与算力评估光看CUDA可用还不够我建议再做一次真实的张量运算验证确保GPU和CPU之间数据搬运也没问题。最简单的方式是跑一次矩阵乘法和一次梯度计算import torch x torch.randn(1024, 1024, devicecuda) y torch.randn(1024, 1024, devicecuda) z x y print(GPU矩阵乘法结果形状:, z.shape) print(显存占用:, torch.cuda.memory_allocated() / 1024**2, MB) linear torch.nn.Linear(256, 256).cuda() optimizer torch.optim.SGD(linear.parameters(), lr0.01) loss linear(torch.randn(64, 256, devicecuda)).sum() loss.backward() print(反向传播完成梯度正常)如果这几行代码都顺畅跑通说明底层的CUDA库、cuDNN和GPU通信都正常。我第一次跑这个验证脚本时矩阵乘法那一步直接卡死没反应最后排查下来发现是Windows侧驱动版本太旧。这里想说的是如果遇到卡死或报错先检查驱动再检查Toolkit版本顺序不要反过来。到这一步环境配置部分已经全部完成了。整套操作下来大概需要一两个小时其中大部分时间都花在下载安装包和网络等待上真正需要动脑子的地方其实不多。但实际操作中总有一些意外情况比如仓库连不上、驱动更新后WSL2里突然不识别GPU等等我接着把这些年遇到过的高频问题整理一张排查表。5. 常见问题与排查技巧实录5.1 nvidia-smi不可用这是我在各个技术社区里看到最多的问题也是我自己第一次配的时候遇到的。现象是在WSL2终端里执行nvidia-smi要么提示找不到命令要么报错说无法访问NVIDIA设备。遇到这个情况先分清是哪一种如果是command not found说明CUDA Toolkit安装时没把nvidia-smi这个工具放到PATH里或者是没安装对应的工具包。解决方式是检查/usr/lib/wsl/lib目录下有没有nvidia-smi如果有手动把它链接到/usr/local/bin下sudo ln -s /usr/lib/wsl/lib/nvidia-smi /usr/local/bin/nvidia-smi在较新版本的WSL2里/usr/lib/wsl/lib是Windows驱动映射到Linux的文件系统路径NVIDIA相关工具都在那里。如果这个目录下连nvidia-smi都没有问题就出在Windows侧驱动没有正确安装回Windows检查一下设备管理器里显卡是否正常识别。另一种情况是nvidia-smi提示NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver这说明Linux侧找不到驱动通信接口大概率是你在WSL2内部装了Linux版驱动导致冲突。处理办法是在WSL2里卸载掉所有nvidia相关的包然后重启WSL2sudo apt purge *nvidia* wsl --shutdown重启后再进入一般就能恢复正常。5.2 libcuda.so.1缺失或符号链接问题有时PyTorch的torch.cuda.is_available()返回Falsenvidia-smi也正常就非常诡异。打开Python手动加载一下CUDA时会看到类似于libcuda.so.1: cannot open shared object file的报错。这个错误的核心原因是Python进程运行时需要在动态链接库路径里找到libcuda.so.1而这个库是WSL2特有的通常位于/usr/lib/wsl/lib。我用的解决方法是把WSL的库目录加到LD_LIBRARY_PATHecho export LD_LIBRARY_PATH/usr/lib/wsl/lib:$LD_LIBRARY_PATH ~/.bashrc source ~/.bashrc另一种情况是libcuda.so.1存在但指向的版本文件缺失比如系统中的libcuda.so.1是一个悬空的软链接。这时候去/usr/lib/wsl/lib目录下看看实际的so文件名比如libcuda.so.1.1然后手动重建软链接sudo ln -sf /usr/lib/wsl/lib/libcuda.so.1.1 /usr/lib/wsl/lib/libcuda.so.1这个操作有点底层了建议谨慎进行确保你备份了原有的链接。5.3 内存、磁盘与性能类问题WSL2的性能问题大部分和资源上限直接相关。如果你发现训练时显存占用正常但内存跑满导致系统卡顿优先去调.wslconfig里的memory参数不要让WSL2无限吞噬宿主机内存。根据我的经验分配固定大小的内存比让系统自适应更稳定比如memory8GB跑中小模型完全够用。磁盘方面有个容易被忽视的点WSL2的虚拟磁盘文件默认只会增长不会缩减。如果你往里装了又卸载了很多大软件磁盘空间被占用但不会自动释放看起来像是“空间谜之消失”。可以用Windows侧的工具压缩虚拟磁盘但更省心的方式是平时注意不要往WSL2里乱装大型软件能用conda管理环境的就不往系统里塞。还有一个常见的性能陷阱把训练数据放在Windows文件系统路径下然后在WSL2里跨文件系统读取。比如直接把数据放到/mnt/c/...路径WSL2通过9P协议访问Windows文件系统I/O性能比原生Linux文件系统慢不少。我的建议是训练数据一定要拷贝到Linux一侧比如~/data目录跨文件系统访问只适合传输小文件。5.4 重装驱动或升级后的坑Windows显卡驱动升级是日常操作但升级后WSL2里偶尔会出现GPU访问失效或者CUDA版本不匹配的问题。原因是驱动版本变了驱动内置的CUDA运行时版本也随之改变如果你之前安装的CUDA Toolkit版本比新驱动能支持的最高版本还高就会出现不兼容。我的习惯是升级Windows驱动后第一时间进WSL2跑一下nvidia-smi看一眼驱动显示支持的CUDA版本有没有变化。如果发现WSL2内部GPU访问异常最快的修复方法是执行wsl --shutdown彻底重启WSL2而不是在Windows里反复重启。绝大多数升级后的GPU失效问题都能靠这个操作解决。另外如果Windows大版本更新后WSL2整个消失了检查Windows功能面板里“适用于Linux的Windows子系统”和“虚拟机平台”是否被关闭重新勾选并重启即可。这种情况在我用Win10期间遇到过两次Win11上反而稳定很多。6. 一些可以再说说的经验写到最后分享一点我个人用这套环境跑了快两年的体会。第一点是环境配置这件事最重要的是理清“Windows驱动、CUDA Toolkit、PyTorch”这三层的关系。很多人配置失败是因为把这三层混为一谈搞不清楚每一层解决什么问题、应该装在哪个系统里。只要把这个逻辑理清了哪怕以后某个软件版本更新频繁你自己也能判断该怎么调整。第二点是尽量保持软件版本“跟随主流”。我不是说新版本一定好而是PyTorch、CUDA这种生态里的软件社区主流的版本组合往往是踩坑最少、教程最多、兼容性最好的组合。比如我当时选CUDA 12.1加PyTorch 2.1的组合就是因为在社区里看到大量人在用遇到问题随便搜都能找到答案。非要追求最新版本出了问题可能连错误资料都搜不到性价比很低。最后一个小技巧把这篇文章里用到的命令和配置模板保存成一个单独的笔记文件下次换电脑或者重装系统时直接照着操作五分钟内就能把环境重新拉起来。配置深度学习环境这个事第一次做的时候会觉得信息量巨大但熟悉了整套流程之后它其实完全是最简单、最不需要创造力的部分真正有价值的永远是你拿着这套环境之后要做的事情。祝你一次跑通少走弯路。