做 AI 开发这几年我对环境折腾这件事一直有种矛盾感。Windows 下装 PyTorch 倒是方便但一到编译 C 扩展、跑 shell 脚本、做模型推理部署尤其在碰到一些只发 Linux 二进制包的库时Windows 那套环境就处处掣肘。双系统又太伤来回重启浪费时间不说Windows 端的数据和 Linux 端的项目还不能随时互访。直到我认真把 WSL2 用起来之后这个问题才算彻底解决。它本质上是一个运行在 Windows 内部的轻量虚拟机带完整 Linux 内核支持 GPU 直通让 Windows 用户也能丝滑地跑 CUDA、PyTorch、大模型推理这类标准的 AI 工作流。这篇文章我会把 WSL2 从环境选型、安装配置、GPU 直通验证、CUDA 环境搭建到常见报错排查完整走一遍。适合刚入手深度学习、想做本地大模型推理、或者受不了 Windows 原生 Python 环境的开发者。你要是已经装了 WSL2 但 GPU 一直不工作可以直接跳到第三节和第五节看排查思路。1. 为什么选择 WSL2 搭建 AI 开发环境1.1 WSL2 不是“虚拟机”那么简单很多朋友一听“虚拟机”就下意识拒绝觉得性能有损耗、操作也麻烦。但实际上 WSL2 跟传统虚拟机差别非常大。WSL1 还是个 API 翻译层把 Linux 系统调用转成 Windows 调用跑起来快但兼容性有限很多依赖系统调用的程序根本跑不了WSL2 干脆换了个思路直接在一个轻量化的 Hyper-V 虚拟机里跑一个完整的、经过微软优化裁剪的 Linux 内核。这意味着什么你在 WSL2 里拿到的不是一个模拟出来的 Linux 外壳而是货真价实的 Linux 内核系统调用几乎 100% 兼容。什么 systemd、Docker、CUDA 驱动栈、eBPF甚至一些内核模块都能正常工作。我在 WSL2 里跑过 Docker 容器、编译过 Linux 内核模块、跑过需要 io_uring 的异步程序体验和物理机上的 Ubuntu 几乎没有差别。另一个容易忽略的点是启动速度。WSL2 的虚拟机不是传统 VM 那种冷启动流程而是按需启动、后台常驻第一次进入需要几秒钟之后开一个终端窗口几乎就是秒开。加上 VS Code 的 Remote-WSL 扩展整个开发体验非常接近本机操作不会有“我在一台虚拟机里”的割裂感。1.2 GPU 直通的原理与真相标题里“GPU 直通”其实是个容易让人误会的说法。WSL2 并不是像 VMware 那样把 NVIDIA 显卡完整分配给虚拟机而是通过微软和 NVIDIA 合作开发的 GPU-PVGPU 半虚拟化技术在 WSL2 内核里暴露了一个/dev/dxg设备节点把 CUDA 调用转发给 Windows 宿主侧的显卡驱动。真正干活的时候你从 Linux 侧发的 CUDA 请求会经过 WSL2 的 dxgkrnl 驱动由 Windows 的 NVIDIA 驱动执行最后把结果返回给 Linux 侧。这个转发层的开销在大多数深度学习任务里完全可以忽略不计。我在 WSL2 里跑 Stable Diffusion 的 fp16 推理和一个 7B 规模的模型微调显存占用、速度与双系统裸跑几乎没有可感知的差别。这里有一个关键结论很多人被各种教程绕晕了WSL2 里不需要安装 Linux 版的 NVIDIA 驱动。你只需要在 Windows 侧装一个支持 WSL2 的 NVIDIA 驱动WSL2 内部就能直接通过 nvidia-smi 看到显卡。Windows 驱动就是 Linux 侧的驱动没有双份驱动的概念这比双系统省心太多了。1.3 双系统、纯 Windows、远程服务器怎么选我身边不止一个朋友在环境选型上纠结很久我说说自己的对比结论。双系统的优势是性能最完整、兼容性最好但代价是切换成本极高。开发过程中经常要查文档、看教程、发消息这些都在 Windows 侧来回重启一次至少五分钟除非你一个上午只专注在一件事上否则效率损失非常大。纯 Windows 跑 AI 的问题在于生态。TensorFlow 和 PyTorch 在 Windows 上的支持已经好了很多但一旦你要用一些底层依赖 Linux 的库比如某些只提供.so的推理引擎、需要编译驱动的项目、或者要部署到 Linux 服务器的代码Windows 就很容易卡壳。而且 Docker Desktop 在 Windows 上默认要跑一个 Linux VM最终还是绕回 Linux 环境。远程服务器适合模型训练和部署但日常开发和调试不适合。就算内网延迟低SSH 来回传文件、编辑器远程插件的体验终究不如本地顺手。而且私有数据放远端很多人心里不踏实。WSL2 正好卡在几者中间本地实时交互、Linux 内核兼容、能跑 Windows 下的 IDE 和浏览器。我现在的工作流是WSL2 里管理代码、跑训练和推理Windows 侧开浏览器看文档、用微信沟通、用截图工具做记录两边通过 VS Code Remote 无缝衔接体验相当顺畅。2. 环境准备与安装配置2.1 硬件和系统版本要求先说硬性条件免得你装到一半卡壳。Windows 10 版本 200420H1及以上或者 Windows 11。低版本的系统默认不支持 WSL2需要手动开启“虚拟机平台”功能很折腾。主板 BIOS 里必须开启虚拟化技术Intel 叫 VT-xAMD 叫 SVM。这一步很多人忽略导致报“无法启动因为此计算机上未启用虚拟化”。内存至少 16GB。跑深度学习训练或者加载大模型16GB 是入门水平想要舒服一点建议 32GB。显卡方面NVIDIA 显卡是体验最好的驱动从 470.76 版本开始支持 WSL2 CUDAAMD 显卡也能用但 AI 生态的兼容性和 CUDA 完全不能比。系统的内存分配也值得注意。WSL2 默认最多使用宿主机 50% 的内存如果 Windows 侧同时开着浏览器和一堆软件内存很容易吃紧。后面我会讲怎么通过.wslconfig文件手动控制分配反正 16GB 内存的用户建议先提前做好心理准备。2.2 标准安装流程现在的 Windows 11 安装 WSL2 很简单管理员权限打开 PowerShell 或 Windows Terminal一条命令wsl --install这条命令会自动开启需要的 Windows 功能下载内核设置默认发行版为 Ubuntu整个过程基本不用干预。如果要做 AI 开发我建议显式指定 Ubuntu 22.04wsl --install -d Ubuntu-22.04安装完成后重启电脑重启完系统会要求你设置 Linux 用户名和密码然后你会落到一个 Bash 提示符下。到这里 WSL2 骨架已经搭好了你可以先跑一下uname -r确认内核版本能看到内核版本号说明 WSL2 已经正确工作。我建议跟着做两件事第一运行sudo apt update sudo apt upgrade -y把系统更新到最新第二安装基础工具链sudo apt install -y build-essential git curl wget unzipbuild-essential 里的 gcc、g 和 make 是后面编译很多 Python 包时的硬依赖不装的话你会碰到各种莫名奇妙的编译报错。2.3 离线安装与下载慢的解决思路很多人的 WSL2 安装卡在下载 Ubuntu 镜像这一步要么是网络差要么是断点续传出问题。我在帮同事排查时常见的现象是wsl --install跑半天最后报个超时错误再试一次又从零开始。碰到这种问题我推荐两种替代方案。第一种直接打开 Microsoft Store 搜索 Ubuntu 22.04从商店页面点击安装。商店下载本身支持断点续传速度通常比命令行稳定。装完以后从开始菜单直接启动 Ubuntu首次启动同样会要你设置用户名密码。第二种如果连商店都慢可以用手动下载方式。打开浏览器访问 Ubuntu WSL 镜像的官方下载页面下载.appx或者.msixbundle文件然后双击安装。这种方式的好处是下载过程可以被浏览器接管支持多线程加速下载完了以后安装是秒级完成的。下载完把文件后缀改成.zip解压后运行里面的ubuntu.exe即可完成注册。还有一点很多教程会教你设置 apt 国内镜像源这个我强烈建议做。在/etc/apt/sources.list里把archive.ubuntu.com替换成可用的国内镜像地址不然装 CUDA 和 PyTorch 依赖时会等到怀疑人生。2.4 Ubuntu 22.04 还是 24.04写这篇之前我专门对比过两个版本。当前阶段我建议选Ubuntu 22.04 LTS。原因很简单AI 工具链的兼容性。PyTorch、TensorFlow 这些框架的预编译 wheel 包对 Ubuntu 22.04 上的 Python 版本3.10和 GCC 版本支持是最成熟的。Ubuntu 24.04 默认带的 Python 3.12 和更新的 OpenSSL反而可能和一些还没跟上节奏的库产生依赖冲突我在 24.04 上安装某些旧版 CUDA 工具链的时候就踩过坑。如果你想用 24.04 图个新也不是不行但要做好心理准备要么所有套件都手动编译要么碰到某些老库安装不上的情况时自己去折腾兼容方案。做 AI 开发最重要的是环境稳定没必要为了系统版本新而给自己找麻烦。22.04 的维护期到 2032 年完全够用了。3. GPU 直通与 CUDA 环境搭建3.1 宿主机驱动优先原则前面说过WSL2 的 GPU 支持依赖 Windows 侧的驱动所以第一步永远是把 Windows 上的 NVIDIA 驱动升级到最新或足够新的版本。打开 Windows 的nvidia-smi看一下 Driver Version如果低于 511建议直接去 NVIDIA 官网下载对应显卡型号的最新驱动。我在实际部署中验证过的一个结论是Windows 驱动版本不要太追求新也不要太旧。太新的驱动偶尔会和某些 CUDA 版本的镜像仓库存在小冲突太旧则不支持 WSL2 的 CUDA 转发。相对稳妥的选择是 NVIDIA 官网的 Game Ready 或 Studio 驱动Studio 驱动稳定性更好适合搞开发和训练我工作室的机器一直用 Studio 驱动。驱动装好以后在 WSL2 终端里直接运行nvidia-smi如果能看到类似下面的输出说明 GPU 直通链路已经通了--------------------------------------------------------------------------------------- | NVIDIA-SMI 535.154.05 Driver Version: 536.67 CUDA Version: 12.2 | ---------------------------------------------------------------------------------------这里注意一个细节输出里显示的 CUDA Version 只是驱动支持的 CUDA 最大版本不代表 WSL2 里就能直接用这个版本的 CUDA。你还需要在 Linux 侧单独安装 CUDA Toolkit。3.2 在 WSL2 内安装 CUDA ToolkitWSL2 里安装 CUDA Toolkit我推荐用 NVIDIA 官方提供的 WSL-Ubuntu 软件源比直接去官网下载 runfile 安装方便得多升级维护也简单。针对 Ubuntu 22.04依次执行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这里有个容易踩的坑很多人直接执行sudo apt install cuda这个包会安装所有 CUDA 组件包括驱动相关的东西体积巨大且容易冲突。装cuda-toolkit-12-4这种带版本号的包就够了它只装编译器和开发库不含驱动。装完以后配置环境变量。编辑~/.bashrc末尾追加export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后执行source ~/.bashrc再运行nvcc --version能正常输出版本号说明 CUDA Toolkit 已经就位。3.3 安装 PyTorch 并跑通 GPU 验证有了 CUDA Toolkit接下来装深度学习框架就顺理成章了。我现在的工作环境是 Python 3.10 PyTorch建议先用 venv 隔离环境别把系统的 Python 环境搞乱。python3 -m venv ~/ai-env source ~/ai-env/bin/activate pip install --upgrade pip注意PyTorch 的安装源分 CPU 和 GPU 版本。直接用pip install torch默认装的是 CPU 版你得指定 CUDA 版本对应的 wheel 源pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124这里cu124表示 CUDA 12.4如果你的 toolkit 是 12.4 就选这个。安装完成后写一个最简单的验证脚本import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0))如果torch.cuda.is_available()输出True说明 PyTorch 已经能用上 GPU。我再建议用一个几秒钟就能跑完的真实计算验证一下而不是只查布尔值import torch a torch.randn(10000, 10000, devicecuda) b torch.randn(10000, 10000, devicecuda) c torch.matmul(a, b) print(c.sum().item())能正常输出一个数值就说明显存分配、计算内核、内存交换全链路都没问题。我第一次配完测这个矩阵乘法的时候看到那一瞬间的输出心里才真正踏实了。3.4 大模型推理的额外配置很多人接 WSL2 不只是为了训练模型更是为了本地跑大模型推理比如 LLaMA 系列、Qwen 系列。这类场景我建议直接装 Ollama它是目前把大模型本地化做得最省心的工具之一。curl -fsSL https://ollama.com/install.sh | sh安装完成以后拉取一个适合你显卡显存的模型。实时来说8GB 显存建议用 7B 量级的量化模型16GB 显存可以尝试 13B 甚至 32B 的四位量化模型ollama run qwen2.5:7bOllama 本身会自动检测 WSL2 里的 CUDA 环境不需要额外配置。我第一次在 WSL2 里跑通 7B 模型对话时生成速度和双系统下几乎一样那一刻真的觉得 WSL2 值得折腾。如果你要做更精细的推理部署比如用 vLLM 做批量推理或提供 OpenAI 兼容 API那就需要在 WSL2 里额外装 vLLM。这一步建议用pip install vllm但在编译过程中会有一些底层依赖需要 C 编译器前面让你装的 build-essential 就是在这时候派上用场的。4. 开发体验优化技巧4.1 文件系统的性能陷阱WSL2 有一个非常容易被忽视的坑跨文件系统访问的性能极差。我见过很多人把代码放在 Windows 的D:\projects目录下然后在 WSL2 里直接访问/mnt/d/projects结果训练时加载数据慢得离谱还以为是 GPU 直通没生效。原因是 WSL2 访问/mnt/d的 Windows 文件系统时要经过 9P 协议转换I/O 开销巨大。而数据密集型任务中最耗时的恰恰是大量小文件的随机读取这个场景下 9P 的瓶颈尤其明显。解决思路很简单所有代码和数据集一定要放在 WSL2 自己的文件系统里也就是~/路径下。Windows 侧的文件复制到 WSL2 我的习惯用法cp -r /mnt/d/datasets /home/username/datasetsWSL2 访问自己的 ext4 文件系统时速度几乎等同宿主机直读。我在实际测试中用同样的数据集做图像分类训练放在/mnt/d下每轮 epoch 耗时 180 秒挪到~/datasets后直接降到 95 秒差距就是这么悬殊。4.2 把 WSL2 迁移到 D 盘很多人的 C 盘是固态硬盘空间本来就不宽裕。WSL2 的虚拟磁盘文件一个 vhdx 后缀的镜像文件动辄二三十 GB如果装了 CUDA、PyTorch 再拉几个模型轻松突破 50GB。把 WSL2 迁移到其他盘符是必须掌握的技能。迁移前先关闭 WSL2wsl --shutdown然后导出当前发行版到镜像文件wsl --export Ubuntu-22.04 D:\wsl_backup\ubuntu2204.tar这一步根据系统体积大小会耗时几分钟到十几分钟。导出完成后可以注销原来的发行版wsl --unregister Ubuntu-22.04注意unregister 会删除原系统的虚拟磁盘文件执行前确认自己的数据已经导出备份好了。最后重新导入到新的目录wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl_backup\ubuntu2204.tar --version 2导入后默认会以 root 用户进入并且默认用户不是原来的用户名。修改方式是在 WSL2 里编辑/etc/wsl.conf加入[user] defaultusername这里的username替换成你原来的 Linux 用户名。改完执行wsl --shutdown再重新启动就能回到原来的用户环境。4.3 VS Code 连接与 Python 解释器配置开发 AI 项目离不开一个趁手的编辑器。VS Code 的 Remote-WSL 扩展是我现在使用频率最高的组合它不需要 SSH不需要额外配置直接就能在本地窗口里打开 WSL2 内的项目目录。安装步骤只有两步在 Windows 的 VS Code 里装WSL扩展扩展 ID 是ms-vscode-remote.remote-wsl然后在任意 WSL2 终端里执行code /path/to/projectVS Code 会自动启动一个连接到 WSL2 的窗口这个窗口里所有操作都发生在 Linux 环境内。你打开的终端是 bash你安装的 Python 解释器是 Linux 版本甚至连断点调试走的都是 WSL2 的进程。这里有个细节要注意VS Code 的 Python 解释器选择。底部状态栏点一下 Python 版本号选择你创建的那个 venv 路径/home/username/ai-env/bin/python。如果不手动指定VS Code 可能会自动选系统 Python导致你 pip 装好的 torch 在编辑器里报找不到模块。配合 Jupyter 插件的体验也值得一提。你在 WSL2 里打开一个.ipynb文件选好 Python 内核后每个 cell 的代码都直接跑在 Linux 环境里GPU 资源同样可用。这比我在 Windows 原生跑 Jupyter 时碰到的各种路径分隔符、环境变量问题干净太多了。4.4 内存和 CPU 限制WSL2 默认不是无限使用宿主机内存的。它默认分配的是宿主机总内存的 50%或者 8GB取两者中较小的一个。跑大模型或者做训练时这个默认值很可能不够用尤其是你怎么调都感觉 WSL2 里的程序总是 OOM 的时候。解决方案是在 Windows 用户目录下创建一个.wslconfig文件比如C:\Users\你的用户名\.wslconfig内容类似[wsl2] memory16GB processors8 swap8GB localhostForwardingtrue改完以后执行wsl --shutdown再重启 WSL2 才能生效。这里的memory是 WSL2 可用内存上限processors是可用 CPU 核心数swap是 WSL2 自己的交换空间大小相当于 Linux 的交换分区。我个人建议如果宿主机是 16GB 内存WSL2 分配 12GB 左右会比较平衡留 4GB 给 Windows 侧开浏览器和编辑器。如果是 32GB 内存直接分配 24GB基本上能满足大部分本地大模型的需求。swap 也不用设得太大SSD 交换速度比内存慢太多swap 只是用来防止 OOM真到了频繁写 swap 的地步说明显存或内存规划本身出问题了。5. 常见问题与排查实录5.1 “WSL2 尚未准备就绪”怎么处理这个报错是我被问过最多的问题也是 WSL2 部署里最容易出状况的一环。通常在初次执行wsl --install之后或者 Windows 更新之后出现。根因多半是 WSL2 内核没有正确安装或更新。先试试手动更新内核wsl --update如果这条命令卡住不动多半是网络问题。可以检查一下 Windows Update 服务是否正常运行或者干脆去微软官方 GitHub 仓库下载 WSL2 内核安装包.msi文件手动安装。下载后双击运行安装完成后重新打开 WSL2 终端。还有一个隐蔽的原因Windows 功能里“虚拟机平台”没有完全启用。在 PowerShell 管理员模式运行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启电脑。这个功能是 WSL2 的底层依赖缺了它一切 WSL2 内核都起不来。5.2 “无法启动因为此计算机上未启用虚拟化”这个报错几乎都和 BIOS 虚拟化开关有关但有意思的是很多人的机器其实已经开了虚拟化问题出在 Windows 的“内核隔离”或“基于虚拟化的安全”和现有的虚拟机功能冲突。排查步骤我建议按顺序来第一步打开任务管理器切到“性能”标签看“虚拟化”一栏是否显示“已启用”。如果显示“已禁用”重启进 BIOS找 Intel Virtualization Technology 或者 SVM Mode开启后保存退出。第二步检查 Windows 可选功能。控制面板 → 程序 → 启用或关闭 Windows 功能确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”两个勾选框都打勾了。这里有一点容易让人困惑Hyper-V 不勾选其实没关系WSL2 并不需要完整的 Hyper-V 角色只需要虚拟化平台这一层。第三步如果前两步都没问题检查 Windows 设置里的“内核隔离”。在 Windows 安全中心 → 设备安全性 → 内核隔离设置里把“内存完整性”关闭然后重启。这个功能有时会干扰 Hyper-V 层的运行。我在某台笔记本上就碰到过这个问题关掉内存完整性后 WSL2 立刻正常启动。5.3 GPU 无法识别nvidia-smi 报错本来nvidia-smi好好的某天打开 WSL2 却发现找不到 GPU 了。这种事我在 Win11 的系统更新后踩过好几次原因基本都是 Windows 驱动更新被 Windows Update 自动替换成了不兼容 WSL2 的版本。排查思路先在 Windows 的 PowerShell 里跑一下nvidia-smi如果 Windows 侧也报找不到 GPU说明 Windows 驱动本身出了问题重装 NVIDIA 驱动即可。如果 Windows 侧正常WSL2 侧报错那就是 WSL2 的驱动转发层出了问题。最直接的修复方法是完全重启 WSL2wsl --shutdown然后再启动 WSL2。如果还不行检查 Windows 驱动的版本在 WSL2 里跑nvidia-smi时它会显示 Windows 驱动版本号这个版本号必须大于 470.76否则 WSL2 的 CUDA 转发根本不可用。我在别人机器上还见过一种特殊情况Windows 侧同时装了 NVIDIA 的 DCH 驱动和标准版驱动两个驱动程序互相覆盖导致 WSL2 的 GPU 接口找不到设备卸载其中一个驱动后就好了。5.4 内存溢出与系统假死WSL2 里跑大模型加载时系统突然卡死鼠标都动不了这个场景相信不少人都遇到过。出现这种问题的本质是你给 WSL2 分配的内存上限设置太大Windows 侧自身可用内存不足而 Windows 在极端内存压力下会频繁触发 swap导致整个系统假死。我的建议是如果你只有 16GB 内存还想跑 13B 模型别硬撑。要么换更小的量化模型要么把.wslconfig里的 memory 调低一点给 Windows 留 4GB 保命。模型虽然大了需要更多内存但系统假死的代价是模型进度毫无价值地丢掉了得不偿失。还有一个相关的细节WSL2 的 vhdx 虚拟磁盘增长到很大后就算删除了里面的文件磁盘文件也不会自动缩小。这会导致 C 盘可用空间不断下降。定期清理大文件后可以用命令压缩虚拟磁盘在 Windows PowerShell 里wsl --shutdown diskpart然后在 diskpart 里选择虚拟磁盘文件所在路径执行compact vdisk手动压缩磁盘空间。5.5 时间不同步和文件权限问题WSL2 有几个算不上大故障但很影响体验的小问题。系统时间不同步。如果你在 WSL2 里跑训练时发现日志时间滞后或者 Git 提交的时间戳不对多半是 WSL2 的时钟跟 Windows 宿主脱节了。重启 WSL2 就会解决或者用sudo hwclock -s强制同步。这个问题不影响模型训练但会影响你对比日志和版本管理建议碰到了就顺手处理一下。还有Exec format error这类奇怪的报错。如果你尝试在 WSL2 里运行一个.exe文件或者 Windows 侧的程序会报这个错。反过来在 Windows 终端里直接运行 Linux 的二进制文件也会。这是架构限制不是出 bug 了需要把文件复制到对的环境里再运行。文件权限的问题也值得一提。你把 Windows 文件cp到 WSL2 后文件权限默认可能变成-rwxrwxrwx这不是什么问题。反过来你在 WSL2 里创建的脚本拿到 Windows 侧运行时可能会因为行尾符差异报错。我的习惯是所有脚本和配置文件都在 WSL2 里用nano或vim编辑别在 Windows 的记事本里改这样能避免行尾符引发的各种诡异问题。末尾分享一些个人体会我用了大半年 WSL2 做 AI 开发踩过不少坑从驱动问题到文件系统性能陷阱都经历过。要说最值得记住的一点就是“别把 Windows 的习惯带进 WSL2”——代码放 Linux 侧驱动只装 Windows 侧环境隔离用 venv大模型分配内存留余地。这套组合下来WSL2 的稳定性和性能已经让我彻底放弃了双系统。最后分享一个小技巧装完 WSL2 以后建议立刻在~/.bashrc里加一条alias wswsl --shutdown以后碰到任何 WSL2 里的诡异问题先执行ws重启一下能解决八成的问题。这个习惯帮我省下了大量排查时间希望也能帮到你。
做 AI 开发这几年我对环境折腾这件事一直有种矛盾感。Windows 下装 PyTorch 倒是方便但一到编译 C 扩展、跑 shell 脚本、做模型推理部署尤其在碰到一些只发 Linux 二进制包的库时Windows 那套环境就处处掣肘。双系统又太伤来回重启浪费时间不说Windows 端的数据和 Linux 端的项目还不能随时互访。直到我认真把 WSL2 用起来之后这个问题才算彻底解决。它本质上是一个运行在 Windows 内部的轻量虚拟机带完整 Linux 内核支持 GPU 直通让 Windows 用户也能丝滑地跑 CUDA、PyTorch、大模型推理这类标准的 AI 工作流。这篇文章我会把 WSL2 从环境选型、安装配置、GPU 直通验证、CUDA 环境搭建到常见报错排查完整走一遍。适合刚入手深度学习、想做本地大模型推理、或者受不了 Windows 原生 Python 环境的开发者。你要是已经装了 WSL2 但 GPU 一直不工作可以直接跳到第三节和第五节看排查思路。1. 为什么选择 WSL2 搭建 AI 开发环境1.1 WSL2 不是“虚拟机”那么简单很多朋友一听“虚拟机”就下意识拒绝觉得性能有损耗、操作也麻烦。但实际上 WSL2 跟传统虚拟机差别非常大。WSL1 还是个 API 翻译层把 Linux 系统调用转成 Windows 调用跑起来快但兼容性有限很多依赖系统调用的程序根本跑不了WSL2 干脆换了个思路直接在一个轻量化的 Hyper-V 虚拟机里跑一个完整的、经过微软优化裁剪的 Linux 内核。这意味着什么你在 WSL2 里拿到的不是一个模拟出来的 Linux 外壳而是货真价实的 Linux 内核系统调用几乎 100% 兼容。什么 systemd、Docker、CUDA 驱动栈、eBPF甚至一些内核模块都能正常工作。我在 WSL2 里跑过 Docker 容器、编译过 Linux 内核模块、跑过需要 io_uring 的异步程序体验和物理机上的 Ubuntu 几乎没有差别。另一个容易忽略的点是启动速度。WSL2 的虚拟机不是传统 VM 那种冷启动流程而是按需启动、后台常驻第一次进入需要几秒钟之后开一个终端窗口几乎就是秒开。加上 VS Code 的 Remote-WSL 扩展整个开发体验非常接近本机操作不会有“我在一台虚拟机里”的割裂感。1.2 GPU 直通的原理与真相标题里“GPU 直通”其实是个容易让人误会的说法。WSL2 并不是像 VMware 那样把 NVIDIA 显卡完整分配给虚拟机而是通过微软和 NVIDIA 合作开发的 GPU-PVGPU 半虚拟化技术在 WSL2 内核里暴露了一个/dev/dxg设备节点把 CUDA 调用转发给 Windows 宿主侧的显卡驱动。真正干活的时候你从 Linux 侧发的 CUDA 请求会经过 WSL2 的 dxgkrnl 驱动由 Windows 的 NVIDIA 驱动执行最后把结果返回给 Linux 侧。这个转发层的开销在大多数深度学习任务里完全可以忽略不计。我在 WSL2 里跑 Stable Diffusion 的 fp16 推理和一个 7B 规模的模型微调显存占用、速度与双系统裸跑几乎没有可感知的差别。这里有一个关键结论很多人被各种教程绕晕了WSL2 里不需要安装 Linux 版的 NVIDIA 驱动。你只需要在 Windows 侧装一个支持 WSL2 的 NVIDIA 驱动WSL2 内部就能直接通过 nvidia-smi 看到显卡。Windows 驱动就是 Linux 侧的驱动没有双份驱动的概念这比双系统省心太多了。1.3 双系统、纯 Windows、远程服务器怎么选我身边不止一个朋友在环境选型上纠结很久我说说自己的对比结论。双系统的优势是性能最完整、兼容性最好但代价是切换成本极高。开发过程中经常要查文档、看教程、发消息这些都在 Windows 侧来回重启一次至少五分钟除非你一个上午只专注在一件事上否则效率损失非常大。纯 Windows 跑 AI 的问题在于生态。TensorFlow 和 PyTorch 在 Windows 上的支持已经好了很多但一旦你要用一些底层依赖 Linux 的库比如某些只提供.so的推理引擎、需要编译驱动的项目、或者要部署到 Linux 服务器的代码Windows 就很容易卡壳。而且 Docker Desktop 在 Windows 上默认要跑一个 Linux VM最终还是绕回 Linux 环境。远程服务器适合模型训练和部署但日常开发和调试不适合。就算内网延迟低SSH 来回传文件、编辑器远程插件的体验终究不如本地顺手。而且私有数据放远端很多人心里不踏实。WSL2 正好卡在几者中间本地实时交互、Linux 内核兼容、能跑 Windows 下的 IDE 和浏览器。我现在的工作流是WSL2 里管理代码、跑训练和推理Windows 侧开浏览器看文档、用微信沟通、用截图工具做记录两边通过 VS Code Remote 无缝衔接体验相当顺畅。2. 环境准备与安装配置2.1 硬件和系统版本要求先说硬性条件免得你装到一半卡壳。Windows 10 版本 200420H1及以上或者 Windows 11。低版本的系统默认不支持 WSL2需要手动开启“虚拟机平台”功能很折腾。主板 BIOS 里必须开启虚拟化技术Intel 叫 VT-xAMD 叫 SVM。这一步很多人忽略导致报“无法启动因为此计算机上未启用虚拟化”。内存至少 16GB。跑深度学习训练或者加载大模型16GB 是入门水平想要舒服一点建议 32GB。显卡方面NVIDIA 显卡是体验最好的驱动从 470.76 版本开始支持 WSL2 CUDAAMD 显卡也能用但 AI 生态的兼容性和 CUDA 完全不能比。系统的内存分配也值得注意。WSL2 默认最多使用宿主机 50% 的内存如果 Windows 侧同时开着浏览器和一堆软件内存很容易吃紧。后面我会讲怎么通过.wslconfig文件手动控制分配反正 16GB 内存的用户建议先提前做好心理准备。2.2 标准安装流程现在的 Windows 11 安装 WSL2 很简单管理员权限打开 PowerShell 或 Windows Terminal一条命令wsl --install这条命令会自动开启需要的 Windows 功能下载内核设置默认发行版为 Ubuntu整个过程基本不用干预。如果要做 AI 开发我建议显式指定 Ubuntu 22.04wsl --install -d Ubuntu-22.04安装完成后重启电脑重启完系统会要求你设置 Linux 用户名和密码然后你会落到一个 Bash 提示符下。到这里 WSL2 骨架已经搭好了你可以先跑一下uname -r确认内核版本能看到内核版本号说明 WSL2 已经正确工作。我建议跟着做两件事第一运行sudo apt update sudo apt upgrade -y把系统更新到最新第二安装基础工具链sudo apt install -y build-essential git curl wget unzipbuild-essential 里的 gcc、g 和 make 是后面编译很多 Python 包时的硬依赖不装的话你会碰到各种莫名奇妙的编译报错。2.3 离线安装与下载慢的解决思路很多人的 WSL2 安装卡在下载 Ubuntu 镜像这一步要么是网络差要么是断点续传出问题。我在帮同事排查时常见的现象是wsl --install跑半天最后报个超时错误再试一次又从零开始。碰到这种问题我推荐两种替代方案。第一种直接打开 Microsoft Store 搜索 Ubuntu 22.04从商店页面点击安装。商店下载本身支持断点续传速度通常比命令行稳定。装完以后从开始菜单直接启动 Ubuntu首次启动同样会要你设置用户名密码。第二种如果连商店都慢可以用手动下载方式。打开浏览器访问 Ubuntu WSL 镜像的官方下载页面下载.appx或者.msixbundle文件然后双击安装。这种方式的好处是下载过程可以被浏览器接管支持多线程加速下载完了以后安装是秒级完成的。下载完把文件后缀改成.zip解压后运行里面的ubuntu.exe即可完成注册。还有一点很多教程会教你设置 apt 国内镜像源这个我强烈建议做。在/etc/apt/sources.list里把archive.ubuntu.com替换成可用的国内镜像地址不然装 CUDA 和 PyTorch 依赖时会等到怀疑人生。2.4 Ubuntu 22.04 还是 24.04写这篇之前我专门对比过两个版本。当前阶段我建议选Ubuntu 22.04 LTS。原因很简单AI 工具链的兼容性。PyTorch、TensorFlow 这些框架的预编译 wheel 包对 Ubuntu 22.04 上的 Python 版本3.10和 GCC 版本支持是最成熟的。Ubuntu 24.04 默认带的 Python 3.12 和更新的 OpenSSL反而可能和一些还没跟上节奏的库产生依赖冲突我在 24.04 上安装某些旧版 CUDA 工具链的时候就踩过坑。如果你想用 24.04 图个新也不是不行但要做好心理准备要么所有套件都手动编译要么碰到某些老库安装不上的情况时自己去折腾兼容方案。做 AI 开发最重要的是环境稳定没必要为了系统版本新而给自己找麻烦。22.04 的维护期到 2032 年完全够用了。3. GPU 直通与 CUDA 环境搭建3.1 宿主机驱动优先原则前面说过WSL2 的 GPU 支持依赖 Windows 侧的驱动所以第一步永远是把 Windows 上的 NVIDIA 驱动升级到最新或足够新的版本。打开 Windows 的nvidia-smi看一下 Driver Version如果低于 511建议直接去 NVIDIA 官网下载对应显卡型号的最新驱动。我在实际部署中验证过的一个结论是Windows 驱动版本不要太追求新也不要太旧。太新的驱动偶尔会和某些 CUDA 版本的镜像仓库存在小冲突太旧则不支持 WSL2 的 CUDA 转发。相对稳妥的选择是 NVIDIA 官网的 Game Ready 或 Studio 驱动Studio 驱动稳定性更好适合搞开发和训练我工作室的机器一直用 Studio 驱动。驱动装好以后在 WSL2 终端里直接运行nvidia-smi如果能看到类似下面的输出说明 GPU 直通链路已经通了--------------------------------------------------------------------------------------- | NVIDIA-SMI 535.154.05 Driver Version: 536.67 CUDA Version: 12.2 | ---------------------------------------------------------------------------------------这里注意一个细节输出里显示的 CUDA Version 只是驱动支持的 CUDA 最大版本不代表 WSL2 里就能直接用这个版本的 CUDA。你还需要在 Linux 侧单独安装 CUDA Toolkit。3.2 在 WSL2 内安装 CUDA ToolkitWSL2 里安装 CUDA Toolkit我推荐用 NVIDIA 官方提供的 WSL-Ubuntu 软件源比直接去官网下载 runfile 安装方便得多升级维护也简单。针对 Ubuntu 22.04依次执行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这里有个容易踩的坑很多人直接执行sudo apt install cuda这个包会安装所有 CUDA 组件包括驱动相关的东西体积巨大且容易冲突。装cuda-toolkit-12-4这种带版本号的包就够了它只装编译器和开发库不含驱动。装完以后配置环境变量。编辑~/.bashrc末尾追加export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后执行source ~/.bashrc再运行nvcc --version能正常输出版本号说明 CUDA Toolkit 已经就位。3.3 安装 PyTorch 并跑通 GPU 验证有了 CUDA Toolkit接下来装深度学习框架就顺理成章了。我现在的工作环境是 Python 3.10 PyTorch建议先用 venv 隔离环境别把系统的 Python 环境搞乱。python3 -m venv ~/ai-env source ~/ai-env/bin/activate pip install --upgrade pip注意PyTorch 的安装源分 CPU 和 GPU 版本。直接用pip install torch默认装的是 CPU 版你得指定 CUDA 版本对应的 wheel 源pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124这里cu124表示 CUDA 12.4如果你的 toolkit 是 12.4 就选这个。安装完成后写一个最简单的验证脚本import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0))如果torch.cuda.is_available()输出True说明 PyTorch 已经能用上 GPU。我再建议用一个几秒钟就能跑完的真实计算验证一下而不是只查布尔值import torch a torch.randn(10000, 10000, devicecuda) b torch.randn(10000, 10000, devicecuda) c torch.matmul(a, b) print(c.sum().item())能正常输出一个数值就说明显存分配、计算内核、内存交换全链路都没问题。我第一次配完测这个矩阵乘法的时候看到那一瞬间的输出心里才真正踏实了。3.4 大模型推理的额外配置很多人接 WSL2 不只是为了训练模型更是为了本地跑大模型推理比如 LLaMA 系列、Qwen 系列。这类场景我建议直接装 Ollama它是目前把大模型本地化做得最省心的工具之一。curl -fsSL https://ollama.com/install.sh | sh安装完成以后拉取一个适合你显卡显存的模型。实时来说8GB 显存建议用 7B 量级的量化模型16GB 显存可以尝试 13B 甚至 32B 的四位量化模型ollama run qwen2.5:7bOllama 本身会自动检测 WSL2 里的 CUDA 环境不需要额外配置。我第一次在 WSL2 里跑通 7B 模型对话时生成速度和双系统下几乎一样那一刻真的觉得 WSL2 值得折腾。如果你要做更精细的推理部署比如用 vLLM 做批量推理或提供 OpenAI 兼容 API那就需要在 WSL2 里额外装 vLLM。这一步建议用pip install vllm但在编译过程中会有一些底层依赖需要 C 编译器前面让你装的 build-essential 就是在这时候派上用场的。4. 开发体验优化技巧4.1 文件系统的性能陷阱WSL2 有一个非常容易被忽视的坑跨文件系统访问的性能极差。我见过很多人把代码放在 Windows 的D:\projects目录下然后在 WSL2 里直接访问/mnt/d/projects结果训练时加载数据慢得离谱还以为是 GPU 直通没生效。原因是 WSL2 访问/mnt/d的 Windows 文件系统时要经过 9P 协议转换I/O 开销巨大。而数据密集型任务中最耗时的恰恰是大量小文件的随机读取这个场景下 9P 的瓶颈尤其明显。解决思路很简单所有代码和数据集一定要放在 WSL2 自己的文件系统里也就是~/路径下。Windows 侧的文件复制到 WSL2 我的习惯用法cp -r /mnt/d/datasets /home/username/datasetsWSL2 访问自己的 ext4 文件系统时速度几乎等同宿主机直读。我在实际测试中用同样的数据集做图像分类训练放在/mnt/d下每轮 epoch 耗时 180 秒挪到~/datasets后直接降到 95 秒差距就是这么悬殊。4.2 把 WSL2 迁移到 D 盘很多人的 C 盘是固态硬盘空间本来就不宽裕。WSL2 的虚拟磁盘文件一个 vhdx 后缀的镜像文件动辄二三十 GB如果装了 CUDA、PyTorch 再拉几个模型轻松突破 50GB。把 WSL2 迁移到其他盘符是必须掌握的技能。迁移前先关闭 WSL2wsl --shutdown然后导出当前发行版到镜像文件wsl --export Ubuntu-22.04 D:\wsl_backup\ubuntu2204.tar这一步根据系统体积大小会耗时几分钟到十几分钟。导出完成后可以注销原来的发行版wsl --unregister Ubuntu-22.04注意unregister 会删除原系统的虚拟磁盘文件执行前确认自己的数据已经导出备份好了。最后重新导入到新的目录wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl_backup\ubuntu2204.tar --version 2导入后默认会以 root 用户进入并且默认用户不是原来的用户名。修改方式是在 WSL2 里编辑/etc/wsl.conf加入[user] defaultusername这里的username替换成你原来的 Linux 用户名。改完执行wsl --shutdown再重新启动就能回到原来的用户环境。4.3 VS Code 连接与 Python 解释器配置开发 AI 项目离不开一个趁手的编辑器。VS Code 的 Remote-WSL 扩展是我现在使用频率最高的组合它不需要 SSH不需要额外配置直接就能在本地窗口里打开 WSL2 内的项目目录。安装步骤只有两步在 Windows 的 VS Code 里装WSL扩展扩展 ID 是ms-vscode-remote.remote-wsl然后在任意 WSL2 终端里执行code /path/to/projectVS Code 会自动启动一个连接到 WSL2 的窗口这个窗口里所有操作都发生在 Linux 环境内。你打开的终端是 bash你安装的 Python 解释器是 Linux 版本甚至连断点调试走的都是 WSL2 的进程。这里有个细节要注意VS Code 的 Python 解释器选择。底部状态栏点一下 Python 版本号选择你创建的那个 venv 路径/home/username/ai-env/bin/python。如果不手动指定VS Code 可能会自动选系统 Python导致你 pip 装好的 torch 在编辑器里报找不到模块。配合 Jupyter 插件的体验也值得一提。你在 WSL2 里打开一个.ipynb文件选好 Python 内核后每个 cell 的代码都直接跑在 Linux 环境里GPU 资源同样可用。这比我在 Windows 原生跑 Jupyter 时碰到的各种路径分隔符、环境变量问题干净太多了。4.4 内存和 CPU 限制WSL2 默认不是无限使用宿主机内存的。它默认分配的是宿主机总内存的 50%或者 8GB取两者中较小的一个。跑大模型或者做训练时这个默认值很可能不够用尤其是你怎么调都感觉 WSL2 里的程序总是 OOM 的时候。解决方案是在 Windows 用户目录下创建一个.wslconfig文件比如C:\Users\你的用户名\.wslconfig内容类似[wsl2] memory16GB processors8 swap8GB localhostForwardingtrue改完以后执行wsl --shutdown再重启 WSL2 才能生效。这里的memory是 WSL2 可用内存上限processors是可用 CPU 核心数swap是 WSL2 自己的交换空间大小相当于 Linux 的交换分区。我个人建议如果宿主机是 16GB 内存WSL2 分配 12GB 左右会比较平衡留 4GB 给 Windows 侧开浏览器和编辑器。如果是 32GB 内存直接分配 24GB基本上能满足大部分本地大模型的需求。swap 也不用设得太大SSD 交换速度比内存慢太多swap 只是用来防止 OOM真到了频繁写 swap 的地步说明显存或内存规划本身出问题了。5. 常见问题与排查实录5.1 “WSL2 尚未准备就绪”怎么处理这个报错是我被问过最多的问题也是 WSL2 部署里最容易出状况的一环。通常在初次执行wsl --install之后或者 Windows 更新之后出现。根因多半是 WSL2 内核没有正确安装或更新。先试试手动更新内核wsl --update如果这条命令卡住不动多半是网络问题。可以检查一下 Windows Update 服务是否正常运行或者干脆去微软官方 GitHub 仓库下载 WSL2 内核安装包.msi文件手动安装。下载后双击运行安装完成后重新打开 WSL2 终端。还有一个隐蔽的原因Windows 功能里“虚拟机平台”没有完全启用。在 PowerShell 管理员模式运行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启电脑。这个功能是 WSL2 的底层依赖缺了它一切 WSL2 内核都起不来。5.2 “无法启动因为此计算机上未启用虚拟化”这个报错几乎都和 BIOS 虚拟化开关有关但有意思的是很多人的机器其实已经开了虚拟化问题出在 Windows 的“内核隔离”或“基于虚拟化的安全”和现有的虚拟机功能冲突。排查步骤我建议按顺序来第一步打开任务管理器切到“性能”标签看“虚拟化”一栏是否显示“已启用”。如果显示“已禁用”重启进 BIOS找 Intel Virtualization Technology 或者 SVM Mode开启后保存退出。第二步检查 Windows 可选功能。控制面板 → 程序 → 启用或关闭 Windows 功能确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”两个勾选框都打勾了。这里有一点容易让人困惑Hyper-V 不勾选其实没关系WSL2 并不需要完整的 Hyper-V 角色只需要虚拟化平台这一层。第三步如果前两步都没问题检查 Windows 设置里的“内核隔离”。在 Windows 安全中心 → 设备安全性 → 内核隔离设置里把“内存完整性”关闭然后重启。这个功能有时会干扰 Hyper-V 层的运行。我在某台笔记本上就碰到过这个问题关掉内存完整性后 WSL2 立刻正常启动。5.3 GPU 无法识别nvidia-smi 报错本来nvidia-smi好好的某天打开 WSL2 却发现找不到 GPU 了。这种事我在 Win11 的系统更新后踩过好几次原因基本都是 Windows 驱动更新被 Windows Update 自动替换成了不兼容 WSL2 的版本。排查思路先在 Windows 的 PowerShell 里跑一下nvidia-smi如果 Windows 侧也报找不到 GPU说明 Windows 驱动本身出了问题重装 NVIDIA 驱动即可。如果 Windows 侧正常WSL2 侧报错那就是 WSL2 的驱动转发层出了问题。最直接的修复方法是完全重启 WSL2wsl --shutdown然后再启动 WSL2。如果还不行检查 Windows 驱动的版本在 WSL2 里跑nvidia-smi时它会显示 Windows 驱动版本号这个版本号必须大于 470.76否则 WSL2 的 CUDA 转发根本不可用。我在别人机器上还见过一种特殊情况Windows 侧同时装了 NVIDIA 的 DCH 驱动和标准版驱动两个驱动程序互相覆盖导致 WSL2 的 GPU 接口找不到设备卸载其中一个驱动后就好了。5.4 内存溢出与系统假死WSL2 里跑大模型加载时系统突然卡死鼠标都动不了这个场景相信不少人都遇到过。出现这种问题的本质是你给 WSL2 分配的内存上限设置太大Windows 侧自身可用内存不足而 Windows 在极端内存压力下会频繁触发 swap导致整个系统假死。我的建议是如果你只有 16GB 内存还想跑 13B 模型别硬撑。要么换更小的量化模型要么把.wslconfig里的 memory 调低一点给 Windows 留 4GB 保命。模型虽然大了需要更多内存但系统假死的代价是模型进度毫无价值地丢掉了得不偿失。还有一个相关的细节WSL2 的 vhdx 虚拟磁盘增长到很大后就算删除了里面的文件磁盘文件也不会自动缩小。这会导致 C 盘可用空间不断下降。定期清理大文件后可以用命令压缩虚拟磁盘在 Windows PowerShell 里wsl --shutdown diskpart然后在 diskpart 里选择虚拟磁盘文件所在路径执行compact vdisk手动压缩磁盘空间。5.5 时间不同步和文件权限问题WSL2 有几个算不上大故障但很影响体验的小问题。系统时间不同步。如果你在 WSL2 里跑训练时发现日志时间滞后或者 Git 提交的时间戳不对多半是 WSL2 的时钟跟 Windows 宿主脱节了。重启 WSL2 就会解决或者用sudo hwclock -s强制同步。这个问题不影响模型训练但会影响你对比日志和版本管理建议碰到了就顺手处理一下。还有Exec format error这类奇怪的报错。如果你尝试在 WSL2 里运行一个.exe文件或者 Windows 侧的程序会报这个错。反过来在 Windows 终端里直接运行 Linux 的二进制文件也会。这是架构限制不是出 bug 了需要把文件复制到对的环境里再运行。文件权限的问题也值得一提。你把 Windows 文件cp到 WSL2 后文件权限默认可能变成-rwxrwxrwx这不是什么问题。反过来你在 WSL2 里创建的脚本拿到 Windows 侧运行时可能会因为行尾符差异报错。我的习惯是所有脚本和配置文件都在 WSL2 里用nano或vim编辑别在 Windows 的记事本里改这样能避免行尾符引发的各种诡异问题。末尾分享一些个人体会我用了大半年 WSL2 做 AI 开发踩过不少坑从驱动问题到文件系统性能陷阱都经历过。要说最值得记住的一点就是“别把 Windows 的习惯带进 WSL2”——代码放 Linux 侧驱动只装 Windows 侧环境隔离用 venv大模型分配内存留余地。这套组合下来WSL2 的稳定性和性能已经让我彻底放弃了双系统。最后分享一个小技巧装完 WSL2 以后建议立刻在~/.bashrc里加一条alias wswsl --shutdown以后碰到任何 WSL2 里的诡异问题先执行ws重启一下能解决八成的问题。这个习惯帮我省下了大量排查时间希望也能帮到你。
