并行编程实战—验证cuDNN是否安装成功

一、cuDNN安装后验证的问题

在前面的cuDNN安装验证中(CUDA环境的安装之高版本更新)，使用了Pytorch框架的相关Python脚本进行处理。但在后续的不断深入中，发现了一个细节问题。下面是使用脚本验证的结果：

PyTorch安装信息: PyTorch版本: 2.10.0+cu126 CUDA可用: True CUDA版本: 12.6 cuDNN启用: True GPU数量: 1 当前GPU: NVIDIA GeForce GTX 960 GPU内存: 4.29 GB cuDNN操作测试: 成功 cuDNN版本: 91002

当时也没有注意，发现其最后一行“cuDNN版本: 91002”，版本号与实际安装的不一致（实际安装的是cuDNN8.9.7.29,上篇文章写成8.7了，不过截图是8.9）啊。先是从网上搜索，发现有不少的回答说是Pytorch框架自定义的返回错误值，这下有点小慌。不过前面对应的测试代码和相关的cuDNN的调用都是通过的。

二、具体情况说明

经过更深入的资料查找和相关细节的查询，发现91002代表的是cuDNN9.10.0.2，是一个较新的版本。而且Pytorch为了更好的利用cuDNN库会预编译优化过的相关库。也就是说，自行安装的cuDNN并不会影响到Pytorch框架的应用。这也意味着，网上提出的利用Pytorch来验证cuDNN是否安装成功不适合于手动安装的这种情况。
回忆一下Pytorch的安装，是使用pip命令进行的（使用conda也是如此）。其二进制包内会自带cuDNN，在前面的验证程序中，其实就是调用了框架自身的cuDNN版本的库，所以返回的版本信息与实际安装的显示不同。这种情况自Pytorch2.3以后，就基本这样了。
从目前得到信息来看，这种情况并不影响使用，而且也不推荐手动将Pytorch中的cuDNN显式的指定到手动安装的系统中的 cuDNN(即8.9版本)。这是一种正常的现象，不需要进行处理，除非有特殊的兼容的需求情况。
此处顺带说一下，在查找资料的过程发现，TensorFlow自2.11版本后，不再支持Windows平台上的GPU处理。如果想在Windows平台应用GPU版本的TensorFlow，则只能使用 TensorFlow 2.10 + CUDA 11.2 + cuDNN 8.1。此处先做个备份，省得未来安装时踩这个坑。

三、实例

既然前面的例程无法证明本地的cuDNN是否安装成功，那么如何怎么样才能真正证明本地的cuDNN可用呢？已经有了CUDA的环境，那就直接上。使用CUDA利用C++直接调用相关的库接口。看代码：

#include<iostream>#include<cudnn.h>intmain(){std::cout<<"获取当前安装的cuDNN环境"<<std::endl;// 获取 cuDNN 版本size_tver=cudnnGetVersion();std::cout<<"当前环境安装的cuDNN版本: "<<ver<<std::endl;// 获取版本细节intmajor=ver/1000;intminor=(ver%1000)/100;intpatch=(ver%100)/10;std::cout<<"版本号管理的版本为: "<<major<<"."<<minor<<"."<<patch<<std::endl;// 创建操作句柄cudnnHandle_th;cudnnStatus_tstatus=cudnnCreate(&h);if(status==CUDNN_STATUS_SUCCESS){std::cout<<"成功创建操作句柄!"<<std::endl;cudnnDestroy(h);std::cout<<"操作句柄已经销毁!"<<std::endl;return0;}else{std::cerr<<"操作句柄创建失败! 错误码: "<<status<<std::endl;return1;}return0;}

相关代码的处理为：

1. 在VC环境中创建一个控制台项目

2. 将上面代码拷贝到主文件

3. 配置相关的头文件和库目录路径
   右键项目属性：
   VC++目录 =>包含目录,添加 CUDA include 路径（本文为：C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.6\include）
   VC++目录 => 库目录：添加 CUDA lib 路径（本文为C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.6\lib\x64）
   

4. 配置链接库
   链接器 => 输入 => 附加依赖项：添加 cudnn.lib
   

5. 重新编译并运行

得到的运行结果为：

获取当前安装的cuDNN环境 当前环境安装的cuDNN版本: 8907 版本号管理的版本为: 8.9.0 成功创建操作句柄! 操作句柄已经销毁!

四、总结

“正入万山圈子里，一山方出一山拦”。虽然说不会影响使用，但安装好却无法证明确实是一个重要的问题。版本的迭代和映射太复杂了，一不小心就会出现各种各样的问题。其实Pytorch这样做应该是更妥贴的，防止出现版本不匹配的现象出现。但这也从另外一个层面屏蔽了底层安装的一种验证机制，这就是一个如何看待场景应用的问题了。