这几年给不少团队做过边缘AI项目的方案评估见过太多翻车现场。有人照着宣传页上的TOPS值买了块大算力开发板做到产品定义阶段才发现功耗和散热根本压不住整机结构、电源、成本全部推倒重来也有人为了省成本选了便宜芯片部署时才发现关键的几个算子不支持模型根本跑不起来。这些坑的根源其实出在同一个地方大家都是先看芯片参数再回头找场景顺序反了。边缘端AI算力选型真正靠谱的思路是从场景反推芯片。先把业务场景翻译成一串可测量、可校对的工程参数比如输入分辨率、帧率、模型计算量、时延预算、功耗边界再拿着这堆参数去匹配具体平台。这篇东西不打算给你罗列芯片天梯图而是把我这几年实践中验证过的“场景反推法”完整梳理一遍从量化需求、算力换算法则到主流平台对比、常见坑点全部摊开讲适合正在做边缘视觉、智能硬件、工业检测、无人机/机器人产品的工程师和项目负责人参考。1. 为什么“从场景反推芯片”才是正确的选型姿势1.1 先选芯片再做方案的典型翻车路径我接触过一个做充电桩智能监控的团队最初选了当时社区热度最高的方案理由很实在教程多、资料全、跑Demo快。结果量产评估时发现三个问题一是目标终端是7x24小时户外部署对整机功耗卡得很死那块板子满载功耗远超预算二是客户要求所有数据本地处理、不上云单台成本必须压到三位数以内而那颗芯片加外围的成本直接逼近整机预算三是产品是密封外壳没有主动风扇芯片一旦在夏季高温下持续跑检测模型就触发降频实测识别帧率直接掉到标称值的四成。最后方案推倒重来大半年时间浪费在返工上。这种翻车不是个例。不少团队拿着开发板先跑通Demo把技术验证做完了才发现产品化的路走不通。核心原因就是选型的起点错了从“我手上有什么芯片”出发而不是从“场景到底需要什么”出发。开发板阶段的顺利会给人错觉等真正围绕芯片做整机设计、做功耗控制、做成本核算的时候才发现这个芯片压根不是为这个场景准备的。1.2 场景反推的本质把业务语言翻译成工程参数“从场景反推芯片”并不是什么玄学它本质上是把模糊的业务需求拆解成一组可量化、可验证的工程指标。比如客户说“要识别流水线上的螺丝缺陷”这句话没法直接对应到TOPS你得先搞清楚相机分辨率是多少产品经过视野时的运动速度有多快需要几毫秒内输出结果现场有没有强光干扰算法要不要跑多级模型级联设备是市电供电还是电池供电单台物料成本上限是多少。这些信息整理清楚之后选型就变成了一道不那么难的匹配题。关键是要养成一个习惯永远先填需求清单再去看芯片。需求清单上每一项都有对应的芯片指标分辨率乘帧率决定处理吞吐模型结构决定需要的每秒乘加次数功耗和散热方式决定芯片的典型功耗上限时延预算决定CNN还是更轻量的模型结构成本约束直接筛掉一大半候选平台。也只有走完这一步不同芯片之间的比较才有意义。脱离场景谈算力就和脱离预算谈买车一样除了制造焦虑没有别的用处。2. 把场景翻译成算力指标五个必填参数与精度换算2.1 选型前必须填清楚的五个必填参数先给一个可以直接抄走的参数模板我每次做选型评估都会先让项目方把这张表填完填的过程中一半的问题就暴露出来了。第一个参数是输入规模与帧率。这决定了系统的数据吞吐底线。一台设备接几路相机每路的分辨率是多少目标帧率是多少合在一起就是每秒需要处理多少像素。很多人会习惯性地填“4K30帧”但如果场景只需要检测静止目标或者慢速传送带1080P 20帧就够了分辨率越高后端的计算量、带宽、存储压力全部指数级上升。第二个参数是算法模型清单与输入尺寸。这里不要求把网络结构背下来但要知道业务目标对应什么量级的模型。简单的物体分类、唤醒词识别可能只需要几M到几十M的MACs每帧目标检测通常需要几G MACs每帧像高精度分割、姿态估计、Transformer结构模型则要十几G甚至几十G MACs每帧。模型的输入尺寸也非常关键320x320和640x640差了四倍计算量很多芯片就是被这一步压垮的。第三个参数是端到端时延预算。不同场景对时延的敏感度完全不同闸机刷脸通常几百毫秒内可以接受但工业机械臂的视觉引导可能需要100毫秒以内的响应这时候不仅要看NPU推理速度还要把摄像头曝光、图像传输、预处理、后处理、通信协议等全链路时间都算进去。时延预算越紧对算力余量和系统架构的要求就越高。第四个参数是功耗与散热边界。电池供电设备和市电供电设备是两种完全不同的选型逻辑。电池设备要盯紧典型功耗和峰值功耗视觉计算的瞬时负载波动很大选型时不能只看平均功耗无风扇密封设备则要关注芯片的TDP上限和降频策略否则算力标称值再高实际稳态吞吐也会被散热压住。这个参数直接决定了芯片等级区间很多人到后期才发现散热改不动只能在前面做减法。第五个参数是成本与供货约束。单台BOM里算力芯片能占多少预算直接决定你是在MCU级别选还是SoC级别选是在国产平台选还是进口平台选。同时要了解芯片的生命周期状态、是否有替代料、原厂支持力度如何。边缘AI产品从立项到量产通常要半年到一年以上选了一颗即将停产的芯片后面每走一步都在给自己挖坑。2.2 int8、fp16、fp32、fp64到底怎么影响算力需求选型参数里有一个经常被忽略但又极其关键的项目模型推理精度。很多芯片规格书会同时标注FP32、FP16、INT8下的不同算力值而它们对应的实际推理能力差距巨大。搞清楚这几种精度意味着什么是评估算力需求的前提。FP64双精度主要用于科学计算、仿真和数值分析这类对精度极度敏感的领域边缘AI推理场景基本不会碰。FP32单精度是GPU通用计算的经典格式训练和早期推理常用但硬件单元开销大同芯片下算力通常最低。FP16半精度是训练和推理之间的折中方案很多NPU和GPU原生支持计算密度比FP32高一倍是边缘端推理的重要精度档位。INT8整型量化则是目前边缘端推理的主流由于整数运算单元更简单、并行度更高理论算力通常又是FP16的两倍。这就带来一个选型常识同一颗芯片在FP32、FP16、INT8三种精度下的标称算力比值大概在1比2比4左右具体看硬件架构。评估模型的算力需求时如果模型已经做了INT8量化就用INT8的TOPS值去对比如果模型还处在FP16阶段就按FP16算力对比。很多团队拿INT8标称算力去匹配一个还没做量化的模型最后实测帧率对不上还以为芯片虚标。我的建议是不要一上来就追求INT8。INT8量化需要校准数据集对敏感层有精度损失风险工具链支持程度也参差不齐。实际操作中最稳妥的路径是先用FP16精度做完整的功能验证算法效果达标后再做INT8量化量化后精度损失如果可控再按INT8算力评估部署规模。这样流程上多花一点时间但每一步都在为后面的量产排除风险。2.3 从GMACs到TOPS手把手算一遍单帧算力需求量化算力需求时最常用的单位是GMACs十亿次乘加运算和TOPS每秒万亿次操作。两者之间有一个固定换算对应关系一次乘加通常算两次操作1 GMACs约等于2 GOPS也就是0.002 TOPS。把这个换算公式记牢后面所有计算都是套用。以一个常见的工业场景为例我需要在边缘盒子里面跑YOLOv5s目标检测输入分辨率640x640目标帧率30fps。YOLOv5s在640输入下单帧计算量大约8 GMACs左右。单路视频30fps需要的原始算力就是8乘以30等于240 GMAC/s换算成TOPS就是480 GOPS约0.5 TOPS。到这里很多人会觉得“不就这样吗0.5 TOPS随便一片芯片就够”。问题在于这不是最终答案。算力需求必须考虑三个修正系数。第一是NPU利用率实际部署后受算子实现、内存搬运、流水线停顿影响NPU利用率很少有超过70%的常见区间在40%到60%所以至少按两倍余量评估。第二是CPU侧后处理目标检测不是推理完就结束还有NMS、坐标映射、逻辑判定这些后处理要跑在CPU上分辨率越高、目标越多CPU占用越不可忽视。第三是系统其它任务视频解码、ISP处理、通信协议栈、日志存储都会抢占资源。综合下来0.5 TOPS的算力需求至少要放大到1.5 TOPS左右才算稳妥。如果场景是4路1080P视频同时做检测那就是0.5乘4等于2 TOPS原始算力需求放大到6 TOPS级别。这个数字正好对应RK3588这类主流边缘SoC的INT8算力区间。很多产品选择RK3588做多路视觉方案并不是巧合而是场景需求推导下来的自然结果。真正合理的选型过程就应该是这个样子的从业务场景推导出一个让人信服的数字然后让芯片特征去匹配这个数字。3. 主流边缘AI芯片平台横评算力分级与隐性门槛3.1 边缘AI芯片的四个算力等级把市面上常见的边缘AI平台按照算力量级分了四个档位每一档对应不同的典型场景、功耗区间和成本区间。第一档属于MCU级代表平台有ESP32系列、STM32部分带简单加速器的新型号。这类平台没有像样的独立NPU算力通常不以TOPS为单位标称而是用CoreMark、TinyML基准来体现。它们适合唤醒词识别、震动异常检测、温湿度分类这类极轻量的TinyML任务模型大小被严格限制在几百KB以内。这种方案的本质卖点是成本极低、功耗极低、启动快、可靠性高适合海量传感器节点。第二档是轻量SoC级别代表平台包括瑞芯微RK3566/RK3568、全志系列、算能的一些低功耗边缘模组。算力大致在0.5到2 TOPS之间可以跑单路720P或1080P的轻量检测、分类、人脸识别模型功耗控制得当BOM成本友好。很多智能门锁、低功耗IPC、便携式识别设备都落在这个区间。第三档是主流SoC级别代表平台是瑞芯微RK3588/RK3576、地平线旭日X3系列、英伟达Jetson Orin Nano以及国内厂商的一些带加速卡的模组。算力在5到40 TOPS之间。这一档是当前边缘AI产品的主力区间能覆盖多路视频流分析、YOLO系列检测、人脸识别、车牌识别、OCR等等。它们普遍集成了较完整的NPU工具链也具备跑一定规模Transformer模型的能力。第四档是大算力模组和独立加速卡级别代表平台有Jetson Orin NX、Jetson AGX Orin、Atlas边缘计算模组、算能BM1684X等。算力从几十TOPS到两百TOPS以上。这里支持更大分辨率、更高帧率、Transformer结构的视觉模型甚至边缘侧跑大语言模型的实验也在这个区间。代价是功耗、体积、成本同时上升量产的散热设计复杂度明显提高。这里还要补一个概念不同厂商的TOPS标称口径并不统一。有的标INT8稠密算力有的标INT8稀疏算力有的标FP16算力。英伟达的TOPS口径通常支持稀疏加速实际稠密推理时标称值要打折扣国产芯片有些标的是“等效算力”“AI算力”具体实现和理论峰值之间差距更明显。对比平台时必须先统一口径否则就是在拿苹果比橘子。3.2 两大主力平台深度对比RK3588与Jetson系列怎么选当前边缘AI项目里被问得最多的对比就是瑞芯微和英伟达这两条路线。它们的逻辑完全不同适合的场景也差异很大简单说“谁更强”没有意义。瑞芯微RK3588的核心价值是“性价比够用”。它有6 TOPS左右的INT8 NPU集成8核CPU、GPU、丰富的视频编解码能力典型功耗大概在3到10瓦区间配合被动散热也能持续输出算力。RKNN工具链经过几年迭代对YOLO系列和常见CNN的支持已经比较成熟。它的供货和成本优势让它在国内做整机产品的团队里接受度很高。缺点也明显工具链的灵活度不如英伟达对复杂算子和新模型的适配速度慢很多冷门算子需要自己写自定义算子或者等官方更新。英伟达Jetson系列的核心价值是“生态成熟且上限高”。Orin Nano这种入门级模组标称算力就远高于RK3588Orin NX和AGX Orin则进入了大算力区间。TensorRT推理引擎经过十几年打磨算子覆盖、量化工具、模型优化能力都是目前边缘端最成熟的很多团队在Jetson上迁移模型只需要很少的时间。Jetson的劣势是价格和供货以及功耗随性能提升增长很快要做好散热设计需要额外投入。对于做原型验证、算法快速迭代、高附加值产品的团队Jetson依然是最省心的选择。我的建议很简单团队还在技术验证阶段、需要快速验证算法效果直接上Jetson产品定义明确、追求成本可控、目标场景是固定功能的批量部署优先考虑RK3588这种国产SoC。真正让这两个平台拉开差距的往往不是TOPS数字而是你的团队对哪条工具链更熟悉以及产品的供货安全策略。3.3 容易被忽略的隐性指标内存带宽、稳定吞吐与工具链只看TOPS做选型是最容易交学费的做法。因为TOPS只描述理论峰值的上限和实际业务能拿到的有效算力之间隔着好几道坎。第一道坎是内存带宽。NPU要做运算数据必须从DDR搬到片上SRAM运算完再搬回去。如果数据搬运速度跟不上运算速度再高的TOPS也只能空转。所有主流边缘芯片的内存带宽其实都有上限像入门级平台带宽可能只有十几GB/s中高端模组在50到100GB/s甚至更高。跑低分辨率小模型看不出差别一旦跑高分辨率大图或者全图patch密集推理带宽瓶颈立刻凸显。验证方法很简单在目标平台实测大批量推理的稳定吞吐看是否有带宽受限导致的非线性下降。第二道坎是稳定吞吐而非峰值算力。芯片标称的TOPS都是瞬时峰值能力实际持续运行会因为温度、供电、任务调度等因素下降。很多边缘设备是7x24小时运行的评估算力时应该用“连续工作2小时后的稳态FPS”作为依据而不是Demo启动前几秒的瞬时FPS。第三道坎是工具链的算子覆盖范围。这一点怎么强调都不过分。芯片标称的算力再高如果模型里某个算子不兼容要么算子掉到CPU执行导致速度骤降要么整个模型根本无法转换。常见的坑点包括Transformer的Attention结构、非标准激活函数、动态尺寸输入、自定义后处理逻辑。选型阶段就应做一次“算子兼容性预检”花一周时间在目标芯片上把真实模型完整跑一遍比研究任何参数表都有价值。4. 从需求到型号的完整选型流程问卷、计算过程与真实案例4.1 一张可以直接抄的选型需求问卷我沉淀了一张“边缘AI算力需求问卷”每次做项目评估都直接丢给需求方填写。这张表的价值不在于字段多而在于逼着项目方把模糊的业务想法变成可执行的工程参数。字段需要填写的内容这个字段决定什么接入路数同一设备同时接入几路图像/音频信号算力需求的总乘数输入分辨率每路原始信号的分辨率决定带宽与预处理压力目标帧率业务要求的处理帧率决定算力的时间维度模型清单每个任务对应的算法模型及输入尺寸决定单帧计算量GMACs时延预算从信号输入到结果输出的最大允许时延决定是否要GPU/NPU协同供电方式市电/电池/太阳能是否允许峰值功耗冲击锁定芯片功耗等级散热条件密封壳/主动风扇/整机结构余量决定实际稳定算力成本目标单台BOM目标价和年产量直接淘汰一批平台供货要求是否要求国产化、生命周期要求缩小候选范围团队熟悉度是否熟悉某芯片工具链影响开发效率和风险这张表填完之后剩下的工作就是机械的算力和成本匹配。如果一个团队填不出来分辨率、帧率、模型清单那说明产品定义本身还没成熟这时候不动手选型才是最优解。4.2 案例一多路工业质检设备的完整推算过程拿一个真实的工业质检项目来演示整条计算链路。设备要接入4路500万像素工业相机相机分辨率2448x2048用于检测金属表面的微小缺陷产线节拍要求每路达到10fps处理速度。项目方最初的想法是“500万像素看起来不算特别高找一片入门级芯片试试”。我给他们算了一笔账。缺陷检测模型通常是ResNet类骨干网络输入尺寸如果是512x512单帧计算量大概在10 GMACs量级。但这里的关键是500万像素原图不能直接缩放成512x512整体推理那样会丢掉微小缺陷细节实际方案是把2448x2048的原图切成若干256x256或512x512的patch逐个推理一张图算下来往往有20到60个patch。按平均40个patch计算单帧总计算量是40乘以10 GMACs等于400 GMACs也就是0.8 TOPS的单帧需求。再乘4路相机、乘10fps帧率每秒需要处理16000 GMACs换算下来约32 TOPS的原始算力。留出NPU利用率和CPU后处理余量之后至少需要50 TOPS级别的平台。这和项目方最初设想的“入门级芯片”完全不是一个量级。这个案例最有价值的地方在于提醒大家不要被“单帧模型计算量”迷惑要始终把“业务真实输入”放在第一位。工业视觉里分辨率膨胀带来的patch爆炸会让算力需求指数级上升。碰到这类场景先做计算量拆解再选芯片千万别拍脑袋。4.3 案例二无人机机载视觉的低功耗权衡另一个常见场景是无人机电力巡检机载端挂一个摄像头做绝缘子、杆塔、异物检测。原始需求是4K30帧视频输入在机载设备里实时识别并把结果叠加回图传。4K30帧听起来很唬人但实际业务根本不需要每帧全分辨率推理因为目标和无人机之间距离比较稳定。最终的工程方案是缩小检测区域并抽帧处理每秒钟只对选定的ROI区域做10帧检测检测模型的输入也只有640x640用的还是YOLOv8n这种轻量模型单帧计算量约4 GMACs。这样算下来单帧0.4乘以10帧等于4 GMAC/s原始算力只有0.01 TOPS量级放大的芯片选型区间甚至不到1 TOPS。但这里真正卡人的不是算力而是功耗和重量。无人机整机电源预算极其紧张机载设备要控制重量散热条件也差所以选型反而落在了轻量SoC级别甚至回到了MCU加轻量NPU的组合。这个案例说明一个反直觉的事实从场景反推并不意味着永远选大算力有时候精算之后发现需求很小用小芯片压低成本和功耗才是最优解。知道不需要什么算力一样是选型的重要结论。4.4 配套元件也要在同一轮定下来电源、保护与可靠性设计芯片算力选型永远不是孤立的它会连带决定整机设计里一大堆配套选择。很多团队在看芯片的时候只看了Datasheet和开发板没有同步看外围配套等原理图阶段再发现选型冲突返工成本非常高。首先是电源设计。算力越高的SoC对供电质量越敏感。RK3588这类平台的负载电流波动极大可能瞬间从几毫安拉到几安培电源路径上的电感选型要关注额定电流和饱和电流不能只看标称电感量TVS管选型要关注钳位电压和浪涌吸收能力尤其是户外部署设备要面对雷击浪涌和电磁干扰电池供电的设备还要考虑电池保护电路像锂电池常用的8205这类MOS保护芯片以及相应的充放电管理方案。这些元件一个选错整机稳定性就会出问题。其次是可靠性设计。边缘设备经常部署在无人值守的地方死机、卡死、程序跑飞是常态。所以硬件设计上要预留看门狗芯片一旦系统异常自动复位对外接口要做好静电保护和防反接防止现场接线失误烧毁主板。布局上还要考虑电容的放置位置和电源层的分割否则系统在满载推理时容易因为电源纹波导致死机。这些内容虽然不是算力选型的核心但它们是任何一款边缘AI产品走向量产都要过的关。5. 落地阶段常见问题与避坑清单5.1 为什么芯片标称6 TOPS实际能用只有3 TOPS如果要用一句话总结边缘AI项目里最普遍的误区就是把这个阶段都集中在一组对比中见下。常见问题现场表现深层原因解决建议标称算力虚高实际推理帧率只有理论值的一半厂商标称值多为稀疏INT8峰值稠密推理要打折NPU利用率有限用稳态真实模型实测不迷信标称内存带宽不足提高分辨率后帧率急剧下降数据搬运速度成为瓶颈优先考察DDR带宽测试大输入下的吞吐算子不兼容模型转换失败或某些层掉到CPU工具链不支持特定算子选型前做算子兼容性报告和POC散热触发降频持续运行后性能明显下降芯片过热保护限制频率用目标散热条件做24小时长稳测试后处理吃掉CPUNPU很快但整体时延不达标NMS/解码/协议栈抢占CPU资源架构设计时算上CPU侧负载工具链迭代快旧代码在新版本无法编译NPU工具链API不稳定锁定工具链版本并跟随官方支持窗口标称6 TOPS的国产SoC实际用YOLOv5s这类模型跑稳态推理在完全优化的情况下能稳定拿到3 TOPS左右的有效吞吐就已经相当不错了。一方面是因为INT8稀疏算力和稠密算力的差距另一方面是NPU利用率很难到百分百。模型里的算子越多、张量维度越复杂、动态分支越多利用率越低。选型时把标称算力乘0.4到0.6作为“可信算力”再去做匹配能少踩很多坑。5.2 算子兼容性检查选型阶段就必须做的POC我见过最惨痛的一个案例是某团队完成全部应用开发后才发现目标芯片的工具链不支持模型里的一个关键上采样算子导致整个模型要么改结构重训、要么用CPU跑。无论哪种方案项目周期都要往后拖两三个月。这个风险完全可以在选型阶段用一周时间规避掉。正确做法是选型阶段就做一个最小化POC把目标模型完整导出用芯片官方工具链做转换看算子支持情况、逐层耗时、量化后精度然后在开发板上跑真实数据流并记录功耗。这项工作看起来提前投入了一周时间实际能帮后面省下几周甚至几个月的返工时间。我在评估一个新平台时POC是绝对不省略的步骤。另外工具链版本要盯紧。很多NPU型号的工具链处于快速迭代期算子支持能力变化很大。做产品选型时要把工具链版本和模型的兼容矩阵一并锁定避免开发到一半因为工具链升级导致整套代码失效。5.3 散热与功耗的真实边界别把瞬时算力当成持续算力产品化阶段最容易出现的问题是开发板环境和量产环境之间的巨大差异。开发板在桌面上敞开放着有散热风扇吹着环境温度25度测出来的性能非常好看。产品被放进密封壳里夏天户外45度环境温度没有任何风道同样的芯片持续运行性能可能只剩三分之一。边缘AI设备的散热量直接和算力成正比。10瓦级别的芯片做无风扇设计已经需要仔细考虑均热板和外壳散热面积25瓦级别几乎必须主动风冷或大体积金属外壳100瓦以上基本要上热管甚至液冷方案。所以选型阶段就要问产品形态允许多大散热面积、使用环境温度区间是多少、有没有风扇噪音限制。这几个问题的答案会和TOPS值一样硬性影响最终选型。5.4 常见问题速查表与我的排查经验给一张实用性优先的速查表都是我在项目里真实踩过或看别人踩过的坑可以直接作为排查起点使用。问题现场排查方向优先级模型转换失败报算子不支持查看工具链算子支持列表确认模型结构最高帧率比预期低一半先查NPU利用率再查数据搬运耗时最高跑一会儿就开始卡顿查温度曲线和降频日志看散热设计高增加一路视频后整体性能明显下降查内存带宽占用和CPU占用可能不是NPU瓶颈高同一模型在不同版本工具链下性能差异巨大对比工具链版本优化策略锁定版本中单板性能达标但批量不一致查电源纹波、DDR颗粒批次、芯片体质中我的排查习惯是永远先建立“基准数据”再做优化。拿到目标芯片的第一天就先记录一套标准模型的帧率、功耗、温度基线。后面无论遇到什么问题都拿当前数据去和基线对比。没有基线所有问题排查都会变成猜谜游戏有了基线偏差和异常都一目了然。6. 写在最后几个用血泪换来的选型建议这几点建议不来自任何一份规格书都是我做项目过程中实打实总结出来的。第一永远给算力需求留足余量。算法团队优化模型只会让它越来越准而准确率提升往往意味着计算量上升分辨率升级、检测类别增加、客户新需求加入这些都是项目生命周期里一定会发生的事情。选型时按计算需求留30%到50%的余量不会让你多花多少成本但能避免一年后就面临算力瓶颈的尴尬。第二不要迷信“最新最强”。边缘AI项目的量产周期通常很长今天参数表上最亮眼的芯片往往供货还不稳定、工具链还不成熟、参考设计还在迭代。我更倾向选择发布一年以上、有大量量产案例、工具链稳定的“次新”平台。工程项目的胜利靠的是确定性不是数据表的华丽。第三团队熟悉度对开发效率的影响被严重低估。一个团队如果已经熟悉了某家芯片的交叉编译、量产烧录、算子开发流程换到另一家平台的学习成本往往抵得上几个月的开发工时。在候选芯片性能差距不超过两倍的前提下选团队更熟悉的那个平台通常总成本更低。第四如果实在拿不准就先买两块最候选的开发板回来各自跑一遍真实模型看转换难度、看稳态性能、看在恶劣散热条件下的表现。几百块的开发板成本对比一个错误选型带来的整体返工真的不值一提。边缘端AI算力选型没有标准答案但找答案的方法论是通用的。把场景需求量化清楚把精度、帧率、功耗、成本这些变量翻译成芯片参数再结合工具链和供货情况做取舍大概率不会选错方向。