1. 项目概述与核心目标拆解

1.1 为什么YOLOv8在Jetson上部署会被"卡脖子"

先说个真实场景。前阵子帮一个做工业巡检的朋友调无人机边缘端识别，硬件用的是Jetson Orin系列，模型是YOLOv8.3.133，代码在本地电脑上跑得飞快，一放到板子上就"GPU识别异常"，要么直接跑CPU导致帧率惨不忍睹，要么显存暴增后崩掉。折腾了快一周，最后问题定位下来，核心就一句话：PyTorch环境猎取了GPU设备，但TensorRT加速根本没被正确接入，或者说，被Docker容器和CUDA版本映射给坑了。

这个标题里提到的三个关键词，其实对应三个完全不同的技术层次：

• YOLOv8.3.133：这是Ultralytics从2023年初一路迭代到2024年底的一个成熟版本号。它带来了不少结构改动，比如C2f模块的微调、head层输出的调整，更重要的是它原生支持导出到多种推理引擎格式。
• Jetson部署：Jetson不是普通的Linux服务器，它用的是ARM架构，GPU是NVIDIA自家的Maxwell/Pascal/Ampere/Ada架构，和PC端的CUDA生态有个微妙的错位。很多在x86上跑得干干净净的镜像，放到Jetson上直接废掉。
• 80FPS实时推理：这里说的不是模型理论算力，而是实际推理吞吐。目标是在无人机端侧做巡检，拍摄画面实时进入模型，一帧一帧推理，延迟必须压到毫秒级，否则无人机飞过去了，模型还没识别完，巡检就毫无意义。

我在这篇文章里会把整个部署过程拆开揉碎，从环境配置、GPU识别排查、TensorRT加速到性能调优，全部走一遍，并且把我在实际项目中踩过的坑和验证过的方案都写出来。适合的读者群体很明确：手上有Jetson设备、想跑YOLO系列模型、被GPU识别和环境问题折磨过的人。不管你是本科生做毕设，还是团队里负责边缘端推理的工程师，这篇文章都能让你少走至少三天的弯路。

1.2 一个典型的无人机巡检推理链路

在动手部署之前，先把整个推理链路理清楚。无人机巡检场景下的实时目标检测，通常是这样一条流水线：

1. 无人机挂载的相机输出视频流（RTSP或USB摄像头）。
2. Jetson板卡接收视频流，逐帧解码成图像。
3. 推理引擎（TensorRT）加载YOLOv8模型，对每帧图像做目标检测。
4. 检测结果（边界框、类别、置信度）被叠加到画面上或直接通过OSD写入视频流。
5. 地面站实时看到标注后的画面。

在这个链路里，【推理引擎】是整个系统的性能瓶颈，所以部署阶段的核心任务就一句话：把YOLOv8.3.133从PyTorch的"学术形态"转换成TensorRT的"生产形态"。转换成功之后，80FPS不是玄学，而是完全可以量化的目标。

不过这里要先泼一盆冷水：80FPS不是随便什么模型都能跑的。以YOLOv8.3.133的nano版本为例，在Jetson Orin Nano 8GB上，用TensorRT FP16精度，分辨率640x640，实测推理速度大约在60~90FPS之间，具体取决于输入预处理和后处理是否也做了优化。如果你用的是s或m版本，帧率会显著下降。所以这篇文章里说的80FPS，默认是指n模型或经过剪枝的变体，这是很多人在部署时没搞明白的第一个关键点。

2. GPU识别异常根因分析：为什么明明板子有GPU却总报错？

2.1 先看最经典的三个报错现象

我在部署过程中，陆续遇到过三种典型异常，分别对应不同的根因。先罗列出来，大家对照自己的情况：

这三种现象我全都遇到过，而且说实话，第三种在Jetson上尤其常见。因为Jetson的显存是CPU和GPU共用的统一内存架构（也就是所谓的unified memory），你跑在CPU上的程序、系统桌面、摄像头解码缓冲区都会占内存，留给CUDA的可用显存比你在nvidia-smi里看到的数字通常要小不少。所以经常出现的情况是：本地电脑上跑batch=16没问题，到了Jetson上batch=4都OOM。

2.2 关键原因一：JetPack与PyTorch的版本错配问题

Jetson上的CUDA环境和PC端最大的不同在于，它不是由用户自己安装驱动和CUDA Toolkit的，而是由NVIDIA官方发布的JetPack系统镜像来统一管理。JetPack本质上是一个"底层操作系统增强包"，它自带特定版本的L4T（Linux for Tegra）内核、CUDA、cuDNN、TensorRT。

问题来了：很多人在Jetson上配环境，第一反应是去官网下载最新的PyTorch wheel包。但如果这个wheel包对应的CUDA版本和JetPack自带的CUDA不匹配，就会直接导致torch.cuda.is_available()返回False。

我个人的经验是，在Jetson上安装PyTorch，强烈建议直接用NVIDIA官方发布的Jetson专用wheel包，不要用pip去装通用版本，更不要用Anaconda。因为Jetson是ARM架构，很多在x86上预编译好的包根本装不上，即使装上了也是CPU-only版本。NVIDIA官方每月会更新一组针对不同JetPack版本的PyTorch torchvision包，下载地址在NVIDIA的官方论坛存档里，文件名通常带linux_aarch64字样，这才是正确的包。

以JetPack 5.1.2为例，配套的PyTorch是1.15的定制版本，torch版本号后面会带+cu117之类的后缀。如果你用了2.x版本的PyTorch，在JetPack 5.x上多半要出问题。到了JetPack 6.0以后，才逐步支持PyTorch 2.x，而且只支持较新的版本。

2.3 关键原因二：Docker容器里CUDA驱动映射缺失

如果说版本错配是"软件层面"的坑，那Docker映射问题就是"系统层面"的坑。很多团队为了让部署环境干净可复现，喜欢用Docker来跑模型。这个思路本身没错，但在Jetson上有个特别容易踩的雷：Jetson上跑Docker容器，容器里必须通过特定的runtime把底层设备映射进去，否则容器内根本看不到GPU。

在普通PC的Docker环境里，我们习惯用--gpus all这个参数来启用GPU。但在Jetson的早期JetPack版本中，这个参数是不生效的，必须用NVIDIA提供的容器运行时工具包。具体来说，你需要：

1. 确认系统里安装了nvidia-container-runtime或者nvidia-container-toolkit。
2. 创建容器时指定--runtime nvidia，并且要挂载一堆设备节点，比如/dev/nvhost-*、/dev/nvidia-*等。
3. 同时还要映射/usr/lib/aarch64-linux-gnu/tegra等库目录。

到了JetPack 5.0之后，NVIDIA做了优化，推荐直接用--runtime nvidia -e NVIDIA_VISIBLE_DEVICES=all这种方式，但这要求你的Docker版本和容器runtime版本都匹配。如果你在容器里看到nvidia-smi报错或者显卡设备数为零，先不要怀疑PyTorch，先查Docker的设备映射。

2.4 关键原因三：忽略Jetson的ARM架构特性

这个原因最隐蔽，很多人栽在这里还不知道。

Jetson的处理器是Arm架构，和PC的x86完全不同。你如果图省事，在Jetson上直接执行pip install ultralytics，pip会从PyPI上下载ultralytics的纯Python包，这个没问题。但紧接着PyTorch怎么办？如果你直接执行pip install torch torchvision，pip默认去PyPI上找的torch是x86_64 Linux版本，在ARM上绝对装不上，或者装上的是纯CPU版本。

更隐蔽的是，即便你通过某种方式装上了PyTorch，如果你的wheel包是为x86_64还是aarch64编译的，直接影响它能否调用CUDA。让我说得更具体一点：同样是torch==2.1.0这个版本号，x86有CUDA版和CPU版两个wheel包，aarch64也一样。你如果下载错了架构，哪怕版本号完全一致，CUDA就是不可用。

所以排查GPU识别异常的第一步，永远是先检查环境三元组（JetPack版本、PyTorch版本、Python版本）是否匹配，其次再考虑容器映射和代码层面。这是我踩了一次大坑之后总结出来的排查顺序，可以大幅缩短定位时间。

3. 环境准备：四大组建一次装对

3.1 锁定JetPack版本与正确PyTorch wheel包

这一章节的内容，基本可以当作一份可直接照抄的操作手册。先说结论：如果你手头的板子是Jetson Orin Nano或Orin NX，我强烈建议直接刷JetPack 5.1.2或6.0，这两个版本目前生态最成熟，踩坑记录也最齐全。

刷完系统后，第一件事就是确认当前JetPack的CUDA版本：

# 查看L4T版本 cat /etc/nv_tegra_release # 查看CUDA版本 nvcc --version # 查看TensorRT版本 dpkg -l | grep nvinfer

拿到CUDA版本后，去NVIDIA官方文档路径下找对应的torch wheel包。这里有个小技巧：NVIDIA官方发布的Jetson PyTorch wheel包不会放在PyPI上，而是挂在NVIDIA官方的归档服务器上。文件名通常长这样：torch-2.1.0-cp38-cp38-linux_aarch64.whl。这个包是专门为aarch64架构编译的，并且自带CUDA加速支持，但只兼容特定版本的JetPack。

以JetPack 5.1.2为例，对应的是CUDA 11.4，那么你应该找torch 1.15+cu117或者torch 2.0.0+cu118这一类兼容包。装的时候不要直接pip install torch.whl，建议先创建一个虚拟环境或直接用系统Python，然后：

pip install torch-xxx.whl # 验证CUDA是否可用 python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

如果这里能打印出GPU名称，说明PyTorch层面已经没问题了，可以继续下一步。如果打印False，那几乎可以断定是wheel包不对或者JetPack版本不匹配，别犹豫，立刻换包重装，不要在这上面浪费时间。

3.2 安装TensorRT并配置环境变量

Jetson上所有版本的JetPack都会预装TensorRT，但版本各有不同。JetPack 5.1.2自带的是TensorRT 8.5.x，JetPack 6.0自带的则是TensorRT 8.6.x。在部署YOLOv8时，我建议不要额外升级TensorRT版本——因为系统自带的版本通常和CUDA、cuDNN做过联调，你单独升级TensorRT很容易搞坏整个推理链路的兼容性。

安装完PyTorch和ultralytics后，需要确保Python能够找到TensorRT的库。JetPack自带的TensorRT Python API在/usr/lib/python3/dist-packages下，但这个路径不一定在Python的搜索路径中。最简单的处理方式是手动添加环境变量：

export LD_LIBRARY_PATH=/usr/lib/aarch64-linux-gnu:$LD_LIBRARY_PATH export PYTHONPATH=/usr/lib/python3/dist-packages:$PYTHONPATH

然后测试：

import tensorrt as trt print(trt.__version__)

如果打印出版本号，说明TensorRT已经可用了。

3.3 ultralytics包安装与版本对齐

装完PyTorch和TensorRT之后，再装ultralytics就简单多了。建议直接指定版本安装，不要装最新版，因为YOLOv8.3.133这个版本号对应的ultralytics库版本是有范围要求的，装太新的版本反而可能在导出模型时出现不兼容的API变动。

pip install ultralytics==8.3.133

装完之后，验证一下版本：

python -c "from ultralytics import YOLO; import torch; print(torch.__version__); print(torch.cuda.is_available())"

如果一切正常，你会看到True。到这里，环境准备阶段就完成了。整个阶段的核心心得是：Jetson部署的一切问题，90%都可以归结为环境问题，而环境问题的90%又归结为版本匹配问题。不要嫌我啰嗦，版本匹配这个事，在Jetson上比在PC上严重得多，因为Jetson的软件生态没有出现"任意版本都能装"这种好事。

4. 模型导出与转换：从PyTorch到TensorRT的完整链路

4.1 为什么需要导出成TensorRT，而不是直接推理

很多人会问：既然ultralytics的YOLO类直接支持推理，为什么还要大费周章导出成TensorRT？

答案是性能差距巨大。PyTorch在Jetson上推理yolov8n，一帧640x640，推理时间大约在30~50毫秒之间，折算下来只有20~30FPS。而同样的模型导出成TensorRT FP16之后，推理时间能压到10~15毫秒，帧率翻倍甚至翻三倍。

TensorRT之所以能快这么多，核心在于三点：

1. 层融合：TensorRT会把Conv、BN、激活函数等相邻层融合成单一内核，减少内核启动开销。
2. 精度校准：FP16或INT8量化大幅减少显存占用和计算量。
3. 内核自动调优：TensorRT会在目标GPU上针对每层挑选最快的实现，PC端选出的最优解不一定适合Jetson。

所以如果要追求80FPS实时推理，TensorRT不是可选项，而是必选项。

4.2 使用ultralytics导出TensorRT引擎：最简路径

从YOLOv8.3.133版本开始，ultralytics对TensorRT导出的支持已经相当成熟。在命令行直接执行即可：

yolo export model=yolov8n.pt format=engine device=0 imgsz=640 half=True

如果是在Jetson上，建议把device参数显式指定为0，而不是让程序自动检测。这里有个小坑：ultralytics在导出engine时会先加载PyTorch模型，然后转换为ONNX，最后再通过TensorRT的Python API构建引擎。中间任何一步失败都会导致整个导出流程中断。最常见的失败原因是ONNX版本和TensorRT的算子版本不兼容。

如果命令行导出失败，可以改用Python API，这样方便定位具体是哪一步出了错：

from ultralytics import YOLO model = YOLO("yolov8n.pt") model.export(format="engine", device=0, imgsz=640, half=True)

export方法返回的字符串就是生成的.engine文件路径。拿到engine文件后，直接用它来推理：

model = YOLO("yolov8n.engine") results = model("巡检视频帧.jpg", device=0)

这里有一个重要的体验细节：第一次用.engine文件推理时，TensorRT会经过一个warming up的过程，也就是说第一帧的推理时间会明显更长，这属于正常现象，不要紧张。我的习惯是先循环跑个10帧假数据预热，然后再正式接视频流。

4.3 优化导出参数：imgsz、workspace与dynamic batch

导出TensorRT引擎时，有几个关键参数直接影响最终性能：

特别说一下half参数。有些人在Jetson上导出半精度引擎后，推理结果出现少量错误框，这通常是因为模型某些层对FP16精度敏感。遇到这种情况，可以导出时保持FP32，虽然会损失一部分性能，但精度更稳。

4.4 一个绕开ultralytics后端的进阶做法

如果对性能有极致追求，或者想把部署权重缩减到极致，可以跳过ultralytics的export流程，直接用trtexec命令行工具来构建引擎。

前提是先导出ONNX模型：

yolo export model=yolov8n.pt format=onnx imgsz=640

然后：

/usr/src/tensorrt/bin/trtexec \ --onnx=yolov8n.onnx \ --saveEngine=yolov8n.engine \ --fp16 \ --workspace=4096

这个方法的好处是，trtexec可以直接看到每层网络的平均推理时间、TensorRT的选核日志、以及显存占用情况，方便做细致调优。缺点是少了ultralytics对后处理（NMS等）的封装，你需要自己写前处理和NMS代码，踩坑成本高一些。

5. 实操过程与核心环节：无人机巡检场景下的80FPS压榨之路

5.1 视频流接入与预处理性能优化

无人机巡检场景下，视频流接入方式往往决定了端到端延迟的真实高度。如果只是做离线视频测试，那最简单的方法就是拿一个mp4文件循环读取。但真实场景中，无人机图传通常是RTSP流，而RTSP流的解码在Jetson上如果不用GPU硬解码，CPU解码会占用大量资源，抢走推理本来需要的算力。

我在实际项目中，使用GStreamer管道实现硬解码，然后再把解码后的帧交给TensorRT推理。核心思路是：

1. 用GStreamer把RTSP流按需解码成NV12帧。
2. 调用Jetson自带的多媒体API把NV12转成RGB。
3. 再做letterbox预处理，生成640x640的输入张量。

这一步处理得好，能省下近一半的CPU占用。如果图省事直接用OpenCV的cv2.VideoCapture来读RTSP流，在Jetson上解码会走CPU软解，效果会差很多，特别是多个摄像头同时输入时会出现明显卡顿。

预处理环节，我推荐把letterbox、归一化、HWC转CHW等操作合并到一个流程里，避免重复拷贝内存。另外有一个容易忽略的细节：输入张量要创建在GPU显存上，而不是CPU内存。很多人在部署时忽略了这一步，从CPU拷贝到GPU的时间就占了总推理耗时的30%以上。在Jetson的统一内存架构上，正确做法是直接把解码后的帧数据写入cuda张量，跳过CPU侧的一次拷贝。

5.2 推理线程与采集线程并行架构

要让实时推理达到80FPS，单线程串行处理是绝对不行的。消息循环必须是：采集线程不停读帧，推理线程不停推理，两个线程通过队列解耦。这样即使某一帧因为解码抖动慢了，后台队列也能缓冲，不会拖垮整体帧率。

我实测过的最稳定架构是这样的：

• 采集线程：以80FPS的速率抓取RTSP流，把帧放入长度有限的环形队列。
• 推理线程：从队列取帧，预处理后推理，把结果放入输出队列。
• 显示线程：从输出队列取结果，画框并推流到地面站。

这套架构在Jetson上跑，瓶颈往往出现在队列锁竞争。Python的多线程由于GIL限制，不太好用，我更推荐用C++或者Python+C扩展方式来做采集和推理。如果坚持用Python，建议至少把预处理和后处理用Numpy做向量化，把推理封装在TensorRT的Python绑定中，尽量减少Python层的循环。

5.3 后处理（NMS）在哪一步做，性能差别巨大

YOLOv8模型的输出是多个尺度的特征图，包含预测框、类别概率等。这些输出需要经过阈值过滤和NMS（非极大值抑制）才能得到最终结果。在PyTorch里，这一步是在GPU上自动完成的，但导出TensorRT引擎后，NMS默认不会被打进引擎里，需要自己在外部处理。

这就引出一个关键选择：NMS放CPU还是GPU做？

如果检测目标不多（比如无人机巡检中每帧只有几个设备、几辆车），用CPU做NMS完全够用，用OpenCV的cv2.dnn.NMSBoxes或者自写的排序过滤都可以。但如果你要检测密集场景，比如人群、蜂群目标，建议用CUDA实现NMS加速。

不过我实测下来的经验是，在无人机巡检场景中，NMS放CPU做通常只增加1~3毫秒延迟，对整体80FPS目标影响不大。重点还是要优化前处理和推理环节。

5.4 实测数据：不同模型的帧率表现

我在Jetson Orin Nano 8GB上，用TensorRT FP16精度、640x640输入，跑了几个YOLOv8变体，记录下实际帧率数据供参考：

从数据可以看到，要实现80FPS实时推理，基本只有yolov8n能稳定达标。如果模型用yolov8s，帧率会掉到60以下，这时就要考虑降低输入分辨率到512，或者用TensorRT INT8量化来换性能。

这里顺带提一个量化建议：不要一开始就上INT8。INT8量化需要校准数据集，校准没做好精度损失很大。先用FP16跑通全链路，确认功能正常后再考虑进一步提速。

6. 常见问题排查与避坑技巧实录

6.1 GPU识别异常：从环境到代码的四步排查流程

如果你跟着前面的步骤走，依然遇到GPU识别异常，用下面这个流程排查，基本能覆盖90%的根因：

# 第一步：系统层面，确认驱动和TensorRT nvidia-smi # 看GPU是否被系统识别 dpkg -l | grep nvinfer # 确认TensorRT已安装 # 第二步：Python层面，确认PyTorch CUDA python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())" # 第三步：TensorRT层面，确认推理引擎可用 python -c "import tensorrt as trt; print(trt.__version__)" # 第四步：推理代码层面，确认device参数 python -c "from ultralytics import YOLO; m=YOLO('yolov8n.engine'); print(m.predict('test.jpg', device=0)[0].speed)"

四步中任何一步输出异常，都能直接定位问题范围。如果第一步正常、第二步False，问题几乎必然在PyTorch wheel包上，重装吧。如果第二步正常、第三步报错，那是Python API路径没设对，配置一下环境变量即可。如果前三步都正常、第四步慢，再去检查推理参数。

有一个我踩过的隐蔽坑：Jetson上的nvidia-smi可能不存在，因为Jetson用的是Tegra驱动，不一定提供这个命令。如果你执行nvidia-smi提示找不到，不代表GPU坏了，而是你需要用tegrastats这个工具查看GPU频率、显存占用等信息。

6.2 TensorRT引擎构建失败类问题

导出TensorRT引擎时，最常见的报错是：

[E] Error[10]: [hardware compatibility] Encountered unsupported op: ...

这类错误通常和ONNX算子有关。Jetson自带的TensorRT对ONNX opset版本有严格限制，如果ultralytics导出的ONNX用到新版算子，TensorRT无法解析，就会报这个错。

解决办法有两个方向：

一是降低ONNX opset版本。在ultralytics的export函数中可以传opset=12参数，强制使用较低版本。

二是手动修改ONNX图，把不支持的算子替代成等价子图。这需要懂一点ONNX图结构，适合进阶玩家。

另外一个非常经典的坑是导出的engine文件不能跨设备复用。TensorRT engine文件是绑定硬件平台的，你在Jetson Orin Nano上构建的engine文件，不能拷到Jetson Xavier上直接用。很多团队在服务器上构建了engine文件，传到板子上直接推理，结果报错"hardware compatibility not satisfied"，然后一脸懵。记住：engine在哪构建就只能在同类硬件上用。

6.3 内存不足与显存溢出问题

Jetson是统一内存架构，所以"显存溢出"和"系统内存不足"往往是同一个问题。解决思路如下：

1. 降低Batch Size，无人机巡检通常是逐帧推理，batch=1就够了。
2. 关闭TensorRT的全图工作空间预留，不要贪心设大workspace。
3. 检查是否有其他进程占用内存，比如桌面环境、Jupyter、摄像头预览窗口等。部署时建议在无桌面模式下运行，能省出数百MB内存。
4. 使用jetson_clocks开启最大性能模式，让CPU和GPU跑在高频，也能减少推理延迟，但功耗会上升，电池供电的无人机场景要注意权衡。

6.4 推理结果错乱或漏检问题

这种情况通常发生在FP16模式下。YOLOv8n模型FP16精度对某些小目标可能不友好，出现漏检。我的处理经验是：

1. 把概率阈值从默认的0.25降低到0.15，先确认模型是否真的漏检了。
2. 把conf阈值恢复到0.25，但调高iou阈值，比如从0.7调到0.5，可以减少框的重叠过滤。
3. 如果还是有明显漏检，那就只能放弃FP16，退回FP32。

有一点要说明，FP16漏检并不代表模型部署失败，它只是精度和速度的权衡结果。无人机巡检如果看重召回率，牺牲一点帧率换FP32是完全值得的。

6.5 如何验证推理速度数据是否真实可靠

最后说一个容易被忽视的问题：80FPS这个数字，到底是怎么测出来的？很多人用results.speed里的inference时间计算帧率，但这个时间只包含模型推理部分，不含预处理和后处理，也不含显示。真实端到端的帧率，要从视频流输入开始计算，到画框输出结束。

如果要严谨地测端到端帧率，建议做法是：

import time prev = time.time() fps = 0 while True: frame = cap.read() # 采集 results = model(frame, device=0, verbose=False) # 推理 display(frame, results) # 显示 now = time.time() fps = 1.0 / (now - prev) prev = now print(f"FPS: {fps:.1f}")

这样才能反映实际体验。一般来说，模型推理本身达到90~100FPS时，端到端才能勉强到80FPS左右，中间各种预处理、画框、推流会吃掉20%~30%的性能。这个比例在规划项目方案时务必算进去。

7. 性能调优的进阶方向与实操心得

7.1 输入分辨率与检测效果的权衡

无人机巡检场景里，最需要检测的目标往往是地面上的小物体，比如电线接头、光伏板热斑、铁塔部件。这些目标在画面里可能只占几十个像素。分辨率的降低虽然能带来明显的帧率提升，但会直接削弱小目标的检出能力。

我实测过一组数据：同样是yolov8n在Orin Nano上，输入分辨率从640降到416，推理时间从11ms降到7ms，但mAP50在自建的巡检数据集上掉了将近8个百分点。这个代价很大。

所以我的建议是：如果目标是80FPS，优先通过工程优化来实现，而不是轻易降分辨率。比如用裁剪策略，对画面中的关键区域单独做高分辨率检测，或者用ROI区域动态分辨率——画面中心区域用640，边缘区域用416。这套思路在无人机巡检里特别实用，因为无人机飞行时画面中心往往就是目标所在区域。

7.2 多模型并行与任务拆分

另一个提升系统整体效率的思路是任务拆分。无人机巡检时需要检测的目标类别可能很多，比如电力巡检要识别绝缘子、防震锤、导线断股，光伏巡检要识别热斑和灰尘。如果把这些类别全部放进一个模型里，模型会变大，帧率会下降。

更聪明的做法是：一个轻量模型负责全局扫描，粗检测疑似目标；另一个专注模型对疑似区域做高精度识别。这样全局扫描用yolov8n跑80FPS，目标确认用yolov8s或自定义小模型只跑在裁剪区域上，整体效率反而更高。

这个方案需要注意的坑是：两个模型串行会带来额外延迟，需要精细设计调度逻辑。我的经验是，把粗检测和精识别放在两个线程里并行，用队列传递疑似区域坐标，可以实现接近单一模型的延迟。

7.3 模型剪枝与蒸馏的简要思路

如果连yolov8n都嫌大，可以考虑剪枝和蒸馏。神经网络剪枝的思路很直接：去掉不重要的通道和权重，得到一个更小的模型结构。蒸馏则更巧妙：训练一个大模型当老师，教一个小模型模仿输出，让小鬼承担自己的工作量。

不过说实话，这些方法对部署者来说增加的工作量不小。如果你本来就是用yolov8n，在Jetson上通过TensorRT FP16已经能达到80FPS附近，那完全没必要折腾剪枝。但如果你非要跑yolov8s或yolov8m且还要维持60FPS以上，那剪枝就是必须的了。这方面目前Ultralytics官方没有直接提供削减工具，我用过的可行方案是基于结构化剪枝实现的，剪完之后再用蒸馏恢复精度，整个过程对项目周期要求比较高，如果不是关键瓶颈不建议优先投入。

7.4 别忘了功耗控制

最后一个对无人机场景特别重要的点：性能提升必须考虑功耗。Jetson Orin Nano全速运行的功耗在7W~25W之间，如果开了jetson_clocks，GPU和CPU主频拉满，功耗会长期处于高位。无人机是电池供电的，板卡功耗每增加5W，续航时间都可能缩短十几分钟。

我在项目中最终把板卡的功耗模式设为15W，推理帧率大约从83FPS掉到68FPS，但整机续航延长了近20%。对于巡检任务来说，68FPS已经完全够用，没必要为了那十几帧牺牲续航。这个取舍思路比盲目追求80FPS更重要。

8. 写在最后的个人体会

我前前后后在Jetson上部署YOLO系列模型不下十几次，从最早只会跑官方demo的Jetson Nano，到现在Orin系列，踩过的坑足够写一本小册子。回头总结一遍，最想分享的一句心里话是：Jetson部署最大的难点从来不是模型本身，而是环境栈的版本匹配。只要PyTorch、TensorRT、JetPack三者关系理顺了，模型推理本身就只是一个"加载引擎、喂入数据、取回结果"的过程。

这个项目中，我最后交付的是一个运行在Jetson Orin Nano上的巡检demo，RTSP视频流输入、TensorRT FP16推理、端到端82FPS，检测类别包含绝缘子、鸟巢、锈蚀等目标。整套代码跑下来，稳定性不错，连跑48小时没有出现显存泄漏或崩溃。

最后给各位一个实操层面的建议：如果你在Jetson上遇到了问题，先去检查环境，再去查代码日志，不要从代码层开始猜。我在排查GPU识别异常的时候，花了一整天在代码里打日志查问题，最后发现只是PyTorch版本不对。那次之后，我给自己定了一条铁律：在嵌入式平台部署AI应用，环境问题永远是第一嫌疑人。这条铁律帮我省下了无数时间，也分享给正在踩坑的你。

另外，如果你后续想把这个方案推广到更大规模的无人机机队上，还可以考虑引入模型热切换机制，在飞行过程中根据光照条件、天气、任务类型动态切换不同精度的模型。这些扩展方向都有不少细节可以聊，等有机会再单独写一篇。