2、GPU计算基础：CUDA、cuDNN、TensorRT等GPU软件栈介绍
刚入行那会儿，我总觉得搞GPU部署就是装个驱动、跑个模型完事。直到有一次在客户现场，模型死活跑不起来，查了半天才发现是cuDNN版本和CUDA Toolkit对不上。从那以后，我才老老实实把这套软件栈的来龙去脉摸了个透。
说白了，GPU软件栈就是一层一层叠起来的。硬件在最底下，上面是驱动，再往上才是我们天天打交道的这些库。你想想看，没有驱动，CUDA跑不了；没有CUDA，cuDNN就是空中楼阁；没有这些基础库，TensorRT再牛也白搭。
一句话总结：CUDA是地基，cuDNN是工具箱，TensorRT是精装修。三者的关系，不能搞混。
2.1 GPU软件栈全景
这张图展示的，就是我从开发到上线经常打交道的那些组件。你看，从最底层的硬件驱动，到最上层的推理框架，每一层都有它该干的事。
嗯，这里要注意一点。不是所有场景都需要把每一层叠满。比如你只是在测试环境跑个小模型，装个CUDA Toolkit就够了。但一旦上了生产，想追求极致性能，cuDNN和TensorRT就是你绕不开的坎。
2.2 CUDA：一切运算的起点
CUDA不是某个单一的软件包。它是一个完整的并行计算平台和编程模型。NVIDIA从2007年推出来，到现在已经迭代了十多个大版本。
我习惯把CUDA分为两部分来理解：
| 组件 | 作用 | 我常用的版本 |
|---|---|---|
| CUDA Driver API | 底层驱动接口，和GPU硬件直接通信 | 随驱动一起安装，版本号看nvidia-smi |
| CUDA Runtime API | 封装了Driver API，更容易上手 | 11.x / 12.x |
| nvcc编译器 | 把CUDA C/C++代码编译成GPU可执行文件 | 随Toolkit一起 |
| cuBLAS / cuFFT / cuRAND | 数学运算加速库 | 随Toolkit一起，但可以单独升级 |
为什么我特别强调Driver和Runtime的版本要匹配？因为它们在同一个机器上，本质上是一对一的关系。Runtime版本不能高于Driver版本支持的CUDA版本。举个例子，你的驱动支持CUDA 12.0，那你用Runtime 11.8完全没问题，但反过来就不行。
查版本的方法也很简单：
# 查看驱动版本和支持的CUDA版本
nvidia-smi
# 输出里会有一行：CUDA Version: 12.2
# 查看当前安装的CUDA Toolkit版本
nvcc --version我的习惯：部署前先跑一遍 nvidia-smi 和 nvcc --version，确保两个版本号能对上。如果驱动版本过低，我一般会升级驱动，而不是降级CUDA Toolkit。
2.3 cuDNN：深度学习加速的核心
cuDNN的全称是CUDA Deep Neural Network library。它专门为深度神经网络设计，提供了高度优化的卷积、池化、归一化、激活函数等操作。
你在PyTorch或TensorFlow里写一行nn.Conv2d，底层实际调用的就是cuDNN的卷积实现。为什么训练和推理速度取决于它？因为卷积操作占了整个计算量的60%-80%。cuDNN把这些算子做到了极致，不管是前向还是反向，都比你手写的CUDA kernel快得多。
安装cuDNN时的坑，我踩过两个：
- 版本必须对齐：cuDNN的版本和CUDA版本绑定。比如cuDNN 8.x必须配合CUDA 11.x或12.x。你不能拿cuDNN 8.0配CUDA 10.2，会直接报错。
- 安装方式有区别：早期要手动下载tar包复制文件，现在NVIDIA提供了deb包和容器镜像。我个人建议生产环境直接拉NVIDIA的官方容器镜像，省去版本匹配的痛苦。
举个例子，我最常用的一个安装命令（假设已经装了CUDA 11.8）：
# 下载cuDNN deb包
wget https://developer.download.nvidia.com/compute/cudnn/9.0.0/local_installers/cudnn-local-repo-ubuntu2204-9.0.0_1.0-1_amd64.deb
# 安装
sudo dpkg -i cudnn-local-repo-ubuntu2204-9.0.0_1.0-1_amd64.deb
sudo cp /var/cudnn-local-repo-*/cudnn-local-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get install libcudnn9-cuda-11
# 验证
dpkg -l | grep cudnn当然，更省事的做法是直接用容器。NVIDIA的NGC容器里已经把CUDA、cuDNN、TensorRT都配好了。我平时在开发机上喜欢手动装，到了生产环境一律走容器。
我曾经在容器里栽过跟头：宿主机装了CUDA 12.0，但容器里是CUDA 11.8的镜像。启动容器时忘了挂载--gpus all和设置NVIDIA_VISIBLE_DEVICES，结果容器根本用不了GPU。踩完这个坑之后，我每次起容器都会检查nvidia-smi能否在容器里正常跑。
2.4 TensorRT：推理优化的利器
把模型从训练环境搬到推理环境，你总得做点什么吧？TensorRT就是干这个的。它把PyTorch、TensorFlow或其他框架训练好的模型，转换成高度优化的推理引擎。
TensorRT都做了哪些优化？我总结了几点：
- 权重量化：把FP32降成FP16或INT8，显存占用直接对半砍，速度还能翻倍。
- 层融合：把 Conv + BN + ReLU 这种连续操作合并成一个kernel，减少访存开销。
- 内核自动调优：扫描所有可能的CUDA kernel实现，选最快的那个。
- 动态形状支持：输入尺寸可变，不用每次调整都会重编译。
举个例子，我优化一个ResNet-50模型的流程：
import tensorrt as trt
# 创建builder
logger = trt.Logger(trt.Logger.WARNING)
builder = trt.Builder(logger)
# 设置网络
network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
parser = trt.OnnxParser(network, logger)
# 加载ONNX模型
with open("resnet50.onnx", "rb") as f:
parser.parse(f.read())
# 配置builder
config = builder.create_builder_config()
config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30) # 1GB
config.set_flag(trt.BuilderFlag.FP16)
# 构建引擎
engine = builder.build_serialized_network(network, config)
with open("resnet50_fp16.engine", "wb") as f:
f.write(engine)这段代码走完，原来跑FP32的ResNet-50，延迟从8ms降到了4ms，而且精度几乎没掉。
关键点：TensorRT的优化不是无痛的。量化后精度可能会掉，尤其是小模型和稀疏模型。我一般在量化后用验证集跑一遍精度对比，掉点超过0.5%就换回FP16甚至FP32。
2.5 版本兼容性：最容易出问题的地方
讲完了各个组件，我必须提一句版本兼容性。这可能是你部署过程中遇到最多的坑。
我整理了一个常用的版本对应关系表，你可以直接当参考：
| CUDA版本 | cuDNN版本 | TensorRT版本 | 驱动最低版本 |
|---|---|---|---|
| 11.8 | 8.9.x | 8.6.x / 8.5.x | 520.61.05 |
| 12.0 | 8.9.x / 9.0.x | 8.6.x | 525.60.13 |
| 12.1 | 8.9.6+ | 8.6.1+ | 530.30.02 |
| 12.2 | 8.9.7+ | 8.6.2+ | 535.54.03 |
怎么查？最简单的办法还是看NVIDIA官方文档。但我有个习惯——每次部署前，先跑一遍下面的验证脚本：
#!/bin/bash
echo "=== Driver ==="
nvidia-smi --query-gpu=driver_version --format=csv,noheader
echo ""
echo "=== CUDA ==="
nvcc --version | grep "release"
echo ""
echo "=== cuDNN ==="
find /usr -name "cudnn_version.h" -exec cat {} \; | grep CUDNN_MAJOR -A 2
echo ""
echo "=== TensorRT ==="
dpkg -l | grep tensorrt我曾经遇到一个生产事故：团队里有人升级了CUDA Toolkit但忘了同步更新驱动。结果容器启动后，TensorRT报错CUBLAS_STATUS_NOT_INITIALIZED。排查了大半天才发现是Driver API版本太老，和Runtime API不兼容。从那以后，我坚持在部署脚本里加入版本校验逻辑，版本匹配失败直接退出。
2.6 容器化部署：规避版本冲突的最佳实践
环境问题太多了，我一个办法治标又治本——用容器。NVIDIA官方提供的NGC容器，已经帮你配好了CUDA、cuDNN、TensorRT。你只需要选对Tag，拉下来直接用。
举个例子，我需要一个基于CUDA 12.2、带TensorRT的推理环境：
docker pull nvcr.io/nvidia/tensorrt:23.12-py3
# 或者拉PyTorch容器（内含CUDA 12.1 + cuDNN 8.9）
docker pull nvcr.io/nvidia/pytorch:23.12-py3每次启动容器，我还会检查GPU是否可用：
docker run --gpus all --rm -it nvcr.io/nvidia/pytorch:23.12-py3 nvidia-smi如果这个命令能在容器里正常输出GPU信息，那后面再跑模型基本不会出环境问题。
一个小建议：如果你是第一次接触GPU部署，直接上容器。别自己折腾宿主机环境。等你熟悉了软件栈的依赖关系，再考虑手动安装。
OK，整个软件栈的底子就是这样。CUDA、cuDNN、TensorRT这三兄弟，搞明白了，后面搭推理服务就顺了。实践出真知，我建议你挑一块卡，从nvidia-smi开始，一步步验证。遇到版本冲突别慌，记住一句话：驱动 ≥ CUDA Runtime ≥ cuDNN ≥ TensorRT。版本只能向下兼容，不能向上超过驱动支持的范围。