WSL2搭建AI开发环境：GPU直通CUDA配置与PyTorch训练实战

1. 为什么我把 AI 开发主力环境从双系统搬到了 WSL2

先说结论：如果你在 Windows 主力机上做深度学习或大模型相关开发，又不想每次训练都要重启进 Ubuntu，那么 WSL2 是目前最值得尝试的中间态方案。

先交代背景。我主要做 CV 方向的模型训练和推理部署，经常要在 GPU 上跑 PyTorch、TensorFlow，偶尔也要调 CUDA 加速的自定义算子。以前的工作模式是双系统：Windows 负责日常办公、看论文、写文档，Ubuntu 专门用来跑训练任务。这个模式最大的痛点不是性能，是切换成本——每次切系统少则一分钟多则两分钟，关键思路经常被重启打断。后来也试过 VMware 和 VirtualBox，GPU 利用率总是不尽如人意，显存分配、CUDA 版本都是老大难问题。

真正让我下定决心换方案的是 2024 年之后 WSL2 的 GPU 直通能力成熟了。现在的 WSL2 跑的是标准 Linux 内核，不是 WSL1 那种 API 翻译层，所以在里面装 CUDA 工具链、跑 GPU 推理任务，行为和裸机 Ubuntu 几乎一致。而 Windows 侧只需要维护一份带 CUDA 能力的驱动，省掉了双系统两套驱动、两套工具链、两套环境的维护成本。

这篇文章定位很明确:给想用 WSL2 搭 AI 开发环境的人，写一份能直接照着操作、能提前避开我踩过的坑的实战记录。内容包括如何判断你的机器适不适配、从零安装 Ubuntu 发行版、配置 CUDA 直通、迁移系统盘、以及实际运行 PyTorch 训练任务时的性能表现和问题排查。如果你手头机器是 N 卡，又没有 A100/H100 那样的服务器资源，这篇文章应该能让你省下至少一个下午的摸索时间。

先说一个最容易劝退新手的点：很多人以为 WSL2 是虚拟机，其实是半虚拟化。WSL2 基于 Hyper-V 的轻量级架构，但和传统虚拟机最大的区别是它不需要完整的设备模拟，而是直接用虚拟化平台把 Linux 内核跑在 Hyper-V 根分区之上，同时通过 Windows 的显卡驱动模型（GPU-PV 机制）让 Linux 侧的应用直接调用物理 GPU。这就是所谓"内核级 Linux + GPU 直通"的底层原理。你不需要在 WSL 里装显卡驱动，Windows 的 NVIDIA 驱动会被直接透传进去。

2. WSL2 安装全记录：从 Windows 功能开关到 Ubuntu 24.04

2.1 先确认你的硬件和 Windows 版本

很多人装 WSL2 失败，往下走到一半才发现是前置条件不满足。WSL2 的基础条件其实就三条：

1. Windows 10 版本 2004 以上（内部版本 19041 及以上），或者 Windows 11。Win10 部分旧版本也可以用，但体验和兼容性不如 Win11，我自己是在 Win11 23H2 上跑的。
2. CPU 支持虚拟化，且 BIOS/UEFI 中已打开 VT-x（Intel）或 SVM（AMD）。
3. 内存至少 8GB，建议 16GB 以上。GPU 训练任务比较吃内存，WSL2 默认分配 50% 的物理内存，后面我会讲怎么调整。

先打开任务管理器，在"性能"标签里看 CPU 是否显示"虚拟化：已启用"。如果显示未启用，去 BIOS 里找 Advanced -> CPU Configuration 或类似路径打开 VT-x/SVM。这一步不能跳过，因为 WSL2 本质上是个轻量级虚拟机，没有虚拟化指令集就完全跑不起来。

2.2 两条安装路线：一键安装和手动装配

Windows 11 和较新的 Win10 版本支持最省事的一键安装，在管理员 PowerShell 里执行一条命令：

wsl --install -d ubuntu-24.04

这条命令会自动开启需要的 Windows 功能（VirtualMachinePlatform、Microsoft-Windows-Subsystem-Linux），下载 WSL2 内核，从 Microsoft Store 拉取指定的 Ubuntu 发行版，然后自动启动。

一键安装的问题是它依赖网络状态，在国内网络环境下经常卡在"正在下载"这一步。如果多次重试还是卡住，我建议使用手动装配方式：

# 1. 以管理员身份打开 PowerShell，启用两个关键功能 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 2. 重启电脑 # 3. 设置默认 WSL 版本为 2 wsl --set-default-version 2

重启后去微软官网搜索"wsl2 Linux 内核更新包"，下载对应系统的 MSI 安装包，按提示安装。这个更新包是 WSL2 运行的核心，如果不想用上面 dism 命令手动开功能，也可以把 MSI 安装包拉下来离线装好。

最后再手动获取 Ubuntu 发行版。从 Microsoft Store 搜索 Ubuntu 24.04.xx LTS，点击安装。装完打开应用会自动初始化，设置用户名和密码即可。

2.3 一键安装时"wsl --install -d ubuntu-24.04"报错的排查思路

如果你用了 wsl --install -d ubuntu-24.04 却报出类似"WslRegisterDistribution failed with error: 0x80370102"或"Error code: WSL_E_INSTALL_POSIX_COMPONENT_MISSING"的报错，不要慌，九成是 Windows 功能没有完全生效。

最常见的原因和对应操作：

• 虚拟化未启用。回到 2.1 检查 BIOS 设置。
• VirtualMachinePlatform 启用后没有重启。很多人执行了 dism 命令就直接装发行版，实际上必须重启一次让功能生效。
• WSL2 内核更新包未安装。这个包是独立的，不随 Store 发行版一起装，漏了就启动不了。
• 之前装过 WSL1 的旧版本残留。可以用wsl --shutdown再重试，必要时先wsl --unregister <发行版名>清掉旧的注册信息。

另外注意：不要同时用 VMware/VirtualBox 的虚拟机监控程序，它们会和 Hyper-V 冲突，导致 WSL2 无法启动。如果电脑上装了安卓模拟器之类依赖虚拟化的软件，也建议在装 WSL2 期间先退掉它们。

2.4 下载速度慢到崩溃？换源和离线包解决

微软 Store 在国内安装 Ubuntu 的体验很不稳定，经常出现进度条不动、几十 KB/s 的下载速度，"wsl2下载慢"这个热搜词印证了这不是个例。我的应对策略是这样的：

如果一键安装卡在"正在下载"超过十分钟，先取消，改走 2.2 节的手动装配路线。发行版本体可以不走 Store，直接到微软官网的 WSL 发行版列表页面找 Ubuntu 的 .appx 或 .msixbundle 安装包下载。这个包一般几百 MB，用浏览器多线程下反而比 Store 快。下载后管理员 PowerShell 里执行：

Add-AppxPackage -Path "路径\Ubuntu_2404.0.0_x64.appx"

装好后在开始菜单打开 Ubuntu 即可初始化。还有一种思路是拿到别人已经装好的 WSL 发行版 tar 包，直接离线导入，这个我放到第 5 章迁移部分一起讲。

3. GPU 直通不是玄学：CUDA 在 WSL2 里的真实配置路径

3.1 WSL2 的 GPU 虚拟化机制

很多人一听到"WSL2 GPU 直通"就觉得是把显卡直接塞给 Linux 虚拟机，这个理解不准确。WSL2 用的是微软的 GPU-Paravirtualization（GPU-PV）技术，原理可以理解为：Windows 拥有物理 GPU 的绝对控制权，Linux 内核通过虚拟化层请求 GPU 资源，Windows 侧再由 NVIDIA 驱动把请求真正交给物理显卡。所以你在 WSL2 里跑 CUDA 程序，本质上是 Windows 驱动替你执行了 GPU 操作，而不是 Linux 侧自己装了显卡驱动。

这带来两个直接结论：

1. Linux 侧不需要安装 NVIDIA 显卡驱动，只需要一个能识别 GPU 的 CUDA Toolkit。
2. Windows 侧必须安装支持 WSL2 CUDA 的 NVIDIA 驱动，版本必须较新。驱动面板里能看到"适用于 WSL 的 CUDA"字样才说明驱动本身支持。

官方文档里通常叫这条路径 "CUDA on WSL"。和裸机 Ubuntu 环境相比，它的好处是驱动升级特别方便——直接在 Windows 侧升级驱动，Linux 里不用动任何东西，CUDA 版本跟随驱动版本变化，这在双系统时代是不可想象的。

3.2 检查 Windows 驱动和 CUDA 版本匹配

在 Windows 侧打开命令行，执行nvidia-smi，输出里会显示驱动版本和 CUDA 支持版本。注意看两处：

• Driver Version：必须是 525.85.05 或更高，这个版本是 NVIDIA 正式加入 WSL CUDA 支持的里程碑版本。现在新驱动普遍是 550+，基本没问题。
• CUDA Version：这是驱动能支持的最高 CUDA 版本。比如驱动显示 CUDA 12.4，那么你 WSL2 里的 CUDA Toolkit 版本不能超过 12.4，否则会出现"driver is too old"的兼容性报错。

如果nvidia-smi在 Windows 下显示不出来，先确保驱动已装好，去 NVIDIA 官网下载最新驱动重装即可。

顺手在 WSL2 里也验证一下 GPU 是否可见，进入 Ubuntu 终端执行：

nvidia-smi

如果输出里能看到显卡型号和驱动版本，说明 GPU 直通链路已经通了。如果提示command not found，说明还没有安装相关工具，先继续往下走。

3.3 Linux 侧安装 CUDA Toolkit 的完整命令

进入 Ubuntu 终端，先更新系统并安装基础依赖：

sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential gcc make

WSL2 里装 CUDA Toolkit 有两种方式。一种是跑 NVIDIA 官方提供的 WSL-Ubuntu 安装脚本，这个脚本适配的发行版版本有限，Ubuntu 22.04/24.04 都能用。我更推荐直接用 CUDA Keyring 方式，因为它和裸机 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 update sudo apt install -y 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或开一个新终端。验证 CUDA 编译器是否可用：

nvcc --version

这个 nvcc 是 CPU 编译器，负责把 CUDA C/C++ 代码编译成 GPU 可执行程序。如果你只使用 PyTorch/TensorFlow 这类框架，其实不需要手动装全套 Toolkit，框架会自带 CUDA 运行库。但要做自定义算子开发，nvcc 必须存在。

3.4 实测验证 GPU 计算是否真正走显卡

装完工具链不能只看版本号，我习惯跑一个小的矩阵运算程序验证 GPU 是否真正参与计算。先写一个最简单的一维向量加法的 CUDA 程序：

#include <stdio.h> __global__ void add(int n, float *x, float *y) { int index = blockIdx.x * blockDim.x + threadIdx.x; int stride = blockDim.x * gridDim.x; for (int i = index; i < n; i += stride) { y[i] = x[i] + y[i]; } } int main(void) { int N = 1 << 20; float *x, *y; cudaMallocManaged(&x, N * sizeof(float)); cudaMallocManaged(&y, N * sizeof(float)); for (int i = 0; i < N; i++) { x[i] = 1.0f; y[i] = 2.0f; } add<<<(N+255)/256, 256>>>(N, x, y); cudaDeviceSynchronize(); float maxError = 0.0f; for (int i = 0; i < N; i++) maxError = fmax(maxError, fabs(y[i]-3.0f)); printf("Max error: %f\n", maxError); cudaFree(x); cudaFree(y); return 0; }

保存为test.cu，编译运行：

nvcc test.cu -o test ./test

输出Max error: 0.000000说明计算正确。出现任何 CUDA error 则说明链路还没通，需要回到 Windows 侧检查驱动。

3.5 PyTorch 在 WSL2 里的 GPU 训练实测

框架层面，PyTorch 的安装和裸机 Ubuntu 完全一样。先确认 Python 版本，然后按 CUDA 版本选择对应的安装命令。安装 PyTorch 官方建议使用 pip 并指定 CUDA 版本：

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

装完跑一下这个检测脚本：

import torch print("CUDA available:", torch.cuda.is_available()) print("Device count:", torch.cuda.device_count()) print("Device name:", torch.cuda.get_device_name(0))

如果输出CUDA available: True，说明 PyTorch 已经能感知到 GPU。顺带跑一个简单的全连接层训练测试，观察 loss 是否下降，确定计算图能正常前向反向传播。

我实际在 WSL2 里训练过一个 ResNet-50 的图像分类模型，batch size 128，输入分辨率 224x224，使用的是一张 RTX 4070 Ti。最终训练吞吐量和我之前双系统裸机 Ubuntu 环境相比，差异在 2% 以内。这个数字完全在可接受范围，特别是在开发调试、跑小模型的场景下，省下的系统切换时间已经远远抵消了那点性能损耗。

4. 安装过程中最容易卡住的三个坑：虚拟化、下载慢、启动失败

4.1 报错"此计算机上未启用虚拟化"的完整排查链路

这是我在网上看到遇到人次最多的问题。很多人照着教程走wsl --install -d ubuntu-24.04，却弹出一句"Error: 0x80370102 The virtual machine could not be started because a required feature is not installed"，后面跟着一句"此计算机上未启用虚拟化"。

先不要慌着去装什么修复工具。然后按照下面这个顺序排查：

1. 打开任务管理器 -> 性能标签 -> CPU，看右下角"虚拟化"一栏是否为"已启用"。
2. 如果显示未启用，进 BIOS/UEFI。不同主板入口不同，一般是开机按 DEL/F2/F10。找到 Intel Virtualization Technology 或 SVM Mode，改成 Enabled，保存重启。这一步完成后，任务管理器里应该显示已启用。
3. 如果 BIOS 里已经是 Enabled，但仍然报错，检查 Windows 功能列表里是否打开了"适用于 Linux 的 Windows 子系统"和"虚拟机平台"。命令方式就是 2.2 节那两条 dism，注意修改后必须重启。
4. 还有极少数情况是主板开启了 Core Isolation（内存完整性）或 Hyper-V 安全功能导致的，可以在 Windows 安全中心 -> 设备安全性 -> 内核隔离里暂时关掉内存完整性，然后重试。

有一个细节值得多说一句："未启用虚拟化"这个提示也可能出现在你已经打开 VT-x 的机器上，因为系统更新后 Hyper-V 的 hypervisor 没有正确加载。这时执行一次bcdedit /set hypervisorlaunchtype auto，再重启，基本能解决。

4.2 报错"WSL2 尚未准备就绪"到底是什么意思

另一个高频报错是"请启用适用于 Linux 的 Windows 子系统或虚拟机平台功能"。这个错误往往出现在打开了wsl --set-default-version 2之后直接装发行版。

这个报错的本质是：WSL2 的运行环境没有完全拼好。它需要三块拼图——内核更新包、VirtualMachinePlatform 功能、发行版本身。最常见的是第一块缺失。很多人只在 Windows 功能里勾了"虚拟机平台",但没有安装那个独立的 MSI 内核更新包。所以看到这个提示，优先去微软官网下载 wsl_update_x64.msi，安装后重启。Win11 用户也可以执行wsl --update在线更新内核。

还有一个容易忽略的地方：检查wsl --status输出的默认版本是否为 2。如果显示默认版本为 1，执行wsl --set-default-version 2。在旧版本 Windows 上，这一步失败的可能性很大，需要先把系统升级到支持 WSL2 的版本。

4.3 下载慢的几个实用替代方案

前面说过 Store 下载容易卡。这里再补充一个完全绕开网络拉取的方法：让已经装好 WSL2 的同事或者另一台机器导出发行版给你。在正常的机器上执行：

wsl --export Ubuntu-24.04 ubuntu2404.tar

拿到 tar 包后，在你机器上离线导入：

wsl --import Ubuntu-24.04 D:\WSL\Ubuntu2404 D:\下载\ubuntu2404.tar --version 2

导入后默认会以 root 进入，后续再配置普通用户和默认用户即可。这个方法不挑网络，只要有包就能装，是我在实验室里最常用的分发方式。

如果只能自己下载，同样是去微软官网找 .appx 离线包，而不要死磕 Store 的进度条。浏览器多线程下载工具对于大文件有显著提速效果，这里不多展开，实操过的人应该都有体会。还有一点，Windows 的 DNS 设置对 Store 下载有一定影响，可以试着把 DNS 改成公共 DNS 再试，这个操作不需要任何额外软件，安全快捷。

5. 把 WSL2 开发盘迁到 D 盘：给 C 盘减负的完整方案

5.1 为什么迁移是很多人的刚需

WSL2 的虚拟磁盘（ext4.vhdx 文件）默认存放在 C 盘用户目录下，路径通常长这样：

C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_*\LocalState\ext4.vhdx

装完 CUDA Toolkit、conda 环境的 Python 包再加上模型文件，这个文件轻松超过 30GB。C 盘往往是小容量固态，很快就会被挤爆。"wsl2如何安装配置到d盘"这个热搜说明这个问题非常普遍。

WSL2 从设计上不支持直接把发行版安装到 D 盘，但可以用导出 -> 导入的方式实现迁移，相当于先把整个系统打包，再到新位置恢复。注意迁移不会保留默认用户的映射，导入后需要重新设置。

5.2 迁移操作的完整命令流程

先关闭正在运行的 WSL2 实例，否则 vhdx 文件处于使用中无法导出。

wsl --shutdown

然后导出当前系统为 tar 包，建议放到有足够空间的分区。tar 包比 vhdx 要小很多，因为它不包含未使用的空间。命令如下：

wsl --export Ubuntu-24.04 D:\wsl-backup\ubuntu2404.tar

导出完成后，注销原来的发行版并删除旧文件：

wsl --unregister Ubuntu-24.04

然后从 tar 包导入到目标位置：

wsl --import Ubuntu-24.04 D:\WSL\Ubuntu2404 D:\wsl-backup\ubuntu2404.tar --version 2

导入后启动会发现默认用户是 root，触发路径是wsl -d Ubuntu-24.04。如果需要恢复普通用户，可以进入发行版后修改默认用户配置，或者更省事的办法：编辑/etc/wsl.conf，追加以下内容：

[user] default=你的用户名

然后把wsl --shutdown，重新启动，就能以普通用户身份登录。注意用 root 身份编辑完文件后要确认文件权限正确。

5.3 迁移后需要修复的两个隐藏问题

第一个隐藏问题是 Windows Terminal 和 VS Code 里的 WSL 连接配置。迁移后会发现在 Windows Terminal 的下拉列表里旧发行版名称可能变成Ubuntu-24.04而不是「Ubuntu」，这个不影响使用，但要养成用wsl -d Ubuntu-24.04指定发行版名称的习惯。

第二个隐藏问题是 conda 或 pip 安装的包的绝对路径。很多环境变量是绝对路径，比如PATH里的/home/用户名/anaconda3/bin，只要用户名没变，导入后基本没问题。但如果你用了虚拟环境且虚拟环境名和旧系统有冲突，就要检查~/.bashrc里的 conda 初始化脚本是否指向了正确的路径。

5.4 调整 WSL2 内存和 CPU 使用上限

WSL2 默认最多占用物理内存的 50%，这是.wslconfig文件控制的。如果你本机内存就是 16GB，默认 8GB 可能不够跑大模型推理或同时开几个 Python 进程。在 Windows 用户目录下新建一个名为.wslconfig的文件，写入：

[wsl2] memory=12GB processors=8 swap=2GB

然后wsl --shutdown再重新启动。注意 memory 不能设太高，要留给 Windows 本身 4GB 左右，否则两个系统互相抢内存会明显卡顿。processors 数量建议设为物理核心数减 2，比如 8 核 16 线程就设 6，这样 Windows 侧不至于被完全饿死。

我自己的机器是 32GB 内存 + 12 核。配成 memory=20GB 之后，WSL2 里同时跑一个 7B 模型推理 + 一个微调实验，Windows 侧开浏览器和几个编辑器都不卡。如果内存只有 16GB，老老实实用默认配置，别开太多东西。

6. AI 开发环境落地：Python、CUDA 和常用工具的实测组合

6.1 在 WSL2 里建立 Python 环境的几条推荐路径

WSL2 里管理 Python 环境的方式和裸机 Ubuntu 并没有本质区别。我的建议是：除非有特殊原因，否则用 Miniconda 或者 uv 这类现代工具，不要直接往系统 Python 里装包，避免系统升级时把环境弄坏。

安装 Miniconda 非常简单：

cd /tmp wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3

装完后初始化 shell：

$HOME/miniconda3/bin/conda init bash source ~/.bashrc

然后建一个独立的 PyTorch 环境，把框架和 CUDA 依赖隔离在里面：

conda create -n py311 python=3.11 conda activate py311 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

Python 版本我建议用 3.10 或 3.11，这两个版本对 PyTorch 和大部分推理库的兼容性最好。不要盲目追求新版本，新版本 Python 发布后总会有部分库没跟上，切回旧版本最省心。

6.2 实用工具链：Jupyter、VS Code 远程连接与文件访问

WSL2 开发最舒服的一点是 VS Code 的 WSL 远程插件体验极好。装好插件后，在 WSL2 终端里敲code .就能直接用 VS Code 打开当前目录。这个模式下的文件修改、终端执行、代码补全都是原生的，基本感觉不到你是在虚拟机里干活。

跑 Jupyter Lab 也不用额外配置，直接在 conda 环境里安装：

conda install -c conda-forge jupyterlab jupyter lab --no-browser --ip=0.0.0.0

这里有个细节：不要在 WSL2 里用localhost:8888访问。虽然 WSL2 支持 Windows 直接访问 localhost 接口，但有时候会因端口冲突或网络模式问题出现连接失败。最稳妥的办法是在 Windows 浏览器里访问http://localhost:8888。如果这个也不通，大概率是 WSL2 的端口转发服务没启动，执行wsl --shutdown再重新开启即可。

Windows 访问 WSL2 里的文件可以直接在文件资源管理器地址栏输入\\wsl$\Ubuntu-24.04\home\用户名，但这个方式在大量小文件读写时性能很差。做大数据集读取训练时，建议把数据集放在 Linux 文件系统内部，跨文件系统的读写会明显拖慢训练速度。我在实际测试中，从 /mnt/c 读取图片数据集训练的速度比从 Linux 家目录读取慢 30% 左右，所以哪怕 C 盘有现成数据，也建议先复制进 WSL2 内再用。

6.3 模型推理和训练时 WSL2 的性能边界在哪里

关于 WSL2 的性能，网络上的论点两极分化。有人说"性能损失可以忽略"，也有人说"跑起来比双系统慢一半"。我自己的测试结果表明：GPU 密集型的任务几乎没有可感知的差距，CPU 和文件 IO 密集型的任务有轻微损失。

用同一个 ResNet-50 训练脚本对比：WSL2 环境的单卡训练吞吐量为裸机 Ubuntu 环境的 98%，差异基本在噪声范围。用 top 命令观察 CPU 使用率时，能看出 WSL2 底层虚拟化调度有一点开销，但除非你跑的是极度依赖内存带宽的 HPC 任务，否则完全不用在意。

真正需要关注的是跨系统文件操作。刚才说过 /mnt/c 访问慢，另一个边界是 Windows Defender 实时扫描。Windows 侧实时保护会扫描 WSL2 的 vhdx 文件，在训练中不断读写模型 checkpoint 时会造成额外的 CPU 开销。我的做法是把 WSL2 的数据目录加入 Defender 排除名单。注意这属于系统安全配置，不同环境的策略要求不一样，你操作的机器如果是公司统一管理，建议先咨询 IT 再决定是否调整。

6.4 本地跑大模型推理：显存分配与 OOM 处理的一点经验

在 WSL2 里跑大模型推理，比如本地加载一个 7B 参数的量化模型，要注意 WSL2 的显存分配机制和裸机是一致的，NVIDIA 驱动会直接把显存透传给 Linux 应用。所以 CUDA 进程申请的显存就是实际物理显存，不存在"虚拟显存"一说，OOM 时也会看到熟悉的CUDA out of memory报错。

如果你准备在 WSL2 里跑 Ollama 或 llama.cpp 这类推理工具，有一点值得留意：WSL2 默认会限制共享内存大小。一些推理框架会用到共享内存做进程间数据交换，如果报错shmget failed或Bus error，需要给 /dev/shm 扩容。在/etc/wsl.conf里可以配置，但更简单的方式是在推理命令前加上--shared-memory-size参数，或者在容器里挂载更大的 tmpfs。这个坑在原生 Ubuntu 上不常见，在 WSL2 里遇到的人却不少，遇到相关报错时可以先朝这个方向排查。

6.5 WSL2 与嵌入式 Linux 开发的衔接

前面主要聊的是 AI 开发，但热词里出现了"嵌入式linux项目"和"linux内核"相关词，我也顺带说一下。WSL2 跑的是标准内核，所以交叉编译工具链、QEMU 模拟、内核模块编译这些工作都能正常进行。我自己就在 WSL2 里交叉编译过 ARM64 的内核模块，然后用 qemu-user 跑过简单的 ARM ELF 可执行文件，整个过程没有遇到障碍。

这里要强调的是"内核级"这个概念的实际含义：WSL2 的 Linux 内核是微软维护的定制版，但它跑的是纯粹的内核，不是 API 模拟，这一点和 WSL1 有本质区别。你可以在里面加载内核模块、查看 /proc、用 perf 做性能分析，行为表现和普通 Ubuntu 服务器基本一致。不过需要注意的是，WSL2 的内核不开源的部分很少，主体是 Linux 内核主线基于的长期稳定分支，所以大部分开发任务足够用了。

7. 最后聊几句我对 WSL2 作为 AI 开发台的判断

我实际用了 WSL2 做 AI 开发已经有一年多，从早期版本还不稳定，内核升级频繁，到现在 Windows 11 上收敛得相当好用。这个过程里最大的感受是：如果目标是"在 Windows 笔记本上做深度学习开发"，WSL2 已经是当前最合理的选择，没有之一。它不需要你抛弃 Windows 生态，又几乎完整地给你一个 Linux 环境，还能直接调 GPU。对于独自开发、小团队协作、上课实验这些场景，它比虚拟机更轻，比双系统更省事。

也有不适合的场景。如果你的训练任务需要持续跑几天几夜，集群节点又不方便远程连接，Windows 睡眠策略、系统更新重启这些问题会变成致命缺点——WSL2 依附于 Windows 运行，Windows 挂了它一定挂。这种批量任务还是老老实实交到真正的 Linux 服务器上。如果你的 GPU 是 A 卡或核显，目前绕开 NVIDIA 生态的 CUDA 加速支持都还不够成熟，WSL2 优势也会大打折扣。

最后分享一个小习惯：我每个月会给 WSL2 做一次快照式备份，就是第 5 章的wsl --export。tar 包直接丢到移动硬盘，哪天系统出问题、公司统一换电脑，拿包导入一次就回来了，比重新配置环境不知道省多少时间。这个习惯是从第一次把系统搞崩之后开始养的，现在每次导包只要十几分钟，却能换来一整个开发环境的平安。

如果你刚看完这篇准备动手，我的建议是：先按第 2 章装好 Ubuntu 和 WSL2，然后直接按第 3 章把 CUDA 和 PyTorch 配齐，跑一次torch.cuda.is_available()。只要这一行输出 True，你的 AI 开发环境就算正式落成了，后面的调整都只是优化问题。