用了小半个月把一台 Windows 工作站的 AI 开发环境从“双系统折腾”收敛到“WSL2 内核级 Linux + GPU 直通”这套方案，期间踩了不少坑，也绕开了很多网上过时的教程。WSL2 这套组合这几年已经非常能打了：里面是真正的 Linux 内核，外面直接调用 Windows 宿主的 NVIDIA 显卡计算资源，AI 训练、推理、调试全都可以在一条链路里完成。这篇文章把我的完整部署过程、底层逻辑和排查经验整理出来，适合想在 Windows 上快速做 AI 开发、又不想放弃图形界面操作习惯的人参考。
1. 为什么我会选择 WSL2 来做 AI 开发环境
1.1 双系统、Docker、WSL2 三者的取舍
先说双系统。我最早就是 Windows + Ubuntu 双系统，每次切系统都要重启，训练任务在里面跑着的时候，外面的微信、Office 全部断掉。虽然可以 SSH 进去看训练日志，但日常操作始终隔了一层。更重要的是，AI 开发往往需要反复改代码、看可视化结果、截图保存，这种工作流放在双系统里非常割裂。
Docker 是另一个常见选择，尤其是 Docker Desktop 配合 Windows 容器模式。但容器本身是共享宿主内核的，在 Windows 上跑 Linux 容器必须有一层虚拟机兜底，GPU 直通配置起来比 WSL2 繁琐得多。加上容器内改环境、调试 CUDA 版本、访问 GUI 程序（比如可视化调试器、TensorBoard）都有额外的端口和显示转发成本，做一个“日常开发环境”并不是它最擅长的事。
WSL2 的定位正好卡在两者之间：它是一个采用 Hyper-V 架构的轻量级虚拟机，跑的是未经裁剪的完整 Linux 内核，但启动时间可以做到秒级，内存和 CPU 又可以按需动态调整。更重要的是微软和 NVIDIA 在 GPU 虚拟化这一层做了原生支持，WSL2 里的 CUDA 程序可以调用宿主机显卡，跑起来接近裸机性能。对 AI 开发者来说，这是目前门槛最低、也最贴合“Windows 干活 + Linux 训练”组合的方案。
1.2 WSL2 到底解决了什么问题
刚接触 WSL2 的人容易把它理解成“虚拟机”，但它和 VirtualBox、VMware 那类传统虚拟机的体验完全不同。传统虚拟机一开机先吃掉固定内存，磁盘镜像文件动辄几十 GB，启动一次还要等完整内核引导。WSL2 的内核由微软统一维护，启动时直接加载，资源占用远低于完整虚拟化方案，而且内存可以根据当前进程压力动态调整。
另外一个容易被忽略的点：WSL2 的文件系统是原生的 ext4，存放在一个 VHDX 虚拟磁盘里，性能比 WSL1 那种在 Windows 文件系统上做翻译层的方式强很多。调用路径从“Windows API -> 翻译 -> Linux 调用”变成了“Hyper-V 虚拟机里的原生内核调用”，这正是训练脚本频繁读写缓存、模型权重时最需要的东西。
再加上 WSLg 的存在，Linux 下的 GUI 程序可以直接弹窗显示在 Windows 桌面上，不需要额外配 X Server。这意味着我可以在 WSL 里跑 Jupyter、跑带界面的 PyTorch 调试工具、甚至直接打开基于 Qt 的标注软件，体验和原生 Linux 几乎没有差别。
2. 动手前先搞清楚 GPU 直通的底层原理
2.1 WSL2 是怎么把显卡“借”给 Linux 的
很多人第一次看到 WSL2 里的nvidia-smi和宿主机输出一样时，会误以为 WSL2 里安装了 NVIDIA Linux 驱动。实际上在 WSL2 里，你不需要也不应该安装 NVIDIA 的 Linux 驱动。这里的实现方式是 GPU 半虚拟化（GPU-PV）：WSL2 虚拟机内部暴露了一个/dev/dxg设备，应用程序通过 DXG 接口把 D3D12 命令转发给 Windows 宿主的图形内核，再由宿主机的 NVIDIA 驱动真正执行计算。
这也就解释了为什么驱动更新只需要在 Windows 侧做一次：宿主机驱动负责把 CUDA 调用映射到显卡硬件，Linux 侧只需要安装 CUDA Toolkit 和 cuDNN 这类用户态库。简单类比一下：Windows 宿主机是“房东”，显卡是“家政阿姨”，Linux 想让她干活不用自己重新雇佣一个阿姨，而是通过中间人（/dev/dxg）直接下指令。
对 AI 开发来说这个设计还有个额外好处：WSL2 里做 CUDA 版本切换时，不需要担心驱动冲突，因为驱动层整个是宿主的，想换 CUDA Toolkit 版本无非就是改软件仓库里的安装包，风险小很多。
2.2 在 WSL2 里跑 CUDA 的前置条件
先说硬件，NVIDIA 显卡是必须的，GeForce、Quadro、Tesla 系列都可以。如果是 AMD 或 Intel 独显，目前跑 AI 框架基本都是靠 ROCm 或 OpenCL，支持度比 CUDA 生态差不少，这里只讨论 NVIDIA 平台。
系统的要求上，Windows 10 21H2 以上或 Windows 11 都可以。这里有一个容易踩的坑：很多教程只说“安装 NVIDIA 驱动”，但驱动版本不能太老。微软和 NVIDIA 约定的 WSL2 支持机制要求驱动支持 WDDM 2.9 以上的 GPU 调度接口，我在实际测试中发现，如果驱动版本低于 470 系列，WSL2 里大概率会看到nvidia-smi报“No devices were found”。所以第一步不是急着进 Linux 装东西，而是先把 Windows 侧的显卡驱动升到足够新。
另外要确认 BIOS 里的虚拟化技术（Intel VT-x / AMD-V）已经打开，因为 WSL2 本质是虚拟机，这道开关没开的话后续所有步骤都会卡住。
2.3 硬件与系统版本建议
这只是我自己的配置参考，不代表最低要求：
| 组件 | 最低建议 | AI 开发舒适配置 |
|---|---|---|
| CPU | 4 核 x86_64 | 8 核以上 |
| 内存 | 16 GB | 32 GB 以上 |
| 显卡 | GTX 1060 6G | RTX 3060 12G 以上 |
| 磁盘 | SSD，剩余 30 GB | 1 TB NVMe，单独分给 WSL |
| 系统 | Win10 21H2 / Win11 | Win11 最新版 |
为什么强调显存 12G？因为现在很多开源大模型的量化版、LoRA 微调需求动辄 6~10G 显存，低于这个容量连试跑都勉强。内存我也建议 32G，因为 WSL2 默认会拿物理内存的 50% 作为上限，如果宿主机只有 16G，训练时 Windows 侧会卡到鼠标都拖不动。
3. WSL2 完整部署流程（实操篇）
3.1 启用 WSL2 与虚拟机平台
这一步是所有操作的基础，在管理员权限的 PowerShell 里执行两条命令：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart第一条开启“适用于 Linux 的 Windows 子系统”，第二条开启“虚拟机平台”。执行完需要重启电脑。如果用的是新版 Windows，也可以直接一条命令搞定：
wsl --install它会自动开启所需功能，并安装默认的 Ubuntu 发行版。不过我建议装完后手动确认一下默认版本是不是 WSL2：
wsl --set-default-version 2这条命令的作用是确保后续所有发行版都以 WSL2 模式运行，否则回到 WSL1 的话，GPU 直通和真实内核都不存在，后面所有内容都白搭。
3.2 安装 Ubuntu 22.04 并迁移到 D 盘
安装发行版最省事的是：
wsl --list --online wsl --install -d Ubuntu-22.04但很多人会在这里卡住，因为wsl --install默认把文件写到 C 盘用户目录下，Ubuntu 的 VHDX 虚拟磁盘如果不是刚创建时很小，等装完 Python、CUDA、PyTorch 再加几个数据集，C 盘很快就爆了。
所以我的建议是：一开始就规划好“发行版系统盘”的位置。比如我想放在 D:\WSL\Ubuntu-22.04，操作思路是先正常装，装完再迁移。迁移命令非常直白：
wsl --shutdown wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu.tar wsl --unregister Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl-backup\ubuntu.tar --version 2这里有个经验：导出的 tar 文件会很大，动辄几个 GB，导出前建议先把apt缓存和已下载的临时包清一清。另外，--import之后默认登录用户会变成root，如果你不喜欢，可以用下面的方式改回默认用户：
先在C:\Users\<你的用户名>\.wslconfig里写：
[wsl2] default=<你的用户名>或者在导入后的根目录/etc/wsl.conf里加：
[user] default=yourname我推荐用/etc/wsl.conf的方式，因为它是跟着 Linux 系统走的，以后导出发行版给别人也不用再改一遍。
3.3 从镜像站下载发行版解决“下载慢”问题
如果你执行wsl --install -d Ubuntu-22.04时一直卡在下载步骤，大概率是默认下载源不顺畅。这种情况下别硬等，可以绕开微软商店和在线下载，直接从国内镜像站拿 rootfs tar 包，再用wsl --import导入。
清华、中科大、阿里等镜像站都有 Ubuntu 的 WSL rootfs 下载。具体导入命令如下：
wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\downloads\ubuntu-22.04-rootfs.tar.gz --version 2把文件路径换成实际下载位置即可。这个方案的好处有两个：第一是下载速度快到让人感动，全程几分钟搞定；第二是 rootfs 包不受微软“系统版本匹配”限制，你想导入 20.04、22.04、24.04、Debian、openSUSE 都行，只需确保是支持 WSL2 的发行版即可。
进入系统后第一件事，我建议做一次完整更新：
sudo apt update && sudo apt upgrade -y sudo apt install build-essential git curl wget python3-pipbuild-essential 是编译很多 CUDA 扩展的刚需，git 和 python3-pip 就不用说了，AI 环境里一天不碰它们都不可能。
4. 在 WSL2 内部搭建 GPU AI 训练/推理环境
4.1 安装宿主机驱动与 WSL2 内 CUDA 工具链
第一步先回到 Windows 侧把 NVIDIA 驱动更新到最新。这一步很多人会忽略，以为之前装过驱动就行。实际我在一台驱动停留在 512 版本的机器上试过，WSL2 里nvidia-smi直接报错；升级到 560 版本后一切正常。所以原则就是：Windows 驱动越新越好，不需要在 WSL2 里再装任何与驱动相关的东西。
然后进入 WSL2，添加 NVIDIA WSL 专属的 CUDA apt 仓库：
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接着安装 CUDA Toolkit：
sudo apt install cuda-toolkit注意这里我装的是cuda-toolkit，不是cuda，也不是nvidia-driver。网络上有些老的教程会让人执行sudo apt install cuda，那个包会连带安装 NVIDIA 的 Linux 驱动，在 WSL2 里属于多余的，还可能和宿主驱动产生冲突。安装完后验证一下：
nvcc --version nvidia-smi你可能会发现nvcc --version显示的 CUDA 版本和nvidia-smi显示的 CUDA 版本不一样。这是正常的：nvcc是编译器工具链的版本，nvidia-smi显示的是宿主机驱动“当前支持到的最大 CUDA 版本”，两者用途不同。
4.2 验证 GPU 可见性与安装 PyTorch
用一条命令确认 WSL2 里能看见 GPU：
nvidia-smi如果能看到类似下面的输出，说明 GPU 直通已经生效：
+-----------------------------------------------------------------------------+ | NVIDIA-SMI 560.94 Driver Version: 560.94 CUDA Version: 12.6 | +-----------------------------------------------------------------------------+接着装 PyTorch。这里给一个我用起来很稳的命令：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121如果你前面装的 CUDA Toolkit 是 12.1，就用cu121；如果是 12.6，也可以直接用默认的 PyTorch 稳定版（它会自动匹配最新 CUDA）。但显式指定 index-url 的好处是，可以保证没有装错 CPU 版本。很多新手遇到torch.cuda.is_available()返回 False，一半以上是因为pip install torch装到了 CPU 版。
验证 GPU 可用性：
import torch print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))如果三条分别输出True、1、NVIDIA GeForce RTX 3060，说明 PyTorch 已经可以正常使用 WSL2 透传过来的 GPU。顺手跑一个简单张量测试：
import torch print(torch.randn(1000,1000).cuda() @ torch.randn(1000,1000).cuda())你会发现结果秒回，没有任何“CUDA driver version is insufficient”之类的报错。这就是 WSL2 和原生 Linux 体验几乎一致的最直观感受。
4.3 配置 VS Code 与 Jupyter 开发链路
开发环境不能只有命令行，我每天的主体工作还是在 VS Code 里写代码。VS Code 和 WSL2 的配合是天然无痛的：在 Windows 侧安装好 VS Code 后，打开 WSL2 终端，直接输入：
code .VS Code 会自动以 Remote-WSL 的模式连接当前目录。左下角会出现一个绿色的“WSL: Ubuntu-22.04”标识，这意味着插件、Python 解释器、终端都运行在 Linux 环境内，Windows 侧只是个图形壳。我可以直接选择 WSL 内的 Python 解释器来运行和调试代码，完全不需要手动配置 SSH 或者远程解释器路径。
Jupyter 的用法也值得单独说一句。在 WSL 里启动：
jupyter notebook --no-browser --port=8888然后 Windows 浏览器直接访问http://localhost:8888即可。这是因为 WSL2 的端口会自动转发到 Windows 的 localhost，不需要额外配置端口映射。我经常这样开着 Jupyter 跑实验，Windows 侧用浏览器看 TensorBoard、检查 loss 曲线，体验非常顺滑。
如果你习惯 PyCharm，可以用它的“远程解释器”功能连接到 WSL，本质上是调用 WSL 里的 Python 环境，和 VS Code Remote 是同一个思路。不过 VS Code 因为插件生态更适合混着用，我还是推荐作为主力。
5. 常见问题排查与避坑实录
5.1 WSL2 尚未准备就绪 / 启动报错
这个错误基本可以分成两类。一类是内核没有更新，表现为执行任意 WSL 命令都提示“WSL 2 尚未准备就绪”。解决办法是在管理员 PowerShell 里执行：
wsl --update如果更新失败，可以去微软官方下载对应的 WSL2 内核安装包，手动执行 MSI。安装完记得重启电脑。
另一类是虚拟化平台没打开，尤其是自己组装机或老笔记本，BIOS 里默认可能把 SVM/VMX 关了。重启进 BIOS，找到“Intel Virtualization Technology”或“SVM Mode”打开即可。这类问题最容易让人绕远路，其实只需进一次 BIOS。
5.2 内存占用过高导致 Windows 卡顿
WSL2 的默认策略是使用宿主机物理内存的 50% 或 8GB 两者中的较大值，如果宿主内存 64GB，WSL2 可能直接吞掉 32GB，导致 Windows 侧资源紧张。这时候需要在用户目录的.wslconfig文件里限制资源：
[wsl2] memory=12GB processors=6 swap=8GB改完后执行wsl --shutdown再重启 WSL 才会生效。这里有个经验点：训练模型时如果 WSL2 内直接 OOM，不一定是你显存不够，而是.wslconfig里的内存上限太小，导致 PyTorch 无法分配足够的 CPU 内存做缓存。建议把 swap 也调大一点，避免大模型加载权重时直接崩溃。
5.3 GPU 不可见 / CUDA 初始化失败
如果nvidia-smi能正常显示，但一跑 PyTorch 就报CUDA error: no kernel image is available for execution on the device，这通常是 PyTorch 版本与显卡计算能力不匹配。老显卡（比如 Maxwell 架构）需要装旧版 PyTorch；新显卡如果装的是太老的 PyTorch，也会出现内核镜像缺失。解决办法是升级 PyTorch 到最新版，或者切换到对应 CUDA 版本的 wheel。
还有一种情况是nvidia-smi什么都看不到，但nvcc --version正常。这种情况优先怀疑宿主机驱动太老，或者 WSL2 里误装了 Linux 版 NVIDIA 驱动。如果你之前执行过sudo apt install nvidia-driver-*，那就得把它卸掉再重启 WSL：
sudo apt purge nvidia-driver-* nvidia-kernel-* cuda-drivers wsl --shutdown5.4 网络源、Docker 与 systemd 配置
WSL2 里下载慢的问题，除了前面说的换镜像站装发行版外，装完系统后也可以把 apt 源换成国内镜像。这里我以自己的经验举例：编辑/etc/apt/sources.list或/etc/apt/sources.list.d/ubuntu.sources，把archive.ubuntu.com替换为国内镜像地址，然后sudo apt update。这一步能显著减少装 Python 包、CUDA 依赖时的等待时间。
另外，新版 WSL2 默认支持 systemd。如果你需要在 WSL 里跑 Docker、SSH、定时任务等服务，建议在/etc/wsl.conf里加这样一段：
[boot] systemd=true然后在 WSL 里安装 Docker 引擎：
curl -fsSL https://get.docker.com | sh装完执行sudo systemctl enable --now docker。这样 WSL2 就变成了一个能跑 Docker 容器的 Linux 开发机。我经常在 WSL2 里直接拉 PyTorch 官方的 Docker 镜像，跑一个隔离的推理服务，Windows 宿主用localhost:8888访问，整个流程完全不需要 Docker Desktop。
如果要把 WSL2 里的服务暴露给局域网其他设备（比如让同事访问你起的推理 API），默认 NAT 模式下会有端口转发限制。新版 WSL2 提供了一个镜像网络模式，在.wslconfig里加networkingMode=mirrored就能让 WSL2 共享宿主的网络接口，外网设备可以直接访问 WSL2 内的服务端口。
6. 实测性能与个人体会
6.1 一个不严谨但真实的性能对比
我在同一台机器上分别用原生 Ubuntu 双系统和 WSL2 做了一次小规模微调测试，任务是对一个小型 BERT 模型做文本分类训练，固定 batch size 和 epoch。结果大致是：纯 GPU 计算部分两者相差不到 5%，WSL2 的主要损耗发生在文件 IO 和 CPU 内存访问环节。如果你跑的是大型矩阵运算密集的任务，比如 Stable Diffusion 出图、大模型推理，基本感受不到区别。
能把损耗压到这么低，关键还是 WSL2 用了原生 Linux 内核和原生文件系统。相比 WSL1 把所有文件操作都翻译成 Windows 调用，WSL2 的计算路径干净太多。唯一需要留神的是不要在/mnt/c/下直接训练，跨文件系统访问才是性能杀手。正确做法是：把数据集放到 Linux 文件系统内，也就是 WSL 的 home 目录下，通过/mnt/d/导入后再复制进去。
6.2 我对这套方案的真实评价
用了这段时间，我对 WSL2 做 AI 开发环境的定位有了明确判断：它最适合的场景是单卡、个人开发、快速原型验证。Windows 上正常办公，WSL 里跑模型训练，两边互不打扰，这是双系统给不了的体验。代码改完直接在 VS Code 里一键调试，数据可视化在浏览器里完成，整个过程没有任何“为了用 Linux 而折腾”的额外负担。
但它也不是万能的。如果你要跑多卡分布式训练，或者要长期挂机跑几十个小时的任务，我还是会建议直接上原生 Ubuntu 服务器，省掉虚拟化层的资源开销和管理复杂度。另外，WSL2 的虚拟磁盘文件（VHDX）会随着使用不断膨胀，即使你在 Linux 里删了大量文件，宿主机上看到的磁盘占用也不会自动缩小。我习惯每隔一段时间用wsl --shutdown后，在 PowerShell 里执行Optimize-VHD或直接对 VHDX 做压缩，这个操作对磁盘空间紧张的人非常关键。
最后分享一个小技巧：如果你在 WSL2 里用 CUDA 训练时偶尔遇到显存不释放，不要急着重启电脑，直接在 WSL2 里跑wsl --shutdown再重新进入即可。它会把整个虚拟机和 GPU 上下文全部重置，比 Windows 侧重启或杀进程省事得多。我自己把这个命令做成了 PowerShell 脚本，一键关闭 WSL、等待几秒、再自动打开，基本不会再被显存残留问题困扰。
