Windows上跑AI开发：WSL2内核级Linux与GPU直通实战指南

在 Windows 上做 AI 开发，最让人难受的不是显卡不够快，而是现代深度学习工具链几乎都长在 Linux 身上。模型训练、CUDA 环境、Docker 隔离、多机分布式，哪一样在 Windows 原生环境下都像穿着不合脚的鞋跑步。后来我把主力开发环境切到了 WSL2，相当于在 Windows 里跑了一个内核级 Linux，同时把 GPU 计算能力直通进 Linux 子系统，这套组合我用了两年多，从研究实验到日常项目落地都在跑。今天把整套部署思路、核心原理和踩坑记录整理出来，给同样想在 Windows 下好好玩 AI 的朋友一条能直接照着走的路。

这套方案解决的核心问题很直白：不用装双系统、不用买第二台机器，Windows 日常办公和 Linux 开发环境可以同时在场。而且 GPU 不是“勉强能用”的水平，像 PyTorch 训练、本地大模型推理、CUDA 计算这类重负载任务，实测性能和原生 Linux 差距非常小。无论你是刚入门 AI 的学生，还是每天跟模型打交道的工程师，只要主力机是 Windows，这篇文章都值得看完。

1. 先搞清楚架构：WSL2 的“内核级 Linux”和 GPU 直通到底是什么

1.1 从 WSL1 到 WSL2：翻译层彻底换成了真内核

很多人在 WSL1 时代对“Windows 上的 Linux”印象很差，觉得那是一个“能跑 bash 和 apt 的模拟器”。这个印象不算错：WSL1 的架构是系统调用翻译层，把 Linux 程序发起的系统调用翻译成 Windows 的系统调用。好处是启动快、和文件系统无缝融合，但坏处也很致命——它不是一个真正的 Linux 内核。

做 AI 开发时这个痛点会被无限放大。Docker 需要 Linux 内核特性支持，WSL1 上跑 docker 是个灾难；CUDA 相关的底层库、某些依赖 eBPF 的工具、依赖io_uring的新式 I/O 框架，在翻译层上经常出现莫名其妙的行为。我早期试过在 WSL1 里跑 TensorFlow，装包没问题，但一跑训练就各种诡异的段错误，排错排到怀疑人生。

WSL2 做了一个根本性改变，从“翻译层”变成了“轻量虚拟机”。它基于微软的 Virtual Machine Platform（Hyper-V 的底层虚拟化技术）跑一个真正的 Linux 内核，只是这个虚拟机被深度优化过：启动时间压缩到 1 到 2 秒，内存可以动态分配和回收，文件系统还保留和 Windows 互通的挂载方式。对用户来说，打开 Windows 终端，输入wsl，进入的是一个名副其实的 Linux 环境。对 AI 工具链来说，它终于拿到了“真正的 Linux”。

我把几种方案在脑子里做了一张对比表，差异一目了然：

1.2 “GPU 直通”直通的到底是什么

先说结论：WSL2 里的 GPU 直通，不是传统意义上把物理显卡整个塞进虚拟机（那叫 PCIe Passthrough），而是微软实现的一种半虚拟化方案，官方全称叫 GPU-PV（GPU Paravirtualization）。简单理解，物理 GPU 还是挂在 Windows 侧，驱动完全由 Windows 管理，但 Hyper-V 底层通过虚拟化桥把 GPU 的计算能力“映射”到了 WSL2 的 Linux 内核里。

对 NVIDIA 显卡来说，这个映射做得非常彻底。你在 WSL2 终端里输入nvidia-smi，能看到和你 Windows 下完全一致的显卡型号、显存容量、驱动版本，甚至 CUDA 版本。更重要的是，CUDA 程序跑起来后，GPU 上的 CUDA 核心是真的在干活，而不是某种软件模拟。

底层原理是 NVIDIA 在 WSL2 专用驱动里做了一层“用户态到内核态的转发”，Linux 侧的程序通过 CUDA API 发起计算请求，请求穿过 Hyper-V 的虚拟化层到达 Windows 侧驱动，由物理 GPU 执行。微软在这条路径上做了专门的性能优化，业内公布的基准测试和大量实测都显示，WSL2 里的 GPU 计算性能能达到原生 Linux 的 95% 以上。对绝大多数训练和推理任务来说，这个损耗可以忽略。

所以“内核级 Linux + GPU 直通”这句话，翻译成人话就是：你既拥有了一个真正的 Linux 内核环境，又不用担心性能浪费，显卡照样火力全开。

1.3 这套方案适合谁，不适合谁

我个人的判断是，WSL2 适合以下人群：

• 主力机是 Windows，不想为了跑模型重装系统。
• 日常需要 Windows 上的办公软件、企业通讯工具，又想兼顾 Linux 开发。
• 使用 PyTorch、TensorFlow、Hugging Face、Ollama 这类高频 AI 工具链。
• 需要 Docker 跑 CUDA 容器，但不想维护一台单独的 Linux 服务器。

不适合的情况也有：如果你的目标是跑多机多卡分布式训练，或者对网络性能、调度延迟有极致要求，原生 Linux 仍然是更稳妥的选择。WSL2 的 NAT 网络虽然日常够用，但高性能集群场景下会有额外开销。另外，如果你手里的电脑 CPU 不支持虚拟化（很老的机器或某些精简版云主机），WSL2 根本跑不起来，这种情况只能退而求其次。

2. 从零开始安装：WSL2 + Ubuntu 的完整落地步骤

2.1 安装前必须做的三项检查

千万不要上来就敲wsl --install，先把前置条件猜一遍，否则报错会把人折磨疯。

第一，Windows 版本。WSL2 正式支持需要 Windows 10 21H2 及以上，或者 Windows 11。如果还停留在老版本的 Win10，建议先把系统更新到最新。微软对 WSL2 的支持一直在迭代，新版本内核更新也更方便。

第二，虚拟化开关。WSL2 依赖 CPU 的虚拟化功能，Intel 平台对应 VT-x，AMD 平台对应 AMD-V。检查方法很简单：打开任务管理器，切到“性能”选项卡，看 CPU 那一栏的右下角，会显示“虚拟化：已启用”或“已禁用”。如果是禁用状态，需要进 BIOS 开启虚拟化选项。这一步很容易被忽略，我见过太多人卡在“无法启动，因为此计算机上未启用虚拟化”这个报错上，回头一查就是 BIOS 里没开。

第三，确认 Windows 功能里“适用于 Linux 的 Windows 子系统”和“虚拟机平台”两个功能处于启用状态。用管理员身份打开 PowerShell，执行这两条命令是最靠谱的方式：

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

执行完重启电脑，然后进入下一步。如果是 Windows 11，也可以直接用控制面板的“启用或关闭 Windows 功能”勾选这两项，效果一样。

2.2 一条命令安装和它背后的逻辑

前置条件满足后，安装 Ubuntu 其实就一条命令：

wsl --install -d Ubuntu-24.04

执行完这条命令，系统会自动做三件事：下载并安装 WSL2 内核、下载 Ubuntu 发行版镜像、完成初始化。如果这一步顺利，终端会提示你设置用户名和密码，然后就能直接进入 Ubuntu 环境了。

但实际执行时，有几个细节值得说清楚。第一，如果你的 WSL 内核本来就比较旧，建议先执行wsl --update把内核更新到最新版，避免后面 WSL 版本冲突。第二，-d参数指定发行版，Ubuntu 22.04 和 24.04 是目前用得最多的两个版本，建议直接 24.04 LTS，支持周期长，软件源也新。第三，想查看当前所有已安装的发行版及各自 WSL 版本，用：

wsl -l -v

正常输出里，Ubuntu 那一行的 WSL 版本应该是 2。如果显示版本 1，执行下面这条把它切到 WSL2：

wsl --set-version Ubuntu-24.04 2

2.3 把发行版装到 D 盘，C 盘空间救星

默认情况下，wsl --install会把发行版放到 C 盘，因为 WSL 的虚拟磁盘文件（ext4.vhdx）会随着你安装的包、模型文件、容器镜像不断膨胀，很容易把 C 盘挤爆。所以建议从一开始就把系统放到 D 盘或其他大容量分区。

新版本的 WSL 已经支持安装时指定位置，命令是这样：

wsl --install -d Ubuntu-24.04 --location D:\WSL\Ubuntu-24.04

如果你已经安装好了才发现位置不对，可以用导出再导入的方式迁移。步骤分三步走：

1. 在 PowerShell 中导出当前发行版：

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

2. 注销当前发行版：

wsl --unregister Ubuntu-24.04

3. 从备份导入到新位置：

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

这里有一个容易踩的坑：用--import导入后的默认用户会变成 root，而不是你之前创建的用户。解决方法是进入 WSL2，编辑/etc/wsl.conf，加入以下内容：

[user] default=你的用户名

保存后在 PowerShell 执行wsl --terminate Ubuntu-24.04，下次启动就会回到你的普通用户。

2.4 换软件源，让 apt 下载速度回到正常区间

默认的 Ubuntu 软件源服务器在国外，国内网络环境下执行apt update或安装基础软件包时常常慢到失去耐心。这一步需要把软件源替换成国内镜像站，操作很简单。Ubuntu 24.04 的软件源配置文件在/etc/apt/sources.list.d/ubuntu.sources，可以用 sed 直接替换：

sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.aliyun.com@g' /etc/apt/sources.list.d/ubuntu.sources sudo apt update && sudo apt upgrade -y

如果用阿里云镜像不顺手，换成清华、中科大等镜像站都可以，路径结构相同。换源后再装软件，速度能提升一个数量级，这个操作我建议在安装任何深度学习依赖之前先做掉。

2.5 下载慢和离线安装的备用方案

有些企业内网环境受限，或者 WSL 内核更新长时间卡住，这时候有几个正规的备用路径。

WSL2 内核更新慢时，可以直接从微软官方下载手动安装包wsl_update_x64.msi，双击安装后重启终端即可，不需要翻任何墙。发行版下载慢时，如果wsl --install走不通，可以从微软官方渠道下载对应发行版的 appx 安装包，然后用 PowerShell 执行以下命令离线安装：

Add-AppxPackage .\Ubuntu_2404.1.0.0_x64.appx

安装完成后，从开始菜单启动 Ubuntu 即可。这里要特别强调一句，务必认准微软官方渠道，任何第三方打包的“精简版”“绿色版”发行版都不要碰，安全和稳定性都没有保障。

3. GPU 直通落地：CUDA、Docker、PyTorch 一条龙

3.1 先想明白驱动是怎么回事

WSL2 里的 GPU 能用，靠的是 Windows 侧显卡驱动把计算能力桥接进 Linux。所以要强调一个反直觉的结论：WSL2 内不需要安装 NVIDIA Linux 驱动，装了反而是坑。

你需要做的，只是在 Windows 侧安装 NVIDIA 驱动。只要是近几年的显卡，去 NVIDIA 官网下载最新 Game Ready 或 Studio 驱动都行，它们都已经内置了对 WSL2 的支持。装好驱动后，重新启动 WSL2，正常情况下 Linux 里会直接多出这些文件：

ls /usr/lib/wsl/lib

里面能看到libcuda.so、libcuda.so.1、libnvidia-ml.so等动态库，同时终端里执行nvidia-smi应该已经能显示你的显卡信息了。如果提示找不到命令，可以把/usr/lib/wsl/lib加入 PATH，并把动态库加入链接路径：

echo 'export PATH=/usr/lib/wsl/lib:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/lib/wsl/lib:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc

这一步做完，GPU 直通的地基就打好了。

3.2 路线 A：在 WSL2 里装原生 CUDA Toolkit

如果你要写的是 CUDA C/C++ 程序，或者需要nvcc编译器直接参与构建，就装完整版 CUDA Toolkit。NVIDIA 为 WSL2 提供了专门的软件源，安装流程和普通 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-get update sudo apt-get -y install cuda-toolkit-12-4

安装完成后，把 NVCC 路径加进环境变量：

echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc

验证命令是nvcc --version，能输出版本号就算成功。这里我要给一个经验之谈：如果只是跑 PyTorch、TensorFlow 这类框架，我的建议是别装这个完整 CUDA Toolkit。框架通常自带 CUDA runtime，额外装一套 system-wide 的 CUDA 反而容易和框架内部的 CUDA 版本打架，出现各种libcudnn、libcublas版本冲突。个人笔记本上用路线 B 更省心。

3.3 路线 B：Ubuntu 内装 Docker，容器里独占 GPU

这是我目前主力使用的方案，也是我最推荐给做 AI 应用开发的人的方式。好处在于环境隔离干净，换 PyTorch 版本、换 CUDA 版本都只是换一个容器的事，不会把你的 Ubuntu 系统搞乱。

在 WSL2 里安装 Docker 有两种做法。第一种是直接在 Ubuntu 里装原生 Docker Engine，这样 WSL2 里的进程直接跟 GPU 通信，链路最短，性能最好。安装命令如下：

curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER

然后安装 NVIDIA 的容器支持工具，让 Docker 能识别并暴露 GPU：

sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo service docker restart

如果系统提示 docker 服务没启动，可以手动启动：

sudo service docker start

验证 GPU 是否能在容器里用，跑一条最简单的命令：

docker run --gpus all -it --rm nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

能看到显卡信息，就说明整套链路完全打通了。

第二种做法是用 Docker Desktop 的 WSL2 backend。这种方式容易上手，有可视化界面，但本质上是多了 Docker Desktop 这一层转发，性能和纯粹 Docker Engine 相比没有优势，而且占用的系统资源更多。我更推荐原生 Docker，一劳永逸。

日常跑 PyTorch，我自己常用的镜像组合是pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime或者nvidia/cuda:12.4.1-cudnn-devel-ubuntu22.04。前者开箱即用，后者适合需要自己搭环境的人。

3.4 实测一把：PyTorch 的 CPU/GPU 性能差距到底多大

环境搭好后，最好做个快速验证。我拿一台笔记本上的 RTX 3060 Laptop 做测试，写一个非常简单的 PyTorch 训练脚本，看一张图片在 CPU 和 GPU 上前向传播加反向传播的耗时差异：

import torch import torch.nn as nn import time device_cpu = torch.device("cpu") device_gpu = torch.device("cuda" if torch.cuda.is_available() else "cpu") model = nn.Sequential( nn.Conv2d(3, 64, kernel_size=3, padding=1), nn.ReLU(), nn.Conv2d(64, 128, kernel_size=3, padding=1), nn.ReLU(), nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Linear(128, 10) ).to(device_gpu) input_data = torch.randn(64, 3, 224, 224).to(device_gpu) # GPU 预热 for _ in range(10): model(input_data) # GPU 计时 start = time.time() for _ in range(50): out = model(input_data) loss = out.sum() loss.backward() gpu_time = time.time() - start # CPU 计时 model_cpu = model.to(device_cpu) input_cpu = input_data.to(device_cpu) start = time.time() for _ in range(5): out = model_cpu(input_cpu) loss = out.sum() loss.backward() cpu_time = time.time() - start print(f"GPU time: {gpu_time:.2f}s for 50 iters") print(f"CPU time: {cpu_time:.2f}s for 5 iters") print(f"torch.cuda.is_available(): {torch.cuda.is_available()}")

运行结果大致是 GPU 跑 50 次迭代不到 2 秒，CPU 跑 5 次迭代要 20 多秒。当然这个模型很小，数据也不真实，但它能确凿证明 CUDA 确实在正常工作，而且比 CPU 快了不止一个量级。我第一次跑通这个测试的时候，对比了同一块显卡在原生 Ubuntu 下的成绩，WSL2 的差距可以忽略。

4. 常见问题与排查实录

4.1 安装启动类问题速查

WSL2 从安装到使用，我踩过不少坑，也帮同事排过不少雷，整理成表格给各位直接对号入座。

这里要额外强调一点：如果你用的是 Win11，Windows 更新到某个大版本后偶尔会出现 WSL 服务异常，执行wsl --shutdown再重新进入，或者彻底重启电脑，能解决八成问题。WSL2 毕竟是系统和 Hyper-V 层的服务，稳定性和 Windows 更新质量强绑定，遇到异常别急着重装系统，先做简单的“重启大法”。

4.2 CUDA 和 GPU 识别类问题速查

这一块是所有人最容易卡住的地方，我把高频问题集中列出来。

• nvidia-smi命令找不到：检查/usr/lib/wsl/lib是否存在，确认 Windows 驱动版本较新，重新启动 WSL2。要记得把该目录加入 PATH。
• nvidia-smi显示“No devices were found”：最常见原因是 Windows 侧驱动不支持 WSL2，或者驱动安装不完整。去 NVIDIA 官网下载最新驱动，安装时选择“自定义安装”并勾选“执行清洁安装”。
• PyTorch 报 “CUDA driver version is insufficient for CUDA runtime version”：驱动太旧，升级 Windows 侧 NVIDIA 驱动即可。
• 报错libcuda.so.1: cannot open shared object file：动态库路径没配置好，确认/usr/lib/wsl/lib在LD_LIBRARY_PATH中。
• torch.cuda.is_available()返回False：首先确认nvidia-smi正常；其次检查当前 Python 环境里是否通过 pip 安装了正确版本的 PyTorch，方法是在 Python 里执行：

import torch print(torch.version.cuda) print(torch.backends.cudnn.version())

如果输出版本号却仍然检测不到 GPU，很可能是系统里混装了 Ubuntu 的nvidia-cuda-toolkit包污染了环境，建议卸载：

sudo apt remove nvidia-cuda-toolkit

这是我在 Ubuntu 上跑 PyTorch 时踩过的最大一个坑。Ubuntu 仓库里自带一个老版本 CUDA 工具包，如果你手滑apt install nvidia-cuda-toolkit过，即使后续用 pip 装了新版 PyTorch，系统里的旧 CUDA 也会让torch.cuda.is_available()返回 False。

4.3 资源与文件系统问题：内存、磁盘、IO 速度

跑 AI 工作负载时，WSL2 吃内存、占磁盘的问题会很快暴露。

内存不足：WSL2 默认情况下最多使用物理内存的 50%，但跑大模型时依然可能不够。解决方案是在 Windows 用户目录（C:\Users\你的用户名）下新建一个.wslconfig文件，内容示例如下：

[wsl2] memory=8GB processors=4 swap=8GB localhostForwarding=true

保存后执行wsl --shutdown，再启动 WSL2 生效。注意分配的内存不要超过物理内存的一半左右，否则 Windows 宿主会非常卡。

vhdx 虚拟磁盘膨胀：WSL2 的磁盘文件只增不减，即使你删掉了大量文件，虚拟磁盘也未必自动缩水。压缩方法如下：

wsl --shutdown diskpart

然后在 diskpart 里执行：

select vhd file=你的安装路径\ext4.vhdx compact vhd detach vhd exit

这个操作可以将虚拟磁盘中空闲的部分回收，效果立竿见影。

IO 速度差异：这是 WSL2 最容易让人产生“电脑变慢”错觉的地方。如果你把训练数据集放在 Windows 盘符下，比如/mnt/c/data，WSL2 访问这些文件走的是 9P 文件协议，读写性能远不如 ext4 文件系统。模型训练要频繁读小文件，这种损耗会被放大到难以容忍的程度。我的经验是：所有数据、代码、虚拟环境，都放在 Linux 文件系统里，也就是默认的家目录下，不要把大项目塞在/mnt/c里。Windows 侧的文件只做交换用途，比如最终成果复制出去。

4.4 网络与远程访问的几个小坑

WSL2 默认走 NAT 网络，WSL2 内的服务可以用localhost直接从 Windows 访问，这条链路是微软默认配置好的，一般不用额外设置。

但有一个场景会踩坑：你想让局域网内其他设备（比如手机或者另一台电脑）访问 WSL2 里的服务。由于 WSL2 的 IP 是 NAT 分配的，局域网设备访问不到，需要在 PowerShell 里做一个端口转发：

netsh interface portproxy add v4tov4 listenport=8000 listenaddress=0.0.0.0 connectport=8000 connectaddress=127.0.0.1

然后再放行 Windows 防火墙对应端口。这一套操作在 Windows 上开发模型服务接口、给同事演示 demo 时非常实用。公司网络环境里如果设了代理，WSL2 内访问外网可能超时，可以通过设置环境变量解决：

export http_proxy="http://你的代理地址:端口" export https_proxy="http://你的代理地址:端口"

需要说明的是这属于企业内部标准代理配置，和任何非正规上网手段无关，纯属正规网络环境下的常见调试。

5. 搓一套顺手的工作流：日常开发与稳定运行心得

5.1 用 .wslconfig 给资源上锁

WSL2 跑 AI 任务时，内存占用是动态调整的，有时候你会发现Vmmem进程把系统内存吃满了，Windows 本身反而卡顿。不要慌，这是 WSL2 的内存缓存策略在起作用，它把空闲内存拿去做文件缓存了，等 Windows 需要时会自动释放。如果实在觉得不舒服，就在.wslconfig里明确限制资源上限：

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

另外新版 WSL 支持autoMemoryReclaim配置，可以在休眠或空闲时自动回收内存：

[wsl2] autoMemoryReclaim=gradual

实测定下来，开启这个选项后，Vmmem 的内存占用会有明显下降。建议用大型模型时限制 memory，给 Windows 留出至少 4GB 以上的余量。

5.2 开发工具链的组合搭配

我目前最顺手的组合是：Windows 终端 + VS Code Remote-WSL + WSL2 内的原生 Docker + 容器内跑 PyTorch。

VS Code 的 Remote-WSL 插件是这一套体验的灵魂。装好之后，打开 VS Code 按F1输入 “Remote-WSL: Reopen Folder in WSL”，就能直接在 WSL2 环境里编辑代码、打开终端、调 GPU 资源，整个过程无感。调试体验和本地开发几乎一模一样，但代码执行环境已经是真正的 Linux。

日常跑模型推理我还会用 Ollama 在 WSL2 里跑本地大模型，安装极简单：

curl -fsSL https://ollama.com/install.sh | sh ollama run llama3.2

它自动识别 WSL2 的 GPU 环境，无需额外配置。跑起来后从 Windows 浏览器访问localhost:11434就能调 OpenAI 兼容的接口，做本地应用原型非常方便。

关于代码位置，我还是要再唠叨一次：代码仓库和虚拟环境一定要放在 Linux 文件系统里。我见过太多人把项目放在 D 盘再用/mnt/d访问，训练数据一大，IO 延迟会让你以为显卡坏了。VS Code 打开 WSL2 里的目录，Windows 侧根本不用存代码副本。

5.3 我个人建议的环境刻度和避坑清单

用这么久的 WSL2 做 AI 开发，基于我的真实体验，汇总几条个人认为价值最高的建议：

• 首选组合：WSL2 + Ubuntu 24.04 + 原生 Docker Engine + 容器内 CUDA 环境 + venv 管 Python 包。
• 只跑 PyTorch/TensorFlow 就别在系统层装 CUDA Toolkit，让框架自带 CUDA 运行时，能省掉无数版本冲突的烦恼。
• Windows 侧显卡驱动务必保持较新版本，NVIDIA 对 WSL2 的优化一直在推进，新驱动对新的 CUDA 版本兼容性也更好。
• 不要频繁开关 WSL2，内存资源紧张时用wsl --shutdown释放，平时让它运行稳定避免 Vmmem 抖动。
• 养成定期清理容器和镜像的习惯，跑实验多了 Docker 占用的虚拟磁盘会非常大，配合 vhdx compact 让磁盘空间回来。
• WSL 内核保持更新，每个 Windows 大版本更新后都检查一下wsl --update，内核会修复大量边界问题。

我个人在实际操作中还有一个很深的感觉：WSL2 最大的价值不是“在 Windows 里能跑 Linux”，而是把“开发环境”和“日常办公环境”之间的隔离墙打碎了。以前开双系统，切一下要重启、要重新打开所有软件，人的思路会被打断好几次；现在模型在后台训练，我可以切到 Windows 写文档、回消息、看数据，两边并行不悖。这种体验上的提升，比单看基准测试性能数字还要值钱。

如果你正准备入坑 WSL2 跑 AI，希望这篇记录能帮你把雷提前排掉。从安装到 GPU 直通，再到容器化训练，每一步背后其实都有一套成体系的工程逻辑。照着上面的路径走，你应该很快就能在 Windows 上跑起自己的第一个 GPU 训练任务。