在Windows上搞AI开发，过去只有两条路：要么装双系统，要么老老实实跑虚拟机。但现在有了第三个选择，而且是我当成主力机方案用了快一年的选择：WSL2 + GPU直通。你可以在Windows 10/11里打开一个真正的Linux终端，终端背后跑着完整Linux内核，还能用你的NVIDIA显卡去跑PyTorch、训练模型，而不是模拟出来的慢速CPU环境。这篇分享就把我配置这套环境踩过的坑、试过的方法、以及最终稳定跑起来的完整方案，从头到尾讲清楚。

如果你是刚入门的AI开发者、准备在笔记本上跑大模型推理或者做日常训练调试的工程师，又不想为了Linux环境重启进双系统，这篇文章能帮你省下至少一个周末的折腾时间。

说句实话，WSL2这套东西刚推出来的时候我也觉得是玩具。直到自己在里面跑通了CUDA、把Transformer训练脚本跑出和Windows侧几乎一致的速度之后，我才意识到这玩意儿真的能当主力环境用。

1. WSL2到底解决了什么问题

很多人不理解“内核级Linux”这个说法到底牛在哪里。我用最直白的话解释：WSL2不是一个模拟器，也不是一个“翻译层”，它是在你Windows系统里运行的一台轻量级虚拟机，虚拟机里跑着微软官方构建的、完整的、真正的Linux内核。这个区别对AI开发来说不是锦上添花，而是生死攸关。

1.1 从WSL1到WSL2：为什么“内核级Linux”对AI开发这么重要

WSL1当年的做法是系统调用翻译，就是把Linux程序发出的系统调用翻译成Windows能理解的调用。听起来很巧妙，但一旦涉及底层内核功能、硬件驱动、GPU调用，这种翻译层的方案就完全不够用了。NVIDIA的CUDA驱动必须在Linux内核环境里加载运行，WSL1根本没有真正的Linux内核可以加载，所以GPU计算在WSL1时代基本没戏。

WSL2换了一条路：直接用Hyper-V轻量级虚拟机承载一个真实的Linux内核。这带来几个直接结果：

第一，Linux的二进制兼容性几乎100%和真机一致。你在WSL2里编译的Docker镜像、跑的原生Linux CUDA库、加载的内核模块，行为都和物理Linux机器一致；第二，Docker可以直接原生跑在WSL2的后端上，不需要折腾模拟层；第三，GPU直通成为可能，因为Linux内核有了图形驱动交互的接口。

AI开发链路里，无论是用GPU驱动库、编译自定义的CUDA算子、跑依赖底层内核调用的分布式框架，还是直接把训练脚本打包进Docker容器，全都要建立在真实Linux内核之上。这就是为什么“内核级”这三个字是这个项目标题里最值钱的定语。

1.2 GPU直通不是玄学：WSL2的GPU共享机制是怎么工作的

先纠一个概念。标题里的“GPU直通”，很多人以为是像虚拟机里的PCIe直通那样，把一张物理显卡完整切给虚拟机独占。但WSL2其实用的是半虚拟化方案，技术上叫GPU-PV（GPU Paravirtualization，半虚拟化GPU）。

打个比方：PCIe直通等于把整辆车完全交给对方开，你这边的车库里就少了一辆车；WSL2的半虚拟化等于车还是你的，但你把方向盘、油门、刹车接口开放给对方，对方能够安全地借你的动力系统跑业务。对AI开发来说，我们需要的正是计算能力和显存访问能力，而不是独占整个图形卡。

在WSL2里，Windows宿主机的显卡驱动通过一个虚拟总线把GPU的计算能力暴露给Linux侧，Linux侧的AI框架直接调用CUDA API，底层数据通过虚拟通道到达物理GPU。微软和NVIDIA联调出来的这套机制，计算类任务的性能损失实测很小，PyTorch训练任务通常只有个位数百分比的损耗，对日常调试和中小规模训练来说完全感知不到。

这个设计的额外好处也很明显：Windows桌面还能继续使用显卡输出画面，WSL2运行的时候你照样浏览网页、用IDE，互不抢显卡。

1.3 双系统、虚拟机、WSL2、云GPU怎么选

用了一个表格，把最近几年接触过的几类AI开发环境方案摊开来对比：

我的选择逻辑是：台式机装了双系统，专门负责长时间跑大模型训练；笔记本上日常开发调试、写代码、跑实验，全部在WSL2里完成。云GPU按小时租用，处理临时需要大显存的任务。四类方案不是互斥关系，关键是把每个方案用在合适的位置上。

2. GPU直通的核心原理与先决条件

光知道WSL2能用GPU还远远不够，里面有个非常容易踩坑的“知识断层”：“Windows侧”和“Linux侧”的责任边界到底在哪里。很多人配置失败，就是因为没搞明白这个边界。

2.1 先决条件一：Windows侧只需要更新显卡驱动

WSL2里GPU能用，实际走的是Windows宿主机的显卡驱动。你在Windows里装好NVIDIA驱动之后，这个驱动里面已经包含了面向WSL2的GPU计算组件。所以Windows侧的操作只有一条：把NVIDIA驱动更新到支持WSL2的版本。

具体版本要求取决于你的操作系统和显卡型号，现在NVIDIA官网上随便下载一个最新Game Ready或Studio驱动，基本都满足条件。装好之后，驱动层面的事就结束了，Windows侧不需要装任何CUDA Toolkit。

这一点很多教程根本没讲透，导致不少人习惯性地在Windows里装了一整套CUDA Toolkit，结果发现WSL2里完全用不上，白白浪费一堆磁盘空间和安装时间。

2.2 先决条件二：CUDA Toolkit装在Linux侧（以及为什么）

真正会被AI框架调用的CUDA运行时，需要安装在WSL2的Linux系统里。原因很简单：PyTorch之类的AI框架运行在Linux进程里，它调动的是Linux侧的CUDA动态库。就算Windows侧装了CUDA，Linux进程也摸不到。

更妙的是NVIDIA专门为WSL2场景提供了WSL-Ubuntu版本的CUDA仓库，你在WSL2里用apt安装就能拿到适配好的CUDA Toolkit。后面我会给出具体的安装命令和两条路径的选择——纯跑PyTorch的人和需要编译自定义算子的，安装策略其实不一样。

2.3 先决条件三：硬件与操作系统版本检查清单

在动手之前，先花三分钟对着清单检查一下环境，后面就能少遇一半问题：

• 操作系统版本：Windows 10 2004及以上，或Windows 11（Win11对WSL2支持最完善，推荐优先使用）。
• CPU虚拟化：需要在BIOS里开启Intel VT-x或AMD SVM虚拟化技术，很多“wsl2无法启动”问题都出在这里。
• 内存建议：至少16GB。WSL2内存机制比较吃资源，8GB的机器跑起来会很紧张。
• NVIDIA GPU：支持CUDA的NVIDIA显卡基本都可以；AMD显卡走ROCm生态也能用，但新手不建议自虐；Intel集显可以跑简单的推理，CUDA生态不要指望。
• 磁盘空间：除了系统盘预留至少10GB给WSL2虚拟磁盘，强烈建议把发行版迁移到空间充裕的D盘或E盘，后面第三节会给命令。

我不止一次看到有人在配置环境时对着报错猛查资料，最后一查发现BIOS里根本没打开虚拟化，白折腾半天。这个点相当于这座大厦的地基，地基没打，后面全白搭。

3. 从零到CUDA跑通：完整实操记录

下面进入实操阶段。到这里为止的步骤都是经过长期验证、可以直接照抄的稳定路径。命令会写清楚，但更重要的是理解每一步在干嘛。

3.1 启用虚拟机平台与WSL2（含离线安装/镜像安装方案）

最简单的方式是使用管理员身份的PowerShell或命令提示符，直接执行官方命令：

wsl --install -d Ubuntu-22.04

这行命令会自动启用“虚拟机平台”和“Windows Subsystem for Linux”两个Windows功能，下载并安装WSL2内核，并把Ubuntu 22.04发行版装好。安装完成后，重启电脑，按提示设置Linux用户名和密码。

如果你的Windows版本相对较老，或者无法使用官方在线安装方式，用两条手动命令启用Windows功能后再安装：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

然后重启，去“Windows功能”里确认这两个选项已勾选。重启后把WSL2设为默认版本：

wsl --set-default-version 2

如果你遇到“wsl2下载慢”或者在线安装失败，可以考虑手动下载方案。去微软官方网站找“WSL2 Linux内核更新包”和“适用于x64的WSL发行版Appx包”，下载后直接双击或使用Add-AppxPackage命令安装。也可以用Ubuntu官网提供的cloud镜像rootfs，通过wsl --import导入——这种方式本质上就是手动安装Linux镜像，适合偏执一点的老玩家。

3.2 Ubuntu初始化与软件源加速

安装完成后，打开WSL终端，建议第一时间做两件事：更新系统和切换软件源。默认的Ubuntu源在国内下载速度时好时坏，换成清华或阿里镜像源能节省大量等待时间。

顺手把软件源更新一下，你需要修改/etc/apt/sources.list，把里面的archive.ubuntu.com替换为镜像站地址，然后执行：

sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential git curl wget

build-essential这组编译工具链是后面安装各种Python包时的隐性前提，没有它很多源码包编译不过，这点新手特别容易忽略。

3.3 把WSL2迁移到D盘，别让C盘胖死

WSL2的发行版默认安装在C:\Users\用户名\AppData\Local\Packages目录下，虚拟磁盘文件动辄三四十GB，C盘很快就会告急。解决方法是把它整体迁移到D盘，而且不需要重装系统。在管理员PowerShell里执行：

wsl --export Ubuntu-22.04 D:\wsl\ubuntu-backup.tar wsl --unregister Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\wsl\ubuntu D:\wsl\ubuntu-backup.tar --version 2

第一条命令导出当前发行版为tar备份，第二条命令从WSL系统中注销这个发行版，第三条命令把之前导出的tar文件导入到D:\wsl\ubuntu目录，并指定使用WSL2模式。

导入完成后有个小坑：默认用户会变成root。手动改回原来的用户名，假设你的用户名是alice，在你的Windows文件资源管理器地址栏输入\\wsl$\Ubuntu-22.04验证位置，然后在WSL里执行：

Ubuntu-22.04.exe config --default-user alice

以后每次打开终端，就自动以alice身份登录了。

3.4 安装CUDA Toolkit与PyTorch GPU版

现在开始处理最核心的环节。我强烈建议用两条路线根据自己的需求选择安装策略：

路线A，你只是使用PyTorch、TensorFlow等等框架跑深度学习，并不打算自己编译CUDA扩展。这种情况下，可以直接跳过完整CUDA Toolkit的安装，只装一个正常的显卡驱动，然后安装PyTorch时选择GPU版本。因为PyTorch官方预编译包已经捆绑了所需CUDA运行时库，足以满足绝大多数训练和推理需求。路线B，你要开发自定义的CUDA算子、编译一些依赖nvcc的项目，那就在WSL2里安装NVIDIA官方提供WSL-Ubuntu仓库的CUDA Toolkit：

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-get update sudo apt-get -y install cuda-toolkit-12-4

安装完用nvcc --version确认编译器版本。这之后与CUDA相关的日常使用一般不会出问题。

接下来建议安装Miniconda，创建一个干净的环境，再安装PyTorch：

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh conda create -n ai python=3.10 -y conda activate ai

注意下面的pip命令必须带上官方CUDA源地址，否则非常容易装成CPU版本：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

这个点我要单独放大强调一下，PyTorch在WSL2里显示“GPU不可用”的案例中，绝大多数原因都是这里这一步出错了。

3.5 五分钟验证GPU是否真正接管计算

安装完毕，验证环节。

第一步，在WSL2里输入nvidia-smi。如果能看到和Windows侧差不多的GPU信息列表，说明系统层面已经打通了。注意这里的nvidia-smi是Linux侧的工具，它拉取的是Windows驱动的GPU信息，所以你会看到类似“Driver Version”的字段。

第二步，以最简单的方式验证PyTorch能用上GPU：

python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

输出2.x.x True就成功了一半。

第三步，做一个真实的计算对比测试：

import torch import time x = torch.randn(4096, 4096, device='cuda') y = torch.randn(4096, 4096, device='cuda') start = time.time() for _ in range(100): z = x @ y torch.cuda.synchronize() print("GPU 100次矩阵乘法耗时:", time.time() - start)

如果这一串能跑下来且耗时在毫秒级，恭喜你，WSL2里的AI开发环境正式跑通了。

4. 常见问题与排查实录

再稳定的方案也有翻车的时候。这节我把过去踩过的、周围同事踩过的、社区里高频出现的问题一并整理出来，作为一个速查手册。

4.1 “wsl2 无法启动，因为此计算机上未启用虚拟机平台”怎么办

这是WSL2部署时遇到频率最高的一条报错。原因通常是两个：BIOS虚拟化设置未启用，或者Windows功能里的“虚拟机平台”没开。

排查顺序很清晰：

1. 按Win + R输入msinfo32，在“系统信息”里看到“基于虚拟化的安全”和虚拟化状态，如果显示“已启用”，说明BIOS没问题。
2. 如果显示“未启用”，重启进BIOS，找到“Intel Virtualization Technology”或“AMD SVM”选项，设为Enabled。
3. 再到“控制面板 > 程序 > 启用或关闭Windows功能”，勾选“虚拟机平台”，重启。

有个细节很隐蔽：如果你电脑上同时装了VMware Workstation或VirtualBox旧版本，可能和Windows Hypervisor发生冲突，导致WSL2起不来。这类场景要么升级虚拟机软件到兼容版本，要么把WSL2作为唯一虚拟化承载环境。

4.2 “WSL2 尚未准备就绪”和“wsl下载慢”的解决思路

这两个问题通常会连着出现。“WSL2尚未准备就绪”多数情况是系统里的WSL2内核或组件版本太旧，和当前发行版的更新进度不匹配。解决方法固定：管理员身份执行wsl --update更新WSL组件，然后重启。

至于“wsl下载慢”，多半发生在wsl --install阶段下载发行版包时。换网络环境属于玄学范畴，真正有效的手段是：第一，给命令加--web-download参数，强制走Web通道下载，有时候比内置通道快数倍；第二，直接去微软官网手动下载WSL发行版Appx安装包，用Add-AppxPackage离线安装；第三，如果只是Ubuntu内部软件源慢，把/etc/apt/sources.list换成镜像站即可，跟WSL2本身无关。

4.3 nvidia-smi不显示、PyTorch用不了GPU的定位方法

先讲定位顺序。nvidia-smi在WSL2里不显示，优先检查Windows侧驱动是否过旧，以及WSL2内核版本是否最新。执行完wsl --update重启后，如果还不行，去Windows设备管理器里看显卡是否正常工作。

如果nvidia-smi正常但PyTorch不能用GPU，问题大概率出在上一节说的pip安装环节：你装的很可能不是CUDA版本的PyTorch。直接用pip list | grep torch查看已装版本号，一般会看到类似torch 2.x.x+cu121的字样，其中cu121就是CUDA 12.1的意思。如果只有2.x.x+cpu，那就删掉重装：

pip uninstall -y torch torchvision torchaudio pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

4.4 显存、内存与性能问题的排障经验

WSL2的显存账面数字往往比Windows侧“看起来少”，原因是Windows桌面自身会占用一部分GPU显存，WSL2能看到的实际是减去桌面占用后的剩余部分。8G显存的显卡，跑着高分辨率桌面，WSL2里能用到六七G已经不错了。遇到显存不足的报错，优先关闭Windows侧占据显存的应用或者降低桌面特效，而不是怀疑WSL2配置。

内存方面，WSL2默认会动态占用系统总内存的50%左右，而且存在缓存回收不及时的问题。解决方案是写配置文件，把内存上限卡死，具体配置在下一节给出。

5. 日常工作流优化与AI开发体验

环境跑通只是第一步，真正舒服的AI开发环境还需要几个日常配置才能顺手。

5.1 用.wslconfig控制WSL2的内存和CPU

在Windows用户主目录下创建.wslconfig文件，内容是：

[wsl2] memory=12GB processors=6 swap=8GB localhostForwarding=true

memory设置为物理内存的一半左右，processors按半数CPU线程设置。不要把这个值设得过大，否则Windows宿主机自己会卡到飞起。配置保存后执行wsl --shutdown再重新启动WSL2让配置生效。

5.2 文件系统别再跨区折腾：代码放Linux侧

这是WSL2优化里最容易忽略也最要命的点。在WSL2里访问/mnt/c开头路径上的文件，并不是直接读取磁盘文件，而是经过Windows和Linux之间的9P协议转发，性能损失可以达到几十倍。同样的Python脚本，代码放在/mnt/c下和放在Linux侧~/projects下，运行速度是两个世界。

所以代码、数据集、虚拟环境全部放在Linux侧文件系统里，Windows侧只保留IDE和浏览器这些图形工具。跨系统共享文件用\\wsl$路径查看即可，但只在需要“看”的时候用，不要在这个路径下跑训练任务。

5.3 WSLg、Jupyter、TensorBoard的桌面环境搭配

WSL2内置的WSLg功能可以直接运行Linux图形程序，并且把窗口投到Windows桌面上，关于这一点，你不需要任何额外配置。但它并不是最常用的AI开发界面，日常更实用的方式是使用浏览器。

比如TensorBoard，直接在WSL2里起服务：

tensorboard --logdir runs

然后在Windows浏览器访问http://localhost:6006即可。Jupyter同理，起服务后Windows侧浏览器访问对应端口，WSL2默认开启了localhost转发，两个环境的网络是打通的。这套组合让你不需要任何图形界面，纯终端加浏览器就能舒服地做完整的AI实验。

5.4 PyCharm与VS Code配置WSL环境

编辑器配置方面，两种主流IDE都有成熟的WSL方案。

VS Code最简单，安装Remote-WSL插件后，在WSL2终端里输入code .命令，就会直接用VS Code打开当前项目，并且在后台为这个项目连接WSL2环境，所有的终端操作、Python解释器选择都默认走Linux侧。

PyCharm的方式也很省事：打开设置，找到“Python Interpreter”，选择“Add”，在类型里选择“WSL”，然后指向WSL2里的conda环境python解释器路径。这样生成的“WSL解释器”配置，跟Windows侧解释器完全隔离。顺带提一句，PyCharm里的AI插件，比如现在社区里比较火的Fitten Code，补全速度和效果都不错，对WSL环境没有特殊限制，装上就能用。

5.5 本地跑大模型推理、微调与多Agent协作的实验场景

环境准备到这里，你已经拥有了一台可以随时秒开的Linux加GPU的AI工作站，接下来可以自然延伸到好几个AI开发场景。

第一类，本地大模型推理。安装了Ollama或VLLM之后，在WSL2里直接启动一个开源模型做推理测试，比在Windows侧装原生版本要顺滑得多，很多依赖Linux生态的工具链在这个环境中开箱即用。

第二类，模型微调。用LoRA或者QLoRA方式微调小模型，WSL2足以处理7B级别模型的单卡低精度微调实验，数据量控制在可接受范围内，跑实验的效率不比双系统差。

第三类，多Agent协作实验。现在Agent框架生态方兴未艾，无论是手写Agent程序还是用开源平台编排多Agent工作流，Linux环境下的进程管理、日志处理、并发调度都远比Windows原生环境顺手。WSL2作为多Agent协作脚本的开发与调试环境，体验非常接近集群节点。如果你正在啃大模型基础理论，想复现论文实验但不想折腾双系统，WSL2完全可以扮演一个耐心、可复用的实验场地。

5.6 配置建议与使用习惯上的心得

关于日常使用习惯，我从踩过的坑里提炼了三条建议。

第一条，建立备份习惯。WSL2环境一旦破坏了，重建一次的成本非常高。建议定期用wsl --export导出一份tar备份，放在固定磁盘上。万一环境崩了，wsl --import恢复到几分钟前，比重新装全套工具链快多了。

第二条，始终保持Windows侧驱动更新到官方最新版本。WSL2的GPU功能跟Windows驱动强耦合，别用老旧驱动，很多看起来怪异的问题在更新驱动后自己消失了。

第三条，别把WSL2当成生产服务器跑重活。虽然WSL2稳定性已经很高了，但它本质上是开发环境，适合调试、原型验证和中小规模实验。真要执行需要长时间跑批的关键任务，我最终都会迁回双系统下的Linux原生环境或者云GPU服务器，这是对自己的数据负责。

我最后再分享一个小技巧：把Windows防火墙中关于WSL2的规则提前放行，并固定使用WSL2推荐的NAT网络模式，这样可以避免很多外部访问的问题。WSL2这个环境搭好后，可以把日常50%左右的AI开发工作全部放进去，Windows侧只保留通信应用和IDE窗口，顺手还不耽误看网页、用微信。对我来说，这种“Windows做图形操作面、Linux做计算工作区”的组合，就是目前本地AI开发的最优解。