想在一台 Windows 电脑上正经跑 AI 开发其实挺拧巴的。身边不少朋友第一反应是装个双系统结果不是 Ubuntu 分区被搞没就是来回切换系统麻烦到直接放弃也有人干脆买云 GPU 实例但本地调试、开个 notebook、挂个小模型推理按月按小时扣费真心不划算。我自己折腾过一圈之后目前最顺手的一套方案是让 Windows 11 里跑一个真正的 Linux 内核再让这块显卡同时伺候 Windows 桌面和 Linux 里的 AI 任务——没错说的就是 WSL2 GPU 直通。这套组合对一个做 AI 的开发者来说几乎是“白嫖”级别的快乐Windows 日常办公、微信截图、浏览器全都留着Linux 环境干净利落没有双系统切换的时间成本也不用担心虚拟机里显卡性能被阉割。关键是 WSL2 不是那种阉割版玩具它是一个拥有完整 Linux 内核的轻量虚拟机配合微软和英伟达做的半虚拟化方案CUDA 运算性能基本贴着原生走。这篇就按我实际操作的顺序从原理到踩坑把它完整拆给你。1. 为什么不用双系统WSL2 到底是什么1.1 WSL2 与 WSL1 的本质区别早期 WSL1 其实是一个系统调用翻译层微软在 Windows 内核里实现了一堆 Linux 系统调用让 Linux 程序以为自己跑在 Linux 上但它不是真的 Linux没有自己的内核。遇到涉及底层内核特性的东西会翻车比如 Docker 就依赖 cgroups 和 namespacesWSL1 基本跑不起来。WSL2 就不一样了。微软直接做了一个轻量级虚拟机里面跑一个真正的 Linux 内核虽然是微软维护的定制版但内核版本跟随主线更新系统调用是 100% 原生的。你把 Ubuntu 22.04 装进去它就是一台不折不扣的 Linux 机器。Docker、systemd、iptables 这些以前搞不定的东西现在全都正常了。因为基于 Hyper-V 虚拟化技术WSL2 的启动方式也变了。它不像传统虚拟机那样开机就要等几十秒而是“按需启动”你打开终端敲一条wsl命令几秒钟内就能进入到 Linux shell速度体感上和打开一个普通终端差不多。内存占用也比较克制默认只吃系统空闲内存的一半不用的时候随着进程退出会释放一部分资源不会一直占着大块内存不还。很多 AI 项目都依赖 Docker 来做环境隔离比如跑 Stable Diffusion 的整合包、部署推理服务WSL2 里装 Docker Desktop 是完全顺畅的。这也是我最终抛弃双系统的核心原因之一既有 Linux 的真内核又有接近虚拟机的隔离性同时还能保持 Windows 侧的日常使用。1.2 它到底是怎么把显卡分给你的 Linux 的这里得先澄清一个容易混淆的概念WSL2 让 Linux 用上 NVIDIA 显卡靠的并不是传统的“PCIe 直通”。传统直通DDADiscrete Device Assignment会把整张显卡直接分配给某一个虚拟机独占宿主机自己反而没法用了这对单显卡用户来说是行不通的。微软的方案是半虚拟化。在 WSL2 的 Linux 内核里有一个名为dxgkrnl的驱动模块它把 Windows 图形内核的 GPU 能力“暴露”给 Linux 侧。CUDA 调用链是PyTorch → CUDA 用户态库 → WSL2 内核 dxgkrnl → Windows GPU 驱动 → NVIDIA 显卡关键点在于WSL2 里的 CUDA 用户态库直接映射到 Windows 驱动的 GPU 地址空间没有额外的数据拷贝关卡。也就是说显存里的数据在 Linux 和 Windows 侧其实是同一份物理资源指令下发路径几乎是直的。所以理论上性能损耗非常小NVIDIA 官方给的宣传是“接近原生”我自己实测跑小规模训练和推理和双系统 Ubuntu 的差距基本可以忽略。当然这也意味着依赖关系Linux 侧不需要装 NVIDIA 显卡驱动但 Windows 侧必须有完整的官方驱动CUDA Toolkit 的版本要和 Windows 驱动所能支持的版本匹配。这个我放在后面的实操部分细讲。1.3 什么时候不适合用 WSL2把 WSL2 捧得再高它也有自己的软肋。首先它毕竟是个虚拟机没法完全替代物理 Linux 做驱动级开发。比如你要做嵌入式开发、写 Linux 内核模块、玩 BPF 这类涉及硬件抽象层的活儿还是得老实开个真机。其次如果你做的是外接 USB GPU、多卡互联这种重硬件场景WSL2 支持得也不好。虽然新的 Windows 版本支持 USB 设备重定向但 GPU 领域的复杂设备比如 TensorRT 盒子就别指望了。还有一个现实问题如果你有 N 卡但只是做 CPU 推理或者用的是 AMD/Intel 显卡做 ROCm/oneAPI那 WSL2 的 AI 加速支持就大打折扣官方支持的生态还是以 CUDA 为主。Intel 显卡在 Windows 侧的 DirectML 能凑合用但和 CUDA 的成熟度没法比。所以整个文章接下来的核心路径默认你的机器是 Windows 10/11 NVIDIA 显卡。这同时也是市面上最容易复现、资料最多、坑最少的一条路线。2. 环境搭建从开启虚拟化到装好 Ubuntu 22.042.1 前置检查与系统功能开启动手装之前先确认两件事你的 Windows 版本至少是 2004 或更高推荐直接用 Windows 11BIOS 里必须开启虚拟化现在新机器基本默认开但有些主板出厂默认是关的一旦后面装完报错“此计算机上未启用虚拟化”第一反应就要来查这里。确认方式很简单打开任务管理器 → 性能 → CPU右下角看“虚拟化”那一栏显示“已启用”就说明没问题。如果显示“已禁用”就需要重启进 BIOS找到 Intel VT-x 或 AMD-V/SVM 的选项打开后保存退出。接着以管理员身份打开 PowerShell输入两条命令启用两个 Windows 功能dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart第一条开 WSL 功能第二条开虚拟机平台两个都必须成功。执行完重启电脑重启之后见到“WSL 尚未准备就绪”这类提示的概率会低很多。2.2 用 wsl --install 装完整个工具链Windows 11 系统上其实还有更省事的办法一条wsl --install就能把 WSL 内核、虚拟机平台、默认发行版全都装上。但首次执行时它默认装的是 Ubuntu 最新版本而且从网络拉发行版镜像的速度经常让人崩溃。所以我更推荐分开装这样每一步出现问题时都能准确定位。先手动设置 WSL 默认版本为 2wsl --set-default-version 2然后安装指定版本。AI 开发圈用 Ubuntu 22.04 的仍然占多数因为 CUDA、PyTorch 等生态对 LTS 版本的支持最成熟。命令如下wsl --install -d Ubuntu-22.04这个步骤会自动从微软的发行版仓库下载镜像。如果遇到下载速度奇慢无比或者卡在 0%几乎一定会遇到别死等。可以打开微软商店先搜索 Ubuntu 22.04 安装或者用wsl --import从离线 rootfs 包导入。后者稍麻烦但成功率最高后面专门讲。装的过程中会提示你设置 Linux 的用户名和密码这个和 Windows 的用户是独立的别嫌麻烦直接回车跳过后面很多操作都要用 sudo。2.3 把 WSL 挪到 D 盘逃离 C 盘爆满WSL2 的虚拟磁盘默认放在C:\Users\你的用户名\AppData\Local\Packages\下面一个 Ubuntu 镜像轻松吃掉 20-30GB这还不算后续装的 conda 环境和模型文件。如果你的 C 盘不是大容量固态建议第一时间把整个发行版迁移到其它盘。这个操作其实不复杂核心是 WSL 的导出导入功能# 先把发行版关闭 wsl --shutdown # 导出当前系统到 D 盘 wsl --export Ubuntu-22.04 D:\wsl\ubuntu-22.04.tar # 注销原系统 wsl --unregister Ubuntu-22.04 # 重新导入到 D 盘 wsl --import Ubuntu-22.04 D:\wsl\ubuntu-22.04 --version 2有个坑要提醒你wsl --export导出的 tar 体积可能很大动辄十几 GBD 盘要提前准备够空间。另外--import导入的新系统默认的默认用户是 root没有你之前创建的普通用户。这会导致后续文件权限比较混乱需要通过wsl --manage或者修改/etc/wsl.conf配置文件来设置默认用户。简单点的方法是重新创建一个用户或者干脆忍受 root 登录等环境搭完再处理权限。说到底迁移最好在装完基础环境之后、开始装 AI 工具链之前做。这样迁移的是干净的系统镜像体积小、速度快后患也少。2.4 第一件事更新、换源、装基础工具首次进入 WSL 的 Ubuntu第一件事永远是更新软件源信息。默认源在国内访问速度很差我一般都直接换成清华或者阿里云的镜像源。Ubuntu 22.04 的源配置文件路径是/etc/apt/sources.list有些新版本改成了/etc/apt/sources.list.d/ubuntu.sources用ls查看具体存在哪个。把源里面的archive.ubuntu.com替换成镜像站地址后执行sudo apt update sudo apt upgrade -y这一步会消耗几分钟到十几分钟不等取决于你的网速。升级完顺手装几个基础工具后面省很多事sudo apt install -y build-essential git curl wget vim net-tools别小看这条命令build-essential编译时缺不了git是拉代码刚需curl和wget是下载工具vim则是所有 Linux 环境里最后的编辑兜底。在此之后我强烈建议你顺手看一眼 WSL 版本确认没降级wsl --status里面能看到默认版本是否为 2。有时候系统自动把新装的发行版默默设成了 WSL1那 GPU 直通就完全没戏了必须提前确认。3. 打通 GPUWSL2 里的 CUDA 环境3.1 为什么 Linux 侧不用装 NVIDIA 驱动这是新手最容易搞混的地方。在正常的 Linux 物理机上装 CUDA 环境要先去 NVIDIA 官网下载对应内核版本的显卡驱动然后再装 CUDA Toolkit。但在 WSL2 里这条流程会被彻底颠覆。WSL2 的 Linux 内核运行在微软定制架构上它不直接管理 PCIe 硬件所以不需要 Linux 版的驱动。你只需要在 Windows 侧安装完整版 NVIDIA 驱动然后在 WSL2 内部通过 Windows 驱动栈间接访问 GPU。这意味着你不需要在 WSL2 里执行nvidia-driver-xxx的 apt 安装你的显卡驱动版本跟着 Windows 更新走而不是跟着 Linux 内核走Linux 侧只装 CUDA Toolkit 和 cuDNN 这些用户态库就够了这个设计可以说是 WSL2 里最让人舒爽的部分。以前 Linux 显卡驱动出问题经常是内核一升级驱动就编译失败现在完全没有这个问题。3.2 Windows 驱动侧的准备即便 Windows 侧已经有了 NVIDIA 驱动也建议先确认版本足够新。WSL2 的 CUDA 支持要求驱动版本至少为 470.76现在随便一个比较新的驱动都远超这个底线但如果你用的是很老的企业版或工作室驱动还是先更新一下比较稳妥。更新驱动建议直接去 NVIDIA 官网下载对应显卡型号的最新驱动。这里有个小经验打游戏选 Game Ready做开发选 Studio 驱动。对 AI 开发来说 Studio 驱动更稳它在 CUDA 相关任务里的兼容性测试更充分建议优先选它。装好驱动后在 Windows 的 PowerShell 里执行nvidia-smi能看到显卡型号、驱动版本、显存信息说明 Windows 侧已经就绪。此时驱动的 CUDA 版本会被 WSL2 延续使用比如驱动显示支持 CUDA 12.4那 WSL2 里的 CUDA Toolkit 就要选 12.x 而不是 13.x版本对不上很容易出现奇怪的运行时报错。3.3 在 WSL2 里安装 CUDA Toolkit在 WSL2 里安装 CUDA Toolkit 有两种主流方法用 NVIDIA 提供的 apt 仓库或者用 runfile 离线安装。我推荐用 apt 仓库因为后续升级和卸载都方便。NVIDIA 官方为 WSL 专门提供了软件源安装命令是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然后安装特定版本的 toolkit。个人建议别直接装默认最新版先apt-cache search cuda-toolkit看看可用的版本再选一个与 Windows 驱动兼容的。以 CUDA 12.4 为例sudo apt install -y cuda-toolkit-12-4这里有个很实用的细节apt 装 toolkit 时千万不要连 NVIDIA 驱动一起装。如果apt install cuda会拉进一堆东西但cuda-toolkit-12-4只装工具库不含驱动。装完后把 CUDA 路径写进~/.bashrcexport PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后source ~/.bashrc生效。3.4 用 nvidia-smi 和 PyTorch 做第一轮验证装完 toolkit先跑一下核心验证nvidia-smi如果你看到的是显卡信息、驱动版本和 CUDA 版本就说明 GPU 已经被 WSL2 完美识别了。这里有个很有意思的现象nvidia-smi显示的驱动版本指的是 Windows 侧的驱动因为 Linux 侧压根没驱动。所以你在 WSL 里用nvidia-smi看到的 CUDA 版本其实是 Windows 驱动支持的最高版本。接下来验证 CUDA 能否真正干活。创建一个测试文件test_gpu.pyimport torch print(CUDA available:, torch.cuda.is_available()) print(GPU count:, torch.cuda.device_count()) print(GPU name:, torch.cuda.get_device_name(0)) a torch.randn(1024, 1024, devicecuda) b torch.randn(1024, 1024, devicecuda) c torch.matmul(a, b) print(Matmul ok, result on GPU:, c.device)能打出CUDA available: True和你的显卡型号GPU 直通就算彻底打通了。这条验证路径比单纯看nvidia-smi更关键因为它测的是实际计算路径而不仅仅是驱动握手。4. 真实跑一个 AI 项目环境联调与性能观察4.1 安装 Miniconda 构建 Python 环境AI 开发绕不开 Python而 Python 环境的管理我强烈推荐用 Miniconda 而不是直接在系统 Python 里装包。理由很简单AI 项目对 Python 版本、CUDA 版本、包依赖的要求经常互相冲突conda 的虚拟环境隔离能把这种冲突矛盾降到最低。在 WSL2 里安装 Miniconda 的标准流程是wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装过程中一路 yes最后把 conda 初始化到 shell 里。如果你不想让 conda 每次都自动激活 base 环境可以用conda config --set auto_activate_base false把这个默认行为关掉省得每次打开终端都要等环境切换。然后为 AI 项目建一个独立环境conda create -n ai python3.10 -y conda activate aiPython 3.10 是目前 PyTorch 生态兼容性最好的版本老库新库基本都能跑。如果项目代码非常新再考虑 3.11 或 3.12但默认 3.10 出错概率最低。4.2 安装 GPU 版 PyTorch 与依赖PyTorch 的安装是 AI 环境搭建中变数最多的一步不同 CUDA 版本对应不同安装命令搞错很容易出现“装上了但用不了 GPU”的尴尬局面。在 WSL2 环境里安装 GPU 版 PyTorch 的命令通常长这样pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124里面cu124的含义是 CUDA 12.4。如果你的 Windows 驱动支持的是 CUDA 12.1 或 12.3把后缀改掉就行。这里有个省事的小技巧直接访问 PyTorch 官网首页它会根据你选择的系统、CUDA 版本自动生成安装命令复制过来执行即可不要凭记忆手写。需不需要用 conda 装 PyTorch我个人觉得 pip 更省心。pip install速度更快而且 PyTorch 官方对 pip 包的测试覆盖最完整。conda 版本偶尔会遇到和 CUDA 库版本不匹配导致运行时报错的问题排查起来比较痛苦。如果你想在 WSL2 里用 TensorFlow 或 JAX也一样先去官方文档复制对应命令。TensorFlow 现在默认pip install tensorflow装的就是 GPU 版前提是 CUDA 相关库已经在 conda 环境里或者被自动拉入了。4.3 跑通训练/推理脚本并观察显存环境装好之后光跑一个矩阵乘法还不够我建议拉一个真实模型做一次端到端验证。比如用 torchvision 里现成的 ResNet50 跑一次随机数据的推理import torch import torchvision.models as models model models.resnet50(weightsNone).cuda() model.eval() x torch.randn(1, 3, 224, 224).cuda() with torch.no_grad(): y model(x) print(y.shape)这个脚本能一次性验证模型加载、前向传播、显存分配三条链路。如果中途报错最常见的几种情况是显存不足小模型都跑不动说明 CUDA 环境有更底层的问题module torch has no attribute cuda说明 CPU 版包被装了重新按 GPU 版命令安装即可如果再想压测一点性能可以用nvidia-smi dmon实时监控显存利用率和 GPU 利用率或者用nvitop这种更现代的工具。在 WSL2 里跑出来的数据和物理 Ubuntu 下基本没有肉眼可见的差异至少我测下来 ResNet 系列、YOLOv8 这类模型吞吐量差距都在 3% 以内。这也是 WSL2 和传统虚拟机的本质差别所在。VMware/VirtualBox 里装 UbuntuGPU 是用软件模拟的跑 CUDA 慢到怀疑人生而 WSL2 因为没有中间层的二次拷贝所以几乎不损失性能。4.4 Windows 与 WSL2 的协作姿势环境跑通后代码和数据放在哪里是个更容易被忽略但影响体验的大事。WSL2 访问 Windows 文件系统是通过/mnt/c、/mnt/d这种路径挂载的但从 Linux 侧读写 Windows 盘上的文件性能会打一个不小的折扣尤其涉及大量小文件编译、数据集读取时速度差距非常明显。所以我的习惯是代码项目放在 WSL2 内部文件系统比如~/projects/数据集或大文件放在 Windows 盘需要时通过/mnt/d/data这类路径引用。编程和编辑代码通过 VS Code 的 Remote-WSL 插件完成它会在 Windows 侧启动一个 VS Code 界面但后台所有操作终端、调试、扩展都在 WSL2 里执行。这样做的理由是VS Code 远程开发时文件 IO 全程在 Linux 侧速度飞快而你 Windows 桌面上的 VS Code 界面又没有任何额外限制截图、输入法、浏览器都能正常用。端口也是个好消息。WSL2 里启动的 Jupyter Notebook、Flask 服务可以直接用localhost:8888在 Windows 浏览器里打开因为 WSL2 的网络做了互通。不需要手动端口转发这是很多 Windows 老教程里还在教的事现在的版本已经不需要了。5. 踩坑汇总那些让人想砸电脑的问题5.1 高频报错速查表我把 WSL2 CUDA 环境搭建过程中曝光率最高的几个问题列成一个速查表方便你遇到问题时直接对照处理问题现象直接原因解决方案运行wsl提示 “WSL 尚未准备就绪”内核组件未更新或功能未重启执行wsl --update重启电脑再检查两个 Windows 功能是否启用运行wsl --install -d Ubuntu-22.04报“此计算机上未启用虚拟化”BIOS 虚拟化被关闭进 BIOS 找 Intel VT-x/AMD-V开启后重启WSL 卡在启动无法进入 shell内核被第三方安全软件拦截或版本过旧wsl --shutdown然后wsl --update重启终端nvidia-smi报 command not foundCUDA Toolkit 没装或 PATH 没配置确认 toolkit 安装成功检查~/.bashrc里的 PATH 是否包含/usr/local/cuda/bintorch.cuda.is_available()返回 FalsePyTorch 装错版本装了 CPU 版卸载后按cu124或对应cu11x后缀的索引地址重新安装模型训练时显存不足OOM显存被 Windows 桌面程序或其它进程占用降 batch size或用nvidia-smi排查占用进程必要时关闭部分 Windows 软件从 Windows 目录拷贝文件到 WSL 速度极慢跨文件系统 IO 天然有开销把大型数据和项目代码放到 WSL2 内部目录WSL 安装的发行版wsl --list显示为 WSL1未手动设定默认版本执行wsl --set-version Ubuntu-22.04 2这张表的每一条我都实际踩过至少一次。其中“WSL 尚未准备就绪”和“torch.cuda.is_available() 返回 False”是出现频率最高的两个排查时从系统功能、BIOS、PATH、PyTorch 版本这几个维度逐层排除基本不会有漏网之鱼。5.2 .wslconfig 调优内存与 CPU默认情况下WSL2 会使用系统一半的内存和同样比例的 CPU 核心数。这个策略在多数场景下够用但如果你开的是 32GB 内存的大机器会发现 Linux 里永远只能用到一半反过来如果你只有 8GB 内存WSL2 和 Windows 同时跑大程序也可能双双卡成 PPT。解决办法是在C:\Users\你的用户名\.wslconfig文件里做自定义配置没有这个文件就自己建一个[wsl2] memory16GB processors8 swap8GB localhostForwardingtrue这几个参数是最常用的。memory是 WSL2 最大可用内存processors是可用 CPU 核心数swap是虚拟内存大小。改完保存然后在 Windows 终端里执行wsl --shutdown再重新进入 WSL配置就生效了。这里有个性能调优的小技巧如果你的 AI 任务主要是训练大模型建议给 WSL2 分配的内存不要超过物理内存的 75%否则 Windows 桌面程序容易响应迟钝如果主要是推理和数据处理内存可以多给一点因为推理不需要 CUDA 常驻大块显存内存反而是瓶颈。5.3 一些实用建议最后分享几条我在这个方案上长期使用的经验。第一是养成定期备份的好习惯。WSL2 的整个系统就是虚拟磁盘文件用wsl --export导出一个 tar 包关键时刻能救命。我一般每搭好一个稳定的开发环境就导出一次标上日期之后任你乱折腾最多花半小时就能恢复。第二是善用 systemd。新版 WSL2 支持 systemd意味着你可以用systemctl管理服务比如自动启动 Jupyter、SSH daemon、Docker。在/etc/wsl.conf里加一行[boot] systemdtrue重启 WSL 后生效之后再也不用每次都手动敲service ssh start了。第三是不要忽略 Windows 侧更新。WSL2 的很多新特性GPU 支持、systemd、本地网络互通都依赖 Windows 的版本更新建议开启自动更新或者每隔一段时间手动wsl --update。这套环境的好处是Linux 内核是微软持续维护的你不用像维护物理 Linux 那样定时升内核省心不少。6. 这套环境还能往哪走如果你已经走到了上面所有步骤都跑通的状态恭喜你的 Windows 机器现在已经具备了和一台 CUDA 工作站几乎一样的能力。基于这个底座后续还能继续扩展不少东西。比如装 Docker Desktop 和 WSL2 集成在 Windows 上直接跑容器化的 AI 推理服务比如用 vLLM 或 llama.cpp 在 WSL2 里把本地模型跑起来当一个小型 GPU 服务器用再比如配置 VS Code Remote-SSH 把 WSL2 当远程开发机用换个更舒服的终端体验。我个人用了大半年 WSL2 做 AI 开发最大的体验变化是不再关心系统切换、不再担心环境破坏、不再因为驱动冲突浪费一整个下午。每天打开电脑敲两下键盘进入 Linux跑起训练脚本再切回 Windows 继续写文档——这种无缝衔接的体验在几年前几乎不可想象。所以如果你还在纠结双系统还是虚拟机或者被云服务器的高昂 GPU 账单劝退不如先试试 WSL2。只需要一个晚上的时间这套环境就能搭好。唯一需要留点心的地方就是出现问题时对照上面的速查表逐项排查别慌。只要 Windows 侧驱动没问题、内核功能都开了剩下的基本都是配置细节总能磨平。