1. 为什么是 WSL2：内核级 Linux 确实不是营销话术
先说我自己的使用场景。我常年在 Windows 笔记本上做 AI 相关的开发，跑模型训练、调 PyTorch、偶尔碰 TensorFlow。以前想在 Windows 上做这些事，要么装双系统，要么开虚拟机，但两条路都很别扭。双系统得重启切换，虚拟机里的 Linux 用 GPU 基本等于痴心妄想。后来微软把 WSL2 做出来，我才真正开始用一套“Windows 做底座、Linux 干活”的开发流。这个标题里的“内核级 Linux”不是夸张，WSL2 确实是一个跑在微软定制 Linux 内核上的轻量虚拟机，和 WSL1 那种“翻译 Windows 系统调用”的兼容层完全不是一个东西。
对 AI 开发者来说，WSL2 最大的价值就是它把两件事同时做到了：一是给你一个几乎原生性能的 Linux 环境，二是通过 GPU 直通让 Linux 里的 CUDA 程序直接调用 NVIDIA 显卡。你不需要重启电脑，不需要双系统，不需要在 Windows 里装 WSL、再在 Linux 里折腾英伟达驱动，整个流程顺下来，Windows 只是宿主，Linux 才是真正的开发工作区。
这篇文章适合谁看？适合手头是 Win10/Win11，想在本地跑 AI 训练、跑大模型推理，又不想放弃 Windows 日常使用的人。也适合正在被 WSL 安装报错、CUDA 识别不了、驱动冲突劝退的新手。我尽量按“为什么这么做、具体怎么做、踩了什么坑”的节奏写，你跟着操作，半小时内能跑起一个能调用 GPU 的 Ubuntu 环境。
1.1 WSL2 和 WSL1 的本质区别
WSL1 的思路是在 Windows 内核里实现一个 Linux 系统调用的兼容层，把 Linux 程序发出来的请求翻译成 Windows API。这种方式启动快、资源占用低，但兼容性有限，很多底层操作（比如需要完整 Linux 内核功能的软件、依赖内核模块的东西）会直接崩。我早期在 WSL1 上尝试跑某些需要内核特性的 AI 工具，经常碰到“Operation not supported”之类的错误，非常劝退。
WSL2 换了个思路，它直接跑一个真正的 Linux 内核，这个内核是微软基于主线 Linux 内核定制维护的，运行在 Hyper-V 虚拟化平台之上。所以 WSL2 里的 Ubuntu 是一个完整的、内核级 Linux 环境，不是模拟器，不是翻译层。内核你能看到、能配置、能挂载内核模块，绝大多数为 Linux 写的软件都能直接跑。
代价是 WSL2 本质是一个轻量虚拟机，启动有一定的内存和 CPU 开销，跨文件系统读写（比如从 Linux 访问 /mnt/c）比原生慢。但这一点对 AI 开发影响不大，因为代码、数据集这些重文件都应该放在 Linux 自己的文件系统里，而不是丢在 Windows 盘里来回折腾。
1.2 双系统、虚拟机、WSL2：AI 开发选型对比
我在一台 16G 内存 + RTX 4060 的笔记本上把这三种方案都试过，感受完全不一样。
双系统性能最“原生”，GPU 驱动也是真正的 Linux 驱动，跑训练没有任何虚拟化损耗。麻烦在于切换系统要重启，Windows 和 Linux 之间的文件共享要靠额外分区或网络，日常开发效率反而低。虚拟机方案（比如 VMware/VirtualBox）在 GPU 直通上很难搞。普通虚拟机的 GPU 是虚拟出来的，想让 Linux 客户机直接访问物理显卡，通常要配合显卡厂商的半虚拟化方案，配置复杂度高，性能损耗也不小。
WSL2 的 GPU 直通走的是微软和 NVIDIA/AMD 合作搞的半虚拟化路径，Linux 侧不需要单独装显卡驱动，直接通过 Windows 驱动访问 GPU。这套方案在 AI 场景下性能已经接近原生，而且切换成本为零。我实测跑同一个 PyTorch 训练脚本，WSL2 和双系统 Linux 的吞吐量差距在几个百分点以内，对一些小步长迭代的 RL 训练、推理任务来说基本无感。
所以我的结论很明确：除非你要做多卡集群、要用 NCCL 大规模多机训练，或者非要折腾一些依赖特定内核特性的底层 CUDA 源码，否则在 WSL2 里做单卡 AI 开发是完全够用的。省下双系统重启的时间，省下虚拟机 GPU 配置的痛苦，这笔账很划算。
2. GPU 直通的底层原理：Windows 驱动和 Linux CUDA 是怎么打通的
第一次听说“WSL2 里能跑 CUDA”时，我第一反应是：这怎么可能？Windows 驱动和 Linux 生态明明是两套东西。搞清楚背后的机制之后，你会对整个方案有更清晰的判断，遇到问题也知道往哪个方向排查。
2.1 从 PCIe 直通到半虚拟化的演进
传统的虚拟机 GPU 直通，是把物理显卡整体分配给某个虚拟机，客户机里直接加载原生 Linux 驱动，独占那整张卡。这种方式性能确实好，但往往需要额外的显卡硬件：一个虚拟机独占一张卡，宿主机自己还得再有一张卡来显示输出，普通开发者的设备根本满足不了。
WSL2 的方案不一样，它用的是 GPU 半虚拟化（GPU-PV）。微软在 Windows 的图形驱动模型里增加了一层虚拟化总线，把物理 GPU 的能力暴露给 WSL2 这个轻量虚拟机。具体来说，Windows 侧的 WDDM 驱动负责和显卡硬件打交道，然后通过 dxgkrnl 驱动、/dev/dxg 设备把这些能力传给 Linux 侧。Linux 里跑的 CUDA 程序并不直接操作显卡寄存器，而是走“用户态 CUDA 库 -> 半虚拟化总线 -> Windows 驱动 -> 物理 GPU”这条链路。
这套机制的好处很明显：只要 Windows 驱动能识别这块显卡，WSL2 里的 Linux 就能用，不需要在 Linux 侧单独装显卡驱动。我一开始老觉得不踏实，总觉得“Linux 里没驱动怎么干活”，后来想明白了，驱动栈是分层的，Linux 里的 CUDA runtime 只需要和虚拟化总线通信，真正的硬件驱动工作在 Windows 宿主里。
2.2 为什么 NVIDIA 驱动装在 Windows 上，WSL2 里 CUDA 照样能跑
NVIDIA 从 R470 时代的驱动开始正式支持 WSL2。现在新版的 Windows 驱动，安装的时候会自动包含一个专门给 WSL 用的用户态组件，Linux 侧通过 libcuda.so 和这个组件对接。
所以在 WSL2 的 Ubuntu 里执行 nvidia-smi，你看到输出的驱动版本其实对应的是 Windows 侧安装的驱动版本，CUDA 版本号也反映的是 Windows 驱动的能力。很多新手在这里会犯一个严重的错误：把传统的 Linux 版 NVIDIA 驱动安装包（.run 文件或 dkms 内核模块）弄到 WSL2 里安装，结果搞到内核模块加载失败、启动黑屏驱动冲突，最后又得从头恢复 WSL 镜像。我自己的原则是：WSL2 里永远不要装 Linux 版 NVIDIA 驱动，只保持 Windows 驱动最新就够。
还有个很小的细节，你在 WSL2 里跑 CUDA 程序时，GPU 也可以同时被 Windows 侧的桌面程序使用，两者共享同一块显卡。好处是方便，坏处是显存会被 Windows 桌面主题、浏览器硬件加速等占掉一部分。后面我会说怎么尽量把显存留给训练任务。
3. 从零实操：Win10/Win11 下 WSL2 + Ubuntu 完整部署
接下来进入动手环节。这一步的核心目标：把 WSL2 跑起来，装上 Ubuntu 发行版，把系统从默认的 C 盘迁到 D 盘，再做基础 Linux 环境配置。如果你已经装好 WSL 和 Ubuntu，可以直接跳到第 4 节看 GPU 直通和 CUDA 部分。
3.1 先搞清楚系统前提条件
WSL2 对 Windows 版本有要求。Win11 全系没问题，Win10 需要 2004 以上版本，且系统要支持并开启虚拟化技术。打开任务管理器，切到“性能”页，点 CPU，看“虚拟化”是否显示“已启用”。如果显示“未启用”，需要进 BIOS 开启 SVM（AMD）或 Intel VT-x。这一步不做，后面会一直报“WSL2 无法启动，因为此计算机上未启用虚拟化”。
Win10 用户还建议顺手更新一下 Windows 到最新版本，老版本的内核组件和新版 WSL 不一定兼容。我自己遇到过一台 LTSC 版本的老系统，wsl --install 命令压根不识别，后来查资料发现是系统版本太老，需要手动启用功能并离线安装 WSL 内核包，第 5 节我会专门讲离线安装的完整流程。
3.2 用一条命令装好 WSL2 和默认发行版
在管理员权限的 PowerShell 或 CMD 里执行：
wsl --install这条命令会自动完成三件事：启用“适用于 Linux 的 Windows 子系统”功能、启用“虚拟机平台”功能、默认安装最新版的 WSL2 内核和 Ubuntu 发行版。装完重启系统，会提示你设置 Linux 用户名和密码。
如果你想装其他发行版，先看列表再指定：
wsl --list --online wsl --install -d Ubuntu-22.04这里有一个新手非常容易困惑的点：到底装 22.04 还是 24.04？我的建议是如果只是跑 AI 训练，两者差别不大，PyTorch、TensorFlow 对系统版本要求并不苛刻，装能稳定拿到软件源的版本即可。Ubuntu 24.04 的 apt 源已经足够新，长期维护周期也长；Ubuntu 22.04 则更“稳”，很多老教程里的命令直接能用。我目前主力是 22.04，因为团队里其他人的环境统一在这个版本，方便对拍问题。
还有个高频问题：wsl --install 下载发行版镜像时进度条长时间卡住。这通常是内核组件或镜像下载失败，解决办法要么是重新执行 wsl --update 更新 WSL 内核，要么干脆从微软商店页面手动安装 Ubuntu。商店页安装和命令行安装的效果完全一样，下载失败时值得一试。
3.3 把发行版迁到 D 盘：两条命令和一次干净的卸载
WSL2 默认把虚拟磁盘文件（vhdx）放在 C 盘的用户目录里，装着装着 C 盘就飘红了。AI 项目的数据集动辄几十 GB，模型权重文件也是几个 GB 起步，所以最好从一开始就把发行版放到 D 盘。
迁到 D 盘的方法并不复杂，核心是用 wsl --export 导出，wsl --import 再导入，重新指定安装目录。先把 WSL 完全停掉再操作：
wsl --shutdown wsl --export Ubuntu D:\wsl-backup\ubuntu.tar wsl --unregister Ubuntu注意 --unregister 会删除当前发行版及其内部所有文件。确认你没有什么重要数据没备份，再执行这一步。导入时指定新的存储位置：
wsl --import Ubuntu D:\WSL\Ubuntu --version 2导入完成后，默认会用 root 用户登录，而不是原来设置的用户名。我建议直接改 /etc/wsl.conf 指定默认用户，省得每次切换：
# 在 WSL2 Ubuntu 里执行 sudo tee /etc/wsl.conf << 'EOF' [user] default=你的用户名 EOF改完执行 wsl --shutdown 再重新进入 WSL，就会以你的普通用户登录了。
迁移后的另一个小技巧是压缩虚拟磁盘。D 盘上这个 vhdx 文件很大，但实际数据可能没那么多，因为 WSL 不会自动回收未用空间。用 DiskPart 可以压缩，以管理员身份打开 CMD 执行：
diskpart select vdisk file="D:\WSL\Ubuntu\ext4.vhdx" attach vdisk readonly compress vdisk detach vdisk exit实测一个装了 CUDA 工具链和模型文件的发行版，压缩前后能差出 5~10 GB，很有用。
3.4 换源、装基础工具和 Python 环境
装完 Ubuntu，第一件事是换 apt 源。默认源在国外，下载速度可以慢到令人崩溃。我用的是清华大学的镜像源，改法如下：
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list sudo apt update && sudo apt upgrade -y如果是 24.04 版本，sources 文件路径稍有变化，通常在 /etc/apt/sources.list.d/ubuntu.sources，把里面的 archive.ubuntu.com 替换成镜像站域名即可。
基础工具我也会一次性装好，涵盖编译环境、版本控制、网络工具和日常运维命令：
sudo apt install -y build-essential git curl wget unzip zip vim htop net-tools安装 Python 不再建议用系统自带的 Python 或手动编译，Miniconda 是最省事的方式，环境隔离对 AI 开发来说是刚需。到清华镜像站下载 Miniconda 安装脚本，装好后顺手设置 conda 和 pip 的国内源：
wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ pip config set global.index-url https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple到这里，WSL2 的 Linux 环境已经算一个能日常使用的开发环境了。接下来的重头戏是 GPU 直通和 CUDA 生态。
4. NVIDIA GPU 直通：从驱动更新到 PyTorch 真正吃满显存
这是整篇文章最核心的部分。目标很明确：让 WSL2 里跑的 PyTorch/TensorFlow 程序看到 GPU，并真正把计算卸载到显卡上。
4.1 第一步永远是更新 Windows 侧驱动
WSL2 的 GPU 支持依赖 Windows 驱动的半虚拟化组件，所以驱动必须是新版本。去 NVIDIA 官网下载最新的 Windows 驱动，安装时选择“自定义安装”，确保勾选上包含 WSL 支持的组件。现在的新驱动默认都会带上，但如果你用的是很老的驱动，建议务必更新。
装完重启系统（如果是驱动更新的话），然后在 WSL2 终端里执行：
nvidia-smi正常情况下会输出显卡型号、显存容量、驱动版本号。如果你能看到和 Windows 侧版本号一致的信息，说明 GPU 直通已经通了。这一步是全文的分水岭——能看到 nvidia-smi，后面基本就是软件层面的安装；看不到，大概率是驱动版本或 BIOS 虚拟化设置的问题。
注意，如果 nvidia-smi 报错找不到设备，先不要急着在 WSL 里重装驱动，按这个顺序排查：Windows 侧驱动版本是否新到支持 WSL；系统是否启用了虚拟化平台；WSL2 是否是默认版本；最后再考虑卸载 WSL 重新安装。
4.2 用 conda 建环境，用 PyTorch 官方轮子装 CUDA
很多教程会让你在 WSL 里单独安装 CUDA Toolkit，但说实话，如果你只用 PyTorch/TensorFlow，这一步完全不用。PyTorch 官方编译好的 wheel 包自带 CUDA runtime，你不需要系统级的 nvcc 也能训练。真正需要单独装 CUDA Toolkit 的场景是你要编译自定义 CUDA 扩展、用 cuDNN 的某些源码接口，那时候再装也不迟。
我的推荐流程是：
conda create -n ai python=3.10 -y conda activate ai pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121cu121 表示 CUDA 12.1，这是目前兼容性最广的版本之一。如果你有更新的显卡（比如 40 系），也可以用 cu124 或 cu128。安装完成之后，执行这段 Python 验证代码：
import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.mem_get_info())如果输出里 torch.cuda.is_available() 是 True，说明整个 GPU 直通链路已经跑通了。我第一次看到输出 True 的时候还挺激动的，毕竟踩了一下午的坑才走到这一步。
这里有个容易踩的坑：在 WSL2 里用 pip list 检查，看到 torch 版本带 +cu121 后缀，但 torch.cuda.is_available() 返回 False。这种问题九成出在驱动栈上，比如 Windows 驱动太老、WSL 内核版本和驱动不匹配。处理办法是先执行 wsl --update 更新 WSL，再更新 Windows 驱动，然后把 conda 环境重新建一遍，基本能解决。
4.3 如果需要系统级 CUDA Toolkit 和 cuDNN
如果你的开发工作流需要源码编译 CUDA 扩展，或者跑一些依赖 nvcc 的工具链，那就用 NVIDIA 官方提供的 WSL 版 CUDA Toolkit。最稳妥的方式是用 apt 源安装，而不是在 Linux 里下载 .run 文件。官方文档里的安装步骤大概是：
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装完之后需要把 CUDA 的 bin 和 lib 路径加进环境变量，比如在 ~/.bashrc 里加：
export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATHcuDNN 也可以用 apt 装，NVIDIA 的 WSL 仓库里直接提供对应版本，安装后导入 PyTorch 时就不需要额外配置。但再次强调，绝大多数 AI 训练需求并不需要走到这一步，别为了追求“完整”而给自己增加不必要的复杂度。
4.4 显存分配和资源调度的实际经验
GPU 直通之后，WSL2 里的程序可以直接和 Windows 共享同一块物理显卡，但显存分配不如原生独占那么“干净”。实测下来，Windows 桌面环境、浏览器硬件加速、游戏后台进程，都会占用几百 MB 到一两 GB 显存。如果你的显卡只有 8GB，跑模型时就要稍微精打细算一点。
一个小技巧是训练之前用任务管理器看一下 GPU 显存占用，把不必要的浏览器硬件加速关掉。另一个更实用的方法是给 WSL2 设置内存和 CPU 上限，避免 WSL 把宿主机的内存吃得干干净净。在 Windows 用户目录下创建一个名为 .wslconfig 的文件，写入：
[wsl2] memory=12GB processors=8 swap=8GB打开 WSL 后执行 wsl --shutdown 再重启，让配置生效。实测下来，这种限制对单卡训练影响不大，但对整个系统的日常流畅度帮助很大，尤其是在内存只有 16G 的机器上。
5. 高频问题排查实录：把这几个报错一次说透
我在部署 WSL2 AI 环境的过程中，被几个问题折腾过很多次。下面这些全是实打实遇到过的，按出现频率排个序。
5.1 启动报错：WSL2 无法启动，因为此计算机上未启用虚拟化
这是新手第一关。wsl --install 装好了，但运行 wsl 或打开发行版时报“WSL2 无法启动，因为此计算机上未启用虚拟化”。
排查顺序如下。先看 BIOS 里的虚拟化开关，AMD CPU 找 SVM Mode，Intel CPU 找 VT-x/Virtualization Technology，确保是 Enabled，重新开机进系统。然后打开 Windows 功能面板，确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两个选项都勾上了。最后检查 Windows 的 Hyper-V 是否被安全软件或系统策略禁用。
如果 BIOS 里开了还是报错，可以用管理员 PowerShell 执行：
bcdedit /set hypervisorlaunchtype auto然后把系统重启。这个命令是让 Windows 的 Hypervisor 从启动时就加载，WSL2 依赖它。我自己有一次是在更新系统后遭遇了这个报错，重新设置 hypervisorlaunchtype 就好了。
5.2 下载慢、wsl --install 卡住的处理思路
很多人卡在这一步就没耐心了。我的经验是，wsl --install 的下载过程受网络环境影响很大，但没必要动用什么复杂手段。先说 apt 和 pip 的慢，那是发行版内软件源的网络问题，换国内镜像源是标准解法，上面已经写过。wsl --install 本身卡在“Installing, this may take a few minutes…”时，我一般先等十分钟，还不动就 Ctrl+C 取消，执行 wsl --update 更新内核，然后再跑一次。
如果 wsl --update 也卡住，可以手动下载新版 WSL 内核安装包。微软官方有独立的 WSL2 Linux 内核更新包，在官网搜索 wsl_update_x64.msi，下载安装后重启，WSL 内核就更新到了新版本。这个方法是离线安装的基础，后面马上会用到。关键是不用碰任何第三方加速工具，老老实实从官方渠道拿。
5.3 每次重启 IP 会变，虚拟机 IP 对不上的问题
WSL2 因为是轻量虚拟机，它的 IP 地址在每次 Windows 重启后都可能变化。如果你用 SSH 连 WSL、或者在 Windows 里配置了端口转发，就会发现非常难受。更坑的是，WSL2 里的网络默认是 NAT 模式，Windows 访问 WSL 里的服务还好，局域网其他机器要访问 WSL 里的服务就麻烦。
其实在 WSL2 里跑 AI 服务，最省心的方式是用 WSL 自带的端口转发能力。WSL2 有 localhost 回环支持，Windows 浏览器直接访问 localhost:7860 这类端口就能连到 Linux 里的 Gradio/Flask 服务。对外提供服务的情况不多，真有需求，建议直接用 netsh 做端口转发，规则写在 Windows 侧，而不是去配 WSL 的网络。
5.4 跨文件系统性能坑：永远不要在 /mnt/c 上跑训练
WSL2 访问 Windows 文件系统（/mnt/c）用的是 9P 协议，性能很差。我试过把数据集放在 D 盘，然后在 WSL2 里通过 /mnt/d 路径读取，训练时数据加载慢到怀疑人生，GPU 使用率一直上不去。改成把同步的代码和数据放到 WSL 的 Linux 文件系统（/home/用户名）里后，性能立刻正常。
这个原则一定要记住：代码和模型放 Linux 原生盘，数据也放 Linux 原生盘，Windows 盘只做传输。你的工作目录在 /home 下，通过 Windows 的资源管理器访问 \wsl$\Ubuntu\home... 可以看到文件，跨系统传文件用这种方式就很舒服。
5.5 Win10 的老系统：离线安装 WSL2 的完整流程
如果系统版本太老，或者环境特殊不能在线安装，离线安装是必须掌握的。大致流程分四步：启用 Windows 功能、安装 WSL 内核、设置 WSL2 为默认版本、导入发行版镜像。
第一步，管理员 PowerShell 或 CMD 执行两条 dism 命令：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart重启系统。第二步，安装 WSL2 内核更新包（wsl_update_x64.msi）。这个包可以从微软官网下载，如果机器完全离线，就只能在联网机器上下好再拷过去。第三步，管理员 PowerShell 执行：
wsl --set-default-version 2第四步，准备一个 Ubuntu 发行版的 rootfs tar 包（比如从已装好 WSL 的机器上导出），然后：
wsl --import Ubuntu D:\WSL\Ubuntu .\ubuntu.tar --version 2导入完成就能用 wsl -d Ubuntu 进入系统。这个流程适合企业内网、断网环境，我帮朋友装过一次，整个过程半小时内完成，唯一麻烦的是提前准备安装包。
6. 延伸实战：在 WSL2 里跑 DeepSeek 等本地大模型
环境搭好之后，最有成就感的用法之一是本地跑大模型。WSL2 的 GPU 直通在这方面优势特别明显：你可以把 Ollama 跑在 Linux 里，Windows 上照样做别的事。
6.1 用 Ollama 一键跑 DeepSeek 蒸馏模型
Ollama 是目前最省事的本地大模型运行工具，一条命令装上，再一条命令拉模型。在 WSL2 Ubuntu 里执行：
curl -fsSL https://ollama.com/install.sh | sh ollama run deepseek-r1:7b第一次运行会自动下载对应模型的 GGUF 量化权重，之后就可以直接在终端里和模型对话。Ollama 在运行时自动检测 GPU，如果 nvidia-smi 能识别到显卡，它就会把推理卸载到 GPU。
我实测在 RTX 4060 8G 显存的笔记本上，deepseek-r1:7b 的 Q4 量化版本，生成速度大约在 20~40 token/s 之间，流畅度完全够日常问答用。如果用 14b 版本，显存占用大概 9~10 GB，在 12G 显存的卡上可以跑，速度会慢一点。部署前最好心里有本账，硬要跑超出显存的模型也不是不行，但推理速度会骤降，体验很差。
6.2 本地大模型在 WSL2 里的性能损耗
很多人担心虚拟化会不会让推理速度大打折扣。我自己做了一个简单对比：同一个 GGUF 模型，用 WSL2 里的 Ollama 跑，和理论上的原生 Linux 环境跑，生成速度基本在一个量级。因为推理任务的核心是矩阵计算和显存带宽，WSL2 的 GPU 半虚拟化在传输层上有一定开销，但现在的驱动已经优化得很不错，对 token 生成速度的影响几乎可以忽略。
如果你用 vLLM 这类推理框架做批量推理，性能同样可控。但注意 PagedAttention 等特性对虚拟内存管理的依赖较高，在 WSL2 里实测偶尔会有兼容性问题，我建议遇到框架报错时优先换回 Ollama 或者 llama.cpp 的简单部署路线。
6.3 训练场景注意事项与资源调优
如果跑的不只是推理，还有训练，会有两个需要留意的地方。第一，WSL2 默认内存上限是物理内存的 50%（除非你配置了 .wslconfig），大模型训练时会出现 OOM。我个人的配置是给 WSL 分 12G，swap 8G，Windows 侧留 4G 保证桌面流畅，这在我 16G 内存的机器上比较均衡。
第二，训练过程中的显存分配会有碎片化风险。因为 Windows 桌面的 GUI 也占用显存，当你在 WSL2 里跑训练时，Windows 侧突然有动画、特效抢占显存，有时会导致 CUDA 报 out of memory。我一般会在训练时把 Windows 主题效果关掉，另外把浏览器硬件加速关掉，能多腾出将近 1G 显存。
关于资源管理，还有个小技巧是使用 Windows 任务管理器观察 GPU 利用率和显存。如果你发现 Win 侧某个进程占用 GPU 很高，可以在任务管理器里结束它，但别把桌面窗口管理器（DWM）关掉，否则整个界面会卡死。这个坑我踩过，教训深刻。
到最后说一下我的整体感受。WSL2 + GPU 直通这套方案，如今已经成为我在 Windows 上做 AI 开发的基本盘。它最让我满意的不是所谓的“性能无限接近原生”，而是我把 Windows 的日常软件生态和 Linux 的开发环境融合在了一起：Windows 里开浏览器、上网查资料，Linux 里跑训练、调模型，中间用 \wsl$ 互传文件，基本无感切换。
如果让我给刚上手的人一个最实在的建议：先把驱动更新到最新，再装 WSL，然后立刻把发行版迁到非系统盘，后面所有坑都少一半。别在 WSL2 里折腾 Linux 版驱动，也别把数据集放在 /mnt/c 下跑训练，这两条“血泪经验”能让你少走一个礼拜的弯路。环境搭好之后，剩下的就是顺着文档装框架、写代码、跑实验，什么时候觉得 Windows 系统资源不够了，再回来调一调 .wslconfig 就完事了。
