1. 为什么要在 WSL2 里折腾 AI 开发环境1.1 一个真实的两难处境搞 AI 开发的人大概率都遇到过这个场景主力机是 Windows显卡驱动、CUDA、各种 Python 环境都装好了但一到跑训练脚本就发现Windows 原生的深度学习生态总有些说不清道不明的坑——某些库在 Windows 上编译不过某些依赖只提供 Linux 版本Docker 在 Windows 上的性能损耗也让人心里没底。可要是彻底切到 Linux 双系统日常办公、娱乐、截图工具、输入法又得重新适应一遍来回重启的代价实在太高。WSL2 就是冲着这个痛点来的。它本质上是跑在 Windows 里的一个轻量级虚拟机内核是微软自己维护的真实 Linux 内核不是早期 WSL1 那种系统调用翻译层。这意味着你在里面跑的东西从内核行为上看就是一个正经的 Linux 发行版。更关键的是从较新的版本开始WSL2 支持了 GPU 直通GPU Paravirtualization也就是把宿主机的显卡以半虚拟化的方式暴露给 Linux 子系统CUDA 和 DirectML 都能直接用上。这套方案能做什么简单说你可以在 Windows 里用着熟悉的编辑器、浏览器、聊天工具同时在一个终端窗口里跑nvidia-smi看到显卡跑 PyTorch 训练脚本吃到 GPU 算力跑 Docker 容器做环境隔离。适合谁适合那些不想放弃 Windows 桌面体验、又需要 Linux 原生 AI 工具链的开发者尤其是只有一台机器、一块显卡的个人开发者和小团队。1.2 这套方案到底解决了什么问题我把它的价值拆成三层来看。第一层是环境一致性你的训练脚本、依赖版本、CUDA 版本都在 Linux 环境下和服务器上的生产环境基本对齐避免了本地能跑、服务器报错的经典问题。第二层是资源复用不用额外买机器不用双系统重启一块显卡在 Windows 和 Linux 之间共享显存按需分配。第三层是工作流整合Windows 侧的 VS Code 可以通过 Remote-WSL 插件直接连进子系统代码编辑、终端、调试、Git 全在一个窗口里完成文件系统还能跨系统访问。不过我得先把丑话说在前面这套方案不是零成本的。GPU 直通对驱动版本、WSL 内核版本、Windows 版本都有要求配置过程中踩坑是常态。下面我会把整个流程拆开讲包括每一步背后的原理和我自己踩过的坑。2. 环境准备与前置条件核查2.1 硬件与系统版本要求在动手之前先确认你的机器满足基本条件。这不是走过场很多配了半天没反应的问题根源就是版本不达标。项目最低要求推荐配置说明Windows 版本Windows 10 21H2Windows 11 22H2 及以上版本越新WSL2 的 GPU 支持越完善显卡支持 CUDA 的 NVIDIA 显卡RTX 系列或更高AMD 显卡走 DirectML 路线生态不同显卡驱动支持 WSL 的专用驱动最新版 Game Ready 或 Studio 驱动必须是 Windows 侧驱动不是 Linux 驱动内存8GB16GB 及以上WSL2 默认最多占用宿主一半内存磁盘40GB 空闲SSD 100GB 以上虚拟磁盘会随使用增长这里有个特别容易搞错的点WSL2 的 GPU 支持靠的是 Windows 侧的显卡驱动你不需要在 Linux 子系统里再装一遍 NVIDIA 驱动。很多人习惯性地在 Ubuntu 里apt install nvidia-driver-xxx结果把环境搞崩。正确的做法是只在 Windows 装好驱动Linux 侧通过/usr/lib/wsl/lib下的库直接调用。注意如果你在 Linux 子系统里误装了 NVIDIA 驱动可能导致nvidia-smi报错或 CUDA 初始化失败。遇到这种情况先卸载 Linux 侧的驱动包重启 WSL 再试。2.2 开启 WSL2 与虚拟化功能Windows 的虚拟化功能默认可能没全开需要手动确认。打开启用或关闭 Windows 功能确保勾选了适用于 Linux 的 Windows 子系统和虚拟机平台两项。如果你习惯命令行用管理员权限的 PowerShell 执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完重启一次。然后设置 WSL 默认版本为 2wsl --set-default-version 2这里解释一下为什么要确认虚拟化WSL2 底层用的是 Hyper-V 的轻量级虚拟化技术如果主板 BIOS 里的虚拟化Intel VT-x 或 AMD-V没开WSL2 根本起不来。有些品牌机出厂默认关闭需要进 BIOS 手动打开。判断方法很简单任务管理器性能标签页里看虚拟化是否显示已启用。2.3 安装 Linux 发行版与内核更新安装发行版最省事的方式是直接wsl --install -d Ubuntu它会自动下载并配置。装完之后建议更新一次 WSL 内核wsl --update内核更新的意义在于GPU 直通相关的驱动模块比如dxgkrnl是随内核一起分发的旧内核可能不支持新显卡或新 CUDA 版本。更新完用wsl --version确认内核版本一般 5.15 以上比较稳妥。装好之后第一次进入系统先做基础更新sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git curl wget这几样是后续几乎所有操作的基础。build-essential提供 gcc、g、make很多 Python 包编译时需要git和curl不用多说。3. GPU 直通的核心原理与验证3.1 GPU 直通是怎么实现的很多人好奇虚拟机里怎么直接用物理显卡这里的技术叫 GPU 半虚拟化GPU-PV。简单类比传统虚拟机直通PCI Passthrough是把整块显卡切给虚拟机独占宿主机就看不到了而半虚拟化是宿主机和子系统共享同一块显卡通过一个叫dxgkrnl的内核驱动做中间层把 GPU 的计算指令转发给物理显卡。这个设计的好处是共享坏处是有一定性能开销。实测下来训练任务的吞吐大概能到原生 Linux 的 90% 左右推理任务差距更小。对于个人开发和小规模实验这个损耗完全可以接受。而且它支持显存动态分配不会像独占直通那样把整块卡锁死。WSL2 里 GPU 相关的库文件放在/usr/lib/wsl/lib包括libcuda.so、libnvidia-ml.so等。系统启动时会自动把这个目录加入库搜索路径。你可以用ldconfig -p | grep wsl看看有没有正确加载。3.2 验证 GPU 是否成功直通装好 Windows 侧驱动、更新完 WSL 内核后进入子系统执行nvidia-smi如果看到显卡型号、驱动版本、显存占用等信息说明直通成功。如果报command not found先确认/usr/lib/wsl/lib/nvidia-smi是否存在存在的话把它加到 PATHexport PATH/usr/lib/wsl/lib:$PATH echo export PATH/usr/lib/wsl/lib:$PATH ~/.bashrc如果nvidia-smi能跑但显示不了显卡多半是 Windows 驱动版本太旧去官网下最新的支持 WSL 的驱动重装。实操心得nvidia-smi显示的 CUDA Version 是驱动支持的最高版本不是你实际安装的 CUDA 版本。实际用哪个版本取决于你装的 CUDA Toolkit 和 PyTorch 编译版本别被这个数字误导。3.3 显存与算力的实际表现我用一块中端显卡做过对比测试同一个 PyTorch 训练脚本在 WSL2 和原生 Linux 下各跑一轮。结果是小批量训练时两者差距在 5% 以内大批量、高显存占用时 WSL2 略慢大概 8% 到 12%。推理场景比如跑一个图像分类模型差距更小基本感知不到。显存方面WSL2 会动态占用不会一上来就吃掉整块卡。你可以在 Windows 任务管理器里看到 GPU 显存被 WSL 进程占用的部分。如果发现显存没释放用wsl --shutdown彻底关掉子系统再重进比在 Linux 里杀进程更干净。4. CUDA 与深度学习框架的落地配置4.1 CUDA Toolkit 的安装选择这里有个关键决策要不要在 WSL2 里装完整的 CUDA Toolkit。我的建议是分情况。如果你只是跑 PyTorch 或 TensorFlow其实不需要单独装 CUDA Toolkit因为 pip 安装的 PyTorch 会自带对应的 CUDA 运行时库。只有当你要编译自定义 CUDA 算子、用 nvcc 编译代码时才需要装完整 Toolkit。装的话推荐用官方 apt 源别用 runfile因为 runfile 会尝试装驱动容易和 WSL 的驱动机制冲突。以 CUDA 12.x 为例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 -y cuda-toolkit-12-4注意源地址里是wsl-ubuntu这是专门为 WSL 准备的源和普通 Ubuntu 源不同。装完把 CUDA 路径加进环境变量export PATH/usr/local/cuda-12.4/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH4.2 PyTorch 环境搭建与版本匹配PyTorch 的版本匹配是新手最容易翻车的地方。核心原则PyTorch 版本、CUDA 版本、显卡驱动版本三者要兼容。驱动版本决定支持的 CUDA 上限PyTorch 的 cu 后缀决定它编译时用的 CUDA 版本。用 conda 或 venv 建独立环境别在系统 Python 里乱装。我习惯用 venvpython3 -m venv ~/ai-env source ~/ai-env/bin/activate pip install --upgrade pip然后根据你的 CUDA 版本装 PyTorch。比如 CUDA 12.1pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完验证import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))cuda.is_available()返回 True 才算成功。如果返回 False先检查nvidia-smi是否正常再检查 PyTorch 的 CUDA 版本和驱动是否匹配。常见现象可能原因解决方向cuda.is_available() 为 FalsePyTorch 装成了 CPU 版重装带 cu 后缀的版本报 CUDA driver version is insufficient驱动太旧更新 Windows 侧驱动报 no kernel image is available显卡算力与编译版本不匹配换对应算力支持的 PyTorch 版本显存溢出但 nvidia-smi 显示空闲WSL 显存未释放wsl --shutdown 后重进4.3 一个完整的验证脚本光看is_available还不够跑个真实的小训练确认端到端没问题import torch import torch.nn as nn device torch.device(cuda if torch.cuda.is_available() else cpu) print(fUsing device: {device}) model nn.Sequential( nn.Linear(1024, 2048), nn.ReLU(), nn.Linear(2048, 10) ).to(device) x torch.randn(64, 1024).to(device) y torch.randint(0, 10, (64,)).to(device) criterion nn.CrossEntropyLoss() optimizer torch.optim.Adam(model.parameters(), lr1e-3) for step in range(100): optimizer.zero_grad() out model(x) loss criterion(out, y) loss.backward() optimizer.step() if step % 20 0: print(fstep {step}, loss {loss.item():.4f}) print(训练完成GPU 端到端正常)这个脚本能跑通说明从驱动到 CUDA 到框架整条链路都通了。5. 开发工作流与性能调优5.1 VS Code Remote-WSL 的正确用法Windows 侧装 VS Code再装 Remote-WSL 扩展然后在 WSL 终端里进入项目目录执行code .VS Code 会自动以远程模式打开。这时候终端、调试器、Python 解释器全在 Linux 侧但界面还是 Windows 的体验很顺。有个细节要注意项目文件放在 Linux 文件系统里别放在/mnt/c/下。跨文件系统访问Windows 的 NTFS 和 Linux 的 ext4 之间性能损耗很大尤其是大量小文件读写时能慢好几倍。正确做法是把代码放在~/projects/这类 Linux 原生路径下需要和 Windows 共享的文件再单独处理。5.2 内存与 CPU 资源限制WSL2 默认会占用最多一半的宿主机内存跑大模型时可能把 Windows 拖卡。可以在用户目录下建.wslconfig文件手动限制[wsl2] memory24GB processors8 swap8GB放在C:\Users\你的用户名\.wslconfig。改完执行wsl --shutdown重启生效。这个配置很实用比如你机器 32GB 内存给 WSL 分 24GB留 8GB 给 Windows 日常用两边都不卡。注意memory设太小会导致训练时 OOM设太大又影响 Windows 流畅度。建议留至少 4GB 给 Windows跑大模型时再按需调整。5.3 磁盘性能与数据存放策略WSL2 的虚拟磁盘是一个ext4.vhdx文件默认会随使用增长但不自动收缩。删了大文件后Windows 侧看到的磁盘占用可能还是很大。手动压缩wsl --shutdown diskpart # 在 diskpart 里执行 # select vdisk fileC:\Users\你的用户名\AppData\Local\Packages\...\ext4.vhdx # compact vdisk数据集存放也有讲究。如果数据集很大放在 Windows 盘符下用/mnt/d/dataset访问读取速度受跨文件系统影响。更好的做法是复制进 Linux 文件系统或者用符号链接。训练时数据加载器DataLoader的num_workers在 WSL2 下建议设小一点因为跨系统 IO 的进程开销比原生 Linux 高。6. 常见问题排查与避坑清单6.1 高频问题速查表问题排查思路解决方式nvidia-smi 找不到检查 /usr/lib/wsl/lib加入 PATH 或重装 WSL 内核GPU 不可用检查 Windows 驱动装支持 WSL 的最新驱动训练中途卡死显存或内存不足调小 batch size检查 .wslconfig磁盘占用不释放vhdx 未收缩diskpart compact vdisk网络下载慢DNS 或镜像源问题换国内 pip/apt 镜像源文件权限异常跨系统挂载权限在 /etc/wsl.conf 配置 metadata6.2 几个我踩过的坑第一个坑是在 Linux 里装 NVIDIA 驱动。前面提过但真的很多人会犯。症状是nvidia-smi报驱动版本不匹配或者 CUDA 初始化失败。解决办法是sudo apt purge掉所有 nvidia 相关包重启 WSL。第二个坑是pip 装 PyTorch 时没指定 index-url。默认源装的是 CPU 版跑起来发现cuda.is_available()是 False还以为是驱动问题折腾半天。记住一定要带--index-url指定 CUDA 版本。第三个坑是**.wslconfig改完没重启**。这个文件只在 WSL 启动时读取改完必须wsl --shutdown再进才生效。我有次改完内存限制发现没变化查了半天才想起来没重启。第四个坑是把项目放在 /mnt/c 下。一开始图方便代码放 Windows 桌面结果 pip 安装、文件扫描、Git 操作都慢得离谱。后来移到~/projects下速度立刻正常。6.3 性能调优的几个实用技巧数据加载是训练瓶颈的常见来源。在 WSL2 下建议把数据集放在 Linux 文件系统DataLoader的num_workers从 2 到 4 起步试别一上来就设 8 或 16跨系统 IO 下 worker 太多反而拖慢。混合精度训练AMP在 WSL2 下收益明显因为减少了显存带宽压力能部分抵消半虚拟化的开销。用torch.cuda.amp几行代码就能开from torch.cuda.amp import autocast, GradScaler scaler GradScaler() for data, target in loader: optimizer.zero_grad() with autocast(): output model(data) loss criterion(output, target) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()另外定期用wsl --shutdown清理一下子系统能释放一些长期运行积累的显存碎片和内存占用。我一般跑完一轮大训练就关一次重进后环境干净下一轮更稳。7. 关于这套方案的一些个人体会用 WSL2 做 AI 开发这套组合我从早期版本一路用到现在最大的感受是它把Windows 办公 Linux 开发这个长期割裂的场景真正缝合起来了。早期 GPU 支持刚出来时确实不稳驱动版本、内核版本、框架版本三者经常打架现在成熟多了只要按版本要求配好日常使用基本无感。但它也不是万能的。如果你要做多卡训练、需要极致的 IO 性能、或者依赖某些内核模块原生 Linux 仍然是更稳的选择。WSL2 的定位是够用且方便不是完全替代。对个人开发者和小团队来说这个够用已经能覆盖八成以上的日常场景了。最后分享一个我常用的检查习惯每次更新 Windows 驱动或 WSL 内核后先跑一遍nvidia-smi和那个小训练脚本确认链路没断再开始正式工作。花两分钟做这个验证能省掉后面几小时的排查时间。这套环境一旦配稳后续就是纯粹的开发体验了值得前期投入这点折腾。 
长河君 · 2026/10/12 19:14:39 · 阅读 1.2k WSL2 GPU直通配置指南：CUDA与PyTorch深度学习环境搭建
1. 为什么要在 WSL2 里折腾 AI 开发环境1.1 一个真实的两难处境搞 AI 开发的人大概率都遇到过这个场景主力机是 Windows显卡驱动、CUDA、各种 Python 环境都装好了但一到跑训练脚本就发现Windows 原生的深度学习生态总有些说不清道不明的坑——某些库在 Windows 上编译不过某些依赖只提供 Linux 版本Docker 在 Windows 上的性能损耗也让人心里没底。可要是彻底切到 Linux 双系统日常办公、娱乐、截图工具、输入法又得重新适应一遍来回重启的代价实在太高。WSL2 就是冲着这个痛点来的。它本质上是跑在 Windows 里的一个轻量级虚拟机内核是微软自己维护的真实 Linux 内核不是早期 WSL1 那种系统调用翻译层。这意味着你在里面跑的东西从内核行为上看就是一个正经的 Linux 发行版。更关键的是从较新的版本开始WSL2 支持了 GPU 直通GPU Paravirtualization也就是把宿主机的显卡以半虚拟化的方式暴露给 Linux 子系统CUDA 和 DirectML 都能直接用上。这套方案能做什么简单说你可以在 Windows 里用着熟悉的编辑器、浏览器、聊天工具同时在一个终端窗口里跑nvidia-smi看到显卡跑 PyTorch 训练脚本吃到 GPU 算力跑 Docker 容器做环境隔离。适合谁适合那些不想放弃 Windows 桌面体验、又需要 Linux 原生 AI 工具链的开发者尤其是只有一台机器、一块显卡的个人开发者和小团队。1.2 这套方案到底解决了什么问题我把它的价值拆成三层来看。第一层是环境一致性你的训练脚本、依赖版本、CUDA 版本都在 Linux 环境下和服务器上的生产环境基本对齐避免了本地能跑、服务器报错的经典问题。第二层是资源复用不用额外买机器不用双系统重启一块显卡在 Windows 和 Linux 之间共享显存按需分配。第三层是工作流整合Windows 侧的 VS Code 可以通过 Remote-WSL 插件直接连进子系统代码编辑、终端、调试、Git 全在一个窗口里完成文件系统还能跨系统访问。不过我得先把丑话说在前面这套方案不是零成本的。GPU 直通对驱动版本、WSL 内核版本、Windows 版本都有要求配置过程中踩坑是常态。下面我会把整个流程拆开讲包括每一步背后的原理和我自己踩过的坑。2. 环境准备与前置条件核查2.1 硬件与系统版本要求在动手之前先确认你的机器满足基本条件。这不是走过场很多配了半天没反应的问题根源就是版本不达标。项目最低要求推荐配置说明Windows 版本Windows 10 21H2Windows 11 22H2 及以上版本越新WSL2 的 GPU 支持越完善显卡支持 CUDA 的 NVIDIA 显卡RTX 系列或更高AMD 显卡走 DirectML 路线生态不同显卡驱动支持 WSL 的专用驱动最新版 Game Ready 或 Studio 驱动必须是 Windows 侧驱动不是 Linux 驱动内存8GB16GB 及以上WSL2 默认最多占用宿主一半内存磁盘40GB 空闲SSD 100GB 以上虚拟磁盘会随使用增长这里有个特别容易搞错的点WSL2 的 GPU 支持靠的是 Windows 侧的显卡驱动你不需要在 Linux 子系统里再装一遍 NVIDIA 驱动。很多人习惯性地在 Ubuntu 里apt install nvidia-driver-xxx结果把环境搞崩。正确的做法是只在 Windows 装好驱动Linux 侧通过/usr/lib/wsl/lib下的库直接调用。注意如果你在 Linux 子系统里误装了 NVIDIA 驱动可能导致nvidia-smi报错或 CUDA 初始化失败。遇到这种情况先卸载 Linux 侧的驱动包重启 WSL 再试。2.2 开启 WSL2 与虚拟化功能Windows 的虚拟化功能默认可能没全开需要手动确认。打开启用或关闭 Windows 功能确保勾选了适用于 Linux 的 Windows 子系统和虚拟机平台两项。如果你习惯命令行用管理员权限的 PowerShell 执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完重启一次。然后设置 WSL 默认版本为 2wsl --set-default-version 2这里解释一下为什么要确认虚拟化WSL2 底层用的是 Hyper-V 的轻量级虚拟化技术如果主板 BIOS 里的虚拟化Intel VT-x 或 AMD-V没开WSL2 根本起不来。有些品牌机出厂默认关闭需要进 BIOS 手动打开。判断方法很简单任务管理器性能标签页里看虚拟化是否显示已启用。2.3 安装 Linux 发行版与内核更新安装发行版最省事的方式是直接wsl --install -d Ubuntu它会自动下载并配置。装完之后建议更新一次 WSL 内核wsl --update内核更新的意义在于GPU 直通相关的驱动模块比如dxgkrnl是随内核一起分发的旧内核可能不支持新显卡或新 CUDA 版本。更新完用wsl --version确认内核版本一般 5.15 以上比较稳妥。装好之后第一次进入系统先做基础更新sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git curl wget这几样是后续几乎所有操作的基础。build-essential提供 gcc、g、make很多 Python 包编译时需要git和curl不用多说。3. GPU 直通的核心原理与验证3.1 GPU 直通是怎么实现的很多人好奇虚拟机里怎么直接用物理显卡这里的技术叫 GPU 半虚拟化GPU-PV。简单类比传统虚拟机直通PCI Passthrough是把整块显卡切给虚拟机独占宿主机就看不到了而半虚拟化是宿主机和子系统共享同一块显卡通过一个叫dxgkrnl的内核驱动做中间层把 GPU 的计算指令转发给物理显卡。这个设计的好处是共享坏处是有一定性能开销。实测下来训练任务的吞吐大概能到原生 Linux 的 90% 左右推理任务差距更小。对于个人开发和小规模实验这个损耗完全可以接受。而且它支持显存动态分配不会像独占直通那样把整块卡锁死。WSL2 里 GPU 相关的库文件放在/usr/lib/wsl/lib包括libcuda.so、libnvidia-ml.so等。系统启动时会自动把这个目录加入库搜索路径。你可以用ldconfig -p | grep wsl看看有没有正确加载。3.2 验证 GPU 是否成功直通装好 Windows 侧驱动、更新完 WSL 内核后进入子系统执行nvidia-smi如果看到显卡型号、驱动版本、显存占用等信息说明直通成功。如果报command not found先确认/usr/lib/wsl/lib/nvidia-smi是否存在存在的话把它加到 PATHexport PATH/usr/lib/wsl/lib:$PATH echo export PATH/usr/lib/wsl/lib:$PATH ~/.bashrc如果nvidia-smi能跑但显示不了显卡多半是 Windows 驱动版本太旧去官网下最新的支持 WSL 的驱动重装。实操心得nvidia-smi显示的 CUDA Version 是驱动支持的最高版本不是你实际安装的 CUDA 版本。实际用哪个版本取决于你装的 CUDA Toolkit 和 PyTorch 编译版本别被这个数字误导。3.3 显存与算力的实际表现我用一块中端显卡做过对比测试同一个 PyTorch 训练脚本在 WSL2 和原生 Linux 下各跑一轮。结果是小批量训练时两者差距在 5% 以内大批量、高显存占用时 WSL2 略慢大概 8% 到 12%。推理场景比如跑一个图像分类模型差距更小基本感知不到。显存方面WSL2 会动态占用不会一上来就吃掉整块卡。你可以在 Windows 任务管理器里看到 GPU 显存被 WSL 进程占用的部分。如果发现显存没释放用wsl --shutdown彻底关掉子系统再重进比在 Linux 里杀进程更干净。4. CUDA 与深度学习框架的落地配置4.1 CUDA Toolkit 的安装选择这里有个关键决策要不要在 WSL2 里装完整的 CUDA Toolkit。我的建议是分情况。如果你只是跑 PyTorch 或 TensorFlow其实不需要单独装 CUDA Toolkit因为 pip 安装的 PyTorch 会自带对应的 CUDA 运行时库。只有当你要编译自定义 CUDA 算子、用 nvcc 编译代码时才需要装完整 Toolkit。装的话推荐用官方 apt 源别用 runfile因为 runfile 会尝试装驱动容易和 WSL 的驱动机制冲突。以 CUDA 12.x 为例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 -y cuda-toolkit-12-4注意源地址里是wsl-ubuntu这是专门为 WSL 准备的源和普通 Ubuntu 源不同。装完把 CUDA 路径加进环境变量export PATH/usr/local/cuda-12.4/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH4.2 PyTorch 环境搭建与版本匹配PyTorch 的版本匹配是新手最容易翻车的地方。核心原则PyTorch 版本、CUDA 版本、显卡驱动版本三者要兼容。驱动版本决定支持的 CUDA 上限PyTorch 的 cu 后缀决定它编译时用的 CUDA 版本。用 conda 或 venv 建独立环境别在系统 Python 里乱装。我习惯用 venvpython3 -m venv ~/ai-env source ~/ai-env/bin/activate pip install --upgrade pip然后根据你的 CUDA 版本装 PyTorch。比如 CUDA 12.1pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完验证import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))cuda.is_available()返回 True 才算成功。如果返回 False先检查nvidia-smi是否正常再检查 PyTorch 的 CUDA 版本和驱动是否匹配。常见现象可能原因解决方向cuda.is_available() 为 FalsePyTorch 装成了 CPU 版重装带 cu 后缀的版本报 CUDA driver version is insufficient驱动太旧更新 Windows 侧驱动报 no kernel image is available显卡算力与编译版本不匹配换对应算力支持的 PyTorch 版本显存溢出但 nvidia-smi 显示空闲WSL 显存未释放wsl --shutdown 后重进4.3 一个完整的验证脚本光看is_available还不够跑个真实的小训练确认端到端没问题import torch import torch.nn as nn device torch.device(cuda if torch.cuda.is_available() else cpu) print(fUsing device: {device}) model nn.Sequential( nn.Linear(1024, 2048), nn.ReLU(), nn.Linear(2048, 10) ).to(device) x torch.randn(64, 1024).to(device) y torch.randint(0, 10, (64,)).to(device) criterion nn.CrossEntropyLoss() optimizer torch.optim.Adam(model.parameters(), lr1e-3) for step in range(100): optimizer.zero_grad() out model(x) loss criterion(out, y) loss.backward() optimizer.step() if step % 20 0: print(fstep {step}, loss {loss.item():.4f}) print(训练完成GPU 端到端正常)这个脚本能跑通说明从驱动到 CUDA 到框架整条链路都通了。5. 开发工作流与性能调优5.1 VS Code Remote-WSL 的正确用法Windows 侧装 VS Code再装 Remote-WSL 扩展然后在 WSL 终端里进入项目目录执行code .VS Code 会自动以远程模式打开。这时候终端、调试器、Python 解释器全在 Linux 侧但界面还是 Windows 的体验很顺。有个细节要注意项目文件放在 Linux 文件系统里别放在/mnt/c/下。跨文件系统访问Windows 的 NTFS 和 Linux 的 ext4 之间性能损耗很大尤其是大量小文件读写时能慢好几倍。正确做法是把代码放在~/projects/这类 Linux 原生路径下需要和 Windows 共享的文件再单独处理。5.2 内存与 CPU 资源限制WSL2 默认会占用最多一半的宿主机内存跑大模型时可能把 Windows 拖卡。可以在用户目录下建.wslconfig文件手动限制[wsl2] memory24GB processors8 swap8GB放在C:\Users\你的用户名\.wslconfig。改完执行wsl --shutdown重启生效。这个配置很实用比如你机器 32GB 内存给 WSL 分 24GB留 8GB 给 Windows 日常用两边都不卡。注意memory设太小会导致训练时 OOM设太大又影响 Windows 流畅度。建议留至少 4GB 给 Windows跑大模型时再按需调整。5.3 磁盘性能与数据存放策略WSL2 的虚拟磁盘是一个ext4.vhdx文件默认会随使用增长但不自动收缩。删了大文件后Windows 侧看到的磁盘占用可能还是很大。手动压缩wsl --shutdown diskpart # 在 diskpart 里执行 # select vdisk fileC:\Users\你的用户名\AppData\Local\Packages\...\ext4.vhdx # compact vdisk数据集存放也有讲究。如果数据集很大放在 Windows 盘符下用/mnt/d/dataset访问读取速度受跨文件系统影响。更好的做法是复制进 Linux 文件系统或者用符号链接。训练时数据加载器DataLoader的num_workers在 WSL2 下建议设小一点因为跨系统 IO 的进程开销比原生 Linux 高。6. 常见问题排查与避坑清单6.1 高频问题速查表问题排查思路解决方式nvidia-smi 找不到检查 /usr/lib/wsl/lib加入 PATH 或重装 WSL 内核GPU 不可用检查 Windows 驱动装支持 WSL 的最新驱动训练中途卡死显存或内存不足调小 batch size检查 .wslconfig磁盘占用不释放vhdx 未收缩diskpart compact vdisk网络下载慢DNS 或镜像源问题换国内 pip/apt 镜像源文件权限异常跨系统挂载权限在 /etc/wsl.conf 配置 metadata6.2 几个我踩过的坑第一个坑是在 Linux 里装 NVIDIA 驱动。前面提过但真的很多人会犯。症状是nvidia-smi报驱动版本不匹配或者 CUDA 初始化失败。解决办法是sudo apt purge掉所有 nvidia 相关包重启 WSL。第二个坑是pip 装 PyTorch 时没指定 index-url。默认源装的是 CPU 版跑起来发现cuda.is_available()是 False还以为是驱动问题折腾半天。记住一定要带--index-url指定 CUDA 版本。第三个坑是**.wslconfig改完没重启**。这个文件只在 WSL 启动时读取改完必须wsl --shutdown再进才生效。我有次改完内存限制发现没变化查了半天才想起来没重启。第四个坑是把项目放在 /mnt/c 下。一开始图方便代码放 Windows 桌面结果 pip 安装、文件扫描、Git 操作都慢得离谱。后来移到~/projects下速度立刻正常。6.3 性能调优的几个实用技巧数据加载是训练瓶颈的常见来源。在 WSL2 下建议把数据集放在 Linux 文件系统DataLoader的num_workers从 2 到 4 起步试别一上来就设 8 或 16跨系统 IO 下 worker 太多反而拖慢。混合精度训练AMP在 WSL2 下收益明显因为减少了显存带宽压力能部分抵消半虚拟化的开销。用torch.cuda.amp几行代码就能开from torch.cuda.amp import autocast, GradScaler scaler GradScaler() for data, target in loader: optimizer.zero_grad() with autocast(): output model(data) loss criterion(output, target) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()另外定期用wsl --shutdown清理一下子系统能释放一些长期运行积累的显存碎片和内存占用。我一般跑完一轮大训练就关一次重进后环境干净下一轮更稳。7. 关于这套方案的一些个人体会用 WSL2 做 AI 开发这套组合我从早期版本一路用到现在最大的感受是它把Windows 办公 Linux 开发这个长期割裂的场景真正缝合起来了。早期 GPU 支持刚出来时确实不稳驱动版本、内核版本、框架版本三者经常打架现在成熟多了只要按版本要求配好日常使用基本无感。但它也不是万能的。如果你要做多卡训练、需要极致的 IO 性能、或者依赖某些内核模块原生 Linux 仍然是更稳的选择。WSL2 的定位是够用且方便不是完全替代。对个人开发者和小团队来说这个够用已经能覆盖八成以上的日常场景了。最后分享一个我常用的检查习惯每次更新 Windows 驱动或 WSL 内核后先跑一遍nvidia-smi和那个小训练脚本确认链路没断再开始正式工作。花两分钟做这个验证能省掉后面几小时的排查时间。这套环境一旦配稳后续就是纯粹的开发体验了值得前期投入这点折腾。