很多朋友第一次接触 CUDA，是从本地跑大模型开始的——把 N 卡驱动装上，再装一个 CUDA Toolkit，结果跑 Python 代码时依然报错，一脸懵。我第一次配环境也折腾了大半天，最后发现不是安装步骤有多难，而是没搞明白显卡驱动、CUDA Toolkit、cuDNN 这三兄弟到底是什么关系，怎么协同工作。今天这篇文章就用最近帮朋友排错的几个真实例子，把 CUDA 与 N 卡驱动安装这件事从头到尾讲透。内容覆盖驱动安装、DDU 清理、CUDA 多版本共存、WSL2 里的 CUDA 环境，以及装完之后怎么验证，适合刚入门 GPU 编程、要在 Windows 或 WSL2 里跑 PyTorch、TensorFlow、llama.cpp 的读者，也适合那些装着装着就翻车、正准备重装系统的朋友。
1. 先搞清楚三兄弟的关系：驱动、CUDA Toolkit、cuDNN
很多人安装失败不是步骤顺序错了，而是压根没分清楚这几个东西各自负责什么。你把驱动装上，GPU 能被系统识别，但 PyTorch 未必认；你把 CUDA Toolkit 装上，nvcc -V可能正常，但程序跑起来依然说找不到设备。要避免这种窘境，优先级最高的事是把概念理清。
1.1 三者的分工：为什么装了驱动还跑不起模型
我习惯用一句话记住三者的区别：显卡驱动管“能不能干活”，CUDA Toolkit 管“拿什么工具干活”，cuDNN 管“干活快不快”。用做饭来类比的话，驱动相当于天然气管道，通了之后灶台才能点火；CUDA Toolkit 是菜刀和锅铲，你总归要用这些工具才能切菜炒菜；cuDNN 则像半成品酱料包，同样的菜，放了它能省很多时间。
大多数人犯的第一个错误，是驱动装完就以为 CUDA 环境好了，结果打开 PyTorch 发现torch.cuda.is_available()还是 False。原因是 PyTorch 这类框架运行时要找的是 CUDA 的运行时库，而不只是驱动。如果没装 Toolkit，或者装了但版本对不上，框架就会假装看不见 GPU，甚至直接报CUDA driver version is insufficient这种提示。
反过来，只装 Toolkit 不装驱动也不行。nvcc -V能正常输出版本号，但一跑程序，GPU 根本用不起来，因为驱动层缺失。这个场景常见于“先装 CUDA Toolkit，再插显卡驱动”的新手操作。顺序反了不会造成物理损伤，只要把驱动补上，环境一般就能正常。
还有一个容易被忽略的角色是 cuDNN。TensorFlow 2.5 这类的老版本框架，对 cuDNN 的版本要求卡得很死，用错了版本，框架加载时就会报Could not load library cudnn_cnn_infer64_8.dll之类的错误。所以不要只盯着 CUDA 版本，cuDNN 也要按官方表格来选。
1.2 版本对应关系：从驱动版本反推 CUDA 版本
先记住一条铁律：驱动决定上限，Toolkit 决定开发，cuDNN 决定性能。NVIDIA 驱动内置了 CUDA 运行时的一部分能力，而且它是向后兼容的——新驱动能跑老 Toolkit 编译出来的程序，老驱动通常跑不了新 Toolkit 的程序。所以当程序报错说CUDA driver version is insufficient时，十有八九是驱动太旧。
安装驱动后，在终端输入nvidia-smi，最下面一行会显示一个CUDA Version数字，这就是当前驱动能够支持的最高 Toolkit 版本。例如驱动 550.144.03 通常对应 CUDA 12.4，意思是你可以安装 12.4 或更低的 Toolkit 版本，但不要装 13.x 这种比驱动上限还新的版本。有个朋友看到CUDA 12.4几个字，就以为 CUDA 环境已经装好了，其实这只是驱动支持的上限，并不代表 Toolkit 已经装好。
NVIDIA 官方也维护一份驱动与 CUDA 版本的兼容表，我按常见分支整理如下，方便你对照自己的驱动版本号快速定位：
| NVIDIA 驱动主版本 | 最高支持 CUDA Toolkit |
|---|---|
| 470.x | CUDA 11.4 / 11.5 |
| 525.x | CUDA 12.0 |
| 535.x | CUDA 12.2 |
| 550.x | CUDA 12.4 |
查表是必要的，但实际使用中我更推荐直接看nvidia-smi的输出，那才是最真实的当前机器状态。表格里记的是“最高支持”，不是“必须使用”，所以驱动新一点，往往能兼容更多 Toolkit 版本，反而更省心。
1.3 一个核心误区：CUDA 版本不是越新越好
很多人的思路是“既然 CUDA 出到 12.x 了，那我直接装最新版”。这个思路在纯学习场景还行，一旦你依赖特定框架，就会很痛苦。比如某个开源项目明确写明“支持 CUDA 11.8”，你用 12.4 去编译，运气好能过，运气不好就挂。llama.cpp 这类程序对 CUDA 版本和 GPU 架构参数很敏感，常有人遇到类似cuda llama.cpp non compatible的提示，细看往往是对应的 CUDA Toolkit 版本或编译参数跟显卡不匹配。
正确做法是：先看框架官方文档要求哪个 CUDA 版本，再看nvidia-smi显示的驱动支持上限，最后选择一个不超过上限、且满足框架要求的版本。例如你的是 4060 Ti，驱动 550.144.03，想跑 TensorFlow 2.5。查官方说明知道 TensorFlow 2.5 需要 CUDA 11.2 和 cuDNN 8.2，那就装 CUDA 11.2，驱动完全向下兼容，环境就很稳。如果你想跑最新 PyTorch，而它要求 12.4，那驱动又是 550 系列，装 12.4 也完全够用。
另外，关于 AMD 显卡能不能跑 CUDA 的问题经常被问。确实有“AMD 显卡跑 CUDA”之类的说法出现，原理多半是用转译层把 CUDA 程序转成其他显卡指令，或者借助 ROCm 这类方案来间接执行。这类项目能跑通一部分程序，但兼容性和稳定性远不如原生 N 卡环境，中间涉及的环境变量、驱动配置也相当折腾。如果你是学习 CUDA 本身，踏踏实实用 N 卡；如果只是想让某个模型跑起来，考虑原生 CUDA 环境或者云主机，别在转译上浪费太多时间。
2. 驱动安装的顺滑路线与翻车现场
概念理清之后，再上手安装就顺畅多了。驱动是所有 CUDA 工作的地基，这一节把标准流程、DDU 清理、老驱动获取这三个关键点都过一遍。很多人卡在驱动这步，不是下载装不上，而是旧环境没清干净。
2.1 标准安装流程：从官网下载到装完重启
安装 N 卡驱动，渠道一定是官方下载页。选择显卡型号和操作系统后，页面会给你推荐一个最新驱动。这里有一个很多人不知道的差别：驱动分 Game Ready 和 Studio 驱动。跑 CUDA、PyTorch、视频渲染之类的开发任务，我建议选 Studio 驱动，它更侧重稳定性和生产力工具，而不是游戏帧率优化。装的时候选择自定义安装，最好勾选“执行清洁安装”，这样能把旧驱动残留文件清理掉，避免后续各种玄学报错。
安装过程中会弹出一个组件选择列表，比如 NVIDIA PhysX、HD 音频驱动、GeForce Experience 等。GeForce Experience 可以不装，它是游戏优化工具，对 CUDA 开发没用，少装一个组件就少一个后台服务。装完驱动重启系统，打开nvidia-smi，确认显卡被正确识别、显存容量和驱动版本都对得上，这一步就算过了。
有个常见的坑：安装新版驱动后，有的用户会遇到“n 卡更新后闪退”或者“n 卡更新出现一个错误”之类的情况。这种大多不是新驱动本身损坏，而是旧版本文件没清干净，和系统其他组件冲突。解决办法不是反复重装，而是先用下一节说的 DDU 在安全模式清理一遍，再装新驱动。大部分“更新失败”的案例，靠这一套操作都能解决。
2.2 DDU 清理旧驱动的正确姿势
DDU 全称 Display Driver Uninstaller，是显卡驱动清理圈子里几乎人手一份的工具。它的用途是彻底移除系统中残留的显卡驱动文件、注册表项和服务，避免新旧驱动互相干扰。我见过最经典的场景是：显卡从 A 卡换成 N 卡，系统重装后仍然出现花屏、驱动装不上等问题，DDU 清一遍，问题就消失了。
用 DDU 的正确步骤，我建议按这个顺序来：
- 下载 DDU 压缩包，解压到非系统盘目录。
- 重启进入 Windows 安全模式（设置-系统-恢复-高级启动，或者在登录界面按住 Shift 点重启）。
- 在安全模式下打开 DDU，切换显卡厂商为 NVIDIA，选择“清理并重启”。
- 重启后保持断网状态，再安装新驱动。
- 驱动装好确认没问题后再联网。
为什么一定要在安全模式下做？因为在正常模式下，显卡驱动服务和一堆 GUI 进程都还在运行，DDU 删除文件时总会遇到占用、拒绝访问的情况，清理不彻底。在安全模式下，系统只加载最小驱动集，显卡驱动相关服务基本不启动，这时候才删得干净。断网那一步同样关键，因为 Windows Update 会在驱动缺失时自动补装一个老驱动。你千辛万苦装的新驱动，可能一联网就被覆盖成旧版了。
提示：DDU 只会清理显卡驱动以及相关注册表项，不会动操作系统文件，放心用。但务必从官网或可信渠道下载，别在第三方网站找“绿色版”。
2.3 老驱动去哪儿找：N 卡官网没有老版本怎么办
有时候不是你想用最新驱动，而是某个老项目只认特定版本的驱动。但 NVIDIA 官网默认只展示最新驱动，历史版本藏得比较深。别急，有两个官方途径可以找老驱动。
第一个是在 NVIDIA 驱动下载页面的搜索结果里，通常有“Beta 和旧版驱动”入口，点进去可以按日期和分支浏览历史版本。第二个是驱动档案页面，它会列出不同分支、不同时间点的驱动，你可以在里面挑选需要的版本号。需要说明的是，太新的显卡不一定能找到很老的驱动，因为 NVIDIA 不会为最新架构维护几年前的旧版驱动。
如果驱动档案里也找不到，多半是你需要的版本和显卡年代跨度太大。这时候换个思路：升级依赖库的版本，而不是死磕老驱动。某个 CUDA 程序必须在老驱动下跑，十有八九是程序本身用的库太老，更新程序或者换一个兼容新驱动的版本，往往比反向找老驱动容易得多。驱动回退也可以在 Windows 设备管理器里操作：右键显卡-更新驱动-浏览我的电脑-让我从计算机上的可用驱动程序列表中选择，系统有时会保留上一个版本供你回退。这个方法适合“刚升级完驱动发现翻车”的场景。
3. CUDA Toolkit 安装：多版本共存与路径管理
驱动搞定了，接下来就是 CUDA Toolkit。这一节内容比较细，因为很多人会在多版本共存和路径切换上翻车。你不需要把所有命令都背下来，但必须理解目录结构和环境变量的逻辑，遇到问题才能自己排查。
3.1 安装包选择与参数：别用默认路径
CUDA Toolkit 的安装包在 NVIDIA Developer 官网下载。下载时会让你选择操作系统和架构，Windows 下选择 exe（local）安装包即可。安装时选择自定义安装，里面的组件默认全选，但实际开发并不需要全部。我通常保留 CUDA 核心、CUDA Runtime、Development 这几个主组件，以及 Samples 示例程序，取消勾选 Visual Studio Integration，除非你确定要在 Visual Studio 里开发 CUDA 程序。
默认安装路径建议保持不动，也就是C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4这种形式。很多框架和第三方库在 Windows 下是硬编码去找这个目录的，你改成 D 盘或其他自定义路径，后续麻烦事会多得多。装完后，系统一般会自动设置CUDA_PATH环境变量，如果没有自动配好，需要手动在系统环境变量里添加这个路径，并把bin目录加进PATH。
注意一个小细节：安装页面同一版本下会有 12.4.0、12.4.1 等小版本号，但安装目录名只显示大版本 v12.4。所以如果你先后装了 12.4.0 和 12.4.1，实际目录都在同一个 v12.4 下面，后装的会覆盖前装的。真正想实现多版本共存，必须是大版本不同，比如 v11.8 和 v12.4，这才是两个独立目录。
3.2 多版本 CUDA 并存的目录结构
多版本共存的场景太常见了。我身边不少人的电脑上同时装着 CUDA 11.8 和 12.4，因为不同项目依赖不同。装多个版本本身很简单，按顺序各装各的，目录自然分成 v11.8 和 v12.4，互不覆盖。真正麻烦的是怎么让不同项目用上对应的版本。
问题出在环境变量上。系统里只有一个CUDA_PATH，它指到哪个版本，默认的nvcc就是哪个版本。如果多个版本同时装，最后安装的那个版本往往会改写CUDA_PATH，导致之前项目用的 nvcc 版本“悄悄变了”。这就是很多人新装一个 CUDA 之后，以前能编译的老项目突然编译失败的原因。
为了管理多版本，我自己的做法是：系统CUDA_PATH指向最常用的版本，其他项目需要切换时，在命令行里临时设置环境变量，而不是去改系统全局配置。Windows 的 cmd 里这样临时设置：
set CUDA_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8 set PATH=%CUDA_PATH%\bin;%PATH% nvcc -V设置完后，当前终端窗口里nvcc就指向 11.8 了，不影响其他窗口和其他程序。这种临时变量方式胜在干净、可逆，关掉窗口就恢复原状。
3.3 环境变量切换：让不同项目各用各的 CUDA
如果你经常在多个 CUDA 版本之间切换，每次手敲两行 set 命令很烦。我推荐写一个简单的切换脚本，放在固定目录，一键切换。比如用 PowerShell 写一个switch-cuda.ps1，接受版本号参数，验证目录存在后设置CUDA_PATH和PATH。脚本写好后，切换就是一行命令的事。
# switch-cuda.ps1 param([string]$version) $cudaBase = "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA" $cudaPath = Join-Path $cudaBase "v$version" if (Test-Path $cudaPath) { $env:CUDA_PATH = $cudaPath $env:PATH = "$cudaPath\bin;$env:PATH" Write-Host "Switched CUDA to v$version" } else { Write-Host "v$version not found in $cudaBase" }用脚本切换前，记得先运行nvcc -V确认当前版本。另外，切换环境变量只影响从当前终端启动的新进程，已经启动的 Python 进程、Jupyter Notebook 不会自动更新环境。所以在 Jupyter 里跑代码，切换完 CUDA 版本后要把 Notebook 服务重启一遍才生效。这个细节容易被忽略，我就在上面栽过跟头。
关于“CUDA 迁移”，也就是把项目从旧版 CUDA 环境迁到新版，我的经验是先别直接换系统 CUDA，而是先建一个隔离环境测试。比如用 conda 创建新环境，在里面指定 CUDA 相关依赖，跑通后再切到正式环境。直接覆盖大版本，很容易让系统里一堆老项目全部炸掉。迁移完还建议跑一遍项目自带的测试用例，确认关键计算逻辑的输出没有变化。
4. WSL2 里跑 CUDA：和 Windows 完全不同的那套逻辑
现在很多人在 Windows 上跑 Linux 开发环境，WSL2 是绕不开的话题。它和原生 Linux 不同，也和 Windows 原生环境不同，但很多教程直接把两套逻辑混在一起讲，把人绕晕。WSL2 里跑 CUDA 其实有一套固定的流程，搞清楚了会发现比 Windows 原生更省心。
4.1 为什么 WSL2 不需要装 Windows 驱动
WSL2 不是传统意义上的虚拟机，它不模拟硬件，而是直接共享 Windows 系统的内核和驱动通道。所以结论很明确：Windows 下装好 N 卡驱动后，WSL2 里不需要再装任何显卡驱动，直接在 Linux 里面就能用 CUDA。
很多人在 WSL2 里第一件事是sudo apt install nvidia-driver，把内核模块装得乱七八糟，这是完全没必要的。你在 WSL2 里运行nvidia-smi，看到的信息其实来自 Windows 侧的驱动。WSL2 的 CUDA 设计是“驱动的归 Windows，Toolkit 的归 Linux”，开发者在 Linux 环境里只装 CUDA Toolkit 和 cuDNN 即可。相比双系统或者原生 Linux，这套方案反而更干净。
验证驱动通道是否正常很简单，在 WSL2 终端输入：
nvidia-smi只要能看到显卡名称和显存，说明 Linux 侧已经能访问 Windows 驱动。如果提示找不到设备或无法通信，第一步先去升级 Windows 侧的驱动，而不是折腾 WSL2 本身。
提示：WSL2 内的
nvidia-smi显示的 CUDA 版本，和 Windows 下看到的通常一致，因为底层驱动是同一个。这个数字代表驱动能支持的 Toolkit 上限，不代表 WSL2 里已经装了对应版本的 Toolkit。
4.2 WSL2 内部安装 CUDA Toolkit 的步骤
在 WSL2 里安装 CUDA Toolkit，推荐使用 NVIDIA 官方提供的 apt 源。以 Ubuntu 22.04 或 24.04 为例，大体流程是先下载cuda-keyring包，导入 NVIDIA 的软件源，然后 apt 更新，最后安装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安装完把下面两行写进~/.bashrc：
export PATH=/usr/local/cuda-12.4/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH重开终端，运行nvcc -V确认版本号。
这里有个经验：如果只是跑 PyTorch 预编译包，其实不装完整 Toolkit 也可以，因为 PyTorch 的 wheel 包自带 CUDA 运行时。但如果你要编译 llama.cpp、二次开发 CUDA kernel，或者给 OpenCV 编译 with CUDA 版本，就必须装完整 Toolkit。所以默认装完整工具链更省事，省得到用的时候抓瞎。需要编译 C/C++ 项目时，还要检查本机 gcc 版本和 Toolkit 要求的 gcc 是否匹配，老版本 CUDA 对 gcc 版本限制很严格。
4.3 WSL2 与 Windows CUDA 版本不同步时的坑
这是个很经典的坑。有朋友问我，Windows 驱动是 550.144.03，对应 CUDA 12.4，但他在 WSL2 里图省事直接装了一个最新 CUDA Toolkit 12.6。跑 llama.cpp 编译时，各种non compatible和奇怪的链接错误横飞。问题根源就出在 CUDA Toolkit 版本超过了底层驱动的支持上限。
解决方法是降级 WSL2 里的 Toolkit。先运行nvidia-smi看驱动支持的上限是多少，然后安装不超过这个上限的 Toolkit 版本。比如上限是 12.4，就在 WSL2 里把 Toolkit 降到 12.4，重开终端再编译，问题基本就消失了。这个原则和 Windows 下完全一样，只是 WSL2 的 Toolkit 安装走 apt，检查时容易让人忘了底层驱动来自 Windows。
还有一个坑：WSL2 内部如果用系统默认源直接装nvidia-cuda-toolkit包，装出来的版本可能不是你需要的，组件也可能不全。遇到这种情况，卸载默认源装的东西，改用 NVIDIA 官方 wsl-ubuntu 源来安装，版本管理会清晰很多。实在不行也可以使用 conda 安装 CUDA 相关包，虽然版本受 conda 渠道限制，但胜在环境隔离，互不污染。
5. 装好之后怎么验货：nvidia-smi、nvcc 与真实案例
环境装完，最怕心里没底。我遇到太多人发来一张nvidia-smi截图，问“CUDA 装好了吗”，其实这个命令只能说明驱动加载正常，和 Toolkit 是否装好完全是两回事。验证环境需要多管齐下，最好再跑个真实程序，才能说一句“稳了”。
5.1 三个命令三种含义：nvidia-smi / nvcc / deviceQuery
很多人弄混这三个工具，这里一起说清楚。
nvidia-smi是驱动层的总览，它能显示显卡型号、显存占用、驱动版本，以及驱动支持的 CUDA 版本上限。这个命令有问题，说明驱动安装失败或者驱动服务没起来。
nvcc -V是 CUDA 编译器版本查询。它能输出你当前默认使用的 Toolkit 版本号，但它只能证明编译器存在，不能证明驱动和运行时都健康。有些人在某个终端里看到旧版本，换个终端又看到新版本，就是因为环境变量在每个终端的初始化时机不同。
deviceQuery是 CUDA Samples 里的一个示例程序，专门枚举 GPU 设备、创建 CUDA 上下文，最终输出Result = PASS。它能真正证明“编译工具、运行时、驱动、硬件”整条链路是通的。Windows 下 Samples 一般位于C:\ProgramData\NVIDIA Corporation\CUDA Samples\v12.4\1_Utilities\deviceQuery，找不到的话，多半是安装时没勾选 Samples 组件，重装一次并勾上即可。用 Visual Studio 打开deviceQuery.sln编译，或者直接用命令行编译运行都行。
5.2 实际跑一个推理程序验证
如果上面三个命令全都正常，我会再跑一个真实的程序收尾。这样做不是不信任命令，而是因为框架与 CUDA 的匹配问题，只有程序能真正暴露出来。框架预编译包往往内置了某个 CUDA 版本，如果和你机器的驱动环境不对应，命令层面根本看不出任何异常，一跑程序就现原形。
用 PyTorch 的话，最快的一段验证代码是：
import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出显卡型号且is_available()是 True，基本稳了。想进一步测计算正确性，可以在 GPU 上执行一次大矩阵乘法，比如a = torch.randn(10000, 10000, device='cuda')再算个torch.matmul。矩阵计算能正常完成并返回数值，说明 CUDA 运行时和显存分配都正常。
用 TensorFlow 的话，tf.config.list_physical_devices('GPU')是类似的验证方式。框架报错提示找不到 CUDA 库时，先确认你装的 CUDA 和 cuDNN 版本，是不是框架官方表格里写的那一组。比如 TensorFlow 2.5 对应 CUDA 11.2 和 cuDNN 8.2，版本对不上就会出现driver version insufficient或failed to load the native runtime这类问题。这就是我一直强调版本匹配的原因。
5.3 常见报错与排查思路
最后整理几个我在实际排错中反复见到的报错，以及对应的排查顺序。
报错CUDA driver version is insufficient for CUDA runtime version，说明驱动太旧，撑不起当前的 Toolkit。查一下nvidia-smi显示的 CUDA 上限，把 Toolkit 降到上限以下即可，或者升级驱动。
报错NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver，一般是驱动坏了，或者驱动服务没启动。系统设备管理器里大概率能看到显卡带黄色感叹号，按 DDU 流程清掉重装驱动。
报错nvcc: command not found，Windows 下是环境变量没配好，Linux 下是 PATH 没设置。确认CUDA_PATH和PATH里都有 bin 目录，然后重开终端再试。
编译 C++ 项目时提示编译器版本太老，通常是 gcc 或 Visual Studio 工具集不符合 CUDA 官方要求。每个 CUDA 版本对编译器有明确限制，老版本 CUDA 配新编译器、新版本 CUDA 配老编译器都会出问题。
还有 40 系显卡用户特别容易犯的错：在 4060 Ti 上强行装 CUDA 11.x。虽然不一定完全用不了，但 Ada 架构和 12.x 时代的库配合更顺畅，报错概率低很多。每次有人问“4060 Ti 支持哪个 CUDA 版本”，我的回答都是：40 系就老老实实用 12.x，别为了跟随老教程去装 11.x。
排查顺序也很固定：先看nvidia-smi，再看nvcc -V，接着跑deviceQuery，最后上真实程序。按这个顺序，大部分环境问题能在前三步定位。如果前三个都正常，程序还报错，那问题几乎不在 CUDA 环境，而是框架版本或依赖库匹配问题，这时候应该去查框架的官方安装文档，而不是继续折腾驱动和 Toolkit。
最后说一点个人体会：装 CUDA 和 N 卡驱动这件事，翻车的人基本都是栽在“版本匹配”而不是“安装步骤”上。我给朋友排错时，第一个问题永远是要nvidia-smi的输出，第二个问题是nvcc -V的输出，这两行信息一贴出来，问题基本能定位一半。决定自己动手的话，我建议把 Windows 和 WSL2 两套环境分开看待，但都遵循同一条原则：先看驱动上限，再定 Toolkit 版本，最后按框架要求补 cuDNN。多版本切换记得用脚本管理，别动不动就改全局环境变量。这套流程你走通一次，以后再装任何 CUDA 相关的环境，都会轻松很多。
