1. 为什么值得折腾TensorRT从训练到推理的最后一公里搞深度学习的人都有一个共同的痛点模型在实验室里跑得挺好一上生产环境就拉胯。PyTorch训练出来的模型推理速度慢、显存占用高、吞吐量上不去尤其是在边缘设备或者需要实时响应的场景里这个问题会被无限放大。我最早接触TensorRT是在一个视频分析的项目里当时用PyTorch直接推理单帧处理时间接近200毫秒根本达不到实时要求。后来把模型转成TensorRT引擎同样的硬件条件下单帧降到了30毫秒以内吞吐量翻了将近7倍。这个差距不是靠调参能弥补的它来自底层推理框架对硬件的深度优化。TensorRT是NVIDIA推出的一套高性能深度学习推理SDK核心思路就一个针对特定GPU型号把训练好的模型重新编译成一个高度定制化的推理引擎。这个引擎会做几件关键的事——层融合、精度校准、内核自动调优、动态批处理。打个比方PyTorch模型像是一份通用菜谱什么厨房都能做但效率一般TensorRT引擎则像是针对你家厨房设备专门优化过的操作流程每一步都卡在最省时间的路径上。这套东西适合谁如果你正在做模型部署、推理加速、边缘计算或者你训练完模型发现推理速度实在没法接受那TensorRT就是绕不过去的一环。但要注意它不是万能药也不是所有模型都能无脑转。有些自定义算子、动态控制流、不支持的层类型都会让转换过程变得棘手。这篇文章我会从安装开始一步步讲到PyTorch模型怎么转成TensorRT引擎中间踩过的坑、绕过的弯、总结出来的经验都会毫无保留地分享出来。2. 环境准备与TensorRT安装别让版本兼容性把你劝退2.1 安装前的关键检查项TensorRT的安装本身不复杂复杂的是环境匹配。我见过太多人卡在版本不兼容上折腾一整天连第一个demo都跑不起来。所以在动手之前先把这几件事确认清楚。第一确认你的GPU型号和计算能力。TensorRT对GPU是有要求的太老的卡可能不支持最新版本。你可以用nvidia-smi查看GPU型号然后去NVIDIA官网查对应的计算能力Compute Capability。一般来说计算能力7.0以上的卡用起来比较舒服5.0到7.0之间的也能用但某些新特性可能受限。第二确认CUDA版本。TensorRT和CUDA的版本绑定非常紧密每个TensorRT版本都有对应的CUDA版本要求。比如TensorRT 8.6通常搭配CUDA 12.xTensorRT 8.5搭配CUDA 11.8。你不能随便混搭否则安装完import的时候直接报错。第三确认cuDNN版本。cuDNN是深度神经网络加速库TensorRT依赖它。版本也要和CUDA匹配这个在NVIDIA开发者网站上有明确的对应表。第四确认PyTorch版本。如果你打算用PyTorch的TensorRT部署路径PyTorch版本、CUDA版本、TensorRT版本三者必须形成一个兼容的三角关系。我的建议是先确定TensorRT版本然后反推CUDA和PyTorch版本这样最稳妥。注意不要盲目追求最新版本。最新版TensorRT可能刚发布不久和PyTorch的兼容性还没经过充分验证。选择一个发布3到6个月的稳定版本踩坑概率会低很多。2.2 三种安装方式的实际体验对比TensorRT的安装方式主要有三种pip安装、tar包安装、deb/rpm包安装。我三种都用过各有各的适用场景。pip安装是最省事的直接pip install tensorrt就行。但这种方式安装的TensorRT功能可能不完整某些组件比如trtexec命令行工具、Python的某些子模块可能缺失。如果你只是想快速跑通一个demopip安装够用。但要做完整的部署我不推荐这种方式。tar包安装是我最常用的方式。从NVIDIA官网下载对应版本的tar包解压后把lib路径加到LD_LIBRARY_PATH把Python包路径加到PYTHONPATH就完事了。这种方式的好处是灵活你可以同时装多个版本的TensorRT通过切换环境变量来切换版本。缺点是每次新开终端都要重新设置环境变量建议直接写进.bashrc或者.zshrc里。deb/rpm包安装适合在Ubuntu或者CentOS上做系统级部署。安装完自动配置好路径不用手动设置环境变量。但这种方式一个系统只能装一个版本版本切换很麻烦。我个人的选择是开发阶段用tar包方便切换版本做对比测试生产部署用deb包省去环境变量配置的麻烦。2.3 验证安装是否成功的完整流程安装完之后别急着跑模型先做几个基础验证确保环境没问题。# 检查TensorRT版本 python -c import tensorrt; print(tensorrt.__version__) # 检查CUDA是否可用 python -c import torch; print(torch.cuda.is_available()) # 检查cuDNN版本 python -c import torch; print(torch.backends.cudnn.version())如果这三条命令都能正常输出说明基础环境没问题。接下来可以跑一个官方的sample验证一下。TensorRT的tar包里通常自带sample目录里面有一些预编译好的例子。跑通一个最简单的sample比如sampleMNIST能进一步确认TensorRT的推理功能是正常的。还有一个容易被忽略的点检查trtexec是否可用。这个命令行工具在后续的模型转换和性能测试中非常有用。trtexec --help如果提示找不到命令说明trtexec所在的路径没有加到PATH里。tar包安装的话trtexec通常在bin目录下手动加一下就行。3. PyTorch模型转TensorRT的核心路径拆解3.1 为什么不能直接转换理解中间的IR环节很多人第一次尝试PyTorch转TensorRT的时候会想当然地以为有一个torch2trt的函数调一下就行了。实际上PyTorch模型不能直接转成TensorRT引擎中间必须经过一个中间表示Intermediate RepresentationIR。这个IR通常是ONNXOpen Neural Network Exchange。ONNX是一个开放的模型格式标准PyTorch可以导出ONNXTensorRT可以解析ONNX。所以完整的路径是PyTorch模型 → ONNX模型 → TensorRT引擎。为什么要多这一步因为TensorRT的优化器需要在一个标准化的计算图表示上做分析。PyTorch的动态图虽然灵活但包含了很多Python层面的控制逻辑TensorRT没法直接理解。ONNX把模型固化成一个静态的计算图每个节点都是标准的算子TensorRT才能在这个基础上做层融合、精度校准这些优化。但ONNX也不是完美的。有些PyTorch算子没有对应的ONNX算子导出的时候会报错或者产生不正确的图。有些算子虽然有对应的ONNX算子但TensorRT不支持。这些问题在转换过程中会一个个冒出来需要逐个解决。3.2 ONNX导出时的关键参数与避坑指南PyTorch导出ONNX的接口是torch.onnx.export这个函数的参数不少但真正影响转换成功率和后续TensorRT兼容性的主要是这几个。opset_versionONNX的算子集版本。这个参数非常关键版本太低可能缺少某些算子版本太高可能TensorRT还不支持。我的经验是TensorRT 8.x系列搭配opset 11到13比较稳。具体选哪个要看你模型里用到的算子。如果模型比较简单opset 11就够了如果用了比较新的算子可能需要opset 13甚至更高。input_names和output_names给输入输出节点起名字。这个看起来不起眼但在后续用TensorRT做推理的时候你需要通过这些名字来指定输入输出。如果名字乱起后面写推理代码的时候会很痛苦。建议用有意义的英文名比如input_ids、attention_mask、logits。dynamic_axes指定动态维度。如果你的模型支持变长输入比如NLP模型里的序列长度不固定就需要用这个参数把对应的维度标记为动态的。不设置的话导出的ONNX模型会固定住输入尺寸后续TensorRT也只能用这个固定尺寸。do_constant_folding常量折叠优化。这个参数默认是True建议保持。它会把模型里可以提前计算的常量表达式算好减小模型体积也能避免一些转换时的奇怪问题。torch.onnx.export( model, dummy_input, model.onnx, opset_version12, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}, output: {0: batch_size}}, do_constant_foldingTrue )导出完之后强烈建议用onnxruntime验证一下ONNX模型是否正确。有时候导出过程不报错但模型实际上是错的直接拿去转TensorRT会浪费很多时间。import onnxruntime as ort sess ort.InferenceSession(model.onnx) result sess.run(None, {input: dummy_input.numpy()})把ONNX模型的输出和PyTorch模型的输出对比一下误差在1e-4以内就算正常。3.3 TensorRT引擎构建的两种方式trtexec与Python API拿到ONNX模型之后构建TensorRT引擎有两条路用trtexec命令行工具或者用TensorRT的Python API。trtexec是最快的方式一行命令就能把ONNX转成引擎trtexec --onnxmodel.onnx --saveEnginemodel.engine --fp16这个命令会加载ONNX模型用FP16精度构建引擎然后保存成文件。trtexec还支持很多参数比如--best会自动选择最优精度--workspace指定显存工作空间大小--minShapes、--optShapes、--maxShapes指定动态尺寸的范围。用trtexec的好处是快适合快速验证和性能测试。但它的灵活性有限比如你想自定义某些层的精度或者想插入自定义插件就做不到了。Python API的方式更灵活代码量也不大import tensorrt as trt 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) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) config.set_flag(trt.BuilderFlag.FP16) engine builder.build_engine(network, config) with open(model.engine, wb) as f: f.write(engine.serialize())这段代码做了几件事创建builder和network用ONNX parser解析模型配置构建参数最后构建并序列化引擎。set_memory_pool_limit设置工作空间大小这个值影响TensorRT能做多少优化太小会导致某些优化无法进行太大会浪费显存。一般来说1GB到4GB之间比较合适。set_flag(trt.BuilderFlag.FP16)开启FP16精度。如果你的GPU支持INT8还可以用trt.BuilderFlag.INT8但INT8需要校准数据集流程会复杂一些。实操心得构建引擎的过程可能比较慢尤其是大模型。我遇到过一个模型构建引擎花了将近20分钟。建议把构建好的引擎保存成文件后续直接加载引擎做推理不要每次都重新构建。4. 精度选择与性能调优FP32、FP16还是INT84.1 三种精度的实际差异与选择逻辑TensorRT支持三种精度模式FP32、FP16、INT8。精度越低速度越快但准确率损失也越大。怎么选取决于你的场景对准确率的容忍度。FP32是默认精度和PyTorch训练时的精度一致准确率无损。但速度最慢显存占用也最大。如果你的场景对准确率要求极高或者模型本身对数值精度很敏感那就用FP32。FP16是半精度浮点速度通常比FP32快1.5到2倍显存占用减半。准确率损失一般很小在大多数视觉模型和NLP模型上FP16的准确率下降在0.1%到0.5%之间。我的经验是除非你的模型有特殊的数值稳定性问题否则FP16是性价比最高的选择。INT8是8位整数精度速度最快显存占用只有FP32的四分之一。但INT8需要校准也就是用一批代表性数据去统计激活值的分布确定量化的缩放因子。校准做得好准确率损失可以控制在1%以内校准做得不好准确率可能崩掉。INT8适合对速度要求极高、且能接受少量准确率损失的场景比如大规模推荐系统、实时视频分析。精度速度提升显存占用准确率损失适用场景FP32基准基准无准确率敏感型任务FP161.5-2倍约50%0.1%-0.5%大多数推理场景INT83-4倍约25%0.5%-2%极致速度要求场景4.2 INT8校准的实操细节INT8校准是TensorRT部署里最容易出问题的环节。校准的本质是用一批数据跑一遍模型统计每一层激活值的动态范围然后确定量化的缩放因子。校准数据的质量和数量直接影响最终的准确率。校准数据不需要标注但必须能代表真实推理时的数据分布。数量上我一般用500到1000个样本。太少的话统计不充分太多的话校准时间太长。校准数据要覆盖各种边界情况比如极端值、长尾分布否则量化后的模型在这些情况上会表现很差。TensorRT提供了几种校准器最常用的是IInt8EntropyCalibrator2。这个校准器用熵最小化的方法来确定缩放因子在大多数模型上表现不错。class Calibrator(trt.IInt8EntropyCalibrator2): def __init__(self, data_loader, cache_file): super().__init__() self.data_loader data_loader self.cache_file cache_file self.batch_idx 0 self.device_input cuda.mem_alloc(...) def get_batch_size(self): return self.batch_size def get_batch(self, names): # 返回一个batch的数据 ... def read_calibration_cache(self): # 读取缓存 ... def write_calibration_cache(self, cache): # 写入缓存 ...校准过程可能比较慢尤其是大模型。校准完成后TensorRT会把校准表缓存下来下次构建引擎时可以直接读取缓存不用重新校准。注意校准表是和校准数据、模型结构、TensorRT版本绑定的。换了任何一个校准表都要重新生成。不要试图复用一个旧的校准表。4.3 动态Shape与Batch Size的权衡动态Shape是TensorRT 7.0之后引入的特性允许引擎在运行时接受不同尺寸的输入。这对NLP模型特别重要因为序列长度经常变化。配置动态Shape需要指定三个范围最小尺寸、最优尺寸、最大尺寸。TensorRT会针对最优尺寸做优化同时保证在最小和最大尺寸之间都能正确运行。profile builder.create_optimization_profile() profile.set_shape(input, min(1, 3, 224, 224), opt(8, 3, 224, 224), max(32, 3, 224, 224)) config.add_optimization_profile(profile)最优尺寸的选择很关键。TensorRT会为最优尺寸生成最高效的kernel其他尺寸则可能退化到通用kernel。所以最优尺寸应该设为你实际推理时最常用的尺寸。动态Shape的代价是引擎构建时间更长显存占用更大。因为TensorRT需要为多个尺寸范围准备kernel。如果实际场景中输入尺寸是固定的那就不要用动态Shape固定尺寸的引擎性能更好。Batch Size的选择也要权衡。大batch能提高GPU利用率但会增加延迟。实时场景通常用batch size 1到4离线批处理可以用更大的batch。我的建议是先用batch size 1测延迟再用大batch测吞吐找到满足延迟要求前提下的最大batch。5. 部署落地从引擎文件到生产服务5.1 推理代码的完整实现框架引擎构建好之后部署的核心就是加载引擎、分配显存、执行推理、处理输出。下面是一个完整的推理框架。import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit import numpy as np class TRTInference: def __init__(self, engine_path): self.logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f: self.engine trt.Runtime(self.logger).deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() self.stream cuda.Stream() self.allocate_buffers() def allocate_buffers(self): self.inputs [] self.outputs [] self.bindings [] for binding in self.engine: size trt.volume(self.engine.get_binding_shape(binding)) dtype trt.nptype(self.engine.get_binding_dtype(binding)) host_mem cuda.pagelocked_empty(size, dtype) device_mem cuda.mem_alloc(host_mem.nbytes) self.bindings.append(int(device_mem)) if self.engine.binding_is_input(binding): self.inputs.append({host: host_mem, device: device_mem}) else: self.outputs.append({host: host_mem, device: device_mem}) def infer(self, input_data): np.copyto(self.inputs[0][host], input_data.ravel()) cuda.memcpy_htod_async(self.inputs[0][device], self.inputs[0][host], self.stream) self.context.execute_async_v2(bindingsself.bindings, stream_handleself.stream.handle) for out in self.outputs: cuda.memcpy_dtoh_async(out[host], out[device], self.stream) self.stream.synchronize() return [out[host] for out in self.outputs]这段代码做了几件事反序列化引擎、创建执行上下文、分配host和device内存、执行异步推理、拷贝结果回host。pagelocked_empty分配的是锁页内存比普通内存的拷贝速度快。execute_async_v2是异步执行配合CUDA stream可以实现流水线并行。5.2 多线程与多流并发的注意事项在生产环境里单线程推理往往无法充分利用GPU。多线程或者多流并发能显著提高吞吐量但也有一些坑。TensorRT的execution context不是线程安全的。如果你在多线程里共享一个context会出现各种奇怪的错误。正确的做法是每个线程创建自己的context共享同一个engine。engine是线程安全的context不是。# 每个线程创建自己的context context engine.create_execution_context()多流并发是另一种提高吞吐的方式。创建多个CUDA stream每个stream上跑一个推理请求GPU可以同时执行多个stream上的kernel。但要注意显存是有限的并发太多会导致显存不足。而且GPU的计算资源也是有限的并发超过一定数量后吞吐量不会再提升反而可能因为资源竞争而下降。我的经验是先用单流测出基准吞吐量然后逐步增加并发数观察吞吐量的变化。当吞吐量不再明显提升时就是最优并发数。5.3 性能监控与瓶颈定位部署上线之后性能监控是必不可少的。你需要知道推理的延迟、吞吐量、GPU利用率、显存占用这些指标。延迟和吞吐量可以在应用层统计。GPU利用率和显存占用可以用nvidia-smi或者pynvml来采集。import pynvml pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) util pynvml.nvmlDeviceGetUtilizationRates(handle) memory pynvml.nvmlDeviceGetMemoryInfo(handle) print(fGPU利用率: {util.gpu}%, 显存占用: {memory.used / 1024**2:.0f}MB)如果GPU利用率很低说明瓶颈可能在数据预处理或者后处理上GPU在等数据。如果GPU利用率很高但吞吐量上不去说明瓶颈在GPU计算上可能需要优化模型或者换更强的GPU。还有一个容易被忽略的瓶颈是内存拷贝。host到device的拷贝、device到host的拷贝如果数据量大拷贝时间可能超过计算时间。解决办法是用锁页内存、异步拷贝、CUDA stream重叠拷贝和计算。6. 常见问题与排查技巧实录6.1 ONNX导出与解析阶段的典型报错报错一Unsupported operator这是最常见的报错。PyTorch的某个算子没有对应的ONNX算子或者TensorRT不支持这个ONNX算子。解决办法有几个一是查TensorRT的算子支持列表确认是否真的不支持二是用TensorRT的自定义插件机制实现这个算子三是修改模型结构用支持的算子替代。报错二Shape inference failedONNX导出时某些节点的shape推断失败。通常是因为模型里有动态控制流或者某些操作的shape依赖运行时数据。解决办法是简化模型结构把动态逻辑移到模型外面或者用torch.onnx.export的dynamic_axes参数显式指定动态维度。报错三ONNX model is invalid导出的ONNX模型本身有问题。用onnx.checker.check_model检查一下通常会给出具体的错误信息。常见原因是opset版本不匹配或者模型里有重复的节点名。6.2 引擎构建阶段的显存与精度问题问题一Out of memory during engine building构建引擎时显存不足。TensorRT在构建引擎时需要大量显存来做优化和kernel自动调优。解决办法是减小workspace大小或者用更小的batch size和更小的输入尺寸来构建。如果还是不行可能需要换显存更大的GPU。问题二FP16精度下准确率下降明显某些模型在FP16下会出现数值溢出或者下溢。解决办法是检查模型里是否有对数值范围敏感的操作比如softmax、layer norm。可以尝试对这些层保持FP32精度其他层用FP16。TensorRT支持逐层设置精度。问题三INT8校准后准确率崩了校准数据不能代表真实数据分布或者校准算法不适合这个模型。解决办法是换一批更有代表性的校准数据或者换一种校准器。有时候用IInt8MinMaxCalibrator比IInt8EntropyCalibrator2效果更好具体要看模型。6.3 推理阶段的性能异常排查现象一首次推理特别慢首次推理包含了CUDA kernel的加载和初始化慢是正常的。但如果后续推理也慢那就有问题。检查一下是不是每次推理都重新创建了context或者重新分配了显存。现象二推理结果和PyTorch不一致先检查输入数据是否完全一致包括数据类型、归一化方式、通道顺序。然后检查输出是否做了正确的后处理。如果这些都确认了那可能是精度问题试试用FP32构建引擎对比一下。现象三多线程下结果错乱大概率是共享了execution context。每个线程必须有自己的context。另外如果用了CUDA stream也要确保每个线程用自己的stream。问题现象可能原因排查方法解决方案ONNX导出报错算子不支持查看报错信息中的算子名替换算子或写插件引擎构建OOMworkspace太大减小workspace调小batch或输入尺寸FP16准确率下降数值溢出逐层对比精度敏感层保持FP32INT8准确率崩校准数据差换校准数据换校准器或增加数据首次推理慢kernel初始化测第二次推理正常现象可预热多线程结果错乱context共享检查context创建每线程独立context避坑技巧在构建引擎之前先用trtexec的--verbose参数跑一遍看看有没有warning。很多问题在warning里就有提示提前发现能省很多时间。7. 一些实战中攒下来的经验TensorRT的版本迭代很快每个大版本都会引入新特性和行为变化。我的建议是锁定一个稳定版本不要频繁升级。升级之前先在测试环境验证确认模型转换和推理都没问题再上生产。模型转换不是一次性的工作。每次模型结构有改动都需要重新导出ONNX、重新构建引擎。建议把整个流程脚本化用CI/CD跑起来减少手动操作带来的错误。性能调优是一个迭代过程。先跑通再优化。不要一上来就追求极致性能先把FP32跑通确认结果正确再逐步尝试FP16、INT8、动态Shape、多流并发。每一步都要验证准确率和性能确保优化没有引入问题。最后分享一个小技巧TensorRT的引擎文件是和GPU型号绑定的。在A卡上构建的引擎拿到B卡上可能加载失败或者性能很差。所以生产环境里引擎构建和推理部署要在同型号的GPU上进行。如果有多型号GPU的集群需要为每种型号分别构建引擎。 
长河君 · 2026/10/14 10:50:03 · 阅读 1.2k TensorRT推理加速实战：PyTorch模型部署与性能调优指南
1. 为什么值得折腾TensorRT从训练到推理的最后一公里搞深度学习的人都有一个共同的痛点模型在实验室里跑得挺好一上生产环境就拉胯。PyTorch训练出来的模型推理速度慢、显存占用高、吞吐量上不去尤其是在边缘设备或者需要实时响应的场景里这个问题会被无限放大。我最早接触TensorRT是在一个视频分析的项目里当时用PyTorch直接推理单帧处理时间接近200毫秒根本达不到实时要求。后来把模型转成TensorRT引擎同样的硬件条件下单帧降到了30毫秒以内吞吐量翻了将近7倍。这个差距不是靠调参能弥补的它来自底层推理框架对硬件的深度优化。TensorRT是NVIDIA推出的一套高性能深度学习推理SDK核心思路就一个针对特定GPU型号把训练好的模型重新编译成一个高度定制化的推理引擎。这个引擎会做几件关键的事——层融合、精度校准、内核自动调优、动态批处理。打个比方PyTorch模型像是一份通用菜谱什么厨房都能做但效率一般TensorRT引擎则像是针对你家厨房设备专门优化过的操作流程每一步都卡在最省时间的路径上。这套东西适合谁如果你正在做模型部署、推理加速、边缘计算或者你训练完模型发现推理速度实在没法接受那TensorRT就是绕不过去的一环。但要注意它不是万能药也不是所有模型都能无脑转。有些自定义算子、动态控制流、不支持的层类型都会让转换过程变得棘手。这篇文章我会从安装开始一步步讲到PyTorch模型怎么转成TensorRT引擎中间踩过的坑、绕过的弯、总结出来的经验都会毫无保留地分享出来。2. 环境准备与TensorRT安装别让版本兼容性把你劝退2.1 安装前的关键检查项TensorRT的安装本身不复杂复杂的是环境匹配。我见过太多人卡在版本不兼容上折腾一整天连第一个demo都跑不起来。所以在动手之前先把这几件事确认清楚。第一确认你的GPU型号和计算能力。TensorRT对GPU是有要求的太老的卡可能不支持最新版本。你可以用nvidia-smi查看GPU型号然后去NVIDIA官网查对应的计算能力Compute Capability。一般来说计算能力7.0以上的卡用起来比较舒服5.0到7.0之间的也能用但某些新特性可能受限。第二确认CUDA版本。TensorRT和CUDA的版本绑定非常紧密每个TensorRT版本都有对应的CUDA版本要求。比如TensorRT 8.6通常搭配CUDA 12.xTensorRT 8.5搭配CUDA 11.8。你不能随便混搭否则安装完import的时候直接报错。第三确认cuDNN版本。cuDNN是深度神经网络加速库TensorRT依赖它。版本也要和CUDA匹配这个在NVIDIA开发者网站上有明确的对应表。第四确认PyTorch版本。如果你打算用PyTorch的TensorRT部署路径PyTorch版本、CUDA版本、TensorRT版本三者必须形成一个兼容的三角关系。我的建议是先确定TensorRT版本然后反推CUDA和PyTorch版本这样最稳妥。注意不要盲目追求最新版本。最新版TensorRT可能刚发布不久和PyTorch的兼容性还没经过充分验证。选择一个发布3到6个月的稳定版本踩坑概率会低很多。2.2 三种安装方式的实际体验对比TensorRT的安装方式主要有三种pip安装、tar包安装、deb/rpm包安装。我三种都用过各有各的适用场景。pip安装是最省事的直接pip install tensorrt就行。但这种方式安装的TensorRT功能可能不完整某些组件比如trtexec命令行工具、Python的某些子模块可能缺失。如果你只是想快速跑通一个demopip安装够用。但要做完整的部署我不推荐这种方式。tar包安装是我最常用的方式。从NVIDIA官网下载对应版本的tar包解压后把lib路径加到LD_LIBRARY_PATH把Python包路径加到PYTHONPATH就完事了。这种方式的好处是灵活你可以同时装多个版本的TensorRT通过切换环境变量来切换版本。缺点是每次新开终端都要重新设置环境变量建议直接写进.bashrc或者.zshrc里。deb/rpm包安装适合在Ubuntu或者CentOS上做系统级部署。安装完自动配置好路径不用手动设置环境变量。但这种方式一个系统只能装一个版本版本切换很麻烦。我个人的选择是开发阶段用tar包方便切换版本做对比测试生产部署用deb包省去环境变量配置的麻烦。2.3 验证安装是否成功的完整流程安装完之后别急着跑模型先做几个基础验证确保环境没问题。# 检查TensorRT版本 python -c import tensorrt; print(tensorrt.__version__) # 检查CUDA是否可用 python -c import torch; print(torch.cuda.is_available()) # 检查cuDNN版本 python -c import torch; print(torch.backends.cudnn.version())如果这三条命令都能正常输出说明基础环境没问题。接下来可以跑一个官方的sample验证一下。TensorRT的tar包里通常自带sample目录里面有一些预编译好的例子。跑通一个最简单的sample比如sampleMNIST能进一步确认TensorRT的推理功能是正常的。还有一个容易被忽略的点检查trtexec是否可用。这个命令行工具在后续的模型转换和性能测试中非常有用。trtexec --help如果提示找不到命令说明trtexec所在的路径没有加到PATH里。tar包安装的话trtexec通常在bin目录下手动加一下就行。3. PyTorch模型转TensorRT的核心路径拆解3.1 为什么不能直接转换理解中间的IR环节很多人第一次尝试PyTorch转TensorRT的时候会想当然地以为有一个torch2trt的函数调一下就行了。实际上PyTorch模型不能直接转成TensorRT引擎中间必须经过一个中间表示Intermediate RepresentationIR。这个IR通常是ONNXOpen Neural Network Exchange。ONNX是一个开放的模型格式标准PyTorch可以导出ONNXTensorRT可以解析ONNX。所以完整的路径是PyTorch模型 → ONNX模型 → TensorRT引擎。为什么要多这一步因为TensorRT的优化器需要在一个标准化的计算图表示上做分析。PyTorch的动态图虽然灵活但包含了很多Python层面的控制逻辑TensorRT没法直接理解。ONNX把模型固化成一个静态的计算图每个节点都是标准的算子TensorRT才能在这个基础上做层融合、精度校准这些优化。但ONNX也不是完美的。有些PyTorch算子没有对应的ONNX算子导出的时候会报错或者产生不正确的图。有些算子虽然有对应的ONNX算子但TensorRT不支持。这些问题在转换过程中会一个个冒出来需要逐个解决。3.2 ONNX导出时的关键参数与避坑指南PyTorch导出ONNX的接口是torch.onnx.export这个函数的参数不少但真正影响转换成功率和后续TensorRT兼容性的主要是这几个。opset_versionONNX的算子集版本。这个参数非常关键版本太低可能缺少某些算子版本太高可能TensorRT还不支持。我的经验是TensorRT 8.x系列搭配opset 11到13比较稳。具体选哪个要看你模型里用到的算子。如果模型比较简单opset 11就够了如果用了比较新的算子可能需要opset 13甚至更高。input_names和output_names给输入输出节点起名字。这个看起来不起眼但在后续用TensorRT做推理的时候你需要通过这些名字来指定输入输出。如果名字乱起后面写推理代码的时候会很痛苦。建议用有意义的英文名比如input_ids、attention_mask、logits。dynamic_axes指定动态维度。如果你的模型支持变长输入比如NLP模型里的序列长度不固定就需要用这个参数把对应的维度标记为动态的。不设置的话导出的ONNX模型会固定住输入尺寸后续TensorRT也只能用这个固定尺寸。do_constant_folding常量折叠优化。这个参数默认是True建议保持。它会把模型里可以提前计算的常量表达式算好减小模型体积也能避免一些转换时的奇怪问题。torch.onnx.export( model, dummy_input, model.onnx, opset_version12, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}, output: {0: batch_size}}, do_constant_foldingTrue )导出完之后强烈建议用onnxruntime验证一下ONNX模型是否正确。有时候导出过程不报错但模型实际上是错的直接拿去转TensorRT会浪费很多时间。import onnxruntime as ort sess ort.InferenceSession(model.onnx) result sess.run(None, {input: dummy_input.numpy()})把ONNX模型的输出和PyTorch模型的输出对比一下误差在1e-4以内就算正常。3.3 TensorRT引擎构建的两种方式trtexec与Python API拿到ONNX模型之后构建TensorRT引擎有两条路用trtexec命令行工具或者用TensorRT的Python API。trtexec是最快的方式一行命令就能把ONNX转成引擎trtexec --onnxmodel.onnx --saveEnginemodel.engine --fp16这个命令会加载ONNX模型用FP16精度构建引擎然后保存成文件。trtexec还支持很多参数比如--best会自动选择最优精度--workspace指定显存工作空间大小--minShapes、--optShapes、--maxShapes指定动态尺寸的范围。用trtexec的好处是快适合快速验证和性能测试。但它的灵活性有限比如你想自定义某些层的精度或者想插入自定义插件就做不到了。Python API的方式更灵活代码量也不大import tensorrt as trt 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) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) config.set_flag(trt.BuilderFlag.FP16) engine builder.build_engine(network, config) with open(model.engine, wb) as f: f.write(engine.serialize())这段代码做了几件事创建builder和network用ONNX parser解析模型配置构建参数最后构建并序列化引擎。set_memory_pool_limit设置工作空间大小这个值影响TensorRT能做多少优化太小会导致某些优化无法进行太大会浪费显存。一般来说1GB到4GB之间比较合适。set_flag(trt.BuilderFlag.FP16)开启FP16精度。如果你的GPU支持INT8还可以用trt.BuilderFlag.INT8但INT8需要校准数据集流程会复杂一些。实操心得构建引擎的过程可能比较慢尤其是大模型。我遇到过一个模型构建引擎花了将近20分钟。建议把构建好的引擎保存成文件后续直接加载引擎做推理不要每次都重新构建。4. 精度选择与性能调优FP32、FP16还是INT84.1 三种精度的实际差异与选择逻辑TensorRT支持三种精度模式FP32、FP16、INT8。精度越低速度越快但准确率损失也越大。怎么选取决于你的场景对准确率的容忍度。FP32是默认精度和PyTorch训练时的精度一致准确率无损。但速度最慢显存占用也最大。如果你的场景对准确率要求极高或者模型本身对数值精度很敏感那就用FP32。FP16是半精度浮点速度通常比FP32快1.5到2倍显存占用减半。准确率损失一般很小在大多数视觉模型和NLP模型上FP16的准确率下降在0.1%到0.5%之间。我的经验是除非你的模型有特殊的数值稳定性问题否则FP16是性价比最高的选择。INT8是8位整数精度速度最快显存占用只有FP32的四分之一。但INT8需要校准也就是用一批代表性数据去统计激活值的分布确定量化的缩放因子。校准做得好准确率损失可以控制在1%以内校准做得不好准确率可能崩掉。INT8适合对速度要求极高、且能接受少量准确率损失的场景比如大规模推荐系统、实时视频分析。精度速度提升显存占用准确率损失适用场景FP32基准基准无准确率敏感型任务FP161.5-2倍约50%0.1%-0.5%大多数推理场景INT83-4倍约25%0.5%-2%极致速度要求场景4.2 INT8校准的实操细节INT8校准是TensorRT部署里最容易出问题的环节。校准的本质是用一批数据跑一遍模型统计每一层激活值的动态范围然后确定量化的缩放因子。校准数据的质量和数量直接影响最终的准确率。校准数据不需要标注但必须能代表真实推理时的数据分布。数量上我一般用500到1000个样本。太少的话统计不充分太多的话校准时间太长。校准数据要覆盖各种边界情况比如极端值、长尾分布否则量化后的模型在这些情况上会表现很差。TensorRT提供了几种校准器最常用的是IInt8EntropyCalibrator2。这个校准器用熵最小化的方法来确定缩放因子在大多数模型上表现不错。class Calibrator(trt.IInt8EntropyCalibrator2): def __init__(self, data_loader, cache_file): super().__init__() self.data_loader data_loader self.cache_file cache_file self.batch_idx 0 self.device_input cuda.mem_alloc(...) def get_batch_size(self): return self.batch_size def get_batch(self, names): # 返回一个batch的数据 ... def read_calibration_cache(self): # 读取缓存 ... def write_calibration_cache(self, cache): # 写入缓存 ...校准过程可能比较慢尤其是大模型。校准完成后TensorRT会把校准表缓存下来下次构建引擎时可以直接读取缓存不用重新校准。注意校准表是和校准数据、模型结构、TensorRT版本绑定的。换了任何一个校准表都要重新生成。不要试图复用一个旧的校准表。4.3 动态Shape与Batch Size的权衡动态Shape是TensorRT 7.0之后引入的特性允许引擎在运行时接受不同尺寸的输入。这对NLP模型特别重要因为序列长度经常变化。配置动态Shape需要指定三个范围最小尺寸、最优尺寸、最大尺寸。TensorRT会针对最优尺寸做优化同时保证在最小和最大尺寸之间都能正确运行。profile builder.create_optimization_profile() profile.set_shape(input, min(1, 3, 224, 224), opt(8, 3, 224, 224), max(32, 3, 224, 224)) config.add_optimization_profile(profile)最优尺寸的选择很关键。TensorRT会为最优尺寸生成最高效的kernel其他尺寸则可能退化到通用kernel。所以最优尺寸应该设为你实际推理时最常用的尺寸。动态Shape的代价是引擎构建时间更长显存占用更大。因为TensorRT需要为多个尺寸范围准备kernel。如果实际场景中输入尺寸是固定的那就不要用动态Shape固定尺寸的引擎性能更好。Batch Size的选择也要权衡。大batch能提高GPU利用率但会增加延迟。实时场景通常用batch size 1到4离线批处理可以用更大的batch。我的建议是先用batch size 1测延迟再用大batch测吞吐找到满足延迟要求前提下的最大batch。5. 部署落地从引擎文件到生产服务5.1 推理代码的完整实现框架引擎构建好之后部署的核心就是加载引擎、分配显存、执行推理、处理输出。下面是一个完整的推理框架。import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit import numpy as np class TRTInference: def __init__(self, engine_path): self.logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f: self.engine trt.Runtime(self.logger).deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() self.stream cuda.Stream() self.allocate_buffers() def allocate_buffers(self): self.inputs [] self.outputs [] self.bindings [] for binding in self.engine: size trt.volume(self.engine.get_binding_shape(binding)) dtype trt.nptype(self.engine.get_binding_dtype(binding)) host_mem cuda.pagelocked_empty(size, dtype) device_mem cuda.mem_alloc(host_mem.nbytes) self.bindings.append(int(device_mem)) if self.engine.binding_is_input(binding): self.inputs.append({host: host_mem, device: device_mem}) else: self.outputs.append({host: host_mem, device: device_mem}) def infer(self, input_data): np.copyto(self.inputs[0][host], input_data.ravel()) cuda.memcpy_htod_async(self.inputs[0][device], self.inputs[0][host], self.stream) self.context.execute_async_v2(bindingsself.bindings, stream_handleself.stream.handle) for out in self.outputs: cuda.memcpy_dtoh_async(out[host], out[device], self.stream) self.stream.synchronize() return [out[host] for out in self.outputs]这段代码做了几件事反序列化引擎、创建执行上下文、分配host和device内存、执行异步推理、拷贝结果回host。pagelocked_empty分配的是锁页内存比普通内存的拷贝速度快。execute_async_v2是异步执行配合CUDA stream可以实现流水线并行。5.2 多线程与多流并发的注意事项在生产环境里单线程推理往往无法充分利用GPU。多线程或者多流并发能显著提高吞吐量但也有一些坑。TensorRT的execution context不是线程安全的。如果你在多线程里共享一个context会出现各种奇怪的错误。正确的做法是每个线程创建自己的context共享同一个engine。engine是线程安全的context不是。# 每个线程创建自己的context context engine.create_execution_context()多流并发是另一种提高吞吐的方式。创建多个CUDA stream每个stream上跑一个推理请求GPU可以同时执行多个stream上的kernel。但要注意显存是有限的并发太多会导致显存不足。而且GPU的计算资源也是有限的并发超过一定数量后吞吐量不会再提升反而可能因为资源竞争而下降。我的经验是先用单流测出基准吞吐量然后逐步增加并发数观察吞吐量的变化。当吞吐量不再明显提升时就是最优并发数。5.3 性能监控与瓶颈定位部署上线之后性能监控是必不可少的。你需要知道推理的延迟、吞吐量、GPU利用率、显存占用这些指标。延迟和吞吐量可以在应用层统计。GPU利用率和显存占用可以用nvidia-smi或者pynvml来采集。import pynvml pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) util pynvml.nvmlDeviceGetUtilizationRates(handle) memory pynvml.nvmlDeviceGetMemoryInfo(handle) print(fGPU利用率: {util.gpu}%, 显存占用: {memory.used / 1024**2:.0f}MB)如果GPU利用率很低说明瓶颈可能在数据预处理或者后处理上GPU在等数据。如果GPU利用率很高但吞吐量上不去说明瓶颈在GPU计算上可能需要优化模型或者换更强的GPU。还有一个容易被忽略的瓶颈是内存拷贝。host到device的拷贝、device到host的拷贝如果数据量大拷贝时间可能超过计算时间。解决办法是用锁页内存、异步拷贝、CUDA stream重叠拷贝和计算。6. 常见问题与排查技巧实录6.1 ONNX导出与解析阶段的典型报错报错一Unsupported operator这是最常见的报错。PyTorch的某个算子没有对应的ONNX算子或者TensorRT不支持这个ONNX算子。解决办法有几个一是查TensorRT的算子支持列表确认是否真的不支持二是用TensorRT的自定义插件机制实现这个算子三是修改模型结构用支持的算子替代。报错二Shape inference failedONNX导出时某些节点的shape推断失败。通常是因为模型里有动态控制流或者某些操作的shape依赖运行时数据。解决办法是简化模型结构把动态逻辑移到模型外面或者用torch.onnx.export的dynamic_axes参数显式指定动态维度。报错三ONNX model is invalid导出的ONNX模型本身有问题。用onnx.checker.check_model检查一下通常会给出具体的错误信息。常见原因是opset版本不匹配或者模型里有重复的节点名。6.2 引擎构建阶段的显存与精度问题问题一Out of memory during engine building构建引擎时显存不足。TensorRT在构建引擎时需要大量显存来做优化和kernel自动调优。解决办法是减小workspace大小或者用更小的batch size和更小的输入尺寸来构建。如果还是不行可能需要换显存更大的GPU。问题二FP16精度下准确率下降明显某些模型在FP16下会出现数值溢出或者下溢。解决办法是检查模型里是否有对数值范围敏感的操作比如softmax、layer norm。可以尝试对这些层保持FP32精度其他层用FP16。TensorRT支持逐层设置精度。问题三INT8校准后准确率崩了校准数据不能代表真实数据分布或者校准算法不适合这个模型。解决办法是换一批更有代表性的校准数据或者换一种校准器。有时候用IInt8MinMaxCalibrator比IInt8EntropyCalibrator2效果更好具体要看模型。6.3 推理阶段的性能异常排查现象一首次推理特别慢首次推理包含了CUDA kernel的加载和初始化慢是正常的。但如果后续推理也慢那就有问题。检查一下是不是每次推理都重新创建了context或者重新分配了显存。现象二推理结果和PyTorch不一致先检查输入数据是否完全一致包括数据类型、归一化方式、通道顺序。然后检查输出是否做了正确的后处理。如果这些都确认了那可能是精度问题试试用FP32构建引擎对比一下。现象三多线程下结果错乱大概率是共享了execution context。每个线程必须有自己的context。另外如果用了CUDA stream也要确保每个线程用自己的stream。问题现象可能原因排查方法解决方案ONNX导出报错算子不支持查看报错信息中的算子名替换算子或写插件引擎构建OOMworkspace太大减小workspace调小batch或输入尺寸FP16准确率下降数值溢出逐层对比精度敏感层保持FP32INT8准确率崩校准数据差换校准数据换校准器或增加数据首次推理慢kernel初始化测第二次推理正常现象可预热多线程结果错乱context共享检查context创建每线程独立context避坑技巧在构建引擎之前先用trtexec的--verbose参数跑一遍看看有没有warning。很多问题在warning里就有提示提前发现能省很多时间。7. 一些实战中攒下来的经验TensorRT的版本迭代很快每个大版本都会引入新特性和行为变化。我的建议是锁定一个稳定版本不要频繁升级。升级之前先在测试环境验证确认模型转换和推理都没问题再上生产。模型转换不是一次性的工作。每次模型结构有改动都需要重新导出ONNX、重新构建引擎。建议把整个流程脚本化用CI/CD跑起来减少手动操作带来的错误。性能调优是一个迭代过程。先跑通再优化。不要一上来就追求极致性能先把FP32跑通确认结果正确再逐步尝试FP16、INT8、动态Shape、多流并发。每一步都要验证准确率和性能确保优化没有引入问题。最后分享一个小技巧TensorRT的引擎文件是和GPU型号绑定的。在A卡上构建的引擎拿到B卡上可能加载失败或者性能很差。所以生产环境里引擎构建和推理部署要在同型号的GPU上进行。如果有多型号GPU的集群需要为每种型号分别构建引擎。