简介：cuDNN 8.9.7 for CUDA 11.x 是一套面向深度学习开发者的专用加速库，主要解决 CUDA 11.x 环境中卷积、池化、归一化等神经网络算子执行效率偏低的问题，适合使用 TensorFlow、PyTorch 搭建训练或推理环境，以及通过 C/C++ 调用 cuDNN API 的自研推理引擎。压缩包共包含 32 个文件：9 个 .h 头文件提供完整 API 声明，14 个 .lib 导入库用于编译链接，7 个 .dll 动态运行库供程序运行时加载，另附 readme.txt 与 LICENSE 说明安装要点和授权范围，包体大小 671.62MB。资源对应官方 cudnn-windows-x86_64-8.9.7.29_cuda11-archive 版本，目录保留 include、lib、bin 三段式结构，拿到后可直接替换或对齐 CUDA 安装目录，减少自行收集文件带来的版本不一致风险，提升训练与推理的算子执行速度。使用这套配套文件还可避免因版本不匹配导致的程序启动失败或异常结果，省去手工编译与四处搜寻文件的步骤。目前已有 1201 人学习下载，适合需要稳定复现训练实验、在 Windows 上完成标准深度学习环境配置的中高级用户。
1. 为什么这个版本组合值得单独写一篇
前两天帮朋友调一个训练脚本，torch.cuda.is_available()明明返回 True，可一跑卷积网络就直接报CUDNN_STATUS_EXECUTION_FAILED。排查了半天，最后发现是系统里有三套 cuDNN 在打架——conda 一套、系统路径一套、CUDA 自带的又一套。这种乱象在深度学习环境配置里太常见了，尤其是 cuDNN 8.9.7 配 CUDA 11.x 这个组合，正好卡在 PyTorch 官方预编译包的依赖区间里，用的人特别多，踩坑的也特别多。
cuDNN 8.9.7 for CUDA 11.x，本质上是 NVIDIA 针对 CUDA 11 系列发布的一个深度学习加速库版本。CUDA 11.x 系列覆盖了 11.0 到 11.8 等多个小版本，而 cuDNN 8.9.7 是 8.9 系列里对 CUDA 11 支持最完整、也是最后一个大规模铺开的稳定版本之一。很多人在网上搜这个组合，是因为 PyTorch 2.x 的官方安装命令里明确写着依赖cuDNN 8.9.7，如果你用的是 CUDA 11.8 的 PyTorch 轮子，那么对应匹配的 cuDNN 就是这个版本。
这篇文章面向的是需要在 Linux 服务器或本机配置深度学习环境的开发者，尤其是用 PyTorch 跑 CV 模型的场景。我会把这套组合的安装思路、底层版本匹配逻辑、核心操作步骤、以及我在实际环境中遇到的坑全部拆开讲清楚，保证你看完能少走弯路。
2. 先搞懂 cuDNN 和 CUDA 的关系，再动手装
2.1 cuDNN 不是独立软件，它是 CUDA 的加速插件
很多新手容易把 cuDNN 和 CUDA 搞混，觉得这是两个并列的东西。实际上，CUDA 是 NVIDIA 的通用 GPU 计算平台，它负责最底层的 GPU 调度、内存管理、内核执行；而 cuDNN（CUDA Deep Neural Network library）是建立在 CUDA 之上的专用深度学习加速库，专门优化卷积、池化、归一化、激活函数这些深度学习中高频出现的运算。
打个比方，CUDA 像是给你一套完整的工具箱，里面有扳手、螺丝刀、电钻；cuDNN 则是针对"拧螺丝"这个具体场景，单独做了三个特制螺丝刀头，不仅好用，而且拧得比通用工具快得多。PyTorch、TensorFlow 这些框架在 GPU 上跑卷积时，底层调用的不是自己写的卷积实现，而是直接调用 cuDNN 的 API。所以 cuDNN 版本不对、损坏或缺失，框架层面不一定报错，但跑起来要么极慢，要么直接崩溃。
cuDNN 的版本号和 CUDA 版本号是两套体系。cuDNN 8.9.7 的意思是，这是 cuDNN 的第 8 个大版本，9 是特性版本，7 是补丁版本。而它支持哪些 CUDA 版本，由 NVIDIA 官方在发布说明里通过支持矩阵来定义，不能你自己觉得"都是 11 应该没问题"就乱配。
2.2 为什么是 8.9.7 而不是最新的 9.x
cuDNN 9.x 已经在 2024 年底逐步铺开了，但 PyTorch 官方稳定版的预编译包目前很多还是依赖 cuDNN 8.x。特别是pip install torch默认安装的 CUDA 11.8 版本，其内部要求的 cuDNN 版本范围就指向 8.9.x。你如果强行给 PyTorch 2.1/2.2 配一个 cuDNN 9.x，很有可能在导入 torch 时直接报undefined symbol之类的链接错误，或者运行时CUDNN_STATUS_NOT_INITIALIZED。
用 cuDNN 8.9.7 配 CUDA 11.x，有这几个核心理由：
- 兼容性经过大量验证。PyTorch 官方 CI 在 CUDA 11.8 环境下用的就是 cuDNN 8.9.7，这是最稳的组合之一。
- 训练和推理性能表现稳定。8.9 系列引入了对 Ampere 架构（A100/A30 等）的进一步优化，同时也保留了对 Turing、Volta 的较好支持。
- 不强迫升级系统 CUDA。很多生产环境的 CUDA 是 11.4 或 11.8，不能随便动，cuDNN 8.9.7 对 CUDA 11.x 全系列都兼容，不需要你动已有的 CUDA 安装。
2.3 CUDA 11.x 内部的小版本差异
CUDA 11.x 不是一个单一版本，我见过不少人在这一步栽跟头。CUDA 11.0、11.1、11.2、11.3、11.4、11.5、11.6、11.7、11.8 这九个版本，虽然都属于 11.x 系列，但配套的驱动程序要求、GPU 架构支持、以及 PyTorch 对应关系都有差异。
cuDNN 8.9.7 的官方支持矩阵里，明确列出了它支持 CUDA 11.0 到 11.8 的所有小版本。但实际使用中，我建议你在满足框架要求的前提下，优先使用 CUDA 11.8。原因很简单：PyTorch 官方对 CUDA 11.8 的支持最完善，而且 cuDNN 8.9.7 对 CUDA 11.8 的验证也最充分。如果你用的是 CUDA 11.4 或更低版本，虽然也能装上，但部分新特性可能不会生效，比如某些针对 Ampere 架构的 TF32 优化。
还有一个容易忽略的点：nvidia-smi输出的 Driver Version 和你实际用的 CUDA Toolkit 版本是两码事。驱动是驱动，Toolkit 是你安装的开发库。cuDNN 只依赖 Toolkit，不直接依赖驱动，但驱动版本太低会导致 Toolkit 根本跑不起来。所以如果你nvidia-smi显示驱动是 450 以下的版本，先把驱动升上去再谈 cuDNN。
3. 安装 cuDNN 8.9.7 的完整实操流程
3.1 第一步：检查环境现状
在动手之前，建议先花两分钟把环境摸清楚。打开终端执行以下命令：
# 查看 GPU 型号和驱动版本 nvidia-smi # 查看已安装的 CUDA Toolkit 版本 nvcc --version # 查看系统里已有的 cuDNN（如果有的话） find /usr -name "cudnn*.h" 2>/dev/null find /usr -name "libcudnn*" -type f 2>/dev/null为什么要先做这一步？我遇到过太多人装完 cuDNN 发现"没生效"，最后发现是系统里本来就有一套旧版 cuDNN，新装的被覆盖了，或者压根没装到对的地方。特别是很多 Linux 发行版自带/usr/lib/x86_64-linux-gnu/下的库，如果你后来又手动编译安装了别的路径，很容易出现冲突。
执行完之后，你需要确认三件事：GPU 驱动版本是否支持 CUDA 11.x（建议 450.80.02 以上，最好 470+）；nvcc --version显示的 Toolkit 版本是哪个；系统中是否已有 cuDNN 残留。
3.2 第二步：从官网下载正确的安装包
这一步是坑最多的，我把它单独展开讲。
登录 NVIDIA Developer 官网的 cuDNN 下载页面，选择 "Download cuDNN v8.9.7 for CUDA 11.x"。这里会出现多个文件类型，常见的有：
Local Installer for Linux x86_64 (Tar)——tar 包，需要手动解压和配置，推荐用这个。Local Installer for Linux x86_64 (Deb)——deb 包，适用于 Ubuntu/Debian 系，直接dpkg -i安装。Windows和WSL的安装包——对应平台选择。
我为什么推荐 tar 包而不是 deb 包？虽然 deb 包一条命令就装完了，看起来省事，但它有两个问题：一是它会把文件覆盖到系统默认路径，如果系统里有一个 conda 或其他软件自己带的旧版 cuDNN，容易出现"系统层面是新版、虚拟环境里是旧版"的混乱；二是卸载起来不如 tar 包干净，想回退版本会很麻烦。
下载完成后，确认文件的 SHA256 校验值是否和官网一致。这一步很多人忽略，但一旦下载文件损坏，装完会出现各种诡异的运行时错误，排查起来极其痛苦。校验命令：
sha256sum cudnn-linux-x86_64-8.9.7.29_cuda11-archive.tar.xz常见的损坏表现是解压时直接报错，这在安装阶段就能暴露；但有些文件解压没问题，实际使用时才会崩，所以校验这步别省。
3.3 第三步：解压并放置文件
假设你下载的是cudnn-linux-x86_64-8.9.7.29_cuda11-archive.tar.xz，执行：
# 解压 tar -xvf cudnn-linux-x86_64-8.9.7.29_cuda11-archive.tar.xz # 进入解压目录 cd cudnn-linux-x86_64-8.9.7.29_cuda11-archive解压后的目录结构里会有include/、lib/两个核心目录。我们需要把其中的头文件和库文件放到 CUDA Toolkit 的安装目录里。
首先确认你的 CUDA Toolkit 装在哪里，常见路径是/usr/local/cuda，这是一个软链接，指向具体的版本目录如/usr/local/cuda-11.8。可以用ls -l /usr/local/cuda查看它指向哪里。
然后执行复制操作：
# 将头文件复制到 CUDA 的 include 目录 sudo cp include/cudnn*.h /usr/local/cuda/include/ # 将库文件复制到 CUDA 的 lib64 目录 sudo cp lib/libcudnn* /usr/local/cuda/lib64/ # 修改权限（这一步很重要，很多新手漏掉） sudo chmod a+r /usr/local/cuda/include/cudnn*.h sudo chmod a+r /usr/local/cuda/lib64/libcudnn*为什么要chmod a+r？因为源文件默认权限可能不包含其他用户的可读权限，如果你用非 root 用户跑训练程序，读取权限不足会导致程序启动时找不到头文件或库文件。我踩过一次这个坑，症状很奇怪——root 用户能跑，普通用户跑就直接error while loading shared libraries，后来发现就是权限问题。
3.4 第四步：建立软链接
复制完文件后，/usr/local/cuda/lib64/下会看到几个库文件，但注意它们的命名方式。cuDNN 的库文件名称带有版本后缀，比如libcudnn.so.8，而程序和 PyTorch 加载时默认找的是不带版本号的libcudnn.so。所以需要建立软链接。
cd /usr/local/cuda/lib64/ # 先删除可能存在的旧软链接（如果有的话） sudo rm -f libcudnn.so sudo rm -f libcudnn_ops.so sudo rm -f libcudnn_adv.so sudo rm -f libcudnn_cnn.so # 创建新的软链接 sudo ln -s libcudnn.so.8 libcudnn.so sudo ln -s libcudnn_ops.so.8 libcudnn_ops.so sudo ln -s libcudnn_adv.so.8 libcudnn_adv.so sudo ln -s libcudnn_cnn.so.8 libcudnn_cnn.so这里有个容易混淆的地方：8.9.7 版本把原来的libcudnn.so.8拆成了多个子库（ops、adv、cnn），这是 cuDNN 8.x 中后期引入的架构调整。如果你只是简单地把旧版的libcudnn.so.8映射到libcudnn.so，而忽略了另外几个子库，PyTorch 在运行时还是会报找不到符号的错误。所以务必检查这四组库的软链接是否都建立好了。
3.5 第五步：配置动态链接器
Linux 系统的动态链接器负责在程序运行时找到.so文件。我们需要确保系统知道去哪里找 cuDNN 的库。有两种方式，推荐第二种。
方式一：临时设置环境变量（只对当前终端有效）
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}方式二：写进系统的 ld 配置（全局生效，推荐）
# 创建 CUDA 的 ld 配置文件 sudo bash -c 'echo "/usr/local/cuda/lib64" > /etc/ld.so.conf.d/cuda.conf' # 重载动态链接器缓存 sudo ldconfig很多人装完 cuDNN 之后运行程序还是提示libcudnn.so.8: cannot open shared object file，问题就出在这一步。/usr/local/cuda/lib64不在系统的默认搜索路径里，必须通过ldconfig把它加进去。注意，LD_LIBRARY_PATH和ldconfig的区别在于：前者是每次终端会话都要重新 export 的临时变量，重启终端就失效了；后者是写入系统配置，全局生效。
我用ldconfig配置完之后，会顺手检查一下是否成功加载：
ldconfig -p | grep cudnn如果输出里能看到libcudnn.so.8，说明链接器已经找到了。如果什么都没有，检查一下/etc/ld.so.conf.d/cuda.conf文件内容是否写对了，以及ldconfig是否以 root 权限执行。
3.6 第六步：验证安装结果
安装完不能只看文件在不在，必须实测一下能不能被正确加载。先做一个基础的运行时检查：
# 动态库加载测试 ldconfig -p | grep cudnn # 编译验证一下头文件和库的版本一致性 cat /usr/local/cuda/include/cudnn_version.h | grep CUDNN_MAJOR -A 2然后写一个最简单的 C 程序来调用 cuDNN API，验证整个链路是通的：
// test_cudnn.c #include <cudnn.h> #include <stdio.h> int main() { cudnnHandle_t handle; cudnnStatus_t status = cudnnCreate(&handle); if (status != CUDNN_STATUS_SUCCESS) { printf("cudnn create failed: %d\n", status); return 1; } cudnnVersion_t version; cudnnGetVersion(&version); printf("cudnn version: %d.%d.%d\n", version.major, version.minor, version.patch); cudnnDestroy(handle); return 0; }编译并运行：
gcc -o test_cudnn test_cudnn.c -I/usr/local/cuda/include -L/usr/local/cuda/lib64 -lcudnn如果输出类似cudnn version: 8.9.7，说明安装成功了。这里要注意，编译时-lcudnn链接的就是libcudnn.so，也就是我们之前建立软链接的那个库。
接下来用 Python 验证 PyTorch 是否能识别到 cuDNN 版本：
import torch print(torch.backends.cudnn.version()) print(torch.cuda.is_available())如果能打印出8907和True，说明 PyTorch 已经通过 CUDA 找到了 cuDNN 8.9.7。值得注意的是，torch.backends.cudnn.version()返回的是编码后的版本号，8.9.7 对应的是 8907，不是 897，这个细节经常被搞混。
4. 常见问题与排查技巧实录
4.1 问题一：PyTorch 报错CUDNN_STATUS_NOT_INITIALIZED
这个错误基本可以断定是 cuDNN 版本不匹配。我在排查这类问题时，第一步先看的是 PyTorch 的预编译依赖目标：
python -c "import torch; print(torch.version.cuda)"如果输出11.8，那你安装的 cuDNN 必须是支持 CUDA 11.8 的版本。cuDNN 8.9.7 支持，但如果系统里还有一套 cuDNN 8.2 或者更老的版本，并且它的库文件路径排在前面，程序就会加载到旧版本，然后报错。
解决办法是检查当前的库搜索顺序：
python -c "import torch; print(torch.__file__)"去torch包目录下的lib/看看有没有libcudnn.so.8。PyTorch 的 pip 包会自带一小部分 cuDNN 库，但版本通常只覆盖到它要求的那个基准。如果它是一个旧版 PyTorch 自带的 cuDNN 8.0/8.1，而你的 CUDA 是 11.8，就很可能因为版本过旧出问题。此时有两种处理方式：一是升级 PyTorch 到与 CUDA 11.8 + cuDNN 8.9.7 匹配的版本；二是用 conda 安装指定版本的 PyTorch，它会拉取配套的 cuDNN。
4.2 问题二：libcudnn.so.8找不到
这个在 3.5 节已经提到了，核心原因就是 ldconfig 没配好或者路径不对。但我要补充一个容易被忽略的场景：如果你在用 conda 管理 Python 环境，且 conda 环境里有自己的lib/目录，那么 conda 环境下运行的 Python 程序可能会优先加载 conda 环境里的库，而不是系统的/usr/local/cuda/lib64。
检查方式：
python -c "import ctypes; ctypes.cdll.LoadLibrary('libcudnn.so.8'); print('load success')"如果加载失败，看一下环境变量：
echo $LD_LIBRARY_PATHconda 环境激活时会把它的lib/加到LD_LIBRARY_PATH里。如果你的 conda 环境里没有 cuDNN，但又占用着搜索路径，就会导致系统路径里的 cuDNN 找不到。此时可以用：
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH但要注意，这个方案是临时的。长期方案是在 conda 环境里显式安装 cuDNN：
conda install cudnn=8.9.7 cuda-version=11.84.3 问题三：显存充足但卷积训练极慢
这个问题比较隐蔽——程序不报错，但你发现训练速度比预期慢好几倍，GPU 利用率却只有百分之几十。绝大多数情况下，是 PyTorch 没有正确开启 cuDNN 的 benchmark 模式，或者是 cuDNN 版本与实际 GPU 架构不匹配。
先说 benchmark，PyTorch 里默认torch.backends.cudnn.benchmark是False。对于固定输入尺寸的 CV 训练任务，建议开启：
torch.backends.cudnn.benchmark = True这样 cuDNN 会在启动时跑一小段自动调优，选择当前输入尺寸和 GPU 架构下的最优卷积算法，速度提升可能在 20% 到 50% 之间。
再检查你的 GPU 架构是否被 cuDNN 8.9.7 完整支持。如果你用的是 GTX 10 系列（Pascal 架构）的老卡，虽然 CUDA 11.x 核心是支持 Pascal 的，但 cuDNN 8.9 系列对 Pascal 的优化已经不如 Ampere 和 Turing 那么激进，你可以自行对比一下是否值得用旧版 cuDNN。如果用的是 A100/A800 这类 Ampere 卡，8.9.7 是完全没有问题的，9.x 对 Ampere 的支持虽然也在，但 PyTorch 官方还没完全切过去之前，我建议还是用 8.9.x 更稳。
4.4 问题四：多套 CUDA 版本的冲突
一台机器上装了 CUDA 11.4 和 CUDA 11.8 两个版本，或者系统里既有/usr/local/cuda-11.8又有/usr/local/cuda软链接，这种情况在共享服务器上很常见。
我的处理原则是：/usr/local/cuda这个软链接指向当前默认使用的 CUDA 版本。你安装了 cuDNN 8.9.7 的文件到/usr/local/cuda/lib64/，其实是放到了软链接指向的真实目录里。如果你的nvcc显示的是另一个版本（比如 11.4），那就可能引发混乱。
排查方法：
# 查看软链接指向 ls -l /usr/local/cuda # 同样检查 nvcc 的实际路径 which nvcc如果你确实需要共存多个 CUDA 版本，最好用update-alternatives来管理，或者每次切换时只改PATH和LD_LIBRARY_PATH。但我要提醒你，cuDNN 是放在具体的 CUDA 目录里的，不是"对系统全局生效"，所以你得给每个 CUDA 版本都装一个对应的 cuDNN 文件，或者直接用 conda 环境来隔离。
4.5 问题五：Windows 下的安装差异
虽然前面主要讲的是 Linux，但 Windows 下也有不少人用 cuDNN 8.9.7 配 CUDA 11.x。Windows 的安装步骤与 Linux 高度相似，几个关键差异需要特别注意：
- 下载 Windows 版本的 zip 压缩包，而不是 tar.xz。
- 解压后的
cuda/bin/、cuda/include/、cuda/lib/x64/三个目录里的文件，要分别复制到 CUDA 安装目录（默认是C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\）的对应子目录。 - 不需要手动配置
ldconfig，但需要手动把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin添加到系统PATH环境变量。如果不加，Python 程序运行时可能直接报DLL load failed。 - 注意杀毒软件可能会把
cudnn_ops64_8.dll这类动态库文件误判为可疑程序，我第一次在 Windows 上装时就遇到 Windows Defender 把bin\cudnn_ops64_8.dll直接隔离了，运行时报FileNotFoundError。解决办法是先把目录加入白名单，再复制文件。
5. 实际使用中的性能验证与配置建议
装好之后，我建议不要直接跑完整的大规模训练，先用一个小规模的模型做一次基准测试，确认 cuDNN 的加速确实生效了。用 PyTorch 跑一个简单的 ResNet-18 在 ImageNet 子集上的训练，对比开启和关闭 cudnn 的耗时差异：
import torch import torch.nn as nn import torchvision.models as models import time model = models.resnet18().cuda() input_tensor = torch.randn(32, 3, 224, 224).cuda() criterion = nn.CrossEntropyLoss() # 关闭 cudnn 测试 torch.backends.cudnn.enabled = False start = time.time() for _ in range(50): output = model(input_tensor) loss = criterion(output, torch.randint(1000, (32,)).cuda()) loss.backward() print("cudnn disabled:", time.time() - start) # 开启 cudnn 测试 torch.backends.cudnn.enabled = True torch.backends.cudnn.benchmark = True start = time.time() for _ in range(50): output = model(input_tensor) loss = criterion(output, torch.randint(1000, (32,)).cuda()) loss.backward() print("cudnn enabled:", time.time() - start)正常情况下，开启 cuDNN 后，尤其是 CNN 网络，耗时会有 30% 以上的下降。如果速度没有明显提升，或者开启前后几乎一样，那很可能你的 cuDNN 没被真正调用，重新检查一下安装路径是否被 PyTorch 识别到。
还有一个我在实际项目中特别关注的点：多卡训练时，torch.nn.DataParallel或DistributedDataParallel环境下，每张卡都会独立初始化 cuDNN handle。如果 cuDNN 版本不一致（比如一台机器上多卡但环境不统一），会导致部分卡的benchmark自动调优结果不同，进一步导致训练不收敛或结果抖动。所以多卡机器的环境一致性极其重要，所有卡跑在同一个 cuDNN 版本上是基本要求。
另外，如果你在跑推理服务（比如用 TensorRT 部署模型），那 cuDNN 的验证逻辑又不太一样。TensorRT 在构建 engine 时会把 cuDNN 的算法选择固化到 engine 文件里，所以同一台机器换 cuDNN 版本后，旧的 TensorRT engine 可能就失效了，需要重新构建。这个点容易被做部署的同学忽略，他们以为是 cuDNN 没装好，其实是 engine 缓存过期了。
6. 一个值得养成的习惯：用 nvidia-smi 与全链路日志交叉验证
关于版本验证，我想分享一个自己摸索出来的习惯：不要只看安装成功，也不要只看torch.cuda.is_available()，那只是入口。你需要的是一条完整的证据链。
我会依次查看：
nvidia-smi确认驱动支持 CUDA 版本。nvcc --version确认 Toolkit 版本。ldconfig -p | grep cudnn确认动态链接器能找到 cuDNN。python -c "import torch; print(torch.backends.cudnn.version())"确认 PyTorch 层面加载的版本。- 跑一个包含卷积和反向传播的小模型，确认 cuDNN 路径不是直接 fallback 到 PyTorch 的 CPU 实现。
这五步全部对齐之后，环境才算是真正可靠的。很多人在第 2 步和第 4 步之间迷失，就是因为没有把 "Toolkit 版本" 和 "PyTorch 实际加载的运行时版本" 区分开。Toolkit 提供编译环境和头文件，运行时加载的是系统里的.so/.dll文件，两者可以不一致，然后就会出问题。
我还习惯把 cuDNN 的安装和验证命令写成一个 shell 脚本，放在公共环境里。这样团队里任何人换机器或者重建环境，都能用同一个脚本快速完成部署，不会出现一个人一个装法的问题。脚本里我会留一个-c参数用来指定 CUDA 版本，方便适配不同型号的服务器。
最后再提醒一句：cuDNN 版本升级前务必备份现有的环境。虽然 8.9.7 覆盖了 CUDA 11.x 全系列，但如果你之后想切到 CUDA 12.x，那 cuDNN 也要跟着换到对应的版本，二者不能混用。保持环境干净、版本一致，是深度学习项目稳定运行的最底层保障。
本文还有配套的精品资源，点击获取
