YoloV3在Jetson TX2及树莓派部署的性能与运行问题咨询

前置问题：笔记本上用多线程/多进程优化YOLO速度是否可行 #

可行。你可以将视频流读取、图像预处理、模型推理、后处理、结果渲染这几个环节拆分到不同线程/进程运行，避免IO操作阻塞推理流程，可提升10%~30%的整体运行速度。注意核心推理环节为计算密集型任务，单GPU场景下不要给推理模块开多进程，否则会抢占显存和CUDA资源反而导致速度下降。

问题1：不使用加速器、模型压缩等技术，未做修改的YOLOv3能否直接在TX2上运行？ #

不能。原生YOLOv3（416输入分辨率）单batch推理最低需要9~10GB显存，TX2默认显存仅8GB，共享内存模式下最多也只能划分4GB左右给GPU显存，显存不足会直接导致模型加载失败，即使勉强加载完成，推理帧率也会低于1fps，完全达不到可用标准。

问题2：除换用小模型、TensorRT优化、模型剪枝外的其他可行方案？ #

首先解决你遇到的cannot allocate memory in static TLS block报错：该报错不是单纯显存不足导致，是TX2的glibc版本与你使用的深度学习框架（大概率为PyTorch）的静态线程局部存储分配规则冲突，临时解决方法为在运行脚本前添加环境变量：

export LD_PRELOAD=/lib/aarch64-linux-gnu/libgomp.so.1

大部分场景下可直接解决该报错。
其他显存&性能优化方案：

• 降低推理输入分辨率：比如从608降到416甚至320，显存占用可降低30%以上，若精度下降幅度在可接受范围内可直接使用
• 开启FP16半精度推理：TX2的Pascal架构支持FP16计算，直接将模型转为半精度，显存占用直接减半，推理速度可提升30%~50%，精度损失极小
• 推理阶段禁用梯度计算：PyTorch场景下添加torch.no_grad()修饰，不保留中间计算图，可节省大量显存
• 固定batch size为1，不要开启多batch推理

问题3：不用tiny-YOLO的前提下，如何在树莓派/TX2上同时保证检测精度和实时帧率？ #

• 优先使用TensorRT做量化优化：可选择INT8量化，使用你自己的5类目标数据做校准集，INT8量化后推理速度可提升2~4倍，显存占用降低75%，精度损失可控制在2%以内，完全满足多数场景需求
• 选用更新的轻量化检测模型：比如YOLOv5s、YOLOv8n，这类原生小模型的精度远高于旧版tiny-YOLO，在TX2上跑416分辨率可达到20~30fps的实时帧率，完全适配5类目标检测需求
• 树莓派本身算力远低于TX2，建议额外搭配NCS2神经计算棒做推理加速，或使用NNAPI量化部署，可达到10fps左右的可用帧率

问题4：裁剪COCO仅保留所需5类重训同结构YOLOv3，能否提升精度、速度且模型体积不变？ #

该认知部分正确：

• 精度一定会提升：模型仅需要学习5类目标的特征，不会被其余80类的特征干扰，同等训练轮次下你的目标类别AP会有明显提升
• 模型体积确实不变：你没有修改网络结构，卷积层数量、卷积核尺寸均未调整，权重文件大小和原始预训练模型完全一致
• 速度不会有明显提升：推理计算量和类别数几乎无关，YOLO检测头的输出通道仅随类别数做小幅调整，这部分计算量占整个模型的比例不到5%，实际使用中几乎感知不到速度变化，不要指望重训少类模型能提升推理速度

问题5：实时目标检测领域精度最优和速度最优的模型分别是哪些？ #

• 精度最优的实时检测模型（2024年主流方案）：YOLOv8x、YOLOv9e、RT-DETR-X，这类模型在COCO数据集上AP可达55%以上，在高端消费级GPU上可稳定跑30fps以上的实时帧率
• 速度最优的边缘端实时检测模型：YOLOv8n、YOLOv5n、PP-YOLOE-nano，这类模型参数量仅几MB，在低端ARM设备上也可跑到10fps以上，高端GPU上可达到100fps以上的帧率

问题6：MobileNet的性能表现如何？精度和速度是否优于YOLO系列模型？ #

MobileNet本身是通用分类骨干网络，不是完整的检测模型，通常是将YOLO的骨干替换为MobileNet实现轻量化：

• 精度维度：同参数量级下，MobileNet作为骨干的YOLO模型，精度比原生YOLO小模型低2%~5%左右，YOLO原生的CSPDarknet骨干是专门为检测任务优化的，比通用分类出身的MobileNet更适配检测场景
• 速度维度：CPU端上，MobileNet版YOLO的速度比原生YOLO小模型快10%~20%，因为MobileNet的深度可分离卷积更适配CPU计算逻辑；GPU端上原生YOLO速度更快，因为Darknet的卷积结构对GPU并行计算更友好，没有深度可分离卷积的碎片化计算开销

内容的提问来源于stack exchange，提问作者Shabnam