1. 项目概述为什么INT8推理在自动驾驶落地中不是“可选项”而是“生死线”你手头有一套训练好的YOLOv5或ResNet-101模型精度达标检测框准mAP跑得漂亮——但一上车就卡住。摄像头每秒喂进来30帧1080p图像GPU显存爆了推理延迟飙到280ms车辆在60km/h下已经滑出12米等模型输出结果黄灯早变红灯行人也已走过斑马线。这不是理论推演是某车企实车路测时反复出现的“精度与速度不可兼得”的窒息现场。基于TensorRT 3的自动驾驶快速INT8推理说白了就是把原本需要FP32精度、耗时200ms的模型硬生生压进INT8整型计算框架里在保证检测召回率不掉过3个百分点的前提下把单帧推理时间干到18ms以内让车载计算单元真正能“跟上现实世界的节奏”。它不是实验室里的炫技而是决定一辆L2级车辆能否通过功能安全ASIL-B认证、能否量产装车的硬门槛。核心关键词——TensorRT 3、INT8量化、自动驾驶、实时推理——每一个词背后都连着产线节拍、车规级功耗墙和功能安全红线。适合谁看不是纯算法研究员而是那些天天蹲在嵌入式板卡前调tensorrt_engine、对着nvprof抓kernel耗时、被客户问“你们的AEB触发延迟到底多少毫秒”的一线部署工程师也包括正为毕业设计选题发愁、想拿一个“有真实硬件约束感”的AI项目上简历的研究生。它不讲大而全的深度学习原理只聚焦一件事怎么把纸面上的模型变成铁壳子里能扛住震动、高温、电磁干扰且每帧都不掉链子的可靠推理引擎。2. 整体设计思路为什么必须是TensorRT 3为什么非得走INT8这条路2.1 TensorRT 3那个被低估的“工业级编译器”角色很多人把TensorRT当成一个“加速库”这是个致命误解。TensorRT 3发布于2018年的本质是一个面向NVIDIA GPU的深度学习图编译器与运行时优化器。它不像PyTorch或TensorFlow那样边解释边执行而是把整个网络图——从输入张量、卷积核、激活函数到后处理逻辑——全部静态解析然后做三件关键事层融合Layer Fusion、内核自动调优Kernel Auto-Tuning、内存复用规划Memory Reuse Planning。举个最直观的例子一个典型的YOLOv5检测头原始ONNX图里可能包含Conv BatchNorm LeakyReLU Upsample Concat共7个独立算子节点。TensorRT 3在构建engine时会直接把前三个合并成一个“Conv-BN-ReLU”融合内核省掉两次全局内存读写再把Upsample和Concat也融合进去最终整个检测头可能只生成2个GPU kernel。我实测过某款车载SoC上的ResNet-50原始TensorFlow模型在GPU上跑一次要142ms经TensorRT 3优化后仅靠FP16精度就压到了68ms——这还没动INT8。TensorRT 3之所以成为当时2018–2020自动驾驶量产项目的事实标准核心在于它的确定性同一个engine文件在同一块Tegra Xavier板卡上1000次推理的延迟标准差小于0.3ms这对需要满足ISO 26262 ASIL-B时序安全要求的系统比“平均快”重要一百倍。后来的TensorRT 7/8虽然支持更多算子但在Tegra系列芯片上的engine兼容性反而更脆弱一个TRT7生成的engine在Xavier上可能因cuBLAS版本不匹配直接报错。而TensorRT 3的API极其稳定nvinfer1::ICudaEngine接口十年没变过这才是工业场景真正需要的“老黄牛”。2.2 INT8不是“降精度凑数”而是“用信息论重写计算契约”提到INT8很多人第一反应是“精度暴跌”。错。INT8量化在自动驾驶场景下本质是一场针对传感器数据特性的精准信息压缩工程。摄像头采集的RGB图像其像素值天然集中在0–255整数区间激光雷达点云的反射强度值也基本落在0–1000的整数范围内。这些数据本就不需要FP32那种10^-38到10^38的动态范围用32位浮点去表示一个0–255的整数就像用万吨货轮运一颗螺丝钉——资源浪费且引入冗余噪声。INT8量化做的是用一个缩放因子scale和零点zero-point建立FP32张量与INT8张量的线性映射INT8_value round(FP32_value / scale) zero_point关键难点在于scale不能随便设。设大了微弱特征比如雨雾中的远距离车辆轮廓直接被截断为0设小了强光区域如正午路面反光大量溢出变成饱和值127/-128丢失细节。TensorRT 3的解决方案是校准Calibration它不要求你重新训练模型而是让你提供500–1000张具有代表性的实车采集图像必须覆盖晴天/雨天/黄昏/隧道等典型工况让模型以FP32前向传播一遍记录每一层激活值activation的实际分布直方图再用“熵最小化”算法自动选出最优scale——这个过程叫Entropy Calibration。我做过对比用随机scale粗暴量化YOLOv5s在KITTI数据集上mAP直接掉12.3%而用TensorRT 3的Entropy CalibrationmAP仅下降1.8%且所有漏检案例都集中在“极低对比度的灰色卡车”这类本就难检的边缘case上符合功能安全中“失效可预测”的设计原则。所以INT8不是妥协是用更少比特承载更贴合物理世界的数据本质。2.3 为什么不是FP16为什么不是混合精度FP16看起来很美速度比FP32快约2倍精度损失极小。但它在车载环境里有两个硬伤。第一是动态范围不足FP16的有效数值范围是6×10^-5到65504而自动驾驶模型中BN层的running_var方差在训练后期可能小至10^-8量级FP16直接下溢为0导致推理时batch norm失效输出全乱。第二是硬件支持不均一Tegra Xavier的FP16 tensor core虽强但其INT8 tensor core的峰值算力是FP16的4倍30 TOPS vs 7.5 TOPS且INT8计算功耗仅为FP16的1/3。实测数据显示在Xavier上跑INT8版YOLOv5s整机功耗稳定在22W风扇静音切回FP16功耗跳到31W散热模块开始高频啸叫——这对需要7×24小时运行的ADAS域控制器是不可接受的可靠性风险。至于混合精度如部分层FP16部分层INT8TensorRT 3根本不支持。它的设计哲学很硬核要么全FP32调试用要么全INT8量产用中间态不存在。这种“二极管式”的设计恰恰保障了engine构建与运行的绝对可复现性避免了因某一层精度切换引发的梯度消失或数值不稳定。3. 核心细节解析从ONNX模型到可部署engine的七道关卡3.1 第一道关ONNX导出——别让PyTorch的“灵活”毁了TensorRT的“严谨”很多工程师卡在第一步PyTorch模型导出ONNX后TensorRT 3报错Unsupported operator: Resize或Unsupported attribute: coordinate_transformation_mode。根源在于PyTorch的torch.nn.functional.interpolate在导出时默认使用align_cornersTrue而TensorRT 3只认align_cornersFalse的双线性插值。解决方法不是改模型代码而是在导出时强制指定torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, # 必须≤11TRT3不支持opset12 input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}}, # 关键禁用align_corners custom_opsets{onnx: 11}, ) # 导出后用onnx-simplifier工具清理无用节点 !onnxsim yolov5s.onnx yolov5s_sim.onnx提示务必用onnx-simplifier。我见过太多案例因为PyTorch导出的ONNX里残留了ConstantOfShape这类TRT3无法识别的算子导致build engine失败。简化后的ONNX文件体积通常缩小40%且图结构干净TRT3解析成功率100%。3.2 第二道关校准数据集——500张图怎么选比模型训练还考功力校准数据的质量直接决定INT8 engine的鲁棒性。绝不能用ImageNet子集或COCO验证集——那些图太“干净”全是居中、打光均匀的物体。你需要的是真实车载视角的“脏数据”。我的做法是从实车采集的10万帧视频中按以下规则抽样500张200张晴天正午高对比度含强光反射如玻璃幕墙、湿滑路面150张黄昏/黎明低照度物体边缘模糊信噪比低于15dB100张中雨天气挡风玻璃有水痕远处目标呈弥散状50张隧道出入口明暗交界剧烈存在严重过曝与欠曝区域。每张图必须带原始标注bbox坐标用于后续验证量化后精度损失。校准前先用OpenCV对图像做预处理统一resize到640×640保持长宽比padding黑边BGR转RGB归一化除以255.0不做任何gamma校正或直方图均衡——因为实车ISP模块输出的就是原始gamma2.2的图像校准必须模拟真实pipeline。3.3 第三道关Calibration算法选型——Entropy还是Min-Max数据说了算TensorRT 3提供两种校准模式IInt8EntropyCalibrator2默认和IInt8MinMaxCalibrator。前者用直方图熵最小化选scale后者直接取激活值最大最小值。多数人无脑选Entropy但我在某毫米波雷达点云分割项目上栽过跟头点云强度值分布极度偏态95%数据集中在0–105%异常值高达500Entropy Calibration被那5%异常值带偏scale设得过大导致主干特征全被压扁。这时必须切到Min-Max并手动截断异常值// 在calibrator类中重写getBatch() float* data new float[batchSize * channels * height * width]; for (int i 0; i batchSize; i) { cv::Mat img cv::imread(imagePaths[i]); preprocess(img, data i * size); // 预处理 // 关键对每个通道单独截断 for (int c 0; c channels; c) { float* ptr data i * size c * height * width; for (int j 0; j height * width; j) { if (ptr[j] 255.0f) ptr[j] 255.0f; // 强制上限 } } }注意Min-Max校准后必须用trtexec --int8 --calibcalib.table命令生成校准表再用该表构建engine。Entropy则无需此步直接--int8即可。3.4 第四道关Engine构建参数——那些藏在文档角落的“保命开关”IBuilderConfig里的参数表面看是性能调优实则是功能安全的“保险丝”。最关键的三个setMaxWorkspaceSize(1_GiB)必须设Xavier板卡显存仅8GB若不设限TRT3可能申请4GB workspace导致其他进程OOM。实测1GB workspace对YOLOv5s足够且能避免显存碎片化。setFlag(BuilderFlag::kSTRICT_TYPES)必开。它强制所有层使用INT8计算禁用任何FP32 fallback。关掉它某些复杂层如自定义NMS可能悄悄切回FP32导致INT8精度优势全失且时序不可预测。setAverageFindIterations(2)控制auto-tuning迭代次数。设为1会跳过tuning用默认kernel快但慢15%设为4会多花2分钟但快3%。我一律设2——在开发机上多等1分钟换来实车测试时10ms的确定性延迟值。构建代码片段IBuilder* builder createInferBuilder(gLogger); INetworkDefinition* network builder-createNetwork(); // 解析ONNX... ICudaEngine* engine builder-buildEngineWithConfig(*network, *config); // 关键序列化engine供车载端加载 IHostMemory* serializedModel engine-serialize(); std::ofstream p(yolov5s_int8.engine, std::ios::binary); p.write(reinterpret_castconst char*(serializedModel-data()), serializedModel-size());3.5 第五道关推理Pipeline——如何让INT8 engine真正“活”在车载系统里engine文件只是冰山一角。真正的挑战在推理循环的健壮性设计内存绑定INT8 engine的输入buffer必须是cudaMallocPitch分配的而非cudaMalloc。因为TRT3的INT8 kernel对内存对齐要求苛刻需128字节对齐cudaMallocPitch自动处理行对齐避免因地址未对齐导致kernel silent fail不报错但输出全0。同步机制绝不能用cudaDeviceSynchronize()——它会阻塞整个GPU。必须用cudaEvent_t做细粒度同步cudaEventRecord(start, 0); context-execute(batchSize, buffers[0]); // buffers[0]是输入buffers[1]是输出 cudaEventRecord(stop, 0); cudaEventSynchronize(stop); float milliseconds 0; cudaEventElapsedTime(milliseconds, start, stop); // 精确测时后处理迁移NMS非极大值抑制这种逻辑复杂、分支多的操作TRT3不支持INT8 NMS layer。必须在CPU端用OpenCV的cv::dnn::NMSBoxes实现但输入bbox坐标必须从INT8输出buffer中反量化回来// 假设output_buffer是INT8指针scale0.003921/255 float* fp32_output new float[output_size]; for (int i 0; i output_size; i) { fp32_output[i] (output_buffer[i] - zero_point) * scale; } cv::dnn::NMSBoxes(bboxes, scores, 0.3, 0.45, indices); // CPU端NMS实操心得NMS耗时占整帧推理的35%必须用OpenMP并行化。我用#pragma omp parallel for把bboxes分块实测在Xavier的8核CPU上NMS从42ms压到11ms。4. 实操全流程从零搭建YOLOv5s INT8推理引擎附完整代码与参数4.1 环境准备Tegra Xavier JetPack 4.4的“黄金组合”TensorRT 3与JetPack版本强绑定。必须用JetPack 4.4含CUDA 10.2、cuDNN 8.0、TensorRT 7.1.3.4因为TRT 7.1.3.4是最后一个完全兼容TensorRT 3 API的版本通过libnvinfer.so.7软链接指向TRT3的底层实现。安装步骤刷机用NVIDIA SDK Manager下载JetPack 4.4选择“Jetson AGX Xavier”目标取消勾选“Deep Learning Frameworks”避免安装TF/PyTorch冲突验证dpkg -l | grep tensorrt应显示libnvinfer7和libnvinfer-plugin7设置环境变量export TENSORRT_ROOT/usr/lib/aarch64-linux-gnu export LD_LIBRARY_PATH$TENSORRT_ROOT:$LD_LIBRARY_PATH注意JetPack 4.5已移除TRT3兼容层强行降级会破坏系统稳定性。某次我帮某公司救急他们用4.5刷机后硬装TRT3结果CUDA驱动崩溃Xavier变砖三次。4.2 模型准备YOLOv5s的ONNX导出与简化实测可用代码以YOLOv5 v5.0版本为例修改models/export.pydef export_onnx(model, im, file, opset11): # 关键替换interpolate为onnx兼容的Resize for m in model.modules(): if isinstance(m, Detect): # 替换Detect层的upsample m.m nn.Sequential(*[ nn.Upsample(scale_factor2, modenearest), # 强制nearest禁用bilinear Conv(c1, c2, 1) # 后续卷积保持不变 ]) # 导出 torch.onnx.export( model, im, file, opset_versionopset, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}}, # 关键添加shape inference do_constant_foldingTrue ) # 简化 import onnx from onnxsim import simplify model_onnx onnx.load(file) model_simp, check simplify(model_onnx) onnx.save(model_simp, file.replace(.onnx, _sim.onnx)) print(fONNX export success: {file})运行python export.py --weights yolov5s.pt --include onnx --opset 11生成yolov5s_sim.onnx。用Netron打开检查所有Resize节点的coordinate_transformation_mode属性必须为asymmetric否则TRT3拒绝加载。4.3 校准器实现Entropy Calibration的C实操避坑版创建calibrator.hclass Int8EntropyCalibrator2 : public IInt8EntropyCalibrator2 { private: int batchSize_; int batchCount_; std::vectorstd::string imageList_; int currIndex_; float* deviceInput_; std::string cacheFile_; public: Int8EntropyCalibrator2(int batchSize, const std::vectorstd::string images, const std::string cacheFile) : batchSize_(batchSize), imageList_(images), cacheFile_(cacheFile), currIndex_(0) { cudaMalloc(deviceInput_, batchSize * 3 * 640 * 640 * sizeof(float)); } virtual ~Int8EntropyCalibrator2() { cudaFree(deviceInput_); } int getBatchSize() const override { return batchSize_; } bool getBatch(void* bindings[], const char* names[], int nbBindings) override { if (currIndex_ imageList_.size()) return false; std::vectorcv::Mat batch; for (int i 0; i batchSize_; i) { if (currIndex_ imageList_.size()) break; cv::Mat img cv::imread(imageList_[currIndex_]); cv::resize(img, img, cv::Size(640, 640)); img.convertScaleAbs(img, img, 1.0/255.0); // 归一化到[0,1] batch.push_back(img); } // 合并batchBGR-RGBNHWC-NCHW float* hostInput new float[batchSize_ * 3 * 640 * 640]; for (int n 0; n batch.size(); n) { for (int c 0; c 3; c) { for (int h 0; h 640; h) { for (int w 0; w 640; w) { // OpenCV是BGRTRT要RGB int srcIdx h * 640 * 3 w * 3 (2-c); // 2-c实现BGR-RGB int dstIdx n * 3 * 640 * 640 c * 640 * 640 h * 640 w; hostInput[dstIdx] batch[n].data[srcIdx] / 255.0f; } } } } cudaMemcpy(deviceInput_, hostInput, batchSize_ * 3 * 640 * 640 * sizeof(float), cudaMemcpyHostToDevice); bindings[0] deviceInput_; delete[] hostInput; return true; } const void* readCalibrationCache(size_t length) override { std::ifstream input(cacheFile_, std::ios::binary); input.seekg(0, std::ios::end); length input.tellg(); input.seekg(0, std::ios::beg); char* cache new char[length]; input.read(cache, length); return cache; } void writeCalibrationCache(const void* cache, size_t length) override { std::ofstream output(cacheFile_, std::ios::binary); output.write(static_castconst char*(cache), length); } };关键避坑readCalibrationCache返回的指针必须是new分配的堆内存且writeCalibrationCache中cache指针由TRT内部管理不可delete。我曾因delete[] cache导致segmentation faultdebug三天。4.4 Engine构建与推理端到端C代码可直接编译build_engine.cpp#include NvInfer.h #include NvInferPlugin.h #include calibrator.h #include fstream #include iostream using namespace nvinfer1; void buildEngine(const std::string onnxFile, const std::string engineFile, const std::vectorstd::string calibImages) { Logger logger; IBuilder* builder createInferBuilder(logger); INetworkDefinition* network builder-createNetwork(); // 解析ONNX auto parser nvonnxparser::createParser(*network, logger); parser-parseFromFile(onnxFile.c_str(), 1); // 配置 IBuilderConfig* config builder-createBuilderConfig(); config-setMaxWorkspaceSize(1ULL 30); // 1GB config-setFlag(BuilderFlag::kSTRICT_TYPES); config-setAverageFindIterations(2); // 校准 Int8EntropyCalibrator2 calibrator(1, calibImages, calib.table); config-setInt8Calibrator(calibrator); // 构建 ICudaEngine* engine builder-buildEngineWithConfig(*network, *config); IHostMemory* modelStream engine-serialize(); // 保存 std::ofstream p(engineFile, std::ios::binary); p.write(reinterpret_castconst char*(modelStream-data()), modelStream-size()); std::cout Engine built: engineFile std::endl; // 清理 modelStream-destroy(); engine-destroy(); config-destroy(); network-destroy(); parser-destroy(); builder-destroy(); } int main() { std::vectorstd::string calibList {calib/00001.jpg, calib/00002.jpg, /* ... */}; buildEngine(yolov5s_sim.onnx, yolov5s_int8.engine, calibList); return 0; }编译命令g -stdc11 build_engine.cpp -o build_engine \ -lnvinfer -lnvonnxparser -lnvcaffeparser -lnvinfer_plugin \ -L/usr/lib/aarch64-linux-gnu -I/usr/include/aarch64-linux-gnu ./build_engine生成yolov5s_int8.engine后推理代码infer.cpp只需加载engine、分配buffer、执行context-execute()全程50行核心代码。4.5 性能实测数据Xavier上的硬核成绩单在Tegra Xavier32GB LPDDR4xJetPack 4.4上对YOLOv5s进行全链路测试指标FP32FP16INT8EntropyINT8Min-Max单帧推理延迟158ms72ms17.3ms16.8ms整机功耗38.2W31.5W22.1W21.9WmAP0.555.2%54.9%53.4%51.7%内存占用1.8GB1.2GB0.9GB0.85GB连续运行1小时温度78°C82°C65°C64°C实测心得INT8的17.3ms是端到端延迟含数据拷贝、kernel launch、NMS非纯GPU计算时间。温度降低13°C意味着风扇可维持最低转速整车NVH噪声振动粗糙度指标提升一个等级——这对高端车型是硬性卖点。5. 常见问题与排查技巧那些官方文档不会写的“血泪经验”5.1 问题速查表从报错日志直击根因报错日志根本原因排查步骤解决方案ERROR: INVALID_ARGUMENT: Cannot find binding of given name: inputONNX导出时input_names与实际图输入名不一致用Netron打开ONNX查看左侧Inputs节点名称修改torch.onnx.export的input_names参数严格匹配Netron显示名ERROR: UNSUPPORTED_NODE: Node (Resize_123) has input weight not initializedResize节点缺少scale属性Netron中检查Resize节点看是否有scales输入在PyTorch中用nn.Upsample替代F.interpolate并设modenearestERROR: Internal error: could not find any implementation for node网络含TRT3不支持算子如GELU、SoftmaxV2trtexec --onnxmodel.onnx --verbose查看详细解析日志用torch.nn.functional.softmax替代torch.nn.Softmax避免inplace操作Segmentation fault (core dumped)校准器readCalibrationCache返回栈内存或未分配内存GDB调试calibrator-readCalibrationCache返回地址确保返回指针由new分配且length参数正确赋值Engine validation failed: Input dimensions mismatch输入buffer尺寸与engine期望不符engine-getBindingDimensions(0)打印期望尺寸用cudaMallocPitch分配buffer并确保width*height*channels与期望一致5.2 “幽灵bug”排查INT8特有的精度漂移陷阱某次路测发现INT8 engine在隧道出口处频繁漏检自行车。用trtexec --loadEngineyolov5s_int8.engine --dumpOutput导出各层输出对比FP32结果发现第12层P3特征图的激活值在明暗交界处出现系统性偏移FP32输出均值为0.21INT8为0.18偏差达14%。根因是校准数据中缺乏隧道场景样本。解决方案从实车视频中提取100张隧道出口图像加入校准集用trtexec --int8 --calibcalib.table --saveCalibcalib_new.table重新生成校准表关键删除旧engine用新校准表重建——TRT3不会自动更新已有engine的scale参数。提示用trtexec --onnxmodel.onnx --int8 --calibcalib.table --dumpProfile可生成各层scale值CSV人工检查是否某层scale异常如P3层scale0.005而P4层0.02说明P3量化过激。5.3 硬件级优化Xavier的“隐藏性能开关”Xavier的GPU频率默认被限制在1.1GHz节能模式。实测发现INT8推理时GPU利用率仅65%瓶颈在内存带宽。开启性能模式sudo nvpmodel -m 0 # 设置为MAXN模式 sudo jetson_clocks # 锁定GPU/CPU最高频此时GPU升至1.37GHzINT8延迟从17.3ms降至15.8ms且nvidia-smi显示GPU Memory-Usage从92%降至78%。但代价是功耗升至25.3W需确认散热模组能否持续承受。某次我忽略这点连续测试2小时后Xavier触发thermal throttleGPU频率自动降频延迟跳变到22ms误判为engine bug。5.4 功能安全补丁如何让INT8 engine通过ASIL-B认证ISO 26262要求任何安全相关功能必须具备故障检测与响应机制。INT8 engine本身无自检能力需在应用层加护输入完整性检查每次memcpy前用cudaMemGetInfo检查显存剩余量100MB则丢弃本帧输出合理性验证NMS后检查bbox坐标是否超出图像边界如x10或x2640若超限则标记“输出异常”触发降级策略如冻结上一帧结果时序监控用clock_gettime(CLOCK_MONOTONIC, ts)记录每帧start/end时间若连续3帧延迟25ms上报E_INT8_ENGINE_TIMEOUT错误码通知MCU进入L2降级模式。这些补丁代码不足100行却是过审的关键证据——它证明你不是把INT8当“黑盒”用而是理解其边界并构建了完整的安全监控链。6. 实战延伸从单模型到车载多任务推理框架6.1 多模型协同如何让YOLOv5s与语义分割共享INT8 engine资源一辆车不止要检测还要分割车道线、可行驶区域。若为每个模型单独建INT8 engine显存不够。TensorRT 3支持多输入多输出Multi-IOengine把YOLOv5s的检测头和SegFormer的分割头拼成一个ONNX图共享Backbone如EfficientNet-B3。构建时network-addInput()添加两个输入张量det_input,seg_inputnetwork-markOutput()标记两个输出det_output,seg_output。关键技巧两个输入必须同尺寸如640×640且预处理参数mean/std一致在IBuilderConfig中setMaxWorkspaceSize需按两倍峰值需求设如2GB推理时context-execute()传入双buffer数组TRT3自动调度kernel。实测在Xavier上双任务INT8 engine总延迟28ms比两个单任务engine171532ms快4ms且显存占用仅1.4GB单任务各0.9GB。6.2 模型热更新如何在不重启系统的情况下切换INT8 engine车载系统要求OTA升级时服务不中断。TRT3 engine是二进制文件可动态加载。方案新engine下载到/tmp/yolov5s_v2.engine启动新线程用dlopen加载libnvinfer.so.7调用createInferRuntime新建runtimeruntime-deserializeCudaEngine加载新engine创建新IExecutionContext原context执行完当前帧后原子切换指针指向新context旧context在无引用后自动销毁。注意deserializeCudaEngine是线程安全的但IExecutionContext不是。切换时必须用std::atomic保护context指针。6.