企业官网建设流程全解析

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

Windows 用户想做 AI 开发，过去无非两条路：装双系统，或者开虚拟机。双系统每次切换都要重启，烦不说，来回折腾容易把硬盘和数据搞乱；虚拟机倒是灵活，但 GPU 性能被虚拟化层卡掉一大截，跑个模型训练能比物理机慢 30% 起步，谁用谁知道。直到 WSL2 把“内核级 Linux + GPU 直通”这套组合拳打出来，相当于直接在 Windows 里塞了一个轻量级虚拟机，Linux 内核是真的在跑，GPU 算力却是真的能透传进去，应用层用起来和原生 Linux 几乎没区别。

这个标题的核心目标很明确：在 Windows 11/10 上，通过 WSL2 拉起一套完整的 AI 开发环境，从 Python、CUDA、PyTorch 到各种训练工具链，全都在 Linux 侧跑，同时把 NVIDIA 显卡的算力直接映射进这个环境。适合谁？适合那些主力机是 Windows、但所有 AI 生态依赖 Linux 的开发者和学习者，也适合不想重装系统、又想体验内核级 Linux 环境的人。这套方案的优势一句话总结：不用重启、不用装双系统、不损失 GPU 性能，日常写代码用 Windows，训练模型切到 WSL2 里跑，两边各干各的活。

2. WSL2 的底层逻辑与 GPU 直通原理

2.1 WSL2 和 WSL1 到底差在哪

很多人听说 WSL，第一反应是“这不就是个 Windows 的 Linux 工具吗”。其实 WSL2 和 WSL1 是两个完全不同的物种。WSL1 用的是系统调用翻译层，Windows 内核直接翻译 Linux 的系统调用，性能好但兼容性差，很多依赖内核模块的软件跑不起来。WSL2 则是在 Hyper-V 虚拟化平台上跑一个真正的 Linux 内核，是一个轻量级虚拟机，内核完全独立，兼容性大幅提升，几乎所有 Linux 软件都能装、能跑。

代价是内存和启动机制不同了。WSL2 因为要跑一个完整内核，内存占用会比 WSL1 高，启动也要花一两秒。但做 AI 开发，内核兼容性和生态完整性远比那几秒启动时间重要。尤其像 CUDA、Docker、OpenGL 这些依赖内核级支持的软件，WSL1 基本没法用，WSL2 才有戏。

2.2 GPU 直通的原理：不是“共享”，是“透传”

“GPU 直通”这四个字听起来玄乎，拆开来看其实不难理解。传统虚拟机要做到 GPU 直通，需要把物理显卡完整分配给某个虚拟机，别的虚拟机碰都不能碰，迁移性差，配置还麻烦。WSL2 走的是另一条路：基于微软和 NVIDIA 合作开发的 GPU 虚拟化方案 GPU-PV（GPU Paravirtualization），把 Windows 的 WDDM 驱动栈和 Linux 侧的驱动栈桥接起来，应用层直接通过统一的 API 调用到物理 GPU，计算任务由真正的显卡执行。

关键点在于，你在 Windows 侧安装的 NVIDIA 驱动，是同时给 Windows 桌面和 WSL2 Linux 用的。WSL2 里不需要再装什么显卡驱动，驱动模块已经随 Windows 驱动一起加载进 Linux 内核了。你只需要在 Linux 侧装 CUDA Toolkit、cuDNN 这类用户态的库，就能直接调用 GPU 算力。这也是为什么很多人在 WSL2 里跑 PyTorch 训练，nvidia-smi 看到的就是那种“驱动版本在 Windows 侧、CUDA 版本在 Linux 侧”的组合显示——很正常，别懵。

2.3 为什么 AI 开发选 WSL2 比双系统舒服

双系统上跑 AI 开发最大的痛点是切换成本。你写完一段 Python 改个 bug，要运行 Linux 侧的数据脚本，就得保存工作区、重启进 Linux、跑完再重启回来。中间一旦哪个文件没存，心态直接崩。WSL2 把 Linux 环境变成了 Windows 里的一个普通进程，文件在两边可以互通访问，你在 Windows 侧用 VS Code 编辑代码，在 WSL2 侧跑训练脚本，数据存两边都行，无缝切换。

从资源利用率上也更划算。双系统分区，你在 Linux 侧想用到 Windows 上的训练数据集，要么挂载 NTFS 分区，要么来回拷贝，麻烦得很。WSL2 默认就能访问 Windows 的整个盘符，没必要拷来拷去，模型权重、数据集直接放在 Windows 磁盘上，Linux 侧当作/mnt/d/...路径用就行。真要说有什么注意点，就是跨文件系统读写 IO 会有损耗，训练大文件多的数据集时，建议还是放在 Linux 文件系统内（比如~/datasets）跑，避免性能被文件映射拖后腿。

3. 环境部署实操：从零把 WSL2 支棱起来

3.1 开启 WSL2 的前置条件自查

在动手之前，先确认你的机器满足三个条件：

• Windows 10 版本 19041 及以上，或者 Windows 11 任意版本，才支持 WSL2。
• CPU 必须支持虚拟化，且 BIOS 里已开启 VT-x/AMD-V。
• 如果机器上有 VMware/VirtualBox，需要处理冲突，最好先停用不相关的虚拟化功能。

第一个条件不满足，你后续所有安装步骤都会卡在“虚拟化平台未启用”。第二个条件尤其容易踩坑，很多人的 CPU 明明支持虚拟化，但 BIOS 里默认关闭了，如果后续安装时报错提示“此计算机上未启用虚拟机平台”，第一反应就去检查 BIOS 里 Intel VT-x（或 AMD SVM）是否开启。

另外建议用管理员权限打开 PowerShell 来跑命令，否则有些步骤会静默失败，表面上没报错，实际没生效，折腾半天才发现权限问题。

3.2 安装步骤：一行命令装好 WSL2 + Ubuntu

最简单的装法是直接用wsl --install，Win10 和 Win11 都支持，一条命令会把 WSL 核心组件、虚拟机平台、以及默认的 Ubuntu 发行版全部装好。在 PowerShell 管理员模式里执行：

wsl --install

装完之后重启一次系统，然后 Ubuntu 会进入初始化设置，让你配置用户名和密码。这里有个坑：第一次配置用户，密码输入时屏幕不显示任何字符，是正常现象，不是键盘坏了，直接盲打回车就行。

重启之后先在 Windows 终端里检查一下版本：

wsl -l -v

看到 Ubuntu 的状态是Running，VERSION 列显示2，就说明已经是 WSL2 了。如果 VERSION 显示1，说明默认跑在 WSL1 模式，手动切一下就行：

wsl --set-version Ubuntu 2

3.3 安装 Ubuntu 22.04：镜像慢与版本冲突的解决办法

wsl --install默认装的是当前时间点 WSL 官方推荐的版本，可能是 Ubuntu 24.04，也可能是别的。如果你明确想装 Ubuntu 22.04，和后面的 CUDA 生态兼容性更稳一些，可以指定发行版名称安装：

wsl --install -d Ubuntu-22.04

如果这一步卡在下载或者特别慢，八成是网络原因。可以换一些 Linux 镜像源，WSL 支持从镜像源直接安装发行版。命令格式是：

wsl --install -d <发行版名称> --web-download

--web-download参数会绕过微软商店的下载通道，从网络直接拉取镜像，很多时候能明显加快速度。如果还是慢，可以手动从 Linux 发行版官网下载 appx 包，然后用Add-AppxPackage命令安装，但一般用--web-download就够了。

我实测下来，用--web-download装 Ubuntu 22.04，一分钟左右就能把镜像拉下来，比默认通道快不少。

3.4 把 WSL2 安装到非系统盘：别让 C 盘变成灾难

WSL2 默认把虚拟磁盘放在 C 盘，一个 Ubuntu 装完大概 5-8 GB，后续你装 CUDA、PyTorch、模型文件，分分钟撑到 30-50 GB。C 盘不太够用的，一定要趁刚装完的时候迁移到 D 盘，别等用满了再搬，那会麻烦得多。

操作方式很简单，先导出再导入：

wsl --export Ubuntu D:\wsl-backup\ubuntu.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\wsl-distros\ubuntu

有一个细节，从这个方式导入的 WSL 发行版，默认登录用户是 root，原来你配的普通用户、密码、HOME 目录都没了。想要还原回原来的用户，得在 Ubuntu 里手动指定默认用户，或者直接/etc/wsl.conf里加一行：

[user] default=你的用户名

然后执行wsl --terminate Ubuntu重启一下发行版生效。

另外一个替代方案是先下载 Ubuntu 的 tar 包，用wsl --import导入到 D 盘，效果一样，而且从 22000 版本开始 WSL 还支持从云端直接导入 tar 镜像，灵活性更高。但无论哪种方式，记住一个原则：尽量让虚拟磁盘待在非系统盘，不然 C 盘空间会随着模型文件越攒越多直接爆掉。

3.5 更新 WSL 内核：老内核默认跑不动新功能

WSL2 的内核其实是可以升级的。微软经常给 WSL 本身推送更新，但命令行的wsl --update或者直接装最新版 WSL 包，很多人会忽略这一步。如果你的 WSL 版本太老，可能出现wsl2 尚未准备就绪或者请启用虚拟机平台这种报错，其实就是内核组件没更新，和驱动、虚拟化设置都没关系。

建议装完 WSL 后第一时间：

wsl --update

然后重启一次终端，确认wsl -v输出里的 WSL 版本至少是 1.x 以上（版本号高的更新），这一步能省下你后面至少三项疑难杂症排查。

4. CUDA、cuDNN、PyTorch 的安装与 GPU 验证

4.1 Windows 驱动装好，Linux 侧才能看到显卡

前面说了，WSL2 场景下，Linux 侧是不需要单独装 NVIDIA 驱动的，GPU 驱动由 Windows 承载，透传给 WSL2。所以第一步反而是在 Windows 侧把显卡驱动更新到最新版本，确认nvidia-smi在 Windows 终端里正常显示。

注意，驱动版本决定了你 Linux 侧能支持的 CUDA 版本上限。推荐去 NVIDIA 官网下载 Game Ready 或 Studio 驱动均可，不要用 Windows 自动更新提供的旧版本，尽量手动装最新版。装完在 Windows 终端里跑nvidia-smi，确认右上角的 CUDA Version 值，这个值代表这个驱动最多能支持的 CUDA 版本，后续你 Linux 侧装的 CUDA 版本不要超过它。

4.2 进入 Linux 侧：装好了 Ubuntu，要怎么正式开工

WSL2 本身是一个“即接即用”的交互式环境。打开 Windows 终端（或者 Windows Terminal），输入wsl就进入 Ubuntu 的 bash。想要更顺手，直接安装 Windows Terminal 然后配置 Ubuntu 为默认 profile，好看也好用。

进到 bash 之后，第一件事是换源、更新软件包：

sudo apt update && sudo apt upgrade -y

如果你在安装软件、克隆 GitHub 仓库时感觉很慢，建议先换国内镜像源，比如清华、阿里云源。这一步能把这个环境的使用体验从“卡顿”拉到“顺畅”，我做这套环境的习惯是装完必换源。

4.3 CUDA Toolkit 安装：在 WSL2 里装什么、不装什么

第二步是在 Linux 侧安装 CUDA Toolkit。注意，不要在 WSL2 里安装 NVIDIA 的 Linux 驱动，那会破坏 WSL 内部的 GPU 透传机制。你只需要装 toolkit 里的用户态库和工具链。

推荐用 NVIDIA 官方给 WSL-Ubuntu 提供的 deb 源来装：

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

安装时间取决于网速，装完之后验证：

/usr/local/cuda/bin/nvcc --version

如果输出了 CUDA 版本号，说明 toolkit 安装成功。装完记忆一个关键点：CUDA 的 PATH 和 LD_LIBRARY_PATH 需要配置：

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

每次都重新 export 太啰嗦，建议直接写进~/.bashrc里，一劳永逸。

4.4 在 WSL2 里验证 GPU 真正能用：nvidia-smi 和一个小 demo

验证 GPU 是否真正直通，Linux 侧输入：

nvidia-smi

如果能看到类似 Windows 侧的显卡信息，比如 GPU 名称、显存大小、驱动版本，说明驱动层已经通了。这里的 driver 版本显示的其实是 Windows 侧驱动版本，完全正常。

再深一步验证，用 Python 写个小脚本，调用 CUDA 算力去测矩阵计算或直接调用 PyTorch：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果输出True和显卡型号，说明 PyTorch 已经能调用 GPU。有些教程会让你跑一个简单的张量计算来验证是否真的用上了 GPU，这在后面“跑个最小例程”的时候一并做。

4.5 安装 PyTorch / TensorFlow：版本匹配是最大的坑

PyTorch 的安装命令：

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

后面那个--index-url参数用来指定 CUDA 版本对应的 PyTorch wheel 源。坑就出现在这里：你可能在 Windows 侧装过一个 PyTorch，到了 WSL2 里又得装一个，两边的 CUDA 版本还未必一致。如果 CUDA 版本和驱动版本不匹配，torch.cuda.is_available()就会返回False，你就得回头检查是驱动版本不够，还是 PyTorch 的 wheel 装错了。

查攻略时经常看到cu121、cu118这种后缀，意思是 CUDA 12.1 或 CUDA 11.8 编译的 PyTorch。版本选择原则：驱动能支持的最高 CUDA 版本，向下兼容。比如驱动支持 CUDA 12.x，你装 cu121 或 cu118 都能用。你 Linux 里装的独立 CUDA Toolkit 版本，只要比 PyTorch 要求的版本高就行，不一定完全一致。

TensorFlow 同理，确认tensorflow-gpu和 CUDA/cuDNN 版本是否匹配也很重要，看官方文档里给的对应表即可，别凭感觉乱配。

4.6 cuDNN 也要装吗，怎么装

如果你要用 TensorFlow，或者用一些底层依赖 cuDNN 的框架，就需要单独装。cuDNN 不在 CUDA Toolkit 里，得从 NVIDIA 官方下载，需要注册账号登录。下载完 deb 包：

sudo dpkg -i cudnn-local-repo-ubuntu2204-8.x.x.x.deb

装完记得sudo ldconfig刷新一下动态链接库。如果跳过这步，可能你程序跑起来时提示找不到libcudnn.so，又是半小时起步的烦恼。

5. 环境调优：Windows 与 Linux 侧的协作配置

5.1.wslconfig配置文件：限制内存和 CPU 的正确姿势

WSL2 默认吃掉的内存上限是物理内存的 50% 或者总内存 8GB 取最小值，对 AI 开发来说经常不够用，尤其是训练大模型时，Python 进程动不动就 OOM（内存耗尽）被系统 kill 掉，此时第一时间不一定是加内存，而可能是调.wslconfig。

路径在 Windows 用户目录下C:\Users\你的用户名\.wslconfig，用记事本或者 VS Code 新建即可。我的配置参考：

[wsl2] memory=16GB processors=8 swap=8GB

改完配置，需要有一步让 WSL2 重启加载新的资源配额，执行：

wsl --shutdown

再重新进入 WSL2，用free -h确认内存数值变化。注意，memory别设成物理内存的全部，Windows 本身还要运行，互相抢内存会让屏幕卡顿。

5.2 文件系统边界：什么时候用 /mnt/c，什么时候放 Linux 内部

WSL2 天然支持访问 Windows 的盘符，Linux 侧把 C:\ 挂在/mnt/c/下。这样做很方便，但如果你跑的是训练脚本，要频繁读写大量小文件，放在/mnt/c/下会慢很多，因为跨文件系统传输有额外开销。大文件传输还好，几千个小文件就会明显拖慢训练数据加载速度。

最好养成一个习惯：训练数据集、模型权重、大文件放 Linux 自己的文件系统里，比如~/datasets/；最终成果、配置脚本、小文件可以放 Windows 侧，比如/mnt/d/projects/。两边互通访问很灵活，但性能敏感的部分要在 Linux 内部干活。

5.3 从 Windows 侧调用 WSL 里的 GPU 程序

WSL2 也支持从 Windows 侧直接运行一些 Linux GUI 程序，比如在 Windows 终端里输入wsl nvidia-smi，Windows 侧的控制台里会显示 Linux 侧跑出来的结果。另外，如果你在 Linux 侧训练了一个模型，想用 Windows 侧的工具可视化日志或上传到云平台，可以直接访问 WSL 文件系统中的文件，Windows 资源管理器地址栏输入\\wsl$\Ubuntu，就能像操作普通目录一样拷文件。

还有些人会在 Windows 侧直接用 PyCharm 连 WSL 解释器，在 PyCharm 的设置里配置 WSL Python 环境即可。这比在 Linux 侧用命令行写代码舒服很多，尤其是习惯了图形化调试的人，WSL2 在这方面支持得相当好。

6. 实战：在 WSL2 里跑通一个 AI 小模型的训练全流程

6.1 准备一个小数据集和最小训练脚本

装了环境，最终目的还是跑起来跑得顺。拿一个最简单的手写数字识别（MNIST）来做验证，权重小、训练快、容易确认 GPU 是否真正派上了用场。

先装依赖：

pip install torch torchvision

然后建一个train_mnist.py：

import torch import torch.nn as nn import torch.optim as optim from torchvision import datasets, transforms from torch.utils.data import DataLoader transform = transforms.Compose([ transforms.ToTensor(), transforms.Normalize((0.1307,), (0.3081,)) ]) train_dataset = datasets.MNIST('./data', train=True, download=True, transform=transform) train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True) # 一个极简 CNN class SimpleCNN(nn.Module): def __init__(self): super().__init__() self.conv1 = nn.Conv2d(1, 32, kernel_size=3) self.conv2 = nn.Conv2d(32, 64, kernel_size=3) self.fc1 = nn.Linear(64 * 5 * 5, 128) self.fc2 = nn.Linear(128, 10) def forward(self, x): x = torch.relu(self.conv1(x)) x = torch.max_pool2d(x, 2) x = torch.relu(self.conv2(x)) x = torch.max_pool2d(x, 2) x = x.view(x.size(0), -1) x = torch.relu(self.fc1(x)) return self.fc2(x) device = 'cuda' if torch.cuda.is_available() else 'cpu' model = SimpleCNN().to(device) optimizer = optim.Adam(model.parameters()) criterion = nn.CrossEntropyLoss() for epoch in range(3): for batch_idx, (data, target) in enumerate(train_loader): data, target = data.to(device), target.to(device) optimizer.zero_grad() output = model(data) loss = criterion(output, target) loss.backward() optimizer.step() if batch_idx % 100 == 0: print(f'Epoch {epoch} Batch {batch_idx} Loss {loss.item():.4f}')

6.2 训练过程和性能观察笔记

在 Linux 侧执行：

python train_mnist.py

如果看到训练 loss 逐轮下降，并且 GPU 利用率可以被 Windows 侧的任务管理器看到，说明整个链路已经通了。

我跑这个例程时，用 RTX 4060，3 个 epoch 的 MNIST 训练耗时在 20 秒上下，CPU 占用却不低，说明这个模型太小，GPU 利用率还没顶满就已经训练完了，瓶颈反倒在数据加载。这个现象很真实，也解释了为什么小模型在小数据集上，初学者会觉得“GPU 好像没在干活”。你可以用nvidia-smi dmon实时看 GPU 利用率，或者用watch -n 1 nvidia-smi，基本能判断算力是否真的被调动了。

6.3 数据加载和内存的坑：为什么训练动不动就崩

训练过程中最常见的崩溃原因有三类：

1. 显存不够。PyTorch 报CUDA out of memory，日志最后一行经常是RuntimeError: CUDA out of memory.。对策：减小 batch size，降低图像分辨率，用with torch.no_grad():排查哪一步占显存过大，或者加torch.cuda.empty_cache()，但根本办法还是减小规模或加显存。

2. 内存不够。WSL2 默认只给 50% 内存，大模型加载权重时直接把内存打满，进程被 OOM kill。对策：调.wslconfig里的memory。

3. 磁盘 IO 慢。数据集放/mnt/d/，每次 epoch 都要从 Windows 侧读几百 MB 数据，训练速度肉眼可见变慢。对策：把数据集复制到~/datasets/下，速度能翻倍。

这三个坑对应三个优化层面，实际调试频率极高。遇到问题别先急着怀疑代码，先看一眼显存、内存和磁盘 IO 三项指标，多数问题都出在这。

7. 常见问题速查表与解决方案

1. 报错：WSL2 尚未准备就绪

• 原因：WSL 内核组件未更新，或虚拟机平台未启用。
• 解决：先wsl --update，不行就去“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”，重启，再wsl --update。

2. 报错：请启用虚拟机平台 Windows 功能并确保在 BIOS 中启用虚拟化

• 原因：BIOS 里虚拟化未开，或者 Windows 功能没勾选。
• 解决：进 BIOS 找 Intel VT-x / AMD SVM / SVM Mode，开启保存，重启后 Windows 功能里把“虚拟机平台”勾上。

3. 安装 Ubuntu 时下载慢或下载失败

• 原因：官方源网络波动。
• 解决：试wsl --install -d Ubuntu-22.04 --web-download，手动下载 tar 包再导入，或者给 WSL 换了国内源之后再做apt update。

4. 想迁移到 D 盘，怎么“搬家”最安全

• 解决：wsl --export导出 tar 包，wsl --unregister注销，wsl --import导入到新路径。注意导入后默认用户会变成 root，用/etc/wsl.conf配置回原用户。

5. CUDA 装完nvidia-smi能看到 GPU，但 PyTorch 报torch.cuda.is_available()为 False

• 原因：PyTorch 的 wheel 版本对应的 CUDA 版本不匹配，驱动版本不够新。
• 解决：先看nvidia-smi的 CUDA 版本，再装对应版本的 torch wheel。比如驱动支持 12.1，就装cu121版本。驱动太旧就先去 Windows 侧更新 NVIDIA 驱动。

6. Linux 侧会不会和 Windows 侧装两份 CUDA 冲突

• 本质上互不干扰，它们各自有自己的环境变量和库路径。唯一要注意的是显存主次问题，WSL2 内调用 GPU 时，Windows 桌面本身的图形渲染也走同一张卡，显存会被两边共用，模型训练吃显存太狠，可能导致 Windows 桌面卡顿。

7. 开着训练任务，Windows 桌面卡顿

• 这是显存被分走的正常现象，WSL2 里训练大模型时，Windows 侧基本没法干重活。解决办法：要么调小 batch size，要么给 Windows 留出足够显存。

8. 权重要导出给 Windows 侧工具处理

• 直接去文件管理器地址栏输\\wsl$\Ubuntu，找到你在 Linux 侧生成的文件路径，复制出来即可，比命令行cp直观得多。

8. 扩展视角：WSL2 + AI Agent 与嵌入式开发场景

8.1 从训练到部署：能否在 WSL2 里跑推理服务

WSL2 不仅能训练，也能直接跑推理服务。比如你用 FastAPI 搭一个本地推理接口，加载 PyTorch 模型权重，接受 HTTP 请求返回结果，这在 WSL2 里完全可行。由于 WSL2 的网络模式是 NAT 转发，外部设备访问你 Windows 时需要通过端口转发。像wsl run python api.py在 WSL2 内监听 8000 端口，Windows 本机访问localhost:8000就能通，局域网其他设备访问你的 Windows 地址也能转发进去，这一点很适合做模型演示和本地小工具。

如果你想把 WSL2 当轻量级 GPU 服务器用，它在 AI 开发场景里，尤其适合单机模型验证和自动化测试，没必要为了一个测试环境去开整台 Linux 服务器。

8.2 WSL2 跑 AI Agent 的潜力

现在很多 AI Agent 项目都在 Linux 环境里开发，比如多工具调用的 agent 框架、机器人操作系统相关的工具链。WSL2 和这些生态的兼容性相当好，因为本质上 Linux 内核是完整的，各种现成的 Linux 工具链、Python 包、Node 服务都能跑。我自己试过在一个 WSL2 实例里同时起多个 agent 进程，配合调度脚本管理，内存开销控制好之后，体验和一台普通 Linux 开发机几乎没有差别。

当然也要承认，如果你对 Linux 内核模块、字符设备、底层硬件抽象有强需求，嵌入式开发类项目，WSL2 不一定够，那种场景用原生 Linux 会更合适。WSL2 更适合“上层 AI 应用开发 + 模型训练 + 轻量服务化”这一类，不要硬往上塞系统级需求。

8.3 和 Docker Desktop 的配合

AI 开发中经常要用 Docker 统一环境，WSL2 作为 Docker Desktop Windows 版的后端，也是一个经典用法。Docker Desktop 集成 WSL2 后，你既可以在 Windows 侧用 Docker 命令管理容器，也可以在 WSL2 里直接跑容器，前提是 Docker Desktop 里把“Use the WSL 2 based engine”打开，并分配对应发行版。这个配合最大的价值是环境隔离，训练环境、服务环境各用各的容器，不污染本地 Python 环境。

跑 GPU 容器时，记得加--gpus all参数，并确认容器内能看到nvidia-smi。如果容器里看不到，多半是 Docker Desktop 的 GPU 支持没开启，检查 Docker Desktop 的 Resources 设置里是否勾选了 “GPU” 相关选项。

9. 个人实践心得与几个小技巧

这套 WSL2 AI 开发环境，我用了大半年。期间踩的最多的坑反而不是安装，而是版本匹配——CUDA、PyTorch、驱动三者之间的兼容关系，理解透彻之后，剩下的事基本一马平川。核心建议就是：每次装环境前，先确认三个版本号：Windows 驱动支持的 CUDA 版本、你要装的 PyTorch 需要的 CUDA 版本、以及 CUDA Toolkit 的版本，把它们写在笔记里，按顺序安装，基本不会出重大问题。

再分享一个实际工作中特别好用的小技巧：把 WSL2 和 VS Code 的 Remote-WSL 扩展配合起来。在 Windows 侧打开 VS Code，连接到 WSL，编辑 Linux 目录下的代码，性能不错，还沉浸。比直接在纯终端里写代码舒服得多。配合 PyCharm 的 WSL 解释器也可以，看你的个人习惯。

最后一个小贴士：每个 WSL2 发行版之间的数据是隔离的，多项目多环境的需求，建议一个人搞几个独立的发行版实例，避免互相污染依赖。实例太多手动切换麻烦，倒是可以把生成式 AI 的 Agent 场景和多实例管理结合起来，顺手还解决了不少环境管理的心智负担。