模型推理延迟卡在 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 这些底层库上执行。单个算子的性能并不差但 convbnrelu 这种高频组合在 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 fileCUDA 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_locationcpu)[model].float() model.eval() dummy torch.zeros(1, 3, 640, 640) torch.onnx.export( model, dummy, yolov5s.onnx, opset_version17, do_constant_foldingTrue, input_names[images], output_names[output], dynamic_axes{ images: {0: batch, 2: height, 3: width}, output: {0: batch}, }, )opset 建议 16 到 17TensorRT 对相对新的 opset 支持更完整。动态轴里 batch 一般都要放开宽高如果部署输入固定可以只留 batch 动态来降低转换复杂度。导出完成后用 onnx-simplifier 清理一次图中的冗余节点比如 Identity、重复 Cast 这些再用 onnxruntime 跑一遍确认输出和原模型对得上。这一步不能省很多 TensorRT 转换报错追根溯源都是 onnx 图里混进了脏节点。3.2 先用 trtexec 验证转换可行性拿到干净的 onnx 后我会先用 trtexec 做快速验证。它能直接输出 engine 构建信息、kernel 耗时和各阶段延迟省去先写 Python builder 的麻烦。trtexec --onnxyolov5s.onnx \ --saveEngineyolov5s.trt \ --fp16 \ --minShapesimages:1x3x640x640 \ --optShapesimages:4x3x640x640 \ --maxShapesimages:8x3x640x640注意动态形状必须把三个 profile 一起给min 是最小 shapeopt 是优化目标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_handlestream.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后端精度Batch1 延迟相对 CPU 基线ONNX Runtime CPUFP3228.6 ms基线ONNX Runtime CUDA EPFP324.31 ms约 6.6xORT TensorRT EPFP323.52 ms约 8.1xTensorRT 原生FP322.87 ms约 10.0xTensorRT 原生FP161.64 ms约 17.4xBatch8 的吞吐差距更能说明问题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 利用率才能真正上去。我观察到的经验是batch1 多路并发场景下先把各路输入预处理合并到 host 端再用一个 stream 统一提交比每个线程各起一个 stream 再互相等待要稳定。最后提一个很多人忽略的点上线前把首个推理从统计样本里剔除单独记录 engine 反序列化耗时。很多莫名其妙的超时统计其实都是把初始化开销算进了常规延迟。这套从 ONNX Runtime 到 TensorRT 原生引擎的迁移本质是把推理控制权从通用框架手里拿回来交给更懂 GPU 的编译器。过程里你会被迫搞懂算子的融合方式、显存的生命周期、stream 的调度关系这些理解反过来也会让你用 ONNX Runtime 时更清楚瓶颈在哪。如果你正卡在类似的延迟问题上建议别急着全量迁移先按上面的步骤做一次 trtexec 预评估再决定投入多少成本。