Windows下CUDA与cuDNN配置指南：从版本匹配到环境变量避坑

很多刚接触深度学习或者高性能计算的朋友，第一次在Windows下配置CUDA和cuDNN时，最容易遇到的情况是：官网下载页一堆版本号，装完之后跑PyTorch却报“CUDA driver version is insufficient”，或者明明安装了CUDA 12.x，nvcc -V显示的却是另一套版本。这篇文章我把整个安装与配置流程从头到尾拆开讲一遍，包括版本匹配逻辑、安装步骤、环境变量的坑、多版本切换，以及几个高频报错的排查思路，希望能帮你一次装对、少走弯路。

这篇文章适合这几类人看：准备在Windows上跑PyTorch/TensorFlow做深度学习训练的新手、需要在本机编译CUDA扩展或做图像处理开发的工程师，以及那种“装了好几次都没搞明白CUDA到底装没装上”的朋友。我会尽量把原理说清楚，但重点还是放在可以直接照做的实操步骤上。

1. 先搞懂CUDA、cuDNN和NVIDIA驱动的关系

1.1 三个组件各管哪一段

很多人分不清NVIDIA显卡驱动、CUDA Toolkit、cuDNN这三者的区别，导致安装时把每个组件都当成独立的“大块头”去装，结果版本对不上，反复折腾。

我用一个比较生活化的类比来解释。显卡驱动（NVIDIA Driver）相当于操作系统和GPU硬件之间的“翻译官”，只要你用NVIDIA显卡，这个驱动就必须装，它负责让系统识别显卡、输出画面、调用基础的GPU计算能力。CUDA Toolkit则是给开发者用的“工具库”，里面包含编译器（nvcc）、运行时库、数学库、调试工具等等，你的C/C++、Python代码要调用GPU做通用计算，靠的是这一层。cuDNN是NVIDIA专门为深度神经网络设计的“加速库”，它基于CUDA之上，把卷积、池化、归一化这些深度学习里的高频操作做了深度优化，PyTorch、TensorFlow这类框架运行时的底层计算会调到它。

也就是说，这三个东西是“从底到上”的关系：驱动在最底层，CUDA Toolkit在中间，cuDNN在最上层。驱动决定了GPU能被识别，CUDA决定了你能用GPU做计算，cuDNN决定深度学习框架能跑得多快。缺了任何一层，你写代码调用GPU都会失败，只是报错信息不同而已。

1.2 版本匹配的逻辑：向下兼容与编译绑定

这是整个安装过程里最核心、最容易踩坑的地方。先说一句话总结：驱动向下兼容，CUDA Toolkit版本必须和你要用的深度学习框架（比如PyTorch）的预编译版本匹配，cuDNN必须适配你装的CUDA版本。

NVIDIA驱动的兼容策略是：新版本驱动可以运行旧版本的CUDA Toolkit。也就是说，你的驱动是较新的，比如支持CUDA 12.6，那你可以正常使用CUDA 11.8、12.1、12.4这些更早的版本，但不建议强行使用比驱动更高版本的CUDA Toolkit。很多人在官网看到最新CUDA版本是13.x，就下载安装了，结果运行时不支持，报错或者直接找不到，原因就在这里：驱动版本没跟上。

PyTorch这类框架的情况更特殊一些——它们官方提供的是已经预编译好的二进制包，每个版本对应一个固定的CUDA编译版本。举例来说，PyTorch 2.4版本对应有cu118（编译自CUDA 11.8）、cu121（编译自CUDA 12.1）、cu124（编译自CUDA 12.4）这几个变体。如果你选择安装cu121变体，那么本机的CUDA Toolkit最好就是12.1（或者驱动版本能够兼容12.1的更高版本），否则运行时会报类似“CUDA error: no kernel image is available for execution”的错误。

cuDNN的版本号又和CUDA版本绑定更紧。比如cuDNN 9.x系列有对应CUDA 12.x的版本包，下载时你需要看清楚“Installation Guide”里支持的CUDA版本范围。装错了，通常不会在安装阶段报错，而是在你真正跑深度学习模型时突然出现莫名其妙的算子错误或性能异常，排查起来非常痛苦。

所以，我的建议永远是：先把你要用的框架版本定下来，再从框架的文档反推CUDA版本，最后根据CUDA版本选cuDNN。而不是反过来先去下载最新版CUDA，那只会给自己埋坑。

2. 下载前的准备工作：硬件检测与版本选型

2.1 确认显卡型号与驱动版本

在动手下载之前，先花两分钟确认你的硬件环境。Windows下最简单的确认方式：

先看显卡型号。右键桌面空白处 → NVIDIA控制面板 → 左下角“系统信息”，里面能看到显卡型号，比如GeForce RTX 3060 Ti、RTX 4090。或者更直接一点，用快捷键Win + R输入dxdiag，在“显示”选项卡里也能看到名称和显存大小。

再看驱动版本。命令行里输入nvidia-smi，输出信息的最右上角会显示“Driver Version: xxx”，下面还有一行“CUDA Version: xx.x”。这个“CUDA Version”表示当前驱动最多能支持到哪个CUDA版本，但它不等同于你已经安装了CUDA Toolkit。这里经常有人误读，以为是当前系统的CUDA版本，其实驱动那行显示的只是一个“支持上限”。

我自己的习惯是先把这两条信息截图或者记下来，后面选版本的时候对照着看。如果驱动太老，比如还是4xx系列，那建议先去NVIDIA官网把驱动更新到最新版本，因为旧驱动对后续工具链的兼容性会很差。

2.2 如何确定自己该装哪个CUDA版本

版本选型这件事，不能拍脑袋，我用两个实际例子来演示思路。

场景一：准备用PyTorch跑项目。先去PyTorch官网（pytorch.org）选择对应的安装命令。比如你选Windows + Pip + CUDA 12.4，官网会给出类似pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124的命令。这就意味着你本机的CUDA版本要和12.4保持一致（或驱动足够新），你就去下载CUDA Toolkit 12.4.x。

场景二：准备用TensorFlow跑项目。TensorFlow对CUDA版本的要求更严格，每个版本都有明确的Python版本、CUDA版本、cuDNN版本对应表，比如TensorFlow 2.15要求CUDA 12.2、cuDNN 8.9。这时就得严格按照官方表格来装，不能自由发挥。

这里额外提一个我经常强调的经验：如果你只是用PyTorch跑模型推理、训练，装不装完整版CUDA Toolkit其实影响不大，因为PyTorch的whl包内部已经自带了所需的CUDA runtime部分。但如果你要编译自定义的CUDA扩展、使用一些依赖nvcc的库，或者你是做底层CUDA开发的，那就必须安装完整版CUDA Toolkit。前者我会推荐一种“轻量配置”思路，后面第6章会展开。

2.3 从官网下载CUDA Toolkit时需要注意的版本陷阱

CUDA下载页面（NVIDIA官网的CUDA Toolkit Archive）提供了历史版本列表，不会只让你下载最新版。这是很多新手不知道的。如果你需要12.4、11.8这类历史版本，直接进Archive页面找到对应版本下载就好。

每个版本的下载页会让你选择操作系统、架构、发行版本、安装类型等选项。Windows平台通用的选择是：Operating System → Windows；Architecture → x86_64；Version → 对应的Windows版本（比如Win10/Win11）；Installation Type → exe(local)（本地安装包）。

这里有个小坑：建议选exe(local)而不是exe(network)。前者是完整安装包，离线也能装，网络不好的时候用着省心。后者是联网安装器，安装过程中还要去NVIDIA服务器下载组件，经常因为网络问题中途失败。

下载cuDNN时，情况类似，也是从Archive或最新版页面进入，选择“Windows版本 + 对应的CUDA版本”的压缩包。下载前NVIDIA会要求你登录账号，注册一下就行，不涉及付费。

3. 安装CUDA Toolkit的分步实操

3.1 安装前需要做的三件事

安装CUDA Toolkit之前，我建议按顺序处理好三件事，能省掉很多后面的麻烦。

第一，更新显卡驱动到最新。这一步不是必须，但在新驱动上装CUDA Toolkit的成功率和兼容性都会高很多。去NVIDIA驱动下载页面选择你的显卡型号，下载最新Game Ready或Studio驱动安装即可。装完再用nvidia-smi确认驱动版本，顺便把“支持的CUDA版本”记下来。

第二，确认Visual Studio的安装情况。只有在你要用CUDA C/C++编写和编译自定义内核（kernel）时，才需要Visual Studio。如果只是配合PyTorch使用，这一项可以跳过。如果确实需要，建议安装Visual Studio 2019或2022，并勾选“使用C++的桌面开发”工作负载。

第三，关闭所有正在使用GPU的程序。安装过程中NVIDIA安装程序会去替换或更新一些GPU相关的驱动文件和组件，如果此时有程序占用GPU资源（比如正在训练、正在玩游戏、浏览器开了硬件加速），可能会导致安装失败或需要重启才能生效。我习惯在安装前把占用GPU的软件都退出，同时关掉浏览器硬件加速。

3.2 安装过程中的关键选项

双击下载好的CUDA Toolkit安装包，如果弹出“Windows已保护你的电脑”，点击“更多信息”→“仍要运行”即可。安装向导的第一步选择“解压路径”时，默认是C盘下的一个临时文件夹，如果C盘空间较大就保持默认，后续安装完成后这个目录会变成安装源文件目录。

真正的关键选项在“安装选项”这一屏——一定要选择“自定义（高级）”而不是“精简”。“精简”模式会一股脑装很多你可能用不上的组件，比如Performance Clips、NVIDIA Virtual Tools等，既浪费时间又占空间。

自定义模式的组件列表里有几个重点需要手动画勾：

• CUDA Runtime：必选。这是CUDA运行时的核心。
• CUDA Toolkit（开发环境）：这里面包含nvcc编译器、头文件、静态库等。如果你是开发者，这一项必选。
• CUDA Development Tools：包含调试工具、分析工具等，开发经常用，建议选上。
• Visual Studio Integration：只有装了VS并且需要VS开发CUDA程序时才选。没有VS就取消勾选，否则安装到最后可能报集成失败。
• Driver components：这里会显示当前驱动版本新旧，如果已有驱动不旧，且勾了“Display Driver”，安装程序可能要求你重启或替换驱动，建议直接取消勾选驱动部分，避免覆盖原有驱动。尤其在数据中心或特定开发环境下，覆盖驱动往往容易出事。
• Nsight Tools、OptiX等：按需选择，不搞图形开发可以全部去掉。

安装路径方面，默认会装到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4这样的目录。不建议改路径，或者即使改路径也不要用带空格的目录、不要用中文路径，否则后续编译工具链可能因为路径解析出问题。

安装过程中会有一个选项是“CUDA Samples”，勾不勾都行，但如果你想要自带示例项目验证安装是否成功，建议保留。装完后安装程序提示“安装成功”就说明主程序搞定了。

3.3 环境变量配置与nvcc -V验证

安装完成后，环境变量通常会自动配置好。但为了保险，我每次都会手动检查一遍。在Windows设置里搜索“编辑账户的环境变量”，打开后看“系统变量”列表里是否有以下两个关键项：

• CUDA_PATH：值应该是C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4（或你的实际版本目录）。旧版本安装程序还会创建CUDA_PATH_V12_4这种带版本号的变量。
• PATH：要包含C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\bin和C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\libnvvp这两个目录。 还有两个目录——...\extras\CUPTI\lib64和...\include——在大多数场景下也会用到，建议一并加到PATH里。

环境变量配置好之后，不要忘记重新打开一个命令行窗口，让新环境变量生效。然后在命令行中输入：

nvcc -V

如果输出类似Cuda compilation tools, release 12.4, V12.4.131这样的信息，说明CUDA Toolkit安装成功，nvcc编译器可以被正常识别。这一步是验证CUDA安装是否成功的最关键指标，比安装时那个“安装成功”对话框可靠得多。

也可以再跑一个更完整的硬件验证。进入CUDA Samples默认的示例目录，或者用deviceQuery这个小工具（安装完成后通常位于C:\ProgramData\NVIDIA Corporation\CUDA Samples\v12.4\bin\win64\Release），在命令行执行：

deviceQuery.exe

正常输出会以“PASSED”结尾，同时列出你的显卡型号、驱动版本、显存大小等信息。出现“FAILED”或者找不到设备，就说明CUDA在底层和硬件的连接出了问题，需要回去检查驱动。

4. cuDNN安装与部署

4.1 下载cuDNN的正确方式

cuDNN目前可以通过两个渠道获取：一是NVIDIA的开发者账号登录后到官网下载，二是在NVIDIA的GitHub仓库（或Archived版本）：下载对应CUDA版本的安装包。多数人走的都是第一条，这里把关键步骤说清楚。

进入NVIDIA cuDNN下载页面，选择“Download cuDNN”会要求登录NVIDIA账号。注册不需要付费，就是需要一些基本资料。登录之后，你会看到针对不同CUDA版本的cuDNN版本列表。先看你的CUDA版本是12.x还是11.x，然后选择对应分类下的最新稳定版。

下载时需要注意安装包又细分为几个选项：Windows (x86_64) 的压缩包、安装程序（.exe）版本、以及某些版本可能提供zip压缩包。这里我推荐用zip或本地安装器。cuDNN的本质是一组动态链接库（DLL）文件，安装过程本质就是个“解压+放对目录”的过程，不需要像CUDA那样跑一个复杂的安装向导。

4.2 解压后文件放置的两种方式

cuDNN下载后是一个压缩包，解压后会看到这样的目录结构：

cudnn-windows-x86_64-9.x.x.x_cuda12-archive/ ├── bin/ ├── include/ ├── lib/ └── (部分版本还有这几种结构)

把这几个目录里的文件放到CUDA Toolkit安装目录里，是最标准的做法。具体操作是：

把bin目录下的DLL文件复制到CUDA安装目录的bin下；把include目录下的头文件复制到CUDA安装目录的include下；把lib目录下的导入库文件复制到CUDA安装目录的lib\x64下。默认路径就是：

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\

这样做的好处是，后续所有找cuDNN的程序都会去CUDA目录的默认路径寻找，不需要额外配置环境变量。缺点是，如果以后你升级了cuDNN版本，记得要覆盖更新（或者先把旧文件清理掉再复制新的，否则残留的旧DLL可能导致版本混乱）。

另一种方式是保留cuDNN压缩包解压的原始目录，比如放在D:\cudnn\下，然后把D:\cudnn\bin添加进系统PATH环境变量。这种方式适合那些不想动CUDA安装目录的人，但缺点很明显：你需要在PATH里维护额外的路径，而且如果同时安装了多个CUDA版本，需要手动切换cuDNN的路径，很容易搞混。所以对我来说，还是“并入CUDA安装目录”这种方案最直接。

4.3 确认cuDNN已生效

拷贝完成后怎么确认cuDNN生效了？命令行里执行：

where cudnn_ops_infer64_9.dll

如果系统能找到这个DLL文件，就说明cuDNN的bin目录已经在PATH里了。如果你采用的是“复制进CUDA目录”方案，那这一步也是从CUDA的bin路径里找到的。

更保险的验证方式，是写一个小脚本或者直接通过Python检查。假设你已经装了PyTorch，可以运行：

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

其中torch.backends.cudnn.version()会返回cuDNN的版本号，只要能打印出来一个整数，说明Python调用链里的cuDNN没问题。要注意的是，这个输出的是Python包的“CUDNN编译版本”，和系统里安装的cuDNN实际版本可能不是同一个，但它能反映一个大前提：底层DLL能不能正常加载。如果这么查没啥问题，那cuDNN层面基本上是稳了。

5. 验证与常见问题排查

5.1 安装完成后必做的三个验证

我每次装完一套环境，不会直接跑大模型，而是按从小到大的顺序先验证三件事。

第一步，验证驱动与GPU识别。命令行执行nvidia-smi，确认能看到显卡信息。如果这一步就看不到显卡，后面所有问题都不用查了，先解决驱动问题。

第二步，验证CUDA Toolkit。命令行执行nvcc -V，确认nvcc能正常输出版本信息。如果没输出，优先检查环境变量PATH里有没有CUDA的bin目录。

第三步，验证CUDA真正能跑起来。用Python跑一句：

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

输出True和你的显卡名称，说明从应用层到驱动层的整条链路已经通了。如果你平时不用Python，那跑一下deviceQuery.exe也是等效的验证方式。

这三步都过了，再跑你的实际任务，基本就不会出现底层环境问题。

5.2 高频报错：no kernel image is available for execution

这条报错应该是Windows下深度学习用户最常遇到的问题之一。完整错误长长这样：

torch.acceleratorerror: cuda error: no kernel image is available for execution on the device

我把它直接翻译成人话：当前运行的PyTorch版本，它里面编译的CUDA代码（kernel）和你显卡的算力（SM架构）不匹配，或者驱动版本太老，GPU没法执行这个程序。

这句话很简短，但我遇到过的情况一般就这样几种：

第一种，驱动版本太老。显卡是RTX 40系（Ada架构，算力8.9），但驱动还是5xxx系列，很多旧驱动根本不认识新架构的算力标识，即使CUDA版本号对了也没用。解决办法就是更新驱动到最新，然后重启。

第二种，PyTorch版本太老，或者它的CUDA编译版本太老。RTX 40系和50系显卡发布之后，旧版本PyTorch（比如1.8、1.9）预编译的kernel基本都是针对较早架构写的，不包含对安培、Ada或Blackwell等新架构的支持。解决办法是升级PyTorch到较新版本，或者选择对应更高CUDA版本（cu12x）的PyTorch包。

第三种，系统里的两个CUDA共存导致的混乱。比如你装了12.4的CUDA Toolkit，但是PATH里先出现的却是CUDA 11.8的路径，导致PyTorch运行时找到的某些动态库是旧版本的，这种半新半旧状态极易触发kernel不兼容。解决办法是查一下PATH顺序，确保你要用的版本排在前面（具体切法见第6章）。

排查这类问题我建议按这个顺序来：先nvidia-smi看驱动，再nvcc -V看编译工具链版本，然后torch.version.cuda看框架编译版本，最后用torch.cuda.get_arch_list()看当前PyTorch支持哪些GPU架构（返回列表里像sm_86、sm_89、sm_120这类条目）。如果get_arch_list()列表里没有你显卡架构对应的sm_xx，那基本上可以确定是PyTorch版本太老或装错了CUDA变体。

5.3 其他容易踩的坑

除了上面这条大热报错，我把这段时间里反复遇到的其他问题也整理一下，方便你对号入座：

这里额外补充一个小技巧：如果你在Windows下的PATH里同时有多个CUDA目录，它们之间可能出现“路径中存在同名DLL”的问题。Windows查找DLL的时候是按PATH顺序从左到右找的，所以哪个CUDA目录排在前面，应用实际加载的就是哪个。明白了这个机制，后面多版本管理就好理解了。

6. 多版本CUDA的切换与管理

6.1 为什么需要多版本共存

说得直接点，现实情况下你极有可能同时需要两三个CUDA版本。你有一个老项目用的PyTorch是cu118编译的，可另一个新项目需要cu124；或者你在调一个依赖特定CUDA版本的源码项目，同时又要跑官方最新框架的模型。卸载重装来回折腾，一次都要十几分钟，多来几次心态就崩了。

好在Windows下CUDA多版本共存本身没有冲突问题，冲突只发生在外围：PATH环境变量、动态库加载优先级、以及nvcc -V指向哪一个编译器。搞清楚这几点，多版本共存并不复杂。

6.2 Windows下切换CUDA版本的思路

我的做法是：安装不同版本的CUDA Toolkit时都采用默认路径，这样它们的目录天然就是分开的，比如CUDA\v11.8和CUDA\v12.4并存，互不干扰。

切换的核心就是改系统PATH环境变量里CUDA相关路径的顺序。你不需要删除其他版本，只需要把想要生效的那个版本的bin目录移到PATH列表的最前面。

但这有一个副作用——nvcc -V和你编译时的默认工具链确实指向了新版本，可Python/PyTorch不一定买账。因为PyTorch自带CUDA runtime，它不会去系统PATH里找CUDA，更多是直接加载自带库；它只关心驱动是否满足要求。所以很多时候你会发现，nvcc -V是12.4，但PyTorch照样用的它内置的CUDA 12.1运行，两边版本并不需要完全一致，只要驱动兼容就行。

那什么场景下需要精确切换呢？主要就是你自己用CMake、Makefile或PyTorch源码编译扩展时，编译器会通过nvcc和CUDA_PATH变量去找匹配的CUDA。这时候我会写一个简单的批处理脚本，例如switch_cuda.bat：

@echo off :: 切换到 CUDA 12.4 set CUDA_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4 set PATH=%CUDA_PATH%\bin;%CUDA_PATH%\libnvvp;%PATH% nvcc -V

每次在命令行先执行这个脚本，再执行编译或运行命令，就可以在当前会话里加载指定版本，不影响系统全局配置。这个方式比“右键我的电脑→属性→高级系统设置→环境变量→上移下移”那套快太多了，尤其适合频繁切换版本的时候用。

除了环境变量切换法，还有一类更省心的方案：用conda环境隔离版本。如果你平时主力是PyTorch，直接在conda里创建不同环境，分别安装cu118和cu124的PyTorch版本，系统层面甚至不需要安装完整版CUDA Toolkit。因为PyTorch的wheel包自带CUDA runtime，真正被依赖的系统组件只有驱动和cuDNN（且cuDNN也在多数情况下被PyTorch内部链接进去了）。这种“轻量配置”方式我强烈推荐给只做深度学习应用开发、不做底层GPU编程的读者。

7. 补充：WSL2里的CUDA与cuDNN配置要点

7.1 为什么要在WSL2里装CUDA

Windows下做开发，很多人最终还是会绕进WSL2。原因很直接：Linux生态下的命令行工具链更顺手，很多深度学习项目在Linux上部署起来更平滑，而且Docker容器在WSL2里跑GPU也稳定得多。

WSL2里使用CUDA有一个巨大的简化点：GPU驱动和CUDA Toolkit是分开的，WSL2本身不需要单独安装GPU驱动。Windows宿主机上装好NVIDIA驱动后，WSL2里面就能直接访问GPU。你需要做的，是在WSL2内部安装CUDA Toolkit，以及必要的cuDNN库。这个设计帮我省掉了在Linux子系统里折腾GPU驱动的大部分麻烦。

7.2 WSL2中的CUDA安装要点

如果在WSL2里安装CUDA Toolkit，最省事的做法是用NVIDIA官方提供的apt仓库，而不是下载Linux安装包手动装。我记录一下在WSL2 Ubuntu 22.04/24.04上的大致流程：

# 添加NVIDIA官方软件源 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 # 安装需要的CUDA版本 sudo apt-get install cuda-toolkit-12-4

安装完成后，在当前shell里追加环境变量（也可以写进~/.bashrc）：

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

WSL2里/usr/local/cuda通常是一个软链接，指向当前默认的CUDA版本目录。所以如果同时装了多个版本，你直接改这个软链接的指向就能切换默认版本：

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

这套操作思路在Windows本机上也适用，只是它的“软链接”概念换成了“注册表环境变量”。理解了底层逻辑，换到哪个平台都顺手。

7.3 WSL2中验证GPU是否可用

装完CUDA之后，在WSL2里同样要跑一遍验证。我一般执行这几步：

nvidia-smi nvcc -V

然后跑Python验证：

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

如果在WSL2里输出的是Windows宿主机上的NVIDIA显卡名称，比如“NVIDIA GeForce RTX 3060 Ti”，说明GPU透传没问题，WSL2里的CUDA工具链工作正常。cuDNN的安装则通常和Linux下一致：从NVIDIA官网下载cuDNN for WSL/Ubuntu的deb包或tar包，安装后把cudnn的动态库放入LD_LIBRARY_PATH，再执行和Windows版一样的Python验证即可。

8. 我的个人习惯与最后一点建议

关于CUDA和cuDNN的安装配置，我踩过不少坑，最后形成的固定流程大体是：先看驱动版本，再根据框架锁版本，最后才动手装。并且在第一次验证通过之后，我会立刻用conda create建一个干净的测试环境，把torch + torchvision + torchaudio装进去，跑一个几十行的小分类模型，确认从数据搬到GPU、子模块初始化、反向传播这条链路都通。这个过程看似多花了10分钟，实际能省掉后面定位环境问题的一整天。

还有一个小习惯想分享：CUDA安装包和cuDNN压缩包下载下来之后，我会在本地留一个带版本号的存档目录，比如D:\installers\cuda_12.4.0_551.86_windows.exe、cudnn-windows-x86_64-9.5.1.17_cuda12-archive.zip。因为NVIDIA官网的历史版本页面偶尔会调整入口，几个月之后再想找回某个旧版本，有本地存档会从容很多。

配置CUDA和cuDNN这件事，本质上就是“把版本对应关系搞对，把环境变量指对”。只要按流程一步步来，它并没有网上传的那么玄乎。这套环境配好之后，后面无论是跑PyTorch、TensorFlow，还是自己写CUDA扩展，都会顺很多。希望这篇文章能帮你少走几次弯路，一次把环境理清楚。