企业官网建设流程全解析

边缘端 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。即使你的摄像头输出 1080p，AI 计算量也不等于 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 TOPS，FP16 就只有 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 芯片眼花缭乱，但从算力和应用定位维度，可以大致分成几个档位。这里我把每个档位的代表芯片、典型算力范围和适合的工作做一张对照表，方便你快速建立坐标系。

这个表只是一个粗线条的坐标，实际选型时还要看得更细。下面分别说说每个档位的定位和注意点。

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 的选型本来就是把所有坑提前踩完的过程。