简介面向深度学习开发和算法研究人员的TensorRTYOLO部署工具包集成目标检测与实例分割两大功能覆盖C和Python两套工程实现可在Linux与Windows平台运行适用于监控安防、工业质检、智能交通等场景。压缩包约314MB共收录1523个文件既有412个hpp头文件、144个h头文件完善接口定义也有52个py脚本和42个cpp源文件供二次开发还附带cmake构建配置、cu/cuh内核文件、样例数据与说明文档目录结构清晰便于检索。目前已有307人浏览学习适合需要快速上手TensorRT部署YOLO项目的中高级开发者参考。无论是开发者集成功能到项目还是研究人员进行算法测试验证都能从中获得可直接落地的工程参考。包内内容覆盖从环境配置、模型转换到推理演示的完整链路用户可阅读文档、运行Python脚本或编译C程序直接验证目标检测与实例分割效果有效减少在平台适配和部署细节上的踩坑时间。1. 同样是 YOLO 推理TensorRT 部署后帧率翻倍是怎么做到的辛辛苦苦调好的 YOLO 实例分割模型在 PyTorch 里单张推理 40ms看着能接受一上服务端并发就卡死换到 TensorRT 之后同一张显卡、同一个模型检测和分割一起跑能压进 10ms 以内GPU 利用率也终于从 30% 提到 70% 以上。反直觉的地方在于提速的大头往往不在模型前向本身而在数据搬运、后处理调度和推理引擎的显存复用。这套方案要做的事情很具体——把 YOLO 的检测头和实例分割头一起转成 TensorRT 引擎用 Python 快速验证用 C 做生产落地并且保证在 Linux 和 Windows 上都能跑。适合算法工程师、部署工程师和想在 Jetson 上做实时检测的开发者也适合刚入门 TensorRT 但被版本兼容性和一堆 API 绕晕的人。2. 部署前的关键决策TensorRT 为什么快版本和显卡怎么选2.1 TensorRT 为什么快层融合、精度校准与显存复用TensorRT 本质上不是一个推理框架而是 NVIDIA 针对自家 GPU 做的编译器加运行时。它最狠的优化是层融合。一个标准的 YOLO 卷积块包含 Conv、BatchNorm、激活函数在 PyTorch 里是三个算子在 TensorRT 的 engine 里会被融合成一个算子。C2f 结构里的 concat 节点也会被直接消除数据不用从显存里读出来再写回去。这一层优化省掉的是 kernel launch 次数和显存带宽对于 640x640 输入的模型来说效果非常明显。第二个重要机制是精度校准。TensorRT 可以把 FP32 的权重和激活值转成 FP16 甚至 INT8。FP16 在 RTX 显卡上有专用硬件单元吞吐直接翻倍INT8 则需要一个校准数据集来统计每层激活值的动态范围。但精度校准不是免费的FP16 对大多数 YOLO 模型几乎无损INT8 对实例分割的掩码头却常常掉点这个坑后面会细说。第三个机制是内核自动调优。同一个算子TensorRT 会生成多种 CUDA kernel然后在目标显卡上实际跑一遍选最快的那个这个过程叫 tactic 选择。所以同一个 ONNX 文件在 RTX 3090 和 Jetson Orin 上生成的 engine 是不同的换机器必须重新构建。显存复用也值得一提。TensorRT 会做显存池化把中间张量的峰值显存复用而不是每层都去 cudaMalloc。这也是为什么同一个模型TensorRT 的显存占用往往比 PyTorch 低 30% 以上。理解这几个机制之后你就能解释后来遇到的绝大多数问题为什么 engine 文件不能跨机器拷贝为什么 FP16 在某些层上精度崩了为什么显存峰值比 PyTorch 低那么多。TensorRT 对你来说仍然是个黑匣子但你能猜到它在里面干了什么。2.2 版本与硬件选型TensorRT 10.x 和 GTX 1070 不兼容很多人下载 TensorRT 时习惯直接拿最新版这是部署环节最常见的翻车点。TensorRT 的版本和 CUDA 版本、GPU 架构是强绑定的。TensorRT 10.x 发布时官方把最低支持的 GPU 计算能力提到了 Volta 架构也就是 sm_70 及以上。这意味着 GTX 1070 这类 Pascal 架构的卡算力只有 6.1直接被移出了支持列表。我见过一个项目开发机上装的 TensorRT 10.x现场一套工控机是 GTX 1070engine 构建时报Unsupported compute capability: 6.1最后只能把整套环境降级到 TensorRT 8.6 CUDA 11.8才在旧卡上跑起来。选型的核心原则是先查你手上显卡的算力再查 TensorRT 对应版本的 Release Notes最后才决定装哪个版本。RTX 20 系以后基本都是 Volta 以上架构问题不大Jetson 系列则跟着 JetPack 走它内置的 TensorRT 版本和桌面版不是一个发布节奏。环境搭建这块我习惯用 conda 隔离避免和训练环境互相污染。TensorRT 在 PyPI 上有官方轮子安装很简单conda create -n yolo_trt python3.10 -y conda activate yolo_trt pip install tensorrt-cu12 onnx onnxruntime onnxsim opencv-python python -c import tensorrt as trt; print(trt.__version__)这里的tensorrt-cu12是给 CUDA 12.x 用户准备的轮子包如果你的机器是 CUDA 11.8需要找对应的旧版本轮子。安装完成后必须验证一下trt.__version__因为 PyPI 包的版本和 NVIDIA 官网下载的 deb/zip 包版本经常不一致后续排查问题时要认准这个打印出来的版本号。2.3 Linux 与 Windows 环境核对清单双平台部署时环境差异比代码差异更折磨人。Linux 下 TensorRT 一般通过 deb 包或 tar 包安装trtexec 在/usr/src/tensorrt/bin或者解压目录的bin下Windows 下是 zip 包解压后需要把TensorRT-10.x/bin和TensorRT-10.x/lib加进系统 PATH。这一点漏了后面运行 trtexec 或者 C 程序时会出现 dll 找不到的报错。组件Linux 常见方式Windows 常见方式CUDA Toolkitapt 或 runfileexe 安装包cuDNN拷贝 .so 到 /usr/local/cuda/lib64拷贝 .dll 到 CUDA/binTensorRTdeb 包或 tar 包zip 解压trtexec/usr/src/tensorrt/bin/trtexec%TRT_ROOT%/bin/trtexec.exeC 编译Makefile / CMake gccVisual Studio 2019/2022 CMake环境核对时Linux 下我一般用这几条命令做体检nvidia-smi | grep CUDA Version python3 -c import tensorrt as trt; print(trt.__version__) which trtexec dpkg -l | grep -i tensorrt # 如果是 deb 安装Windows 下对应的检查方式是在 PowerShell 里跑Get-Command trtexec确认 PATH 生效。还有一个容易被忽略的点如果你用 VSCode 做开发Python 解释器一定要选到 conda 的 yolo_trt 环境里否则会出现命令行 import tensorrt 正常、VSCode 里运行却报 ModuleNotFoundError 的诡异问题我已经因为这个浪费过两次时间。3. 把 YOLO 的 ONNX 转成 TensorRT 引擎实例分割双输出头的转换与三个必调参数3.1 从 PyTorch 导出带两条输出的 ONNX检测头与掩码头分离做 TensorRT 部署的第一步是把训练好的 PyTorch 模型导成 ONNX。以 YOLOv8-seg 为例导出后的 ONNX 和纯检测模型有一个本质区别它有两个输出头这是实例分割和语义分割在工程实现上的分水岭。语义分割输出的是逐像素的类别概率图一个头就够了实例分割要区分这是哪个实例所以它输出检测框、类别、掩码系数再配一个共享的掩码原型推理时两者做矩阵乘法还原出每个实例的掩码。以输入 640x640、COCO 80 类为例输出结构如下输出名形状含义output0[1, 116, 8400]4 个坐标 80 个类别分数 32 个掩码系数output1[1, 32, 160, 160]掩码原型 proto8400 是三个尺度特征图的候选框总数116 这个数字拆开就是 4 80 32。纯检测模型是 4 80 84少了一个掩码系数的维度。导出代码用 ultralytics 官方 API 就行from ultralytics import YOLO model YOLO(yolov8s-seg.pt) model.export( formatonnx, opset12, dynamicTrue, simplifyTrue, )这里三个参数都有讲究。dynamicTrue让 ONNX 的输入是动态形状后续构建 TensorRT engine 时可以设置 min/opt/max 三档形状opset12是因为 TensorRT 对低版本 opset 的算子兼容性更好但也不能低于 11否则某些算子导出不了simplifyTrue会调用 onnxsim 对计算图做一轮简化去掉很多冗余的 shape 节点和恒等 op后面转 TensorRT 的成功率高很多。导出之后我建议先用 onnxruntime 快速验证一遍确认输出名和形状没有意外import onnxruntime as ort sess ort.InferenceSession(yolov8s-seg.onnx, providers[CUDAExecutionProvider]) for inp in sess.get_inputs(): print(input:, inp.name, inp.shape, inp.type) for out in sess.get_outputs(): print(output:, out.name, out.shape, out.type)这一步非常便宜但能提前暴露 90% 的问题。比如有的环境导出的 ONNX 输出名会带/前缀或者多出 Gather 节点这些在 TensorRT 里都会变成难查的坑。ORT 能正常跑通再进 TensorRT这是一条稳妥的流水线。3.2 用 Python API 构建 TensorRT 引擎动态形状配置与显存池构建引擎是这套流程的核心步骤。TensorRT 提供了 Python API可以不依赖 trtexec 命令行在代码里完成整个构建过程。我通常把构建逻辑封装成一个函数import tensorrt as trt def build_engine(onnx_path, engine_path, fp16True): logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) # 必须开启 EXPLICIT_BATCH动态形状依赖它 network builder.create_network( 1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH) ) parser trt.OnnxParser(network, logger) with open(onnx_path, rb) as f: assert parser.parse(f.read()), ONNX 解析失败请检查日志 # 输入名要和 ONNX 里的一致一般是 images profile builder.create_optimization_profile() profile.set_shape(images, (1, 3, 640, 640), (4, 3, 640, 640), (8, 3, 640, 640)) config builder.create_builder_config() config.add_optimization_profile(profile) # 显存池上限1GB 是 640 输入的常规起点 config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) if fp16 and builder.platform_has_fast_fp16: config.set_flag(trt.BuilderFlag.FP16) # 序列化引擎直接写文件 engine_bytes builder.build_serialized_network(network, config) if engine_bytes is None: raise RuntimeError(engine 构建失败) with open(engine_path, wb) as f: f.write(engine_bytes) print(fengine saved to {engine_path})逻辑上分四步创建 network 和 OnnxParser 解析模型创建优化 profile 定义动态输入的 min/opt/max 三档形状设置构建配置项最后序列化引擎。这里的 profile 三档形状含义不同min 决定最小显存占用max 决定显卡要预留的显存上限opt 是实际推理时最常见的形状TensorRT 重点为 opt 形状调优 kernel。比如生产上主要跑 batch4就把 opt 设为 4min 设为 1 兼容调试max 设为 8 留余量。set_memory_pool_limit控制的是构建时工作空间的显存上限不是运行时显存。640x640 输入的实例分割模型1GB 是够用的显存紧张的卡可以调到 512MB代价是 kernel 的选择范围变小个别层可能变慢。platform_has_fast_fp16这个检查很重要如果显卡不支持快速 FP16硬开会报错。构建过程中真正容易卡住的是 ONNX 算子兼容性。如果 parser 报某个算子不支持常见做法是回到导出这一步换 opset或者用 onnx-graphsurgeon 把不支持的节点替换掉。对于常规 YOLOv8/v11 系列opset12 加 simplify 基本不会走到改图这一步。3.3 用 trtexec 做引擎体检延迟和显存一次看清engine 构建完成后我习惯先用 trtexec 做一次标准化体检特别是不确定新显卡或者新版本 TensorRT 的性能时。trtexec 是 TensorRT 自带的命令行工具既能把 ONNX 转成 engine也能加载已有 engine 做基准测试trtexec \ --onnxyolov8s-seg.onnx \ --saveEngineyolov8s-seg.engine \ --fp16 \ --minShapesimages:1x3x640x640 \ --optShapesimages:4x3x640x640 \ --maxShapesimages:8x3x640x640 \ --memPoolSizeworkspace:1024注意--memPoolSize是新版参数TensorRT 8.x 老版本用的还是--workspace。跑完之后trtexec 会输出一张性能表格里面包含 Mean latency、P90 latency、显存峰值等指标。这里有个容易误读的点这个延迟是纯引擎时间不包含预处理 letterbox 和后处理 NMS所以它只能作为模型前向性能的参考不能当端到端延迟来汇报。如果 engine 在推理时报输入形状不匹配可以在 trtexec 命令里手动指定测试形状trtexec \ --loadEngineyolov8s-seg.engine \ --shapesimages:1x3x640x640加--verbose会打印 engine 的输入输出张量名和形状排查 binding 错误时很好用。trtexec 还有一个被低估的参数--noDataTransfers它会跳过 CPU 到 GPU 的数据拷贝单独测计算单元耗时用来判断数据搬运在整条链路里的占比非常直观。4. Python 与 C 双语言推理从加载引擎到实例分割后处理4.1 Python 推理实现加载引擎、letterbox 预处理与掩码还原Python 推理的优点是开发快、逻辑直观适合做原型验证和低并发场景。核心流程是加载 engine、创建 context、分配显存 buffer、执行推理、后处理。实例分割的后处理比纯检测多两步掩码系数和 proto 做矩阵乘法再把掩码放大回原图尺寸。import numpy as np import tensorrt as trt class YoloSegTRT: def __init__(self, engine_path, conf_thr0.25, iou_thr0.45): logger trt.Logger(trt.Logger.WARNING) runtime trt.Runtime(logger) with open(engine_path, rb) as f: self.engine runtime.deserialize_cuda_engine(f.read()) self.ctx self.engine.create_execution_context() self.conf_thr conf_thr self.iou_thr iou_thr def letterbox(self, img, size640): h, w img.shape[:2] ratio min(size / h, size / w) new_h, new_w int(h * ratio), int(w * ratio) resized cv2.resize(img, (new_w, new_h)) canvas np.full((size, size, 3), 114, dtypenp.uint8) pad_w, pad_h (size - new_w) // 2, (size - new_h) // 2 canvas[pad_h:pad_h new_h, pad_w:pad_w new_w] resized blob canvas.transpose(2, 0, 1)[None].astype(np.float32) / 255.0 return blob, ratio, pad_w, pad_h def infer(self, blob): # 动态输入要先 set_input_shape四维 shape 要和 profile 匹配 self.ctx.set_input_shape(images, blob.shape) # 分配和搬运 buffer 的细节省略核心是 execute_async_v2 self.ctx.execute_async_v2(bindingsself.bindings, stream_handleself.stream.handle) return self.outputs上面的代码省略了 buffer 分配细节但有一个关键点必须写出来动态 shape 的 engine推理前每一帧都要调用set_input_shape而且传入的实际形状必须落在构建时 profile 的 min 和 max 之间否则会直接报 binding shape invalid 的错误。后处理这块检测分支先做置信度过滤和 NMS分割分支再做掩码还原def postprocess(self, output0, output1, ratio, pad_w, pad_h, orig_shape): # output0: [1, 116, 8400]前 4 位是 xywh中间 80 位是类别分最后 32 位是掩码系数 pred output0[0].T # [8400, 116] boxes_xywh pred[:, :4] scores pred[:, 4:84] mask_coeffs pred[:, 84:] keep scores.max(axis1) self.conf_thr boxes, masks, labels [], [], [] for idx in np.where(keep)[0]: cls_id scores[idx].argmax() conf scores[idx, cls_id].item() box boxes_xywh[idx] coeff mask_coeffs[idx] # 32 维 # 掩码 sigmoid(coeff proto)再 resize 到原图 mask 1.0 / (1.0 np.exp(-(coeff self.proto.T))) # [160, 160] mask cv2.resize(mask, (orig_w, orig_h)) mask[mask 0.5] 1 masks.append(mask)v8 系列和 v5 系列在后处理上有个经典差异v5 的输出是 4 个坐标 1 个 objectness 80 个类别一共 85 维解析时要跳过 objectness 那一列v8 删掉了 objectness直接是 4 80初转过来的同学最容易在这里翻车检测框大面积偏移但又不报错。关于置信度门限COCO 默认的 0.25 是一个偏低的起点适合论文指标复现实际业务里误检多就往上调到 0.4 到 0.5漏检多就往下调。这个参数性价比极高往往比重新训练模型更立竿见影。4.2 C 推理实现Tensor Address 绑定与跨平台编译C 推理是生产环境的主选尤其是多线程高并发场景。相比 PythonC 对显存生命周期的控制更精确没有 GIL 锁启动延迟也更低。TensorRT 从 8.5 开始推荐用setTensorAddress加enqueueV3这套新 API取代了老的executeV2绑定数组的方式。#include NvInfer.h #include cuda_runtime_api.h #include fstream #include vector using namespace nvinfer1; // 读取 engine 文件注意 Windows 下必须用二进制模式 std::vectorchar loadEngineFile(const std::string path) { std::ifstream file(path, std::ios::binary); file.seekg(0, std::ios::end); size_t size file.tellg(); file.seekg(0, std::ios::beg); std::vectorchar data(size); file.read(data.data(), size); return data; } void runInference(ICudaEngine* engine, float* input) { auto ctx engine-createExecutionContext(); auto stream cudaStream_t(nullptr); cudaStreamCreate(stream); // 遍历所有 IO tensor分配显存并绑定地址 std::vectorvoid* bindings(engine-getNbIOTensors()); for (int i 0; i engine-getNbIOTensors(); i) { const char* name engine-getIOTensorName(i); auto dims ctx-getTensorShape(name); size_t vol 1; for (int d 0; d dims.nbDims; d) vol * dims.d[d]; cudaMalloc(bindings[i], vol * sizeof(float)); } // 新 API按名字绑定输入输出 ctx-setTensorAddress(images, bindings[0]); ctx-setTensorAddress(output0, bindings[1]); ctx-setTensorAddress(output1, bindings[2]); ctx-enqueueV3(stream); cudaStreamSynchronize(stream); // 后处理读取 output0 和 output1 到 CPU或者直接在 GPU 上用自定义 kernel }getNbIOTensors和getIOTensorName是动态推理的标准接口不要写死 binding 索引因为不同 ONNX 导出方式的输出排列可能不同。enqueueV3是异步的后面必须跟cudaStreamSynchronize或者在流里加回调否则数据还没算完就去读结果是未定义行为。C 的编译在 Linux 和 Windows 上有差异。Linux 下直接 g 链接 nvinfer 库g main.cpp -o yolo_demo \ -I$TRT_ROOT/include -L$TRT_ROOT/lib \ -lnvinfer -lcudart \ -Wl,-rpath,$TRT_ROOT/libWindows 下建议用 CMake避免手动配置 Visual Studio 的属性页set(TRT_ROOT C:/TensorRT-10.x) find_library(NVINFER nvinfer HINTS ${TRT_ROOT}/lib) find_library(CUDART cudart HINTS ${CUDA_ROOT}/lib/x64) target_link_libraries(yolo_demo PRIVATE ${NVINFER} ${CUDART})Windows 上还有一个隐蔽的坑如果 dll 不在 exe 同目录或系统 PATH 里运行时会报找不到 nvinfer.dll但这在编译阶段完全不报错。解决方法是把 TensorRT 的 lib 目录和 CUDA 的 bin 目录都加进系统的 PATH 环境变量并且记得重新打开终端。4.3 Python 和 C 的分工边界不是二选一很多团队纠结到底用 Python 还是 C我的判断标准其实很简单看吞吐要求和集成环境。Python 版本适合快速验证、批量测试、内部工具C 适合对外交付、高并发服务、嵌入式设备。关键认知是TensorRT 的 Python API 本身性能损耗很小真正的差距在于后处理特别是 NMS 和掩码还原这部分如果用纯 Python 循环写大 batch 下会拖掉一半的帧率。对比维度Python 方式C 方式开发效率高适合原型和调试低适合稳定交付后处理性能numpy 向量化后可接受可以上 CUDA kernel多线程受 GIL 限制完全可控部署体积需要 Python 环境单二进制文件实际项目里我见过最稳的架构是 C 做核心推理服务暴露一个简单的 C 接口然后用 pybind11 封装回 Python 给算法团队调用。这样算法同学可以继续用 Python 调试线上服务又是 C 的稳定性和性能。如果你看到网上有 FastSAM 的 C TensorRT 实现思路也是这套只是 FastSAM 的模型更重后处理更复杂实时性远不如 YOLO-seg。5. 部署避坑实录从引擎加载失败到分割掩码错位的 5 个排错记录5.1 TensorRT 10.x 跑在 GTX 1070 上直接报 Unsupported compute capability现象用 TensorRT 10.x 构建 engine或者加载现成 engine报[E] 3: Unsupported compute capability: 6.1构建直接中断。原因GTX 1070 是 Pascal 架构计算能力 6.1TensorRT 10.x 官方最低要求是 Volta 架构sm_70。旧卡不在支持列表里engine 构建不了。解决两个方向要么把 TensorRT 降到 8.6 并搭配 CUDA 11.8要么换 RTX 20 系以上的显卡。生产环境选型时先把显卡算力查清楚再定 TensorRT 版本省得整套环境搭完才发现根本不兼容。5.2 动态 batch 推理报 Binding shape invalid现象engine 构建成功Python 或 C 推理时抛异常日志显示Binding idx1 is incompatible with input shape。原因构建时设置了动态 profilemin1, opt4, max8但推理时没有调用set_input_shape或者传入的 batch 大于 8。TensorRT 要求推理的实际形状必须落在 profile 定义的范围内。解决推理前显式设置形状哪怕输入固定是 1 也要设置self.ctx.set_input_shape(images, (1, 3, 640, 640))C 里对应的是context-setInputShape(images, dims)。凡是动态 shape 的 engine 都必须走这个流程没有例外。5.3 实例分割掩码错位letterbox 的 pad 没有还原现象检测框位置完全正确但分割掩码整体偏移到右下角或者掩码形状和物体轮廓对不上像是被拉扯过。原因模型的输入是 letterbox 之后的 640x640 图掩码 proto 也是在 640x640 的空间里生成的。后处理时如果直接把 mask resize 回原图尺寸没有扣除 letterbox 时加上的 padding掩码就会整体偏移。比例变换和 padding 偏移量没有同步映射也会导致掩码拉伸。解决在 letterbox 预处理时把ratio和(pad_w, pad_h)保存下来掩码还原时按这个偏移量裁剪mask cv2.resize(mask, (new_w, new_h)) # 先缩放到 letterbox 后的实际图像区域 # 再把 mask 放到原图坐标系里偏移量是 pad常见错误是把 resize 的目标尺寸直接写成原图的宽高而正确的顺序是先裁剪到有效区域再映射回原图坐标。5.4 Windows 下读取 engine 文件失败deserialize 返回空现象在 Linux 上生成的 engine 通过 U 盘拷贝到 Windows 机器C 加载时deserialize_cuda_engine返回空指针或者 Python 里读出 0 字节。用文本编辑器打开 engine 文件里面是乱码。原因两层原因叠加。第一engine 文件本身跨平台不通用Linux 生成的 engine 到 Windows 上大概率跑不了第二Windows 下用std::ifstream读文件时没有指定std::ios::binary在某些环境下会以文本模式截断数据。解决engine 文件必须在目标平台上重新构建不能拷贝。读取时显式用二进制模式std::ifstream file(path, std::ios::binary);Windows 的路径里尽量不要带中文和空格CUDA 的字符处理在这类问题上偶尔会翻车这是我在现场换来的血泪经验。5.5 v8-seg 的输出解析用 v5 的 85 维公式检测框全部偏移现象检测框能画出来但位置明显不对有的框跑到物体旁边的背景上置信度还特别高看起来像是坐标解析错位。原因把 v8-seg 的输出当成 v5 的 85 维结构来解析。v5 的输出是 4 坐标 1 个 objectness 80 个类别v8 系列取消了 objectness输出是 4 坐标 80 类别 32 掩码系数。解析代码如果按 4 1 80 去跳列后面的掩码系数会错位坐标本身虽然没错但类别分数取错列导致置信度计算全乱。解决先打印 ONNX 输出的最后一维大小84 是纯检测116 是带着 32 个掩码系数的实例分割。判断清楚再写解析逻辑。这里再次强调实例分割和语义分割的区别实例分割的这 32 个系数不是像素级类别概率而是用来和共享的 proto 矩阵做乘法、还原出每个实例独有掩码的权重这也是它比语义分割多一个输出头的原因。6. 从跑通到跑满性能基准测试与多流、INT8 等进阶调优6.1 基准怎么跑才有参考价值分离引擎时间和完整链路时间性能验证最忌讳只报 trtexec 的数字。trtexec 测的是纯引擎计算时间而业务方关心的帧率是图像采集 预处理 推理 后处理的完整链路。我的做法是两套基准分开跑第一套用 trtexec 记录引擎的 Mean latency 和 P90用来对比不同精度配置下的性能上限第二套在业务代码里统计完整链路至少跑 100 帧取平均值而且前面要有 10 到 20 帧的 warmupfor _ in range(10): infer(blob) # 热身后再计时 t0 time.perf_counter() for _ in range(100): infer(blob) dt (time.perf_counter() - t0) / 100 print(favg latency: {dt * 1000:.2f} ms)如果 trtexec 显示 5ms端到端测出来却是 15ms那瓶颈一定在预处理或后处理。常见情况是 Python 的 NMS 循环太慢或者 letterbox 里的cv2.resize每帧重复申请内存。把后处理的矩阵运算从 Python 循环改成 numpy 向量化或者直接搬到 GPU 上用 CUDA kernel 实现通常能把端到端时间打回 8ms 以内。6.2 进阶调优方向多流推理、INT8 校准与 Jetson DLA跑通之后想进一步压榨性能第一个方向是多流推理。TensorRT 的 context 不是线程安全的常见做法是每个线程创建独立的 context 和 CUDA stream共用同一个 engine。吞吐量在 4 到 8 个流的时候提升最明显但要注意 CPU 端的预处理线程别成为瓶颈。第二个方向是 INT8 量化。检测分支在 INT8 下掉点通常不严重但实例分割的掩码分支对量化非常敏感掩码边缘会出现明显的锯齿和空洞。如果要做 INT8校准数据集至少要选 500 张和业务场景接近的图生成的 calibration cache 要在发布包里一起保留换机器重新校准是灾难。第三个方向是 Jetson 平台的 DLA 部署只对 NVIDIA 嵌入式平台有效。DLA 是专用深度学习加速器功耗比优于 GPU但不是所有算子都支持需要逐层跑兼容性检测。这个属于移植工程模型结构越简单越省事YOLO 这类检测模型在 DLA 上的支持度还可以但是带 mask proto 的分支经常需要回退到 GPU 上执行收益打折扣。每次交付的时候我都会把 TensorRT 版本、CUDA 版本、显卡型号、引擎构建参数写进发布记录里因为 engine 文件换台机器就失效没有这份记录三个月后排查现场问题就是大海捞针。这个习惯已经救过我两次希望帮到你。本文还有配套的精品资源点击获取
