1. 为什么非要折腾一套 WSL2双系统和虚拟机的真实痛点我有一张 NVIDIA 显卡平时在 Windows 上做日常开发跑 AI 实验的时候却总是陷入两难。刚入行那阵子我习惯了双系统方案磁盘划出一个分区装 Ubuntu要训练重启从 GRUB 里选 Linux跑完再重启回 Windows。听起来很硬核但当你在同一个下午要反复切换五六次的时候你会发现大量时间都花在等待开机、等待环境加载、等待 SSH 服务恢复这些破事上。后来我试着用虚拟机Oracle VM VirtualBox 和 VMware 都试过。虚拟机倒是解决了不用重启的问题可它带来的新问题更糟心显卡在虚拟机里根本没法直通或者说即便能直通配置过程繁琐不说CUDA 的支持也时好时坏。结果就是我在虚拟机里跑 PyTorch明明看着是 GPU 版本实际计算却在用 CPU 硬扛一个 epoch 要跑十几分钟。这种体验逼着我去认真研究 WSL2。WSL2 这套方案最终成了我的主力开发环境它跑的是一颗真正的 Linux 内核能直接调用 Windows 侧的显卡驱动把 CUDA 计算能力完整暴露给 Linux 应用程序而且不需要重启、不需要双系统、不需要虚拟机里的复杂显卡穿透配置。这篇文章就把我的部署过程、踩过的坑、以及实测下来的性能数据完整记录下来给想在 Windows 上做 AI 开发、又不想告别 Windows 日常体验的朋友一个可复现的参考。先说清楚一点WSL2 不完全等于一台独立的 Linux 服务器它更适合本地开发、调试、训练中小规模的模型以及跑一些需要 Linux 生态的依赖工具。如果你需要多卡训练、需要长时间独占整机跑大规模任务还是老老实实用物理机或者云服务器。但如果你和我一样主要工作是写代码、调模型、跑单卡训练WSL2 是这个场景下 Windows 用户最顺手的答案。2. WSL2 的内核级 Linux到底是怎么实现的从翻译层到真内核2.1 WSL1 到 WSL2为什么必须换内核很多人把 WSL1 和 WSL2 混为一谈其实两者完全是两个物种。WSL1 的本质是一个用户态的系统调用翻译器。它没有 Linux 内核而是把 Linux 程序发起的系统调用翻译成 Windows NT 内核能理解的请求再把结果翻译回来。这种方案的好处是启动快、内存占用低、文件系统性能还行坏处是兼容性有限。很多依赖 Linux 内核特性的东西在 WSL1 里直接跑不起来比如 Docker 容器、某些内核模块、eBPF 工具链以及需要访问底层设备的功能。WSL2 从设计上换了一条路直接基于 Hyper-V 虚拟化平台跑一个真正的、微软定制过的 Linux 内核内核版本会跟随上游更新。这个虚拟机是轻量级的它没有传统虚拟机那种完整的 BIOS、显存、声卡等虚拟设备栈而是只提供 Linux 需要的那部分硬件抽象。启动一个 WSL2 发行版通常只需要一两秒钟这得益于它的特殊架构内核启动到用户态就绪的过程被大幅减化而且 Windows 会常驻一个轻量级的虚拟化基础服务。我刚开始也不信这套轻量虚拟机能有多轻量直到我在任务管理器里看到 Vmmem 这个进程时才意识到它确实是个虚拟机只是被 Windows 管理得足够透明让我感觉它就是终端里的一个普通 Linux 会话。2.2 轻量虚拟机的资源管理vmmem 与动态内存WSL2 的资源管理策略和传统虚拟机不一样。传统虚拟机你给多少内存就是多少开机先占住WSL2 则默认采用动态内存分配Linux 需要多少Windows 就分多少给它理论上可以回收。但这个动态不是无限的默认状态下 WSL2 最多能吃掉你机器物理内存的 50% 左右这是早期版本的默认行为如果你在做大模型推理或者预处理大数据集很容易发现电脑整体变卡。所以部署 AI 环境的第一个重点就是一定要学会配置 .wslconfig 文件。它位于 Windows 用户目录下%UserProfile%.wslconfig专门用来控制 WSL2 的资源上限。我在这台 32GB 内存的机器上用的是下面这组配置[wsl2] memory16GB processors8 swap8GB autoMemoryReclaimgradual这里每项都有讲究。memory 是给 Linux 的最大内存我设 16GB 是为了避免它吞噬掉 Windows 侧的所有内存processors 限制 CPU 核数防止全核满载时 Windows 卡死autoMemoryReclaim 是较新版本 WSL 加入的自动回收选项值设为 gradual 后当 Linux 内不再有大块缓存占用时Windows 会渐进式回收内存而不是等用户手动 wsl --shutdown。如果你要跑 PyTorch DataLoader 这类频繁吃内存的流程建议把 swap 留出来8GB 作为一个缓冲区足够大多数任务使用了。但注意swap 文件默认放在虚拟磁盘里本质上是要写磁盘的不能指望它代替真正的物理内存它只是防 OOM 的兜底。2.3 systemd、Docker、内核模块这些关键能力是怎么落地的WSL2 现在默认支持 systemd这意味着你在里面装 docker、ssh、cron 这类依赖 service 管理的软件时体验和原生 Ubuntu 几乎一样。早期版本 WSL2 没有 systemd只能靠 /etc/wsl.conf 里的 boot 命令和手动启动服务的方式硬凑那才是真的难受。以 Docker 为例在 WSL2 里安装 docker-ce 后systemd 能让 dockerd 以服务形式自动启动不需要你每次开终端先 service docker start。这是内核级 Linux最有说服力的地方普通的用户态模拟方案做不到这种透明性。更关键的是内核模块能力。WSL2 允许你加载一些内核模块比如 NVIDIA 的 nvidia-smi 相关工具、CUDA 运行时的内核驱动接口都是借助这个能力工作的。虽然默认情况下你不需要自己编译内核但如果你需要某些特殊模块例如使用特定文件系统类型WSL2 是支持内核自定义编译的只是步骤比较繁琐大多数人用不到。2.4 别误会WSL2 不是完整替代 Linux 服务器我在跟朋友推荐 WSL2 的时候总会收到一个误解那岂不是我有一台免费的 Linux 服务器了从用户体验来说确实很像但从网络和系统层面看它和你租一台云服务器或者在真机上装 Linux 有本质差异。WSL2 默认走的是 NAT 网络模式Linux 侧拿到的是一个虚拟交换机分配的 IP除非你在 Windows 上做端口转发wsl hostname -I 拿到 IP然后用 netsh 做端口转发否则外部设备无法直接访问你 WSL2 里跑的 Web 服务。宿主机访问 WSL2 内服务时Windows 会做一个 localhost 转发这个在开发时够用但要让局域网里其他机器访问就需要额外配置。另外WSL2 的文件系统分为两部分Linux 自身的 ext4 虚拟磁盘通常挂载在 / 下和 Windows 文件系统挂载在 /mnt/c、/mnt/d 等位置。两者之间的文件访问效率差距悬殊这个我在后面专门讲文件 IO 时会详细展开。搞清楚这些边界之后你就明白 WSL2 的定位了它是给开发者的桌面 Linux 体验而不是给运维的服务器 Linux 体验。3. GPU 直通拆解Windows 驱动如何变成 Linux 里的 CUDA3.1 GPU-PV 的工作原理WDDM、dxgkrnl 与半虚拟化标题里GPU 直通这四个字很吸引人但如果直接把它理解成传统虚拟化领域里的 PCIe Passthrough那就理解偏了。传统虚拟机做 GPU 穿透是把物理显卡直接分配给虚拟机使用宿主 OS 通常就看不到这张卡了。WSL2 的 GPU 访问走的是另一套机制叫 GPU-PVGPU ParavirtualizationGPU 半虚拟化。GPU-PV 的基本思路是Windows 侧保留显卡的完整控制权通过 WDDMWindows Display Driver Model驱动把 GPU 能力以半虚拟化接口的形式暴露给 Linux。在这个架构下WSL2 内运行的程序调用 CUDA / OpenCL / DirectX 时请求会被发送到 Windows 侧的 GPU 调度层由 Windows 的驱动去访问真实硬件再把结果返回给 Linux 应用。这意味着两件事Windows 侧的显卡驱动始终保持对硬件的独占和直接管理不会因为 WSL2 的使用导致驱动冲突。Linux 侧不需要安装任何 NVIDIA 显卡驱动只需要安装 CUDA Toolkit 以及配套的 runtime 库。这套设计非常聪明它既绕开了传统 PCIe 穿透对硬件的独占问题又避免了在虚拟机和宿主机之间维护两套驱动栈的噩梦。代价是会有一定的软件调度开销但 NVIDIA 和微软在这条路径上做了不少优化实测性能差距很小。3.2 WSL2 里 nvidia-smi 的显示逻辑和常见误读第一次在 WSL2 里敲 nvidia-smi 的人都会觉得神奇它居然能显示完整的 GPU 信息、显存使用量、进程列表和原生 Linux 简直一模一样。于是很多人误以为 WSL2 里也装了一整套 NVIDIA Linux 驱动。实际上WSL2 里的 nvidia-smi 本身是一个独立的可执行文件它从 Windows 侧通过 GPU-PV 查询硬件状态然后以 Linux 用户熟悉的格式展示出来。你在 WSL2 里看到的那一长串驱动版本号其实是 Windows 驱动的映射版本而不是 Linux 侧安装的驱动。这个机制带来一个非常关键的部署原则如果手动去 NVIDIA 官网下载Linux x86_64版本的驱动安装到 WSL2 里大概率会把现有的 GPU 工作链路搞坏或者出现驱动冲突。正确做法是让 WSL2 保持不装 Linux 驱动的状态只装 CUDA Toolkit 和它自带的用户态库。3.3 NVIDIA 驱动的单侧安装策略为什么 Linux 侧不能装驱动我在最初调配环境时出于惯性思维直接在 WSL2 里执行了 NVIDIA 官方网站的 Linux 驱动安装脚本结果就是 nvidia-smi 报错、PyTorch 报 CUDA 初始化失败。排查之后我才明白WSL2 的 GPU 访问路径完全不依赖 Linux 侧的内核模块。它需要的是一组用户态库包括 libcuda.so、libnvidia-ml.so 等这些库由 CUDA Toolkit 提供而内核侧的访问则通过 WSL2 核心机制dxgkrnl 模块映射透传给了 Windows 的 WDDM 驱动。所以正确且唯一的做法是在 Windows 侧安装最新且支持 WSL2 的 NVIDIA 驱动然后在 WSL2 内部只安装 CUDA Toolkit不安装任何 NVIDIA 的 Linux .run 驱动包。Windows 侧驱动要保证满足两个条件版本不能太老建议 470.76 及以上这是 NVIDIA 对 WSL2 支持的起步版本但到 2025 年我们普遍用 550 系列以上的新驱动了并且是支持 WSL2 的 Game Ready 或 Studio 驱动。我的建议是直接用 Studio 驱动现在叫 NVIDIA Studio Driver它在 CUDA 场景下测试覆盖面更全稳定性更好。3.4 实际性能数据理论上接近原生实测到底差多少纸上得来终觉浅我实际跑了两个实验来验证 WSL2 的 GPU 性能。第一个实验是矩阵乘法密集任务用 PyTorch 在固定大小的 tensor比如 4096x4096 矩阵乘法上循环 500 次对比 WSL2 和同一台机器原生双系统 Linux 的耗时两者差距在 1%-3% 之间几乎可以认为是噪声。第二个实验是微调一个中小规模的 BERT 模型batch size 设置为 32序列长度 128统计每个 step 的平均时间。WSL2 里大概比原生 Linux 慢了 2%-5%而且这个差距主要来自启动瞬时的驱动调用开销不是持续计算阶段的差异。我还专门看了显存带宽的表现。用 torch 连续执行大规模张量拷贝和卷积操作整体吞吐量约等于原生的 96% 以上。这个数据说明一个问题计算密集型的 AI 任务在 WSL2 里跑性能损失非常有限完全不影响日常开发、调试、训练、推理实验。当然性能接近不等于零差异。如果任务里大量涉及小文件读写、频繁调用系统调用、或者对网络延迟敏感WSL2 的虚拟化边界还是会产生额外的开销。这就要求我们合理规划工程结构把高频 IO 操作放在 Linux 侧文件系统内把网络敏感的组件尽量放在 Windows 侧或做映射。4. 从零到 torch.cuda.is_available()完整部署操作链路4.1 版本匹配清单Windows 版本、驱动、CUDA 版本部署 AI 开发环境最忌讳的就是照着教程敲命令但版本全看运气。WSL2 的 GPU 链路涉及 Windows 版本、显卡驱动、CUDA Toolkit、PyTorch 四个层次每个层次都有兼容性窗口。我在部署前整理了这样一张匹配表你可以直接参考组件我使用的版本说明Windows 系统Windows 11 22H2 及以上Windows 10 21H2 以上也能用但 WSL 新版特性都在 Win11 上优先NVIDIA 驱动551.86Studio 驱动关键驱动在 Windows 侧安装版本决定 CUDA 上限WSL 版本2.0.9通过 wsl --update 更新老版本 WSL 对 autoMemoryReclaim 等新功能支持不全CUDA Toolkit12.3wsl-ubuntu 版对应编译 PyTorch 所用的 CUDA 版本PyTorch2.1.2cu121 版本和 CUDA 12.3 保持兼容注意一个常识Windows 侧安装的驱动支持某个高版本的 CUDA并不意味着你一定得安装最新 CUDA Toolkit。PyTorch 是自带 CUDA runtime 的一部分的你完全可以用 cu118 版本的 PyTorch 跑在支持 CUDA 12 的驱动上NVIDIA 驱动是向后兼容的。所以原则是驱动用新的但 PyTorch 的 CUDA 版本根据项目依赖来选择不必刻意追新。4.2 安装 WSL2 并配置 Ubuntu 系统如果你是第一次接触 WSL直接用管理员 PowerShell 执行这条命令wsl --install这条命令会一次性启用 Windows 虚拟化平台、安装默认发行版通常是 Ubuntu、并把 WSL 版本设置为 2。对于已经装过老版本 WSL 的机器可以分步操作# 启用功能 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启后执行 wsl --set-default-version 2 wsl --update安装指定发行版wsl --list --online wsl --install -d Ubuntu-22.04安装完第一次进入 Ubuntu 会让你设置用户名和密码这里有个容易被忽略的点这个初始用户会被自动加入 sudo 组但还是建议你立刻把 apt 源更换为国内可用源比如阿里云、中科大的镜像站否则后面的 CUDA 下载会非常痛苦。更换源的操作就是把 /etc/apt/sources.list 里的镜像地址替换然后 apt update。这一步网上很多教程我这里只提醒一点一定要确认你的源对应的 Ubuntu 版本代号22.04 是 jammy别用错版本。4.3 CUDA Toolkit 的 WSL-Ubuntu 安装路线CUDA Toolkit 在 WSL2 里的安装方式和原生 Ubuntu 略有不同NVIDIA 专门为 WSL 构建了一个 apt 源。我用的是 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-get update sudo apt-get -y install cuda-toolkit-12-3这里解释一下为什么不直接装 cuda 这个元包cuda 这个包会把驱动相关的组件也拉进来但在 WSL2 里这些组件不仅没用还可能造成冲突。cuda-toolkit-12-3 只装编译和运行需要的用户态库包括 nvcc、cuda-runtime、cublas、cudnn 等。装完之后把 CUDA 的 bin 和 lib 路径加入环境变量我习惯写在 ~/.bashrc 里export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后验证nvcc --version能看到 Cuda compilation tools 的版本信息就说明 Toolkit 安装成功。4.4 PyTorch 安装与版本对应关系PyTorch 的预编译包已经把 CUDA runtime 打包进去了所以你不需要去碰系统的 CUDA 动态库直接根据你要用的 CUDA 版本选择对应的 wheel 即可。我给一个通用的安装命令模板conda create -n ai python3.10 -y conda activate ai pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这里 --index-url 指定了 PyTorch 官方预编译的 CUDA 版本索引。常见的对应关系是PyTorch 版本CUDA 索引适用 CUDA 版本torch 2.1.xcu118CUDA 11.8torch 2.1.xcu121CUDA 12.1torch 2.3.xcu121/cu124CUDA 12.1/12.4我个人的选择是 cu121因为生态最成熟大多数第三方库的预编译版本都覆盖了这个 CUDA 版本。如果你要跑一些老项目依赖 CUDA 11就选 cu118驱动层面完全兼容。关于 conda 还是 venv我推荐用 conda 管理 Python 环境因为 AI 生态里经常需要不同版本的 Python、cudnn、nccl 搭配conda 能把这些非 Python 依赖也管理起来。如果嫌 conda 太慢可以用 micromamba 替代但管理逻辑是一样的。4.5 验证脚本与预期输出环境配置完成不代表万事大吉一定要跑一遍真实的 GPU 计算验证。下面这段脚本是每次新环境我都会执行的点火测试import torch print(PyTorch version:, torch.__version__) print(CUDA available:, torch.cuda.is_available()) print(GPU device count:, torch.cuda.device_count()) print(GPU name:, torch.cuda.get_device_name(0)) print(Current device:, torch.cuda.current_device()) # 在 GPU 上创建一个随机张量并执行矩阵乘法 a torch.randn(2048, 2048, devicecuda) b torch.randn(2048, 2048, devicecuda) c a b torch.cuda.synchronize() print(Matrix multiplication result shape:, c.shape) print(Peak memory allocated: {:.2f} MiB.format(torch.cuda.max_memory_allocated() / 1024 / 1024))预期输出里应该看到 CUDA available: TrueGPU 名称正确显示你的显卡型号矩阵乘法正常完成。如果 CUDA available 是 False大概率是版本链接出了问题要么是 PyTorch 装成了 CPU 版要么是 CUDA Toolkit 和 PyTorch 的 CUDA 版本差距太大。还有一个细节在 WSL2 里你可以同时打开 Windows 任务管理器查看 GPU 利用率会发现和 Linux 侧 nvidia-smi 显示的利用率是同步的。这个观察也能帮你确认 GPU-PV 链路两个端是通的。5. 高负载训练后的真实反馈显存、内存和文件 IO 的边界5.1 显存分配与释放为什么有时候训练完显存还在WSL2 里跑完一个训练脚本有时候用 nvidia-smi 看显存并没有完全释放而是停在一个比较高的水位上。我在原生 Linux 上见过类似情况但在 WSL2 里更容易发生。原因有两层。第一层是 PyTorch 的缓存分配器PyTorch 默认会缓存已释放的显存块以便后续快速复用这在同进程内是好事但进程退出后缓存应该被释放。第二层是 WSL2 的 GPU-PV 机制对显存的占用有一层自己的管理逻辑Windows 侧的显存分配器不会在进程结束后立刻把显存归还给硬件而是保留一段时间。如果你确实需要立即释放显存最直接的办法是wsl --shutdown这会关闭整个 WSL2 虚拟机重开后显存状态会完全干净。代价是当前 WSL2 里所有的终端会话和服务都需要重新启动。所以我的习惯是在长时间高负载训练结束后统一调度一次 wsl --shutdown把资源彻底放干净。对于训练脚本内部合理使用 torch.cuda.empty_cache() 只在需要时才调用因为主动清空缓存会导致下次分配变慢。真正该做的是控制 batch size 让显存峰值在你的显卡容量 85% 以内留出余量给自动混精度的中间变量。5.2 内存上限与 .wslconfig 调优内存问题是我在 WSL2 里排障最多的一类问题。默认状态下WSL2 的内存限制是物理内存的 50%。假设你有 64GB 内存Linux 最多拿 32GB听着够用了。但如果你同时跑 Dataloader 的 num_workers8每个 worker 都会预加载一批数据再加上缓存机制32GB 可能瞬间被打满然后 OOM 直接让训练进程被杀掉而且不会给你任何 Linux 侧明显的报错提示只在日志里留下一段 Kernel panic 级别的记录。我的调优配置前面已经给出过。这里再补充两个参数的重要说明。sparseMode 是较新版 WSL2 引入的用于虚拟磁盘稀疏化防止 Linux 内部删除文件后vhd 文件不缩小导致 Windows 磁盘空间白白占用。设成 true 之后在同一块虚拟磁盘里反复创建和删除大文件比如多个虚拟环境时磁盘空间可以被重新利用。swap 参数很多人忽略但在做大规模数据预处理时作用明显。数据加载过程中出现瞬时内存尖峰不可避免swap 能挡住一部分假 OOM给 GC 和缓存清理争取时间。5.3 /mnt/c 的 9P 协议与文件位置规划这是一个绝大多数第一次用 WSL2 做开发的人都会踩的坑你把项目代码放在 Windows 的 D 盘然后在 WSL2 里 cd /mnt/d/project 执行训练脚本结果发现数据读取速度慢得离谱。原因是 WSL2 访问 Windows 文件系统时走的是 9P 协议这是一个网络文件系统协议本质上是把 Windows 侧的文件访问请求通过网络栈桥接给 Linux 侧的目标进程。对于大量小文件的读取这个路径的性能损耗极其明显实测可以比 Linux 原生 ext4 访问慢一个数量级。更麻烦的是如果你在 /mnt/c 下直接初始化一个 conda 环境或者让 pip 依赖缓存落在 Windows 侧整个包安装和导入过程都会变慢。最正确的文件规划方式把项目代码、数据集、虚拟环境全部放在 Linux 侧文件系统内默认是 ~/ 目录下的某个路径。Windows 侧只保留日常办公文件需要共享时再通过 /mnt/c 互访。具体操作上我一般是这样安排目录结构的~/ ├── projects/ │ ├── nlp-experiment/ │ ├── cv-demo/ │ └── llm-finetune/ ├── datasets/ ├── envs/ # conda 环境统一放这里 └── tools/这样 Linux 侧的读写性能不打折扣同时 Windows 侧也能通过 \wsl$ 路径访问这些文件实现用 Windows 软件查看 Linux 侧数据的需求。VS Code 远程连接 WSL2 后编辑和调试也都在 Linux 侧完成非常自然。5.4 Docker Desktop 还是原生 docker-ceWSL2 上跑 Docker 有两条主流路线Docker Desktop它内部用 WSL2 做后端和直接在 WSL2 里装 docker-ce。我用 Docker Desktop 的时间比较长但它有几个对 AI 开发不太友好的点一是 Docker Desktop 自带的 Linux VM 会额外占用内存二是它和 WSL2 之间夹了一层文件共享和端口转发性能打折扣三是 Docker Desktop 的商业授权政策对大型企业不友好个人用倒是没什么限制。对比下来我更推荐在 WSL2 内部直接安装 docker-ce。原因很简单既然 WSL2 本身就是完整的 Linux那直接让 Linux 自己管理 Docker 进程是性能损耗最小的方案。安装命令很简单curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh sudo usermod -aG docker $USER要支持 GPU 容器的话还需要安装 NVIDIA Container Toolkitdistribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker完成后运行 GPU 容器验证docker run --gpus all nvidia/cuda:12.3.1-runtime-ubuntu22.04 nvidia-smi如果你能看到 GPU 信息说明 Docker 的 GPU 通道也通了。这一步对于复现很多开源项目的镜像环境非常关键因为不少项目 Dockerfile 里写死了 Nvidia 驱动和 CUDA 版本用容器的好处就是把这些依赖隔离开。6. 翻车复盘WSL2 部署 AI 环境最容易踩的四个坑6.1 驱动版本错位带来的连锁反应我遇到过的最难排查的问题是 Windows 侧驱动更新后CUDA Toolkit 的 nvcc 编译一切正常但运行 PyTorch 时报CUDA error: no kernel image is available for execution on the device。当时我怀疑是 PyTorch 版本问题折腾了半天后来才发现是显卡驱动升级到了某个较新版本但 PyTorch 里打包的 CUDA runtime 较旧两者在部分操作上出现兼容性缺口。NVIDIA 显卡驱动一般向后兼容老 CUDA 应用但兼容不代表所有路径都验证过个别版本的组合就会触发奇怪的现象。经验法则升级 Windows 驱动后第一时间在 WSL2 里重新跑一遍第 4.5 节的验证脚本如果出现奇怪的 CUDA 报错优先考虑回退驱动版本或者升级 PyTorch 小版本。别急着怀疑你的代码。6.2 多发行版并存时的 GPU 资源瓜分WSL2 支持同时装多个发行版比如一台机器里同时存在 Ubuntu 22.04 和 Debian 12。这本身不是问题但在 GPU 资源分配上会有个坑GPU 显存和计算资源是被多个发行版共享的如果两个发行版同时跑训练任务Windows 侧的 GPU 调度器不会公平分配可能出现某个发行版把显存占满导致另一个发行版 CUDA 初始化失败。我的建议很简单AI 开发环境只用单一发行版。多个发行版留一个当实验工具箱就够了不要让两个 Linux 环境同时跑 GPU 任务。这样能省掉一票资源竞争问题。6.3 网络配置的隐性坑WSL2 的网络是 NAT 模式这个前面提过。实际使用中最容易出问题的场景是你在 WSL2 里跑了 Jupyter Notebook 服务Windows 浏览器访问 localhost:8888 没问题但手机或局域网其他电脑访问不了。你在 WSL2 里跑分布式训练需要 22 端口接受外部 SSH 连接默认配置下外部无法直接访问。如果你确实需要让局域网设备访问 WSL2 内的服务可以在 Windows 侧用 PowerShell 做端口转发netsh interface portproxy add v4tov4 listenport8888 listenaddress0.0.0.0 connectport8888 connectaddress172.x.x.x其中 172.x.x.x 是 WSL2 当前分配的 IP用 wsl hostname -I 可以拿到。注意 WSL2 每次重启 IP 都可能变化所以这个转发要及时更新。更优雅的方案是给 WSL2 配置镜像网络模式networkingModemirrored这个模式在较新的 WSL 版本里已经可用能让 Linux 共享 Windows 的网络接口外部访问更自然。6.4 WSL2 里跑大规模多卡训练的现实局限与我的选型结论最后泼一盆冷水WSL2 支持多卡 GPU 吗理论上支持因为 GPU-PV 允许 Windows 暴露多个 GPU 给 Linux 侧PyTorch 也能用 torch.cuda.device_count() 看到不止一张卡。但实践经验告诉我多卡场景不要依赖 WSL2。多卡训练需要 NCCL、需要一定的高性能网络通信能力还涉及 GPU 间的直连拓扑比如 NVLink。WSL2 的半虚拟化路径在这些场景下的优化远远不如单卡场景扎实通信开销会显著拉高训练效率打折扣。更现实的方案是单卡开发和调试在 WSL2 里做多卡训练丢给原生 Linux 物理机或云容器实例。所以我自己最终的选型结论是桌面端 Windows WSL2承担日常开发、单卡调试、中小模型训练、快速原型验证服务器端原生 Linux承担多卡训练和大规模数据处理。两者之间用 Git 和 rsync 同步代码与数据环境用容器或者 conda 锁定切换时尽量无缝。这套方案我已经稳定跑了几个月最直观的感受是不再需要频繁重启系统Windows 上各种办公、浏览器、IM 工具保持在线写代码和训练模型都在同一个终端窗口里完成整体工作流顺畅很多。最后分享一个习惯每两周左右我会跑一次 wsl --update把 WSL 的内核和功能更新到较新版本因为微软在这个组件上的迭代非常快很多性能优化和新特性都是通过更新内核带来的而升级成本几乎为零。配合一个定期维护的 .wslconfig这个环境可以长期保持好用。
1. 为什么非要折腾一套 WSL2双系统和虚拟机的真实痛点我有一张 NVIDIA 显卡平时在 Windows 上做日常开发跑 AI 实验的时候却总是陷入两难。刚入行那阵子我习惯了双系统方案磁盘划出一个分区装 Ubuntu要训练重启从 GRUB 里选 Linux跑完再重启回 Windows。听起来很硬核但当你在同一个下午要反复切换五六次的时候你会发现大量时间都花在等待开机、等待环境加载、等待 SSH 服务恢复这些破事上。后来我试着用虚拟机Oracle VM VirtualBox 和 VMware 都试过。虚拟机倒是解决了不用重启的问题可它带来的新问题更糟心显卡在虚拟机里根本没法直通或者说即便能直通配置过程繁琐不说CUDA 的支持也时好时坏。结果就是我在虚拟机里跑 PyTorch明明看着是 GPU 版本实际计算却在用 CPU 硬扛一个 epoch 要跑十几分钟。这种体验逼着我去认真研究 WSL2。WSL2 这套方案最终成了我的主力开发环境它跑的是一颗真正的 Linux 内核能直接调用 Windows 侧的显卡驱动把 CUDA 计算能力完整暴露给 Linux 应用程序而且不需要重启、不需要双系统、不需要虚拟机里的复杂显卡穿透配置。这篇文章就把我的部署过程、踩过的坑、以及实测下来的性能数据完整记录下来给想在 Windows 上做 AI 开发、又不想告别 Windows 日常体验的朋友一个可复现的参考。先说清楚一点WSL2 不完全等于一台独立的 Linux 服务器它更适合本地开发、调试、训练中小规模的模型以及跑一些需要 Linux 生态的依赖工具。如果你需要多卡训练、需要长时间独占整机跑大规模任务还是老老实实用物理机或者云服务器。但如果你和我一样主要工作是写代码、调模型、跑单卡训练WSL2 是这个场景下 Windows 用户最顺手的答案。2. WSL2 的内核级 Linux到底是怎么实现的从翻译层到真内核2.1 WSL1 到 WSL2为什么必须换内核很多人把 WSL1 和 WSL2 混为一谈其实两者完全是两个物种。WSL1 的本质是一个用户态的系统调用翻译器。它没有 Linux 内核而是把 Linux 程序发起的系统调用翻译成 Windows NT 内核能理解的请求再把结果翻译回来。这种方案的好处是启动快、内存占用低、文件系统性能还行坏处是兼容性有限。很多依赖 Linux 内核特性的东西在 WSL1 里直接跑不起来比如 Docker 容器、某些内核模块、eBPF 工具链以及需要访问底层设备的功能。WSL2 从设计上换了一条路直接基于 Hyper-V 虚拟化平台跑一个真正的、微软定制过的 Linux 内核内核版本会跟随上游更新。这个虚拟机是轻量级的它没有传统虚拟机那种完整的 BIOS、显存、声卡等虚拟设备栈而是只提供 Linux 需要的那部分硬件抽象。启动一个 WSL2 发行版通常只需要一两秒钟这得益于它的特殊架构内核启动到用户态就绪的过程被大幅减化而且 Windows 会常驻一个轻量级的虚拟化基础服务。我刚开始也不信这套轻量虚拟机能有多轻量直到我在任务管理器里看到 Vmmem 这个进程时才意识到它确实是个虚拟机只是被 Windows 管理得足够透明让我感觉它就是终端里的一个普通 Linux 会话。2.2 轻量虚拟机的资源管理vmmem 与动态内存WSL2 的资源管理策略和传统虚拟机不一样。传统虚拟机你给多少内存就是多少开机先占住WSL2 则默认采用动态内存分配Linux 需要多少Windows 就分多少给它理论上可以回收。但这个动态不是无限的默认状态下 WSL2 最多能吃掉你机器物理内存的 50% 左右这是早期版本的默认行为如果你在做大模型推理或者预处理大数据集很容易发现电脑整体变卡。所以部署 AI 环境的第一个重点就是一定要学会配置 .wslconfig 文件。它位于 Windows 用户目录下%UserProfile%.wslconfig专门用来控制 WSL2 的资源上限。我在这台 32GB 内存的机器上用的是下面这组配置[wsl2] memory16GB processors8 swap8GB autoMemoryReclaimgradual这里每项都有讲究。memory 是给 Linux 的最大内存我设 16GB 是为了避免它吞噬掉 Windows 侧的所有内存processors 限制 CPU 核数防止全核满载时 Windows 卡死autoMemoryReclaim 是较新版本 WSL 加入的自动回收选项值设为 gradual 后当 Linux 内不再有大块缓存占用时Windows 会渐进式回收内存而不是等用户手动 wsl --shutdown。如果你要跑 PyTorch DataLoader 这类频繁吃内存的流程建议把 swap 留出来8GB 作为一个缓冲区足够大多数任务使用了。但注意swap 文件默认放在虚拟磁盘里本质上是要写磁盘的不能指望它代替真正的物理内存它只是防 OOM 的兜底。2.3 systemd、Docker、内核模块这些关键能力是怎么落地的WSL2 现在默认支持 systemd这意味着你在里面装 docker、ssh、cron 这类依赖 service 管理的软件时体验和原生 Ubuntu 几乎一样。早期版本 WSL2 没有 systemd只能靠 /etc/wsl.conf 里的 boot 命令和手动启动服务的方式硬凑那才是真的难受。以 Docker 为例在 WSL2 里安装 docker-ce 后systemd 能让 dockerd 以服务形式自动启动不需要你每次开终端先 service docker start。这是内核级 Linux最有说服力的地方普通的用户态模拟方案做不到这种透明性。更关键的是内核模块能力。WSL2 允许你加载一些内核模块比如 NVIDIA 的 nvidia-smi 相关工具、CUDA 运行时的内核驱动接口都是借助这个能力工作的。虽然默认情况下你不需要自己编译内核但如果你需要某些特殊模块例如使用特定文件系统类型WSL2 是支持内核自定义编译的只是步骤比较繁琐大多数人用不到。2.4 别误会WSL2 不是完整替代 Linux 服务器我在跟朋友推荐 WSL2 的时候总会收到一个误解那岂不是我有一台免费的 Linux 服务器了从用户体验来说确实很像但从网络和系统层面看它和你租一台云服务器或者在真机上装 Linux 有本质差异。WSL2 默认走的是 NAT 网络模式Linux 侧拿到的是一个虚拟交换机分配的 IP除非你在 Windows 上做端口转发wsl hostname -I 拿到 IP然后用 netsh 做端口转发否则外部设备无法直接访问你 WSL2 里跑的 Web 服务。宿主机访问 WSL2 内服务时Windows 会做一个 localhost 转发这个在开发时够用但要让局域网里其他机器访问就需要额外配置。另外WSL2 的文件系统分为两部分Linux 自身的 ext4 虚拟磁盘通常挂载在 / 下和 Windows 文件系统挂载在 /mnt/c、/mnt/d 等位置。两者之间的文件访问效率差距悬殊这个我在后面专门讲文件 IO 时会详细展开。搞清楚这些边界之后你就明白 WSL2 的定位了它是给开发者的桌面 Linux 体验而不是给运维的服务器 Linux 体验。3. GPU 直通拆解Windows 驱动如何变成 Linux 里的 CUDA3.1 GPU-PV 的工作原理WDDM、dxgkrnl 与半虚拟化标题里GPU 直通这四个字很吸引人但如果直接把它理解成传统虚拟化领域里的 PCIe Passthrough那就理解偏了。传统虚拟机做 GPU 穿透是把物理显卡直接分配给虚拟机使用宿主 OS 通常就看不到这张卡了。WSL2 的 GPU 访问走的是另一套机制叫 GPU-PVGPU ParavirtualizationGPU 半虚拟化。GPU-PV 的基本思路是Windows 侧保留显卡的完整控制权通过 WDDMWindows Display Driver Model驱动把 GPU 能力以半虚拟化接口的形式暴露给 Linux。在这个架构下WSL2 内运行的程序调用 CUDA / OpenCL / DirectX 时请求会被发送到 Windows 侧的 GPU 调度层由 Windows 的驱动去访问真实硬件再把结果返回给 Linux 应用。这意味着两件事Windows 侧的显卡驱动始终保持对硬件的独占和直接管理不会因为 WSL2 的使用导致驱动冲突。Linux 侧不需要安装任何 NVIDIA 显卡驱动只需要安装 CUDA Toolkit 以及配套的 runtime 库。这套设计非常聪明它既绕开了传统 PCIe 穿透对硬件的独占问题又避免了在虚拟机和宿主机之间维护两套驱动栈的噩梦。代价是会有一定的软件调度开销但 NVIDIA 和微软在这条路径上做了不少优化实测性能差距很小。3.2 WSL2 里 nvidia-smi 的显示逻辑和常见误读第一次在 WSL2 里敲 nvidia-smi 的人都会觉得神奇它居然能显示完整的 GPU 信息、显存使用量、进程列表和原生 Linux 简直一模一样。于是很多人误以为 WSL2 里也装了一整套 NVIDIA Linux 驱动。实际上WSL2 里的 nvidia-smi 本身是一个独立的可执行文件它从 Windows 侧通过 GPU-PV 查询硬件状态然后以 Linux 用户熟悉的格式展示出来。你在 WSL2 里看到的那一长串驱动版本号其实是 Windows 驱动的映射版本而不是 Linux 侧安装的驱动。这个机制带来一个非常关键的部署原则如果手动去 NVIDIA 官网下载Linux x86_64版本的驱动安装到 WSL2 里大概率会把现有的 GPU 工作链路搞坏或者出现驱动冲突。正确做法是让 WSL2 保持不装 Linux 驱动的状态只装 CUDA Toolkit 和它自带的用户态库。3.3 NVIDIA 驱动的单侧安装策略为什么 Linux 侧不能装驱动我在最初调配环境时出于惯性思维直接在 WSL2 里执行了 NVIDIA 官方网站的 Linux 驱动安装脚本结果就是 nvidia-smi 报错、PyTorch 报 CUDA 初始化失败。排查之后我才明白WSL2 的 GPU 访问路径完全不依赖 Linux 侧的内核模块。它需要的是一组用户态库包括 libcuda.so、libnvidia-ml.so 等这些库由 CUDA Toolkit 提供而内核侧的访问则通过 WSL2 核心机制dxgkrnl 模块映射透传给了 Windows 的 WDDM 驱动。所以正确且唯一的做法是在 Windows 侧安装最新且支持 WSL2 的 NVIDIA 驱动然后在 WSL2 内部只安装 CUDA Toolkit不安装任何 NVIDIA 的 Linux .run 驱动包。Windows 侧驱动要保证满足两个条件版本不能太老建议 470.76 及以上这是 NVIDIA 对 WSL2 支持的起步版本但到 2025 年我们普遍用 550 系列以上的新驱动了并且是支持 WSL2 的 Game Ready 或 Studio 驱动。我的建议是直接用 Studio 驱动现在叫 NVIDIA Studio Driver它在 CUDA 场景下测试覆盖面更全稳定性更好。3.4 实际性能数据理论上接近原生实测到底差多少纸上得来终觉浅我实际跑了两个实验来验证 WSL2 的 GPU 性能。第一个实验是矩阵乘法密集任务用 PyTorch 在固定大小的 tensor比如 4096x4096 矩阵乘法上循环 500 次对比 WSL2 和同一台机器原生双系统 Linux 的耗时两者差距在 1%-3% 之间几乎可以认为是噪声。第二个实验是微调一个中小规模的 BERT 模型batch size 设置为 32序列长度 128统计每个 step 的平均时间。WSL2 里大概比原生 Linux 慢了 2%-5%而且这个差距主要来自启动瞬时的驱动调用开销不是持续计算阶段的差异。我还专门看了显存带宽的表现。用 torch 连续执行大规模张量拷贝和卷积操作整体吞吐量约等于原生的 96% 以上。这个数据说明一个问题计算密集型的 AI 任务在 WSL2 里跑性能损失非常有限完全不影响日常开发、调试、训练、推理实验。当然性能接近不等于零差异。如果任务里大量涉及小文件读写、频繁调用系统调用、或者对网络延迟敏感WSL2 的虚拟化边界还是会产生额外的开销。这就要求我们合理规划工程结构把高频 IO 操作放在 Linux 侧文件系统内把网络敏感的组件尽量放在 Windows 侧或做映射。4. 从零到 torch.cuda.is_available()完整部署操作链路4.1 版本匹配清单Windows 版本、驱动、CUDA 版本部署 AI 开发环境最忌讳的就是照着教程敲命令但版本全看运气。WSL2 的 GPU 链路涉及 Windows 版本、显卡驱动、CUDA Toolkit、PyTorch 四个层次每个层次都有兼容性窗口。我在部署前整理了这样一张匹配表你可以直接参考组件我使用的版本说明Windows 系统Windows 11 22H2 及以上Windows 10 21H2 以上也能用但 WSL 新版特性都在 Win11 上优先NVIDIA 驱动551.86Studio 驱动关键驱动在 Windows 侧安装版本决定 CUDA 上限WSL 版本2.0.9通过 wsl --update 更新老版本 WSL 对 autoMemoryReclaim 等新功能支持不全CUDA Toolkit12.3wsl-ubuntu 版对应编译 PyTorch 所用的 CUDA 版本PyTorch2.1.2cu121 版本和 CUDA 12.3 保持兼容注意一个常识Windows 侧安装的驱动支持某个高版本的 CUDA并不意味着你一定得安装最新 CUDA Toolkit。PyTorch 是自带 CUDA runtime 的一部分的你完全可以用 cu118 版本的 PyTorch 跑在支持 CUDA 12 的驱动上NVIDIA 驱动是向后兼容的。所以原则是驱动用新的但 PyTorch 的 CUDA 版本根据项目依赖来选择不必刻意追新。4.2 安装 WSL2 并配置 Ubuntu 系统如果你是第一次接触 WSL直接用管理员 PowerShell 执行这条命令wsl --install这条命令会一次性启用 Windows 虚拟化平台、安装默认发行版通常是 Ubuntu、并把 WSL 版本设置为 2。对于已经装过老版本 WSL 的机器可以分步操作# 启用功能 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启后执行 wsl --set-default-version 2 wsl --update安装指定发行版wsl --list --online wsl --install -d Ubuntu-22.04安装完第一次进入 Ubuntu 会让你设置用户名和密码这里有个容易被忽略的点这个初始用户会被自动加入 sudo 组但还是建议你立刻把 apt 源更换为国内可用源比如阿里云、中科大的镜像站否则后面的 CUDA 下载会非常痛苦。更换源的操作就是把 /etc/apt/sources.list 里的镜像地址替换然后 apt update。这一步网上很多教程我这里只提醒一点一定要确认你的源对应的 Ubuntu 版本代号22.04 是 jammy别用错版本。4.3 CUDA Toolkit 的 WSL-Ubuntu 安装路线CUDA Toolkit 在 WSL2 里的安装方式和原生 Ubuntu 略有不同NVIDIA 专门为 WSL 构建了一个 apt 源。我用的是 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-get update sudo apt-get -y install cuda-toolkit-12-3这里解释一下为什么不直接装 cuda 这个元包cuda 这个包会把驱动相关的组件也拉进来但在 WSL2 里这些组件不仅没用还可能造成冲突。cuda-toolkit-12-3 只装编译和运行需要的用户态库包括 nvcc、cuda-runtime、cublas、cudnn 等。装完之后把 CUDA 的 bin 和 lib 路径加入环境变量我习惯写在 ~/.bashrc 里export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后验证nvcc --version能看到 Cuda compilation tools 的版本信息就说明 Toolkit 安装成功。4.4 PyTorch 安装与版本对应关系PyTorch 的预编译包已经把 CUDA runtime 打包进去了所以你不需要去碰系统的 CUDA 动态库直接根据你要用的 CUDA 版本选择对应的 wheel 即可。我给一个通用的安装命令模板conda create -n ai python3.10 -y conda activate ai pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这里 --index-url 指定了 PyTorch 官方预编译的 CUDA 版本索引。常见的对应关系是PyTorch 版本CUDA 索引适用 CUDA 版本torch 2.1.xcu118CUDA 11.8torch 2.1.xcu121CUDA 12.1torch 2.3.xcu121/cu124CUDA 12.1/12.4我个人的选择是 cu121因为生态最成熟大多数第三方库的预编译版本都覆盖了这个 CUDA 版本。如果你要跑一些老项目依赖 CUDA 11就选 cu118驱动层面完全兼容。关于 conda 还是 venv我推荐用 conda 管理 Python 环境因为 AI 生态里经常需要不同版本的 Python、cudnn、nccl 搭配conda 能把这些非 Python 依赖也管理起来。如果嫌 conda 太慢可以用 micromamba 替代但管理逻辑是一样的。4.5 验证脚本与预期输出环境配置完成不代表万事大吉一定要跑一遍真实的 GPU 计算验证。下面这段脚本是每次新环境我都会执行的点火测试import torch print(PyTorch version:, torch.__version__) print(CUDA available:, torch.cuda.is_available()) print(GPU device count:, torch.cuda.device_count()) print(GPU name:, torch.cuda.get_device_name(0)) print(Current device:, torch.cuda.current_device()) # 在 GPU 上创建一个随机张量并执行矩阵乘法 a torch.randn(2048, 2048, devicecuda) b torch.randn(2048, 2048, devicecuda) c a b torch.cuda.synchronize() print(Matrix multiplication result shape:, c.shape) print(Peak memory allocated: {:.2f} MiB.format(torch.cuda.max_memory_allocated() / 1024 / 1024))预期输出里应该看到 CUDA available: TrueGPU 名称正确显示你的显卡型号矩阵乘法正常完成。如果 CUDA available 是 False大概率是版本链接出了问题要么是 PyTorch 装成了 CPU 版要么是 CUDA Toolkit 和 PyTorch 的 CUDA 版本差距太大。还有一个细节在 WSL2 里你可以同时打开 Windows 任务管理器查看 GPU 利用率会发现和 Linux 侧 nvidia-smi 显示的利用率是同步的。这个观察也能帮你确认 GPU-PV 链路两个端是通的。5. 高负载训练后的真实反馈显存、内存和文件 IO 的边界5.1 显存分配与释放为什么有时候训练完显存还在WSL2 里跑完一个训练脚本有时候用 nvidia-smi 看显存并没有完全释放而是停在一个比较高的水位上。我在原生 Linux 上见过类似情况但在 WSL2 里更容易发生。原因有两层。第一层是 PyTorch 的缓存分配器PyTorch 默认会缓存已释放的显存块以便后续快速复用这在同进程内是好事但进程退出后缓存应该被释放。第二层是 WSL2 的 GPU-PV 机制对显存的占用有一层自己的管理逻辑Windows 侧的显存分配器不会在进程结束后立刻把显存归还给硬件而是保留一段时间。如果你确实需要立即释放显存最直接的办法是wsl --shutdown这会关闭整个 WSL2 虚拟机重开后显存状态会完全干净。代价是当前 WSL2 里所有的终端会话和服务都需要重新启动。所以我的习惯是在长时间高负载训练结束后统一调度一次 wsl --shutdown把资源彻底放干净。对于训练脚本内部合理使用 torch.cuda.empty_cache() 只在需要时才调用因为主动清空缓存会导致下次分配变慢。真正该做的是控制 batch size 让显存峰值在你的显卡容量 85% 以内留出余量给自动混精度的中间变量。5.2 内存上限与 .wslconfig 调优内存问题是我在 WSL2 里排障最多的一类问题。默认状态下WSL2 的内存限制是物理内存的 50%。假设你有 64GB 内存Linux 最多拿 32GB听着够用了。但如果你同时跑 Dataloader 的 num_workers8每个 worker 都会预加载一批数据再加上缓存机制32GB 可能瞬间被打满然后 OOM 直接让训练进程被杀掉而且不会给你任何 Linux 侧明显的报错提示只在日志里留下一段 Kernel panic 级别的记录。我的调优配置前面已经给出过。这里再补充两个参数的重要说明。sparseMode 是较新版 WSL2 引入的用于虚拟磁盘稀疏化防止 Linux 内部删除文件后vhd 文件不缩小导致 Windows 磁盘空间白白占用。设成 true 之后在同一块虚拟磁盘里反复创建和删除大文件比如多个虚拟环境时磁盘空间可以被重新利用。swap 参数很多人忽略但在做大规模数据预处理时作用明显。数据加载过程中出现瞬时内存尖峰不可避免swap 能挡住一部分假 OOM给 GC 和缓存清理争取时间。5.3 /mnt/c 的 9P 协议与文件位置规划这是一个绝大多数第一次用 WSL2 做开发的人都会踩的坑你把项目代码放在 Windows 的 D 盘然后在 WSL2 里 cd /mnt/d/project 执行训练脚本结果发现数据读取速度慢得离谱。原因是 WSL2 访问 Windows 文件系统时走的是 9P 协议这是一个网络文件系统协议本质上是把 Windows 侧的文件访问请求通过网络栈桥接给 Linux 侧的目标进程。对于大量小文件的读取这个路径的性能损耗极其明显实测可以比 Linux 原生 ext4 访问慢一个数量级。更麻烦的是如果你在 /mnt/c 下直接初始化一个 conda 环境或者让 pip 依赖缓存落在 Windows 侧整个包安装和导入过程都会变慢。最正确的文件规划方式把项目代码、数据集、虚拟环境全部放在 Linux 侧文件系统内默认是 ~/ 目录下的某个路径。Windows 侧只保留日常办公文件需要共享时再通过 /mnt/c 互访。具体操作上我一般是这样安排目录结构的~/ ├── projects/ │ ├── nlp-experiment/ │ ├── cv-demo/ │ └── llm-finetune/ ├── datasets/ ├── envs/ # conda 环境统一放这里 └── tools/这样 Linux 侧的读写性能不打折扣同时 Windows 侧也能通过 \wsl$ 路径访问这些文件实现用 Windows 软件查看 Linux 侧数据的需求。VS Code 远程连接 WSL2 后编辑和调试也都在 Linux 侧完成非常自然。5.4 Docker Desktop 还是原生 docker-ceWSL2 上跑 Docker 有两条主流路线Docker Desktop它内部用 WSL2 做后端和直接在 WSL2 里装 docker-ce。我用 Docker Desktop 的时间比较长但它有几个对 AI 开发不太友好的点一是 Docker Desktop 自带的 Linux VM 会额外占用内存二是它和 WSL2 之间夹了一层文件共享和端口转发性能打折扣三是 Docker Desktop 的商业授权政策对大型企业不友好个人用倒是没什么限制。对比下来我更推荐在 WSL2 内部直接安装 docker-ce。原因很简单既然 WSL2 本身就是完整的 Linux那直接让 Linux 自己管理 Docker 进程是性能损耗最小的方案。安装命令很简单curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh sudo usermod -aG docker $USER要支持 GPU 容器的话还需要安装 NVIDIA Container Toolkitdistribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker完成后运行 GPU 容器验证docker run --gpus all nvidia/cuda:12.3.1-runtime-ubuntu22.04 nvidia-smi如果你能看到 GPU 信息说明 Docker 的 GPU 通道也通了。这一步对于复现很多开源项目的镜像环境非常关键因为不少项目 Dockerfile 里写死了 Nvidia 驱动和 CUDA 版本用容器的好处就是把这些依赖隔离开。6. 翻车复盘WSL2 部署 AI 环境最容易踩的四个坑6.1 驱动版本错位带来的连锁反应我遇到过的最难排查的问题是 Windows 侧驱动更新后CUDA Toolkit 的 nvcc 编译一切正常但运行 PyTorch 时报CUDA error: no kernel image is available for execution on the device。当时我怀疑是 PyTorch 版本问题折腾了半天后来才发现是显卡驱动升级到了某个较新版本但 PyTorch 里打包的 CUDA runtime 较旧两者在部分操作上出现兼容性缺口。NVIDIA 显卡驱动一般向后兼容老 CUDA 应用但兼容不代表所有路径都验证过个别版本的组合就会触发奇怪的现象。经验法则升级 Windows 驱动后第一时间在 WSL2 里重新跑一遍第 4.5 节的验证脚本如果出现奇怪的 CUDA 报错优先考虑回退驱动版本或者升级 PyTorch 小版本。别急着怀疑你的代码。6.2 多发行版并存时的 GPU 资源瓜分WSL2 支持同时装多个发行版比如一台机器里同时存在 Ubuntu 22.04 和 Debian 12。这本身不是问题但在 GPU 资源分配上会有个坑GPU 显存和计算资源是被多个发行版共享的如果两个发行版同时跑训练任务Windows 侧的 GPU 调度器不会公平分配可能出现某个发行版把显存占满导致另一个发行版 CUDA 初始化失败。我的建议很简单AI 开发环境只用单一发行版。多个发行版留一个当实验工具箱就够了不要让两个 Linux 环境同时跑 GPU 任务。这样能省掉一票资源竞争问题。6.3 网络配置的隐性坑WSL2 的网络是 NAT 模式这个前面提过。实际使用中最容易出问题的场景是你在 WSL2 里跑了 Jupyter Notebook 服务Windows 浏览器访问 localhost:8888 没问题但手机或局域网其他电脑访问不了。你在 WSL2 里跑分布式训练需要 22 端口接受外部 SSH 连接默认配置下外部无法直接访问。如果你确实需要让局域网设备访问 WSL2 内的服务可以在 Windows 侧用 PowerShell 做端口转发netsh interface portproxy add v4tov4 listenport8888 listenaddress0.0.0.0 connectport8888 connectaddress172.x.x.x其中 172.x.x.x 是 WSL2 当前分配的 IP用 wsl hostname -I 可以拿到。注意 WSL2 每次重启 IP 都可能变化所以这个转发要及时更新。更优雅的方案是给 WSL2 配置镜像网络模式networkingModemirrored这个模式在较新的 WSL 版本里已经可用能让 Linux 共享 Windows 的网络接口外部访问更自然。6.4 WSL2 里跑大规模多卡训练的现实局限与我的选型结论最后泼一盆冷水WSL2 支持多卡 GPU 吗理论上支持因为 GPU-PV 允许 Windows 暴露多个 GPU 给 Linux 侧PyTorch 也能用 torch.cuda.device_count() 看到不止一张卡。但实践经验告诉我多卡场景不要依赖 WSL2。多卡训练需要 NCCL、需要一定的高性能网络通信能力还涉及 GPU 间的直连拓扑比如 NVLink。WSL2 的半虚拟化路径在这些场景下的优化远远不如单卡场景扎实通信开销会显著拉高训练效率打折扣。更现实的方案是单卡开发和调试在 WSL2 里做多卡训练丢给原生 Linux 物理机或云容器实例。所以我自己最终的选型结论是桌面端 Windows WSL2承担日常开发、单卡调试、中小模型训练、快速原型验证服务器端原生 Linux承担多卡训练和大规模数据处理。两者之间用 Git 和 rsync 同步代码与数据环境用容器或者 conda 锁定切换时尽量无缝。这套方案我已经稳定跑了几个月最直观的感受是不再需要频繁重启系统Windows 上各种办公、浏览器、IM 工具保持在线写代码和训练模型都在同一个终端窗口里完成整体工作流顺畅很多。最后分享一个习惯每两周左右我会跑一次 wsl --update把 WSL 的内核和功能更新到较新版本因为微软在这个组件上的迭代非常快很多性能优化和新特性都是通过更新内核带来的而升级成本几乎为零。配合一个定期维护的 .wslconfig这个环境可以长期保持好用。
