Jetson Orin Nano上YOLOv8部署实战：TensorRT加速与性能调优

时间回到我入手 Jetson Orin Nano 的第一个月。当时我已经在 PC 上用 YOLOv8 训练了一套自己的检测模型，信心满满地把代码拷到板子上，以为改个路径就能跑。结果 PyTorch 推理每秒只有两三帧，风扇倒是转得很欢。那一刻我才意识到，边缘设备上做目标检测，真正的分水岭不在于“模型能不能跑”，而在于“模型能不能跑快”。

这篇文章就围绕这个目标展开：从 Jetson Orin Nano 的环境搭建、PyTorch 模型到 TensorRT 引擎的完整转换链路，到 FP16/INT8 量化、批量推理、多流并行这些实打实的调优手段，最后附上我测过的数据对比和踩坑记录。适合手里正好有板子、想把 YOLOv8 真正部署起来的人，也适合正准备选型边缘硬件、想评估这套方案性价比的朋友。我会把每一步为什么要这么做、参数怎么定、出了问题怎么查都讲清楚，尽量让你跳过那些我替你先踩过的坑。

1. 定位这台板子和这个模型：为什么要选这个组合

1.1 Orin Nano 在边缘部署里的“卡位”

Jetson Orin Nano 是 NVIDIA Jetson 家族里的入门级型号，但它和上一代 Xavier NX 之间的性能差距并不小。以 8GB 版本为例，官方标称算力 40 TOPS（INT8 稀疏算力），这个数字在边缘设备里相当能打，关键是它的功耗墙可以从 7W 拉到 15W 甚至 25W，也就是说你能在“省电模式”和“性能模式”之间做选择。我实测下来的感受是：7W 模式下风扇不转、适合长期挂机做巡检；25W 模式下性能明显释放，但散热必须跟上。

选择 Orin Nano 而不是树莓派或 RK3588，核心原因在于 CUDA 生态。YOLOv8 训练和部署中间的转换链路——PyTorch、ONNX、TensorRT，几乎每一步都在 NVIDIA 的地盘里。虽然 RK3588 也有自己的 NPU 工具链，但如果你希望“训练用 GPU、部署用 TensorRT、出了问题社区里一搜就有答案”，Jetson 平台的学习曲线会平缓很多。更关键的是，TensorRT 对 YOLO 系列的支持非常成熟，甚至可以直接把带 NMS 后的输出层一起优化，这是很多边缘 NPU 工具箱目前还做不到的。

1.2 YOLOv8 好在哪：不只是精度提升

YOLOv8 是 Ultralytics 出的检测框架，相比 YOLOv5，它在结构上引入了 C2f 模块和 Anchor-Free 的检测头，训练收敛更快，mAP 也高一些。但从部署角度看，我最看重的是它export命令的完备性。一条命令就能导出 ONNX、TensorRT、CoreML、TFLite，而且导出的 ONNX 结构非常干净，没有乱七八糟的自定义算子，这对后面转 TensorRT 引擎非常重要。

另一个容易忽略的点是 YOLOv8 的模型规格设计。n、s、m、l、x 五个规格里，在 Orin Nano 这种算力介于“够用”和“紧张”之间的设备上，n 和 s 是主流选择。拿 YOLOv8s 来说，参数量 11.2M，输入 640x640，转换成 TensorRT FP16 引擎后在 Orin Nano 上能跑到 40~60 FPS，这个性能足够覆盖绝大多数实时检测场景。如果你有更高的精度要求，可以上 m；如果对速度极度敏感，n 在 INT8 量化后能跑到上百 FPS。

1.3 这套组合适合什么场景

从我接触到的项目来看，Jetson Orin Nano + YOLOv8 最常出现在这几类应用中：一是工业质检，比如基于 YOLOv8 的咖啡豆成熟度检测系统，这一类通常检测目标小、背景杂，需要在 640 甚至 1280 分辨率下跑；二是路口车流量统计系统，对持续运行稳定性要求高，对单帧延迟要求不那么极端；三是移动巡检机器人和无人机，这类场景对功耗和重量敏感，Orin Nano 的 7W 模式就很合适。

还有一个我在帮朋友做的项目是果园成熟度监测，摄像头装在太阳能供电的杆子上，晴天功率够就跑到 25W，阴天降频到 7W，这种动态功耗调整在 Jetson 上实现起来比较顺手。所以选这个组合，本质上是在“生态成熟度”“性能上限”“功耗控制”三者之间找到了一个平衡点。

2. 环境搭建：JetPack 版本决定你后面少踩多少坑

2.1 JetPack 选 5.1.2 还是 6.0

这是整个部署流程里最容易忽略、也最影响后续体验的决策。Jetson 的软件栈不像普通 Linux 那样可以随意装最新版，它要求底层的 L4T（Linux for Tegra）内核、CUDA、cuDNN、TensorRT 必须作为一个整体（即 JetPack）统一升级。你单独装一个最新版 TensorRT，很可能会把整个环境搞坏。

我推荐新手直接选 JetPack 5.1.2，也就是底层带 CUDA 11.4、TensorRT 8.5.2 的版本。原因很朴素：PyTorch 官方为 Jetson 提供的预编译 wheel 对这版支持最成熟，网上能找到的部署教程和踩坑帖子也基本基于这个版本。JetPack 6.0 虽然基于 Ubuntu 22.04、CUDA 12.2，但当时我尝试时发现部分第三方库还没完全适配，比如有些基于 PyTorch 的老项目会出现编译错误。如果你不是特别需要新特性，在 5.1.2 上做部署会顺很多。

# 查看当前 JetPack 版本 cat /etc/nv_tegra_release sudo apt list --installed | grep nvidia-tensorrt

刷机方面，我建议用 SDK Manager 配合原装 USB-C 线刷，别图省事用 SD 卡镜像。SD 卡方式容易出现分区异常、启动黑屏之类的问题，排查起来很费时间。刷完机后第一时间连网线，因为后面要装十几个依赖包，Wi-Fi 不稳定会让你怀疑人生。

2.2 Python 环境与 PyTorch 安装

到手后的系统默认是 Ubuntu 20.04（JetPack 5.x 对应），系统自带 Python 3.8。这里有个原则：不要动系统 Python，用虚拟环境隔离项目依赖。我习惯用virtualenv，不用 conda，因为 conda 在 aarch64 架构上的源不完整，装 torch 经常碰到不兼容。

PyTorch 的安装是整个环境搭建里最“劝退”的一步。Jetson 是 ARM 架构，不能直接pip install torch装 x86 的版本，必须用 NVIDIA 官方为 Jetson 编译的 wheel 文件。这些 wheel 发布在 NVIDIA 官方论坛的 Jetson 板块，文件名格式通常是torch-2.1.0a0+...nv23.06-py3-none-linux_aarch64.whl，注意aarch64这个标识。

# 示例：安装匹配 JetPack 5.1.2 的 PyTorch pip install torch==2.1.0a0+41361538.nv23.06 \ --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v512

安装完 PyTorch 后还要装对应版本的 TorchVision。这里有个特别容易踩的坑：TorchVision 的版本必须和 PyTorch 版本严格匹配，否则导入阶段就会报类似undefined symbol的错。你可以从 NVIDIA 的 wheel 索引里找到对应的torchvision版本，或者直接编译源码。编译源码需要先安装libjpeg-dev、python3-dev这些依赖，大概要十几分钟，但一次装对之后基本不会再出问题。

2.3 验证环境是否正常

装完之后别急着建模型，先快速验证一下 PyTorch 能不能调用 CUDA。很多人在这一步发现 PyTorch 装上了，但torch.cuda.is_available()返回 False，原因通常是 wheel 版本和 JetPack 的 CUDA 版本不匹配。另一种情况是返回 True，但第一次执行 GPU 运算时崩了，那大概率是 cuDNN 动态库路径没配好。

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) # 建议跑一个小的矩阵乘法，确认能真正执行 CUDA 运算 x = torch.randn(1024, 1024, device='cuda') y = torch.mm(x, x) print(y.sum().item())

顺手再装好 ultralytics 包。这里我建议用pip install ultralytics装当前稳定版就行，不用刻意追求最新。你训练模型时用的 ultralytics 版本和板子上部署用的版本最好保持一致，因为不同版本的导出 ONNX 结构可能有差异，后处理逻辑也可能微调过。

3. 模型转换：从 pt 到 TensorRT 引擎的每一步

3.1 为什么要绕道 ONNX

很多人一开始不理解：为什么不能直接把.pt文件放到板子上用 TensorRT 加载？原因是 TensorRT 的输入格式是它自己定义的 engine 文件，它需要先对计算图做“解析、融合、优化”三步操作，才能生成针对特定 GPU 架构的二进制引擎。PyTorch 的.pt文件是基于 Python 对象序列化的，TensorRT 没法直接读；而 ONNX 是计算图的标准中间表示，TensorRT 的原生解析器可以直接消费。

所以标准的转换链路是：.pt→.onnx→.engine。ONNX 在这个链路里起到“翻译官”的作用——它把 PyTorch 的动态图结构固化成静态的计算图，TensorRT 再在这个静态图上做算子融合、精度选择、显存复用等优化。这也是为什么有些人说“TensorRT 的优化是在 ONNX 层面的”，理解这一点，你就知道 ONNX 导得好不好，直接决定了后面 engine 的性能上限。

3.2 导出 ONNX 时的三个关键参数

用 Ultralytics 官方导出命令导出 ONNX 非常方便，但有几个参数值得认真对待。

首先是opset。ONNX 的算子版本要和 TensorRT 解析器匹配，JetPack 5.1.2 自带的 TensorRT 8.5 对 ONNX opset 12~17 都有不错的支持。我建议用 12，因为这是经过最多验证的版本；如果你用了 YOLOv8 的某些新特性，可能要升到 16 或 17，但在 TensorRT 8.5 上偶尔会有算子不兼容的问题。

其次是动态尺寸dynamic=True。如果你不确定部署时的输入分辨率会不会变，比如检测场景需要 640x640，识别场景需要 960x960，动态尺寸可以让你在推理阶段自由指定输入长宽。但代价是引擎的优化不如固定尺寸深入，且会占用更多显存。我的建议是：固定尺寸优先。像做一个固定机位的安全帽检测，输入分辨率永远不变，那就别开动态，性能更好还省显存。

第三个参数是simplify，配合 ONNX-Simplifier 使用。导出的 ONNX 里常常有一些冗余的 reshape 和 transpose 节点，这些不会影响结果，但会给 TensorRT 的解析带来额外开销。用onnxsim简化完后，有些模型构建引擎的时间能缩短三分之一。

pip install onnx onnxsim yolo export model=yolov8s.pt format=onnx opset=12 dynamic=False simplify=True

导出完后建议用onnx.checker检查一下模型完整性，再可视化看一眼计算图结构，确保输出节点的个数和顺序符合你的预期。

3.3 用 trtexec 构建引擎

拿到 ONNX 之后，就可以用 TensorRT 自带的trtexec工具构建引擎了。这个命令行工具是 TensorRT 的瑞士军刀，我能不用代码就不写代码。

/usr/src/tensorrt/bin/trtexec \ --onnx=yolov8s.onnx \ --saveEngine=yolov8s_fp16.engine \ --fp16 \ --workspace=2048 \ --minShapes=images:1x3x640x640 \ --optShapes=images:1x3x640x640 \ --maxShapes=images:1x3x640x640

--fp16是启用半精度推理。TensorRT 会把支持 FP16 的层转换成半精度计算，速度提升明显，而精度损失对检测任务来说通常可接受。--workspace是构建引擎时允许使用的显存上限，单位是 MB，设大一点可以让 TensorRT 尝试更多的融合策略，但注意不是越大越好，构建完引擎后运行时的显存占用和这个参数不直接相关。

引擎构建完成后，trtexec会自动跑一遍推理并输出性能报告，重点看GPU Compute Time和Throughput这两列。我第一次看到 FP16 比 FP32 快了一倍多时，才真正理解为什么大家说 TensorRT 是部署性能的第一生产力。

3.4 TensorRT 推理脚本完整示例

引擎文件是平台相关的，不能跨设备拷贝使用，也就是说你需要在这块板子上构建引擎。构建完引擎后，推理代码就不需要依赖 PyTorch 了，只需要 TensorRT 和 OpenCV。下面是一个最小可运行的推理脚本骨架，我用它跑通了整个流程：

import cv2 import numpy as np import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit class TRTInference: def __init__(self, engine_path, input_shape=(640, 640)): self.input_shape = input_shape self.logger = trt.Logger(trt.Logger.WARNING) with open(engine_path, 'rb') as f, trt.Runtime(self.logger) as runtime: self.engine = runtime.deserialize_cuda_engine(f.read()) self.context = self.engine.create_execution_context() self._allocate_buffers() def _allocate_buffers(self): # 根据 engine 的绑定信息分配输入输出 buffer self.inputs, self.outputs, self.bindings = [], [], [] for i in range(self.engine.num_bindings): name = self.engine.get_binding_name(i) shape = self.engine.get_binding_shape(i) size = trt.volume(shape) dtype = trt.nptype(self.engine.get_binding_dtype(i)) host_mem = cuda.pagelocked_empty(size, dtype) device_mem = cuda.mem_alloc(host_mem.nbytes) self.bindings.append(int(device_mem)) if self.engine.binding_is_input(name): self.inputs.append({'host': host_mem, 'device': device_mem, 'shape': shape}) else: self.outputs.append({'host': host_mem, 'device': device_mem, 'shape': shape}) def infer(self, image): # image 是已经过 letterbox 等预处理的 RGB 图 np.copyto(self.inputs[0]['host'], image.ravel()) cuda.memcpy_htod(self.inputs[0]['device'], self.inputs[0]['host']) self.context.execute_v2(self.bindings) cuda.memcpy_dtoh(self.outputs[0]['host'], self.outputs[0]['device']) return self.outputs[0]['host'].copy() # 使用示例 model = TRTInference('yolov8s_fp16.engine') img = cv2.imread('test.jpg') img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # letterbox 处理 + 归一化 + CHW 格式，省略细节 input_tensor = preprocess(img_rgb, (640, 640)) output = model.infer(input_tensor) # 后处理：解析 1x84x8400 输出，做 NMS，省略细节 boxes = postprocess(output)

注意这个脚本只是骨架，实际使用中要在preprocess里做 letterbox（保持长宽比缩放后填充灰边），并在postprocess里做解码和 NMS。YOLOv8 的输出是1x(4+80)x8400（COCO 80 类），其中 4 是 box 的 cx、cy、w、h，80 是类别概率，这个格式和 YOLOv5 的1x25200x85不一样，写后处理时小心被旧代码带偏。

4. 性能调优：拿到引擎后还能榨出多少性能

4.1 先摸清基线数据

做性能调优的第一步不是上手就调参数，而是先构建一套稳定的基准测试环境。我建议把摄像头输入、图像预处理、NMS 后处理等都固定下来，单独测推理引擎的延迟，再测端到端的延迟，这样才能定位瓶颈究竟在引擎还是在预处理。

我的测试顺序是：先跑trtexec自带的性能报告，拿到纯 GPU 计算时间；然后跑 Python API 推理脚本，看单次推理耗时；最后接上实时视频流，看端到端的 FPS。三步数据一对比，经常能发现“引擎本身只要 15ms，但 Python 里总共花了 40ms”的情况——这种差距通常来自预处理和后处理的 CPU 开销。

在我最初的原生 PyTorch 测试里，YOLOv8s 在 Orin Nano 上推理一帧要 100ms 以上，转成 TensorRT FP16 后降到 20ms 左右，足足五倍差距。这个提升在部署阶段是决定性的，也说明 TensorRT 优化不是“锦上添花”，而是“必选项”。

4.2 FP16 与 INT8：精度和速度的博弈

FP16 是性价比最高的选择，操作简单，收益巨大。但如果你想在 Orin Nano 上跑 YOLOv8m 还要实时，INT8 量化可能是绕不开的路。

INT8 量化的原理是把 FP16 的权重和激活值用 8 位整数表示，计算速度和吞吐量进一步提升，显存占用也降到 FP16 的一半。但它的难点在于需要校准数据集。TensorRT 的 INT8 校准器会统计每一层激活值的数值分布，从而确定量化范围，如果校准数据选得不好，模型的检测精度可能明显下降。

# trtexec 启用 INT8 的方式 /usr/src/tensorrt/bin/trtexec \ --onnx=yolov8s.onnx \ --saveEngine=yolov8s_int8.engine \ --int8 \ --calibrator=/path/to/calib_cache \ --calibImages=/path/to/images \ --calibBatchSize=8

用trtexec做 INT8 时，校准数据一般需要几百张到几千张典型场景的图片。我习惯从训练集里抽 500 张覆盖各种光照、目标大小和遮挡情况的图，保存成校准缓存文件，之后构建引擎都可以复用。第一次跑 INT8 时，建议用同一批测试集对比 FP16 和 INT8 的 mAP 变化。我在一个安全帽检测项目里，INT8 的 mAP 只掉了 0.8%，但速度提升了接近 40%，这种收益在实时场景里非常值得。

不过要提醒的是，INT8 在 YOLOv8 的小模型上表现更稳定。如果你用的是 YOLOv8x，量化后容易出现个别类别召回率骤降的情况，这时候可以用“敏感层保留 FP16”的混合量化方案，但调试成本会上升，新手还是建议先 FP16 跑通。

4.3 输入尺寸与批处理：被忽略的显性调参项

很多人调优时只盯着量化，忽略了输入尺寸这个最直接的旋钮。YOLOv8 的模型在 640x640 下训练，但这不代表部署时一定只能用 640。如果你的目标物偏大、场景简单，比如仓库门口的车牌识别，用 416x416 甚至 320x320 输入，速度能提升近一倍，精度下降却微乎其微。

我在咖啡豆成熟度检测项目里做过对比：640x640 下 YOLOv8s FP16 约 45 FPS，改成 480x480 后能到 70 FPS，检测小目标的能力有一定下降，但对咖啡豆这种中等大小目标影响不大。建议你做一个简单的脚本，把测试集在两个分辨率下各跑一遍，对比 mAP 和 FPS，找到最适合自己场景的平衡点。

批处理是另一个容易被忽略的点。如果你做的是离线分析——比如批量处理一批图片或视频文件，而不是实时摄像头流，可以一次喂入多张图。TensorRT 对 batch size 为 4 或 8 的输入会做更激进的算子融合和显存复用，单张平均耗时能再降一截。但实时推理时我们要的是“单帧延迟”，批处理反而会增加延迟，所以这个方法要分场景用。

4.4 进阶优化：流并行、显存池和 CUDA Graph

当前面几板斧都试过之后，还有几个可以继续榨性能的方向。一个是用多 CUDA stream 实现“采图-预处理-推理-后处理”的流水线并行。在 Orin Nano 这类设备上，CPU 端 OpenCV 的缩放和颜色空间转换往往比 GPU 推理还慢，如果串行执行，每一帧都要等前处理完成后 GPU 才开始算。用两个 stream 交错执行，一帧在做前处理时 GPU 同时推理上一帧，端到端 FPS 能提升 15% 到 30%。

另一个方向是显存池。TensorRT 每次推理都会从显存池中分配输入输出 buffer，如果频繁创建和销毁 CUDA 内存，Host 和 Device 之间的拷贝会成为瓶颈。我的做法是启动时一次性分配固定大小的 buffer，推理过程中复用，实测能减少一点延迟抖动，对视频流的稳定性有帮助。

CUDA Graph 是更新的特性，它可以把一系列 GPU kernel 捕获成一个图，减少 kernel 启动的开销。TensorRT 8.6 之后支持通过--graph或者 API 方式启用。在 Orin Nano 上，kernel launch 的开销相比服务器 GPU 更明显，CUDA Graph 的收益也相对可观，我在某次实验中看到端到端延迟降低了约 5ms。不过它和新版本 TensorRT 的兼容性需要测试，建议等前面所有优化做完后再考虑。

5. 实测对比：一组数据看清每个环节的收益

5.1 不同配置的实测 FPS 表格

我拿 YOLOv8s 在 Orin Nano 8GB 上做了一组相对完整的对比测试，测试图是一段 10 秒的 1080p 道路监控视频，总共 300 帧，统计端到端 FPS（含预处理、推理、NMS 后处理，不含显示输出）。环境是 JetPack 5.1.2、TensorRT 8.5.2、25W 性能模式。数据可以作为参考，不同批次的板子、不同散热条件会有差异。

5.2 读了数据之后该怎么定自己的方案

这组数据告诉我们：同样一块板子，不同配置下的性能差距可以超过十倍。所以部署前一定要先问自己三个问题：检测目标最小尺寸是多少？可接受的单帧延迟是多少？类别数量和误检代价有多大？

如果在室内做安防检测，目标不会太小，帧率又要求尽量高，我建议直接冲 480x480 + INT8，100 FPS 以上做实时交互体验会非常好。如果做无人车的行人检测，目标大小变化大、误检代价高，保守起见用 640x640 + FP16 就好，INT8 可以等收集到足够多的现场数据后，做充分验证再切换。

还有一个经验分享：在正式方案里要留出 30% 的性能余量。因为测试视频和真实场景的复杂度不同，真实场景里目标数量多、光照变化大，后处理耗时和模型推理耗时都可能上涨。如果测试时已经顶着 100% 算力跑，上线后很可能被突发情况拖垮。

6. 踩坑记录：部署中那些大概率会卡住你的问题

6.1 推理结果全是零或乱框

这是 TensorRT 部署 YOLOv8 时最经典的问题——引擎构建成功，推理也不报错，但输出的检测框要么全是 0，要么框的位置完全对不上。排查了一圈才发现，问题几乎总出在预处理和后处理的“不一致”上。

我在做 YOLOv8s 转换时，有一次拿 YOLOv5 的预处理代码就直接用了。YOLOv5 做 letterbox 时默认填充的是灰色 114，而 YOLOv8 的预处理默认 BGR 转 RGB 后还要除以 255 归一化，顺序不对，结果完全跑偏。还有一次是输出张量的维度问题：YOLOv5 的输出是1x25200x85（已经解码好的框），YOLOv8 的输出是1x84x8400（需要先转置再解码），我在解析时沿用旧逻辑，导致框的数据错位。后来我总结了一个排查顺序：先打印输出 tensor 的 shape 和数值范围，再逐项对比预处理步骤，最后在 PC 上用 ONNX Runtime 跑同输入对比输出，基本十分钟内能定位。

6.2 构建引擎时报 Unsupported Operation

TensorRT 构建引擎时报Unsupported Operation也是高频问题。实际上 YOLOv8 模型里几乎没有生僻算子，绝大多数情况是 ONNX 导出时带了冗余的节点，或者 opset 版本和 TensorRT 解析器不兼容。

一次我在用最新版 ultralytics 导出 YOLOv8m 时，默认 opset 是 17，TensorRT 8.5.2 对其中某些新算子支持不完整，构建到一半直接失败。解决办法是把 opset 降到 12 重新导出，问题立刻消失。遇到这种报错，别急着怀疑模型结构，先检查 opset 和 onnxsim 简化，绝大多数问题都能解决。如果实在不行，可以在 TensorRT 构建时加--verbose参数，它会打印出具体是哪个节点、哪一层算子不支持，按图索骥去源头处理。

6.3 新板子黑屏和系统异常

“Jetson Orin Nano 启动后黑屏”这个标题让我印象很深，因为我自己也遇到过。当时以为是板子坏了，折腾了很久才发现是电源问题。Orin Nano 对电源要求不算苛刻但也不能马虎，官方要求 DC 电源至少 15W，25W 模式必须接 5A 的电源，我用了一个勉强达标的 4A 电源，一进高负载就黑屏重启。

另一个经典情况是 SD 卡刷机后第一次启动黑屏。这个问题很大程度是烧录工具的问题，我后来都改用 SDK Manager 线刷，不再用第三方工具做 SD 卡镜像。如果你手头只有 SD 卡方案，尽量用官方推荐的 Etcher（国内网络不方便下载时可以用开源的 dd 命令替代），烧录完第一次启动耐心等 3 到 5 分钟，别急着强制关机。

6.4 常见报错速查表

最后再分享一个提升调试效率的习惯：每次修改模型或参数前，先用 Git 记录一下当前的 engine 文件和测试脚本的版本。TensorRT 的 engine 文件不像模型权重那样可以随时重新生成，构建一次可能要好几分钟，而且和特定板卡、特定 TensorRT 版本绑定。哪天发现性能异常或结果不对，能快速回滚到上一个正常版本，会省下很多翻来覆去排查的时间。