这两年做边缘端视觉项目被问得最多的问题就是“到底选哪块芯片”我一般的回答是先别问哪块芯片先问你到底要跑什么、跑多快、跑多少路。芯片选型这事儿看起来是拼参数实际上拼的是你对场景的理解。本文就聊聊我常用的“从场景反推芯片”这套选型方法全是实操经验欢迎对号入座。1. 场景量化先搞清楚你的算力“水位线”在哪里选型的第一步不是看芯片手册而是把应用场景翻译成芯片能懂的语言——算力需求。场景翻译不到位后面全是扯皮。1.1 算力需求的三个决定性变量要估出一套边缘方案的算力底线核心就看三个变量输入数据量、模型计算密度、时延预算。三个变量互相牵制最终决定你要站在哪一档算力区间里做选择。输入数据量主要由传感器数量、分辨率、帧率决定。假设你有8路300万像素摄像头做15帧/秒的实时检测那每秒需要处理的原始像素量就是8乘以300万再乘以15算出来是3.6亿像素/秒。如果做1080P 30帧单路输入就有约6220万像素/秒。数据量直接决定了NPU或GPU需要吃进去多少数据这是算力需求的“底数”。模型计算密度取决于你选的算法。一个轻量级的MobileNetV3做分类FLOPs大约在1亿到3亿一个YOLOv5s做检测FLOPs大约在160亿如果换到YOLOv8x或者更大体量的分割模型那直接奔着几千亿FLOPs去了。模型复杂度每上一个台阶算力需求不是线性涨是接近指数级跳的。时延预算决定了你能不能“跑慢一点”。工业质检给了500毫秒的宽松时间终端设备甚至可以把几帧数据攒起来一起推理但如果是AGV避障、无人机视觉导航时延预算往往压到50毫秒以内这时候即便平均算力够用也必须选择推理延迟更低的方案甚至要为“排队等待”做出冗余设计。1.2 一张估算公式算出算力底线我常用的估算方式是算力TOPS FPS × 单帧计算量 ÷ 算力利用率。举个实际例子。你要在边缘端跑YOLOv5s目标帧率30FPS。YOLOv5s的输入分辨率是640×640时单帧推理大约需要16GFLOPs。芯片的实际算力利用率在NPU上往往只有30%到60%GPU上则看架构新旧老架构可能只有20%。假设我们按50%利用率来算那么所需算力约为30 × 16 ÷ 0.5 960 GOPS也就是约1 TOPS的INT8算力。别急着下结论说1 TOPS就够了这里还没算图像预处理、缩放、归一化、后处理NMS这些开销。实际工程里预处理和后处理往往也占用不少CPU和内存带宽尤其是多路视频流场景CPU瓶颈会比NPU瓶颈来得更早。所以我在估算后还会往上乘1.5到2的经验系数也就是至少2 TOPS才算“够得着”。各类模型在不同分辨率下的单帧算力我整理过一张常用速查表基本可以覆盖80%的视觉项目模型类型输入尺寸单帧计算量(GFLOPs)对应INT8算力需求(30FPS)轻量分类模型224×2240.5 - 20.2 - 0.4 TOPS检测模型(YOLOv5s)640×64016 - 201 - 2 TOPS检测模型(YOLOv7-tiny)640×640约130.8 - 1.5 TOPS语义分割模型512×51230 - 502 - 4 TOPS双目深度估计640×48080 - 1205 - 10 TOPS超分/大模型生成多种20010 TOPS以上上表中的算力需求已经含了利用率折损但仍建议再加上各自场景的冗余系数。算力这东西“刚刚好”在工控领域就是个伪命题现场光照一变化、算法一升级余量不足就得换硬件那是要命的返工。2. 主流边缘端AI芯片的档位划分与选型地图确定算力红线之后再来看芯片档位就清晰多了。我习惯把边缘端AI芯片按算力、功耗、外设资源、开发工具链分成三档选型时先对号入座再在档位内部做横向对比。2.1 轻量级档位MCU级与超低功耗SoC这一档主要覆盖传感器端、电池供电设备和极简控制场景。典型代表有瑞萨RA系列、乐鑫ESP32-S3、瑞芯微RV1106/RV1126、全志V853等。算力范围大致在0.2到1 TOPS之间主打一个“功耗低、成本低、启动快”。很多人觉得ESP32-S3是个Wi-Fi MCU跟AI不沾边实际上它的向量指令对部分语音关键词识别和简单异常检测是够用的。真正要跑视觉AI瑞芯微RV1106和RV1126是这档里的“小钢炮”内置0.5到2 TOPS的NPU能跑轻量检测模型典型功耗在1到2瓦。我们做过一个低功耗抓拍设备用的RV1106搭配300万像素摄像头做人脸抓拍整机功耗做到了约2.5瓦电池供电也能撑很久。这一档的软肋在于内存带宽和NPU算子支持。轻量级SoC通常只搭配DDR3或LPDDR4带宽有限跑大模型时NPU经常“等数据”。另外算子库覆盖不全有些模型层需要手工拆分或替换对算法工程师的移植能力要求比较高。2.2 中端主流档位4到10 TOPS的“黄金区间”这一档是目前边缘视觉项目里选得最多的。典型代表有瑞芯微RK35886 TOPS NPU、地平线旭日X3派5 TOPS伯努利架构、算能BM168417.6 TOPS但功耗偏高、英伟达Jetson Orin Nano8代架构最高可达40 TOPS但实际推荐按20到30 TOPS评估。先说RK3588。这颗芯片是瑞芯微的旗舰CPU是4个A76加4个A55的八核设计NPU算力标称6 TOPS支持INT8量化。实际项目里我们用它跑过8路1080P的视频结构化每路跑一个轻量级检测加跟踪模型总负载大约在40%到60%余量还算健康。RK3588最大的优势是接口极其丰富多路MIPI-CSI、PCIe、千兆网、USB3.0非常适合做边缘计算盒子。地平线旭日X3派是另一条路线它的BPU架构对CNN优化很激进官方标称5 TOPS实测跑分类和检测模型时能效比非常亮眼。但它的工具链相对封闭很多自定义算子需要走地平线的适配流程算法团队要提前评估模型兼容性。这个档位的选型核心是看你手里的算法栈和团队的工程能力。模型是PyTorch训练好的优先看英伟达Jetson系列TensorRT生态最成熟部署资料也最多模型以轻量CNN为主且对成本敏感瑞芯微RK3588的RKNN工具链这几年进步很快性价比确实高。2.3 高性能档位面向复杂多模态与大模型应用再往上走就是Jetson AGX Orin、Jetson Orin NX 16GB/32GB、算能BM1684X这些选手了。AGX Orin标称算力最高能到275 TOPSOrin NX 16GB也有100 TOPS级别实际可用算力视功耗限制和散热条件而定。这一档能跑更大的模型、多模态输入、端侧大语言模型微调推理甚至一些轻量的生成式模型。举例来说我们在一个巡检机器人项目上用了Jetson Orin NX 16GB运行一个YOLOv8m检测、一个语义分割模型、外加一个轻量OCR三模型流水线同时跑帧率还能稳定在20以上。这个量级中端档位的芯片基本扛不住。但高性能档位的代价同样明显贵、功耗高、散热复杂。AGX Orin满载功耗可以到60瓦整机散热设计不好芯片降频之后算力直接腰斩。很多团队只看了TOPS数字没算散热成本最后项目现场频繁降频报警这个坑我踩过教训特别深刻。芯片型号NPU/GPU算力(标称)典型功耗适合场景主要挑战RV1106/RV11260.5-2 TOPS1-3W低功耗抓拍、门锁、智能传感算子支持、内存带宽RK35886 TOPS5-15W边缘盒子、NVR、多路视频模型量化精度、散热地平线旭日X3派5 TOPS2-5W机器人、摄像头AI工具链封闭Jetson Orin Nano20-40 TOPS5-25W中端机器人、多路视觉开发成本、供货周期Jetson Orin NX100 TOPS10-25W复杂多模型、自动驾驶研发散热、成本算能BM1684X32 TOPS30-50W服务器级边缘、多路结构化体积大、功耗高3. 不只是TOPS精度、内存带宽与工具链才是真正的分水岭很多选型表只对比TOPS数字这在边缘端是个大误区。同一个模型在不同芯片上跑实际吞吐可能差出好几倍原因是TOPS只是理论峰值内存带宽、算子实现效率、量化支持度都直接影响真实性能。3.1 量化精度与标称算力的真假之间边缘端芯片标称算力大部分指INT8精度少数标FP16。INT8算力通常是FP16的2倍到4倍。这就带来一个容易忽视的问题如果你的模型不支持INT8量化或者量化后精度损失不可接受那你实际能用的算力就只剩标称值的四分之一甚至更低。量化这件事要分模型类型看。分类模型对INT8量化容忍度很高几乎无感检测模型稍微麻烦一点尤其是小目标检测量化后精度损失可能达到2到5个点分割模型对量化更敏感很多项目最后不得不退回FP16。所以在选型阶段就要把你自己的模型跑一遍目标芯片的量化工具链用真实数据验证精度而不是看芯片宣传册上的“支持INT8”。另外还有一个容易被忽略的概念稀疏算力。有些芯片标称的TOPS是基于50%稀疏度甚至更理想情况下的峰值跑密集网络时根本达不到。我一般只看“密集算力”的标称如果官方没有明确说明是稀疏还是密集那就默认打个六折再看。FP16与INT8之间的算力差异我举个直观对比Jetson Orin Nano在FP16下约能提供20 TOPS算力在INT8下可以到40 TOPS。如果你的算子库全是FP16的那你就只能按20 TOPS的盘子来规划很多团队按40 TOPS评估负载现场一测差一半就是这个原因。3.2 内存带宽与DDR选型算力再强数据喂不进去也白搭NPU算力强不等于整机性能强。边缘端推理是一个数据流水线摄像头采集、CPU预处理、数据搬运到NPU、NPU计算、结果回传。其中数据搬运这一环节最容易被选型时忽视。以RK3588为例它支持的LPDDR4/LPDDR5内存带宽大约在34GB/s到51GB/s之间对于6 TOPS的算力来说基本够用。但如果你跑的是高分辨率多路视频预处理时的数据搬运就会挤占大量带宽NPU可能因此频繁等待数据实际利用率往往达不到标称水平。Jetson Orin NX配的是LPDDR5带宽达到102.4GB/s这就能支撑更大的模型和多路数据并发。我实测过一个2000万像素的检测场景同样一个YOLOv5l模型Orin NX能跑实时而某些标称算力差不多的芯片因为带宽不够帧率直接掉一半多。所以选型时我会把内存带宽列入硬指标大致按“每TOPS算力至少配3到5GB/s带宽”来估算低于这个比例就要警惕。3.3 工具链成熟度决定项目交付周期的隐形变量工具链永远是我排在TOPS前面看的指标。芯片的算子库是否齐全、量化工具是否自动化、转换过程是否需要手写汇编决定了你算法组要投入多少人月去做模型移植。从实际体验来看英伟达的TensorRT最成熟算子覆盖面广量化校准工具好用社区案例也多。瑞芯微的RKNN工具链最近两年进步幅度很大从模型转换到板端调试都有完整流程已经能满足大部分视觉模型的转换。地平线的工具链针对自家BPU做了深度优化跑CNN效果很好但如果你用到了比较新的算子比如某些注意力机制的实现适配周期可能比较长。算能这边的tpu-mlir工具链是开源的灵活性高文档相对工程师友好上手有一定门槛适合有AI编译器经验的团队。我自己的建议是选型时让算法负责人拿2个核心模型去目标芯片上各自跑通一遍推理记录从拿到芯片到模型跑通的天数。这个天数就是工具链成熟度最真实的注脚比任何宣传文档都有说服力。4. 实战心法从零推演出一个场景的芯片选型过程光讲理论容易飘我拿一个实际项目完整走一遍“从场景反推芯片”的流程。这个项目是某工厂的安全生产监测系统需要实时识别人员是否佩戴安全帽、是否靠近危险区域。需求拆解后大概是这么个情况部署12路摄像头每路1080P 25帧采用YOLOv5s作为检测模型要求检测结果延迟小于300毫秒系统需7乘24小时连续运行整机功耗希望控制在30瓦以内。4.1 从需求到算力评估的推导过程先算单路负载YOLOv5s在640×640输入下单帧约为16GFLOPs25帧对应每秒400GFLOPs计算量。考虑到目标检测实际输入通常保持原始分辨率附近预处理的缩放和归一化消耗先不细算按NPU利用率50%折损后单路需求的INT8算力约为0.8 TOPS。12路全开就是约9.6 TOPS。再乘一个我习惯预留的1.5倍冗余系数得到最终需求约为15 TOPS的INT8算力。接下来看整体功耗余量。整机控制在30瓦以内扣除外围器件摄像头、交换机、风扇等大约8瓦留给主板的功耗约22瓦。这就意味着芯片满载时的功耗不能超过15瓦左右否则散热压力会非常大。结合算力需求和功耗约束范围很快就缩小到了RK3588和Jetson Orin Nano这两颗芯片上。4.2 两者对比与最终选择的决策逻辑RK3588标称6 TOPS单颗不能满足15 TOPS的需求但如果分两台设备、每台6路每台需求降到约5 TOPS余量刚好够用功耗也能压在15瓦以内。Jetson Orin Nano标称20到40 TOPS一台设备就能扛12路功耗按配置在10到25瓦之间所以单机方案用Orin Nano是更合理的选择。接下来的决策重点转向了开发效率和成本。项目算法基于PyTorch训练部署时TensorRT的成熟度明显优于RKNN工程组对英伟达的部署链路也更有经验。而且这个项目不愁供应交期整机预算也允许上Orin Nano。最终我们选择了Jetson Orin Nano但在实际规划中留了一个重要备份把部分预处理和后处理放到CPU上并行执行减轻NPU负载确保长期运行时的稳定帧率。5. 常见选型误区与避坑手册那些容易返工的“隐形炸弹”边缘端AI选型的坑比参数表上写出来的东西多得多。很多项目初期看着参数没毛病一到现场就拉胯我盘点几个高频雷区。5.1 只看标称算力忽略持续性能标称算力通常是芯片在理想散热、理想功耗下的“峰值瞬时算力”。实际边缘设备往往是密封机箱、被动散热甚至60度高温环境芯片会主动降频保护持续性能和峰值可能差出30%甚至更多。这里有个非常现实的指标叫“持续推理性能”很多厂商不写在宣传页里需要自己实测。我的做法是拿到评估板后不跑基准测试单帧指标而是连续跑至少30分钟以上的满负载推理看最后的平均帧率和CPU温度。这个数字才是选型的真实依据尤其是项目要7乘24小时运行的话这一步骤绝对不能省。5.2 忽视内存带宽与数据搬运瓶颈前面提过内存带宽不足会让NPU“等数据”。但在某些场景里问题更隐蔽多路视频接入时数据从ISP到CPU再到NPU的搬运路径如果没有优化会产生大量CPU拷贝开销。我见过一个项目芯片标称算力高得吓人但实际帧率上不去查了半天发现是图像缩放这个最基础的预处理在CPU上反复拷贝CPU占用率已经打满了。这个坑的应对方式一是把预处理尽量下沉到ISP或硬件加速模块二是合理使用零拷贝接口三是评估板阶段就要做好多路视频流的全链路压测别只测NPU单独推理的帧率。5.3 算子兼容性评估不足模型跑不通芯片厂商说“支持主流CNN模型”但“支持”和“高效支持”是两回事。有些算子虽然工具链支持但实现效率很低有些算子甚至需要手写自定义实现工程成本直接飙升。我在选型阶段会做一次算子扫描把目标模型的每一层都映射到芯片的算子库上逐层查看是否有降级实现或缺失实现。特别提醒几个高频问题算子Focus层YOLOv5早期版本用得多、各种注意力机制模块SE、CBAM、Transformer块、动态尺寸相关的算子如动态NMS。这些在网络里可能只占很少的比例但恰恰是移植时最容易卡住的地方。一个经验丰富的算法工程师在处理这些问题时通常会微调模型结构或者提前在训练阶段就把结构向目标平台的算子库靠拢。6. 从场景出发的选型决策清单照着打钩就不容易翻车把散落的经验收拢一下我整理了一份选型决策清单按照这份清单走一遍至少能砍掉一半以上的错误选项。场景需求确认清单明确输入路数、分辨率、帧率计算出每秒总像素量。跑真实模型统计各模型单帧计算量和目标帧率算出最小算力需求。根据可靠性要求预留1.3到2倍的算力冗余。确认模型精度需求明确能否接受INT8量化是否需要FP16支持。统计整机功耗预算包括散热、电源转换损耗反推芯片可用功耗。对时延敏感场景评估芯片端到端推理延迟而不是只看吞吐量。芯片评估确认清单标称算力是否区分稀疏与密集按密集算力打折处理。内存带宽是否满足数据搬运需求按每TOPS约3到5GB/s估算。工具链对核心算子覆盖情况实际跑通目标模型需要多少天。散热方案是否匹配持续满负载运行。供货交期、成本、长期可用性是否有第二供应商备份方案。开发与运维确认清单评估板驱动、BSP、文档的完整度。是否有预集成好的边缘AI中间件如视频流管理、算法调度框架。现场升级方式是否方便是否支持远程批量更新模型。团队自身的技术栈与芯片工具链的匹配程度。我在每个项目启动前都会把这两份清单过一遍把评估不到位的项目卡在立项阶段而不是等到样机出来再返工。边缘端AI芯片选型本质是一场围绕场景需求、算法约束和工程成本的三角博弈参数表只是入场券真正决定胜负的是你对这个三角的理解深度。
