WSL2 GPU直通实战：从零搭建Windows下的AI开发环境

如果你和我一样主力机用 Windows却要天天和 PyTorch、CUDA、命令行、模型训练打交道那你大概率经历过这种撕裂感Windows 上能装环境、能跑小 demo可一旦要跑训练脚本、编译自定义算子、搞分布式或者直接照着一份带 bash 的项目 README 操作Windows 就开始各种不配合。过去两年多我的主力 AI 开发环境一直住在 WSL2 里——日常办公留在 Windows训练和推理全部在 WSL2 中完成两边共享文件GPU 照常调用。这篇文章就把我这套环境的完整搭建过程、GPU 直通的底层原理、CUDA 配置细节以及我踩过的坑全部梳理出来。文章面向两类人一类是刚接触 WSL2、想在 Windows 上正经跑 AI 项目的开发者另一类是已经在用 WSL2但 GPU 直通或性能始终没调明白的人。内容按实际搭建顺序展开从零开始每步都会说清楚为什么这么做以及不做会有什么后果。1. 为什么是 WSL2从“翻译层兼容”到“内核级 Linux”1.1 WSL1 与 WSL2 的本质差异不只是换个版本号很多人以为 WSL2 只是 WSL1 的“性能加强版”这个理解会直接影响你后面排查问题的思路。WSL1 本质上是一个系统调用翻译层它把 Linux 程序发出来的系统调用“实时翻译”成 Windows NT 内核能理解的操作。好处是启动快、文件访问原生坏处是翻译总有不完整的地方——比如某些 Linux 内核特有的功能、需要内核模块配合的场景WSL1 根本无法兼容。WSL2 直接把这个问题连根拔起它不再翻译而是用一个轻量级虚拟机在 Hyper-V 虚拟化平台上跑一个微软自己维护的 Linux 内核。对 AI 开发来说这个改变是决定性的真正的 Linux 内核意味着 Docker 能跑、CUDA 能跑、内核级特性能用Linux 生态里的东西基本都能搬进来。标题里说的“内核级 Linux”指的是这一层而不是某个发行版名称。用生活化类比WSL1 像一个同声传译你说德语他翻译成英语但遇到文化梗可能翻不动WSL2 则是直接把一个德国人请到了你家里他说德语你也听得懂交流中的损耗降到最低。AI 工具链几乎全是 Linux 优先在 WSL2 里跑就是“原住民”待遇。1.2 “GPU 直通”三个字其实没那么简单标题里的“GPU 直通”需要先说清楚边界。严格的 PCIe 直通是把物理显卡整个分配给虚拟机独占那种方案配置复杂而且本质上只在一台机器上跑一个 VM 时才划算。WSL2 的 GPU 机制不是这种它更像“GPU 半虚拟化转发”具体链路是Windows 侧安装 NVIDIA 官方驱动驱动通过 WDDM 2.9 接口暴露 GPU 能力WSL2 内核中启用了/dev/dxg设备节点负责把 Linux 侧发来的 GPU 请求转发到 Windows 驱动栈NVIDIA 为 WSL 专门提供了 CUDA 用户态适配层让 Linux 程序以为自己在原生 Linux 下跑实际上底层是 Windows 驱动在工作。对开发者来说最终体验就是在 WSL2 里nvidia-smi能看到显卡和显存PyTorch 里torch.cuda.is_available()返回 True训练照常跑。虽然称不上物理级直通但实际使用中不是瓶颈。我一开始也怀疑这套转发层性能损耗大后面的实测告诉我GPU 密集型任务损耗小到基本可以忽略。1.3 先划清边界WSL2 适合做什么不适合做什么任何工具都有适用边界WSL2 也一样。我基于实际使用体验做了一个梳理场景是否适合原因模型训练适合CUDA、显存管理、多进程训练都能正常工作推理服务开发适合FastAPI 等服务端程序在真实 Linux 内核上跑行为与生产一致分布式多机训练较适合单机多卡没问题多机需要网络协商NAT 模式稍有额外配置需要加载自定义内核模块不适合WSL2 内核由微软维护自定义模块不一定能装长时间满载生产环境不建议毕竟底子是虚拟化稳定性依赖 Windows 宿主直接操作物理 GPU 硬编码不适合无法做完整 PCIe 设备透传说白了WSL2 最适合的定位是“开发环境”——你在上面写代码、调模型、做实验跑通了再部署到真正的 Linux 服务器或云端。搞清楚这层定位后面很多纠结自然就放下了不需要神化它也用不着因为一次虚拟化报错就全盘否定。2. 安装前的硬件确认BIOS 虚拟化、系统版本和内存余量2.1 先确认硬件和系统版本别等装一半才报错我第一次装 WSL2 时吭哧吭哧运行wsl --install结果重启后直接告诉我“WSL2 无法启动因为此计算机上未启用虚拟化”。当时一头雾水后来才明白是主板 BIOS 里虚拟化开关没开。这类错误其实完全可以提前规避。安装前先确认三件事Windows 版本。Windows 10 21H2 以上或 Windows 11 都行Windows 11 对 WSL2 的维护更积极很多新特性都先给 Win11。打开“设置 - 系统 - 系统信息”即可查看版本号。CPU 虚拟化。Intel CPU 需要 VT-xAMD CPU 需要 SVM。可以在任务管理器“性能”标签里查看“虚拟化”选项是否为“已启用”。内存与磁盘。基础门槛 8GB 内存能跑起来但 AI 开发建议 16GB 起步磁盘至少留 20GB 给 Linux 发行版还要考虑模型和数据集动不动几个 GB 的情况。另外如果机器上装了老版本的 VMware Workstation、VirtualBox 等虚拟机软件它们和 Windows 的虚拟化平台可能冲突。不是不能用但排查问题时要把这些变量考虑进去。2.2 一条命令装完 Ubuntuwsl --install与wsl --update最省事的方式是用管理员身份打开 PowerShell执行wsl --install -d Ubuntu-24.04这条命令会自动完成三件事安装 WSL2 的核心组件、启用虚拟化平台功能、从在线商店拉取 Ubuntu 24.04 镜像。首次执行后通常提示重启重启后再打开终端会进入 Ubuntu 初始化流程设置一个 Linux 用户名和密码。我在实际环境里遇到过wsl --install只装了 WSL 而没有发行版的情况这是因为早期版本命令行为不同。补救很简单直接运行wsl --install -d Ubuntu-24.04指定发行版即可。装完后第一步建议先在 PowerShell 里执行wsl --update这一步把 WSL 内核和用户态组件更新到最新版本。很多莫名其妙的 Bug比如镜像网络模式不可用、systemd 无法启动都是因为 WSL 本身版本太旧。更新之后再看问题往往就消失了。2.3 两个高频报错虚拟化未启用 与 “WSL2 尚未准备就绪”这两个报错我身边同事几乎都遇到过分开说。第一个是开篇提到的“WSL2 无法启动因为此计算机上未启用虚拟化”。处理方式进入 BIOS开机时按 Del 或 F2 键找到SVM ModeAMD或Intel Virtualization Technology设为 Enabled保存重启。重启后如果还报错去“启用或关闭 Windows 功能”里确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”两项都已勾选必要时再重启一次。第二个是“WSL2 尚未准备就绪”。这个报错通常是 WSL2 内核组件缺失导致的。Windows 功能里勾上了但内核更新包没装或 WSL 版本太旧。解决方式就是上面说的wsl --update它会自动补上内核。如果更新命令失败可以手动下载微软官方的 WSL 内核更新安装包安装后再启动。整个链路排查思路是BIOS 开关 - Windows 可选功能 - WSL 内核包 - WSL 版本按这个顺序来就不会乱。2.4 下载慢和 C 盘空间焦虑离线安装包与迁移 D 盘“wsl2 下载慢”是个热门问题其实原因是发行版镜像默认从微软商店或微软 CDN 拉取网络高峰时期速度确实感人。我的处理方式分两种情况如果只是速度慢可以稍等重试或直接在 Microsoft Store 搜索 Ubuntu 24.04 手动安装。Store 会走自己的下载链路有时候反而更快。如果连 Store 都打不开可以从 Ubuntu 官网下载 WSL 用的 rootfs 或 appx 格式离线包然后在 PowerShell 里用Add-AppxPackage安装。这个方式可控性最高适合网络环境受限的机器。更头疼的是 C 盘空间。WSL2 默认把虚拟磁盘放在 C 盘用户目录下时间一长加上模型文件几百 GB 说满就满。想迁移到 D 盘最稳妥的是wsl --export和wsl --import组合wsl --export Ubuntu-24.04 D:\backup\ubuntu-wsl.tar wsl --unregister Ubuntu-24.04 wsl --import Ubuntu-24.04 D:\WSL\Ubuntu-24.04 D:\backup\ubuntu-wsl.tar这里有个容易忽略的细节--import导入后默认登陆用户会变成 root而不是你之前设置的普通用户。解决方式是在 WSL 内编辑/etc/wsl.conf[user] default你的用户名改完执行wsl --shutdown重启 WSL再进就是正常用户了。导入后的系统、软件包、Python 环境全部原样保留不需要重装。3. 初始配置软件源、终端、文件互通与 systemd3.1 换软件源否则apt install速度会让你崩溃Ubuntu 默认软件源指向国外服务器在本地环境下apt update慢得让人以为网络坏了。装完系统第一件事就是把 apt 源换成国内镜像源。我习惯用清华镜像源只改 Ubuntu 24.04 的主源示例写法sudo sed -i s/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list.d/ubuntu.sources sudo apt update不同版本的 Ubuntu 源文件位置略有差异22.04 及更早版本通常是/etc/apt/sources.list24.04 改成了/etc/apt/sources.list.d/ubuntu.sources。改完源再装任何软件都顺畅很多。这一步不涉及任何特殊网络手段就是走国家法定可用的镜像服务。3.2 Windows Terminal SSH让 WSL 用起来像个正经开发机WSL2 默认用 Windows Terminal 承载强烈建议直接装 Windows Terminal如果 Windows 11 自带就更好了然后把它默认配置文件设置为 WSL 发行版。这样做的好处是命令行体验完整支持多标签页、主题、真彩色还能直接阅读 Linux 路径下的文件。我还会顺手配一个 SSH 服务原因很简单有时候 Windows 本机不方便操作要远程连进来看训练进度。配置方式sudo apt install openssh-server sudo systemctl enable ssh sudo systemctl start ssh虽然 WSL2 的默认网络模式是 NAT但本机回环访问 localhost 通常没问题局域网远程访问需要进一步处理网络模式后面专门说。在 Windows 上直接用ssh 用户名localhost就能连进 WSL这个在日常调试里非常方便不用来回开终端。3.3/mnt/c的性能陷阱与正确的路径规划WSL2 里可以通过/mnt/c访问 Windows 的 C 盘但这是通过 9P 协议实现的性能比 WSL 内部的 Linux 文件系统差很多。尤其是大量小文件读写时速度差距能达到数倍。很多人把 Python 环境、数据集放在C:\workspace然后在 WSL 里通过/mnt/c/workspace跑训练结果发现慢得离谱还以为是 WSL2 的锅。正确的路径规划是项目代码、虚拟环境、模型缓存全部放进 WSL 内部的 Linux 文件系统比如~/projects、~/.cacheWindows 侧的 VS Code 通过\\wsl$\Ubuntu-24.04\home\用户名\projects这个 UNC 路径直接访问编辑体验和本地无所差别数据文件、大模型权重放在 Windows 侧做长期存储但训练时先复制进 WSL 的文件系统再读速度反而更快。这个习惯我在无数次被/mnt/c拖慢后彻底养成了。记住一句话能在 WSL 文件系统里放的东西就不要放/mnt/c。3.4 systemd 与.wslconfig让 WSL 成为一台“完整”的实验机WSL2 早期不支持 systemd导致很多依赖 systemctl 的服务跑不起来。现在较新版本已经默认启用 systemd如果你用的镜像比较保守可以在/etc/wsl.conf里手动开启[boot] systemdtrue开启后Docker、SSH、vllm 这类服务都可以用systemctl管理这算是 WSL2 向“完整 Linux 开发机”看齐的关键一步。如果你只是跑 Python 脚本这一步可以跳过但做 AI 服务开发和容器化部署时systemd 几乎必备。Windows 侧还有一个配置文件.wslconfig放在用户主目录例如C:\Users\你的用户名\.wslconfig用于限制 WSL2 的资源占用。我最常用的配置[wsl2] memory16GB processors8 swap8GB networkingModemirroredmemory控制 WSL 最多能用多少内存processors限制核数networkingModemirrored则是后面要重点讲的镜像网络模式它能让局域网设备直接访问 WSL 里的服务。配置完执行wsl --shutdown重启 WSL 生效。4. GPU 直通的落地实操驱动分工、CUDA 与验证4.1 先弄懂分工Windows 装驱动WSL 内部不装驱动这是最容易搞反的一步。很多人在 WSL 里执行sudo apt install nvidia-driver-470之类命令最后系统直接黑屏或启动失败原因就是 WSL2 不需要、也不应该安装 Linux 侧的显卡驱动。因为 GPU 转发走的 Windows 驱动栈Linux 内核只是把请求转发出去真正的渲染和计算发生在 Windows 驱动层。所以正确分工是Windows 侧安装 NVIDIA Studio 驱动或 Game Ready 驱动版本不要太老最好保持最新WSL2 内部只安装 CUDA Toolkit不需要安装任何 NVIDIA 驱动包WSL2 内核自带/dev/dxg和 NVIDIA 相关内核模块不需要手动加载。这个概念想通之后整个 GPU 配置就会非常顺畅。安装 CUDA 时不要再搜“Linux 驱动安装方式”要去 NVIDIA 官方文档里找 WSL 专用的安装入口。4.2 安装 CUDA Toolkit on WSL官方仓库的完整命令进入 WSL执行以下命令安装 CUDA Toolkit 12.4这是目前兼容性最稳的版本之一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注意这里的源是wsl-ubuntu不是普通 Ubuntu 的linux源。如果你装成普通 Ubuntu 的 deb 源会在 apt 里引入真正的 Linux 驱动项容易造成混乱。为了稳妥我需要说明以上路径是 NVIDIA 官方提供的 WSL 专用源适合在 WSL2 内部使用大家从项目正文里也能看到这是基于官方实践的标准做法。安装完成后把 CUDA 工具目录加入环境变量echo export PATH/usr/local/cuda/bin:$PATH ~/.bashrc echo export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH ~/.bashrc source ~/.bashrc我习惯同时加好PATH和LD_LIBRARY_PATH否则后续编译torch扩展或调用nvcc时会找不到命令。这里的版本号可以按需调整CUDA 11.8、12.1、12.6 都支持 WSL但建议跟随 PyTorch 官方稳定组合来选择。4.3 验证 GPU 真的在用nvidia-smi与 PyTorch 探测装完第一件事执行nvidia-smi正常情况下会输出显卡型号、Windows 侧驱动版本、显存容量。此时你看到的驱动版本是 Windows 驱动映射出来的并不是 WSL 里安装的这再次印证了上面的机制。接下来进入 Python 验证完整链路import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出True和显卡名称说明 CUDA 栈彻底打通。再跑一个简单的矩阵乘法import torch a torch.randn(4096, 4096, devicecuda) b torch.randn(4096, 4096, devicecuda) c a b print(c.shape)这个测试的意义不在于性能而在于确认显存分配和计算调度都能正常工作。第一次跑通这个基本可以宣告 GPU 直通环境就绪了。4.4 双显卡、多 GPU 与显存释放细节笔记本双显卡场景下WSL2 会自动识别 NVIDIA 独显不需要额外设置但要注意 Windows 侧把 NVIDIA 设为 3D 首选 GPU否则部分负载会落在集显上。如果你有多个 NVIDIA GPU同样可以使用CUDA_VISIBLE_DEVICES0,1环境变量控制可见设备这个在 WSL2 内和原生 Linux 完全一致。我常在大显存推理时只暴露一块卡CUDA_VISIBLE_DEVICES0 python train.py显存不释放是另一个高频问题。WSL2 里跑崩了训练脚本nvidia-smi看到的显存仍然被占用很可能是残留的 Python 进程没死透。排查方式ps aux | grep python sudo kill -9 pid如果怎么都找不到进程又确认显存占用异常直接wsl --shutdown重启 WSL 环境最有效。这个操作会同时清理所有残留进程和显存状态代价是要重新启动环境所以适合在非训练时间做。5. AI 开发环境Python、PyTorch、工具链与路径约定5.1 用 Miniconda 管理 Python 环境省心省事WSL2 里管理 Python 环境我首推 Miniconda。系统自带 Python 是 3.12但 AI 生态里很多老项目只兼容 3.8-3.10靠 conda 建独立环境最不折腾。安装命令wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh source ~/.bashrcConda 的默认源同样可以换成清华镜像这一步能大幅提升创建环境的速度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/ conda config --set show_channel_urls yes创建环境示例conda create -n py311 python3.11 -y conda activate py311在py311环境内再做 PyTorch 安装互不污染。我试过直接拿系统 Python 裸装 PyTorch也能用但一旦项目冲突出现环境依赖问题处理成本远高于一开始就用 conda。5.2 装 PyTorch 时最容易搞错的 CUDA 版本匹配PyTorch 安装命令里cu121、cu124这类标签必须和上面安装的 CUDA Toolkit 版本对齐否则会出现“驱动能识别但 PyTorch 不认”的诡异现象。以 CUDA 12.1 为例pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121或者用 conda 方式conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia我自己的经验是先定 PyTorch 需要的 CUDA 版本再回过去装对应 CUDA Toolkit。因为 PyTorch 每年发布频率固定版本依赖关系更明确。如果你安装的 CUDA Toolkit 是 12.4但 PyTorch 选了 cu121多数情况下也能跑因为 CUDA 库对旧版本保持兼容但反过来如果 Toolkit 特别新、PyTorch 版本老就可能出现运行时找不到符号的报错。验证 PyTorch CUDA 状态的方法就是上面那一段torch.cuda.is_available()。补充一个小细节如果 import torch 时提示libcuda.so找不到检查LD_LIBRARY_PATH是否包含/usr/local/cuda/lib64。这个环境变量在 WSL2 的镜像网络模式下尤其重要因为某些服务进程继承的环境可能不完整。5.3 开发工具链VS Code、PyCharm、Jupyter 的对接日常编码我主要用 VS Code。装一个 Remote - WSL 扩展然后通过code .在 WSL 目录中打开体验上完全像是在 Linux 里开发终端自动进入 WSL调试器直接连到 Linux 进程文件路径也是 Linux 路径。这比在 Windows 侧直接编辑/mnt/c文件要舒服得多更重要的是调试时能直接看见 WSL 里 Python 解释器的包环境。PyCharm 专业版和社区版同样支持远程解释器。在 PyCharm 中设置解释器时选择 WSL 路径下的 Python例如/home/ubuntu/miniconda3/envs/py311/bin/python选择完就能像本地开发一样运行和调试。Jupyter 用起来也很顺手WSL 里执行jupyter notebook --port8888然后在 Windows 浏览器访问http://localhost:8888。WSL2 默认会把 localhost 端口转发到 Windows这条链路基本是通着的。如果端口被占用或转发失效重启一下 WSL 网络即可。5.4 数据集、模型缓存和日志的路径约定养成路径统一的好习惯能帮你节省大量排错时间。我现在的约定是项目代码放~/projects/项目名数据集放~/datasets/Hugging Face 模型缓存自动落在~/.cache/huggingface/训练日志放~/logs/虚拟环境全部由 conda 管理不手动 pip install 到系统环境。这样做的底层原因是文件 IO 性能差异。上面说过/mnt/c慢而 WSL 内部文件系统很快。把数据集放在~/datasets里训练时的数据读取瓶颈就只在 CPU 和磁盘本身而不是协议转发。对大规模数据加载这么做甚至能肉眼可见地缩短每个 epoch 的时间。另外如果要把这些数据备份到 Windows 侧直接通过资源管理器访问\\wsl$\Ubuntu-24.04\home\你的用户名\复制出来就行不需要在 WSL 里把文件再挪到/mnt/c再做备份少走一层中转。6. 性能实测与避坑记录和原生 Linux 到底差多少6.1 我实测过的性能GPU 调用几乎无损瓶颈在 IO 和网络先说结论GPU 密集型训练和推理任务WSL2 和原生 Ubuntu 的性能差距非常小。我在同一台机器上分别用原生 Ubuntu 和 WSL2 跑了 ResNet50 的训练脚本损失曲线基本重合单轮 epoch 时间差距在 3%-8% 之间主要来自数据加载和随机抖动不是 GPU 算力本身。原因也不难理解模型的正向传播、反向传播、CUDA 内核启动都在 Windows 驱动栈上执行GPU 层面没有二次虚拟化。WSL2 的转发层只负责把 Linux 侧的请求桥接到驱动上它不是把 CUDA 计算变成两条额外路径所以计算密集型任务损耗有限。真正需要留意的是 IO。小文件大量读写时WSL 内部 ext4 和/mnt/c9P 协议的差距可以拉到 3-5 倍。所以正确放置项目和数据比调任何 WSL 参数都有效。网络方面默认 NAT 模式下 WSL2 访问外网没问题但外部设备访问 WSL 里的服务就需要端口转发。Windows 11 22H2 以后可以在.wslconfig里开启networkingModemirrored让 WSL 直接共享宿主机网络接口局域网里的其他设备就能直接用 Windows 的 IP 访问训练服务了局域网调试模型服务会方便很多。6.2 WSL2 日常使用里最折磨人的五个坑坑一显存不释放。训练脚本崩溃或手动中断后nvidia-smi看到显存依然被占。先找残留的 Python 进程找不到就wsl --shutdown别死磕。坑二内存回收慢。Windows 任务管理器里vmmem占用几十 GB这是 WSL 文件页缓存的正常表现不是内存泄漏。如果影响日常使用调小.wslconfig里的memory值或者定期重启 WSL。坑三Docker 无法启动。WSL2 里的 Docker 需要 systemd 或手动启动 Docker daemon。开启 systemd 之后执行sudo systemctl enable docker --now就能稳定运行。用 Docker Desktop 也可以但资源占用明显更大。坑四休眠后 GPU 异常。笔记本合盖休眠再唤醒后WSL 里nvidia-smi可能报错或卡住。这不是环境坏了是 Windows 驱动重新初始化导致的。执行wsl --shutdown再启动基本都能恢复。坑五时钟漂移。虚拟机长时间运行后WSL 内时间可能和实际时间漂移影响训练日志的时间戳和 HTTPS 请求。可以临时用sudo ntpdate ntp.ubuntu.com校正长期使用建议在 crontab 里定时同步。6.3 VHD 磁盘只增不减压缩、备份与迁移WSL2 的虚拟磁盘文件ext4.vhdx会随使用不断增大删除 WSL 内的大文件后磁盘镜像不会自动缩小。这在长期做 AI 开发、频繁装大模型包后非常明显WSL 内df -h显示一切正常但 Windows C 盘空间却在悄悄减少。压缩方式先wsl --shutdown然后在管理员 PowerShell 中对 vhdx 文件做 compact 操作diskpart select vdisk fileC:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_...\LocalState\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk注意 vhdx 路径会因为发行版和安装方式不同而不同在文件资源管理器里搜索 ext4.vhdx 即可定位。备份方式更简单wsl --export出一条 tar 把整个系统封装起来这个 tar 可以放到移动硬盘或 D 盘归档。恢复时用wsl --import并在/etc/wsl.conf里重设默认用户即可。这个组合方案同时解决了备份、迁移、重置三个问题是我最推荐的做法。结尾我的体悟和建议把这套环境从零搭到顺手我花了大概一个周末后面所有的训练和推理都转移了过来。如果只让我分享一条最重要的经验那就是WSL2 里跑 AI 开发把项目和数据集都放进 Linux 文件系统性能比你想象中快得多遇见任何 GPU 相关怪问题先wsl --shutdown再启动能解决一半的烦恼。另外别纠结“GPU 直通到底是不是真直通”。只要nvidia-smi能显示显卡、PyTorch 能调用 CUDA、训练曲线和原生 Linux 一致这套环境就是可用的。后面我打算在 WSL2 里继续折腾 AI Agent 开发把 LangChain 和 vLLM 的部署流程也一并沉淀成环境配置让这套开发机继续承担更多工作。