1. 从“All in AI”到“走向边缘”一个嵌入式老兵的真实观察这两年“All in AI”的口号喊得震天响大模型训练集群动辄上万张卡云端推理服务卷到毫秒级延迟。但我身边不少做了十年上下的嵌入式工程师反而越来越焦虑云端那套东西离自己太远手里的MCU、RTOS、交叉编译工具链好像一夜之间成了“传统行业”。直到边缘AI真正落地——智能门锁要本地人脸识别、工业相机要实时缺陷检测、车载座舱要离线语音唤醒——大家才反应过来原来AI的最后一公里恰恰是嵌入式工程师的主场。这篇文章不打算给你灌“转型成功学”的鸡汤而是把“嵌入式工程师如何切入边缘AI”这件事拆开揉碎从硬件平台选型Jetson、Rockchip到底怎么选、系统构建Yocto还是Ubuntu、模型部署YOLOv5、Qwen怎么塞进Jetson Orin Nano到实际踩过的坑和面试里真正会被问到的点。适合已经有一定嵌入式Linux基础、想往边缘AI方向靠的开发者也适合还在用STM32做控制、想看看外面世界发生了什么的朋友。我不会只告诉你“用Jetson”而是会解释为什么在某些场景下Rockchip RK3588反而更合适以及Yocto构建一个镜像到底比Ubuntu社区项目多花多少时间、换来什么。先抛一个我自己的判断边缘AI不是让嵌入式工程师去训模型而是让模型在资源受限的硬件上跑得稳、跑得快、跑得省电。这件事的核心竞争力依然是嵌入式那套东西——内存布局、中断延迟、功耗管理、驱动适配。模型是算法工程师给的但让它真正在设备上“活”起来靠的是你。2. 边缘AI硬件平台选型Jetson、Rockchip与国产方案的实战对比2.1 为什么硬件选型决定了你后面80%的工作量很多刚入门的兄弟一上来就问“学边缘AI买什么板子”这问题其实问反了。应该先问“我要部署什么模型、功耗预算多少、量产成本卡在什么价位”。我见过太多人买了Jetson Orin Nano回家结果发现项目只需要跑一个MobileNet做简单分类RK3588的NPU完全够用价格还便宜一半。硬件选型不是选性能最强的而是选算力、功耗、生态、成本四者匹配度最高的。Jetson系列的优势在于CUDA生态和TensorRT。如果你要部署的模型来自PyTorch或TensorFlow并且需要FP16甚至INT8量化TensorRT的加速比通常能到2-5倍。Jetson Orin Nano 8GB版本67 TOPS算力功耗7-15W可调跑YOLOv5s在640x640输入下能到30FPS以上。但它的缺点也明显模块价格高载板设计门槛不低量产成本很难压到消费级。Rockchip RK3588是这两年的黑马。8核CPU4×A764×A55Mali-G610 GPU6 TOPS NPU支持INT8/INT16混合量化。关键是它的RKNN工具链已经相当成熟Ubuntu Rockchip社区项目让系统构建变得简单很多。我实测RK3588跑YOLOv5sNPU加速下能到25FPS左右功耗整板不到10W。对于工业网关、NVR、智能座舱这类场景性价比极高。2.2 Jetson Orin Nano与RK3588的实测数据对比下面这张表是我自己在两个平台上跑同一套YOLOv5s模型输入640×640INT8量化的实测结果环境温度25℃散热条件均为被动散热加小风扇对比项Jetson Orin Nano 8GBRockchip RK3588NPU算力67 TOPS (稀疏)6 TOPS实测推理延迟28ms38ms实测帧率35 FPS26 FPS整板功耗推理时12W8W内存带宽102 GB/s32 GB/s工具链TensorRT CUDARKNN-Toolkit2系统构建JetPack (Ubuntu based)Yocto / Ubuntu Rockchip单板参考价约2000元约800元量产成本高中低从数据看Jetson Orin Nano在绝对性能上领先但RK3588在每瓦性能和每元性能上反超。如果你的项目对帧率要求不是极致比如15-20FPS就够RK3588是更务实的选择。Jetson Orin NX和AGX Orin则适合更高阶的场景比如多路视频分析、激光雷达点云处理。2.3 选型时容易忽略的三个隐性成本第一个是散热设计成本。Jetson Orin系列虽然功耗可调但满载时发热集中需要认真设计散热片和风道。我见过一个项目因为散热没做好Orin NX降频到原来一半性能。RK3588发热相对分散但NPU满载时也需要加散热片。第二个是工具链学习成本。TensorRT的文档和社区支持非常丰富但版本兼容性是个坑——JetPack版本、CUDA版本、TensorRT版本、PyTorch版本必须严格对应。RKNN-Toolkit2相对简单但量化精度调优需要更多经验尤其是遇到自定义算子时。第三个是长期供货稳定性。Jetson模块的供货周期通常较长Rockchip的芯片供货受市场波动影响更大。量产项目必须考虑至少12个月的供货保障这一点在选型初期就要和供应商确认清楚。3. 系统构建Yocto、Ubuntu Rockchip与JetPack的取舍3.1 Yocto到底适合谁Yocto在嵌入式圈子里是“专业”的代名词但它不是万能药。Yocto的核心价值在于可定制、可裁剪、可复现。你可以精确控制镜像里每一个包去掉不需要的组件把根文件系统压到几十MB。对于量产设备Yocto能帮你省Flash空间、减少启动时间、降低安全攻击面。但Yocto的学习曲线陡峭。一个最简单的RK3588 Yocto镜像从零开始配置layer、修改bbappend、处理依赖冲突新手可能一周都跑不起来。而且每次修改都要重新构建增量编译虽然能省时间但第一次全量构建动辄两三个小时。我个人的经验是原型阶段用Ubuntu Rockchip社区项目快速验证量产阶段再切Yocto做精简和固化。3.2 Ubuntu Rockchip社区项目的实际体验Ubuntu Rockchip社区项目由Joshua Riek维护是目前RK3588上最省心的Ubuntu镜像方案。它提供了预编译的Ubuntu 22.04/24.04镜像支持RK3588、RK3588S、RK3568等芯片NPU驱动、GPU驱动、视频编解码都已经集成好。刷机后基本可以当作一台ARM小主机用apt安装软件、Docker跑容器都没问题。我实测在RK3588上跑Ubuntu Rockchip 22.04NPU驱动通过rknpu2库调用Python环境下用RKNN-Toolkit2的runtime接口部署YOLOv5s的流程非常顺畅。缺点是社区项目的更新依赖维护者个人精力某些内核版本可能缺少特定外设驱动。如果你的板子有特殊外设比如特定型号的CAN收发器、多路串口可能需要自己打补丁编译内核。3.3 JetPack的版本管理策略JetPack是NVIDIA为Jetson系列提供的SDK包含L4TLinux for Tegra、CUDA、cuDNN、TensorRT等。JetPack的版本管理有个原则不要追最新要追最稳。比如JetPack 5.x对应L4T 35.xJetPack 6.x对应L4T 36.x。每个大版本的内核版本、CUDA版本都不同TensorRT的API也可能有变化。我建议在项目启动时锁定一个JetPack版本然后所有开发板、CI环境、量产镜像都用同一个版本。升级JetPack意味着重新验证所有模型、重新测试所有外设成本很高。另外JetPack的刷机方式有SDK Manager和flash.sh两种量产时通常用flash.sh做批量烧录需要提前准备好量产镜像和烧录脚本。4. 模型部署实战从YOLOv5到Qwen的Jetson Orin Nano落地4.1 YOLOv5在Jetson Orin Nano上的完整部署流程先讲最经典的YOLOv5部署。假设你已经有一块刷好JetPack 6.0的Jetson Orin Nano系统里已经装了CUDA 12.2、TensorRT 8.6、PyTorch 2.1。第一步是模型导出。在x86主机上训练好的YOLOv5s.pt需要导出为ONNX格式。注意opset版本选12输入尺寸固定为640×640。导出命令python export.py --weights yolov5s.pt --include onnx --opset 12 --imgsz 640 640第二步是在Jetson上编译TensorRT引擎。把ONNX文件拷到Jetson用trtexec工具/usr/src/tensorrt/bin/trtexec --onnxyolov5s.onnx --saveEngineyolov5s.engine --fp16 --workspace2048这里用FP16精度workspace给2GB。编译过程大概3-5分钟生成的engine文件是序列化后的TensorRT引擎加载速度比ONNX快很多。第三步是推理代码。用TensorRT的Python API加载engine分配显存执行推理。关键点是预处理和后处理要自己写预处理把图像resize到640×640并归一化后处理做NMS。我实测FP16精度下YOLOv5s在Orin Nano上单帧推理28ms加上前后处理总共约35ms帧率28FPS左右。4.2 Qwen大模型在Jetson Orin Nano上的可行性分析最近很多人问“Jetson Orin Nano部署Qwen”。先说结论Orin Nano 8GB可以跑Qwen2-1.5B或Qwen2-0.5B的INT4量化版本但速度只能算“能用”。我用llama.cpp的CUDA后端测试Qwen2-1.5B-Instruct的Q4_K_M量化模型Orin Nano上生成速度约8-12 token/s首token延迟约1.5秒。这个速度做本地语音助手勉强够做实时对话就吃力了。部署流程大致是先用llama.cpp的quantize工具把HuggingFace格式的Qwen模型转成GGUF格式并量化然后在Jetson上编译llama.cpp开启CUDA支持最后用llama-cli或llama-server加载模型。内存占用方面1.5B的Q4模型约1.2GB加上KV cache和系统开销8GB内存够用但余量不多。如果要用OllamaJetson Orin Nano上也可以跑但Ollama的ARM64 CUDA支持不如x86完善建议还是用llama.cpp直接编译。另外注意Orin Nano的GPU和NPU是分开的llama.cpp用的是GPUCUDA核心NPU不参与大模型推理。4.3 AirSLAM在Jetson上的部署要点AirSLAM是一个基于深度学习的SLAM方案对Jetson的算力要求较高。在Jetson Orin NX或AGX Orin上部署相对顺畅Orin Nano上需要降低输入分辨率或跳帧处理。部署时注意几点一是CUDA架构要匹配Orin系列是sm_87编译时指定-gencode archcompute_87,codesm_87二是内存管理SLAM的map和feature buffer容易吃满内存建议用NvSciBuf做零拷贝三是实时性SLAM对延迟敏感推理线程要和传感器采集线程做好同步。5. 嵌入式工程师切入边缘AI的学习路线与面试准备5.1 分阶段学习路线从驱动到模型部署如果你已经会嵌入式Linux应用开发想转边缘AI我建议分三个阶段第一阶段1-2个月补齐AI基础。不用去啃深度学习理论但要理解张量、卷积、量化、NMS这些概念。推荐用PyTorch在x86上跑通一个图像分类和检测的demo知道模型输入输出是什么。第二阶段2-3个月掌握一个硬件平台的完整部署链路。选Jetson或RK3588其中一个从刷机开始到跑通YOLOv5再到自己训练一个简单模型并部署。这个阶段的目标是“全链路走通”不是“调优”。第三阶段持续深入性能优化。学习TensorRT或RKNN的量化技巧、层融合、内存复用学习如何用Nsight Systems或perf做性能分析。这个阶段决定你是“会部署”还是“部署得好”。5.2 边缘AI岗位面试中真正会被问到的题嵌入式八股文里那些“volatile关键字作用”“中断上半部和下半部”依然会问但边缘AI岗位会加一些新东西。我整理了几个高频问题TensorRT的FP16和INT8量化有什么区别校准表怎么生成RKNN的量化精度下降严重时你从哪些方向排查Jetson上如何做多线程推理CUDA stream怎么用模型推理延迟高你如何定位是预处理、推理还是后处理的问题Yocto里如何添加一个自定义的NPU驱动包这些问题没有标准答案面试官想看的是你有没有真正动手做过。我见过一个候选人把YOLOv5在RK3588上的量化精度从mAP 0.75调到0.82靠的是逐层分析量化敏感度并调整校准集这种经验比背八股文值钱得多。5.3 值得动手的开源项目推荐如果你想积累项目经验这几个开源项目值得复现一是rknn_model_zooRockchip官方模型库包含YOLO系列、RetinaFace、PPOCR等代码结构清晰二是jetson-inferenceNVIDIA的推理示例涵盖图像分类、检测、分割三是llama.cpp在Jetson上跑小语言模型的最佳起点。每个项目都动手跑一遍遇到问题去查issue和源码比看教程收获大得多。6. 常见问题与排查技巧实录6.1 模型部署中的典型问题速查问题现象可能原因排查方向TensorRT引擎加载失败版本不匹配检查ONNX opset、TensorRT版本、CUDA版本RKNN推理结果全零输入格式错误检查NHWC/NCHW、归一化参数、量化类型推理帧率远低于预期未启用硬件加速确认NPU/GPU是否参与、是否用了FP16内存溢出显存/内存不足减小workspace、降低batch size、检查内存泄漏量化后精度暴跌校准集不具代表性扩充校准集、改用逐层量化、混合精度系统启动卡死设备树配置错误检查dts、时钟、电源域配置6.2 我踩过的三个坑和解决方法第一个坑是TensorRT版本与PyTorch导出ONNX的opset不兼容。JetPack 5.1自带TensorRT 8.5只支持到opset 16但我用PyTorch 2.0默认导出opset 17导致引擎编译失败。解决方法是导出时显式指定--opset 12。第二个坑是RK3588的NPU驱动在Ubuntu Rockchip社区版里默认没加载。需要手动modprobe rknpu并把用户加入video组。这个在官方文档里没写清楚我查了半天issue才找到。第三个坑是Jetson Orin Nano的功耗模式默认是15W但散热跟不上会降频。用nvpmodel切换到7W模式反而更稳定帧率只降了10%但温度低了15℃。量产设备一定要做热仿真和降频策略。6.3 嵌入式环境监控的实用技巧边缘设备部署后环境监控很重要。我通常会在设备上跑一个轻量级监控脚本采集CPU/GPU/NPU利用率、内存、温度、推理延迟通过MQTT上报到本地网关。Jetson可以用tegrastatsRK3588可以用cat /sys/class/thermal/thermal_zone*/temp。如果发现推理延迟随时间上升通常是内存泄漏或散热问题需要及时排查。7. 一些个人的体会边缘AI这个方向说到底还是嵌入式工程师的地盘。算法工程师能把模型训到SOTA但让模型在8W功耗、2GB内存、-20℃到70℃的环境里稳定跑三年这是嵌入式工程师的活。Jetson和Rockchip只是工具Yocto和Ubuntu只是手段真正值钱的是你对系统底层的理解——知道内存带宽在哪里瓶颈、知道中断延迟怎么影响实时性、知道怎么在资源受限下做取舍。我自己的路径是从STM32裸机到嵌入式Linux再到边缘AI部署每一步都是被项目逼出来的。如果你现在还在用STM32做控制不妨先买一块RK3588或Jetson Nano把YOLOv5跑起来感受一下NPU加速和CUDA的魅力。不用一开始就追求极致性能先让整个链路跑通后面再慢慢优化。这个领域变化很快但底层的东西变化很慢把底层吃透上层怎么变都不慌。