嵌入式系统基础：常见嵌入式平台的硬件架构、算力与内存限制
在嵌入式端部署YOLO目标检测模型，首先需要理解一个核心事实：嵌入式平台不是缩小版的PC服务器，而是以特定硬件架构、严格功耗预算和有限内存资源为约束的专用计算系统。选择错误的平台或忽视硬件特性，往往会导致模型推理速度不达标、内存溢出甚至系统崩溃。本章将深入剖析树莓派、NVIDIA Jetson系列和瑞芯微RK3588这三类主流平台的硬件架构差异、算力特征与内存限制，并给出操作系统选型与开发环境搭建的完整路径。
核心原理：三类平台的硬件架构与算力本质
嵌入式平台的算力并非单一指标，而是由CPU、GPU/NPU、内存带宽和缓存层次共同决定的综合能力。树莓派采用博通SoC，其VideoCore GPU仅用于图形输出，不支持通用计算，因此YOLO推理完全依赖ARM CPU。以树莓派4B的Cortex-A72为例，其单核FP32算力约2.4 GFLOPS，四核并行处理YOLOv5s（约7.2M参数、16.5 GFLOPS）时，理论推理时间约1.7秒，实际考虑访存开销后通常在800ms-1.2秒之间。Jetson Orin Nano则集成了Ampere架构GPU，拥有1024个CUDA核心，支持TensorRT的INT8量化，其40 TOPS算力是树莓派的400倍，但代价是功耗从5W提升至15W。RK3588采用异构计算架构，其NPU包含三个核心，每个核心2 TOPS，支持INT8/INT16混合精度，但NPU对模型结构的支持有限，例如某些自定义激活函数或动态形状操作需要特殊适配。
内存限制是另一个关键维度。树莓派的内存带宽仅约4GB/s，而Jetson Orin Nano的LPDDR5带宽达到68GB/s，RK3588的LPDDR4X带宽约34GB/s。在YOLO推理过程中，输入图像（640×640×3）约1.2MB，第一层卷积输出特征图约4.8MB，随着网络加深，中间张量累积可达数十MB。若模型权重为FP32格式，YOLOv5s需要约29MB存储，INT8量化后降至7.2MB。在树莓派上，内存带宽瓶颈往往比算力瓶颈更早出现，导致CPU无法满负荷运行。
判断方法：根据项目需求选择平台
选择嵌入式平台需要从三个维度建立决策矩阵：实时性要求、模型复杂度、功耗与成本约束。首先明确目标帧率，若需≥30 FPS的实时检测，树莓派基本排除，应在Jetson和RK3588之间选择。其次评估模型规模，YOLOv5s、YOLOv8n等轻量模型在Jetson上可通过TensorRT达到实时，而YOLOv5m或更大模型则需考虑RK3588的NPU是否支持算子融合。最后考虑部署环境，若为电池供电的移动设备，RK3588的5-10W功耗更具优势；若为固定安装的智能盒子，Jetson的CUDA生态更成熟。
实际操作中，建议先使用ONNX Runtime在PC上验证模型正确性，再通过各平台的模型转换工具（TensorRT、RKNN-Toolkit2）进行适配。一个实用的预判方法是：计算模型的理论计算量（GFLOPs）除以平台有效算力（TOPS），再乘以1.5-2倍的效率系数，即可估算推理时间。例如YOLOv5s的16.5 GFLOPs在RK3588的6 TOPS NPU上，理论耗时约2.75ms，实际考虑NPU利用率约50%，预计5-6ms，加上预处理和后处理，单帧总耗时约15-20ms。
案例拆解：从树莓派迁移到Jetson的实战过程
某智能安防项目最初在树莓派4B上部署YOLOv5s进行人员检测，实测帧率仅1.2 FPS，无法满足3 FPS的最低要求。分析发现瓶颈并非CPU算力，而是内存带宽：模型权重29MB，每次推理需从DDR读取全部权重，加上输入图像和中间特征图，单帧内存访问量超过200MB，而树莓派4GB/s的带宽导致访存耗时约50ms，远超计算时间。迁移到Jetson Orin Nano后，首先使用TensorRT的trtexec工具将ONNX模型转为FP16引擎，推理时间从800ms降至35ms；进一步使用INT8量化（需提供校准数据集），推理时间降至15ms。关键操作包括：使用Polygraphy工具分析每层精度损失，对敏感层保留FP16；利用CUDA Graph减少kernel启动开销；通过DeepStream的nvstreammux实现多路视频流批处理。最终在8GB内存限制下，同时处理4路1080p视频流，每路帧率稳定在25 FPS，内存占用峰值约5.2GB。复盘经验：迁移到新平台时，不应只做模型转换，还需重新设计数据流水线，例如使用Jetson的硬件解码器（NVDEC）替代CPU软解，可节省30%的CPU资源。
常见误区与总结复盘
误区一：认为TOPS数值越高，实际推理越快。TOPS是理论峰值，实际性能受限于算子支持度、内存带宽和框架开销。RK3588的6 TOPS在运行YOLOv5s时，若使用未优化的RKNN默认配置，可能比Jetson的40 TOPS慢3倍以上。
误区二：忽略内存共享机制。Jetson的GPU和CPU共享8GB内存，若同时运行多个进程，容易触发OOM Killer。建议使用jetson-stats工具监控内存，并设置CUDA的cudaLimitMaxL2FetchGranularity参数优化缓存。
误区三：在树莓派上盲目追求高精度模型。树莓派无硬件加速，YOLOv5s已接近其算力上限，更应关注模型剪枝和量化，例如使用TFLite的dynamic range quantization可将模型压缩至4MB，推理速度提升2倍。
总结本章核心：嵌入式平台选型需综合算力、内存、功耗和工具链四要素。树莓派适合原型验证和教学，Jetson适合需要CUDA生态的实时应用，RK3588适合成本敏感的多路视频场景。开发环境搭建时，树莓派推荐使用Raspberry Pi OS Lite + Docker，Jetson使用JetPack SDK（包含TensorRT、CUDA、cuDNN），RK3588使用Ubuntu 20.04 + RKNN-Toolkit2。无论选择哪个平台，都应先建立基准测试集（包含不同分辨率、光照条件的图像），在部署前完成精度和性能的双重验证。