2、环境搭建：CUDA与cuDNN版本选择、TensorRT安装（deb/tar/rpm方式）、验证安装是否成功。
好，咱们正式开始动手。环境搭建这一步，说难不难，说简单也容易踩坑。我见过不少同学，代码写得飞起，结果卡在安装上，一卡就是半天。说白了，TensorRT 对底层环境的依赖非常敏感，版本不对，后面全是泪。
我个人习惯，在开始任何项目前，先把 CUDA 和 cuDNN 的版本锁死。你想想看，TensorRT 的每个版本都对应着特定的 CUDA 版本。选错了，要么装不上，要么跑起来各种诡异报错。
2.1 CUDA 与 cuDNN 版本选择
先讲 CUDA。TensorRT 8.x 系列，官方推荐 CUDA 11.x。到了 TensorRT 10.x，就得用 CUDA 12.x 了。具体怎么查？去 NVIDIA 官网，找到 TensorRT 的 Release Notes，里面有一张兼容性表格。我每次都会截图保存，省得来回翻。
核心原则：TensorRT 版本 >= CUDA 版本 >= cuDNN 版本。别倒着来。
cuDNN 的选择更简单。你装好 CUDA 后，去 NVIDIA 开发者网站下载对应 CUDA 版本的 cuDNN。比如 CUDA 11.8，就下载 cuDNN for CUDA 11.x。注意，cuDNN 有四个小版本：cudnn-linux-x86_64-8.9.7.29_cuda11-archive.tar.xz 这种命名格式，别下错了。
我在项目中遇到过一件事。有次客户用 TensorRT 8.4，配了 CUDA 11.6 和 cuDNN 8.4。按理说没问题，但推理时一直报 cudaErrorUnsupportedLimit。查了半天，发现是 cuDNN 版本太新，和 TensorRT 内部调用的 cuDNN API 不匹配。降级到 cuDNN 8.3 就解决了。嗯，这里要注意，cuDNN 的小版本号也很关键。
我的建议：直接去 NVIDIA 的 TensorRT 容器镜像里看。比如 nvcr.io/nvidia/tensorrt:22.12-py3，里面装的就是官方验证过的组合。你照着那个版本装，基本不会出错。
2.2 TensorRT 安装：三种方式
TensorRT 的安装方式有三种：deb、tar、rpm。我挨个讲，你根据自己系统选。
2.2.1 deb 方式（推荐 Ubuntu）
这是最省心的方式。适合 Ubuntu 18.04/20.04/22.04。步骤很简单：
- 下载对应 Ubuntu 版本的 deb 包。比如
nv-tensorrt-local-repo-ubuntu2204-8.6.1-cuda-11.8_1.0-1_amd64.deb。 - 安装仓库：
dpkg -i nv-tensorrt-local-repo-ubuntu2204-8.6.1-cuda-11.8_1.0-1_amd64.deb - 更新源：
apt-get update - 安装：
apt-get install tensorrt
deb 方式会自动处理依赖，包括 libcudnn、libcublas 等。我刚开始用 TensorRT 时，就用的 deb，省心。但要注意，它会把 TensorRT 装到系统目录，如果你同时搞多个版本，容易冲突。
警告：deb 方式安装后，不要轻易卸载。我曾经手贱 apt-get remove tensorrt，结果把 CUDA 的库也连带删了，系统差点崩了。卸载前一定看清楚依赖关系。
2.2.2 tar 方式（推荐通用）
tar 方式最灵活。适合所有 Linux 发行版，也适合需要多版本切换的场景。步骤：
- 下载
TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz - 解压到指定目录：
tar -xzvf TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz -C /opt/ - 配置环境变量：
export LD_LIBRARY_PATH=/opt/TensorRT-8.6.1.6/lib:$LD_LIBRARY_PATH
export PATH=/opt/TensorRT-8.6.1.6/bin:$PATH
export PYTHONPATH=/opt/TensorRT-8.6.1.6/python/python3.10/site-packages:$PYTHONPATH我个人习惯用 tar 方式。为什么？因为我可以同时保留 TensorRT 8.4、8.6、10.0 三个版本，切换时改一下环境变量就行。你想想看，做性能对比测试时，这多方便。
不过 tar 方式有个坑：它不会自动安装 cuDNN。你得自己把 cuDNN 的库文件拷贝到 TensorRT 的 lib 目录下，或者加到 LD_LIBRARY_PATH 里。我曾经忘了这一步，结果运行 trtexec 时直接报 libcudnn.so.8: cannot open shared object file。嗯，这个错我一眼就能认出来。
2.2.3 rpm 方式（适合 CentOS/RHEL）
rpm 方式和 deb 类似，但针对 Red Hat 系。步骤：
- 下载
nv-tensorrt-local-repo-rhel8-8.6.1-cuda-11.8-1.0-1.x86_64.rpm - 安装仓库：
rpm -ivh nv-tensorrt-local-repo-rhel8-8.6.1-cuda-11.8-1.0-1.x86_64.rpm - 更新源：
yum clean all && yum makecache - 安装：
yum install tensorrt
rpm 方式我用的不多，但原理和 deb 一样。唯一要注意的是，CentOS 7 的默认 glibc 版本可能不够，需要升级。我有个朋友在 CentOS 7.6 上装 TensorRT 10，折腾了两天，最后发现是 glibc 2.17 太老，升级到 2.28 才搞定。
2.3 验证安装是否成功
装完了，怎么知道对不对？别急着跑模型，先做三个快速验证。
2.3.1 命令行验证
打开终端，输入：
trtexec --version如果看到类似 TensorRT Version: 8.6.1 的输出，说明安装成功。如果报 command not found，检查 PATH 环境变量。
2.3.2 Python 验证
进入 Python 环境：
python3 -c "import tensorrt; print(tensorrt.__version__)"输出应该是 8.6.1 这样的版本号。如果报 ModuleNotFoundError，检查 PYTHONPATH 是否指向了 TensorRT 的 Python 包目录。
小技巧：用 python3 -c "import tensorrt as trt; print(trt.Builder(trt.Logger()))" 可以进一步验证 Builder 能否正常创建。如果报 CUDA 相关的错，大概率是 CUDA 版本不匹配。
2.3.3 简单推理验证
跑一个最简单的 ONNX 模型试试。我一般用 trtexec 工具：
trtexec --onnx=model.onnx --saveEngine=model.engine --fp16如果顺利生成 model.engine 文件，说明 TensorRT 能正常解析 ONNX 并构建引擎。如果报错，看日志。常见的错误有：
[E] Error Code 1: Serialization—— 模型太大，显存不够。[E] Error Code 3: Internal Error—— 算子不支持，或者 cuDNN 版本不对。[E] Error Code 10: Invalid Argument—— 输入输出名称写错了。
我曾经在验证时遇到一个奇葩问题：trtexec 能跑，但 Python 接口报错。查了半天，发现是 Python 的 TensorRT 包和系统安装的 TensorRT 库版本不一致。一个 8.6，一个 8.4。嗯，这种问题最隐蔽，建议你装完后统一用 pip 安装对应版本的 tensorrt 包。
2.4 常见问题与避坑指南
最后，我总结几个我踩过的坑：
- CUDA 版本不匹配：TensorRT 8.x 不支持 CUDA 12.x。别想着用最新的 CUDA，TensorRT 没那么快跟上。
- cuDNN 版本不匹配：cuDNN 8.9 和 TensorRT 8.4 不兼容。降级到 cuDNN 8.3 或 8.4。
- Python 包冲突：如果你用 conda，注意 conda 里的 tensorrt 包可能和系统安装的冲突。我建议用 pip 安装
tensorrt包，版本和系统一致。 - 权限问题：tar 方式解压到
/opt需要 sudo。但运行trtexec时不需要 root。别没事用 sudo 跑推理，容易出权限问题。
好了，环境搭建就这些。你按这个流程走，半小时内应该能搞定。下一章，咱们开始讲 TensorRT 的核心概念——网络定义与构建器。到时候你会明白，为什么环境搭建这么重要。