1. 为什么这套组合至今仍值得折腾
深度学习环境搭建这件事，做过的人都知道，它不像装个普通软件那样一路下一步就完事。版本之间的依赖关系、驱动与运行时的匹配、编译工具链的兼容性，任何一个环节出问题都可能让你在终端前面坐一下午。Ubuntu 18.04 下安装 CUDA 10.2 + cuDNN 8 + TensorRT 6.0 这套组合，放在今天来看似乎有些"复古"，但实际工作中仍然有大量场景需要它——比如维护老项目的推理服务、复现某些论文的实验环境、或者在特定硬件上跑通一套已经验证过的部署方案。
我自己就因为一个边缘计算设备的推理项目，不得不把环境锁死在这套版本上。前后折腾了大概三四天，踩了不少坑，也总结出了一些相对稳妥的流程。这篇文章不是官方文档的翻译，而是把我实际操作的步骤、遇到的问题、以及一些文档里不会写的细节完整记录下来。如果你正好需要搭建类似的环境，希望能帮你少走一些弯路。
先说清楚这套组合的定位：CUDA 10.2 是 NVIDIA 在 2019 年底发布的长期支持版本，cuDNN 8 是配套的深度神经网络加速库，TensorRT 6.0 则是推理阶段的优化引擎。三者版本必须严格对应，否则轻则编译报错，重则运行时出现莫名其妙的段错误。Ubuntu 18.04 作为当时的主流 LTS 系统，对这套组合的支持最为成熟，社区里能找到的参考资料也最多。
适合阅读这篇文章的人：需要在 Ubuntu 18.04 上搭建深度学习推理环境的开发者、维护老项目的工程师、以及想了解 CUDA 生态版本管理逻辑的学习者。如果你用的是更新的系统或更新的 CUDA 版本，部分步骤需要调整，但整体思路是相通的。
2. 环境准备与版本选型逻辑
2.1 硬件与系统的前置检查
在动手之前，有几项检查必须做，否则后面出了问题你都不知道从哪查起。第一件事是确认显卡型号是否在 CUDA 10.2 的支持列表里。CUDA 10.2 支持的算力范围是 3.0 到 7.5，也就是说图灵架构（算力 7.5）是它支持的最后一代。如果你用的是安培架构（算力 8.0 及以上）的卡，这套组合直接跑不起来，不用浪费时间。
检查显卡型号和算力的命令很简单：
nvidia-smi如果这条命令能正常输出显卡信息，说明驱动已经装好了。如果提示命令找不到，说明驱动还没装或者装的有问题。这里有个经验：Ubuntu 18.04 自带的 nouveau 开源驱动会和 NVIDIA 官方驱动冲突，安装官方驱动前需要先禁用它。具体做法是在/etc/modprobe.d/目录下创建一个黑名单文件：
sudo bash -c "echo 'blacklist nouveau' > /etc/modprobe.d/blacklist-nouveau.conf" sudo bash -c "echo 'options nouveau modeset=0' >> /etc/modprobe.d/blacklist-nouveau.conf" sudo update-initramfs -u执行完需要重启系统。重启后用lsmod | grep nouveau检查，如果没有输出，说明禁用成功。
关于驱动版本的选择，CUDA 10.2 要求驱动版本不低于 440.33。我实测下来用 440 系列的驱动最稳，450 系列也能用但偶尔会有兼容性提示。驱动安装方式有两种：用系统包管理器装，或者用 NVIDIA 官方 runfile 装。我推荐用包管理器，因为后续升级和卸载都方便：
sudo apt-get update sudo apt-get install nvidia-driver-440装完重启，再用nvidia-smi确认。输出的右上角会显示当前驱动支持的 CUDA 版本，这个版本号只要大于等于 10.2 就行，不用完全一致。
2.2 为什么选 CUDA 10.2 而不是其他版本
这个问题值得展开说说。CUDA 版本的选择不是越新越好，而是要看你的下游依赖。TensorRT 6.0 官方明确支持的 CUDA 版本就是 10.2，cuDNN 8 也是在这个 CUDA 版本上验证最充分的。如果你强行用 CUDA 11 配 TensorRT 6.0，编译阶段可能就过不去，因为 TensorRT 6.0 的库文件是针对 CUDA 10.2 的 ABI 编译的。
另一个考虑是 GCC 版本。Ubuntu 18.04 默认的 GCC 是 7.5，这个版本正好在 CUDA 10.2 的支持范围内。CUDA 10.2 支持的 GCC 上限是 8.x，如果你系统里装了 GCC 9 或更高版本，编译 CUDA 示例代码时会报"unsupported GNU version"的错误。解决办法是用update-alternatives切换默认 GCC 版本，或者直接在编译时指定：
sudo apt-get install gcc-7 g++-7 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 70 sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 70这里有个细节：update-alternatives的优先级数字（上面写的 70）只是个权重，数字大的会被优先选中。如果你系统里已经有其他版本的 GCC，可以用update-alternatives --config gcc手动切换。
2.3 安装方式的取舍：runfile 还是 deb
CUDA 的安装有两种主流方式：runfile 和 deb 包。这两种方式各有优劣，我分别说一下实际体验。
deb 包方式的好处是走系统包管理器，安装路径规范，卸载干净。但缺点是它会自动把驱动也装一遍，如果你已经手动装过驱动，可能会造成冲突。而且 deb 方式安装的 CUDA 默认路径在/usr/local/cuda-10.2，软链接/usr/local/cuda会自动指向它。
runfile 方式的好处是灵活，安装时可以取消勾选驱动安装，只装 CUDA 工具包。缺点是卸载麻烦，而且如果安装过程中出错，残留文件不好清理。
我最终选的是 runfile 方式，因为我不想让它动我已经装好的驱动。下载地址在 NVIDIA 官网的 CUDA 存档页面，选择 CUDA Toolkit 10.2，系统选 Linux，架构选 x86_64，发行版选 Ubuntu 18.04，安装类型选 runfile。下载下来的文件大概 2.5GB 左右。
注意：下载页面会同时提供 patch 补丁，建议把最新的补丁也下载下来，安装完主包后再装补丁。补丁通常修复了一些编译和运行时的问题，不装的话可能会遇到奇怪的错误。
3. 核心安装步骤与关键细节
3.1 CUDA 10.2 的安装与验证
安装前先关掉图形界面，因为 runfile 安装过程中需要重新加载显卡驱动模块，如果 X 服务在运行会冲突。在 Ubuntu 18.04 上可以这样操作：
sudo systemctl isolate multi-user.target执行后屏幕会黑一下然后进入纯文本模式。如果你是通过 SSH 连接的，这一步不影响。然后给下载的 runfile 加执行权限并运行：
chmod +x cuda_10.2.89_440.33.01_linux.run sudo ./cuda_10.2.89_440.33.01_linux.run安装界面出来后，第一屏是许可协议，输入accept回车。接下来是关键的一屏：安装选项。这里一定要把 Driver 那一项的勾去掉，因为我们前面已经装好驱动了。其他的 CUDA Toolkit、Samples、Documentation 可以按需勾选。我一般只留 Toolkit，Samples 会占不少空间，而且编译起来很慢。
安装完成后，需要配置环境变量。编辑~/.bashrc，在末尾加上：
export PATH=/usr/local/cuda-10.2/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-10.2/lib64:$LD_LIBRARY_PATH export CUDA_HOME=/usr/local/cuda-10.2然后source ~/.bashrc让配置生效。验证安装是否成功：
nvcc -V如果输出显示了 CUDA 10.2 的版本信息，说明安装成功。再跑一个更实际的验证：编译并运行 deviceQuery 示例。如果你装了 Samples，可以在/usr/local/cuda-10.2/samples/1_Utilities/deviceQuery目录下执行sudo make，然后运行生成的deviceQuery可执行文件。它会输出显卡的详细信息，最后一行显示Result = PASS就说明 CUDA 环境完全正常。
这里有个我踩过的坑：如果nvcc -V正常但编译示例时报错找不到头文件，大概率是CUDA_HOME没设置对，或者LD_LIBRARY_PATH里没有包含 lib64 目录。另外，如果你之前装过其他版本的 CUDA，/usr/local/cuda这个软链接可能还指向旧版本，需要手动更新：
sudo rm -rf /usr/local/cuda sudo ln -s /usr/local/cuda-10.2 /usr/local/cuda3.2 cuDNN 8 的部署与版本匹配
cuDNN 的安装本质上就是复制文件，没有复杂的编译过程。但版本匹配这件事必须严格对待。CUDA 10.2 对应的 cuDNN 8 有多个小版本，我推荐用 8.0.5 或 8.1.0，这两个版本在社区里验证得最充分。
下载 cuDNN 需要注册 NVIDIA 开发者账号，登录后在 cuDNN 存档页面找到对应 CUDA 10.2 的版本。下载下来通常是一个 tar.gz 压缩包，解压后里面有三个目录：include、lib64、lib。
部署命令如下：
tar -xzvf cudnn-10.2-linux-x64-v8.0.5.39.tgz sudo cp cuda/include/cudnn*.h /usr/local/cuda-10.2/include/ sudo cp cuda/lib64/libcudnn* /usr/local/cuda-10.2/lib64/ sudo chmod a+r /usr/local/cuda-10.2/include/cudnn*.h sudo chmod a+r /usr/local/cuda-10.2/lib64/libcudnn*验证 cuDNN 是否部署成功，可以查看版本号：
cat /usr/local/cuda-10.2/include/cudnn_version.h | grep CUDNN_MAJOR -A 2如果输出显示CUDNN_MAJOR 8，说明版本正确。这里有个细节：cuDNN 8 的头文件从cudnn.h拆分成了cudnn_version.h和cudnn_ops_infer.h等多个文件，如果你按老教程去 grepcudnn.h里的版本号，可能会找不到。
注意：复制文件时一定要确认目标路径是
/usr/local/cuda-10.2/而不是/usr/local/cuda/。虽然软链接最终指向同一个地方，但如果你后面切换了 CUDA 版本，直接操作具体版本目录更清晰，不容易搞混。
3.3 TensorRT 6.0 的安装与 Python 绑定
TensorRT 6.0 的安装是这套组合里最复杂的一步，因为它涉及多个组件：核心库、Python 绑定、以及可选的推理服务器。我从 tar 包安装的方式说起，这种方式最灵活。
下载 TensorRT 6.0 的 tar 包，文件名类似TensorRT-6.0.1.5.Ubuntu-18.04.x86_64-gnu.cuda-10.2.cudnn7.6.tar.gz。注意文件名里标注的 cudnn 版本是 7.6，但我们装的是 cuDNN 8，这不会有问题，因为 TensorRT 6.0 对 cuDNN 8 是向前兼容的。
解压后进入目录，核心操作是把库文件和头文件复制到系统路径：
tar -xzvf TensorRT-6.0.1.5.Ubuntu-18.04.x86_64-gnu.cuda-10.2.cudnn7.6.tar.gz cd TensorRT-6.0.1.5 echo "export LD_LIBRARY_PATH=$PWD/lib:$LD_LIBRARY_PATH" >> ~/.bashrc source ~/.bashrc然后安装 Python 绑定。TensorRT 6.0 支持 Python 2.7 和 Python 3.6，Ubuntu 18.04 默认的 Python 3 版本正好是 3.6。进入python目录，根据你的 Python 版本选择对应的 whl 文件：
cd python pip3 install tensorrt-6.0.1.5-cp36-none-linux_x86_64.whl pip3 install uff-0.6.9-py2.py3-none-any.whl pip3 install graphsurgeon-0.4.1-py2.py3-none-any.whl验证 Python 绑定是否成功：
import tensorrt as trt print(trt.__version__)如果输出了6.0.1.5，说明安装成功。这里有个常见问题：如果你用的是虚拟环境，pip 安装的 whl 文件可能装到了虚拟环境里，但LD_LIBRARY_PATH是全局的，这会导致 import 时报找不到库文件的错误。解决办法是在虚拟环境的激活脚本里也加上LD_LIBRARY_PATH的设置，或者把 TensorRT 的 lib 目录路径写进/etc/ld.so.conf.d/里。
还有一个坑：TensorRT 6.0 的 Python 绑定依赖pycuda，而pycuda需要编译安装，编译时又依赖 CUDA 的头文件。如果你在安装pycuda时报错，先确认CUDA_HOME环境变量是否正确设置，以及 GCC 版本是否在支持范围内。
4. 环境验证与典型问题排查
4.1 端到端验证：从 CUDA 到 TensorRT
装完这三个组件后，最好做一次端到端的验证，确保它们能协同工作。我一般用一个简单的矩阵乘法来测 CUDA，用一个预训练的小模型来测 TensorRT。
CUDA 验证用 PyTorch 或 TensorFlow 都可以，但需要装对应 CUDA 10.2 的版本。以 PyTorch 为例，安装命令是：
pip3 install torch==1.5.0+cu102 torchvision==0.6.0+cu102 -f https://download.pytorch.org/whl/torch_stable.html装完后运行：
import torch print(torch.cuda.is_available()) print(torch.version.cuda)如果输出True和10.2，说明 PyTorch 能正常调用 CUDA。
TensorRT 的验证稍微复杂一点，需要先把一个模型转成 ONNX 格式，再用 TensorRT 的解析器加载。TensorRT 6.0 自带的示例里有 MNIST 的完整流程，可以在samples/python/mnist目录下找到。运行sample.py脚本，如果能看到推理输出和性能数据，说明 TensorRT 环境完全正常。
这里有个经验：TensorRT 6.0 对 ONNX 的版本有要求，它支持的是 opset 10 和 11。如果你用新版 PyTorch 导出的 ONNX 是 opset 12 或更高，TensorRT 解析时会报错。解决办法是在导出 ONNX 时指定 opset 版本：
torch.onnx.export(model, dummy_input, "model.onnx", opset_version=11)4.2 常见报错与排查速查表
我把这次安装过程中遇到的和社区里高频出现的报错整理成了表格，方便你快速定位问题。
| 报错信息 | 可能原因 | 解决办法 |
|---|---|---|
nvcc: command not found | PATH 未配置 | 检查~/.bashrc中 PATH 是否包含 CUDA bin 目录 |
error: unsupported GNU version | GCC 版本过高 | 切换 GCC 到 7.x 版本 |
libcudnn.so.8: cannot open shared object file | LD_LIBRARY_PATH 未包含 cuDNN 路径 | 确认 cuDNN 库文件已复制到 CUDA lib64 目录 |
ImportError: libnvinfer.so.6 | TensorRT 库路径未配置 | 在~/.bashrc中添加 TensorRT lib 目录到 LD_LIBRARY_PATH |
pycuda 编译失败 | 缺少 CUDA 头文件或 GCC 版本问题 | 确认 CUDA_HOME 设置正确，GCC 版本兼容 |
TensorRT 解析 ONNX 失败 | ONNX opset 版本过高 | 导出 ONNX 时指定 opset_version=11 |
nvidia-smi 无输出 | 驱动未安装或 nouveau 未禁用 | 禁用 nouveau 后重装驱动 |
CUDA 示例编译通过但运行报错 | 驱动版本与 CUDA 不匹配 | 确认驱动版本不低于 440.33 |
除了表格里的问题，还有一个比较隐蔽的坑：Ubuntu 18.04 的默认 Python 3.6 在安装某些 whl 包时可能会因为 pip 版本过低而失败。解决办法是先升级 pip：
python3 -m pip install --upgrade pip另外，如果你在 Docker 容器里搭建这套环境，需要注意容器内的驱动是共享宿主机的，但 CUDA 工具包需要自己装。Docker 镜像可以用nvidia/cuda:10.2-cudnn8-devel-ubuntu18.04作为基础镜像，这样 CUDA 和 cuDNN 就都有了，只需要再装 TensorRT。
4.3 一些文档里不会写的实操心得
第一个心得：安装顺序很重要。一定要先装驱动，再装 CUDA，然后 cuDNN，最后 TensorRT。这个顺序不能乱，因为每一步都依赖前一步的产物。我见过有人先装 CUDA 再装驱动，结果 CUDA 的驱动模块被覆盖，导致nvidia-smi报版本不匹配。
第二个心得：环境变量不要写太多地方。有些人喜欢在/etc/profile、~/.bashrc、~/.profile里都写一遍，结果互相覆盖，排查起来很麻烦。我的做法是统一写在~/.bashrc里，而且用export明确指定路径，不用相对路径。
第三个心得：保留一份安装记录。我会在/opt/下建一个install_notes.txt，把每个组件的版本号、下载来源、安装命令都记下来。过几个月再回来维护这个环境时，这份记录能省很多时间。
第四个心得：如果条件允许，用 Docker 做环境隔离。这套组合的依赖关系比较复杂，直接装在宿主机上容易和其他项目冲突。用 Docker 的话，每个项目一个容器，互不影响。Dockerfile 可以这样写：
FROM nvidia/cuda:10.2-cudnn8-devel-ubuntu18.04 RUN apt-get update && apt-get install -y python3 python3-pip COPY TensorRT-6.0.1.5 /opt/TensorRT ENV LD_LIBRARY_PATH /opt/TensorRT/lib:$LD_LIBRARY_PATH RUN pip3 install /opt/TensorRT/python/tensorrt-6.0.1.5-cp36-none-linux_x86_64.whl这样构建出来的镜像，环境是干净且可复现的。
5. 性能调优与后续扩展方向
5.1 TensorRT 推理性能的几个关键参数
环境搭好只是第一步，真正让推理跑得快还需要调优。TensorRT 6.0 在构建引擎时有几个参数对性能影响很大，我结合实际测试数据说一下。
第一个是max_workspace_size。这个参数决定了 TensorRT 在构建引擎时能使用的显存上限。设得太小，某些优化策略无法启用；设得太大，构建阶段可能因为显存不足而失败。我的经验值是设为显卡显存的 50% 到 70%。比如 8GB 显存的卡，设 4GB 到 5GB 比较合适。代码里这样设置：
config = builder.create_builder_config() config.max_workspace_size = 1 << 30 # 1GB第二个是fp16模式。如果你的显卡支持半精度（算力 6.0 以上都支持），开启 fp16 能带来接近两倍的吞吐提升，精度损失通常在可接受范围内。开启方式：
config.set_flag(trt.BuilderFlag.FP16)第三个是batch size。TensorRT 支持动态 batch，但动态 batch 的引擎构建时间更长，而且推理时如果实际 batch 和优化时的 batch 差异太大，性能会下降。我的做法是先用固定 batch 构建引擎，确定最优 batch size 后再考虑是否改成动态。
5.2 从 TensorRT 6.0 升级到更高版本的注意事项
虽然这篇文章讲的是 TensorRT 6.0，但实际工作中你可能会遇到需要升级的情况。从 6.0 升级到 7.x 或 8.x 时，有几个 API 变化需要注意。
最明显的变化是IBuilder的接口。TensorRT 7.0 开始，build_cuda_engine方法从IBuilder移到了IBuilderConfig，而且max_workspace_size改成了set_memory_pool_limit。如果你直接拿 6.0 的代码在 7.x 上跑，编译阶段就会报错。
另一个变化是 ONNX 解析器。TensorRT 7.x 的 ONNX 解析器对 opset 的支持范围更广，但同时也更严格。一些在 6.0 上能解析的模型，在 7.x 上可能会因为算子版本不匹配而失败。解决办法是用onnx-simplifier先对模型做一次简化。
升级前建议先备份当前环境，或者用 Docker 起一个新容器做测试。直接在生产环境上升级风险太大，一旦出问题回滚很麻烦。
5.3 这套环境还能怎么用
搭好这套环境后，除了跑推理，还能做不少事情。比如用 TensorRT 的 Python API 做模型量化实验，对比 fp32、fp16、int8 三种精度下的性能和精度差异。int8 量化需要校准数据集，TensorRT 6.0 提供了IInt8Calibrator接口，实现一个自定义的校准器就能跑。
还可以用这套环境做 CUDA 编程练习。CUDA 10.2 自带的 Samples 里有从入门到进阶的各种示例，从简单的向量加法到复杂的矩阵乘法优化都有。编译这些示例不需要额外配置，装好 CUDA 后直接make就行。
另外，如果你对推理服务的部署感兴趣，可以在 TensorRT 之上再搭一层服务框架。TensorRT 6.0 自带的triton推理服务器（当时还叫 TensorRT Inference Server）支持 HTTP 和 gRPC 两种协议，能把模型以服务的形式暴露出来。不过 Triton 的配置稍微复杂，需要单独写模型配置文件，这个可以后续再展开。
我个人在实际操作中的体会是，这套环境虽然版本老，但胜在稳定，社区资料全，遇到问题基本都能搜到答案。真正花时间的不是安装本身，而是排查各种版本冲突和路径问题。把每个组件的版本号记清楚，把环境变量配明白，剩下的就是耐心了。
