★ FEATURED ARTICLE 前一阵帮朋友在他那台 Windows 11 笔记本上部署 AI 开发环境他的诉求很明确要在本地跑深度学习实验希望用上 GPU但不想折腾双系统也不想把主力机器直接换成 Linux。我给的答案是 WSL2。这套“内核级 Linux GPU 直通”方案表面看只是装一个子系统实际落地牵扯到 Windows 虚拟化组件、显卡驱动、CUDA 工具链、Linux 发行版、内核版本等多个层面中间任何一个环节不对劲都会出现“WSL2 尚未准备就绪”或者“无法启动因为此计算机上未启用虚拟化”这类让新手当场崩溃的报错。这篇文章就把我在几台不同机器上部署 WSL2 AI 环境的完整流程写出来包括为什么这样设计、命令怎么写、怎么验证以及那些只有踩过才知道的坑。适合 Windows 上想用 GPU 跑 PyTorch、TensorFlow 的人也适合正准备从“双系统还是虚拟机”里做选择的朋友。1. 先弄明白 WSL2 的“内核级 Linux”和“GPU 直通”到底是怎么回事1.1 为什么是 WSL2而不是双系统或传统虚拟机早期 WSL1 是系统调用翻译层把 Linux 的系统调用翻译成 Windows API。好处是启动快、IO 与 Windows 原生互通但它本质上不是真 Linux很多依赖内核特性的软件跑不了比如 Docker 守护进程、需要 inotify/epoll 的框架以及需要加载内核模块的工具。对 AI 开发来说这种“翻译层”方案会时不时冒出怪问题。WSL2 换了路线在一个轻量虚拟机里跑一个真正的 Linux 内核。这个内核经过微软定制但你看到的是完整 Linux有 /proc、有 /sys、有 systemd、能跑 Docker、能编译模块。正因为内核是真的安装依赖、编译 CUDA 算子、跑训练任务时“为什么 Linux 能行 Windows 不行”这类玄学问题基本消失。这就是标题里“内核级 Linux”的含义也是 WSL2 区别于 WSL1 和传统虚拟机的根本。对比双系统双系统性能确实最彻底但来回切换要重启Windows 和 Linux 之间的文件共享麻烦而且很多人主力机器的日常办公还是离不开 Windows。对比 VMware/VirtualBox传统虚拟机也能跑 Linux但想把 NVIDIA GPU 用起来要么搞 PCIe 直通配置复杂笔记本常常不支持要么靠半虚拟化性能和稳定性都看人品。WSL2 把 Linux 开发环境和 Windows 日常使用放进同一个系统切换成本几乎为零。对做 AI 的人来说这是 Windows 下最省心的开发环境。1.2 GPU 直通不是 PCIe 直通这点必须先说清楚标题里的“GPU 直通”很容易让人误以为是把显卡物理直通进虚拟机像 VMware 里那样做 PCIe Passthrough。WSL2 不是这个原理。它走的是微软的 GPU 半虚拟化方案GPU-PVWindows 侧由显卡驱动统一管理 GPUWSL2 里的 Linux 环境通过内核的半虚拟化通道把 CUDA 调用转发给 Windows 驱动再由真正的 NVIDIA 驱动去执行。这个设计带来一个关键结论WSL2 内部不能也不需要单独安装 NVIDIA 的 Linux 驱动。网上一堆老教程让人“在 WSL 里装 Linux 版 GPU 驱动”那是旧时代的做法新版千万不要碰。正确思路是 Windows 侧装好 NVIDIA Windows 驱动WSL 侧只装 CUDA Toolkit、cuDNN 这些用户态库两边各管一段。还有一个容易被忽略的点WSL2 的 GPU 半虚拟化性能损耗很低。我实测大矩阵乘法的吞吐和同一块 GPU 在原生 Ubuntu 下的差异非常小基本持平只有大量小规模 kernel 调度时会有 5% 到 10% 的开销。对小模型调参、中等规模训练来说这个损耗完全可接受别一听“虚拟化”就以为性能崩了。2. 装之前先解决这三个拦路虎虚拟化开关、安装位置、版本选择2.1 检查虚拟化是否真的开了必修课“WSL2 无法启动因为此计算机上未启用虚拟化”是我见过最多的报错。有意思的是很多人 BIOS 里明明把虚拟化打开了Windows 里还是报这个错。原因通常是 Windows 功能组件没勾全。我的处理顺序快捷键 WinR输入OptionalFeatures回车打开“启用或关闭 Windows 功能”。依次勾选这三项“适用于 Linux 的 Windows 子系统”“虚拟机平台”“Windows 虚拟机监控程序平台”。重启电脑这一步不能省。进 BIOS 确认虚拟化开关Intel 平台叫 VT-x 或 Intel Virtualization TechnologyAMD 平台叫 SVM Mode一般在 Advanced 菜单下的 CPU Configuration 里。如果还不行去“设置 - 隐私和安全性 - Windows 安全中心 - 设备安全 - 内核隔离”把“内存完整性”关掉再试。第 5 步是我踩过真坑的地方。有一台台式机BIOS 里虚拟化是开的Windows 功能也勾了但 WSL2 一启动就报错重装完第一次能进重启后又挂。最后发现是“内存完整性”拦了 WSL 内核加载。关掉之后世界安静了。2.2 “WSL2 尚未准备就绪”的排查顺序这个报错通常出现在 Windows 大版本更新之后或者 WSL 组件从旧版切换到商店版的过程中。我的排查顺序固定是先wsl --shutdown把整个 WSL 后台服务彻底重启一遍而不是关掉窗口。再wsl --update把 WSL 组件更新到商店版。用wsl --version查看版本。如果输出 Windows Subsystem for Linux version 2.x.x说明已切到商店版如果提示未知命令或只有 1.x说明组件还是老版本更新后再看。运行winver确认系统版本Win10 2004 以上或 Win11 基本都支持。打开事件查看器eventvwr.msc看 Windows 日志 - 系统过滤来源为 WSL 的错误能定位到虚拟化平台、内存分配等具体原因。有一个容易忽略的冲突源老的 VirtualBox 或第三方虚拟化软件和 WSL2 抢虚拟化资源。VirtualBox 6.1 以上基本能共存老版本需要在虚拟机设置里打开“仅硬件虚拟化”否则启用虚拟机平台时会直接蓝屏。遇到反复蓝屏的组合先排查第三方虚拟化软件。2.3 Ubuntu 版本怎么选22.04 还是 24.04我的建议很明确没有特殊需求优先 22.04。PyTorch、TensorFlow 这些预编译轮子对 22.04glibc 2.35的兼容性经过全行业大量验证装啥都顺。24.04 的 glibc 更新到 2.39部分第三方库偶尔会找不到完全匹配的包。对 AI 开发来说稳定性比“系统版本最新”重要得多。如果确实需要 24.04比如某些新模型只提供了基于新版本系统的预编译包那就装。安装命令是wsl --install -d ubuntu-24.04。注意这个命令可能因为网络原因下载失败报错里就会拖着“WSL2 无法启动”或者“无法连接到服务器”一类的信息这是发行版镜像拉取的问题和虚拟化没直接关系。处理办法是手动下载发行版的 tar 包再用wsl --import方式导入绕开在线商店。下表是我习惯的选择参考场景推荐版本原因日常 PyTorch / TensorFlow 训练Ubuntu 22.04预编译轮子兼容性最好尝试新模型、新框架Ubuntu 22.04 优先遇到问题可查资料最多明确需要新 glibc / 新工具链Ubuntu 24.04系统库版本更符合要求2.4 把 WSL2 装到 D 盘别让 C 盘三天就满WSL2 默认把所有发行版的数据放在 C 盘用户目录下的一个虚拟磁盘文件里ext4.vhdx。这个文件会随着你安装 CUDA、Conda 环境、模型权重而迅速膨胀。所以我一向建议安装完成后第一时间迁移到 D 盘。迁移步骤很简单wsl --shutdown wsl --export Ubuntu D:\wsl-backup\ubuntu.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\wsl\Ubuntu D:\wsl-backup\ubuntu.tar --version 2导入后有个坑默认用户会变成 root不再是你安装时创建的那个用户。解决办法是在 WSL 里创建用户并设置默认用户sudo useradd -m -s /bin/bash yourname sudo passwd yourname然后在 WSL 里编辑/etc/wsl.conf[user] defaultyourname再wsl --shutdown重启 WSL默认用户就生效了。比在 Windows 命令行里执行发行版的config --default-user更省事也跟发行版可执行文件名无关。3. CUDA 配置链路Windows 驱动、WSL 内工具链、验证 GPU3.1 Windows 侧驱动是唯一的驱动入口WSL2 里不需要装任何 Linux 显卡驱动所以第一步必须保证 Windows 侧的 NVIDIA 驱动正确安装。去 NVIDIA 官网下载驱动时选“Windows 驱动程序类型”Studio 驱动或 Game Ready 驱动都行关键是选支持你显卡的最新版。新版 NVIDIA 驱动默认就带 WSL 的 GPU 加速组件不需要额外下载什么 WSL Support 包。装完驱动后打开 Windows 的 cmd 或 PowerShell执行nvidia-smi能看到 GPU 型号、驱动版本、显存信息这一步是后续一切的前提。如果这里都看不到 GPUWSL 里再怎么折腾都没用。这里有一个经验Windows 侧驱动版本和 CUDA 版本不需要严格满足 NVIDIA 官网那张兼容表因为 PyTorch 等框架会带上自己的 CUDA 运行库只要驱动够新就行。真正需要担心版本对应的是你自己用 nvcc 编译 CUDA 源码时那套工具链才要求驱动和 CUDA Toolkit 版本互相兼容。3.2 WSL 内只装 CUDA Toolkit不装驱动进入 WSL 的 Ubuntu执行nvidia-smi如果能看到和 Windows 侧一致的 GPU 信息说明半虚拟化通道已经通了。如果看不到先回到 Windows 侧确认nvidia-smi正常再wsl --update并wsl --shutdown重启。接下来安装 CUDA Toolkit。我推荐用 NVIDIA 的 apt 源注意 repo 名必须是wsl-ubuntu这一点非常关键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 sudo apt install cuda-toolkit-12-4装完可以在 WSL 里跑nvcc --version验证。这里要说明的是如果只是跑 PyTorch、TensorFlow完整 CUDA Toolkit 其实不是必需的因为框架自带的 pip/conda 包已经包含 CUDA 运行库。但做 AI 开发难免要编译自定义算子提前装好 Toolkit 能省不少事所以我还是建议装。3.3 用 PyTorch 做一次真正的 GPU 实测装完环境后别只看nvidia-smi就以为大功告成了我用一段小代码做实际验证import torch import time print(torch:, torch.__version__) print(cuda available:, torch.cuda.is_available()) print(gpu name:, torch.cuda.get_device_name(0)) a torch.randn(4096, 4096, devicecuda) b torch.randn(4096, 4096, devicecuda) # GPU 矩阵乘 torch.cuda.synchronize() t0 time.time() c a b torch.cuda.synchronize() t_gpu time.time() - t0 print(fGPU matmul: {t_gpu:.4f} s)如果torch.cuda.is_available()返回 True并且 GPU 矩阵乘明显比同尺寸 CPU 计算快说明整条链路已经打通。还可以在训练小模型时另开一个终端进入 WSL 执行nvidia-smi能看到 Python 进程占用了 GPU 显存那就是实打实的 GPU 调用。4. 把 AI 开发栈真正跑起来换源、Conda、PyTorch 与日常布局4.1 系统 Python 别乱动用 Miniconda 管理环境很多人第一次进 Ubuntu 习惯直接sudo pip install结果把系统 Python 环境搞乱依赖冲突一堆。我的做法是系统自带的 Python 3 只当系统工具用所有开发环境都丢进 Miniconda。安装 Miniconda 时直接用国内镜像速度快很多wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh安装完成后执行conda init让 shell 能识别 conda 命令。我不喜欢每次开终端都自动激活 base 环境所以执行conda config --set auto_activate_base false需要哪个环境就手动conda activate。4.2 换源要分清楚有 apt 源还有 pip 源和 conda 源Ubuntu 的软件源也要换。22.04 的源文件是/etc/apt/sources.list24.04 默认的源文件是/etc/apt/sources.list.d/ubuntu.sources。用 sed 替换成清华源即可sudo sed -i s//.*archive.ubuntu.com//mirrors.tuna.tsinghua.edu.cng; s//security.ubuntu.com//mirrors.tuna.tsinghua.edu.cng /etc/apt/sources.list24.04 就替换ubuntu.sources文件里的地址。注意别改错文件名否则 apt update 会报文件格式错误。conda 源和 pip 源也一起换成国内镜像conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --set show_channel_urls yes pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple4.3 建环境和装 PyTorch创建专用的深度学习环境conda create -n ai python3.11 -y conda activate ai pip install torch torchvision torchaudio新版 PyTorch 默认的 pip 包已经包含 CUDA 支持不需要额外指定 index。如果你要固定 CUDA 版本可以走 PyTorch 官方索引pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124安装完成后回到第 3.3 节的验证代码跑一遍确认torch.cuda.is_available()是 True。到这里一套能跑 GPU 训练的最小环境就齐了。4.4 文件和数据的摆放位置会影响训练速度WSL2 访问 Windows 文件系统的方式是通过/mnt/c挂载底层走的是 9P 协议大量读写小文件时非常慢。深度学习训练期间要频繁读取图片、文本片段这类小文件如果把项目和数据放在/mnt/c下你会发现 GPU 经常在等数据加载训练速度被 IO 拖垮。我的原则是代码和数据全部放在 Linux 侧文件系统里比如/home/yourname/projects/。需要用 Windows 侧工具打开 Linux 文件时在资源管理器地址栏输入\\wsl.localhost\Ubuntu\home\yourname\projectsVS Code、PyCharm、截图工具都能正常识别。反过来如果要从 Linux 侧访问 Windows 侧的 D 盘大文件比如已经下载好的模型权重用/mnt/d是没问题的只读大文件的速度可以接受但别在这种路径下跑训练。5. 内核相关的问题排查更新、报错定位、自定义内核到底值不值5.1 怎么查看和更新 WSL2 内核WSL2 用的不是 Ubuntu 仓库里那个通用内核而是微软维护的定制内核随 WSL 组件一起管理。查看当前内核版本uname -r查看 WSL 组件版本wsl --version更新内核和 WSL 组件wsl --update注意Windows 大版本更新偶尔会把 WSL 的状态搞乱表现为启动发行版时卡住或直接报错。遇到这种情况先wsl --update再wsl --shutdown基本都能救回来。5.2 定位内核问题的完整链路很多人说“定位内核问题”但根据我的经验真正的 Linux 内核故障在 WSL2 里占比很低多数问题出在 Windows 侧组件。真正属于内核层面的问题一般有这些表现启动发行版时黑屏或一直卡在转圈sudo dmesg | tail -n 100里能看到 panic 或 oops 字样加载内核模块时报Exec format error多半是模块编译用的内核头文件版本和当前运行内核版本对不上想在 WSL2 里再跑 KVM 嵌套虚拟化结果平台不支持。遇到这些问题我的排查顺序是wsl --shutdown后重新进入查看sudo dmesg | tail -n 100确认内核运行时告警查看/var/log/kern.log或/var/log/syslog里的内核相关错误更新wsl --update后再试到 Windows 事件查看器里过滤 WSL 来源的错误记录。如果确实要编译内核模块最容易踩的坑是头文件版本。WSL2 的内核版本和 Ubuntu 仓库里 linux-headers 包的默认版本不一定是同一个正确做法是先确定uname -r输出的具体版本再安装匹配的 headerssudo apt install linux-headers-$(uname -r)如果仓库里找不到匹配版本就要到微软的 WSL2 内核仓库里找对应 tag 的头文件。这个环节最容易翻车我见过太多人在这上面折腾一下午。5.3 自定义内核非必要不折腾WSL2 支持自定义内核你把编译好的内核镜像放到 Windows 侧路径然后在%USERPROFILE%\.wslconfig里指定kernelD:\\path\\to\\kernel。但我的看法是跑 AI 开发环境完全没必要碰这个。原因有三微软定制内核已经集成 WSL2 需要的核心模块自己编译容易漏掉关键驱动显卡半虚拟化、网络转发这些模块少一个都会出隐性问题每次wsl --update可能覆盖你的自定义配置需要重新指定最直接的一点是自定义内核对你跑 PyTorch 的训练速度没有任何帮助反而引入了一堆需要维护的变量。真正需要自定义内核的场景是做内核开发、加载特定驱动、调整内核参数的人那基本是另一个领域的事。6. 部署后的性能与体验调优内存限制、网络模式、IDE 工作流6.1 用 .wslconfig 限制内存和 CPUWSL2 默认的规则是拿掉一半物理内存给虚拟机机器只有 16G 内存时WSL 可能直接分走 8GWindows 日常操作很容易卡。我通常会在用户目录下建一个.wslconfig文件路径是C:\Users\你的用户名\.wslconfig来限制资源[wsl2] memory8GB processors4 swap8GB networkingModemirrored localhostForwardingtruenetworkingModemirrored是 Windows 11 22H2 以上才有的镜像网络模式它让 WSL2 和 Windows 共享网络栈访问 localhost 端口不再有转发的问题体验上比默认 NAT 模式顺滑很多。配置完一定要wsl --shutdown再重新进改动才会生效。6.2 IDE 和开发工作流的整合这套环境的日常使用方式我推荐VS Code装好 Remote-WSL 插件直接在 WSL 里打开项目终端、调试器、文件树都是 Linux 环境和本地开发没有区别。PyCharm新版对 WSL2 支持非常好解释器可以直接指向\\wsl.localhost\Ubuntu\home\yourname\miniconda3\envs\ai\bin\python这样你既能在 Windows 侧写代码又能让代码跑在 Linux 内核环境里。Jupyter Notebook默认 localhost 转发就能用Windows 浏览器直接访问localhost:8888即可。装了镜像网络模式后更稳定不会出现端口转发偶尔失效的情况。6.3 记住这三条WSL2 的 AI 环境基本不会出大问题最后再分享一个我自己实践下来的经验。踩过几次坑之后我总结三条铁律Windows 侧显卡驱动不要乱动更新时选对应型号的最新稳定版即可WSL 侧不要装 NVIDIA Linux 驱动也不要从 NVIDIA 官网下 Linux 版驱动包代码、数据集、虚拟环境都放 Linux 侧文件系统别贪图方便直接操作/mnt/c路径。只要守住这三条绝大多数所谓的“WSL2 部署失败”根本不会发生。这套环境我目前已经连续用了几个月日常跑 PyTorch 训练、调试 CUDA 算子、跑 Jupyter 实验完全没有想切回双系统的冲动。
阅读完成 · 觉得有帮助？
