Windows下WSL2 GPU直通CUDA PyTorch部署全指南

搞了几台 Windows 机器做本地 AI 开发，绕来绕去最后还是回到 WSL2 这个方案上。它不是虚拟机，却又是一个完整的 Linux 内核；它跑在 Windows 里面，却可以直接调用 NVIDIA 显卡做深度学习训练。这篇文章把我实际部署 WSL2 + GPU 直通 + CUDA + PyTorch 的完整过程、踩过的坑、以及每一步背后的原理全部写清楚，给正准备在 Windows 上搞 AI 开发的朋友一份可以直接照着抄的作业。

1. 为什么 Windows 上搞 AI 开发，首选 WSL2

1.1 WSL2 和传统虚拟机、双系统到底差在哪

很多初学者搞不清楚 WSL2、虚拟机、双系统这三者的区别。先说结论：双系统性能最好但切换麻烦，虚拟机隔离最彻底但性能损耗大，而 WSL2 正好卡在中间——它用了一个真实的 Linux 内核，却通过轻量级虚拟机技术跑在 Windows 里。

WSL2 的本质是一个运行在 Hyper-V 虚拟机平台上的轻量级实用工具。它不再是 WSL1 那种 API 翻译层（把 Linux 系统调用翻译成 Windows 系统调用），而是直接跑了一个完整的 Linux 内核。这意味着你在 WSL2 里用 Ubuntu 也好、Debian 也好，行为几乎和原生 Linux 一模一样。对 AI 开发来说这是关键中的关键，因为很多深度学习框架、CUDA 工具链、底层依赖库，都是为原生 Linux 环境设计和测试的。

我把三种方案放在一起对比过，差异非常明显。

对比维度	WSL2	传统虚拟机（VMware/VirtualBox）	双系统
Linux 内核	完整内核，微软维护	完整内核，由虚拟机软件模拟硬件	完整内核，直接运行
GPU 调用	直通，性能损失极小	需要显卡虚拟化，配置复杂且性能损失大	原生直通，性能最好
文件访问	跨系统互访方便	需要共享文件夹配置	需要额外挂载分区
启动速度	秒级	分钟级	重启切换
Windows 与 Linux 共存	同时运行	同时运行	只能二选一
适合场景	开发、训练、测试	需要完整虚拟化的生产环境	追求极致性能的重度计算

对 AI 开发来说，WSL2 最大的优势就是“同时运行”这四个字。我可以在 Windows 里开着浏览器查资料、用微信沟通，同时 WSL2 里跑着一个训练任务，两边互不干扰。如果换双系统，训练一跑就是几个小时，这段时间 Windows 就完全没法用了。

1.2 GPU 直通到底是怎么一回事

标题里提到的“GPU 直通”，技术上准确的叫法是 GPU-PV（GPU 半虚拟化）。WSL2 通过一个名为 dxgkrnl 的内核驱动，把 Windows 的 GPU 能力直接暴露给 Linux 子系统。从 Linux 那边看，它就是一个标准的 NVIDIA 显卡；从 Windows 这边看，它和 Windows 里运行的其他 CUDA 应用共享同一块 GPU。

这里有个容易误解的点：WSL2 里的 CUDA 并不是通过传统意义上的 NVIDIA 驱动直通实现的。你在 WSL2 里安装的 CUDA Toolkit 只是一个包含了编译器、库文件、运行时组件的工具包，而真正和硬件打交道的 GPU 驱动，用的是 Windows 侧安装的 NVIDIA 驱动。WSL2 里的程序发起 CUDA 调用后，请求通过网络栈和内存共享机制传给 Windows 侧的驱动，再由它调度 GPU。

这种架构带来一个实际好处：你只需要在 Windows 里装一个支持 WSL2 的 NVIDIA 驱动，Linux 侧不需要单独折腾显卡驱动。这一点放在实操上就是省掉了一大堆麻烦。

1.3 哪些场景适合用 WSL2，哪些别硬撑

说句实在话，WSL2 不是万能的。我在实际使用中总结出这样几条经验：

适合的场景包括：模型训练和推理（PyTorch、TensorFlow）、数据预处理、Linux 命令行工具的日常使用、Docker 容器（WSL2 后端）、嵌入式交叉编译、跑一些只能在 Linux 下运行的科研代码。

不适合的场景包括：需要直接操作 USB 设备的场景（WSL2 对 USB 支持比较绕，虽然可以通过 usbipd 工具实现，但体验一般）、对实时性要求极高的音频/工业控制、依赖特定 Linux 内核模块的深度定制开发、大型 GUI 应用（虽然 WSLg 能跑图形界面，但性能有限）。

我这里重点说一个坑：如果你做的是嵌入式 Linux 开发，需要烧录设备固件、用 OpenOCD 调试板子、或者直接访问串口，WSL2 默认是不支持这些的。你可以用 usbipd 把 Windows 的 USB 设备共享给 WSL2，但操作起来没有想象中顺滑，而且每次重启都要重新绑定。

2. 部署前准备：版本检查、BIOS 设置和磁盘规划

2.1 确认你的 Windows 版本支持 WSL2

WSL2 对 Windows 版本有明确要求。根据微软官方文档，Windows 10 需要 2004 及以上版本（Build 19041 或更高），Windows 11 所有版本都支持。我的建议是直接升级到 Windows 11，原因不是系统本身，而是 WSL2 在 Windows 11 上的迭代更新更快，很多新特性（比如 WSL 配置文件的更多选项、更好的内存管理）都优先给了 Windows 11。

检查方法很简单。按Win + R，输入winver，查看版本号和 Build 号。如果 Build 号低于 19041，建议先更新系统。

另一个需要确认的是 CPU 虚拟化是否开启。WSL2 依赖 Hyper-V 虚拟机平台，也就是 Windows 的虚拟化功能，这个功能要求 CPU 支持并开启虚拟化技术（Intel VT-x 或 AMD-V）。你可以在任务管理器的“性能”选项卡里看 CPU 部分，如果“虚拟化”显示“已启用”就没问题。如果显示“已禁用”，需要重启进 BIOS 开启。不同品牌的 BIOS 入口不一样，一般是在 Advanced 或 Configuration 菜单下找 Intel Virtualization Technology 或 SVM Mode，设置成 Enabled 后保存退出。

这里要特别提醒一下：这里有个前置条件是 Windows 的虚拟化平台功能必须启用，否则就算 CPU 支持也白搭。如果你运行wsl --install -d ubuntu-24.04时报错提示“WSL2 无法启动，因为此计算机上未启用虚拟化”，首先检查的就是这个功能有没有开。

2.2 磁盘空间和文件系统选择的冷思考

AI 开发环境的磁盘开销比想象中大得多。一个干净的 Ubuntu 基础系统大概占 1.5GB，加上 Python 环境、PyTorch、CUDA 工具链，轻松突破 10GB。如果还要下载几个 Hugging Face 的预训练模型（比如 LLaMA、Qwen 的权重文件），单个模型就可能是 3GB 到 14GB。不考虑模型文件的话，我建议至少预留 30GB 给 WSL2 的虚拟磁盘。

WSL2 默认把所有发行版的数据放在一个 VHDX 虚拟磁盘文件里。这个文件在C:\Users\你的用户名\AppData\Local\Packages\下面，按发行版名称分散存储。如果你的 C 盘空间不足，可以把发行版迁移到 D 盘或其他数据盘。具体操作我放在后面实操章节写，这里先记住一个概念：WSL2 的“系统盘”不等于 Windows 的系统盘，它只是一个虚拟磁盘文件。

还有一点要清楚：WSL2 的虚拟磁盘文件是会随着使用不断增大的，但删除文件后它不会自动缩小。你下载了一个 5GB 模型然后删掉，VHDX 文件还是有那么大。需要手动执行wsl --manage <发行版名> --set-sparse true让磁盘文件变为稀疏文件（只占用实际使用空间），或者干脆用wsl --shutdown后通过磁盘管理来压缩 VHDX。

2.3 你需要准备的软件清单

在开始动手之前，我先把需要用到的东西列个清单，避免后面装到一半发现少了东西。

• Windows 10 2004+ 或 Windows 11
• NVIDIA 显卡（GTX 10 系列以上，驱动版本 470.76 或更高，越新越好）
• Windows 侧最新的 NVIDIA 驱动（支持 WSL2 的版本，官网可查）
• Ubuntu 22.04 或 24.04 镜像（通过wsl --install自动下载）
• 终端工具：Windows Terminal（强烈推荐，支持多标签页和 WSL 集成）
• 网络环境：能访问微软商店和 Ubuntu 软件源，如果下载慢可以换国内镜像源

这里单独说一下“下载慢”的问题。很多用户抱怨wsl --install -d ubuntu-24.04卡在下载阶段，半天不动。原因很简单：发行版镜像文件托管在微软的服务器上，国内访问本身就不快，高峰期更是蜗牛速度。解决办法有两个：一个是配置系统代理（如果有条件的话），另一个是手动下载 Appx 离线包后安装。离线安装的方法我在常见问题章节详细讲。

3. 实操部署：从零开始搭建 WSL2 + Ubuntu

3.1 启用必要的 Windows 功能

第一步是启用 WSL 和虚拟机平台这两个 Windows 功能。打开“控制面板 → 程序 → 启用或关闭 Windows 功能”，勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，确定后重启系统。

更快的办法是直接用管理员权限打开 PowerShell，执行以下命令：

# 启用 WSL2 所需的 Windows 功能 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完毕后重启电脑。这一步非常重要，很多人的 WSL2 装不上就是这个功能没有正确启用。

重启后打开 PowerShell（管理员模式），执行：

# 设置 WSL2 为默认版本 wsl --set-default-version 2

如果这里报错提示需要更新内核组件，去微软官网的 WSL2 Linux 内核更新包页面下载安装对应版本的更新包，之后重新执行一次就行。

3.2 安装 Ubuntu 22.04 发行版

接下来安装发行版。我推荐直接用命令安装，不需要打开微软商店。在 PowerShell 里执行：

# 列出所有可安装的发行版 wsl --list --online # 直接安装 Ubuntu 22.04 wsl --install -d Ubuntu-22.04

如果你想装最新版，可以用wsl --install -d Ubuntu-24.04。安装完成后，系统会提示创建一个 Linux 用户名和密码。这个用户名和 Windows 用户名没有关系，是 Linux 系统内部独立的用户。

关于发行版的选择，这里我给一个建议：新手建议选 Ubuntu 22.04 LTS 或 24.04 LTS。LTS 版本有长期支持，软件源稳定，遇到问题在网上搜索时资料也最多。之前试过 Kali Linux，默认没有启用 WSL 集成和 systemd，要改一些配置才能跑常见开发工具，比较折腾，不适合做 AI 开发环境。

装完后执行wsl --set-version Ubuntu-22.04 2确保用的是 WSL2 版本。同时可以验证一下当前发行版的运行模式：

# 在 WSL 终端里执行，确认运行在 WSL2 uname -r

看到内核版本号里有microsoft-standard-WSL2字样就对了。如果显示的是 WSL1 的内核，说明版本切换没成功，需要检查 Windows 功能是否完整启用。

3.3 把 WSL2 发行版迁移到 D 盘

这一步是针对 C 盘空间紧张的用户。WSL2 的虚拟磁盘默认放在 C 盘用户目录下，如果 C 盘剩余空间不多，强烈建议迁移。官方没有提供一键迁移命令，需要手动导出再导入。

先关闭 WSL2，然后导出发行版为一个 tar 文件：

# 关闭所有正在运行的 WSL 实例 wsl --shutdown # 导出当前 Ubuntu-22.04 发行版到 D 盘临时文件（这一步会看到一个进度条） wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar # 注销原发行版（注意：这会删除 C 盘上的原始虚拟磁盘） wsl --unregister Ubuntu-22.04 # 将 tar 文件导入到 D 盘的新位置 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar # 设置默认用户为你的 Linux 用户名（导入后默认是 root，需要切换回来） ubuntu2204.exe config --default-user 你的用户名

迁移完成后可以删除 D 盘的 tar 备份文件，节省空间。这里有一个需要留意的点：用wsl --import导入的发行版默认以 root 用户登录，需要通过ubuntu2204.exe config --default-user把默认用户改回去，否则后续所有操作都要在 root 下进行。

3.4 配置基础开发环境

进入 WSL2 后，第一件事是更新软件源和系统。如果你发现默认源下载速度慢，换成国内镜像能快不少。操作方式：

# 备份原始源文件 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 编辑源文件，把 archive.ubuntu.com 和 security.ubuntu.com 替换为国内镜像 sudo sed -i 's|archive.ubuntu.com|mirrors.aliyun.com|g' /etc/apt/sources.list sudo sed -i 's|security.ubuntu.com|mirrors.aliyun.com|g' /etc/apt/sources.list # 更新索引 sudo apt update sudo apt upgrade -y

对于 Ubuntu 24.04，源配置已经从/etc/apt/sources.list文件迁移到了/etc/apt/sources.list.d/ubuntu.sources，操作逻辑一样，替换文件里的服务器地址就行。

接下来安装基础工具链：

# 常用工具 sudo apt install -y build-essential git curl wget unzip zip vim htop # Python 开发工具（避免直接用系统的 Python 3.12，建议装 pyenv 或 conda 来管理版本） sudo apt install -y python3-pip python3-venv

3.5 配置 WSL2 系统资源限制

WSL2 默认会占用系统内存的一半（在 Windows 11 上默认是 50%，Windows 10 早期版本甚至可能更多）。如果你的机器有 32GB 内存，WSL2 可能直接吃满 16GB，Windows 这边就会变得比较紧张。可以通过.wslconfig文件来限制资源占用。

在 Windows 的用户目录下（C:\Users\你的用户名\）新建一个.wslconfig文件，内容参考：

[wsl2] memory=12GB processors=4 swap=2GB localhostForwarding=true

• memory：分配给 WSL2 的内存上限
• processors：分配的 CPU 核心数
• localhostForwarding：让 Windows 能通过 localhost 访问 WSL2 里启动的服务

修改完配置后，需要执行wsl --shutdown再重新进入 WSL2 才能生效。

4. GPU 直通配置：NVIDIA 驱动和 CUDA 的完整打通

4.1 Windows 侧驱动是核心中的核心

前面反复强调过，WSL2 里面不需要单独装 NVIDIA 显卡驱动，真正起作用的是 Windows 侧的驱动。但这里有一个版本要求：必须是支持 WSL2 的 NVIDIA 驱动，也就是 CUDA on WSL 版本。如果你装的是很老的驱动，或者笔记本厂商发布的精简驱动，可能不支持 WSL2 的 GPU 直通。

最简单的方法是去 NVIDIA 官网下载最新驱动。安装的时候选择“自定义安装”，勾选“执行清洁安装”，避免旧的驱动残留导致问题。

装完驱动后，在 Windows 的 PowerShell 里执行以下命令验证 GPU 是否对 WSL2 可见：

# 查看 WSL2 是否能识别到 NVIDIA GPU wsl nvidia-smi

如果你在 WSL2 终端里执行nvidia-smi，应该能看到显卡型号、驱动版本和 CUDA 版本。如果你看到“No devices were found”或类似错误，说明驱动不对或者没生效。

4.2 WSL2 里的 CUDA 安装：不装驱动，只装工具包

在 WSL2 里装 CUDA 和原生 Linux 的做法几乎一致，唯一区别就是不需要装 GPU 驱动。CUDA Toolkit 可以从 NVIDIA 官网下载。这里我推荐用下面这种安装方式：

# 进入 WSL2，下载并安装 CUDA WSL-Ubuntu 版本的 .deb 包 wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.0-1_all.deb sudo dpkg -i cuda-keyring_1.0-1_all.deb sudo apt update sudo apt install -y cuda

安装完成后，需要配置环境变量。编辑~/.bashrc，加入：

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

然后执行source ~/.bashrc生效。

验证 CUDA 是否安装成功：

nvcc --version

这一步能看到 CUDA 编译器的版本。同时再执行一次nvidia-smi，确认 GPU 驱动状态正常。

我个人不再建议为了某个框架的兼容性去刻意装特定版本的 CUDA。PyTorch 和 TensorFlow 都自带 CUDA 运行时，他们需要的 CUDA 版本可以独立安装，不必和系统级的 CUDA Toolkit 一致。你只需要保证 NVIDIA 驱动足够新，框架就能从网上拉取对应的 CUDA 依赖。

4.3 验证 GPU 直通真的生效了

硬件和驱动的验证都通过后，用一个简单的 PyTorch 脚本来测试 GPU 的完整计算链路。这一步非常关键，它能一次性验证 CUDA 驱动、cuDNN、PyTorch GPU 版本是否全部正常。

先创建一个虚拟环境：

python3 -m venv ~/ai-env source ~/ai-env/bin/activate pip install torch torchvision

然后运行：

import torch print("PyTorch 版本:", torch.__version__) print("CUDA 是否可用:", torch.cuda.is_available()) print("GPU 型号:", torch.cuda.get_device_name(0)) print("显存容量:", torch.cuda.get_device_properties(0).total_memory / 1024**3, "GB") # 跑一个小矩阵乘法，验证 GPU 计算真的在工作 x = torch.randn(1024, 1024, device="cuda") y = torch.randn(1024, 1024, device="cuda") z = x @ y print("GPU 矩阵乘法结果 shape:", z.shape)

如果你看到CUDA 是否可用: True，并且能打印出显卡型号，那就恭喜你，这条 GPU 计算链路已经打通了。

4.4 WSL2 里跑 AI 任务的性能到底打几折

很多人关心 WSL2 的 GPU 性能相比原生 Linux 损失多少。根据我自己的实测和社区里的公开测试数据，对于计算密集型的张量操作（矩阵乘法、卷积），WSL2 的性能损失大约在 2% 到 5% 之间。对于分布式训练比较常见的数据传输密集型任务，损失会稍微高一些，毕竟多了一层虚拟化转发。

这个损失对绝大多数开发场景来说完全可以接受。我在 WSL2 里跑 LLaMA 的 7B 模型微调，对比双系统的表现，训练速度几乎没有可感知的差别。你真正需要担心的不是 GPU 性能损耗，而是内存带宽和显存容量的上限。

WSL2 的显存访问是通过 GPU 直通实现的，能直接使用整张显卡的显存。你在 Windows 上看到显卡有多少显存，在 WSL2 里就能用到多少。但内存就不一样了，WSL2 默认只分配物理内存的一半，需要通过.wslconfig调大。

5. 把 AI 开发环境补齐：框架、工具和模型实测

5.1 配置 PyTorch 和 TensorFlow 的 GPU 版

PyTorch 的 GPU 版本安装非常简单，在虚拟环境里执行官方推荐的命令即可。国内用户如果带宽紧张，可以用清华的 PyPI 镜像加速：

source ~/ai-env/bin/activate pip install torch torchvision torchaudio -i https://pypi.tuna.tsinghua.edu.cn/simple

TensorFlow 的话，新版已经能自动检测 CUDA 和 cuDNN，不需要手动设置环境变量。但在 WSL2 上装 TensorFlow，有一个容易忽略的细节：确保LD_LIBRARY_PATH里包含 CUDA 的 lib64 目录，否则 tensorflow 可能回报“Could not load dynamic library 'libcudnn.so.8'”。

5.2 搭建 Jupyter Lab 和 VS Code 的 WSL 远程开发

日常开发如果只靠终端里的 Vim 会很难受，我推荐这种做法：在 WSL2 里装 Jupyter Lab，然后 Windows 浏览器直接访问；代码编辑用 VS Code 的“Remote - WSL”插件，直连 WSL2 的开发环境。

Jupyter Lab 装法：

pip install jupyterlab jupyter lab --ip=0.0.0.0 --port=8888 --no-browser

然后在 Windows 浏览器输入http://localhost:8888就能访问。这得益于 WSL2 的localhostForwarding=true配置，Windows 和 WSL2 的 localhost 是互通的。

VS Code 这边，在 Windows 上安装“Remote - WSL”扩展，然后点击左下角绿色的远程连接按钮，选择“Connect to WSL”，VS Code 会自动在 WSL2 侧安装服务器端，然后你就可以在 Windows 的 VS Code 界面里编辑 WSL2 里的文件、使用 WSL2 里的 Python 解释器、调用 WSL2 里的 GPU。这套搭配是我目前用下来最舒服的开发姿势。

5.3 实战检验：跑一个中文大模型

环境搭好之后，我强烈建议跑一个真实的中文大模型来验证整条链路。这里用 Hugging Face 生态，先装依赖：

pip install transformers accelerate

然后用 Qwen2.5-1.5B-Instruct 模型做一个生成测试：

from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "Qwen/Qwen2.5-1.5B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained(model_name, device_map="cuda") prompt = "用一句话解释什么是深度学习" messages = [{"role": "user", "content": prompt}] text = tokenizer.apply_chat_template(messages, tokenize=False) inputs = tokenizer(text, return_tensors="pt").to("cuda") outputs = model.generate(**inputs, max_new_tokens=100) print(tokenizer.decode(outputs[0]))

如果你的环境是首次运行，会自动下载约 3GB 的模型文件，耐心等待即可。GPU 上的推理速度非常快，1.5B 参数模型在 8GB 显存的显卡上，每秒能生成几十个 token。

这一步跑通了，说明从 Windows 驱动到 WSL2 内核，再到 CUDA 工具链和深度学习框架，整条链路完全没有问题。之后不管你是做微调、推理还是数据处理，都可以在这个环境上继续扩展。

6. 高发问题排查：我把踩过的坑都写在这里

6.1 “WSL2 尚未准备就绪”怎么处理

这是出现频率最高的报错之一。出现WSL2 尚未准备就绪通常意味着你运行了某个基于 WSL2 的发行版，但系统里的 WSL2 组件没配置好。排查步骤：

# 在 PowerShell 里检查 WSL 状态 wsl --status

如果显示“默认版本：2”，但启动发行版时仍然报错，执行以下操作：

# 重启 WSL 服务 wsl --shutdown net stop LxssManager net start LxssManager

如果问题依旧，建议直接更新 Windows 系统。这个问题在很多旧版本 Windows 10 上出现过，微软在后续累积更新中修复了相关问题。

6.2 运行wsl --install报错“此计算机上未启用虚拟化”

这个报错的根源有几种可能：CPU 不支持虚拟化、BIOS 里关闭了虚拟化、或者 Windows 的虚拟机平台功能没启用。按以下顺序排查：

第一步，用管理员权限运行 PowerShell，执行systeminfo，拉到最后看“Hyper-V 要求”一栏，如果“固件中已启用虚拟化”显示“否”，那问题就在 BIOS。

第二步，重启进 BIOS，找到虚拟化相关的选项（Intel 平台找 VT-x/虚拟化技术，AMD 平台找 SVM Mode），设置为 Enabled。不同主板厂商的 BIOS 菜单布局差异很大，找不到选项的话建议直接搜“主板型号+BIOS 开启虚拟化”。

第三步，确认 BIOS 开启虚拟化后，再检查 Windows 功能里“虚拟机平台”是否已启用。

6.3 下载发行版镜像速度慢或卡住

wsl --install -d Ubuntu-22.04卡在下载阶段是常见问题，尤其是网络高峰时段。处理方法：

如果卡在百分之几不动，直接按Ctrl+C终止，重新执行安装命令。WSL 下载支持断点续传，重试有效。

如果反复卡住，换离线安装方式。去微软商店的 Ubuntu 发行版页面，找到下载链接拿 Appx 包。但这里要小心商店页面会根据浏览器 UA 返回不同的下载链接，直接复制“下载”按钮的链接不一定能拿对。

比较稳妥的离线安装步骤：

# 1. 从微软商店页面的下载渠道获取 .appx 包 # 2. 用管理员 PowerShell 执行以下命令安装 Add-AppxPackage D:\下载\Ubuntu2204.appx # 3. 安装完成后启动发行版，首次启动会让你创建用户名密码

离线安装还有一个需要注意的点：如果启动发行版时提示“当前计算机 BIOS 设置未启用虚拟化”，先去检查 BIOS；如果提示“WSL 内核版本过低”，去装最新的 WSL2 Linux 内核更新包。

6.4wsl --import导入后默认用户变成 root

前面迁移章节提到过，导入后的发行版默认以 root 用户登录。解决办法已经写过，用发行版专用的 exe 文件设置默认用户：

# Ubuntu-22.04 对应的 exe 文件 ubuntu2204.exe config --default-user 你的用户名

不同发行版对应的 exe 文件名不同：Ubuntu-22.04 对应ubuntu2204.exe，Ubuntu-24.04 对应ubuntu2404.exe，Debian 对应debian.exe，Kali 对应kali.exe。

6.5 GPU 直通失效：nvidia-smi不显示 GPU

这种问题我遇到过几次，常见原因基本是 Windows 驱动更新后 WSL2 的 GPU 会话失效。最有效的处理方式：

# 彻底重启 WSL2 wsl --shutdown

然后重新进入 WSL2，执行nvidia-smi。如果还不行，检查 Windows 侧的 NVIDIA 驱动版本。在 WSL2 里执行nvidia-smi时会显示驱动版本，如果版本低于 470.76，说明驱动太老不支持 WSL2。

另外要注意一种特殊情况：笔记本双显卡（核显+独显）的机器，WSL2 不一定默认使用独显。虽然 Windows 的图形调度器会把 CUDA 任务分配给性能更好的独显，但如果驱动设置有问题，可能出现 CUDA 不可用。遇到这种情况，在 Windows 的“设置 → 系统 → 屏幕 → 显示卡”里，把 WSL2 相关的程序指定为高性能独显。

6.6 常见问题速查表

我把高频问题整理成一张表格，方便对照排查。

报错或现象	直接原因	解决动作
找不到 WSL 可执行文件	系统未启用 WSL 功能	用 DISM 命令启用 Microsoft-Windows-Subsystem-Linux
“此计算机上未启用虚拟化”	BIOS 关闭 VT-x/SVM 或未启用虚拟机平台	进 BIOS 打开虚拟化，启用 Windows 虚拟机平台
wsl --install下载卡住	网络原因，微软服务器下载慢	重试；下载 Appx 离线安装
WSL2 尚未准备就绪	WSL 服务异常或内核组件未更新	wsl --shutdown重启服务；安装最新内核更新包
导入后默认 root 用户	wsl --import不带默认用户	用发行版名.exe config --default-user 用户名修改
WSL2 没 GPU	驱动太老或不支持 WSL2	更新 Windows 侧 NVIDIA 驱动到 470.76+
GPU 内存不够	模型太大放不进显存	用 CPU 推理模式，或减小 batch size，或量化模型
WSL2 内存占用过高	默认占用 50% 物理内存	创建.wslconfig限制 memory
Windows 无法访问 WSL 服务	localhostForwarding 配置异常	检查.wslconfig文件，去掉或修改 localhostForwarding 配置

7. 最后的经验之谈

WSL2 这套方案我用了快两年，从最初的 Windows 10 一直用到 Windows 11，踩过的坑比这篇文章里写的还要多。我个人最大的体会是：WSL2 最大的价值不是让你免费用一个 Linux 系统，而是让 Windows 和 Linux 的边界变得透明。我可以一边在 Windows 上处理文档和邮件，一边在 WSL2 里跑深度学习训练，这种体验是双系统和传统虚拟机都无法提供的。

最后分享两个我日常开发中的小技巧。第一个，把 WSL2 的终端固定为 Windows Terminal 的默认终端，启动时自动进入 WSL2，配合 Oh My Zsh 和 zsh-autosuggestions 插件，命令输入的效率提升非常明显。第二个，给 WSL2 设置别名，在 Windows 的 PowerShell 配置文件里加上wsl2 = wsl -d Ubuntu-22.04，以后输入wsl2就能直接进入工作环境，不用每次输入完整命令。

这套环境搭好之后，后续的扩展空间很大。你可以继续配置 Docker Desktop 的 WSL2 后端，在 WSL2 里跑容器化的训练任务；也可以把 Hugging Face 的模型缓存目录迁移到 Windows 侧的磁盘，统一管理模型文件。我在实际使用中发现，模型缓存放在 Windows 盘符下（通过 /mnt/c 访问）虽然读取速度比 WSL 内部文件系统慢一些，但不会额外占用 WSL2 虚拟磁盘的空间，适合存放那些不经常读取的大文件。根据自己的项目需求去调整就好，没有一套配置是万能的。