企业官网建设流程全解析

标题里写的是"ubantu"，实际应该叫 Ubuntu，这是很多新手都会拼错的词。先把这个小问题说清楚，因为后面所有的命令和路径依赖的都是正确的拼写。这篇文章我打算完整记录一遍在 Windows 上通过 WSL 安装 Ubuntu、再配置 CUDA 的整个流程，包括我踩过的坑、验证过的命令、还有那些网上教程里没写清楚的细节。WSL 的全称是 Windows Subsystem for Linux，它让你直接在 Windows 里跑一个 Linux 发行版，而 CUDA 则是让 NVIDIA 显卡参与计算的核心工具。这条链路配好之后，你的 Windows 机器就能变成一台能跑 PyTorch、能训练深度学习模型的 Linux 开发机，而且不用装双系统、不用重启切换。如果你是第一次接触 WSL，或者之前尝试配置 CUDA 一直没成功，这篇文章应该能帮到你。

1. 为什么我推荐在 Windows 上用 WSL 搭 CUDA 环境

1.1 WSL 到底解决了我什么问题

以前想在 Windows 上做深度学习开发，思路基本只有两条：装双系统，或者用虚拟机。双系统的痛点很明显，重启切换一次要一两分钟，两个系统里的文件互传麻烦，Windows 日常用的软件切过去就用不了了。虚拟机的痛点更致命，性能损耗太大，尤其是 GPU 加速部分，在 VirtualBox 里跑一个小模型都能明显感觉到卡顿，做深度学习基本是灾难。

WSL 的出现把这两个问题同时解决了。WSL2 的实现本质上是一个轻量级虚拟机，但它和传统虚拟机的最大区别在于：微软和 NVIDIA 一起做了 GPU 的半虚拟化透传。你在 WSL 里跑 CUDA 程序时，调用的是 Windows 侧安装的 NVIDIA 驱动，所以性能损耗非常小。我用一台搭载 RTX 4060 Ti 的机器实测，WSL 里跑 PyTorch 训练，和原生 Linux 相比几乎没有可见差距。

还有一点被很多人低估的是文件系统互通。Windows 的 Explorer 可以直接访问\\wsl$\Ubuntu路径下的 Linux 文件，WSL 里也可以直接操作/mnt/c/下的 Windows 文件。这意味着你可以在 Windows 上用 VSCode 写代码，在 WSL 里跑训练，两边切换零成本。这种体验，双系统和传统虚拟机都给不了。

1.2 和双系统、原生 Windows 环境相比怎么选

很多开源深度学习项目的官方文档只提供 Linux 版的安装命令，比如apt-get install这类，在 Windows 原生环境里没法直接执行，要么找 Windows 移植版，要么用 Docker。WSL 解决了这个尴尬：你能拿到一个和 Linux 服务器行为基本一致的开发环境，同时保留 Windows 作为日常桌面系统。

但 WSL 也不是万能的。如果你的目标是多卡集群训练、InfiniBand 互联、自定义内核模块，那还是需要真实的 Linux 物理机或服务器。另外 WSL2 的虚拟网卡不支持监听模式，所以涉及无线网卡抓包这类工作，WSL 也做不了。搞清楚这些边界，才不会在错误的方向上浪费时间。

1.3 这套方案最适合谁

最适合的人群就三类：主力系统是 Windows、但需要跑 Linux 环境的开发者；想用 NVIDIA GPU 跑 PyTorch、TensorFlow、Stable Diffusion 等框架但不想装双系统的人；以及需要调试只能在 Linux 下运行的库或工具的学生和工程师。反过来，如果你所有工作都已经在 Linux 服务器上完成，或者你完全不需要 Windows 侧的软件，那直接使用物理 Linux 更合适。

我自己的使用场景是：Windows 作为日常桌面，负责浏览器、办公、通讯；WSL 里装着一整套深度学习环境，负责代码训练、实验管理。两个环境的文件和剪贴板也可以共享，比如我经常在 Windows 上复制一张图片，直接粘贴到 WSL 里的代码路径下。这种混合工作流，用惯了以后很难再回到纯 Windows 或纯 Linux 的状态。

2. 从零开始装 WSL 与 Ubuntu

2.1 安装前必须确认的两件事

第一件事是 Windows 版本。WSL2 要求 Windows 10 版本 1903 以上（内部版本号 19041 以上）或 Windows 11。如果你的系统版本太老，先升级系统，因为老的 Windows 10 版本对 WSL2 的支持不完整，后续会出现各种诡异错误。

第二件事是 CPU 虚拟化。WSL2 依赖 Hyper-V 虚拟化平台，所以 BIOS 里的虚拟化开关必须打开。检查方法：打开任务管理器，切到"性能"选项卡，看左下角的"虚拟化"一栏。如果显示"已启用"，直接下一步；如果"已禁用"，需要重启进 BIOS 打开 Intel VT-x 或 AMD-V，这个选项通常在主板的 Advanced 或 CPU Configuration 菜单下。

安装 WSL 的命令非常简单，管理员身份的 PowerShell 或终端里执行：

wsl --install

这条命令会一次性完成三件事：开启"适用于 Linux 的 Windows 子系统"功能、开启"虚拟机平台"功能、下载并安装 WSL2 内核和默认的 Ubuntu 发行版。执行完根据提示重启电脑。这里有个小建议：Windows 11 用户如果没有特殊原因，直接用这个命令即可，不需要去 Microsoft Store 手动下载。

如果执行wsl --install报错，常见原因是系统组件存储损坏，这会牵涉到"wsl安装组件存储已损坏"这类错误。解决方法后面第 6 部分专门讲。

2.2 命令行安装的完整过程

重启后会弹出一个 Ubuntu 窗口，让你设置 Linux 系统内的用户名和密码。注意，这个用户名和 Windows 账号没有关系，是独立的 Linux 用户。设置完成后，Ubuntu 就已经可用。在 PowerShell 里执行：

wsl -l -v

会看到类似：

NAME STATE VERSION * Ubuntu Running 2

VERSION 一列必须是 2，如果你发现是 1，需要单独设置默认版本为 WSL2：

wsl --set-version Ubuntu 2

wsl --install默认安装的是最新 LTS 版 Ubuntu，目前是 24.04。如果你需要特定版本，比如 Ubuntu 22.04，可以先查看可用列表：

wsl --list --online

然后指定发行版安装：

wsl --install -d Ubuntu-22.04

我在实际项目里更倾向于用默认最新版，因为深度学习相关的预编译包对新版本 Ubuntu 的适配通常很快。但如果你在跑一些老项目，可能会有库依赖兼容问题，这时候固定老版本 LTS 反而更省心。

2.3 把 Ubuntu 装到 D 盘的正确姿势

wsl --install默认把发行版放在 C 盘的用户目录下，路径类似%LOCALAPPDATA%\Packages\...。一个完整的深度学习环境，装上 CUDA Toolkit、conda、PyTorch 和数据集缓存，轻松占据十几个 GB。如果你的 C 盘空间紧张，就需要把发行版迁移到其他盘。

迁移的标准做法是导出再导入，我操作过很多次，步骤如下：

# 1. 停止 Ubuntu 运行 wsl --terminate Ubuntu # 2. 导出当前系统到 tar 文件 wsl --export Ubuntu D:\wsl\ubuntu.tar # 3. 注销 C 盘里的原发行版（这步会删除原数据） wsl --unregister Ubuntu # 4. 导入到 D 盘指定目录 wsl --import Ubuntu D:\wsl\ubuntu D:\wsl\ubuntu.tar --version 2

导入完成后，默认会用 root 用户登录。如果你希望恢复成原来的普通用户，需要手动指定默认用户。在 PowerShell 里执行（这里假设你的用户名是 dev）：

ubuntu config --default-user dev

注意，如果安装的是 Ubuntu-22.04，那命令是ubuntu2204 config --default-user dev。不同的发行版对应的可执行文件名不同，可以用wsl -l -v的输出结合发行版文档来判断。迁移完成后，建议在 Ubuntu 终端里执行echo $HOME确认目录位置已经切换到 D 盘。

2.4 首次启动后的必备初始化

Ubuntu 启动后，第一件事是更新软件源和系统包：

sudo apt update sudo apt upgrade -y

然后设置 root 密码。虽然日常开发不推荐直接用 root，但总有用得上的场景。很多人在搜索栏里打"ubantu 切换 root"，指的就是切换 root 用户的操作：

sudo passwd root

输入你想要的 root 密码，之后执行su -就能切换到 root。注意，切换成功后终端提示符会从$变成#，这是快速判断当前用户身份的方法。我日常还是坚持用普通用户，仅在某次操作确实需要管理员权限时才临时切换。

接下来是所有国内用户的必修课：换源。Ubuntu 默认源archive.ubuntu.com在国内环境下更新速度极不稳定，我第一次装的时候apt update卡了十几分钟没进度，换源后几秒钟就完成索引。Ubuntu 24.04 的源配置文件路径是/etc/apt/sources.list.d/ubuntu.sources，老版本则是/etc/apt/sources.list，先确认再动手：

sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak sudo sed -i 's|http://archive.ubuntu.com|https://mirrors.tuna.tsinghua.edu.cn|g; s|https://archive.ubuntu.com|https://mirrors.tuna.tsinghua.edu.cn|g' /etc/apt/sources.list.d/ubuntu.sources sudo apt update

我习惯用清华源，稳定性和同步速度都靠谱。当然阿里云、中科大源也是常见的替代方案，选择哪个差异不大，关键是别用默认源。

3. Ubuntu 基础环境配置，打好地基

3.1 sudo 免密与用户权限管理

刚装完系统时，每次执行 sudo 都要输密码，深度学习开发中高频操作很多，来回输密码很影响效率。我建议把免密配置加上。编辑/etc/sudoers.d/下的配置文件：

echo "dev ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/dev

把dev替换成你的用户名。这样配置后，sudo apt install这类命令就不用再输入密码了。注意，这个配置只针对指定的用户，不影响系统的安全性。

还有一个我经常被人问到的点：如何让 WSL 启动时直接进入 root 用户。可以修改/etc/wsl.conf：

[user] default=root

改完执行wsl --terminate Ubuntu再重新进入就生效。但如前所述，我不建议长期用 root 写代码，权限太大会增加误操作的系统风险。

另外一个和权限相关的坑：如果你手动挂载过 Windows 盘符，可能会遇到文件权限错乱的问题。比如在/mnt/d下创建的文件在 Linux 侧看，权限可能全是drwxrwxrwx，这不影响读写，但在某些严格检查文件权限的编译场景会出问题。在/etc/wsl.conf里加一段可以缓解：

[automount] options = "metadata,umask=22,uid=1000,gid=1000"

这行让挂载的 Windows 卷带上元数据，权限行为更接近原生 Linux 文件系统。

3.2 换源后的工具链安装

换源完成后，建议立刻装几类基础工具。编译工具链是必须的，因为后面装 CUDA 和某些 Python 包时可能会触发源码编译：

sudo apt install -y build-essential cmake git curl wget

Python 环境我强烈建议用 miniconda 而不是系统自带的 Python。原因很现实：深度学习项目之间依赖冲突太频繁，conda 的虚拟环境隔离是刚需。从清华镜像下载安装脚本：

wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh

安装过程中提示是否执行conda init时选 yes，这样每次打开终端会自动激活 conda。装完后顺手配置 conda 的国内源：

conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --set show_channel_urls yes

这一步看似不起眼，但能让后面每次conda install都省下大把等待时间。我在帮别人排错时发现，很多人的 conda 环境装包特别慢或者频繁中断，根源就是没配源。

3.3 WSL 的内存与磁盘配置调优

WSL2 默认会占用宿主机约一半的内存，这个策略对深度学习开发来说偏保守。如果你只想跑轻量级任务，那默认配置没问题；但如果你计划训练大模型，建议手动调整。在 Windows 的用户目录下新建.wslconfig文件，写入：

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

改完执行wsl --shutdown再重新进入 WSL 生效。.wslconfig是全局配置，影响所有发行版。我自己的机器是 32GB 内存，给 WSL 分配 24GB，同时保留一部分给 Windows 的浏览器和日常软件，这样训练时两边都不卡。

磁盘方面有个容易忽略的问题：WSL2 的虚拟磁盘文件（ext4.vhdx）只增不减，你删了大量数据后磁盘空间并不会自动释放。长期做训练的人大概率会遇到这个烦恼，我每隔一段时间会做一次磁盘压缩。方法是关闭 WSL 后，在管理员 PowerShell 里运行 diskpart 工具：

diskpart select vdisk file="D:\wsl\ubuntu\ext4.vhdx" attach vdisk readonly compact vdisk detach vdisk exit

注意文件路径要替换成你自己的实际路径。每次做完这个操作，通常能回收好几个 GB 的空间。

3.4 从 Windows 卸载 Ubuntu 和双系统的清理

有搜索记录提到"win10 删除 ubantu 双系统"，这里我想澄清一个点：如果你正在使用 WSL 方案，并不存在双系统的 GRUB 引导问题，因为 WSL 不参与 Windows 的启动引导。卸载 WSL 里的 Ubuntu 发行版很简单：

wsl --unregister Ubuntu

但注意，这个命令会永久删除该发行版里的所有 Linux 数据，包括你已经配置好的环境，执行前务必确认不需要备份。如果只是想暂时停用某个发行版，用：

wsl --terminate Ubuntu

它只是停止运行，不会删除数据。我在多个机器上做过测试，--terminate和--shutdown的语义有区别，前者针对单个发行版，后者针对整个 WSL 环境，别用混了。

4. CUDA Toolkit 安装与验证，关键中的关键

4.1 必须先弄懂 WSL 里的 CUDA 和普通 Linux 有什么区别

很多人配 CUDA 失败，根源是没搞清楚 WSL 的特殊机制。在普通 Linux 系统上装 CUDA，分两层：第一层是显卡驱动，用于让操作系统和 GPU 通信；第二层是 CUDA Toolkit，包含nvcc编译器、CUDA 运行时库和开发工具。但在 WSL2 里，第一层驱动不需要你安装，Windows 侧的 NVIDIA 驱动会被自动透传进来。你可以直接在 WSL 终端执行：

nvidia-smi

如果看到显卡型号和驱动版本，说明透传成功。这一步是整个 CUDA 配置的起点，如果这里失败，后面所有操作都白搭。

另一个容易混淆的概念是版本号。nvidia-smi输出的右上角会有一个 "CUDA Version"，表示当前驱动支持的最高 CUDA 版本。而nvcc -V显示的则是你实际安装的 CUDA Toolkit 版本。两者不一定一致，这是完全正常的。比如驱动显示 CUDA 12.4，但你只装了 CUDA 11.8 的 Toolkit，那nvcc就显示 11.8。排错时如果看到版本不一致，先判断你问的到底是哪个版本。

驱动版本的兼容性有个简单规则：NVIDIA 驱动是向后兼容的，新驱动可以运行旧版 CUDA，反之不行。比如你装了最新驱动，那么所有旧版 CUDA Toolkit 基本都能正常使用。因此，如果你不太想折腾，直接装 Windows 侧的最新 NVIDIA 驱动，省心很多。

4.2 在 WSL 内安装 CUDA Toolkit 的两种方式

NVIDIA 官方提供两种在 WSL 内安装 CUDA Toolkit 的方式：deb 包方式和 runfile 方式。先说结论，我更推荐 runfile local installer。

deb 方式的优点是后续卸载方便，用apt remove就能清理干净。但它会把 CUDA 安装成系统级组件，修改系统的动态链接库配置，而且一个系统上如果装了多个版本，切换起来比较麻烦。runfile 方式则把一切解压到/usr/local/cuda-12.x目录下，安装位置可控，卸载就是删文件夹，多版本共存也简单。

具体操作，先到 NVIDIA CUDA Toolkit 下载页面，选择 Linux -> x86_64 -> WSL-Ubuntu，然后用wget下载对应的 runfile：

wget https://developer.download.nvidia.com/compute/cuda/12.4.1/local_installers/cuda_12.4.1_550.54.15_linux.run sudo sh cuda_12.4.1_550.54.15_linux.run

运行后第一步是协议确认，连续输入accept回车。接着进入组件选择界面，这里有一个致命坑：一定要取消勾选 "Driver"。前面说过，WSL 里不需要安装 Linux 驱动，如果你不小心勾选了 Driver，安装器会尝试操作显卡驱动，可能导致 GPU 透传失效。我自己第一次装的时候就踩过这个坑，最后只能重装系统才恢复。

等待解压安装完成，期间什么也不用做。装完后检查目录：

ls /usr/local/ | grep cuda

正常情况下会看到cuda和cuda-12.4两个目录，前者是后者的软链接。

4.3 配置 nvcc 环境变量与多版本切换

安装完成后，需要把 CUDA 的 bin 和 lib64 目录加入 PATH 和 LD_LIBRARY_PATH。编辑~/.bashrc，在文件末尾追加：

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

执行source ~/.bashrc后，验证：

nvcc -V

输出中包含版本信息就说明成功。如果提示 command not found，大概率是 PATH 没生效，再检查一下写入的位置和内容，然后用echo $PATH确认。

多版本 CUDA 切换是我在实际工作中经常用到的功能。一个项目依赖 CUDA 11.8，另一个项目需要 CUDA 12.4，最简单的做法是在/usr/local下同时保留两个版本，再通过软链接切换：

sudo rm -rf /usr/local/cuda sudo ln -s /usr/local/cuda-12.4 /usr/local/cuda

切换后重新打开终端，nvcc就会指向新的版本。更优雅的方式是为不同的 conda 环境设置独立的CUDA_HOME和PATH，在激活虚拟环境时自动切换，避免全局干扰。这里我推荐后者，因为深度学习项目隔离越彻底，问题越少。不过需要理解的是，PyTorch 等框架里自带的 CUDA 运行库和系统 Toolki 是两个体系。一个带着 cu121 后缀的 PyTorch 包，即使系统里没有装 CUDA Toolkit，它也自带 CUDA runtime 依赖。需要nvcc的是那些要现场编译 CUDA 扩展的场景，比如你手动下载某个开源模型仓库里需要编译的自定义算子。

4.4 编译运行 deviceQuery 做一次真实验证

环境变量配好后，建议立刻编译运行 CUDA 自带的 deviceQuery 示例程序，这是验证整个链路是否双向打通的最快方式：

cd /usr/local/cuda/samples/1_Utilities/deviceQuery sudo make ./deviceQuery

如果最后几行输出Test PASSED，而且能看到你的显卡型号，说明驱动、Toolkit、编译器、运行时库全部正常。deviceQuery 的价值在于它同时检查了硬件识别、驱动通信、CUDA 运行时链接等多个环节。很多人在配完 CUDA 后跑 PyTorch 遇到CUDA error: no kernel image is available，如果先用 deviceQuery 排查，能更快定位问题在哪一层。

如果编译时找不到头文件，会报类似fatal error: cuda_runtime.h: No such file or directory，这通常是CUDA_HOME或 include 路径没配好。检查：

echo $CUDA_HOME echo $PATH

确认/usr/local/cuda/include里真的有 cuda_runtime.h。有时是因为 PATH 指向了旧版本目录，而你要用新版本的库，手动把软链接和 PATH 对齐即可。

5. PyTorch 环境搭建与 GPU 实战验证

5.1 用 conda 独立环境安装 PyTorch

CUDA Toolkit 配好后，接下来就是装 PyTorch 并验证 GPU 加速。我用 conda 建一个干净的虚拟环境，避免污染系统环境：

conda create -n pytorch python=3.10 -y conda activate pytorch

Python 版本用 3.10 是目前兼容性最稳的选择。PyTorch 的安装命令取决于你要用的 CUDA 版本，以 CUDA 12.4 为例：

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

这里有个关键点：--index-url指定了 CUDA 版本的专用源。如果你直接pip install torch，从默认 PyPI 拿到的 torch 很可能是不含 CUDA 支持的 CPU 版本，性能差距天壤之别。

安装完成后，立刻做一个基本测试：

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

torch.cuda.is_available()返回True，并且能打印出你的显卡名字，说明 GPU 相关的动态库和驱动已经打通。如果返回False，不要急着重新安装，先按第 6 部分排查。

5.2 用一段真实训练代码确认 GPU 加速可用

torch.cuda.is_available()返回 True 只是静态检测，我还会跑一段真实的 GPU 运算，确保驱动、运行库和 kernel 都真正启用，而不是仅仅报了个设备名：

python -c "import torch; a=torch.randn(2048,2048).cuda(); b=torch.randn(2048,2048).cuda(); print((a@b).shape)"

这个操作会在 GPU 上执行一次大矩阵乘法，几秒内出结果。想更直观确认 GPU 在工作，可以同时打开 Windows 任务管理器的"性能"选项卡，观察 GPU 的利用率波动。

再进一步，我会跑一个完整的最小训练循环，验证模型的 forward、backward、optimizer.step 全流程：

import torch import torch.nn as nn model = nn.Linear(1024, 1024).cuda() optimizer = torch.optim.SGD(model.parameters(), lr=0.01) data = torch.randn(2048, 1024).cuda() for i in range(50): loss = model(data).sum() optimizer.zero_grad() loss.backward() optimizer.step() if i % 10 == 0: print(f"step {i}, loss={loss.item():.4f}")

跑完没报错，就说明这整套 WSL + Ubuntu + CUDA + PyTorch 链路完全正常，可以正式开工了。如果你后续要跑 Stable Diffusion、ComfyUI 或 LLM 推理，这套环境就是它们的地基。

5.3 在 VSCode 里接入 WSL，让开发体验拉满

环境配好后，强烈建议把 VSCode 接入 WSL。装上 Microsoft 官方的 "WSL" 扩展，然后在 WSL 终端里执行：

cd /home/dev/project code .

VSCode 会启动一个窗口自动附加到当前 WSL 环境，左侧文件树显示的是 Linux 目录，终端也是 bash。在右下角选择 Python 解释器时，指向 conda 环境里的 python，通常路径类似/home/dev/miniconda3/envs/pytorch/bin/python。

配合这个工作流，实际开发体验是这样的：Windows 上写代码、看文档、截图，WSL 终端里跑训练和调试，文件零拷贝直接共享。调试时 VSCode 会在 WSL 侧启动调试进程，断点命中、变量查看都正常工作。很多人在搜"在 vscode 中使用 wsl"，这个流程就是完整的答案。

另外，WSL 里跑 Jupyter Notebook 也很方便。在 conda 环境里安装 jupyter 后，运行jupyter notebook，它会自动使用 WSL 的 Python 内核，浏览器则是在 Windows 侧打开。train 过程里导出的模型文件，可以在 Windows 侧直接用，不需要任何拷贝操作。

5.4 监控 GPU 与显存使用的小工具

开发时实时掌握 GPU 状态很重要。nvidia-smi是基础工具，但它只输出当前瞬间的状态，刷新的体验不好。我喜欢用：

watch -n 1 nvidia-smi

每秒刷新一次显存、温度、功耗和利用率。想记录成日志的话：

nvidia-smi --query-gpu=memory.used,utilization.gpu,temperature.gpu --format=csv -l 1 > gpu_log.csv

在训练脚本里也可以主动控制显存分配。遇到 PyTorch 报CUDA out of memory时，除了调小 batch size，还可以限制进程占用比例：

torch.cuda.set_per_process_memory_fraction(0.9)

这个接口让单个进程最多使用 90% 的显存，给 CUDA context 和其他临时分配留出缓冲，减少因峰值超限直接崩溃的概率。但要注意，这只是一个应急手段，真正的瓶颈还是显存物理容量。

6. 高频问题实测排查速查表

6.1 WSL 安装和启动阶段的错误码处理

热搜词里出现过的错误代码: wsl/installdistro/service/registerdistro/createvm/hcs/error_file_n，本质是 HCS（Host Compute Service）创建虚拟机失败，或者发行版注册失败。遇到这类 WSL 底层错误，按顺序排查效率最高。

第一步确认虚拟化真的开启。在管理员 PowerShell 里执行systeminfo，查看最后是否有 "Hyper-V 要求" 相关的信息，以及虚拟机监控程序是否已检测到。如果没有，说明 BIOS 里的虚拟化开关没开或者被安全软件抢占。

第二步确认 Hyper-V 虚拟机服务在运行：

Get-Service vmcompute

状态不是 Running 的话，启动它：

Start-Service vmcompute

第三步重置网络和 WSL 状态。常见操作是：

wsl --shutdown netsh winsock reset netsh int ip reset

然后重启 Windows。这一套组合拳能解决大部分 HCS 相关的错误。

如果问题依然存在，考虑发行版镜像本身损坏。先wsl --unregister Ubuntu，再重新安装。整个检查流程，我建议按表里顺序走，跳过步骤很容易走弯路：

6.2 驱动、CUDA 版本和 PyTorch 版本匹配速查

版本不匹配是 GPU 环境失败的第一大原因。完整兼容表以 NVIDIA 官方文档为准，我这里给出实际使用中最常见的组合：

实操中最常见的问题是：nvidia-smi显示正常，但torch.cuda.is_available()为 False。这个情况有一个被反复误判的原因：你安装的 PyTorch 是 CPU 版本。检查方法是在 Python 里执行：

import torch print(torch.version.cuda)

如果输出None，说明这个包是纯 CPU 版本，重装带 CUDA 的版本即可。如果输出的是类似12.4的字样但is_available()仍然 False，那再检查 Windows 驱动版本和 WSL 内核是否更新。

不同 CUDA Toolkit 版本共存的问题我也说两句。你完全可以让多个版本存在于/usr/local下，通过软链接切换。关键是确保你用的 PyTorch 包自带的 CUDA runtime 和你手动装的 Toolkit 的版本不冲突。PyTorch 的 wheel 内置了自己的 CUDA 库，所以大多数纯 Python 项目不需要系统级 Toolkit。只有需要编译自定义 CUDA 扩展（比如某些自定义算子）时，才必须用和 PyTorch 同一 CUDA 主版本号的nvcc。

6.3 性能与 IO 相关的经验教训

在 WSL 的深度学习工作流里，最容易忽略的是文件系统 IO 差异。WSL2 里访问 Linux 原生文件系统（比如/home/dev/）很快，而跨操作系统访问 Windows 挂载盘（比如/mnt/c/、/mnt/d/）则慢不少。原因是/mnt/走的是 9P 协议，经过了额外的网络栈转换。我实测过，在/mnt/d/上跑数据加载，比放到 WSL 内部目录慢 3 倍以上。

所以训练数据集和项目目录一定要放在 WSL 内部文件系统，比如/home/dev/datasets/，而不是挂在 Windows 盘的路径下。如果你有 Windows 侧已有的数据，最优做法是复制进 WSL，让训练阶段完全走 Linux 原生 IO。

IO 之外，内存也是一个容易被低估的限制。WSL2 的内存分配策略由.wslconfig控制，默认只给宿主机内存的一部分。一旦训练进程触顶，WSL 会开始使用 swap，性能大幅下跌。如果你发现训练速度突然骤降，先用free -h看一下内存使用情况。遇到这个问题，优先调大.wslconfig里的 memory，其次考虑减小 batch size。

WSL2 的/tmp目录默认使用物理内存存储，如果你往里面复制几个 GB 的文件，内存可能直接被占满。遇到这种情况，把大文件放到~/tmp或直接放在项目目录下。

6.4 一个容易被忽略的网络问题排查思路

有热搜提到"ubantu升级驱动后无法上网"，这在 WSL 场景下偶尔也会遇到。表现是 WSL 里apt update失败，ping外网不通，但 Windows 侧网络正常。这通常不是驱动问题，更可能是 WSL 虚拟网络适配器状态异常。解决办法：

wsl --shutdown

重启后，WSL 会重新初始化虚拟交换机。如果还不行，检查 Windows 的网络连接，确认名称为 "vEthernet (WSL)" 的虚拟网卡没有异常。还有一种情况：Windows 侧启用了第三方网络安全软件或系统代理工具，干扰了 WSL 的流量转发。排查时临时关闭这类软件看是否恢复正常，能快速确认责任方。

另外，WSL 里的 DNS 配置偶尔会失效，表现是nslookup失败但curl直接访问 IP 正常。可以临时修改/etc/resolv.conf，填入nameserver 223.5.5.5（国内可用），再测试网络。注意，WSL 可能会在重启后重写这个文件，所以如果修改有效，就把它固化到/etc/wsl.conf的[network]段。

6.5 关于"升级驱动后 WSL 出错"这类问题的经验

Windows 升级 NVIDIA 驱动后，WSL 里的 CUDA 环境偶尔会出幺蛾子。最常见的表现是 WSL 启动正常，但nvidia-smi报错，或者 PyTorch 提示 CUDA driver 版本不兼容。原因通常是驱动更新过程中，WSL 侧缓存的驱动状态没有刷新。

我的建议是先做一次彻底的 WSL 重启：

wsl --shutdown wsl

如果问题还在，查看nvidia-smi是否能正常显示。检查 Windows 驱动版本是否为最新的官方版本。有时老驱动文件还在系统里，新驱动覆盖不彻底，导致 WSL 里加载到旧版本。对这种情况，最稳妥的办法是使用 NVIDIA 官方驱动卸载工具清理后，再重新安装最新驱动。

另外，如果你在 Windows 侧更新了非常大版本的驱动（比如从 5xx 跨到 6xx），同时 WSL 里的 CUDA Toolkit 是老版本，有可能出现nvcc -V正常但程序运行报CUDA_ERROR_UNSUPPORTED_DRIVER的情况。处理方式不是回退驱动，而是升级 CUDA Toolkit 到与驱动兼容的版本。

我踩过几次坑之后的一些心里话

先说一个原则：如果你不是有明确的新特性需求，不要追求最新版的 CUDA 和 PyTorch。我的主力组合是 CUDA 12.4 + PyTorch 2.3.x，这个组合最大的好处是各大开源项目、预训练模型、推理框架的兼容性都验证得比较充分，踩坑概率最低。尝鲜新版本可以，但别在生产项目里当小白鼠。

然后是环境记录。我强烈建议你建一个笔记或者 README，把 Windows 驱动版本、CUDA Toolkit 版本、PyTorch 版本、WSL 内存配置这些要素全部记下来。等到半年后环境出问题或者需要迁移到新电脑时，这份记录能帮你快速定位问题，而不是从头开始排查。我自己的做法是写了一个setup.sh脚本，把换源、装 miniconda、装 CUDA、建环境、装包这些步骤全部固化成脚本，任何新机器上半小时就能还原一套完整环境。

最后一个容易被忽略的点：WSL 的 Linux 侧数据全在虚拟磁盘里，如果你不小心执行了wsl --unregister Ubuntu，所有数据瞬间消失，没有回收站。我遇到过不止一次因为手滑导致环境全没的事故。所以重要的模型权重、代码仓库、训练日志，一定定期同步到 Windows 侧或者 Git 仓库里，别把 WSL 当成永久存储。

这套 WSL + Ubuntu + CUDA 环境我已经用了一年多，每天在上面跑训练和调试。从最初的频繁踩坑，到现在基本一键还原，整个过程积累下来的经验，就是这篇文章的内容。希望它能帮你把环境一次配好，少走弯路。