YOLOv11边缘部署实战：从TensorRT转换到性能调优的完整链路

简介：YOLOv11模型轻量化与边缘部署全攻略，面向计算机视觉开发者、算法工程师及边缘计算从业者，系统解决目标检测模型在资源受限设备上的高效落地问题。文档从YOLOv11架构解析入手，完整覆盖模型剪枝、量化、知识蒸馏等轻量化技术，并深入讲解TensorRT引擎转换、层融合、多流推理、内存管理及精度性能平衡等优化策略；同时结合智能安防、工业检测、自动驾驶等实战案例，给出边缘设备选型、环境搭建与软硬件协同调优方法。资源为单份PDF文件，共26页，大小1.91MB，支持内置目录跳转与阅读器大纲定位，内容排版清晰，适合按章节针对性查阅。已有267人学习浏览，可供目标检测部署与性能优化阶段的开发者作为系统参考。

1. YOLOv11轻量化：从TensorRT到边缘计算，真正卡住你的不是模型而是部署链路

第一次把YOLOv11的权重文件下载下来，满怀期待地部署到Jetson Orin上跑实时推理，结果帧率只有个位数，内存直接被吃满，当时就知道轻量化这件事没那么简单。很多做工业视觉的同行把精力全放在调模型结构上，觉得换成YOLOv11n或者用一个HCANet之类的注意力模块就能解决问题，实际上真正决定边缘设备能不能跑起来的，是后面那一整条部署链路——模型裁剪、TensorRT转换、引擎校准、内存复用、多路并发。这份全攻略PDF就是沿着这条链路一步步拆的，从环境配置讲到性能调优，我复现完以后觉得它特别适合两类人：一类是刚把YOLOv11环境配置跑通、想往边缘设备迁移的入门开发者，另一类是在工业现场被延迟和显存反复折磨、需要一份完整调优参考的中级工程师。它解决的不是"能不能检测"的问题，而是"在有限算力下，检测能快到什么程度"的问题，网络结构怎么选、TensorRT参数怎么设、边缘侧哪些坑不能踩，这份资源里都给了具体的答案。

2. 模型轻量化选型：YOLOv11系列不是越小越好，得先想清楚瓶颈在哪

2.1 量级选择的真实依据：算力、精度、显存的三方博弈

YOLOv11这条线延续了Ultralytics一贯的n/s/m/l/x分级策略，每一档的差异不只是参数量，还直接影响后续TensorRT部署时的显存占用和推理延迟。很多人上来就选YOLOv11n，理由是它最轻，但在边缘设备上这未必是最优解。我实际测过低算力平台，n版本在小目标场景下漏检率明显偏高，比如检测视野里小于16×16像素的缺陷区域时，n版本基本是放弃状态，s版本勉强能稳定检出。反过来在Jetson Orin Nano这类设备上，m版本配合TensorRT FP16推理，单帧延迟能控制在12毫秒左右，精度比n版本高出一截，代价仅仅是多占一百多MB显存——如果设备本身就配了8GB复用内存，这根本不是问题。

所以在选型时，我一般会先跑一个基准：用官方权重在你的业务数据集上测出各版本的mAP@0.5，然后看边缘设备的可用算力和内存余量，再决定用哪个档位。全攻略里给了一张推荐表，大致思路是：显存小于2GB选n，2到4GB选s，4GB以上且小目标多选m，追求极致吞吐且散热够再考虑l或x。这里最忌讳的是拍脑袋选小模型，因为轻量化的目标不是让模型最小，而是让"精度+速度+内存"这个三角在业务阈值内同时满足。

同样值得关注的是模型的部署方式。YOLOv11的PyTorch权重转ONNX再转TensorRT，这个链路里每一步都可能引入精度损失。我见过不少人直接拿PyTorch模型在边缘设备上跑，FP32推理精度倒是没问题，但速度完全没法看。正确的做法是先把模型导出成ONNX，再用TensorRT的trtexec工具生成engine文件，并在生成时指定FP16甚至INT8精度。FP16对精度的影响一般是可接受的，mAP掉0.3%到0.8%之间，换来的是几乎翻倍的吞吐；INT8就得配合校准数据集了，后面我会专门讲这部分，因为这是整个流程里翻车率最高的环节。

2.2 剪枝与蒸馏的正确打开方式：从ultralytics导出ONNX说起

如果没有能力改网络结构，最稳妥的轻量化手段就是蒸馏和剪枝。YOLOv11提供了一个很好用的起点：先用大模型做教师网络，在业务数据上蒸馏出一个小的学生网络。具体操作用Ultralytics的API可以完成，核心不是改代码，而是蒸馏损失怎么设置。常见做法是用特征图对齐加上检测头的置信度对齐，我自己更习惯只用logits蒸馏，因为特征对齐在YOLO这种复杂检测头里容易让学生网络学到教师网络的冗余信息。

蒸馏之后做剪枝，重点要剪的是C2f模块里的冗余通道。这部分全攻略PDF提供了脚本思路，核心是先做通道重要性统计，再对不重要的通道做剪枝，最后微调几个epoch恢复精度。这里有个非常关键的参数——稀疏化训练的系数，我一般设置在1e-3到5e-3之间，系数太低通道稀疏不明显，剪完效果有限；系数太高会把重要通道也剪掉，精度直接崩。我踩过这个坑，稀疏化系数拉到1e-2，剪完以后mAP掉了18个点，重新微调了30个epoch才勉强拉回来。

# 通道稀疏化训练示例：先用少量epoch找出重要通道 from ultralytics import YOLO model = YOLO("yolov11m.pt") # ssparsity: 稀疏化系数，1e-3到5e-3之间比较安全；epochs建议30-50，太多会过拟合到稀疏结构 # 大模型做教师，学生模型可以是同结构的窄版本 results = model.train( data="coco128.yaml", epochs=30, ssparsity=3e-3, batch=16, device=0, project="sparse_train" )

这段代码的逻辑是：在正常训练流程里叠加一个稀疏化惩罚项，让部分通道的权重逐渐逼近零。等到训练结束后，统计每个通道的L1范数，把低于阈值的通道剪掉，再用剪完的薄模型微调15到20个epoch恢复。这里有两个参数要解释一下：ssparsity是稀疏化强度，决定多少通道会被推向零；epochs不要给太长，稀疏化训练只是为了让通道分布产生明显的长尾效应，给长了反而让所有通道都变稀疏，剪完精度损失反而大。做完这一步，模型体积通常能缩减30%到50%，FP16推理速度提升20%左右——如果你追求更激进的轻量化，这个方向会比直接换n版本更可控，因为你能精确控制剪掉哪些层。

3. TensorRT部署实战：从权重文件到engine文件的完整转换链路

3.1 环境配置的每一步：CUDA、cuDNN、TensorRT版本对应关系

TensorRT部署的第一个拦路虎不是代码，是环境。很多人在Ubuntu上装TensorRT时碰到版本对不上的问题——CUDA版本、cuDNN版本、TensorRT版本三者之间有一张对应表，任何一个不匹配，转换工具都会报库加载失败或算子不支持。最常见的是TensorRT 8.x与CUDA 11.x的组合，如果你用的是Jetson平台，还要注意JetPack版本和TensorRT的对应关系，比如JetPack 5.1自带TensorRT 8.5.2，而JetPack 6.0则对应TensorRT 8.6.1。

安装步骤上，我建议不要用pip直接装tensorrt，除非你用conda环境且CUDA也是conda安装的。最稳妥的方式是从NVIDIA官网下载TensorRT的tar包，然后手动加入环境变量。整个流程可以这样：先确认版次，再下载、解压、配置环境变量，最后验证安装。

# 确认CUDA和cuDNN版本，再决定TensorRT的对应版本 nvcc --version # 例如输出 CUDA 11.8 则选择 TensorRT 8.5.1/8.6.x 均可 # 解压后配置环境变量 tar -xzvf TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda.11.8.tar.gz echo 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/TensorRT-8.6.1.6/lib' >> ~/.bashrc echo 'export PATH=$PATH:/opt/TensorRT-8.6.1.6/bin' >> ~/.bashrc source ~/.bashrc # 验证安装 trtexec --version python3 -c "import tensorrt; print(tensorrt.__version__)"

这里有一件事要特别强调：TensorRT的tar包里自带的Python wheel只对应你下载的那个CUDA版本，如果系统里CUDA是11.8但你装了12.x的wheel，import tensorrt时就会直接Segmentation Fault，而且没有任何提示。我见过不少人在这一步反复重装系统，实际上只要确保wheel版本和系统CUDA完全一致就行。另外trtexec是调试engine的好工具，--version能出结果就说明库加载正常，再往后就是模型转换的事了。

3.2 从YOLOv11导出ONNX到生成engine：动态shape与FP16的精调

YOLOv11的官方导出命令已经封装得很好了，用ultralytics包直接导出ONNX就行。这里需要注意的核心参数是opset和dynamic，opset版本建议11以上，因为TensorRT的某些算子需要新版本onnx才能识别。dynamic=True会导出动态输入尺寸，但动态shape在TensorRT里会触发重新优化，并且显存占用会比固定shape高出不少。对于边缘设备固定分辨率的场景，我强烈建议导出固定shape，把输入尺寸锁定在业务最常用的分辨率上，比如640×640，别给动态shape留空间。

# 导出ONNX，固定输入尺寸，使用FP16精度 yolo export model=yolov11m.pt format=onnx opset=12 dynamic=False imgsz=640 half=True # 使用trtexec生成FP16 engine trtexec --onnx=yolov11m.onnx \ --saveEngine=yolov11m_fp16.engine \ --fp16 \ --workspace=2048 \ --minShapes=images:1x3x640x640 \ --maxShapes=images:16x3x640x640

命令里--workspace是构建engine时的最大显存预算，单位MB，给太小转换会报内存不足，给太大会让构建阶段占用过多显存导致系统卡死。--minShapes和--maxShapes在固定shape下其实不生效，但保留它们可以避免某些版本的trtexec报参数缺失。这里有个经验值：FP16的engine体积一般是ONNX的一半左右，推理速度是FP32的两倍上下，但如果模型里有某些算子对FP16不友好（比如Sigmoid后面的计算），速度提升可能打折，这时候可以用--precisionConstraints手动指定一组算子跑FP32，代价是显存占用上升。

转完engine文件，验证的时候不要只看帧率，要同时跑一遍精度对比。用同一批测试图片分别跑PyTorch模型和TensorRT engine，计算mAP差异。FP16下mAP下降超过1%就要检查有没有算子在FP16下溢出，常见问题出在最后一层卷积的输出范围超过了FP16的表达上限，这种情况可以在转换时给该层单独指定FP32。

3.3 Python调用engine的正确姿势：避开每次推理重新加载的坑

生成engine文件以后，Python侧的推理代码看起来很简单，但有一个高频错误：每次推理都重新加载engine文件。engine的加载和反序列化非常耗时，Jetson这类设备上加载一次要一两秒，如果每次都重新加载，帧率直接掉到0.5以下。正确做法是程序启动时加载一次，之后持续复用一个执行上下文。

import tensorrt as trt import pycuda.driver as cuda import numpy as np class TRTEngine: def __init__(self, engine_path): # 引擎文件只加载一次，整个生命周期复用 logger = trt.Logger(trt.Logger.INFO) with open(engine_path, "rb") as f: runtime = trt.Runtime(logger) self.engine = runtime.deserialize_cuda_engine(f.read()) self.context = self.engine.create_execution_context() # 绑定输入输出缓冲区，固定显存地址避免反复分配 self.inputs = [] self.outputs = [] self.allocations = [] for i in range(self.engine.num_bindings): shape = self.engine.get_binding_shape(i) size = trt.volume(shape) * self.engine.max_batch_size dtype = trt.nptype(self.engine.get_binding_dtype(i)) host_mem = cuda.pagelocked_empty(size, dtype) dev_mem = cuda.mem_alloc(host_mem.nbytes) self.allocations.append(dev_mem) if self.engine.binding_is_input(i): self.inputs.append(host_mem) else: self.outputs.append(host_mem) def infer(self, input_data): # 拷贝输入到显存，执行推理，再拷贝回主机 cuda.memcpy_htod(self.allocations[0], input_data) self.context.execute_v2(bindings=self.allocations) cuda.memcpy_dtoh(self.outputs[0], self.allocations[1]) return self.outputs[0]

这段代码值得注意的地方有三个。一是pagelocked_empty分配的是锁页内存，DMA拷贝速度比普通内存快很多，边缘平台上有个几倍的差距；二是execute_v2绑定的是一次性传入所有输入输出的显存地址，所以allocations数组的顺序必须和engine的binding顺序一致；三是如果你用的是TensorRT 10以上的版本，max_batch_size可能被移除了，就用get_binding_shape实际返回的形状计算元素个数。我一般还会在这个基础上把图像预处理（缩放、归一化、通道变换）也合并进同一份内存里，省掉一次拷贝。

4. 边缘计算性能调优：吞吐上不去不是CPU瓶颈，是内存拷贝和管线设计出了问题

4.1 从Jetson到RK3588：不同边缘设备的调优策略差异

边缘设备的选择会直接改变TensorRT的调优方向。NVIDIA Jetson系列走的是GPU路线，TensorRT能充分发挥统一内存的优势，调优重点是显存分配和CUDA流管理。而RK3588这类NPU方案走的是另一套工具链，不需要TensorRT，但对应的RKNN转换流程里有自己的量化校准和算子融合规则。这也就是说，如果你是换平台部署，那份TensorRT的engine文件不能直接复用，必须先重新导出ONNX再转换。

在Jetson上，我最常优化的垂直方向是减少CPU-GPU之间的数据来回。Jetson的CPU和GPU共享内存，很多人的误区是还会再用cuda.memcpy_htod把数据搬一次，实际上在单卡场景下共享内存可以直接用zero-copy，省掉一次拷贝。全攻略里提到过，Jetson上Camera输入可以用libargus或v4l2直接映射到CUDA内存，整个pipeline从采集到推理结束都不经过CPU内存，这才是实时性的关键。

RK3588这边，关键参数是NPU的core分配和量化方法。RKNN工具链在导出时可以选择混合量化，遇到精度敏感的层单独保留FP16，其他层走INT8。这个策略在RK3588上能把模型跑到几十毫秒以内，但完全INT8在精度上很容易翻车，所以建议先做逐层量化精度分析再决定哪些层回退。调优完之后，用rknn_perf工具跑一遍各层耗时，重点找耗时占比超过20%的算子层，再做特定优化。

4.2 批处理与多线程：边缘设备上最容易被忽视的吞吐利器

很多人做边缘部署时只盯着单帧延迟，忽略了吞吐量。实际上很多工业检测场景是连续帧流水处理，这时用批处理能显著提升GPU利用率。TensorRT天然支持多batch输入，只需要在构建engine时把maxBatchSize设置为实际需要的值。但注意，batch增大带来的延迟增加不是线性的，我实测过从batch=1到batch=8，单帧延迟从11毫秒涨到16毫秒，但吞吐从90FPS涨到500FPS，对多路视频流来说这是质变。

# 多batch推理：输入shape为(batch, 3, 640, 640) import numpy as np import time engine = TRTEngine("yolov11m_fp16_batch8.engine") batch_size = 8 # 模拟8路视频帧，批量归一化后交给推理引擎 frames = np.random.randn(batch_size, 3, 640, 640).astype(np.float32) start = time.perf_counter() for _ in range(100): # 预处理：归一化已经在数据层面完成，这里直接推理 output = engine.infer(frames.flatten()) end = time.perf_counter() print(f"平均batch推理耗时: {(end - start) / 100 * 1000:.2f} ms")

这里的核心要点是输入数据必须是flatten()之后的连续内存块，TensorRT不接受非连续的numpy数组，否则memcpy_htod时会出现不可预知的内容错乱。多batch推理时，数据拼接尽量放在采集线程就完成，不要在推理前临时拼接，因为拼接本身也消耗CPU时间。真正部署的时候，我会把框架设计成"双缓存"模式——采集线程向buffer A写入数据，推理线程读buffer B中的数据，两个buffer交替使用，这样采集和推理完全重叠，吞吐能接近理论峰值。

另一个容易忽略的地方是预热。TensorRT的engine第一次推理时CUDA kernel需要编译和加载，耗时能达到几百毫秒。所以正式运行之前一定要跑几轮空推理预热。全攻略里给的建议是预热至少10次，让cuDNN的autotune把最优算法选出来。如果你发现前几帧特别慢，后面突然变快，就是预热不够，不是什么玄学问题。

4.3 显存管理与内存复用：长时间运行不崩的底层保障

边缘设备最怕的不是性能不够，而是跑两小时以后显存慢慢涨满然后系统卡死。这个问题绝大多数不是TensorRT的bug，是代码里没有做显存复用。Python侧用pycuda.mem_alloc分配显存时，如果每次推理都新建而不是复用，显存碎片和累积泄漏就会让设备在半小时内耗尽内存。

# 显存复用：不要反复mem_alloc，启动时一次性分配 # 推理时只复用self.allocations已经绑定的显存块 # 如果输入尺寸变化（比如多分辨率切换），用set_input_shape重新绑定 engine.context.set_input_shape("images", (batch_size, 3, 640, 640))

这段代码解决的是多分辨率切换的场景——某些业务需要先低分辨率粗检、再高分辨率精检，如果不重新set_input_shape，引擎会直接用旧绑定shape导致越界访问。显存复用之外，还要关注CPU侧的页锁定内存释放。Python的垃圾回收不可控，建议在推理循环里显式del不再使用的大数组，再用gc.collect()触发回收，否则多余的内存占用会拖慢整个系统。

长时间运行的另一个隐性杀手是CUDA context的数量。如果用OpenCV的cv2.imshow或plt.imshow这类接口，它们会在后台创建自己的CUDA context，导致同一进程内多套context互相抢占显存。解决方法是推理部分不要和可视化混在同一个进程，要么用独立线程，要么直接把结果保存成图片而不实时显示。

5. TensorRT部署避坑指南：五个高频翻车点与对应解法

5.1 现象：TensorRT转换时提示算子不支持或维度错误

转换ONNX到engine时经常会碰到Assertion failed: dims.nbDims == 4或某个算子找不到实现。第一反应不要怀疑TensorRT版本，而是先看ONNX里有没有动态shape留下的Resize或Gather算子。YOLOv11的导出过程如果开了dynamic=True，会引入几个动态Resize节点。TensorRT对这类节点的处理非常挑剔，如果你的输入尺寸在转换时没有用--minShapes和--maxShapes锁定，解析阶段就会报维度不匹配。

原因：动态shape没有被完整约束导致引擎无法确定张量形状。解决方法是导出ONNX时就固定imgsz，确需动态输入的话，在trtexec里给--minShapes/--optShapes/--maxShapes三组完整参数，且保证batch维度的三个值一致。

# 动态shape转换的正确打开方式 trtexec --onnx=yolov11_dynamic.onnx \ --minShapes=images:1x3x320x320 \ --optShapes=images:4x3x640x640 \ --maxShapes=images:8x3x1280x1280 \ --fp16 \ --saveEngine=yolov11_dynamic.engine

optShapes是性能优化基准，实际运行时输入越接近这个值性能越好；min和max之间的跨度不要太大，跨度越大引擎内的kernel候选越多，构建时间越长。如果业务输入就在640附近，可以直接min=max=opt全部设成640，这是最高效的方式。

5.2 现象：INT8量化后精度大幅下降，检测结果明显变差

INT8校准是回报率最高但也最容易翻车的环节。症状是量化后mAP掉10%以上，甚至检测框消失。原因通常是校准数据集选得不好。默认的校准会从数据里选500张图，如果选的图全是背景占比大的，激活值分布就无法覆盖目标区域，量化比例因子完全偏掉。解决方法是校准集里必须包含所有类别、不同尺度、不同光照的产品图片，且每张图尽量让目标占画面主体。

另外--calib的输入是TensorRT自己会读的batch流，校准时的batch size设置也会影响结果，常见做法是batch设为8到16，校准次数50次。还有一点容易被忽略：如果模型里有一个全局的Sigmoid层，INT8量化会让它精度损失严重，此时可以用--layerPrecisions为这一层指定FP16运行。

# 指定某层单独跑FP16，其余保持INT8 trtexec --onnx=yolov11_int8.onnx \ --int8 \ --calib=/path/to/calibration_images \ --layerPrecisions="Sigmoid:FP16" \ --saveEngine=yolov11_int8.engine

校准集的数量和质量比模型本身更影响最终精度，我一般会在业务现场采集500到1000张图，确保覆盖极端光照和遮挡情况。别急着把校准跑完就收工，量化前后各跑一遍业务测试集，mAP差距控制在2%以内才算合格。

5.3 现象：Jetson上推理速度正常，但CPU占用率居高不下

跑TensorRT时GPU是瓶颈才合理，如果CPU占用率持续95%以上，说明数据通路里出现了严重的CPU瓶颈。最常见的瓶颈是图像解码和颜色空间转换。Jetson上的imread和cvtColor都是CPU实现的，1080p视频流每帧解码就要吃掉几十毫秒CPU时间。解决方法是把图像解码放到GPU上，用cv2.cuda_GpuMat或直接使用v4l2采集的NV12格式输入，让TensorRT的预处理层自己处理格式转换。

另一个CPU占用高的原因是你可能在每个循环里都调用了np.asarray()或np.copy()来转换数据格式，频繁的Python对象创建会触发大量内存分配。优化思路是启动时把输入buffer固定成一个大数组，每帧数据直接写入这个数组的切片位置，完全避免重复分配。全攻略里还有一个建议：把后处理也放到GPU上用CUDA核实现，或者用TensorRT的插件机制把NMS并进engine里，这样CPU占用能压到20%以下。

5.4 现象：模型在PC上TensorRT延迟5毫秒，Jetson上却要30毫秒

同样的engine文件，从X86平台换到Jetson上性能差异巨大是正常的，但差异大到6倍以上就要检查是不是型号选错了。Jetson系列里有不同算力档位，Orin Nano和Orin NX差距明显，Xavier和Orin的架构也不同，老engine在Orin上需要重新转换才能发挥效能。另外Jetson的散热策略会影响GPU降频，如果设备温度超过85摄氏度，GPU频率会被压到一半，延迟自然飙升。

解决方法是切换nvpmodel模式：Orin系列里-m 0是最大性能模式，-m 1是节能模式。跑推理时强制最高性能模式，并保持风扇全速。还有一个隐蔽点：Jetson的CPU和GPU共享LPDDR5内存，如果你的代码里用了太多CPU内存操作，GPU的带宽会被挤占，推理延迟随之上升。尽量把数据通路做成纯GPU完成，CPU只做调度。

# 强制Jetson运行在最大性能模式 sudo nvpmodel -m 0 sudo jetson_clocks --store sudo jetson_clocks --fan

jetson_clocks会把CPU和GPU频率锁定在最高值，但代价是功耗上升和发热加快，长期运行的设备要评估散热条件，否则跑久了同样会降频。要是设备部署在工业现场且没有良好散热，建议锁在性能模式的80%频率上限，用吞吐换稳定，这个取舍在边缘场景里很常见。

5.5 现象：批次推理时显存报错，out of memory但单batch没有问题

多batch推理的显存占用不是batch_size线性增长的，因为TensorRT会给每个优化kernel预留中间缓冲区，实际占用量往往比预期高2到3倍。很多人按单batch显存乘以batch数去预判，结果到batch=8就崩了。原因是不同batch下的kernel策略会同时保存在显存里，TensorRT构建engine时会把所有候选策略的资源都算进去。

解决方法是减小--workspace和限制--maxBatchSize，也可以在构建engine时设置--maxAuxStreams来控制并行流数量。我在Jetson上做8路视频时，用的是两个engine文件：一个batch=4用于日常负载，一个batch=1用于突发高分辨率任务，两个交替加载，这样可以精准控制显存预算。工程上不要试图用一个engine包打天下，多准备两个不同batch的engine文件，用代码控制切换，比反复调整一个universal engine更省心。

6. 验证与进阶：用ncu逐层分析耗时，把性能调优从靠感觉变成看数据

到了这一步，模型能跑、帧率过得去、设备不崩，但如果你想再压榨20%的性能，就得学用工具做细粒度分析。NVIDIA的ncu（Nsight Compute）可以逐kernel查看耗时和占用率，在Jetson上也能跑，只需要安装对应版本的Nsight套件。用法是：先正常跑一遍推理，然后用ncu打开profiling模式，它会输出每个CUDA kernel的执行时间、占用率、访存吞吐。重点看是否有某个卷积kernel的占用率不到50%，如果是，尝试在转换时增加--stronglyTyped约束或调整--builder-optimization-level到5。

我自己的习惯是每条优化改完以后，立刻跑一组固定测试集，记录四个数字：平均延迟、P99延迟、显存峰值、mAP。任何改动只要让mAP掉了超过0.5%就回滚，因为边缘部署的底线是业务精度不能崩。曾经为了把延迟从11毫秒压到9毫秒，我开了INT8量化，结果mAP掉了1.7%，在产线上多了一堆误检，最后不得不把量化层回退成FP16混合精度才解决问题。从那以后，我每次调完参数都强制完整跑一遍验证集对比，宁可慢一点也绝不停留在"看着能跑"的状态。

这份全攻略PDF里还有很多细碎但有用的内容，比如小目标优化的推理尺寸选择策略、多分辨率切换时的显存复用代码、以及不同边缘平台的性能对比表格。你可以先从第5章的避坑清单过一遍，确认自己没踩过这些坑，再按第3章的步骤重新生成一份FP16的engine，用第4章的多batch方式接上实际视频流，最后用ncu做一轮分析。整个过程走下来，你的部署方案会有一个肉眼可见的提升。希望帮到你。

本文还有配套的精品资源，点击获取