TensorRT部署YOLOv5+DeepSORT：从模型转换到工程避坑实践

简介一套面向嵌入式与服务器场景的目标检测跟踪部署方案基于 YOLOv5 与 DeepSORT 实现行人检测和多目标跟踪借助 TensorRTX 将模型转为 engine适配 NVIDIA Jetson Xavier NX 及 X86 架构适合算法部署工程师、嵌入式 AI 开发者参考也适合需要将检测跟踪模型从训练环境迁移到生产设备的团队。压缩包共 35 个文件以 26 个 Python 脚本为主体覆盖检测器、跟踪器、TensorRT 封装与推理入口另含 engine 序列化模型、自定义插件 so 库、配置文件、依赖清单、测试视频等整体约 42.95MB目录按权重、跟踪配置、工具模块等划分便于对照阅读。目前已有 399 人学习浏览。运行示例推理脚本即可基于现有引擎和测试视频直接启动推理快速复现检测跟踪效果通过梳理引擎转换、插件编译和参数配置还能掌握在 Jetson 上加速部署 YOLOv5DeepSORT 的关键步骤是一份实用且可二次开发的完整实践资料。1. 从“能跑”到“能上线”TensorRT部署YOLOv5DeepSORT要解决什么如果你只是想在本地跑通一个行人检测跟踪demo用PyTorch加载YOLOv5、再调DeepSORT足够。但一旦面对四路摄像头、1080p视频流、或者一台只有旧显卡的工控机帧率会瞬间被打回原形。我见过太多项目在模型精度上卷了半天最后卡在部署环节检测框有了跟踪ID却乱跳GPU利用率上不去延迟动不动就超过100ms。TensorRT部署YOLOv5 DeepSORT这个组合本质上是把检测网络从PyTorch的动态图变成TensorRT的静态优化引擎再把DeepSORT的匹配逻辑接在推理输出上。这样做的直接收益是在GTX 1070这种级别显卡上YOLOv5s的TensorRT版本相比原生PyTorch可以稳定带来2到4倍加速单路延迟从30ms级压到10ms级。适合谁适合那些已经有训练好的YOLOv5检测权重却困于帧率不达标、显存资源紧需要把行人检测跟踪真正塞进业务系统的开发者。2. 部署前先把模型弄明白YOLOv5的检测头与DeepSORT的关联逻辑2.1 YOLOv5输出什么从pt到TensorRT的中间表示YOLOv5的检测输出不是一个框列表而是三个尺度的特征图组合。以YOLOv5s为例输入640x640输出三个特征图shape分别是[batch, 3, 80, 80]、[batch, 3, 40, 40]、[batch, 3, 20, 20]通道数3代表每个格子有3个anchor每个anchor预测85个值x、y、w、h、objectness、80个类别概率。TensorRT部署的核心就是把PyTorch模型导出成ONNX再让TensorRT解析ONNX并生成engine。这个engine里存的是网络结构和每个算子的最优执行计划不是简单的权重拷贝。实际转换时我最常用的是先转ONNX再转engine这条路径。YOLOv5官方代码仓提供了export.py可以直接输出ONNX。但要注意默认导出的ONNX包含大段的解码和NMS后处理节点吗不一定。取决于版本和参数。新版本YOLOv5默认导出端到端模型内部带NMS老版本或关闭端到端时导出的是原始raw output。对TensorRT来说我一般建议导出不带NMS的版本因为TensorRT的NMS插件在旧版本上兼容性比较差而且后处理放在推理引擎外方便调试。也就是说TensorRT输出的是三个特征图我们仍然需要在自己的代码里做anchor解码、置信度过滤和NMS。TensorRT处理YOLOv5的方式有两种常见做法一是直接把原模型的三输出转成三个engine输出然后在host端做decode和NMS二是用TensorRT的EfficientNMS插件或yolov5官方自定义的NMS plugin把后处理封装进engine。第一种方式灵活便于更换NMS策略第二种方式延迟更低但插件依赖多版本升级时坑很多。我一般倾向第一种尤其是刚入门TensorRT时先把手动后处理跑通再考虑插件优化。2.2 DeepSORT如何吃检测框级联匹配与IOU匹配参数DeepSORT不是另一个检测模型它是一个多目标跟踪框架。它接收两种输入检测框由YOLOv5给出和表观特征由ReID网络给出也可以只用框的位置和尺寸。DeepSORT内部维护着若干轨迹每一帧做两轮匹配第一轮是级联匹配基于马氏距离和余弦距离的加权优先处理那些最近被更新过的轨迹第二轮是IOU匹配针对没有匹配上的轨迹和检测框用IOU做最后的关联。整个过程YOLOv5的检测质量直接决定跟踪效果的上限。在TensorRT部署背景下DeepSORT有一个容易被忽略的点它的预测是卡尔曼滤波假设运动是线性匀速的且状态向量是[x, y, a, h, vx, vy, va, vh]这里的a是宽高比h是高度。YOLOv5输出的框是像素坐标DeepSORT内部用的是归一化后的框吗不DeepSORT原始实现里输入框是像素坐标但max_dist通常设为0.2之类的小值。如果你不仔细看代码直接把YOLOv5的框喂进去有时会因为坐标尺度问题导致匹配失效。正确做法是保持训练时的框定义但确认deep_sort的metric计算方式。多数开源DeepSORT代码里级联匹配用余弦距离需要喂ReID特征如果你并没有训练ReID模型可以退而求其次只用IOU匹配也就是把DeepSORT退化成纯基于运动模型的跟踪。但那样的话行人短暂遮挡后ID切换会更频繁。另一个关键参数是nms_max_overlap。DeepSORT内部会对检测框做一次NMS默认值1.0表示不启用额外的NMS。但YOLOv5已经做过NMS了如果DeepSORT里再设一个较小的值比如0.5就会把本来就重叠的检测框再删掉导致漏检。这个参数和YOLOv5的NMS阈值要协同设计后面会细说。2.3 TensorRT提速的本质层融合、FP16与INT8选型TensorRT为什么能让YOLOv5变快核心是它对计算图做了重写。卷积层和BatchNorm可以在构建engine时融合成一个算子ReLU、Clip等激活函数与卷积融合concat和split被消除多个小算子合并成kernel。这些优化对GPU的访存开销影响非常大。YOLOv5的结构里大量使用C3模块包含bottleneck、concat和激活转换成TensorRT后本来要启动几十个kernel的计算可能被压到几个kernel显存带宽占用显著下降。精度模式上部署行人检测跟踪我建议首选FP16。对YOLOv5s来说FP16的mAP损失通常小于0.5%但推理速度能再提升30%以上。INT8需要更多工作要用校准数据集来统计每个激活值的分布校准质量差时行人小目标远距离的人很容易丢。特别是在密集场景下INT8的精度抖动比FP16大得多。所以如果你要处理的是密集行人、小目标老老实实用FP16。如果你的系统对带宽特别敏感比如树莓派5这类嵌入平台INT8可能是唯一选择但那就需要专门针对行人数据做校准集而且最好用量化感知训练而不是简单后量化。此外TensorRT版本的选择影响很大。版本10.x默认不再支持部分旧显卡驱动。GTX1070的算力是6.1TensorRT的官方支持矩阵里从某个版本开始可能不再支持Sm_61。这就直接关系到“tensorrt版本如果是10.x是否支持GTX1070”这个热门问题答案是不一定需要查对应版本的release notes。一般我用的是TensorRT 8.5.x或8.6.x对GTX10系支持完善也是社区里验证最多的版本。如果你被迫用10.x就要先跑兼容性检测或者换驱动、换CUDA版本具体见避坑章节。3. 用TensorRT把YOLOv5和DeepSORT接起来转换与推理代码3.1 环境准备CUDA/cuDNN/TensorRT版本匹配与GTX1070兼容性环境版本匹配是TensorRT部署的第一个大坑。不要以为装个最新版就行。我的常见组合是CUDA 11.8 cuDNN 8.6 TensorRT 8.5.3 PyTorch 1.13用于导出ONNX。GTX1070驱动推荐515或525系列。如果你的显卡只有6GB显存YOLOv5s的FP16 engine占用约1GB加上DeepSORT的ReID模型和视频解码buffer勉强够用但别同时开太多进程。在工程结构上我一般建议把推理部分做成C动态库Python只做调度。因为TensorRT的C API比Python API灵活得多特别是自定义插件、动态shape、显存复用这些C写起来不绕。如果你只想快速原型验证也可以先用Python API用tensorrt这个Python包但最终上线还是建议转C。树莓派5这类ARM平台要特别注意TensorRT对ARM上运行有专门版本JetPack路线X86的deb包不能直接迁移。在开始转换模型之前用trtexec验证环境是最快的办法。TensorRT安装包里自带trtexec可以跑一个简单的网络测试确认CUDA、cuDNN和TensorRT三者是否真的协同工作。错误信息多数是“undefined symbol”、“cannot open shared object”等基本就是版本混装。3.2 pt转ONNX再转engine最小命令与两种转换方式我把转换流程写成一个可复用的脚本先在Python里导出ONNX# 进入yolov5源码目录用官方export脚本导出onnx python export.py --weights yolov5s.pt --img 640 --batch 1 --include onnx --opset 12这里我加了--opset 12因为TensorRT对opset 13以上的某些算子支持不全opset 12最稳。导出后会得到yolov5s.onnx。注意官方export默认导出端到端版本会带上NMS。如果你使用的是YOLOv5 v6.0以上的版本--include onnx会自动导出带NMS的端到端模型。这里建议加一个--no-nms参数不同版本参数名有差异v7.0以后是--nms默认关闭实际要看代码确保导出的是不带NMS的版本。如果没有该参数可以通过修改export.py源码把nms分支注释掉。拿到不带NMS的ONNX后用trtexec转enginetrtexec --onnxyolov5s.onnx --saveEngineyolov5s_fp16.engine --fp16 --workspace2048 --minShapesimages:1x3x640x640 --optShapesimages:1x3x640x640 --maxShapesimages:4x3x640x640参数说明--fp16启用半精度--workspace是TensorRT构建时允许使用的显存上限单位MB一般设2048或4096--minShapes/optShapes/maxShapes是动态shape范围如果设定batch4后面推理时就能一次处理4帧。把这三者设成一样就相当于固定shape也可以省一点构建时间。--saveEngine保存engine文件后续部署直接加载不需要再生成。另一种方式是用TensorRT的Python APIimport tensorrt as trt TRT_LOGGER trt.Logger(trt.Logger.WARNING) builder trt.Builder(TRT_LOGGER) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, TRT_LOGGER) with open(yolov5s.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 2 20) # 2GB config.set_flag(trt.BuilderFlag.FP16) serialized_engine builder.build_serialized_network(network, config) with open(yolov5s_fp16.engine, wb) as f: f.write(serialized_engine)这段代码的逻辑是创建builder和network解析ONNX设置workspace和FP16最后序列化engine。2 20是字节数等于2GB。注意TensorRT 8.5开始builder.max_workspace_size被废弃改用set_memory_pool_limit。如果你用的是旧教程代码会报错找不到属性。这是版本迁移最常见的坑。3.3 C推理骨架预处理、推理、后处理与NMSengine生成后写C推理代码。下面是一个最小可用的推理函数骨架只展示核心步骤// trt_yolov5.cpp #include NvInfer.h #include opencv2/opencv.hpp // 假设已经加载enginecontext为IExecutionContext void infer(cv::Mat img, float* output) { // 1. 预处理resize letterbox cv::Mat input; cv::resize(img, input, cv::Size(640, 640)); // 注意实际部署建议用letterbox input.convertTo(input, CV_32FC3, 1.0 / 255.0); // 归一化到[0,1] // 2. 拷贝到GPU显存 cudaMemcpyAsync(buffers[0], input.data, input.total() * sizeof(float), cudaMemcpyHostToDevice); // 3. 推理 context-executeV2(buffers); // 如果是动态batch用executeV2并设置输入的shape // 4. 拷贝输出 cudaMemcpyAsync(output, buffers[1], outputSize * sizeof(float), cudaMemcpyDeviceToHost); cudaDeviceSynchronize(); }这个骨架省略了letterbox处理。直接resize会改变宽高比导致行人框偏移。正确做法是letterbox即等比例缩放并填充灰色边缩放比例min(640/w, 640/h)然后计算pad偏移。后处理时要把检测框坐标减掉pad再除以缩放比例才能映射回原图。TensorRT的输出是一个数组shape是[1, 25200, 85]640x640输入时的anchor总数。你需要自己把它拆成框先按objectness阈值过滤比如0.5然后对每个类别做NMS或者直接在80个类上做一次NMS。由于行人检测通常只用一个类别“person”可以只取类别索引为0的框这样后处理快很多。下面给一个简化版后处理思路// 后处理解析raw output for (int i 0; i 25200; i) { float obj_conf output[i * 85 4]; if (obj_conf 0.5) continue; // 类别置信度取最大值 float max_cls 0; int cls_id 0; for (int j 5; j 85; j) { if (output[i * 85 j] max_cls) { max_cls output[i * 85 j]; cls_id j - 5; } } float final_conf obj_conf * max_cls; if (final_conf 0.5) continue; // 解码中心点坐标和宽高存入boxes } // 对boxes执行NMSIoU阈值0.45注意YOLOv5的输出来自模型的输出层x,y,w,h是相对于输入特征图的中心点坐标和宽高需要乘以对应的stride8、16、32再换算到640x640的坐标。第二步因为输入做了letterbox所以跑出来的框坐标也要做逆变换。很多新手在这里直接用了原图尺寸导致画出来的框偏到左上角。3.4 把检测框喂给DeepSORTDetection结构体与跟踪器初始化有了YOLOv5的检测框接下来要对接DeepSORT。开源DeepSORT的C版本有很多但接口大同小异。常见做法是定义一个Detection结构体struct Detection { cv::Rect_float box; // 原图坐标的框 float confidence; // 检测置信度 cv::Mat feature; // ReID特征如果没用ReID可以置空 };然后把YOLOv5输出的框转换成这个结构体再调用tracker。注意这里的关键是特征DeepSORT原版需要ReID特征来做级联匹配。如果你没有单独训练ReID模型可以只使用MaxDist很大的值比如1.0来让级联匹配退化成纯运动匹配或者直接用dist只计算马氏距离。实际部署中为了速度快很多方案直接把DeepSORT的ReID部分砍掉只保留卡尔曼滤波和IOU匹配。这样做的好处是不用再部署一个ReID网络显存和延迟都降低坏处是遮挡后重识别能力变差。对于行人检测跟踪且摄像头固定、人流量不是特别大的场景纯IOU版本通常够用。如果你的场景是商场、车站这种密集人群我建议还是保留ReID并且把ReID网络也转成TensorRT否则CPU提取特征会拖后腿。一个容易忽略的地方是DeepSORT内部关联时检测框坐标需要是浮点数且要保持原图尺寸。YOLOv5的输出在letterbox坐标系要先映射到原图再送进DeepSORT。另外DeepSORT的卡尔曼滤波器维护了轨迹的[x,y,a,h]其中a是宽高比。行人这个类别宽高比相对稳定所以DeepSORT对行人的跟踪效果通常比车辆好。你可以利用这一点在跟踪前过滤掉宽高比过大或过小的框比如小于0.3或大于1.2的人形框多半是误检但不要过滤得太狠因为行人姿势变化会影响宽高比。4. 部署中的常见问题与排查五条血泪踩坑记录4.1 检测框乱跳或漏检输入尺寸与归一化不一致现象是用TensorRT engine推理一张图片画出来的框位置明显偏上或偏下或者小目标直接消失。换成PyTorch模型就正常。原因基本是预处理不一致。Torch加载的YOLOv5在letterbox时默认scaleupTrue并且使用RGB通道。OpenCV默认读BGR。TensorRT推理前必须保证一是把BGR转RGB二是归一化到0~1三是用和训练一致的letterbox方式。很多OpenCV教程直接cv2.resize忽略了灰色填充导致框的坐标偏。另外一个坑是导出ONNX时YOLOv5源码中预处理默认使用half精度如果你不转成FP16但engine是FP16输入数据仍是FP32TensorRT是允许的但某些旧版本要求输入buffer精度与engine一致。排查方法很简单取一张固定图把TensorRT输出与PyTorch输出做逐像素对比先比对原始raw output如果差异很大多半是归一化或通道顺序错了。4.2 TensorRT 10.x在GTX1070上翻车版本兼容性排查现象是安装TensorRT 10.0后运行trtexec直接提示“no kernel image available”或者“Unsupported architecture: sm_61”甚至加载engine时崩溃。原因是GTX1070是Pascal架构算力6.1。TensorRT 10.x的官方支持表已经移除了对sm_61的预编译kernel支持。这里要区分如果你自己源码编译TensorRT可以增加sm_61支持但几乎没人这么做。稳妥方案是用TensorRT 8.4或8.5版本这两个版本对Pascal、Turing、Ampere的支持都很完整。如果项目强制要求TensorRT 10.x那就只能换显卡比如RTX 3060或者改用OpenVINO。另外即使TensorRT 8.5支持GTX1070驱动也有要求CUDA 11.x需要Linux驱动450以上Windows驱动472以上。升级驱动前先查一下显卡支持多少别盲目装最新驱动。排查顺序建议先nvidia-smi看驱动版本再用trtexec --version看TensorRT版本然后跑一个小网络比如resnet18看能不能build。如果小网络可以YOLOv5不行那问题在模型解析如果小网络也报错就是环境版本问题。4.3 行人ID频繁切换DeepSORT匹配参数的“玄学”调优现象是一个人从镜头前走过ID从1变成2再变回3或者两个人交错后交换ID。原因有多方面。最常见的是max_dist设置问题。DeepSORT默认的max_dist是0.2这个值是用于马氏距离和余弦距离的加权。如果你没有用ReID特征只用了IOU那max_dist基本失去意义因为IOU距离和余弦距离不在一个尺度。此时你需要在代码里修改匹配逻辑比如只看IOU并把max_iou_distance从默认0.7调低到0.5左右让匹配更严格。另外nms_max_overlap如果设置得太低会把YOLOv5输出的高重叠框删掉导致一个人被拆成两个框跟踪时自然会乱。还有一个容易忽略的点max_age参数。DeepSORT里的max_age控制一个轨迹在丢失检测后存活多少帧。行人场景如果人暂时被柱子挡住max_age太短比如默认30会在遮挡期间直接丢失轨迹之后重新分配新ID。建议把max_age增加到60或更多。但max_age也不是越大越好因为轨迹长时间不被更新卡尔曼滤波的协方差会爆炸重新出现时可能产生错误关联。我一般在行人场景设50并且配合较小的max_dist。调参时不要凭感觉。我建议把每一帧的匹配结果打印出来哪些框匹配到了轨迹、哪些是新建轨迹、哪些轨迹被删除。把输出画在视频上并叠加跟踪框的ID。这样你能直观看到ID切换发生在哪一帧再反查参数。这种回归测试的方法比我对着参数表试一百次都快。4.4 多路视频延迟高batch size与显存复用现象是单路跑得很好帧率50fps但四路视频一起跑延迟反而变成200msGPU占用率也不高。原因大多是在单路推理循环里使用了一个单独的TensorRT context并且每路都申请了独立的显存buffer。GPU的并行能力没有被充分利用。解决办法是使用动态batch把多路视频的帧集合成一个batch一起推理。TensorRT在构建engine时已经指定了--maxShapesimages:4x3x640x640那么推理时你最多可以一次塞4帧。实践上要注意多路视频的采集速度不同你不能等所有路都凑齐再推理否则延时会增大。常见做法是用一个线程池每路采集到新帧就放入一个队列推理线程从队列里取batch大小的帧如果队列里不够就等一小段时间超时则用已有的帧。这样最大化吞吐。另外务必复用显存buffer。不要在每帧推理前都cudaMalloc。一次推理申请一次用cudaMemset或者直接覆盖数据。也可以在C里定义一个BufferManager类统一管理输入输出buffer。显存不够时可以考虑把输入图像的预处理放在GPU上用CUDA核函数减少host与device的拷贝开销。4.5 后处理比推理还慢NMS放CPU还是GPU现象是TensorRT推理只花了2ms但整个帧处理时间却要15ms一查发现后处理占了10ms。原因很直接你把25200个候选框的decode和NMS全部放在单线程CPU上做。在GTX1070上CPU性能并不差但25200个框的循环和排序也不便宜。优化方向有几个一是降低候选框的数量。把objectness阈值从0.25提高到0.5尤其在行人检测场景大部分候选框都是背景提前过滤可以省掉大量无效计算。二是把NMS放在GPU上。TensorRT 8.5以上提供了BatchedNMS插件或者你自己写CUDA kernel。最简单的方式是使用TensorRT自带的NMSPlugin但需要把模型输出做一次reshape和阈值过滤。三是压缩类别数。如果只检测person把类别数从80改成1后处理循环量直接减少到原来的1/80效果立竿见影。我自己的经验是先用阈值过滤把候选框从25200降到几百个再在这些框上用CPU NMS这样后处理时间能控制在1ms以内。不要一上来就引入CUDA NMS代码复杂度会明显上升而且一旦版本升级插件API变化又要重写一遍。5. 性能验证与进阶把行人检测跟踪压到最后一帧5.1 用TensorRT自带perf_test量化延迟与吞吐部署完成后不要只盯着打印出来的帧率看那不够严谨。我习惯先用TensorRT自带的trtexec做基准测试但trtexec只能测engine本身的性能测不了你整个推理链。所以我会自己写一个简单的benchmark程序对同一段视频反复推理统计p50、p95延迟以及总帧数和平均帧率。一个可靠的方法是先跑100帧预热GPU再跑500帧计时。预热是必须的因为TensorRT在第一次推理时会做kernel autotuningCUDNN的算法选择也会在第一次触发。预热后的数据才有参考性。记录CPU和GPU占用时用nvidia-smi dmon采样注意TensorRT的显存占用并不是 constant它会根据上下文动态变化。p50和p95的差别很重要。如果你的p50是8msp95却是25ms说明存在明显的调度抖动可能是跟DeepSORT的关联逻辑有关也可能是视频解码线程阻塞。排查方法分别在YOLOv5推理前后和DeepSORT匹配前后打时间戳定位是哪个环节出现尖峰。5.2 动态batch与多路视频流复用单独一路的视频流TensorRT的提升已经足够。但真正的落地场景往往是多路摄像头。动态batch技术就是让一次推理处理多张图片。这里有一个细节多路视频的分辨率可能不一致。TensorRT的动态shape除了batch维度宽高维度也是动态的但你不能在同一个batch里放多种分辨率的输入。通常做法是统一缩放到640x640或者按分辨率分组同分辨率共享一个engine。多路复用还有一个容易被忽略的点DeepSORT的轨迹是每路单独维护的因为不同摄像头下的行人不能跨镜头跟踪。所以多路部署时每一路需要独立的DeepSORT对象。不要为了省内存而共享tracker否则ID会全局混乱。显存允许的前提下每一路都加载自己的YOLOv5 engine context但复用同一份engine权重是可以的。TensorRT支持多个context共用一个engine但注意每个context都需要自己的bindings buffer。5.3 INT8量化时行人数据集校准的教训如果最终决定用INT8要格外谨慎。INT8的校准集必须贴近部署场景。拿通用COCO数据集的1000张图校准在密集行人场景效果会很差。常见做法是从你的测试视频里抽出100到500帧按时间均匀抽取最好包含光照变化、远近不同尺度的人并确保含有一些比较暗的场景。校准集的图片数量不要太多500张以上收益就饱和反而增加校准时间。在TensorRT Python API里使用Calibrator接口class EntropyCalibrator(trt.IInt8EntropyCalibrator2): def __init__(self, images, batch_size): self.images images self.batch_size batch_size self.current 0 def get_batch(self, names): if self.current len(self.images): return None batch self.preprocess(self.images[self.current:self.currentself.batch_size]) self.current self.batch_size return [np.ascontiguousarray(batch)]这段代码里preprocess必须与你推理时的预处理完全一致包括letterbox、颜色通道、归一化。校准过程中tensorRT会运行模型并在不同激活值上收集统计信息。如果校准数据的分布与你推理时差异大会导致一些激活值溢出表现为小目标漏检而不是全部错乱。所以校验INT8模型时不要只看总体mAP要单独看小目标像素面积小于32x32的检出率。我见过不少项目在COCO上mAP只降了0.5%但在实际行人的中远距离检测上误报率翻了一倍。这不是量化本身的问题而是校准集选得不代表真实场景。最后说一个习惯部署版的engine文件要和训练、导出代码版本绑定记录。我一般会在一个配置文件里记录YOLOv5的git commit号、onnx导出参数、TensorRT构建参数、校准集列表然后把这四个信息写进一个json文件和engine一起存档。否则过了一个月模型重新训练了一个版本你压根记不清当时的engine是用哪次权重生成的。这个习惯帮我省了很多次“反向排查”的时间。希望这篇部署笔记能帮你在TensorRT上少踩几个坑也欢迎你把这些经验带到自己的项目里验证一遍。本文还有配套的精品资源点击获取