边缘端 AI 算力选型这件事我前前后后踩了差不多两年的坑。最早做智能门禁那会儿觉得算力越大越好直接上了一块旗舰级模组结果功耗压不住散热片烫得能煎蛋成本还翻了四倍最后项目被砍掉重来。后来做工业质检、做车载辅助、做农业无人机慢慢摸出一个道理边缘端选芯片从来不是选最强的而是选最合适的。你得先问清楚场景要什么再反推芯片要什么顺序反了钱和工期都得搭进去。这篇文章我想把这两年攒下来的选型逻辑完整讲一遍。核心就一句话从场景反推芯片。我会拆解边缘端 AI 算力的几个关键维度讲清楚 SoC、NPU、CPU、GPU、DSP 各自在什么位置为什么有些场景用 RK3588 就够了有些必须上 Jetson Orin还有些场景一颗 ESP32 加个轻量模型反而最稳。适合正在做边缘 AI 产品定义、硬件选型、算法部署的工程师和产品经理看也适合刚入行想搞清楚“算力到底怎么选”的朋友。全文没有玄学都是能直接拿去对照自己项目的判断方法。1. 先搞清楚边缘端 AI 算力到底在解决什么问题1.1 边缘端和云端的分工边界在哪里很多人一上来就问“哪颗芯片 NPU 算力最强”这个问题本身就问偏了。边缘端 AI 的第一性问题不是算力大小而是数据在哪里产生、决策在哪里发生、延迟能容忍多少。我做过一个对比同样是做人员检测云端方案从摄像头采集到返回结果走公网平均 180 到 350 毫秒遇到网络抖动直接飙到 1 秒以上而边缘端本地推理从帧采集到输出框稳定在 30 到 60 毫秒。这个差距在门禁场景就是“人走过去门开没开”的体验差异在工业质检场景就是“产线能不能跟上节拍”的生死线。边缘端的本质是把推理能力下沉到数据源头附近。它解决的是三类问题第一类是延迟敏感比如机械臂抓取、自动驾驶避障超过 100 毫秒的决策基本没意义第二类是带宽和成本敏感一路 1080P 视频流如果全部回传云端按 4Mbps 算一天就是 40 多 GB几十路摄像头就是天价流量费第三类是隐私和离线可用医疗影像、人脸数据、工厂工艺参数这些东西不出本地是硬要求断网也得能跑。所以选型的第一步是先画清楚你的数据流传感器出来是什么格式、帧率多少、分辨率多少、预处理要做哪些、模型输入张量多大、输出要做什么后处理、最终执行机构是什么。这张图画完你对算力的需求轮廓就出来了而不是拿着芯片参数表瞎对比。1.2 算力单位 TOPS 到底该怎么理解TOPS 是 Tera Operations Per Second每秒万亿次操作。听起来很直观但坑在于不同厂商对“一次操作”的定义不一样。有的按 MAC乘加算一次有的按乘和加各算一次同样标 4 TOPS实际有效算力可能差一倍。更关键的是TOPS 是峰值理论值实际能跑出多少取决于内存带宽、NPU 架构、算子支持度、量化精度。我习惯用一个更接地气的换算方式看 INT8 精度下跑你目标模型的实际帧率。比如 YOLOv5s 输入 640x640在 RK3588 的 NPU 上大概能跑 30 到 40 FPS在 Jetson Orin Nano 8GB 上大概 60 到 80 FPS在 Jetson Orin NX 16GB 上能到 120 FPS 以上。这些数字比参数表上的 TOPS 有用得多因为它们直接对应你的业务节拍。还有一个容易被忽略的点算力不是孤立的它和内存带宽是绑死的。NPU 算得再快权重和特征图从 DDR 里搬不过来也是白搭。这就是为什么有些芯片标称算力很高实际跑大模型时帧率上不去——内存带宽成了瓶颈。选型时一定要看内存类型LPDDR4/LPDDR4X/LPDDR5、位宽32bit/64bit/128bit、频率算一下理论带宽。经验公式是每 1 TOPS 的 INT8 算力至少需要 2 到 4 GB/s 的内存带宽来喂低于这个比例NPU 就会饿着。1.3 从场景反推的三个核心问题我现在做选型先问三个问题答不上来就不往下走。第一个问题你的模型是什么输入多大精度要求多少。分类模型和检测模型对算力的需求差一个量级检测模型里 YOLOv5n 和 YOLOv8x 又差一个量级。量化到 INT8 还是保持 FP16对 NPU 的要求也不同。有些老 NPU 只支持 INT8你拿 FP16 模型过去直接跑不了。第二个问题你的实时性要求是多少是硬实时还是软实时。硬实时意味着最坏情况下的延迟也必须满足比如每帧必须在 33 毫秒内出结果那你的算力预算要按峰值负载留 30% 以上余量。软实时可以接受偶尔掉帧余量可以留少一点。第三个问题你的功耗和散热边界在哪里。电池供电的设备整机功耗可能就 3 到 5 瓦那芯片本身不能超过 2 瓦有风扇的工业盒子可以放到 15 到 25 瓦车载场景有主动散热能上到 30 瓦以上。功耗边界直接砍掉一大半候选芯片。这三个问题答完候选范围基本就缩小到三五颗了。接下来才是看参数、看生态、看价格。2. 主流边缘 AI 芯片阵营拆解与选型逻辑2.1 国产 SoC 阵营RK3588 为什么成了万金油RK3588 这两年几乎是边缘 AI 项目的默认选项我手上至少五个项目用了它。原因很实在6 TOPS 的 NPU、8 核 CPU4 个 A76 加 4 个 A55、支持 8K 编解码、接口丰富、价格相对友好、生态资料多。它不是最强的但它是“什么都能干一点”的典型。它的 NPU 是 3 核架构支持 INT4、INT8、INT16、FP16实际跑 YOLOv5s INT8 大概 30 到 40 FPS跑 ResNet50 分类能到 200 FPS 以上。对于大多数智能安防、工业视觉、零售分析场景这个算力是够用的。我做过一个 16 路 1080P 视频分析的盒子用两颗 RK3588每颗跑 8 路轻量检测整机功耗控制在 25 瓦以内无风扇设计连续跑三个月没出问题。但 RK3588 也有明显的边界。第一它的 NPU 对某些算子和自定义层支持不好比如一些复杂的注意力机制、动态 shape 操作需要手动拆图或者回退到 CPU一回落性能就崩。第二内存带宽是共享的CPU、GPU、NPU、编解码器抢带宽高负载时互相拖累。第三工具链成熟度一般RKNN 工具链更新快但文档零散量化精度损失有时候需要反复调。我的经验是如果你的模型是主流 CNN 架构、输入不超过 640、精度 INT8 可接受、单芯片算力需求在 4 TOPS 以内RK3588 是性价比最高的选择。超出这个范围就得考虑别的。2.2 英伟达 Jetson 阵营生态强但价格硬Jetson 系列是边缘 AI 的老牌选手从 Nano 到 Orin 到 AGX Orin覆盖了从 0.5 TOPS 到 275 TOPS 的跨度。它的核心优势是CUDA 生态——你的模型在服务器上怎么训、怎么调在 Jetson 上几乎可以原样搬过来TensorRT 的优化效果也是业界公认的好。Jetson Orin Nano 8GB 是我用得比较多的一颗算力标称 40 TOPSINT8实际跑 YOLOv8s 能到 60 到 80 FPS功耗可以压在 7 到 15 瓦。它适合什么场景模型结构比较新、需要 FP16 或者混合精度、对帧率要求高、团队熟悉 CUDA 技术栈。比如做多模态、做 Transformer 类模型、做需要频繁换模型的研发阶段Jetson 的灵活性优势非常明显。代价是价格。Orin Nano 8GB 模组加上载板成本大概是 RK3588 方案的三到四倍。Orin NX 16GB 更贵AGX Orin 就是另一个量级了。而且 Jetson 的供货周期和价格波动做过项目的人都知道得提前锁货。还有一个坑Jetson 的功耗和散热设计比参数表看起来要复杂。Orin Nano 标称 7 到 15 瓦可配置但你要跑满算力散热必须跟上被动散热在 15 瓦模式下基本压不住得加风扇或者大散热片。我见过有人把 Orin Nano 塞进密闭小盒子跑满负载十分钟就降频了。2.3 轻量级 MCU 与 MPU 阵营ESP32、STM32 的 AI 边界不是所有边缘 AI 都需要 NPU。有些场景一颗 ESP32 或者 STM32H7 加一个 TinyML 模型反而比上 SoC 更合适。我做过一个振动异常检测的项目用 STM32H743 跑一个几百 KB 的 1D CNN采样率 1kHz推理延迟 2 毫秒以内整机功耗不到 0.5 瓦电池能撑半年。这种场景你上 RK3588 就是杀鸡用牛刀成本和功耗都浪费。ESP32-S3 带向量指令跑一些轻量关键词唤醒、简单图像分类是可行的。STM32 的 X-CUBE-AI 工具链可以把 TensorFlow Lite 模型转成 C 代码部署在 MCU 上。但边界很清楚模型参数量通常在几百 KB 以内输入维度低任务简单。一旦你要做 224x224 以上的图像检测MCU 的算力和内存都不够看。这类方案的价值在于极低功耗、极低成本、极高实时性。如果你的场景是传感器信号处理、简单语音唤醒、低分辨率图像分类先考虑 MCU 方案别一上来就上 SoC。2.4 专用 AI 加速芯片与 IP 阵营除了通用 SoC还有一类是专用 AI 加速芯片或者 IP 核比如寒武纪、地平线、黑芝麻、以及各种 NPU IP。这类方案通常算力密度高、能效比好但生态和通用性差适合出货量大的定制项目。如果你是小批量、多品种的项目用这类芯片的投入产出比不划算工具链适配和算法移植的成本会吃掉你的利润。我的建议是年出货量低于一万台的项目优先选通用 SoC 或者 Jetson超过这个量级再考虑专用芯片做成本优化。这个门槛不是绝对的但大方向是这样。3. 从场景反推芯片的实操方法论3.1 第一步把场景翻译成算力需求清单我习惯用一张表把场景需求量化。以智能安防的人形检测为例需求维度具体指标备注视频路数4 路 1080P每路 25 FPS模型YOLOv5s INT8输入 640x640单帧推理预算40 毫秒4 路并发每路 25 FPS总帧率 100 FPS预处理解码 缩放 归一化可用硬件加速后处理NMS 跟踪CPU 负载功耗上限15 瓦无风扇盒子成本目标单板 300 元以内含内存和存储这张表一出来算力需求就清楚了总帧率 100 FPS 的 YOLOv5s INT8单帧 40 毫秒预算。RK3588 单核 NPU 跑 YOLOv5s 大概 30 FPS三核可以到 90 FPS 左右加上预处理和后处理的 CPU 开销单颗 RK3588 勉强够 4 路但余量不多。如果路数增加到 8 路就得双芯片或者换 Jetson Orin NX。3.2 第二步算清楚内存带宽和功耗账内存带宽这笔账很多人不算结果就是 NPU 利用率上不去。以 RK3588 为例LPDDR4X 4266Mbps64bit 位宽理论带宽是 4266 × 64 ÷ 8 34.1 GB/s。但这是理论值实际有效带宽大概 60% 到 70%也就是 20 到 24 GB/s。NPU 跑 YOLOv5s每帧需要读取权重和特征图粗略估算每帧内存访问量在 100 到 200 MB 量级30 FPS 就是 3 到 6 GB/s。加上 CPU、GPU、编解码器的占用带宽是够的但不宽裕。功耗账更直接。芯片的 TDP 不等于实际功耗实际功耗取决于负载。RK3588 满负载 NPU 加 CPU 大概 8 到 12 瓦加上内存、存储、外设整机 15 到 20 瓦。Jetson Orin Nano 15 瓦模式下整机大概 20 到 25 瓦。这些数字要提前和你的散热方案对齐别等板子回来了才发现压不住。3.3 第三步用实际模型做基准测试参数表都是参考最终决策一定要用你的实际模型跑基准测试。我的流程是在 PC 上用目标框架训练并导出模型ONNX 或者 TFLite用芯片厂商的工具链做转换和量化RKNN、TensorRT、X-CUBE-AI在开发板上跑实际帧率和延迟记录 CPU、NPU、内存占用跑满负载持续 30 分钟以上观察是否降频测试极端场景多路并发、模型切换、异常输入这一步不能省。我见过太多项目参数表上算得好好的实际跑起来帧率只有预期的一半原因就是算子不支持、量化损失大、或者内存带宽瓶颈。3.4 第四步评估生态和长期维护成本芯片选型不只是选硬件更是选生态。工具链是否活跃、文档是否完整、社区是否有案例、厂商是否持续更新这些决定了你后续的开发和维护成本。RK3588 的 RKNN 工具链更新频率不错但文档质量参差不齐很多问题得靠社区和试错。Jetson 的 TensorRT 文档和案例非常丰富但版本兼容性有时候让人头疼CUDA、cuDNN、TensorRT、PyTorch 版本要对齐。MCU 阵营的 X-CUBE-AI 和 TFLite Micro 相对简单但功能也有限。我的经验是团队熟悉什么生态就优先选什么芯片。如果团队都是 Python 和 PyTorch 背景Jetson 的上手成本最低如果团队有嵌入式背景、愿意啃工具链RK3588 的性价比最高如果团队做的是极低功耗传感器节点MCU 方案最合适。4. 典型场景的选型对照与避坑指南4.1 智能安防与视频分析场景这个场景的特点是多路视频、7x24 运行、成本敏感、模型相对固定。主流方案是 RK3588 或者类似国产 SoC单芯片跑 4 到 8 路轻量检测多芯片堆叠做更多路数。Jetson 在这个场景也有用但通常是高端需求比如需要跑更复杂的模型或者更高的帧率。避坑点解码器和 NPU 抢带宽。多路视频解码本身就很吃内存带宽如果 NPU 同时跑推理带宽容易成为瓶颈。解决办法是控制单芯片的路数或者用带独立解码硬件的方案。另外长时间运行的稳定性比峰值性能更重要一定要做 72 小时以上的老化测试。4.2 工业视觉与质检场景工业场景对实时性和确定性要求极高产线节拍是硬约束。模型通常是定制的小模型输入分辨率可能不高但要求极低的漏检率和误检率。这个场景我倾向于用 Jetson因为 TensorRT 的优化效果稳定FP16 精度对质检更友好而且工业客户对价格相对不敏感更看重可靠性。避坑点工业现场的电磁干扰和温度。芯片选型时要看工业级温度范围消费级的 0 到 70 度在车间里可能不够。另外触发和同步很关键相机触发、光源控制、推理、执行机构动作整个链路要在节拍内完成选型时要留足余量。4.3 车载与移动机器人场景车载和机器人场景的核心约束是功耗、重量、功能安全。功耗直接关系到续航重量关系到载重功能安全关系到认证。这个场景通常用专门的車规芯片或者低功耗 SoCJetson 的 Orin 系列在机器人领域用得很多因为算力足、生态好。避坑点电源设计和散热。车载环境电压波动大电源芯片要选宽压输入的。散热在密闭空间里是大问题被动散热方案要仔细算热阻。另外模型的热更新和 OTA要提前设计边缘设备分布广现场升级成本很高。4.4 消费电子与智能家居场景这个场景对成本极其敏感功耗要求苛刻模型通常非常轻量。ESP32-S3、STM32 加 TinyML、或者低端 SoC 是主流。语音唤醒、简单图像分类、传感器融合是典型任务。避坑点别高估 MCU 的 AI 能力。很多团队拿着 PC 上训好的模型想直接塞进 MCU结果发现内存不够、算子不支持、帧率惨不忍睹。MCU 上的模型要专门设计参数量、输入维度、算子类型都要围绕 MCU 的约束来。4.5 常见问题速查表问题现象可能原因排查方向解决思路NPU 利用率低内存带宽瓶颈查 DDR 带宽占用降低分辨率或换高带宽内存实际帧率远低于预期算子回退 CPU看工具链日志替换不支持算子或换芯片量化后精度暴跌量化策略不当逐层对比精度混合量化或保留敏感层 FP16满载运行降频散热不足测芯片温度加散热片或风扇降功耗配置多路视频卡顿解码器带宽争抢查解码和 NPU 并发减少路数或分芯片处理模型转换失败算子不支持看转换报错改模型结构或用手动拆图长时间运行死机内存泄漏或过热查日志和温度加看门狗优化内存管理5. 选型决策的优先级排序与经验总结5.1 我个人的选型优先级经过这么多项目我现在的选型优先级是这样的场景约束 生态成熟度 算力参数 价格。场景约束是硬边界不满足直接淘汰生态成熟度决定开发效率和长期维护成本算力参数只要满足需求就行不必追求最高价格在满足前三条的前提下再优化。这个排序和很多人的直觉相反很多人是价格优先或者算力优先。但实际项目里选了一颗便宜但生态差的芯片后期开发和维护成本会远超芯片差价选了一颗算力过剩的芯片功耗和散热成本也会吃掉利润。5.2 几个反直觉的经验第一个经验算力过剩比算力不足更常见。很多项目一上来就选最高算力的芯片结果模型跑起来 NPU 利用率只有 20%大部分算力闲置功耗和成本却上去了。正确的做法是按实际需求选留 30% 到 50% 余量就够了。第二个经验CPU 性能经常被低估。边缘 AI 不只是 NPU 的事预处理、后处理、业务逻辑、通信协议都在 CPU 上跑。CPU 太弱NPU 再强也发挥不出来。选型时要看 CPU 的单核性能和多核调度能力。第三个经验工具链的坑比硬件多。硬件问题通常有明确的排查路径工具链问题往往是玄学版本不对、算子不支持、量化精度损失每一个都能耗掉几天时间。选芯片前先花时间调研工具链的实际使用体验。5.3 给不同阶段项目的建议原型验证阶段优先选生态好、资料多的方案Jetson 或者 RK3588 开发板快速把功能跑通别在硬件上纠结。小批量试产阶段根据实际负载做基准测试确定最终芯片型号同时评估供货和成本。大批量量产阶段考虑专用芯片或者定制方案做成本优化但要做好工具链适配和算法移植的投入准备。最后分享一个我常用的判断方法如果你不确定选哪颗芯片就选那个社区案例最多、你团队最熟悉的。边缘 AI 的坑大部分不在芯片本身而在开发和部署过程。熟悉的生态能帮你省下大量试错时间这些时间比芯片差价值钱得多。
边缘端AI算力选型实战：从场景反推芯片的两年踩坑经验
边缘端 AI 算力选型这件事我前前后后踩了差不多两年的坑。最早做智能门禁那会儿觉得算力越大越好直接上了一块旗舰级模组结果功耗压不住散热片烫得能煎蛋成本还翻了四倍最后项目被砍掉重来。后来做工业质检、做车载辅助、做农业无人机慢慢摸出一个道理边缘端选芯片从来不是选最强的而是选最合适的。你得先问清楚场景要什么再反推芯片要什么顺序反了钱和工期都得搭进去。这篇文章我想把这两年攒下来的选型逻辑完整讲一遍。核心就一句话从场景反推芯片。我会拆解边缘端 AI 算力的几个关键维度讲清楚 SoC、NPU、CPU、GPU、DSP 各自在什么位置为什么有些场景用 RK3588 就够了有些必须上 Jetson Orin还有些场景一颗 ESP32 加个轻量模型反而最稳。适合正在做边缘 AI 产品定义、硬件选型、算法部署的工程师和产品经理看也适合刚入行想搞清楚“算力到底怎么选”的朋友。全文没有玄学都是能直接拿去对照自己项目的判断方法。1. 先搞清楚边缘端 AI 算力到底在解决什么问题1.1 边缘端和云端的分工边界在哪里很多人一上来就问“哪颗芯片 NPU 算力最强”这个问题本身就问偏了。边缘端 AI 的第一性问题不是算力大小而是数据在哪里产生、决策在哪里发生、延迟能容忍多少。我做过一个对比同样是做人员检测云端方案从摄像头采集到返回结果走公网平均 180 到 350 毫秒遇到网络抖动直接飙到 1 秒以上而边缘端本地推理从帧采集到输出框稳定在 30 到 60 毫秒。这个差距在门禁场景就是“人走过去门开没开”的体验差异在工业质检场景就是“产线能不能跟上节拍”的生死线。边缘端的本质是把推理能力下沉到数据源头附近。它解决的是三类问题第一类是延迟敏感比如机械臂抓取、自动驾驶避障超过 100 毫秒的决策基本没意义第二类是带宽和成本敏感一路 1080P 视频流如果全部回传云端按 4Mbps 算一天就是 40 多 GB几十路摄像头就是天价流量费第三类是隐私和离线可用医疗影像、人脸数据、工厂工艺参数这些东西不出本地是硬要求断网也得能跑。所以选型的第一步是先画清楚你的数据流传感器出来是什么格式、帧率多少、分辨率多少、预处理要做哪些、模型输入张量多大、输出要做什么后处理、最终执行机构是什么。这张图画完你对算力的需求轮廓就出来了而不是拿着芯片参数表瞎对比。1.2 算力单位 TOPS 到底该怎么理解TOPS 是 Tera Operations Per Second每秒万亿次操作。听起来很直观但坑在于不同厂商对“一次操作”的定义不一样。有的按 MAC乘加算一次有的按乘和加各算一次同样标 4 TOPS实际有效算力可能差一倍。更关键的是TOPS 是峰值理论值实际能跑出多少取决于内存带宽、NPU 架构、算子支持度、量化精度。我习惯用一个更接地气的换算方式看 INT8 精度下跑你目标模型的实际帧率。比如 YOLOv5s 输入 640x640在 RK3588 的 NPU 上大概能跑 30 到 40 FPS在 Jetson Orin Nano 8GB 上大概 60 到 80 FPS在 Jetson Orin NX 16GB 上能到 120 FPS 以上。这些数字比参数表上的 TOPS 有用得多因为它们直接对应你的业务节拍。还有一个容易被忽略的点算力不是孤立的它和内存带宽是绑死的。NPU 算得再快权重和特征图从 DDR 里搬不过来也是白搭。这就是为什么有些芯片标称算力很高实际跑大模型时帧率上不去——内存带宽成了瓶颈。选型时一定要看内存类型LPDDR4/LPDDR4X/LPDDR5、位宽32bit/64bit/128bit、频率算一下理论带宽。经验公式是每 1 TOPS 的 INT8 算力至少需要 2 到 4 GB/s 的内存带宽来喂低于这个比例NPU 就会饿着。1.3 从场景反推的三个核心问题我现在做选型先问三个问题答不上来就不往下走。第一个问题你的模型是什么输入多大精度要求多少。分类模型和检测模型对算力的需求差一个量级检测模型里 YOLOv5n 和 YOLOv8x 又差一个量级。量化到 INT8 还是保持 FP16对 NPU 的要求也不同。有些老 NPU 只支持 INT8你拿 FP16 模型过去直接跑不了。第二个问题你的实时性要求是多少是硬实时还是软实时。硬实时意味着最坏情况下的延迟也必须满足比如每帧必须在 33 毫秒内出结果那你的算力预算要按峰值负载留 30% 以上余量。软实时可以接受偶尔掉帧余量可以留少一点。第三个问题你的功耗和散热边界在哪里。电池供电的设备整机功耗可能就 3 到 5 瓦那芯片本身不能超过 2 瓦有风扇的工业盒子可以放到 15 到 25 瓦车载场景有主动散热能上到 30 瓦以上。功耗边界直接砍掉一大半候选芯片。这三个问题答完候选范围基本就缩小到三五颗了。接下来才是看参数、看生态、看价格。2. 主流边缘 AI 芯片阵营拆解与选型逻辑2.1 国产 SoC 阵营RK3588 为什么成了万金油RK3588 这两年几乎是边缘 AI 项目的默认选项我手上至少五个项目用了它。原因很实在6 TOPS 的 NPU、8 核 CPU4 个 A76 加 4 个 A55、支持 8K 编解码、接口丰富、价格相对友好、生态资料多。它不是最强的但它是“什么都能干一点”的典型。它的 NPU 是 3 核架构支持 INT4、INT8、INT16、FP16实际跑 YOLOv5s INT8 大概 30 到 40 FPS跑 ResNet50 分类能到 200 FPS 以上。对于大多数智能安防、工业视觉、零售分析场景这个算力是够用的。我做过一个 16 路 1080P 视频分析的盒子用两颗 RK3588每颗跑 8 路轻量检测整机功耗控制在 25 瓦以内无风扇设计连续跑三个月没出问题。但 RK3588 也有明显的边界。第一它的 NPU 对某些算子和自定义层支持不好比如一些复杂的注意力机制、动态 shape 操作需要手动拆图或者回退到 CPU一回落性能就崩。第二内存带宽是共享的CPU、GPU、NPU、编解码器抢带宽高负载时互相拖累。第三工具链成熟度一般RKNN 工具链更新快但文档零散量化精度损失有时候需要反复调。我的经验是如果你的模型是主流 CNN 架构、输入不超过 640、精度 INT8 可接受、单芯片算力需求在 4 TOPS 以内RK3588 是性价比最高的选择。超出这个范围就得考虑别的。2.2 英伟达 Jetson 阵营生态强但价格硬Jetson 系列是边缘 AI 的老牌选手从 Nano 到 Orin 到 AGX Orin覆盖了从 0.5 TOPS 到 275 TOPS 的跨度。它的核心优势是CUDA 生态——你的模型在服务器上怎么训、怎么调在 Jetson 上几乎可以原样搬过来TensorRT 的优化效果也是业界公认的好。Jetson Orin Nano 8GB 是我用得比较多的一颗算力标称 40 TOPSINT8实际跑 YOLOv8s 能到 60 到 80 FPS功耗可以压在 7 到 15 瓦。它适合什么场景模型结构比较新、需要 FP16 或者混合精度、对帧率要求高、团队熟悉 CUDA 技术栈。比如做多模态、做 Transformer 类模型、做需要频繁换模型的研发阶段Jetson 的灵活性优势非常明显。代价是价格。Orin Nano 8GB 模组加上载板成本大概是 RK3588 方案的三到四倍。Orin NX 16GB 更贵AGX Orin 就是另一个量级了。而且 Jetson 的供货周期和价格波动做过项目的人都知道得提前锁货。还有一个坑Jetson 的功耗和散热设计比参数表看起来要复杂。Orin Nano 标称 7 到 15 瓦可配置但你要跑满算力散热必须跟上被动散热在 15 瓦模式下基本压不住得加风扇或者大散热片。我见过有人把 Orin Nano 塞进密闭小盒子跑满负载十分钟就降频了。2.3 轻量级 MCU 与 MPU 阵营ESP32、STM32 的 AI 边界不是所有边缘 AI 都需要 NPU。有些场景一颗 ESP32 或者 STM32H7 加一个 TinyML 模型反而比上 SoC 更合适。我做过一个振动异常检测的项目用 STM32H743 跑一个几百 KB 的 1D CNN采样率 1kHz推理延迟 2 毫秒以内整机功耗不到 0.5 瓦电池能撑半年。这种场景你上 RK3588 就是杀鸡用牛刀成本和功耗都浪费。ESP32-S3 带向量指令跑一些轻量关键词唤醒、简单图像分类是可行的。STM32 的 X-CUBE-AI 工具链可以把 TensorFlow Lite 模型转成 C 代码部署在 MCU 上。但边界很清楚模型参数量通常在几百 KB 以内输入维度低任务简单。一旦你要做 224x224 以上的图像检测MCU 的算力和内存都不够看。这类方案的价值在于极低功耗、极低成本、极高实时性。如果你的场景是传感器信号处理、简单语音唤醒、低分辨率图像分类先考虑 MCU 方案别一上来就上 SoC。2.4 专用 AI 加速芯片与 IP 阵营除了通用 SoC还有一类是专用 AI 加速芯片或者 IP 核比如寒武纪、地平线、黑芝麻、以及各种 NPU IP。这类方案通常算力密度高、能效比好但生态和通用性差适合出货量大的定制项目。如果你是小批量、多品种的项目用这类芯片的投入产出比不划算工具链适配和算法移植的成本会吃掉你的利润。我的建议是年出货量低于一万台的项目优先选通用 SoC 或者 Jetson超过这个量级再考虑专用芯片做成本优化。这个门槛不是绝对的但大方向是这样。3. 从场景反推芯片的实操方法论3.1 第一步把场景翻译成算力需求清单我习惯用一张表把场景需求量化。以智能安防的人形检测为例需求维度具体指标备注视频路数4 路 1080P每路 25 FPS模型YOLOv5s INT8输入 640x640单帧推理预算40 毫秒4 路并发每路 25 FPS总帧率 100 FPS预处理解码 缩放 归一化可用硬件加速后处理NMS 跟踪CPU 负载功耗上限15 瓦无风扇盒子成本目标单板 300 元以内含内存和存储这张表一出来算力需求就清楚了总帧率 100 FPS 的 YOLOv5s INT8单帧 40 毫秒预算。RK3588 单核 NPU 跑 YOLOv5s 大概 30 FPS三核可以到 90 FPS 左右加上预处理和后处理的 CPU 开销单颗 RK3588 勉强够 4 路但余量不多。如果路数增加到 8 路就得双芯片或者换 Jetson Orin NX。3.2 第二步算清楚内存带宽和功耗账内存带宽这笔账很多人不算结果就是 NPU 利用率上不去。以 RK3588 为例LPDDR4X 4266Mbps64bit 位宽理论带宽是 4266 × 64 ÷ 8 34.1 GB/s。但这是理论值实际有效带宽大概 60% 到 70%也就是 20 到 24 GB/s。NPU 跑 YOLOv5s每帧需要读取权重和特征图粗略估算每帧内存访问量在 100 到 200 MB 量级30 FPS 就是 3 到 6 GB/s。加上 CPU、GPU、编解码器的占用带宽是够的但不宽裕。功耗账更直接。芯片的 TDP 不等于实际功耗实际功耗取决于负载。RK3588 满负载 NPU 加 CPU 大概 8 到 12 瓦加上内存、存储、外设整机 15 到 20 瓦。Jetson Orin Nano 15 瓦模式下整机大概 20 到 25 瓦。这些数字要提前和你的散热方案对齐别等板子回来了才发现压不住。3.3 第三步用实际模型做基准测试参数表都是参考最终决策一定要用你的实际模型跑基准测试。我的流程是在 PC 上用目标框架训练并导出模型ONNX 或者 TFLite用芯片厂商的工具链做转换和量化RKNN、TensorRT、X-CUBE-AI在开发板上跑实际帧率和延迟记录 CPU、NPU、内存占用跑满负载持续 30 分钟以上观察是否降频测试极端场景多路并发、模型切换、异常输入这一步不能省。我见过太多项目参数表上算得好好的实际跑起来帧率只有预期的一半原因就是算子不支持、量化损失大、或者内存带宽瓶颈。3.4 第四步评估生态和长期维护成本芯片选型不只是选硬件更是选生态。工具链是否活跃、文档是否完整、社区是否有案例、厂商是否持续更新这些决定了你后续的开发和维护成本。RK3588 的 RKNN 工具链更新频率不错但文档质量参差不齐很多问题得靠社区和试错。Jetson 的 TensorRT 文档和案例非常丰富但版本兼容性有时候让人头疼CUDA、cuDNN、TensorRT、PyTorch 版本要对齐。MCU 阵营的 X-CUBE-AI 和 TFLite Micro 相对简单但功能也有限。我的经验是团队熟悉什么生态就优先选什么芯片。如果团队都是 Python 和 PyTorch 背景Jetson 的上手成本最低如果团队有嵌入式背景、愿意啃工具链RK3588 的性价比最高如果团队做的是极低功耗传感器节点MCU 方案最合适。4. 典型场景的选型对照与避坑指南4.1 智能安防与视频分析场景这个场景的特点是多路视频、7x24 运行、成本敏感、模型相对固定。主流方案是 RK3588 或者类似国产 SoC单芯片跑 4 到 8 路轻量检测多芯片堆叠做更多路数。Jetson 在这个场景也有用但通常是高端需求比如需要跑更复杂的模型或者更高的帧率。避坑点解码器和 NPU 抢带宽。多路视频解码本身就很吃内存带宽如果 NPU 同时跑推理带宽容易成为瓶颈。解决办法是控制单芯片的路数或者用带独立解码硬件的方案。另外长时间运行的稳定性比峰值性能更重要一定要做 72 小时以上的老化测试。4.2 工业视觉与质检场景工业场景对实时性和确定性要求极高产线节拍是硬约束。模型通常是定制的小模型输入分辨率可能不高但要求极低的漏检率和误检率。这个场景我倾向于用 Jetson因为 TensorRT 的优化效果稳定FP16 精度对质检更友好而且工业客户对价格相对不敏感更看重可靠性。避坑点工业现场的电磁干扰和温度。芯片选型时要看工业级温度范围消费级的 0 到 70 度在车间里可能不够。另外触发和同步很关键相机触发、光源控制、推理、执行机构动作整个链路要在节拍内完成选型时要留足余量。4.3 车载与移动机器人场景车载和机器人场景的核心约束是功耗、重量、功能安全。功耗直接关系到续航重量关系到载重功能安全关系到认证。这个场景通常用专门的車规芯片或者低功耗 SoCJetson 的 Orin 系列在机器人领域用得很多因为算力足、生态好。避坑点电源设计和散热。车载环境电压波动大电源芯片要选宽压输入的。散热在密闭空间里是大问题被动散热方案要仔细算热阻。另外模型的热更新和 OTA要提前设计边缘设备分布广现场升级成本很高。4.4 消费电子与智能家居场景这个场景对成本极其敏感功耗要求苛刻模型通常非常轻量。ESP32-S3、STM32 加 TinyML、或者低端 SoC 是主流。语音唤醒、简单图像分类、传感器融合是典型任务。避坑点别高估 MCU 的 AI 能力。很多团队拿着 PC 上训好的模型想直接塞进 MCU结果发现内存不够、算子不支持、帧率惨不忍睹。MCU 上的模型要专门设计参数量、输入维度、算子类型都要围绕 MCU 的约束来。4.5 常见问题速查表问题现象可能原因排查方向解决思路NPU 利用率低内存带宽瓶颈查 DDR 带宽占用降低分辨率或换高带宽内存实际帧率远低于预期算子回退 CPU看工具链日志替换不支持算子或换芯片量化后精度暴跌量化策略不当逐层对比精度混合量化或保留敏感层 FP16满载运行降频散热不足测芯片温度加散热片或风扇降功耗配置多路视频卡顿解码器带宽争抢查解码和 NPU 并发减少路数或分芯片处理模型转换失败算子不支持看转换报错改模型结构或用手动拆图长时间运行死机内存泄漏或过热查日志和温度加看门狗优化内存管理5. 选型决策的优先级排序与经验总结5.1 我个人的选型优先级经过这么多项目我现在的选型优先级是这样的场景约束 生态成熟度 算力参数 价格。场景约束是硬边界不满足直接淘汰生态成熟度决定开发效率和长期维护成本算力参数只要满足需求就行不必追求最高价格在满足前三条的前提下再优化。这个排序和很多人的直觉相反很多人是价格优先或者算力优先。但实际项目里选了一颗便宜但生态差的芯片后期开发和维护成本会远超芯片差价选了一颗算力过剩的芯片功耗和散热成本也会吃掉利润。5.2 几个反直觉的经验第一个经验算力过剩比算力不足更常见。很多项目一上来就选最高算力的芯片结果模型跑起来 NPU 利用率只有 20%大部分算力闲置功耗和成本却上去了。正确的做法是按实际需求选留 30% 到 50% 余量就够了。第二个经验CPU 性能经常被低估。边缘 AI 不只是 NPU 的事预处理、后处理、业务逻辑、通信协议都在 CPU 上跑。CPU 太弱NPU 再强也发挥不出来。选型时要看 CPU 的单核性能和多核调度能力。第三个经验工具链的坑比硬件多。硬件问题通常有明确的排查路径工具链问题往往是玄学版本不对、算子不支持、量化精度损失每一个都能耗掉几天时间。选芯片前先花时间调研工具链的实际使用体验。5.3 给不同阶段项目的建议原型验证阶段优先选生态好、资料多的方案Jetson 或者 RK3588 开发板快速把功能跑通别在硬件上纠结。小批量试产阶段根据实际负载做基准测试确定最终芯片型号同时评估供货和成本。大批量量产阶段考虑专用芯片或者定制方案做成本优化但要做好工具链适配和算法移植的投入准备。最后分享一个我常用的判断方法如果你不确定选哪颗芯片就选那个社区案例最多、你团队最熟悉的。边缘 AI 的坑大部分不在芯片本身而在开发和部署过程。熟悉的生态能帮你省下大量试错时间这些时间比芯片差价值钱得多。
