ONNX Runtime迁TensorRT原生：GPU推理延迟降低50%实战

模型推理延迟卡在 4 毫秒附近上不去、GPU 利用率一直没过三成，这是我当时用 ONNX Runtime 上线检测服务最大的两个痛点。后来我把整套链路从 ONNX Runtime 迁到了 TensorRT 原生引擎，同样的模型、同一块 GPU，单帧延迟压到 2 毫秒以内，批量吞吐翻了一倍多。这篇就把这次推理加速的完整探索过程拆开讲：为什么值得从 ORT 迁到原生 TensorRT、环境怎么配、pt 权重怎么一步步转成 trt 引擎、原生推理代码怎么写、评测怎样才公平，以及文档里不会写的几个坑。适合已经在用 ONNX Runtime 做部署、想进一步榨干 GPU 性能的读者，也适合刚接触 TensorRT 的人用来建立一条完整的转换-验证-部署链路。

1. 为什么从 ONNX Runtime 迁到 TensorRT 原生：先讲我的延迟调查

1.1 用 ORT 部署本来挺顺，但瓶颈其实早就埋下了

用 ONNX Runtime 的优势很清楚：把 PyTorch 模型 export 成 onnx，然后配一下 CUDA execution provider，十几行代码就能把服务跑起来。我最早也是这么上线的，模型是 YOLOv5s 检测器，输入 640×640，跑在 RTX 3090 上，单帧延迟大概 4.2ms，看起来完全够用。

但压测一段时间后，nvidia-smi 显示 GPU 利用率经常只有 25% 到 35%，延迟忽高忽低，Batch 一调大反而出现掉帧。排查后我才意识到，ONNX Runtime 本质上是一个图解释器，它把模型按算子逐个调度到 cuDNN、cuBLAS 这些底层库上执行。单个算子的性能并不差，但 conv+bn+relu 这种高频组合在 ORT 里会变成三次独立的 kernel launch，每一次都有调度和显存读写开销。层数一多、Batch 一大，这部分开销就变得非常可观。

这也解释了为什么 ORT 的 CUDA EP 适合快速上线，但离 GPU 理论性能总有一截距离。TensorRT 的优势恰恰是在编译层面把可融合的算子合并成一个 kernel，把整个网络变成一个优化过的执行计划，而不是逐节点解释执行。这正是推理加速最需要补的功课。

1.2 ORT 的 TensorRT EP，和"原生"到底差在哪

很多人会问：ONNX Runtime 不也提供了 TensorRT execution provider 吗？直接用不行吗？我用过之后建议：可以拿来过渡，但别把 ORT 加 TRT EP 当作原生 TensorRT 来用。

ORT 的 TensorRT EP 工作方式是把 ONNX 图做子图划分，把能转的算子交给 TensorRT 编译，剩下的算子留在 ORT 里。这个方案有三个实际问题：子图边界上要频繁做显存拷贝和 ownership 交接；一旦模型里有 ORT 分不干净的算子，整条链路会被拖慢；TRT EP 的算子支持范围跟 ORT 版本绑定，升级 TensorRT 时还可能遇到子图划分行为变化导致性能回退。我实测 ORT 加 TensorRT EP 相对 ORT CUDA EP 大约能快 18%，但这个收益没到原生产物的水平，还引入了版本兼容的复杂度。

原生 TensorRT 路径则是把 ONNX 整图交给 TensorRT 的 parser，由它统一构图、融合、选择 kernel，最终产出一个序列化的 engine。运行时只需要反序列化 engine 并执行，调度开销非常小。代价是你要自己管理 binding、显存和执行上下文。这篇文章后续全部围绕这条原生路径展开。

1.3 迁移前的收益预估，避免白忙一场

任何加速改造前都该先估算收益边界。对 CNN 类检测和分割模型，TensorRT 相对 ORT 加 CUDA EP 通常能带来 20% 到 50% 的延迟下降；如果同时开 FP16，收益还会更高。但换到算子非常离散的模型，比如有大量自定义算子、频繁做 tensor 重排的模型，收益可能很小，甚至因为转换失败得不偿失。

我的做法是先跑一遍 trtexec 的快速 benchmark 再决定。如果延迟下降超过 15%，就投入人力接入生产；低于这个阈值，继续优化 ONNX 图可能更划算。这个前置判断很重要，它避免了你花一周时间改造完才发现收益不够的尴尬。

2. TensorRT 环境搭建：版本匹配是第一个大坑

2.1 版本矩阵到底怎么对齐

TensorRT 的安装问题常年排在踩坑率第一名。它不是一个纯 Python 库，底层依赖 CUDA runtime、cuDNN，还要和驱动版本匹配。很多报错根本不是代码写法问题，而是版本没对齐。

先说结论：如果你主要用 Python 做实验，直接 pip install 官方 wheel 即可。官方从 8.5 开始提供带 CUDA 依赖的 pip 包，8.6 之后逐步统一成 tensorrt 加 tensorrt-cu11、tensorrt-cu12 这样的命名。装之前先用 nvcc --version 看 toolkit 版本，用 nvidia-smi 看驱动版本。TensorRT 对 CUDA 版本的要求是向下兼容，但 pip 和 deb 两套安装方式混用很容易把环境搞乱。

最省心的方案是直接用 NVIDIA 官方 PyTorch 容器。ngc.nvidia.com 上的 nvcr.io/nvidia/pytorch 镜像把 CUDA、cuDNN、TensorRT、PyTorch 的版本一次性对齐了，能省掉八成环境折腾。我的建议是先用容器把整条链路跑通，确认模型和代码都没问题，再回到裸机复制一套相同版本组合。这样即使裸机出问题，你也知道是环境问题而不是代码问题。

2.2 安装后的验证与典型失败症状

装完别急着写代码，先做三个检查：

python -c "import tensorrt; print(tensorrt.__version__)" trtexec --help python -c "import onnxruntime; print(onnxruntime.__version__)"

第一个检查包是否可用，第二个检查命令行工具是否在 PATH 里，第三个确认 ONNX Runtime 版本没有被意外升级。我见过太多人花两小时排查代码，最后发现只是 trtexec 没在 PATH 里。

常见失败症状和对应解决办法：

• trtexec 找不到：deb 安装和 pip 安装混用了。确保 PATH 指向 pip 安装的 bin 目录，或者干脆统一用 pip 重装。
• ImportError: libcudart.so.xx: cannot open shared object file：CUDA runtime 库路径没加载。把 TensorRT 依赖的 lib 目录加进 LD_LIBRARY_PATH，多数情况是 cuDNN 没装全或版本不一致。
• torch 能跑、tensorrt 不能跑：典型标志是 CUDA driver 版本低于 TensorRT 要求的 runtime 版本，优先升级驱动。

提示：环境问题不要靠"重新装一遍"解决。先记录三个版本号：驱动版本、CUDA runtime 版本、TensorRT 包版本。新人对不上号的问题，九成能靠这张表定位。

3. 转换链路实战：从 pt 权重到 trt 引擎

3.1 PyTorch 导出 ONNX 的四个关键配置

TensorRT 不直接吃 pt 文件，标准流程是先转 ONNX。导出这一步决定了后面能不能顺利转换，重点在四处：动态轴、opset 版本、do_constant_folding 和导出后的图清理。

模型从 pt 转 onnx 就失败的情况大多是因为把尺寸写死了。下面这个导出模板是我一直在用的：

import torch model = torch.load("yolov5s.pt", map_location="cpu")["model"].float() model.eval() dummy = torch.zeros(1, 3, 640, 640) torch.onnx.export( model, dummy, "yolov5s.onnx", opset_version=17, do_constant_folding=True, input_names=["images"], output_names=["output"], dynamic_axes={ "images": {0: "batch", 2: "height", 3: "width"}, "output": {0: "batch"}, }, )

opset 建议 16 到 17，TensorRT 对相对新的 opset 支持更完整。动态轴里 batch 一般都要放开，宽高如果部署输入固定，可以只留 batch 动态来降低转换复杂度。导出完成后用 onnx-simplifier 清理一次图中的冗余节点，比如 Identity、重复 Cast 这些，再用 onnxruntime 跑一遍确认输出和原模型对得上。这一步不能省，很多 TensorRT 转换报错追根溯源都是 onnx 图里混进了脏节点。

3.2 先用 trtexec 验证转换可行性

拿到干净的 onnx 后，我会先用 trtexec 做快速验证。它能直接输出 engine 构建信息、kernel 耗时和各阶段延迟，省去先写 Python builder 的麻烦。

trtexec --onnx=yolov5s.onnx \ --saveEngine=yolov5s.trt \ --fp16 \ --minShapes=images:1x3x640x640 \ --optShapes=images:4x3x640x640 \ --maxShapes=images:8x3x640x640

注意动态形状必须把三个 profile 一起给：min 是最小 shape，opt 是优化目标，max 是上限。构建引擎时 TensorRT 会针对 opt shape 做最大程度的 kernel autotuning，运行时只要 shape 落在区间内都能跑，但低于 opt 的 shape 性能会打折。这一步如果报错，大多是某个算子不支持，可以升级 opset、简化图或替换掉冷门 op 来定位。

3.3 用 Python API 构建正式引擎

trtexec 验证通过后，再换成 Python API 集成进项目，方便把构建参数纳入自动化脚本。

import tensorrt as trt TRT_LOGGER = trt.Logger(trt.Logger.WARNING) def build_engine(onnx_path, save_path): builder = trt.Builder(TRT_LOGGER) network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser = trt.OnnxParser(network, TRT_LOGGER) with open(onnx_path, "rb") as f: ok = parser.parse(f.read()) if not ok: for i in range(parser.num_errors): print(parser.get_error(i)) return None config = builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30) config.set_flag(trt.BuilderFlag.FP16) profile = builder.create_optimization_profile() profile.set_shape("images", (1, 3, 640, 640), (4, 3, 640, 640), (8, 3, 640, 640)) config.add_optimization_profile(profile) engine = builder.build_serialized_network(network, config) with open(save_path, "wb") as f: f.write(engine) return engine

这里有两个容易被忽略的细节。create_network 必须带 EXPLICIT_BATCH 标志，否则动态 batch 会解析失败。workspace 是构建引擎时允许使用的最大显存空间，不是运行时常驻，给太大会让 kernel autotuning 试更多方案导致构建变慢，给太小则会限制 kernel 选择范围，最终性能受损。

4. 原生 TensorRT 推理代码：自己管显存换来的低开销

4.1 引擎加载与三个核心对象

原生推理和 ORT 的最大区别是：没有 Session，没有抽象的输入输出封装，一切围绕 engine、execution context、binding 三个对象展开。

import tensorrt as trt class TRTEngine: def __init__(self, engine_path): with open(engine_path, "rb") as f: engine_data = f.read() runtime = trt.Runtime(TRT_LOGGER) self.engine = runtime.deserialize_cuda_engine(engine_data) self.context = self.engine.create_execution_context() def get_input_shape(self, name): return self.engine.get_binding_shape(name)

需要理解的是：engine 是编译产物，可以多个线程共享；execution context 是每次执行的状态，推荐每个并发线程单独持有一个 context。引擎文件本身和运行语言无关，用 Python 构建的 engine 可以直接被 C++ 程序反序列化执行，反过来也一样。所以如果后续要做 C++ 部署，不需要重新转换，只要保证部署机上的 TensorRT 版本一致就行。

4.2 动态形状下输入输出的绑定与显存分配

动态形状模型里，每次推理前要把实际 shape 告诉 context，再根据 binding shape 分配显存。TensorRT 的输出 binding 不会自动带出具体尺寸，必须在 set_binding_shape 之后再读取。

import numpy as np import pycuda.driver as cuda def infer(self, input_np, stream): batch = input_np.shape[0] self.context.set_binding_shape(0, (batch, 3, 640, 640)) out_shape = self.context.get_binding_shape(1) out_size = int(np.prod(out_shape)) d_input = cuda.mem_alloc(input_np.nbytes) d_output = cuda.mem_alloc(out_size * 4) cuda.memcpy_htod_async(d_input, input_np, stream) self.context.execute_async_v2(bindings=[d_input, d_output], stream_handle=stream.handle) cuda.memcpy_dtoh_async(output_np, d_output, stream) stream.synchronize()

binding 的顺序以 engine 内定义为准，可以用 engine.binding_is_input 和 engine.get_binding_name 遍历确认。生产环境里，输入输出 buffer 应该在第一次推理后常驻，不要每帧都 mem_alloc。这段代码虽然比 ORT 麻烦，但省掉了每层解释、每层调度的额外开销，这正是大吞吐低延迟的关键。

4.3 用 CUDA Stream 把拷贝和计算重叠

我上线多路视频流时踩过一个坑：每个线程各自分配 stream、各自等待，结果 GPU 利用率反而上不去。后来改成所有推理共享同一个 CUDA stream，但 preprocess 和 postprocess 放到线程里并行做，效果立刻改善。

核心理念是让数据搬运和 kernel 执行重叠。输入先异步拷到显存，execution 提交到 stream，再异步拷回结果，最后统一 synchronize。这个模式下 CPU 不会被 GPU 执行时间卡死，GPU 空转的时间也大幅减少。如果需要更高吞吐，还可以把一个 batch 的多路输入先拼成一个大 tensor 再提交，比反复提交小 batch 稳定得多。

5. 评测方法：别只盯着一个延迟数字

5.1 用 CUDA event 而不是 time.time

聊加速效果之前，先说你几乎一定会踩的坑：用 Python 的 time 包测 GPU 推理时间。CPU 计时会把 kernel 排队、CPU 等待混进来，而且不预热的话第一次调用还包含显存分配和 kernel 编译，结果严重失真。

正确做法是用 CUDA event 测量 GPU 端耗时：

start = cuda.Event() end = cuda.Event() start.record(stream) for _ in range(100): context.execute_async_v2(bindings, stream.handle) end.record(stream) stream.synchronize() print("avg time:", start.time_till(end) / 100, "ms")

我的统计口径是：先跑 50 轮 warmup，再连续测 500 次，分别记录 p50、p95、p99。只看平均数会被初始化峰值拉高，只看最好成绩又过于乐观。生产环境真正要看的是 p99，它决定了会不会出现偶发超时。

5.2 一组可以复现的对比数据

以下是我在 RTX 3090 上跑 YOLOv5s、输入 640×640 的实测数据，单 batch 延迟取 p50：

Batch=8 的吞吐差距更能说明问题：ORT CUDA EP 大概在 480 FPS 左右，TensorRT 原生 FP16 能到 1350 FPS 以上。原因在于 TensorRT 会把连续 batch 的计算合并成更大的 kernel 执行，减少显存往返，而 ORT 在算子调度层面的消耗会随 batch 线性放大。

5.3 精度对拍与验收标准

性能数字漂亮不代表能直接上线。我会把同一批测试图分别过 PyTorch 模型和 TRT 引擎，比较输出张量的最大绝对误差和余弦相似度。FP32 下两者差距通常在 1e-3 量级，属于正常浮点差异；FP16 下可能出现个别通道误差到 1e-2，甚至检测框坐标轻微偏移。

验收标准不要只看张量误差，还要看下游任务指标，比如检测的 mAP 或实际业务指标是否满足预期。我见过 FP16 张量误差看起来挺大，但 mAP 只掉了 0.5 个点的案例，这种情况下上线是完全能接受的。

6. 踩坑实录与调优：profile、精度和多路并发

6.1 动态形状 profile 引发的启动错误

用动态 shape 后最常见的是运行时抛 "Binding shape out of optimization profile" 类似错误。原因是 context 里设置的输入 shape 超出了构建引擎时定义的 min、opt、max 区间。

解决办法有三个方向。一是尽量扩大 profile 区间，但别为了覆盖所有情况把 max 设得过大，否则 kernel autotuning 的显存预算会超。二是用多个 profile 覆盖典型场景，运行时在 profile 间切换，适合输入尺寸跨度很大的场景。三是如果上线 shape 固定，直接用静态 shape 构建引擎，性能通常比动态好一点，省了运行时 shape 推断的开销。

6.2 FP16 精度不够时的兜底手段

开 FP16 后发现检测框抖动、分割掩码边界变差，先别急着关掉全局 FP16。可以对特定层单独指定精度：

for layer in network: if layer.name in ["conv3_1", "sigmoid_2"]: layer.precision = trt.float32 config.set_flag(trt.BuilderFlag.PREFER_PRECISION_CONSTRAINTS)

但要注意，TensorRT 只有在满足层间约束的情况下才会保持 FP32，设置前最好确认这些层没有被张量融合吞掉。另一个兜底方案是回退到 FP32 引擎，只保留层融合优化，延迟会涨 20% 左右，但精度和原模型几乎完全一致。这是我实际项目中用的最多的妥协方案。

另外提一句 INT8：如果模型动态范围小、量化校准数据足够，INT8 能比 FP16 再快 30% 到 50%。但校准集的选择直接决定精度 loss，我通常用几百张覆盖各种光照和遮挡情况的实际业务图做校准，并且上线前持续观察指标。这是一个单独的主题，这次不展开。

6.3 多路并发时的显存与流管理

生产环境经常是多路视频流同时推理，显存峰值和多路并发会互相打架。TensorRT 的显存占用主要来自输入输出 binding 和构建时的 workspace 峰值。最常见的显存浪费是给每个线程各建了一个 engine，正确做法是所有线程共用同一个 engine，各自持有 execution context。

多路并发开启 CUDA stream 并行后，不同 stream 的 kernel 可以重叠执行，GPU 利用率才能真正上去。我观察到的经验是：batch=1 多路并发场景下，先把各路输入预处理合并到 host 端，再用一个 stream 统一提交，比每个线程各起一个 stream 再互相等待要稳定。最后提一个很多人忽略的点：上线前把"首个推理"从统计样本里剔除，单独记录 engine 反序列化耗时。很多莫名其妙的超时统计，其实都是把初始化开销算进了常规延迟。

这套从 ONNX Runtime 到 TensorRT 原生引擎的迁移，本质是把推理控制权从通用框架手里拿回来，交给更懂 GPU 的编译器。过程里你会被迫搞懂算子的融合方式、显存的生命周期、stream 的调度关系，这些理解反过来也会让你用 ONNX Runtime 时更清楚瓶颈在哪。如果你正卡在类似的延迟问题上，建议别急着全量迁移，先按上面的步骤做一次 trtexec 预评估，再决定投入多少成本。