边缘端 AI 选型这个事我见过太多团队一上来就盯着“哪块芯片最强”不放。实际动手才发现芯片选贵了项目成本扛不住选低了模型在板子上跑不到实时最头疼的是那些纸面参数相当漂亮的 NPU一到真实模型上就露馅。我自己做了几年边缘端 AI 落地也踩过不少坑慢慢形成的习惯是从场景反推芯片先把应用需求拆成能量化的硬指标再拿着这些指标去跟芯片的真实能力做匹配。这篇文章就把这套思路完完整整分享出来覆盖从 MCU 到中高端 NPU 的主流方案适合硬件工程师、算法工程师、以及正在做边缘端 AI 产品预算和选型的技术负责人参考。1. 从场景反推芯片的选型逻辑别先问“哪块芯片强”1.1 先芯片后场景是边缘端项目最常见的死法很多人选边缘端 AI 芯片的路径是看新闻、看排行榜、看友商用了什么然后直接买一块市面上最热的开发板跑一个 Demo发现能跑通就开始设计产品。这种“先有锤子再找钉子”的模式在边缘端 AI 项目里失败率极高。原因很简单。芯片厂商给出的算力数字都是在特定条件下测出来的峰值。比如某个 NPU 标称 6 TOPS它可能是在 INT8 精度、特定网络结构、特定输入尺寸、甚至开了稀疏加速的情况下测出来的。你把真实的业务模型丢上去跑出来的帧率可能只有标称值的五分之一甚至更低。如果一开始是按照峰值算力去规划产品的等模型部署到现场就会很被动。反过来走就稳多了。先把场景看清楚要处理几路视频分辨率多高模型多大延迟要求是秒级还是毫秒级设备供电是电池还是 PoE 供电工作环境温度多高批量成本能到多少钱把这些变成一组可量化的数字再拿着数字去匹配芯片逻辑上是闭环的而且每一步都能算、能验证。1.2 三种典型的“死于选型”方式结合我看到的项目反馈选型翻车主要集中在三种情况。第一种是算力预算过于乐观。项目规划时按标称 TOPS 算帧率等到真实模型跑到板子上帧率不够用只能临时换更高档位的芯片外壳、散热、电源、PCB 全部推翻重来成本和周期一起失控。第二种是预算过于保守。为了省几十块钱选了低端芯片结果模型勉强跑通系统吞吐已经满了摄像头多一点、画面频闪大一点就没法处理后续想升级功能就只能换平台。第三种是忽略了非 AI 部分的配套能力。边缘端 AI 从来不是只有 NPU 就够了。视频进来要经过 ISP 处理、硬解码、内存搬运输出要做显示或编码这些环节的带宽和算力消耗往往比 NPU 本身还大。选芯片只看 NPU不看 CPU、编码器、ISP、内存控制器这些配套模块最后做出来的系统要么功耗爆表要么延迟高到没法用。1.3 场景反推的正确顺序我通常按下面的顺序推进选型这套顺序基本可以套用到绝大多数边缘端 AI 产品上。第一步定义业务输入几路传感器、什么分辨率、什么帧率、什么接口。第二步定义 AI 模型模型类型、输入尺寸、量化精度、每帧推理计算量。第三步定义性能目标单帧时延、端到端吞吐、功耗上限、工作环境温度。第四步定义成本边界单板 BOM 成本、外壳散热成本、批量价格目标。第五步拿前四步的约束条件去筛选芯片平台列出候选清单。第六步用真实模型在候选平台上跑基准测试跑完再做最终决策。这一步一步走完芯片选型就变成了一个匹配和验证的过程而不是拍脑袋。接下来我就把第二步和第三步里“如何把场景翻译成算力需求”这个关键环节展开讲。2. 把场景翻译成算力需求四个必须锁死的参数场景本身很抽象“做一个人脸识别门禁”“做一套河道垃圾检测系统”这种描述不能直接用来选型。你得先把场景拆成四个硬件选型直接相关的参数。2.1 像素吞吐量和编码路数视频类的边缘端 AI 项目第一件事是算清楚一秒要处理多少路画面。但这里有个很容易混淆的点AI 推理的输入尺寸不等于视频原始分辨率。大多数目标检测模型不会习惯直接拿 1920x1080 的全图去推断而是会先做缩放、裁剪或者其他预处理喂给模型的可能是 640x640 或 416x416。即使你的摄像头输出 1080pAI 计算量也不等于 1080p 全分辨率的推理而是等于模型输入分辨率下的推理。不过视频流进来之后的第一关并不是 NPU而是解码和 ISP。1080p 30 帧画面的 H.265 硬解码、色彩转换、缩放、归一化这些操作全部要占用系统资源。如果你的产品是 8 路 4K 摄像头同时接入那 CPU 和编解码器的压力会非常大。这类项目对芯片的要求除了 NPU 之外必须同时关注视频解码能力和内存带宽。具体计算时我习惯用“每秒总像素数”给系统打个底摄像头路数乘以单路分辨率乘以帧率得到一个 Pixels/秒 的数字。这个数字决定了芯片的视频编解码规格、ISP 能力以及内存带宽需求。它和 NPU 算力是两个维度不要混在一起看。2.2 模型的类型和单帧计算量算力需求真正的核心变量是模型计算量。不同模型类型计算量差异巨大。一个轻量级图像分类模型比如 MobileNetV3 或者是用于唤醒词识别的语音模型单次推理可能只有几 MOPS 到几十 MOPS。这类负载对算力的要求极低MCU 级别都能跑。一个基于 CNN 的目标检测模型比如 YOLOv5s 在 640x640 输入下单帧计算量通常在一二十 GMACs 这个量级。这里的 GMACs 是 Giga Multiply-Accumulate十亿次乘加运算。一次乘加在深度学习里通常按两次浮点或整数运算来算。一个基于 Transformer 的模型比如 RT-DETR 或者边缘端跑视觉大模型计算量会进一步攀升可能到几十 GMACs 甚至上百 GMACs同时模型参数量变大对内存带宽和模型并行度的要求也更高。选型的时候先把你准备部署的模型确定下来算一次前向推理的 GMACs再乘以目标帧率就能得到一个很粗略的算力需求下限。这个数字很重要但它只是理论下限实际工程中还有一层折损这部分后面专门讲。2.3 延迟预算和功耗上限延迟决定了对算力的“实时性”要求。同样是 10 帧每秒的检测任务如果是制造业质检允许 200 毫秒的延迟问题不大如果是无人车避障或者是无人机避障延迟要求可能直接压到几十毫秒那就不能只看平均帧率还必须考虑单帧推理的最大时延和抖动。功耗在很多边缘端场景里比算力更重要。电池供电的物联网设备比如智能门锁、穿戴设备、便携巡检仪整机功耗可能要在百毫瓦级甚至是几十毫瓦级这时候哪怕芯片算力再强也用不上因为散热和电池根本撑不住。市电供电的设备相对宽松但散热还是有上限尤其要做无风扇设计的时候芯片的持续功耗会被严格限制。延迟和功耗这两个参数往往可以大大缩小候选芯片的范围。很多 MCU 级芯片不是因为算力不够而是因为功耗太高被淘汰很多高端芯片不是因为跑不动而是因为 20W 的功耗和毫无散热空间的外壳不匹配才被放弃。2.4 接口、体积和物料成本最后还要看接口是否满足场景需求。摄像头是 MIPI CSI 还是 USB需要输出到屏幕吗需要几路串口需要支持 4G 或者 Wi-Fi 模组吗这些接口直接关系到芯片的外围设计方案、PCB 层数和整体体积。成本方面我一般会给出一个整机 BOM 的预算区间然后倒推出芯片和模组的可接受价格。如果产品是千元以内的边缘计算盒子那 RK3588 级别的模组就是合理选择Jetson Orin NX 这种就是明显超预算如果是面向高端工业场景的智能相机成本容忍度会高一些甚至可以直接上 CUDA 生态的平台。把这些参数都列出来之后选型工作就从“这块芯片听起来不错”变成了“用这几个约束条件去筛平台”也就是把场景翻译算力需求的关键成果。3. 算力换算不是简单除法TOPS、GFLOPs 和实际帧率之间的距离经常被问到一个问题这块芯片标称 6 TOPS到底能跑多少帧要回答这个问题先得把算力单位之间的关系搞清楚也要知道为什么理论计算出来的帧率在实际中很难达到。3.1 TOPS 和 GMACs 到底表示什么TOPS 是 Tera Operations Per Second也就是每秒一万亿次运算操作。GMACs 是每秒十亿次乘加运算。在深度学习中一次“乘法累加”计算通常被认为是两次操作因为乘法和加法是两个独立运算。所以严格换算的话1 TOPS 理论上相当于大约 500 GMACs。这也就是为什么同一块芯片用 MACs 描述时数值看起来会比用 TOPS 描述小很多。举个例子。一个模型单帧推理需要 16 GMACs芯片 NPU 标称 6 TOPS理论帧率是多少先换算6 TOPS 等于 3000 GMACs 每秒除以 16 GMACs 每帧理论算下来是 187 帧每秒。这个数字听起来很夸张但实际工程里几乎不可能达到。为什么因为 NPU 不是专为某一个模型设计的算子执行效率、数据搬运开销、内存带宽、量化方式都会造成性能折损。我做了这么多项目的经验可以给你一个非常朴素的估算系数真实可用的算力大致是标称算力的两成到五成。具体落在哪个位置取决于模型结构跟 NPU 指令集的匹配程度以及内存带宽是否够用。算力预算的时候我一般都按标称值的 30% 左右做规划留出充足的余量等跑完基准测试再修正。3.2 INT8、FP16、FP32、FP64 对选型的影响这里要重点提一下热词里常出现的 INT8、FP16、FP32、FP64 这几个精度体系。它们在边缘端 AI 芯片的选型里起着决定性作用。绝大多数消费级和工业级边缘 NPU 的宣传算力都是在 INT8 精度下测出来的。INT8 量化能用 8 位整数表达一个数占内存小、计算速度快对推理任务来说精度损失通常可以接受。所以当你看到一款边缘芯片标称 6 TOPS 时默认是 INT8 算力。FP16 是半精度浮点比 INT8 动态范围更大不容易溢出但在同一份硅片上FP16 的计算速度通常只有 INT8 的一半甚至更低。比如某些 NPU 标称 INT8 是 6 TOPSFP16 就只有 3 TOPS 左右。如果你的模型不做 INT8 量化而是在 FP16 下推理那预算的时候就要按 FP16 算力算不能直接拿 INT8 的标称值去规划。FP32 是单精度浮点通常用于训练而非边缘端推理。边缘端芯片即使支持 FP32算力也往往比 INT8 低了好几倍所以我不建议在边缘端核心推理链路里跑 FP32。FP64 就更不用说了双精度浮点是科学计算和 HPC 领域的东西边缘端 AI 推理基本用不到只有在极少数需要高精度数值计算的工业场景才会考虑。记住一个大原则边缘端推理优先搞 INT8训练用 FP32/混合精度FP16 看情况用于模型不易量化或对精度敏感的场景。3.3 实际性能折损从哪里来理论算力和实际帧率之间的差距主要来自四个地方。内存带宽模型参数和中间特征图都要从 DDR 里反复读取NPU 计算速度快但内存搬运速度跟不上NPU 就要空等算力利用率上不去。算子适配度NPU 对某些算子的加速比很有限比如 softmax、某些归一化层、动量累积操作很可能被放到 CPU 上跑这部分耗时很容易被忽略。量化开销模型本身是 FP16 或者 FP32 的转成 INT8 后精度或速度会有波动有时候为了保住精度还要混合量化保留一部分层在 FP16这会明显拖慢整体帧率。多路并发和系统调度多路视频流同时进内存、NPU、CPU 之间互相争抢总线实际吞吐会比单路跑出来的帧率低不少。这些折损很难通过理论计算精确预测只能靠基准测试。所以选型的最后一步一定是用真实模型、真实输入尺寸、真实并发路数去跑板子而不是拿厂商给的 Demo 数据做决策。如果这一步做不到前面所有计算都是空中楼阁。4. 按算力档位盘点货架上常用的边缘 AI 芯片了解了需求侧怎么算再来看供给侧。目前边缘端 AI 芯片眼花缭乱但从算力和应用定位维度可以大致分成几个档位。这里我把每个档位的代表芯片、典型算力范围和适合的工作做一张对照表方便你快速建立坐标系。档位代表芯片/模组典型算力典型内存适合负载MCU 级ESP32-S3、STM32 系列含 AI 加速、nRF 系列微小K 到百 M OPS几百 KB 到 1MB SRAM关键词识别、简单唤醒、震动/手势分类轻量级 SoCRK3568、i.MX 8M Plus、全志 T5270.5 - 1 TOPSINT81 - 4GB DDR轻量物体检测、单路视频分析、智能面板中高端 NPU SoCRK3588、地平线旭日 X3、算能 BM1684X、高通 QCS 系列5 - 16 TOPSINT84 - 16GB LPDDR多路视频结构化、安防监控、智能相机模组级计算平台Jetson Orin Nano / NX / AGX Orin20 - 275 TOPSINT8 含稀疏8 - 64GB多路复杂模型、机器人与自动化、边缘大模型边缘小服务器/集群多张推理卡或边缘服务器数百 TOPS 级32GB 以上边缘机房、小规模集群、视频中台这个表只是一个粗线条的坐标实际选型时还要看得更细。下面分别说说每个档位的定位和注意点。4.1 MCU 级算力小但功耗和体积优势突出ESP32-S3 和 STM32 系列属于边缘端 AI 的入门选项。ESP32-S3 自带 SIMD 向量指令和一些针对神经网络的扩展指令可以在低功耗下跑小型分类模型。STM32 现在也有 Edge AI 工具链支持可以把训练好的 Keras、ONNX 模型压缩量化后部署到 MCU 上。这个档位的芯片适合做传感器端的“第一道智能”比如唤醒词检测、设备姿态识别、振动异常分类、简单的人脸存在性检测等等。它们最大的优势是启动快、功耗低、外围电路简单、价格便宜整个系统甚至可以靠纽扣电池维持很长时间。但它们的算力天花板也非常低跑不了稍微像样的目标检测网络。如果你有毫秒级语音唤醒的需求选 MCU 级是合理的如果有视频目标检测需求就不要在这个档位浪费时间了。4.2 轻量级 SoC单路视频检测的性价比区间RK3568 是这一档里非常典型的芯片集成了 1 TOPS 左右的 NPU支持常见模型格式转换配套的 RKNN 工具链也比较成熟。i.MX 8M Plus 是恩智浦的方案NPU 在 2.3 TOPS 左右工业级品质和应用案例积累比较多。全志 T527 也在这个区间主打成本和多功能融合。这个档位适合做智能家居中控屏、轻量级工业检测设备、单路视频分析的边缘盒子。比如一个简单的安全帽检测或者工服识别输入画面 640x640模型用 YOLOv5n 或 YOLOv8n这个档位能跑到 10 到 20 帧每秒对很多实时性要求不那么高的场景已经够用。这个档位的好处是功耗通常只有几瓦散热设计简单甚至可以被动散热。缺点是算力余量小如果你想同时跑两个模型或者视频路数从 1 路变成 4 路就可能直接超出能力范围。4.3 中高端 NPU SoC多路视频和复杂模型的主战场RK3588 是目前国内边缘端 AI 项目里被讨论得最多的芯片之一集成 6 TOPS NPU同时有很强的 CPU 和视频编解码能力支持多路视频硬解码。它很适合做 4 到 8 路视频分析的智能盒子也是很多人做边缘计算小服务器的首选。地平线旭日 X3 是国产方案里工具链口碑不错的存在它的 BPU 架构对 CNN 类模型的支持比较高效配套的开发资料和模型部署文档写得接地气落地速度相对快。算能 BM1684X 的算力规模更大适合对算力要求更高的智能分析设备。高通的 QCS 系列则继承了移动平台的成熟设计ISP 和多媒体能力强在智能摄像头产品里比较常见。这个档位上的芯片做视频分析已经不是能不能跑的问题而是能不能在多路并发下保持稳定。做多路视频结构化时我建议把 NPU 算力、解码路数、内存带宽放在同一个表格里一起评估。比如 RK3588 声称支持数十路 1080p 解码但如果你同时把每路都送去推理NPU 和内存带宽会先顶不住。所以别只盯着宣传的视频路数要算清“解码路数×推理帧率”的组合是不是够用。4.4 模组级计算平台CUDA 生态和极致算力NVIDIA Jetson 系列是很多算法团队偏爱的平台Orin Nano、Orin NX、AGX Orin 覆盖了从入门到高端的算力区间。它们的优势在于 CUDA 生态成熟TensorRT 推理引擎优化到位尤其适合跑那些在训练阶段就用了很多 GPU 特性代码的模型或者是对精度要求高、必须用 FP16 跑的模型。这个档位也很适合边缘端部署大型模型的试探性项目。比如你想在一个边缘计算盒子里跑 7B 参数甚至更大规模的大语言模型Orin NX 或 AGX Orin 配合量化压缩手段是可以做轻载推理实验的。不过功耗和价格也随之升高Orin 系列整机功耗从十几瓦到几十瓦不等必须有散热风扇或者大尺寸散热器工作环境还要考虑灰尘防护。做产品时Jetson 平台常常会面临“性能没问题但成本压不下来”的尴尬所以如果是消费级产品我更推荐先在中高端国产 NPU 上做评估把 Jetson 方案作为备份和验证工具。5. 三组典型场景从需求推导芯片的全过程光讲方法论容易飘我挑了三个不同类型的边缘端 AI 场景完整走一遍从需求拆分到芯片决策的过程。这三个场景分别代表 MCU 级、轻量级 SoC 级和中高端 NPU 级覆盖了最常见的产品形态。5.1 场景一电池供电的智能门锁语音功能产品需求是给智能门锁加一个低功耗语音能力用户靠近时可以通过语音唤醒设备然后说一句“打开门”或者“请呼叫物业”。整机由两节锂电池供电要求唤醒状态下待机功耗尽量低门锁主控长期处于休眠状态只有语音唤醒模块保持监听。这个场景的边界很清晰。模型是关键词识别和极简意的图分类输入是 16kHz 或者 32kHz 的音频帧计算量非常小一次推理通常在百万次操作级别。延迟要求是唤醒在 100 到 300 毫秒内响应。功耗要求却非常苛刻监听状态下整个模块最好不超过几毫瓦到几十毫瓦。这个需求一出来基本就把中高端芯片全部排除了。候选范围落在 ESP32-S3、带 AI 加速的 STM32 系列以及类似低功耗 MCU 上。最终怎么选主要看团队熟悉哪个生态。如果团队对 Arduino 和 ESP-IDF 熟悉ESP32-S3 上手很快如果有过硬的 STM32 产品经验ST 的 Edge AI 工具链也能胜任。这里有个容易被忽视的细节语音唤醒并不是“芯片算力够不够”的问题而是“唤醒之后主系统要不要被拉起来”的系统级设计问题。哪怕唤醒芯片算力再强如果每次唤醒都要把全系统吵醒功耗也兜不住。所以选型时要格外看重芯片的低功耗模式和快速唤醒能力而不是反复比较 TOPS。5.2 场景二工厂安全帽佩戴检测的 4 路视频盒子产品需求是一个边缘计算盒子接 4 路 1080p 摄像头实时检测作业区域内工人是否佩戴安全帽。检测画面每一路 15 帧每秒就够延迟允许 500 毫秒以内。盒子安装在厂房墙壁上要求无风扇被动散热环境温度最高 45 摄氏度整机功耗最好控制在 10 瓦以内单板成本尽量低。这个场景的模型可以选择 YOLOv5n 或 YOLOv8n 这类轻量检测模型输入尺寸 640x640单帧计算量大约在 7 到 10 GMACs。4 路乘以 15 帧每秒等于每秒要处理 60 帧。按 10 GMACs 每帧算一秒需要的计算量是 600 GMACs。换算成 TOPS因为 1 TOPS 约等于 500 GMACs 每秒所以算力需求下限大概是 1.2 TOPS。这么看RK3568 的 1 TOPS 有点紧张RK3588 的 6 TOPS 又显得太多。这里就要把性能折损系数加进去按标称算力的三成估算实际可用算力RK3568 实际可用只有 0.3 TOPS 左右明显不够RK3588 实际可用 1.8 TOPS 左右足够覆盖 1.2 TOPS 的需求还留了一部分余量。因此在成本和性能两端平衡之后候选会集中在 RK3588 以及同档位的国产 NPU 方案上。这个场景的另一个关键点是散热。设备放在 45 度的厂房里无风扇被动散热这意味着整套系统的持续功耗不能太高。RK3588 在跑满视频分析时的功耗并不低设计时 CPU 要锁核降频内存要选合适的 LPDDR 频率外壳必须用铝合金加鳍片结构把热量导出来。这些工程细节往往决定了芯片到底能不能稳定运行而不只是看算力数字。5.3 场景三园区 8 路视频结构化分析加轻量大模型产品需求是一个稍微超前的边缘计算节点接 8 路摄像头同时做车牌识别、区域入侵检测和人员轨迹分析。另外客户还想在这个节点上尝试接一个自然语言交互层用户可以对着盒子提问模型基于当天的结构化数据进行简单回答。输入分辨率 1080p目标帧率每路 10 帧延迟 1 秒以内可接受节点部署在机房可以用主动散热。这个场景比前面的复杂在“同时做多种任务”。车牌识别、入侵检测、人员轨迹可能是三个模型不一定同时跑但要在同一块板上调度好。更麻烦的是自然语言交互层哪怕只是一个轻量的对话模型参数量也有几个 B对算力和内存带宽的消耗都远高于视觉模型。这个场景做算力预算就不能只算单一模型的 GMACs而是要分模块来评估视觉推理部分按 8 路乘 10 帧每秒乘多模型做加法语言模型部分单独评估内存占用和生成时延还要把视频硬解码和特征向量存储的开销算进去。综合下来这个节点需要的算力在 15 TOPS 量级内存最好大于 16GB才能保证视觉模型和轻量语言模型共存。候选平台就剩两级了。算力要求不高的话算能 BM1684X 或 RK3588 的高配方案可以做预算更可控。如果语言模型的分量更重比如未来要做多轮对话和更长上下文直接上 Jetson Orin NX 会更轻松CUDA 生态对 Transformer 类模型的支持相对更完善。这个决策说白了就是在“国产化成本”和“开发效率”之间做权衡而不是单纯比谁跑得快。6. 选型定了之后还要补的工程课散热、内存与工具链芯片选型完成只代表项目跨过了一个门槛真正决定项目生死的是选型之后那些跟不上算力指标的工程配套。这一章我把项目里最容易踩的坑集中拎出来讲。6.1 散热设计别把无风扇当成“不用管”很多边缘端 AI 盒子都主打无风扇设计看起来很省事实际上无风扇是最讲究散热的一类设计。芯片在满负载运行时的功耗跟外壳散热能力之间必须严格匹配。我用过一个标称 10W 的芯片方案因为没有设计好热传导路径内部温度直接冲到 80 度以上NPU 触发降频推理帧率腰斩。做无风扇系统时芯片本身必须有热设计功耗TDP数据而不是只看峰值功耗。外壳要做成金属的芯片与外壳之间用导热硅脂和导热垫片填充必要的时候还要加均热板。如果外壳设计已经定死没法改那就只能软办法锁 CPU 频率、压低 NPU 频率、限制内存带宽牺牲一部分性能来换稳定。提前想清楚“要性能还是要安静”比后期反复改散热骨架高效得多。6.2 内存带宽才是隐藏瓶颈算力需求算了半天最容易忽略的就是内存带宽。模型参数和中间特征都放在 DDR 里NPU 每算一层就要把数据搬进来搬出去带宽跟不上NPU 就算力再强也只能空转。这也是很多芯片标称算力很高、实际推理帧率上不去的重要原因。选内存时要注意芯片支持的是 LPDDR4 还是 DDR4是单通道还是双通道。能选高带宽就选高带宽能上 64bit 位宽就不要用 32bit。内存容量同样需要提前规划推理框架、系统缓存、多路视频缓冲、中间特征图存储每一项都会吃内存。中高端边缘 AI 盒子至少配 8GB 起步多路视频加多模型并发的话16GB 已经不算多。6.3 工具链生态和量化精度要提前验证芯片的 NPU 再强如果配套工具链对常见模型格式支持不完整项目就会卡在模型转换这一步。国内几家做 NPU 的厂商工具链成熟度已经比几年前好了很多但不同框架模型之间仍然会存在算子不支持、量化后精度掉点的问题。我的建议是在选型阶段就要把“模型转换量化精度验证”这个流程跑一遍而不是等板子到手才做。具体做法是挑一个和目标模型结构相似的模型在候选芯片上完成 INT8 量化用同一批测试集对比量化前后的精度差异。如果精度掉点严重就要评估是不是需要给某些层保留 FP16或者换用对量化更友好的模型结构。还有官方 Demo 模型的运行效果只能参考不要用来做最终性能判断。厂商 Demo 模型通常是在硬件上反复优化过的甚至部署在最佳条件上。你真实的业务模型可能有大量自定义算子有复杂的后处理逻辑有动态尺寸输入这些都会把帧率往下拉。拿真实模型跑基准是所有选型流程里最不可省略的一步。6.4 从单板算力推集群算力注意规模效应最后说一个容易被低估的话题。当你的项目不是单台设备而是一整套边缘计算网络时选型时还要从单板推演到集群。比如 30 个边缘盒子布置在几十个园区里每个盒子 6 TOPS总算力 180 TOPS听起来不少但集群的瓶颈常常在运维、网络回传和管理调度上。如果边缘节点之间要协同比如多个节点共同完成一个模型推理任务那就必须考虑算力调度的框架是不是成熟节点间的通信带宽够不够。这时候芯片本身的 TOPS 反而不是最核心的指标平台的稳定性、远程升级能力、容器化支持程度会变成选型的关键。做这类系统我会建议优先选软件生态和运维工具成熟的平台哪怕单板算力稍微低一点也可以避免后续集群部署的噩梦。每个人的项目约束都不一样我上面这套流程只是给一个通用的思考框架。实际做选型时一定要用你手上的真实模型、真实摄像头参数、真实环境去跑一遍最终选出来的平台才是真正适合你的。不要怕折腾边缘端 AI 的选型本来就是把所有坑提前踩完的过程。
