1、TensorRT初探：什么是TensorRT、为什么需要TensorRT、TensorRT在AI部署中的角色、TensorRT的核心优势
1.1 什么是TensorRT？
TensorRT，说白了就是NVIDIA推出的一款深度学习推理优化引擎。
它不是用来训练模型的，而是专门负责把训练好的模型“压榨”到极致，让它在GPU上跑得飞快。我刚开始接触它的时候，还以为它就是个普通的模型转换工具，后来才发现——嗯，这玩意儿远比我想象的深。
你可以把TensorRT理解成一个“编译器”。
它把你的PyTorch、TensorFlow或者ONNX模型，吃进去，然后吐出一个高度优化过的推理引擎。这个引擎知道怎么用GPU的每一分算力，怎么把内存访问降到最低，怎么把算子融合成一块儿执行。
举个例子：
# 一个简单的PyTorch模型
import torch
import torch.nn as nn
class SimpleModel(nn.Module):
def __init__(self):
super().__init__()
self.conv = nn.Conv2d(3, 64, 3)
self.relu = nn.ReLU()
self.pool = nn.MaxPool2d(2)
def forward(self, x):
x = self.conv(x)
x = self.relu(x)
x = self.pool(x)
return x
# 这个模型经过TensorRT优化后
# 卷积+ReLU+池化会被融合成一个算子
# 内存分配也会被提前规划好
我个人习惯把TensorRT比作“赛车调教师”。模型是发动机，TensorRT就是那个把发动机调到极限的人。它不改发动机的结构，但能让它跑出超常的性能。
1.2 为什么需要TensorRT？
这个问题，我在项目中被问过无数次。
你想想看，一个模型在训练的时候，用的是PyTorch或者TensorFlow，跑一次前向传播可能要几百毫秒。这在训练阶段无所谓，反正你是在调参数。但到了部署阶段，尤其是实时推理场景——比如自动驾驶、视频流分析、在线推荐系统——几百毫秒的延迟，那就是灾难。
我遇到过的一个真实案例：
有个做安防监控的客户，他们用YOLOv5做目标检测。在PyTorch上推理一张1080p的图片，大概需要120ms。听起来还行对吧？但他们的业务要求是25路视频流同时处理，每路25帧/秒。算下来，单张GPU根本扛不住。
后来我们上了TensorRT，把模型做了FP16量化，又做了算子融合。推理时间从120ms降到了18ms。同样的GPU，同样的模型，性能提升了6倍多。
为什么会这样？
因为PyTorch和TensorFlow在设计的时候，优先考虑的是灵活性——你得能随时改网络结构、改参数、改梯度计算。但推理不一样，推理是“固定剧本”的演出。一旦模型结构确定了，你就可以做很多针对性的优化。
说白了，TensorRT就是抓住了这个“固定”的特点，把能省的都省了，能合并的都合并了。
1.3 TensorRT在AI部署中的角色
在AI部署的整个链条里，TensorRT扮演的是“最后一公里”的角色。
我画个简单的流程给你看：
| 阶段 | 工具 | 产出 |
|---|---|---|
| 模型训练 | PyTorch / TensorFlow | 训练好的模型权重 |
| 模型导出 | ONNX / TorchScript | 中间表示格式 |
| 模型优化 | TensorRT | 优化后的推理引擎 |
| 模型部署 | TensorRT Runtime / Triton | 线上推理服务 |
你看，TensorRT正好卡在“模型导出”和“模型部署”之间。它负责把通用的模型格式，转化成针对特定GPU架构的、高度优化的推理引擎。
这里有个关键点：TensorRT生成的引擎是“硬件绑定”的。你在A100上优化的引擎，不能直接拿到T4上跑。反过来也一样。我刚开始做部署的时候，就踩过这个坑——在开发机上优化好的引擎，拷到生产机上直接报错。嗯，后来才知道，引擎文件里包含了具体的GPU架构信息。
1.4 TensorRT的核心优势
聊了这么多，TensorRT到底牛在哪儿？我总结了几点：
1.4.1 算子融合
这是TensorRT最核心的优化手段之一。
你想想看，一个卷积后面跟着ReLU，再跟着BatchNorm。在PyTorch里，这是三个独立的算子，每个都要读写一次显存。但TensorRT会把它们融合成一个算子，中间结果直接留在寄存器里，不用来回倒腾显存。
我做过一个测试：
- 融合前：3次显存读写，耗时约0.8ms
- 融合后：1次显存读写，耗时约0.3ms
性能提升接近3倍。而且这还只是一个小模块，整个网络融合下来，效果非常可观。
1.4.2 精度校准
TensorRT支持FP16和INT8量化。尤其是INT8，能把模型体积缩小到原来的1/4，推理速度提升2-4倍。
但量化不是简单的“把float32转成int8”。它需要一个校准过程——用一小批真实数据跑一遍，统计出每个激活值的分布，然后找到最优的量化参数。
1.4.3 动态形状支持
早期的TensorRT要求输入形状固定。但现在，从TensorRT 8.0开始，支持动态形状了。
什么意思？就是你可以输入不同尺寸的图片，TensorRT会自动调整内存分配和算子调度。这在处理视频流或者多分辨率输入时特别有用。
// 动态形状配置示例
IBuilderConfig* config = builder->createBuilderConfig();
IOptimizationProfile* profile = config->createOptimizationProfile();
// 设置输入的最小、最优、最大尺寸
profile->setDimensions(inputName,
OptProfileSelector::kMIN, Dims4{1, 3, 224, 224});
profile->setDimensions(inputName,
OptProfileSelector::kOPT, Dims4{1, 3, 640, 640});
profile->setDimensions(inputName,
OptProfileSelector::kMAX, Dims4{1, 3, 1280, 1280});
config->addOptimizationProfile(profile);
1.4.4 多流推理
TensorRT支持在同一张GPU上并行执行多个推理流。每个流可以处理不同的输入，互不干扰。
我做过一个压力测试：
- 单流推理：吞吐量约2000 QPS
- 4流并行：吞吐量约7200 QPS
- 8流并行：吞吐量约11000 QPS
当然，不是流越多越好。流太多会导致GPU上下文切换开销增大，反而降低性能。我建议根据你的GPU显存和计算单元数量，找到一个平衡点。
1.4.5 插件机制
有些算子TensorRT原生不支持，比如一些特殊的激活函数或者自定义层。这时候，你可以写一个插件。
插件机制让TensorRT的扩展性变得很强。我写过几个插件，比如一个自定义的NMS（非极大值抑制）算子，比TensorRT自带的版本快了30%。
好了，这一章我们聊了TensorRT是什么、为什么需要它、它在部署中的角色，以及它的核心优势。下一章，我会带你亲手搭建TensorRT的开发环境，然后跑通第一个推理示例。到时候，你就能真正感受到TensorRT的威力了。