边缘端 AI 算力选型这个话题，我这两年被问到的频率实在太高了。几乎每个来找我帮忙看方案的人，开场台词都差不多：这块芯片算力标称多少 TOPS，够不够跑我的模型？说实话，这种问法从一开始就跑偏了。真正的问题从来不是“芯片有多强”，而是“你的场景到底需要多强”。这篇博文就把我自己在项目里反复用的一套选型方法完整讲一遍，核心思路就是标题里那四个字：从场景反推芯片。我会把 TOPS、INT8/FP16/FP32 这类容易糊弄人的概念拆开讲清楚，再拿一个真实项目案例，从 8 路视频结构化到轻量大模型落地，把算力推算的每一步都摊开给你看。不管你做的是工业视觉、智慧安防、巡检机器人，还是想在本地跑一个 AI Agent，这套思路都能直接拿去用，至少能让你少踩几个我踩过的坑。

1. 为什么要“从场景反推芯片”

1.1 算力选型的最大误区

很多团队的选型流程其实不是“选”，是“抢”。项目一开始，领导或者甲方直接指定要用某款热门芯片，理由是隔壁项目用了、网上评测说强、生态好。然后整个团队围绕这块芯片去适配算法，能跑就上，跑不动就砍功能，砍不掉就降分辨率、降帧率，最后交付一个勉强能用但谁都不满意的系统。

我见过最典型的反面案例：有人在 RK3588 上做 8 路视频结构化，买开发板之前只听别人说“RK3588 有 6 TOPS 算力，很猛”，结果拿回来一跑，同时开 8 路 1080P 解码加 YOLOv5s 检测加跟踪，NPU 直接满载，内存带宽告急，CPU 也凑热闹忙到冒烟。最后只能砍到 4 路，再把检测帧率降到 8，才勉强稳住。问题出在哪？出在别人说“够”的项目场景跟你的不一样，你说的“跑得动”跟系统的真实需求也不一样。

所以选型的第一步，不是看芯片参数，而是把场景需求量化。算力够不够，不是一个定性问题，是一个定量问题。你说“够”，至少要回答“多少路、多少分辨率、多少帧率、多少个模型、多低的时延才算够”。没有这些数字，任何芯片选型都是拍脑袋。

1.2 场景拆解的第一步：先回答四个问题

我在做选型之前，会逼着需求方把场景参数填满一张需求表。这张表其实就四个核心问题：

• 输入是什么？分辨率、帧率、路数、视频编码格式，还是传感器数据，还是纯文本输入。这决定了数据入口的吞吐压力，也就是解码和预处理负载。

• 算法是什么？用目标检测、语义分割、姿态估计还是大语言模型？模型参数量多大？输入尺寸多少？是单模型流程还是多模型级联（比如先检测后跟踪再属性识别）？这决定了核心算力消耗点。

• 时延要求多高？是实时控制（比如机械臂抓取，要求在几十毫秒内出结果），还是准实时处理（比如视频结构化，单帧分析可以接受几百毫秒），还是离线分析（完全不关心时延，只关心吞吐）？时延等级直接影响算力冗余设计。

• 部署环境限制？供电功率、散热条件、外壳体积、户外还是室内、工作温度范围、是否需要宽温设计。这一点很多人会忽略，等结构设计完了才发现芯片散热压不住，又回头换平台，折腾一次至少一两周。

这四个问题填完之后，你才算有了“场景”的清晰画像。就拿买车来类比：你不会因为某款车发动机排量大就买它，你会看平时是通勤还是跑长途，是买菜还是拖房车，有没有停车位，充电方不方便。算力选型跟买车是一个道理，先明确“用车需求”，再谈“发动机参数”，顺序反了肯定出事。

1.3 从场景到算力需求的推导链路

场景画像有了，下一步就是把场景翻译成算力需求。这条链路很简单，就三步：

第一步，把场景转成计算量。说白了就是算一秒钟要跑多少次推理。公式其实很朴素：每秒推理次数 × 单次推理计算量。比如你要做 8 路实时检测，每路按 10 帧每秒处理，那一秒就是 80 次检测；单次检测如果是一个 640×640 输入的 YOLOv5s，大约需要 16 GMACs 左右的计算量，换算下来每秒大约需要 1.28 T MACs，再折算成 INT8 下的操作次数（乘加算两次操作），大约 2.56 TOPS。

第二步，加上设计冗余。不要把算力用到 100%，因为你还有系统开销、多线程调度、驱动损耗、模型升级空间。我一般至少留 1.5 到 2 倍余量。刚才那个例子就要按 4 到 5 TOPS 的需求去选芯片。

第三步，对照芯片的“有效算力”而不是“标称算力”来选择。这一步最关键，也是大多数人翻车的地方，下一章我专门讲算力标定的坑。

2. 算力标定：TOPS、INT8/FP16/FP32 那些容易被营销话术糊弄的事

2.1 TOPS 是怎么算出来的，别被账面参数骗了

TOPS 是 Tera Operations Per Second，每秒万亿次运算。听起来很硬核，但这里有个很容易被忽略的点：这个 O 到底是什么 Operation，厂商和厂商之间用的口径并不完全一致。最常见的是以 INT8 乘法累加运算为基础，一次 MAC（乘加）算两次操作（一次乘、一次加），所以理论上 TOPS = MAC 次数 × 2。

但有些厂商在宣传时喜欢用稀疏化算力，就是声称跳过矩阵里的零值，直接把测出来的稀疏场景算力标到参数表上。这类标称值在实际跑稠密模型的时候完全达不到。还有一些芯片标称算力是“理论峰值”，要构成这个峰值需要把 NPU 的每个 MAC 单元都跑满、数据搬运没有冲突、算子完全匹配硬件结构，这在真实模型推理里几乎做不到。所以你会看到很多芯片，标称 6 TOPS，实测跑 YOLOv5s 只能跑出 3 到 4 TOPS 的有效算力，我不是在黑某一家，这是行业通病，国产进口都有。

我的习惯是，拿到一颗芯片先不看官方 PPT，直接跑一个基准模型，用同样一个 YOLOv5s 或者 MobileNet，在同样输入尺寸下测帧率，反推有效算力。同一个模型测出来的差异，比任何参数表都有说服力。

2.2 INT8、FP16、FP32 的实际算力差异

精度格式是另一个容易踩坑的点。先说结论：边缘端部署，绝大多数情况下用 INT8；FP16 常见于 GPU 类平台和高精度要求场景；FP32 在边缘端很少用，只有在部分不支持低精度优化的老芯片上才被迫使用。

这三者的差异，可以用一个简单对比说明：

我举一个具体数字：同一个模型在支持的硬件上，INT8 的推理速度通常是 FP16 的 1.5 到 3 倍，是 FP32 的 3 到 8 倍。原因很简单，带宽占用少了一半到四分之三，而边缘端 NPU/DSP 的 MAC 阵列本身就是为低精度优化设计的。

所以选型时不要只看“标称 TOPS”，要先确认这个 TOPS 是什么精度下的。同一颗芯片，FP16 算力和 INT8 算力往往差一倍以上。你拿 INT8 TOPS 去跑 FP16 模型，实际能跑出来的速度可能只有账面的一半甚至更低。RK3588 的 NPU 标称 6 TOPS，指的是 INT8 下的理论峰值；如果你非要用 FP16 跑，算力就要大打折扣。很多人不知道这一点，照着 INT8 峰值去估算了模型吞吐，结果部署时发现模型是 FP16 的，性能缩水到怀疑人生。

2.3 带宽和内存：最容易忽略的“隐性算力”

算力（TOPS）只是肌肉，带宽和内存才是神经系统。很多项目算力选完看起来没问题，真跑起来却卡成 PPT，问题往往出在带宽上。

举一个我实际调过的案例：某项目用一颗标称 3 TOPS 的 SoC 做 4 路 1080P 视频分析，理论上算力完全够，但实测 NPU 占用率只有 40% 的时候就跑不动了。我查了内存带宽占用，DDR 带宽直接打满。问题出在哪？出在解码、缩放、NPU 数据搬运、CPU 后处理都在抢同一份内存带宽。视频解码器把原始帧写进内存，NPU 把帧数据从内存读到片上缓存，算完再写回内存，CPU 后处理又要读一遍。一次推理看起来只有一个模型计算量，实际上数据来回搬了好几次，带宽开销远大于模型本身的计算量。

所以选型时，除了看 TOPS，还要看三样东西：内存类型（LPDDR4X 还是 LPDDR5，带宽差很多）、内存通道数和位宽、以及 SoC 内部是否有独立的编解码单元。RK3588 之所以在边缘视频分析领域口碑好，不只是因为有 6 TOPS NPU，更因为它自带强大的 VPU 硬编解码，能把视频解码从 CPU 上解放出来，省下大量带宽和 CPU 时间。很多评测博主只盯着 NPU 数字，不跟你提 VPU 和带宽，但真实项目里这些往往比算力数字更致命。

3. 主流边缘芯片平台梳理

3.1 MCU 级：STM32、ESP32，只能做简易 AI

很多做硬件出身的朋友喜欢从 MCU 切入 AI，因为上手简单、成本低、没有复杂系统。STM32 的生态确实好，CubeMX 点点点就能生成工程，又有大量现成例程；ESP32 则胜在网络能力强，配个摄像头模块就能做简单的图像采集和 WiFi 传输。

但要认清一个现实：MCU 级芯片的算力天花板就在“微型 AI”这个档位。你可以在 STM32 上跑一个关键词语音唤醒，比如“你好芯片”这种；可以在 ESP32 上用轻量级模型做手势识别、异常声音检测、简单故障诊断；但你想跑 YOLOv5 级别的目标检测，哪怕是最小的模型，MCU 也扛不住。原因很简单：MCU 的算力单位是 GOPS，而不是 TOPS，差了三个数量级，而且内存只有几百 KB 到几 MB，模型参数都装不下。

我用 ESP32-S3 做过一个实验，跑一个极端压缩的人体存在检测模型，输入 96×96 灰度图，帧率只能跑到 3 到 5 FPS，CPU 已经满载。这个水平做“有人经过才点亮屏幕”这种场景够用，但离实时视觉分析差得太远。所以 MCU 适合的场景很明确：低成本、低功耗、单点触发、模型极小、对时延不敏感。如果你想用 MCU 做视觉 AI，我劝你冷静一下，这不是优化能解决的问题，是硬件算力天花板的问题。

3.2 轻量 SoC 级：K210、树莓派，入门玩具到准工业

轻量 SoC 这个档位，是很多 AI 爱好者和原型验证项目的甜点区。嘉楠科技的 K210 是这个价位最出名的选择之一，自带 KPU（知识处理单元），标称算力 0.8 TOPS 左右，功耗极低，开发板几十块就能买到，玩过人脸识别门禁的同学应该都认识它。我做原型验证时用过 K210 跑简单的人脸检测，效果在室内光照均匀的场景下是可以接受的，但一旦遇到逆光、侧脸、遮挡，效果就崩得很快。

树莓派则是另一个极端，它的 CPU 通用性很强，但 AI 算力全靠 CPU 硬算，或者靠外挂加速棒（比如 Hailo、Intel Movidius），单板本身没有什么 NPU 算力可言。树莓派更适合做“系统的控制中心”而不是“算力核心”，你可以用它做数据采集、界面控制、网络通信，但指望它实时跑 YOLOv5s 也是不现实的。

这个档位适合谁？适合三件事：学习 AI 部署流程、验证算法可行性、做数据流原型。真要上产线、做产品，我还是建议直接跳到下面的高性能 SoC 档位。别浪费时间在玩具上做工业级验证，你会发现换平台之后很多坑还得重新踩一遍。

3.3 高性能 SoC 级：RK3588、Jetson Orin Nano，边缘 AI 主力

这是边缘端 AI 项目的绝对主力区间。瑞芯微 RK3588 和英伟达 Jetson Orin Nano 是这个档位最有代表性的两个选手，很多朋友纠结在这两者之间，我把几个关键差异摆出来：

我的建议很直接：如果你做的是视频分析类产品，而且要考虑量产成本，RK3588 是目前性价比很高的选择，尤其它是国产芯片，供应链和合规性都省心不少；如果你团队以算法为主，希望把训练和部署拉得近一点，不太想折腾模型转换和算子适配，Jetson 的 CUDA 生态会让你舒服很多，代价是成本高、供货周期长。

顺带说一句，Jetson Orin Nano 的“8 TOPS”和“20 TOPS”其实是同一个芯片，一个是 8GB 版本降频，一个是 16GB 版本满血，别看走眼。

3.4 面向 AI Agent 和多模态的算力盒子

最近 AI Agent 和端侧大模型火得不行，很多朋友问我：能不能在边缘端跑一个轻量大模型，做一个本地无云的 AI Agent？答案是可以，但仍然要“从场景反推”。

先说数据。目前主流的轻量大模型，比如 Qwen2.5-3B、Llama-3-8B，经过 INT4 量化后，参数量缩到约 2GB 到 5GB，在 RK3588 或者 Jetson Orin 上可以跑起来，但生成速度比较感人。实测下来，8B INT4 在 RK3588 上只有 3 到 6 token 每秒，在 Orin Nano 上稍好一些，大概 8 到 15 token 每秒。这个速度做聊天机器人体验很差，但做离线文档摘要、定时任务报告生成、结构化信息提取，完全够用。

我的建议是：不要把大模型推理放在 NPU 上硬跑，而是把端侧 Agent 拆成感知、决策、生成三段。感知部分用传统视觉模型跑 NPU，比如目标检测、OCR、人脸识别；决策部分用规则引擎或轻量逻辑；生成部分才交给大模型，而且只在真正需要时调用。这样一来，算力消耗最大的视觉部分落到高效 NPU 上，大模型只在低频次跑，整个系统的响应速度和发热都得到了控制。

顺带提一下云端验证和边缘部署的关系。很多人会先在 AutoDL 这类云算力平台完成模型验证和参数调试，再把模型量化移到边缘端，这是很高效的工作流。边缘端选型前，先用云端“租算力”把算法效果验证完，不要拿边缘开发板去慢慢跑实验，一天的时间成本差很多。

4. 实操：8 路视频结构化 AI 盒子的算力推算全过程

4.1 场景需求参数

为了把上面的方法落到地面上，我拆一个最近刚做完的真实项目。需求很简单：一个边缘计算盒子，接 8 路 1080P 网络摄像头，要做行人检测、人脸抓拍、车辆属性识别，同时要把结构化结果通过 MQTT 上报到平台。

一开始需求方给我的要求只有一句：“找个算力够用的盒子。”我说不行，你得先跟我把参数对齐。最后我们一起填出了这样一张表：

• 视频输入：8 路 1080P，25 帧每秒编码流，H.264/H.265 混合
• 检测目标：行人、车辆、人脸，三个模型串联使用
• 检测输入尺寸：640×640
• 检测帧率：每路要求 10 FPS 以上，保证不漏人
• 时延要求：从视频帧到达处理模块到输出结构化结果，不超过 500ms
• 功耗约束：整机功耗 15W 以内（适配器 24V 供电，无风扇）
• 部署位置：室外机箱，工作温度 -20℃ 到 55℃

这张表一出来，选型目标就清晰了：需要一个能同时干三件事的平台——硬解 8 路 1080P 视频流、跑三个串联检测模型、在 500ms 时延内完成结构化，同时整机功耗控制在 15W 左右。

4.2 算力与带宽推算

接下来是数学时间。先算检测模型的单次推理计算量。以 YOLOv5s 为例，输入 640×640，大约需要 16 GMACs。注意这是乘加运算次数，换算成“操作次数”需要乘 2，也就是 32 GOPS 左右。但这只是理论值，真实测下来，加上预处理、后处理、NMS，一个实际检测流程大约消耗 40 GOPS 的计算资源。

每个目标模型都跑一遍显然太多了。项目里实际做的是：先用行人检测模型跑全图，检测到目标后再用小图裁剪做属性识别；人脸抓拍也是，先行人检测框出人头区域，再送给小型人脸检测网络做精确抓拍，最后才做人脸特征提取。所以实际计算量是“全图大模型 × 检测帧率 + 小图模型 × 目标数量”，依赖目标数量，上下浮动明显。

推算如下：8 路 × 10 FPS = 80 次全图检测每秒，单次约 32 GOPS，这样每秒需要 80 × 32 = 2560 GOPS，也就是 2.56 TOPS。再加上属性识别和特征提取这类目标级模型，按每路每秒平均 5 个目标、每个目标额外消耗 1 GOPS 算，又是 8 × 10 × 5 × 1 = 400 GOPS，总共约 3 TOPS。按我前面说的 1.5 到 2 倍余量，实际需求是 4.5 到 6 TOPS INT8 的有效算力。

带宽方面，8 路 1080P@25FPS 解码后原始数据量大约是每路 1920×1080×3 字节 × 25 = 155 MB/s，8 路合计 1.24 GB/s。即便做 ROI 裁剪和缩放，NPU 读取和写回也需要消耗可观的带宽。实测 LPDDR4X 平台的 68GB/s 带宽，要同时支撑解码、缩放、NPU 推理、CPU 后处理，余量真的不多，这也是我强烈建议用带 VPU 硬解芯片的原因。

4.3 芯片选择与最终配置

算完这笔账，答案已经很明显了。满足算力 4.5 到 6 TOPS、自带硬解、功耗 15W 以内的平台，市面上可选的也就那么几款，其中 RK3588 几乎是这个需求的“标准答案”。

最终我选的配置是：RK3588 平台，8GB LPDDR4X，系统盘 32GB eMMC + 128GB SSD，双千兆网口，整机外壳用挤压铝被动散热。选 RK3588 的理由很明确：三核 NPU 总计 6 TOPS INT8，满足余量需求；自带 VPU 支持 8 路 1080P 硬解，不需要额外加视频解码芯片；CPU 有 8 核 A76/A55，跑后处理和业务逻辑绰绰有余；国产化供应链稳定，不像某些进口芯片一订就要等四个月。

这里有个细节：RK3588 有三个 NPU 核心，RKNN 工具链默认会把模型分配到多个核心上并行跑。我把三个检测模型分别部署到不同的 NPU 核心上，行人检测占一个核，车辆检测占一个核，人脸抓拍和属性识别共享一个核，再用 CPU 做任务调度。这样充分的核并行，实测 NPU 整体负载在 70% 左右，还有余量应对高峰。

4.4 实际效果与调整空间

实测数据是这样的：8 路 1080P 全部启用，每路检测帧率稳定在 12 FPS 左右，超过需求表里写的 10 FPS；从视频帧到 MQTT 输出的端到端时延约 380ms，在 500ms 指标以内；整机功耗实测约 11W，散热片温度稳定在 52℃ 左右（环境温度 25℃ 下），放到室外机箱里也没有过热降频。

不过这套方案不是没有冗余空间。如果甲方后续要加“抽烟检测”或“安全帽检测”这类新模型，按现在的负载是跑不动的。我的处理方案是：新模型只对检测到“人”的 ROI 区域做二次分析，而不是全图跑，这样增加的计算量非常有限。这个思路核心就是“大模型粗筛、小模型精查”，边缘端算力有限，要学会用策略换算力，而不是一味堆硬件。

5. 常见问题与排查实录

5.1 为什么芯片标称算力够，跑起来却卡

这是我在技术支持里遇到最多的问题。一上来就是“明明是 6 TOPS，为什么跑个 YOLOv5s 还卡成狗”，排查下来原因大概分三类。

第一类是模型算子没有完全落到 NPU 上。很多模型里有些层是 NPU 不支持的，比如某些自定义算子、动态 shape 的 op、特殊的激活函数。RKNN 工具链遇到不支持的算子，会回退到 CPU 执行，而 CPU 跑卷积层的速度可能只有 NPU 的十分之一。如果模型里恰好多层都落到 CPU 上，性能就直接崩了。排查方法很简单，用 NPU 提供 profiling 工具，把每层的耗时和执行单元拉出来看，一眼就能发现哪些层在“拖后腿”。

第二类是内存带宽瓶颈。芯片的 TOPS 是算力天花板，但数据要喂进 NPU 才能算，喂不进来算力就空转。前面那个 4 路卡顿的案例就是典型，内存带宽满了，NPU 反而在等数据。排查方式是跑推理的同时监控内存带宽占用率，或者看实际吞吐距离标称 TOPS 差多少。

第三类是驱动和工具链版本问题。边缘 AI 芯片的工具链更新频率很高，同一个模型在不同版本工具链下的性能差异很大。RKNN 工具链 1.4 和 1.5 跑同一个模型，帧率可能相差 20% 以上。所以拿到开发板后第一件事就是把工具链更新到和官方最新文档匹配的版本，不要用了半年还在跑出厂固件。

5.2 量化和精度问题

模型从 FP16 量化到 INT8，精度掉点是最常见的部署事故。很多团队选型时没把量化精度考虑进去，FP16 验证时效果好好的，一量化到 INT8，检测 mAP 直接掉了 5 个点以上，小目标几乎全丢。

我的经验是：量化掉点严重时，先用“逐通道量化”替代“逐张量量化”试试；再不行，给模型换个小数据集做校准集，校准集和实际部署场景分布越接近越好。第三个办法是混合量化，敏感的层（比如检测头的最后几层）保留 FP16，骨干层用 INT8，这样精度损失很小，速度也只损失一点点。还有一个冷门但好用的技巧：INT8 量化后如果发现某些输入框偏移严重，去检查输入数据预处理，确保校准和推理时的归一化参数完全一致。很多人掉点是因为预处理不一致，跟量化本身关系不大。

5.3 AI Agent 和轻量大模型部署的算力误区

接着前面 AI Agent 的话题说。很多朋友有一个认知误区，认为边缘端跑大模型就是把一个模型拉到板子上跑，跑得动就用，跑不动就换更强的板子。真不是这样。

我实测过在 RK3588 上跑 INT4 量化的 Qwen2.5-3B，单线程推理速度约 8 token/s，端侧可用但离流畅对话差得远；换 8B 模型大概只剩 3 token/s，基本不可用。但这不代表边缘端不能做 AI Agent，重点是架构设计。比如一个巡检机器人 Agent，完全可以用 NPU 跑视觉感知，用规则引擎处理状态机，用大模型只做“总结汇报”和“语义解析”这两个环节，大模型调用频率降到每 30 秒一次，甚至更少。这样算下来，一个 3B 模型的推理需求分摊到 30 秒里，完全不会卡顿。

另一种思路我最近在试：把大模型放在本地做“小脑”，云端做“大脑”。本地模型负责意图粗分类和工具调用，复杂的文档问答和长文本生成都走云端 API。这套架构的好处是断网时基础功能还能用，联网时大模型负责更聪明的部分，也算是一种“共享算力”思路，只不过共享的是公共云算力而不是局域网里的个人电脑。

5.4 供应链和生命周期坑

选型时只管性能和技术、不看供应链和生命周期，是很多项目后期痛苦的根源。我用过一款国产新锐芯片，算力和功耗数据都很漂亮，结果量产前厂商通知该型号生命周期结束，我们被迫重新选型，前后折腾了两个月。所以选型清单里一定要加上生命周期这一栏。

具体怎么判断？第一看芯片是否被多家知名方案商采用，采用量大说明生命周期和供货稳定性有保障。第二看厂商是否有长期供货承诺，一些大厂会提供 5 到 10 年的供货周期说明。第三看是否有第二供应商替代方案，至少画好备份方案，一旦主芯片停产，能够在 1 个月内切到替代平台。

顺便说一句硬件可靠性。边缘设备多在户外或工业环境运行，芯片选型时别只看算力，还要看工作温度范围、看门狗、电源纹波耐受能力。有的芯片参数表写着 -40℃ 到 85℃，实际放户外夏天晒到 60℃ 就开始降频，设计时必须留足散热余量，必要时加被动散热片加风扇，或者选宽温版芯片。

选型这件事，做久了你会发现它本质上不是一道技术题，而是一道数学题加工程题。算力需求是算出来的，不是感觉出来的；芯片选型是对着需求表比出来的，不是对着天梯图挑出来的。我个人最值钱的一个习惯，就是每个项目开始前先做一张“场景参数表”，把分辨率、帧率、路数、时延、功耗、成本全部列出来，再对照芯片的有效算力、带宽、生态、生命周期逐项打分。这套流程看起来笨，但能挡住百分之八十的选型翻车。最后再分享一个小技巧：拿到新芯片开发板后，先别急着跑业务模型，用统一的基准模型（同一个 YOLOv5s、同一个输入尺寸）测一遍有效算力，记录下来。不同芯片之间横向对比的时候，这份实测数据比任何厂商 PPT 都可靠。我的实测数据库现在已经攒了十几款平台了，每次选型都会先查自己的记录，而不是去翻评测文章。希望这篇内容能让你少走几步弯路，也欢迎在实际项目里把你这边的选型心得再验证一遍。