1. 为什么你的模型在 GPU 上跑得不够快TensorRT 模型部署的真实场景如果你已经把 PyTorch 或 TensorFlow 模型训练好了准备放到 GPU 服务器上做推理服务大概率会遇到一个尴尬的情况模型能跑但延迟高、显存占用大、吞吐上不去。尤其是做视觉检测、分割、OCR 这类任务时单张图推理动辄几十毫秒QPS 一上来 GPU 利用率却只有 30% 左右。这时候 TensorRT 模型部署就成了绕不开的一环。TensorRT 是 NVIDIA 推出的 GPU 推理加速 SDK它做的事情可以简单理解为把你训练好的模型ONNX、PyTorch 导出等拿过来做层融合、精度校准、kernel 自动调优最后生成一个针对你当前 GPU 架构高度优化的 engine 文件。这个 engine 在推理时不需要再走框架的解释执行直接调用底层 CUDA kernel延迟通常能降到原来的 1/2 到 1/5显存占用也会明显下降。它适合谁适合已经有一块 NVIDIA GPU比如 T4、A10、3090、4090并且需要把模型真正落地成在线服务的开发者。如果你只是做实验、跑 notebookTensorRT 的收益没那么明显但一旦进入部署阶段安装与使用 TensorRT 就是必须掌握的技能。我试过在一个检测模型上做对比原始 PyTorch FP32 推理单张 640x640 图片约 45ms转成 TensorRT FP16 engine 后降到 12ms 左右显存从 2.1GB 降到 900MB。这个差距在并发场景下会被进一步放大。下面我把从环境安装、版本匹配、engine 构建到推理验证的完整流程拆开讲每一步都给可复制的命令和配置。2. TensorRT 安装前的环境准备与版本匹配CUDA、cuDNN、Python wheel 怎么选TensorRT 安装最容易踩的坑不是命令本身而是版本对不上。TensorRT 和 CUDA、cuDNN、驱动版本之间有严格的对应关系装错了轻则 import 失败重则 build engine 时直接崩溃。所以第一步不是急着下载而是先把版本矩阵确认清楚。先看你的 GPU 驱动支持的最高 CUDA 版本命令是nvidia-smi右上角会显示 CUDA Version。注意这个是你驱动能支持的最高版本不是你实际安装的版本。然后用nvcc -V看你实际装的 CUDA Toolkit 版本。TensorRT 要跟实际 CUDA Toolkit 版本匹配而不是驱动版本。假设你用的是 CUDA 11.8那么对应可以选择 TensorRT 8.5.x 或 8.6.x。下载地址在 NVIDIA 官网的 TensorRT 下载页选择 zip 包而不是 deb 或 tar因为 zip 包最灵活可以同时拿到 Python wheel、C 库和头文件。下载下来类似TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz这样的文件。解压后目录结构是这样的lib放动态库include放头文件python放 wheel 包bin放trtexec等工具。接下来分两条线配置Python 环境和 C 环境。Python 这边先创建虚拟环境避免污染系统 Pythonconda create -n trt_env python3.10 -y conda activate trt_env然后进入解压目录的 python 文件夹根据你的 Python 版本选择对应 wheel。比如 Python 3.10 就装tensorrt-8.6.1-cp310-none-linux_x86_64.whlcd TensorRT-8.6.1.6/python pip install tensorrt-8.6.1-cp310-none-linux_x86_64.whl pip install tensorrt_lean-8.6.1-cp310-none-linux_x86_64.whl pip install tensorrt_dispatch-8.6.1-cp310-none-linux_x86_64.whl如果你要用 ONNX 解析还需要装graphsurgeon和onnx_graphsurgeon它们也在 python 目录下。装完后验证python -c import tensorrt; print(tensorrt.__version__)能打印出版本号就说明 Python 侧 OK 了。C 侧则需要把lib目录加到LD_LIBRARY_PATH把include加到编译器的 include 路径。在~/.bashrc里加export TRT_PATH/opt/TensorRT-8.6.1.6 export LD_LIBRARY_PATH$TRT_PATH/lib:$LD_LIBRARY_PATH export PATH$TRT_PATH/bin:$PATH然后source ~/.bashrc。这样trtexec命令就能直接用了后面验证 engine 会用到它。注意如果你在 Docker 里部署建议直接把 TensorRT 的 lib 和 include 拷进镜像而不是依赖宿主机环境变量否则容器重启后容易丢配置。版本匹配这块再强调一次CUDA 11.8 配 TensorRT 8.5/8.6CUDA 12.x 配 TensorRT 8.6/9.x/10.x。如果你用的是 TensorRT 10API 有较大变化build_engine被build_serialized_network取代老代码不能直接跑。所以生产环境建议锁定一个稳定版本不要盲目追新。3. 可复制的 TensorRT 配置骨架ONNX 转 engine 的 Python 脚本与参数说明环境装好之后核心工作就是把模型转成 TensorRT engine。目前最通用的路径是PyTorch → ONNX → TensorRT engine。中间用 ONNX 做桥梁是因为 TensorRT 的 ONNX Parser 最成熟支持算子最全。先导出 ONNX。以 PyTorch 为例import torch import torch.nn as nn class SimpleModel(nn.Module): def __init__(self): super().__init__() self.conv nn.Conv2d(3, 16, 3, padding1) self.pool nn.MaxPool2d(2, 2) self.relu nn.ReLU() def forward(self, x): return self.relu(self.pool(self.conv(x))) model SimpleModel().cuda().eval() dummy torch.randn(1, 3, 224, 224).cuda() torch.onnx.export( model, dummy, model.onnx, input_names[input], output_names[output], opset_version11, dynamic_axes{input: {0: batch}, output: {0: batch}} )这里dynamic_axes很关键它让 batch 维度变成动态的后面 TensorRT 才能接受不同 batch size 的输入。如果你不需要动态 shape可以去掉。接下来是 TensorRT 的构建脚本。我把它写成一个可复用的函数参数用 JSON 风格配置方便你直接改import tensorrt as trt import json CONFIG { onnx_path: model.onnx, engine_path: model.engine, fp16: True, int8: False, workspace_gb: 4, min_shape: [1, 3, 224, 224], opt_shape: [4, 3, 224, 224], max_shape: [8, 3, 224, 224], input_name: input } def build_engine(cfg): 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(cfg[onnx_path], rb) as f: if not parser.parse(f.read()): for i in range(parser.num_errors): print(parser.get_error(i)) raise RuntimeError(ONNX parse failed) config builder.create_builder_config() config.set_memory_pool_limit( trt.MemoryPoolType.WORKSPACE, cfg[workspace_gb] 30 ) if cfg[fp16] and builder.platform_has_fast_fp16: config.set_flag(trt.BuilderFlag.FP16) if cfg[int8] and builder.platform_has_fast_int8: config.set_flag(trt.BuilderFlag.INT8) profile builder.create_optimization_profile() profile.set_shape( cfg[input_name], tuple(cfg[min_shape]), tuple(cfg[opt_shape]), tuple(cfg[max_shape]) ) config.add_optimization_profile(profile) serialized builder.build_serialized_network(network, config) if serialized is None: raise RuntimeError(Engine build failed) with open(cfg[engine_path], wb) as f: f.write(serialized) print(fEngine saved to {cfg[engine_path]}) if __name__ __main__: build_engine(CONFIG)这段脚本里几个参数值得展开说。workspace_gb是构建时允许使用的显存上限太小会导致某些层无法用最优 kernel太大会浪费显存一般 2 到 8GB 够用。min_shape、opt_shape、max_shape是动态 shape 的三档配置TensorRT 会针对opt_shape做重点优化所以你应该把最常用的 batch size 填在opt_shape。fp16开启后精度损失通常很小但速度提升明显int8需要校准数据集后面单独讲。如果你用命令行trtexec也能直接转trtexec --onnxmodel.onnx --saveEnginemodel.engine \ --fp16 --minShapesinput:1x3x224x224 \ --optShapesinput:4x3x224x224 \ --maxShapesinput:8x3x224x224trtexec的好处是它会自动打印每层的耗时和显存占用方便你定位瓶颈层。实测下来先用trtexec跑一遍看 profile再用 Python 脚本固化配置是比较顺的流程。4. 验证 TensorRT 推理请求engine 加载、异步执行与精度延迟对比engine 构建好之后必须验证它真的能跑而且结果和原始模型一致。这一步很多人跳过结果上线后才发现输出对不上。验证分三块加载 engine、执行推理、对比精度和延迟。先写一个 Python 推理封装import tensorrt as trt import torch import numpy as np class TRTInfer: def __init__(self, engine_path): logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f: runtime trt.Runtime(logger) self.engine runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() self.stream torch.cuda.Stream() def infer(self, input_tensor): input_tensor input_tensor.cuda().contiguous() self.context.set_input_shape(input, tuple(input_tensor.shape)) output_shape tuple(self.context.get_tensor_shape(output)) output torch.empty(output_shape, dtypetorch.float32, devicecuda) bindings [0] * self.engine.num_bindings bindings[self.engine.get_binding_index(input)] input_tensor.data_ptr() bindings[self.engine.get_binding_index(output)] output.data_ptr() self.context.execute_async_v2( bindings, torch.cuda.current_stream().cuda_stream ) torch.cuda.synchronize() return output加载 engine 时用deserialize_cuda_engine执行时用execute_async_v2配合 CUDA stream这样能和其他 GPU 任务重叠。注意set_input_shape必须在每次输入 shape 变化时调用否则动态 shape 会报错。验证精度拿同一个输入分别跑 PyTorch 和 TensorRT对比输出的最大绝对误差。FP16 下一般误差在 1e-3 量级如果超过 1e-2 就要检查是不是某些层不支持 FP16 被回退了。x torch.randn(1, 3, 224, 224) with torch.no_grad(): torch_out model(x.cuda()).cpu().numpy() trt_out trt_infer.infer(x).cpu().numpy() print(max abs diff:, np.abs(torch_out - trt_out).max())验证延迟用trtexec最方便trtexec --loadEnginemodel.engine --shapesinput:4x3x224x224 \ --warmUp500 --duration10 --fp16它会输出GPU Compute Time的 mean、median、percentile这就是你的真实推理延迟。对比 PyTorch 的延迟可以用torch.cuda.Event计时跑 100 次取平均。我实测一个 ResNet50 分类模型PyTorch FP32 在 T4 上 batch4 时约 28msTensorRT FP16 约 7ms加速比 4 倍左右。显存从 1.8GB 降到 700MB。这个数据因模型和 GPU 而异但量级上 TensorRT 的收益是稳定的。注意第一次跑 engine 会有初始化开销测延迟前一定要 warm up否则数据会偏高。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth 与 engine 构建失败部署过程中报错是常态这里列几个高频问题和定位方法。报错一ImportError: libnvinfer.so.8: cannot open shared object file这是LD_LIBRARY_PATH没配好。检查echo $LD_LIBRARY_PATH是否包含 TensorRT 的 lib 目录。如果是在 Python 虚拟环境里确认虚拟环境激活后环境变量还在。Docker 里则要在 Dockerfile 里显式ENV LD_LIBRARY_PATH。报错二[TRT] Error Code 3: API Usage Error ... input tensor shape out of range动态 shape 超出 profile 范围。比如你设的 max_shape 是 8但推理时传了 batch16。解决办法是重新构建 engine 把 max_shape 调大或者在推理前做 batch 裁剪。注意 max_shape 越大构建时间和显存占用越高要权衡。报错三onnx parse failed: Unsupported operatorONNX 里有 TensorRT 不支持的算子。先用trtexec --onnxmodel.onnx --verbose看具体是哪个节点。常见的是自定义算子或某些新版本 PyTorch 导出的算子。解决办法是用onnx_graphsurgeon做算子替换或者升级 TensorRT 版本。报错四CUDA out of memory在 build engine 阶段workspace_gb设太大了。降到 2GB 试试。另外构建时如果同时有其他进程占显存也会失败先nvidia-smi确认空闲显存。报错五local proxy failed或网络相关错误如果你在拉取模型或依赖时遇到网络问题检查 pip 源和代理配置。生产环境建议用内网镜像源避免构建时卡在网络请求上。报错六reading choices或配置解析失败这类错误通常出现在用配置文件驱动构建脚本时JSON 或 YAML 格式不对。用python -m json.tool config.json验证 JSON 合法性。如果是 OAuth 相关的认证失败检查 token 是否过期重新生成即可。排查思路总结成一句话先看错误码再看是构建期还是推理期构建期多半是版本和 shape 问题推理期多半是绑定和显存问题。把trtexec --verbose和trt.Logger.VERBOSE打开日志会告诉你具体哪一层出的问题。6. 从安装到加速推理的闭环把 TensorRT 接入你的服务链路走到这里你已经完成了 TensorRT 的安装、engine 构建、推理验证和排错。最后一步是把它接入真实服务。这里给几个实用建议。第一engine 文件不要每次启动都重新构建。构建一次可能几十秒到几分钟线上服务等不起。把 engine 存到本地或对象存储启动时直接deserialize。但要注意 engine 和 GPU 架构绑定T4 上构建的 engine 不能拿到 A10 上用跨卡部署要分别构建。第二动态 shape 的 profile 要按真实流量设置。如果你的服务 batch 大部分是 1偶尔到 8那opt_shape设 1 或 2max_shape设 8。这样大部分请求走最优 kernel少数大 batch 也能兜住。第三INT8 量化能再提速一倍左右但需要校准数据集。用trt.IInt8EntropyCalibrator2实现一个校准器喂 500 到 1000 张代表性图片让 TensorRT 统计激活分布。精度损失通常控制在 1% 以内但检测类任务要仔细验证小目标召回。第四监控推理延迟的 P99 而不是均值。TensorRT 的均值很漂亮但 P99 可能因为显存碎片或 kernel 切换而抖动。用 Prometheus 采集trtexec或自己埋点的延迟分布设置告警阈值。如果你在找稳定的模型接入和 API 管理方案可以了解下 TaoToken 的模型对话和 Coding Plan它提供了 API Key 管理和接入文档适合把多个模型统一到一个入口做调度。具体可以看 https://taotoken.net/api 和接入文档API Keys 在 console 里生成。最后TensorRT 不是银弹。它适合推理密集、延迟敏感的场景。如果你的模型算子太新、动态控制流太多可能转 ONNX 都困难这时候要考虑用 TensorRT 的 plugin 机制自己实现算子或者退回 PyTorch TorchScript。部署这件事能跑通、能监控、能回滚比单纯追求极致延迟更重要。