1. 先搞懂边缘端 AI 算力的“账本”
1.1 算力的三类单位：TOPS、FPS、MACs
聊边缘端 AI 算力选型，很多人一上来就盯着 TOPS（Tera Operations Per Second，每秒万亿次运算）这个数字看，好像算力越大芯片就越强。但实际做项目选型的时候，光看 TOPS 很容易被带到沟里去。我先把这个账本掰开来讲清楚。
边缘端 AI 算力最常出现的三个单位是 TOPS、FPS 和 MACs，它们各自描述的是“理论峰值计算能力”“实际推理速度”和“模型计算量”。TOPS 是芯片厂商最爱宣传的，因为它是硬件理论上的最高吞吐，代表 NPU 在最优条件下每秒能完成多少次整数运算。但理论值几乎不可能跑满，实际能利用的往往只有 30%-60%，甚至更低。FPS（Frames Per Second）是模型的真实推理速度，比如“YOLOv5s 在这个芯片上跑 1080P 输入、INT8 量化后能跑到 30 帧每秒”，这才是项目验收真正关心的数字。MACs（Multiply-Accumulate Operations）则是模型的一次前向推理要执行多少次乘加运算，它挂在模型身上，和硬件无关，是估算“这个模型在这个算力上能跑多快”的桥梁。
这三者的关系可以比作一个停车场：TOPS 是停车场的最大车位数（理论容量），MACs 是你这趟要停多少辆车（模型体量），FPS 是实际每小时能进出多少辆车（吞吐效率）。光看车位数没用，还得看进出通道顺不顺、收费环节卡不卡，对应到芯片上就是内存带宽、算子优化程度、数据搬运效率。
1.2 算力不等于可用算力：从峰值到有效算力
这里我要特别强调一个概念：有效算力。做边缘端选型，判断芯片能不能扛住业务，不能拿 6 TOPS 去套模型，得先乘一个“利用系数”。利用系数受几个因素影响：一是 NPU 和 CPU 之间的数据搬运开销，输入图像要经过 DMA 搬运到 NPU 内存，推理结果再搬回来，这一来一回要吃掉不少时间；二是内存带宽是否足够，很多小芯片 TOPS 标得挺高，但内存带宽只有 16GB/s，一旦模型大了，数据搬不过来，NPU 就在那干等，实际帧率完全上不去；三是算子支持度，芯片厂商的 SDK 对常见算子的优化程度千差万别，有的算子跑 NPU 比跑 CPU 还慢，那就只能降级或者重写。
举个例子，某款号称 6 TOPS 的芯片，实际部署一个 YOLOv5s INT8 模型，理论算力只需要 1.5 TOPS 就能跑到 30FPS，但实测只能跑到 12-15FPS，就是因为内存带宽和算子优化浪费了大部分算力。所以我选型时习惯用一个粗估公式：有效算力 ≈ 标称 TOPS × 0.3 × 算子适配系数（0.7-1.0）。按这个公式，标称 6 TOPS 的有效算力大概只有 1.2-1.8 TOPS，这才是你真正能动用的算力池。
1.3 功耗与散热：边缘端最容易被低估的约束
如果说算力是选型的明线，那功耗和散热就是暗线，而且这条暗线往往在项目中期突然跳出来咬人。边缘端设备形态千奇百怪，有挂在电杆上的盒子、嵌在产线设备里的工控机、装在车里的域控制器，还有无人机吊舱这类对重量和功耗都极其敏感的场景。这些形态决定了整机的散热能力，而散热能力直接封死了你选高算力芯片的路。
我见过太多人忽略功耗，在 7W 散热的盒子里塞了一块 15W 的算力板卡，结果高温降频，标称 100 TOPS 实际只能跑出 40 TOPS 的效果，反而比一开始就选低功耗平台更慢。选型的时候必须把“功耗墙”考虑进去：先算整机可用功耗和散热条件，再倒推芯片的平均功耗上限，最后才在该功耗档位内找算力最高的方案。工业盒子通常能压 10-25W，车载场景能压 5-15W，手持设备可能只有 2-7W，每一档对应的可选芯片范围完全不同。
2. 场景反推芯片：从需求到参数的四步走
2.1 第一步：摸清你的推理负载到底是什么
从场景反推芯片的第一步，不是查芯片参数表，而是老老实实把场景的需求“翻译”成对算力的要求。我先问自己几个问题：跑的是什么模型？检测、分类、分割还是多任务集合？输入分辨率是多少？业务要求的实时性是多少帧？并发路数是几路？出结果是秒级响应还是分钟级聚合？这些答案决定了模型的 MACs 总量上限。
拿工业质检来说，检测的是 2000 万像素的 PCB 板图像，看是否有虚焊、少件、划痕，分辨率决定了输入尺寸可能要到 2592×1944，模型跑一次前向的 MACs 就非常吓人。而另一个场景是做安防视频结构化，输入只是 1080P 视频流，按 25FPS 抽帧检测人和车，模型可以压到 640×640 输入，两者的算力需求差出三到五倍。同样叫“边缘 AI 项目”，云泥之别。
这个环节最容易出的错是用错模型版本。同一套算法，服务端用的可能是大而准的模型，但边缘端必须换轻量版本，不能拿服务端模型直接塞边缘设备。我一般会准备 2-3 个候选模型（比如 YOLOv5m、YOLOv5s、YOLOv5n），分别统计它们的 MACs 和参数量，作为后续估算的输入。
2.2 第二步：确定精度与帧率预算
模型跑起来能接受什么精度？这里不只是“精度损失多少”的问题，还牵涉到 INT8/FP16/FP32 三种格式在异构芯片上的算力差异。很多边缘芯片的 NPU 对 INT8 有专门的算力单元，标称 TOPS 通常是基于 INT8 计算出来的；如果你用 FP16 跑，算力数字直接腰斩甚至只有三分之一；用 FP32 上 NPU，大多数芯片根本不支持，只能丢给 CPU 跑，性能惨不忍睹。
帧率预算也很关键，它直接决定你要不要上多线程流水线。一个单路 25 帧每秒的检测任务和一个两路 12 帧每秒的检测任务，对算力的需求可能差不多，但前者的延迟表现更难做，因为你要在 40ms 内完成一帧的前处理、推理、后处理，而在 SoC 上这三角色往往在抢 CPU 核心。选型时我会把“帧率 × 输入分辨率 × 模型计算量”拉到一起算总账，而不是只看单帧延迟。
2.3 第三步：反向估算所需算力
有了模型 MACs、目标帧率和可接受精度格式，就可以做一次粗略但好用的反向估算。公式很简单：
所需算力(TOPS) ≈ 模型MACs(GMAC) × 每秒帧数(FPS) × 2 / 1000
为什么乘 2？因为一次 MAC 包含一次乘法和一次加法，对应两次运算，TOPS 统计的是运算次数而非乘加次数。举例：YOLOv5s 的输入是 640×640，MACs 大约 8.7 GMAC，每帧所需运算量就是 17.4 GFLOPs。目标帧率 30FPS，那需要的线性算力是 17.4 × 30 = 522 GOPS ≈ 0.52 TOPS。听起来很小对吧？但别忘了乘利用系数。如果有效算力是标称的 30%，那实际需要标称算力约 0.52 / 0.3 ≈ 1.75 TOPS。考虑到还要同时跑前后处理、多路并发、系统开销，我至少会在计算结果上留出 50%-100% 的余量。也就是说这个看似轻量的场景，最好选一个标称 3TOPS 以上的芯片平台，并且优先看它的内存带宽和算子优化情况。
这一步我建议大家都落在表格里，把“模型、输入尺寸、MACs、目标帧率、计算FLOPs、利用系数、所需标称TOPS、余量后TOPS”逐项列出来。真实做选型报告时，这份表格拿出去说理非常有说服力，比光说“感觉够用”强太多。
2.4 第四步：把算力需求翻译成芯片选型约束
得出了一个“够用”的算力底线之后，接下来才轮到选芯片。但“够用”只是一个约束，还有几个约束得同时满足：一看内存带宽，至少能支撑模型权重和特征图的反复搬运，我通常要求 SoC 的内存带宽不低于 25.6GB/s（LPDDR4x 双通道水平），否则大模型跑起来会明显掉帧；二看易用性，NPU 的 SDK、算子库、量化工具链是否成熟，这直接决定你团队要烧多少时间，甚至比硬件本身更关键；三看外设接口，摄像头接入要用 MIPI-CSI 还是 USB，输出要 HDMI 还是千兆网口，这决定了你要不要在核心板外面再加转接板；四看代码生态和量产能力，能不能保证五到十年的供货，会不会突然停产换封装。
我在实际选型时习惯把“算力池”和“接口槽位”分开看。算力池决定算法跑得动跑不动，接口槽位决定硬件能不能挂到产线上。很多项目死在后者，大家辛辛苦苦挑了高算力芯片，结果做出来的盒子接不了现有的工业相机，还得做个转接板，一来一回多耗两周。
3. 主流边缘 AI 芯片平台横向对比
3.1 RK3588 / RK3576：国产性价比路线
瑞芯微的 RK3588 是当前边缘端 AI 项目里出现频率极高的芯片，8 核 CPU（四核 Cortex-A76 + 四核 Cortex-A55）+ 6 TOPS NPU，支持 INT8/INT16/FP16 混合精度。它的优势在于接口极其丰富，双 2.5G 网口、HDMI 输入输出、多个 USB3.0、PCIe3.0，做边缘盒子几乎不需要再加太多外围芯片。更关键的是 RKNN-Toolkit2 这几年迭代很快，对 PyTorch/ONNX 模型的支持做得相当顺手，量化、转换、调试的链路比较完善，社区案例也很多，踩坑容易找到解法。
RK3576 是 RK3588 的低功耗版本，NPU 大约也是 6 TOPS 级别，但 CPU 换了 A72 核心组合，整体功耗更低，适合对功耗更敏感的盒子和一些车载场景。这两颗芯片放在国产方案里，属于“软件生态 + 硬件接口 + 供货稳定”三位一体都做得比较均衡的选择。
如果想更省事一点，直接买成熟的 RK3588 开发板做评估，比如香橙派等品牌都有对应产品，几百块就能把整个软件链路跑通。很多量产盒子厂商也直接提供基于 RK3588 整机方案，连 PCB 都不用自己画，非常适合中小团队快速出原型。
3.2 NVIDIA Jetson Orin 系列：生态天花板
NVIDIA Jetson 系列是边缘端绕不开的选项，尤其是 Orin NX 和 Orin Nano，分别能提供 100 TOPS 和 40 TOPS（INT8）的算力。这个系列最大的优势是 CUDA 生态和 TensorRT。如果你团队里算法工程师的经验主要集中在 PyTorch 生态，那 Jetson 就是天然的家，大部分算子都有高性能实现，TensorRT 做 FP16/INT8 优化的工具链是最成熟的，部署周期可以压缩到几天。
Jetson Orin Nano 8GB 是很多做自动驾驶、机器人、智慧零售团队的入门首选，原因在于 40 TOPS 的标称算力放在 7-10W 功耗区间里非常能打。虽然它的 CPU 相对弱一些，但如果主要负载是 CNN 推理而不是复杂的逻辑调度，Orin Nano 足够撑起一路高分辨率检测加一路分割任务。
不过 Jetson 系列也有两个痛点：一是价格，板卡价格从千元到近万元不等，量产后整机成本比国产方案高很多；二是 5-10 年的供货承诺和合规性在部分项目里会受限，做海外项目问题不大，但国内国企或涉密项目经常要求国产化方案，这时候 Jetson 只能出局。所以选 Jetson 还是 RK3588，很多时候是“生态优先还是成本优先”的取舍，没有绝对答案。
3.3 地平线旭日、寒武纪、海思等其他路线
除了瑞芯微和 NVIDIA，市面上还有一些值得关注的选手。地平线旭日系列（如旭日 X5）主打车规级和机器人场景，走的是软硬协同路线，工具链 OpenExplorer 对 Transformer 类模型的支持比较积极，如果你模型里带 ViT、BEV 结构，地平线这块是有说法的。寒武纪的思元系列在安防、智慧城市方向有不少落地案例，但开发者社区和文档相对封闭，适合大厂定制项目，不适合小团队快速开发。海思 Hi3559 等曾是安防领域的经典，受制裁影响后供应链不稳，现在选它得多留个心眼。
这些平台不是不好，而是“生态、供货、社区”这三个维度里总有一个短板。我给团队的建议是：如果目标是三个月内上线、团队规模不大、没有国产化强制约束，优先级推荐 RK3588 或 Jetson Orin；如果项目对功耗有极限要求（无人机、手持设备），可以考虑海思、全志、瑞萨等低功耗路线；如果后续要上车的，地平线的工具链值得提前熟悉。总之不要只看算力排行榜，还要看那个芯片的社区里有多少人和你用同样的模型。
3.4 工具链生态：选芯片本质是选软件链
这是我要反复强调的核心观点：选边缘 AI 芯片，本质上是在选一条软件工具链。芯片的 TOPS 再高，如果模型转换工具连 ONNX 的某些算子都解析不了，或者量化后的精度掉得没法看，那这块芯片对你就是玩具级别。倒过来，一个算力稍微低一点但工具链顺手的芯片，往往能让你项目更快落地。
我列几个关键的评估点：算子覆盖率、模型转换是否要手动改图、是否支持动态 batch、量化工具能不能对特定层指定不量化、有没有 profiler 工具可以定位性能瓶颈。这些功能在评估期可能感觉不到重要，到了量产调优阶段全是真真切切的时间。举个例子，RKNN 工具链早期对 ROI Align、某些上采样算子支持不友好，部署检测模型得手动拆算子，一个模型折腾一周；现在好很多了，但遇到特殊结构仍要手改。TensorRT 相对省心，但版本升级时模型也要跟着重新导出，也有它自己的兼容性问题。
我的经验是：选型评审时至少花两天时间，把你们实际要部署的模型在候选芯片上完整跑一遍，记录“模型转换耗时、算子改动量、量化后 mAP 掉点、端到端帧率”四个指标。这比任何芯片吹嘘的参数都更能说明问题。
4. 量化精度与推理框架的影响
4.1 INT8 / FP16 / FP32 对算力的影响
量化是边缘端部署绕不开的关卡，因为边缘芯片的 NPU 绝大多数是为 INT8 设计的。理解这三者的差异，关键看两点：算力吞吐和数据位宽。
FP32 用 32 位表示一个数，精度最高，但计算量最大、内存占用最大，边缘芯片的 NPU 基本不支持，只能靠 GPU/CPU 里的 FP32 单元跑，速度极慢。FP16 用 16 位，精度居中，计算吞吐大概是 FP32 的两倍，内存占用减半，Jetson 系列对 FP16 支持非常好，很多场景不量化也能满足精度要求。INT8 用 8 位整数，计算吞吐通常是 FP16 的两到四倍，内存占用再减半，是边缘端实现高性能推理的主要手段。代价是精度有损失，常见检测模型掉点在 1%-5% 之间，如果做量化校准不仔细，掉点可能到 10% 以上。
我这里强调“量化后掉点”不是玄学，而是一个必须被测量的指标。很多时候我用 TensorRT 的 INT8 模式跑一遍校验集，mAP 掉 2%，完全能接受；但如果换成 3 倍速试试，用 KL 散度校准选错样本，掉点可能直接失控。所以边缘端部署流程里，我始终坚持先做 FP16 基准测试，再做 INT8 量化，并调试校准集，用一对准确率数据来指导精度和性能的平衡。
4.2 常见推理框架适配性对比
框架选型同样容不得拍脑袋。当前边缘端用得多的推理框架有 NVIDIA TensorRT、瑞芯微 RKNN、地平线 OpenExplorer、还有通用的 ONNX Runtime、NCNN、OpenVINO 等。TensorRT 是 Jetson 系列的默认选择，优势是高性能和广泛算子支持，劣势是闭源、每个版本有锁定的 CUDA 版本，且对动态 shape 的支持比较费劲。RKNN 是瑞芯微 NPU 的官方工具链，从 PyTorch 模型转 ONNX 再转 RKNN 的链路已经很顺，但很多操作需要先用它的预处理工具做归一化和通道转换。NCNN 是腾讯开源的轻量神经网络框架，聚焦 CPU/GPU 推理，适合没有专用 NPU 的嵌入式 Linux 环境，但性能上限远低于专用 NPU 方案。
选框架要看两层：一层是模型能不能顺利转换，一层是转换后跑得快不快、内存稳不稳定。有些模型在 PyTorch 里写得飞起，但包含大量动态控制流、自定义算子，转到边缘推理框架时直接变成坑，被迫重写算子、剪枝，非常耗时。所以我在选型阶段就会把目标框架和芯片绑定一起测，绝不分头行动。
5. 实操流程与踩坑实录
5.1 一个从零开始的选型流程示例
这里列一个我常用的选型实操流程，从需求书到软硬件验证总共三步。
第一步，整理需求书，输出一份“算力需求估算表”。咱们拿一个简单的场景举例：做农贸市场的智能秤，用摄像头识别秤盘上的蔬菜种类并自动计价。模型选 YOLOv5n，输入尺寸压到 320×320，MACs 约 1.6 GMAC，目标帧率 5FPS 足够。按之前的公式：1.6 × 2 × 5 = 16 GOPS ≈ 0.016 TOPS。这个数字小得惊人，哪怕利用系数拉低到 0.1，标称 1 TOPS 都绰绰有余。所以真实约束根本不在算力，而在体积、功耗和摄像头接口。最后可能随便一颗 2 TOPS 级别的小 SoC 都能胜任，重点反而是摄像头 ISP 能力和整机成本。
第二步，对照需求选 2-3 个候选平台，统一跑基准模型。基准模型不要用你自己的业务模型，太慢也太复杂，先用一个标准的 YOLOv5s + 640 输入跑一遍，记录帧率和延迟。这一步的目的是看每个平台最基础的性能表现，后续再换上自己的模型精调。
第三步，做一次 7 天的板级验证。主要测三件事：模型转换和量化链路是否跑得通、内存是否稳定（跑 24 小时有无越涨）、温升后的性能表现。这一步能发现大量只在标称值里看不到的问题，比如某些板子满载 10 分钟就过热降频，或者内存带宽在高分辨率输入时断崖下跌。
5.2 常见误区：从算力焦虑到接口陷阱
踩过不少坑之后，我总结出几个边缘 AI 选型最常见的误区。
第一个误区是“算力越大越好”。很多团队上来就选最高 TOPS 的板卡，结果项目百分之九十的时间系统都在空转，成本却翻了几番，功耗和体积也压不下来。选型不是买彩票，越大的算力不会带来越多的确定性，反而会带来更多的散热和电源设计压力。
第二个误区是“忽略输入输出链路的效率”。边缘端数据管道的开销常常比推理本身还大。摄像头采集图像、内存拷贝、图像缩放、色彩空间转换，这些操作如果都在 CPU 上做，一张 1080P 图像可能吃掉 30ms，而推理本身只要 20ms。选择带硬件 ISP 加速、支持零拷贝推理的芯片能大幅改善这些链路的效率。
第三个误区是“等模型调完再做选型”。模型结构直接决定了算力需求，不同的 backbone、head 和输入尺寸造成的计算量天差地别。我见过团队辛辛苦苦把模型精度调到 99%，结果发现边缘板卡根本跑不动，只好回头改模型，等于把选型周期翻倍。建议大家在做模型轻量化的时候就同步做选型验证，而不是步步为营串行推进。
5.3 上手避坑指南：供电、散热与量产稳定性
等选型做完、开发板也调好了，还有几个“量产物”领域常见的坑值得专门提醒。
供电设计。边缘 AI 板卡启动瞬间电流很大，很多板卡要求 5V/3A 以上，甚至要 12V 供电。如果电源不稳，可能会出现“接上摄像头就重启”的怪现象。我建议一开始就按峰值电流的 1.5 倍去设计供电，并且要选带主动散热风扇或良好被动散热贴合的散热方案，因为 NPU 满载时温度上升非常快，超过 85°C 就会开始触发降频，性能直线下滑。
量产稳定性。开发板调得再好，和量产板还是有区别的。选择核心板 + 底板这种方案时，尽量把 DDR 的速率档位调到稳定区，不要一味追求最高频率，否则量产批次会因为 PCB 布线稍长就出现不稳定。另外，量产阶段的批量烧录、SN 管理、OTA 升级方案要提前设计，别等几千台设备铺出去才发现没法在线升级模型，那就折腾大了。
最后再说一个很多人问的问题：什么时候用云，什么时候用边缘？我的标准是：数据隐私要求高、网络不稳定或时延要求低时，边缘优先；模型需要频繁迭代更新、需要聚合大量数据训练时，云优先。现在越来越多的方案走“边缘推理 + 云端训练”的混合路线，这其实是当前工程上最稳妥的选择。选型不是百米冲刺，而是一场综合博弈，把场景需求、成本、功耗、工具链都放到一张表里去做权衡，你就能在各种边缘 AI 芯片之间找到真正的那一个。
