企业官网建设流程全解析

1. 场景约束才是边缘AI选型的第一输入

我见过太多项目是这么开始的：先在电商平台上看到一块开发板，标称 6TOPS、8TOPS，看起来参数很猛，价格也能接受，于是先买回来，再琢磨“到底能做什么”。结果等真正接上工业相机、跑起自己的模型，才发现帧率不够、带宽顶满、接口对不上，板子只能在桌面吃灰。这个顺序一旦搞反，后面每一步都是在给前面的冲动买单。

边缘端 AI 算力选型的真正起点，从来不是“哪颗芯片算力大”，而是“我到底要把什么任务，放在什么环境里，以什么样的频率运行”。一个好的选型过程，应当是从场景需求反推芯片：先确定功能边界，再确定模型规模，再算出算力、内存、带宽和功耗需求，最后才落到具体芯片型号。

为什么我不厌其烦地强调这一点？因为算力数字本身非常具有欺骗性。一颗芯片标注的 TOPS，往往是在最理想条件下、用特定算子、特定数据精度测出来的峰值；而真实项目里，推理框架的调度开销、数据搬移、预处理、后处理、多路视频解码，都会把有效算力大幅拉低。你在宣传页上看到的“6TOPS”，真正能用到项目里的，可能只有 2-3TOPS，甚至更低。

所以拿到一个边缘 AI 项目时，我的习惯是先列一个约束清单，三个问题必须回答清楚：

• 供电和散热环境：设备是插电固定安装，还是电池供电？能承受多少瓦的功耗？机箱是密闭还是通风？
• 实时性要求：是 10 毫秒级的工业控制反馈，还是 300 毫秒可接受的分析告警？这直接决定你能不能用简单的端侧设备，还是必须上更大算力的平台。
• 数据规模与路数：现在接 1 路摄像头，未来会不会扩展到 8 路 12 路？模型输入是 640×640 还是 1920×1080？这些一乘，算力需求可能直接翻一个数量级。

举一个很常见的例子：做智能楼宇的人脸门禁，单路 1080P 视频、每秒钟跑 1-2 帧检测，这个负载其实不大，很多带 NPU 的 SoC 都能轻松完成。但同一个模型如果放到工厂产线上，变成工业相机每秒钟处理 30 帧，还要在 20 毫秒内把缺陷信号传给 PLC 停机，那就不是同一回事了。前者用 STM32 加一颗轻量 NPU 都可以，后者可能需要上到 RK3588 这种级别的平台。

换句话说，场景约束决定了任务的极限值，任务极限值决定了模型复杂度，模型复杂度决定了你能接受什么样的量化精度和推理框架，最后一环才是选芯片。这篇文章后面所有内容，都是围绕这条反推链展开的。

2. 把业务需求量化成TOPS、带宽和精度的这套算法

2.1 先弄清楚 INT8、FP16、FP32、FP64 到底影响什么

很多新手选芯片时会忽略数据类型，直接在对比表里看 TOPS 谁大就选谁。实际上，数据类型对算力需求的放大效应，远比芯片标称值更重要。

先看一张极简关系表：

为什么边缘端如此偏爱 INT8？因为硬件设计上，一个 INT8 乘法器占用的晶体管面积和功耗，远小于 FP16 乘法器。芯片厂商省下来的面积，可以放进更多计算单元，从而推高“宣传 TOPS”。同时 INT8 权重只占 FP32 四分之一的内存带宽，搬运同样数据量时，带宽压力小得多。这就是为什么几乎所有边缘 NPU 都围绕 INT8 做优化。

但要注意，这只是标称理论对比。有些芯片的 INT8 和 FP16 算力是分开展示的，一块 RK3588 的 NPU 标称 6TOPS，通常指的是 INT8 条件。如果你为了精度必须跑 FP16，实际算力可能就不是 6TOPS，而是更低的数值。选型时务必查清楚这颗芯片的 FP16 算力规格，别把 INT8 的满血值当成能直接用一辈子的数值。

FP64 在边缘端基本可以划掉。除非你在做流体仿真、地质建模这一类必须双精度计算的活，那本来也不是边缘 AI 该干的。选型阶段就把数据类型写进规格表，后面每一步计算才有依据。

2.2 从“模型运算量+帧率”反推 TOPS 需求

选型的核心计算其实很简单，我在多个项目里用的都是同一个公式：

所需算力（TOPS）≈ 单次推理运算量（GFLOPs）× 目标帧率（FPS）÷ 1000 ÷ 有效利用系数

这里的有效利用系数，我一般取 0.4-0.6。原因很粗暴：NPU 在真实调度时有初始化、等待、数据搬运、算子不连续等开销，理论峰值很难维持。保守一点，按 50% 估算比较稳妥。

举个例子。假设你的目标模型是一个 YOLOv5s 级别的检测网络，单次前向推理的运算量约 16GFLOPs。你希望在边缘设备上以 15FPS 实时运行，那么：

16 × 15 = 240 GFLOPS/s 240 ÷ 0.5 = 480 GOPS/s ≈ 0.5 TOPS

只看这个数字，你会觉得哪怕一颗 2TOPS 的芯片都绰绰有余。但请注意，这只是纯模型的推理负载。真实部署时，你还要加视频解码、图像缩放、色彩空间转换、NMS 后处理、多线程调度，甚至可能同时跑多个模型。把这些全算进去，实际占用可能是模型推理量的一倍以上。所以我一般会在最终结果上再乘 1.3-1.5 的余量系数。

再考虑多路并发。如果一台设备要接 8 路摄像头，每路 10FPS，那就是 8×10=80FPS 的等效推理负载，算力需求就变成刚才的 5 倍多。这也是很多项目做完单路 Demo 很流畅、一上多路就崩的真实原因。

2.3 算力不是唯一瓶颈，内存带宽往往先爆

做大模型部署或者处理大分辨率视频时，经常会出现一种魔幻现象：NPU 利用率不算高，但程序跑得很慢，换更贵芯片也没明显改善。这种情况十有八九是内存带宽被顶满了。

可以把算力和内存带宽的关系想象成餐厅：算力是后厨的锅灶，内存带宽是传菜通道。锅再多，传菜跟不上，翻台率照样上不去。

一张 1080P 图像在 INT8 下就是约 2MB 数据。如果模型输入分辨率是 1920×1080，一秒钟处理 30 帧，光输入数据就是 60MB/s，还不算中间特征图、权重参数、多路解码数据。遇到注意力机制、大卷积核这类高访存算子，带宽消耗会更夸张。

因此选型时不仅要看芯片算力，还必须关注芯片支持的内存类型和位宽。同样是视觉盒子，有些板载 LPDDR4X，带宽只有 30-50GB/s；有些上 LPDDR5 双通道或 DDR5，带宽能到 68GB/s 甚至更高。你要跑本地大模型或高分辨率多路视频，带宽参数比 TOPS 更重要。

2.4 别忘了功耗、温度和长期稳定性

边缘设备往往装在现场，不是在空调机房里。工业现场可能 60 摄氏度环境温度，室外杆上设备可能有阳光直射，电池供电设备则对功耗极度敏感。

芯片标称功耗和真实满载功耗是两码事。以 RK3588 为例，虽然不少资料说板卡典型功耗 5-10W，但当你把 8 路 H.265 解码加上 NPU 满载加 CPU 多线程跑起来，整板功耗可能冲到 15-20W 以上。如果机箱是铝合金密闭结构，散热设计没跟上，芯片降频带来的算力损失，会比选小一个档次的芯片更严重。

所以需求表上应该明确写：峰值功耗上限是多少？散热方式是自然散热还是带风扇？工作温度范围是多少？这几条直接决定你能不能把算力充分释放出来。

3. 从MCU到边缘GPU：主流芯片档位的适合场景

把常见边缘 AI 平台按算力量级和场景分成四个档位，对比更清晰。

第一档 MCU 级，常被低估，但在对的地方非常合适。比如 STM32 系列跑 TensorFlow Lite Micro，可以在极低功耗下做简单的异常声音检测、震动频谱分析、传感器状态分类。ESP32-S3 这类带向量指令的芯片，也能做轻量级关键词识别。它们不适合跑视觉检测或大模型，但适合那些“每天只唤醒几次、电池要用一年”的任务。

第二档是现在边缘视觉项目的主流。RK3588 是最典型的例子：CPU 部分是四核 A76 加四核 A55，NPU 标称 6TOPS INT8，还带强大的视频编解码能力。玩过的人都知道，这类芯片跑 YOLO 系列、OCR、人脸检测这类常规视觉任务很成熟，资料多、社区活跃，采购和开发成本都可控。如果你的场景是 4-16 路视频分析、工业视觉检测、智能安防盒子，这个档位通常是最先考虑的。

第三档适合需要更大算力、但仍要放在设备端的场景。比如机械臂识别抓取、移动机器人、多模态感知融合，或者要在本地跑 7B 甚至更大参数量的大模型，Jetson Orin 这类的价值就凸显出来了。它们算力足够高，内存带宽大，配合成熟生态，部署周期明显缩短。代价是功耗和价格都上一个台阶。

第四档边缘 GPU 服务器，严格说已经是“机柜边缘”了。当任务复杂到单张 1080P 图需要进行分割、检测、OCR、大模型结构化等多种模型串联，或者要在本地承载一个 7B/14B 大模型的并发服务，就得考虑这种设备。它的好处是把 GPU 的大算力、大显存带到现场，坏处是功耗、散热、体积都不能再叫“边缘小设备”。

给选型做个粗筛：先把场景对应的负载丢进这四档里，至少能砍掉一半错误选项。接下来再用算力和带宽公式精确算一遍，确定档位内的具体型号。

4. 三个选型案例的完整反推过程

4.1 产线视觉缺陷检测：终极需求是接口稳定，不是算力爆炸

一个做电子元件包装盒检测的项目，要求检测每盒是否缺少零件、标签是否贴歪，检测节拍是每盒 2 秒，也就是 0.5FPS 就够。但有一个硬性约束：误检和漏检必须严格控制，一旦判定 NG，要在 50 毫秒内通过 IO 信号触发分拣机构动作。

模型选择相对轻量，单张输入用 800×600 分辨率，YOLOX-s 量化为 INT8 后，单帧推理运算量大约 2-3GFLOPs。按 0.5FPS 计算，纯算力需求连 0.01TOPS 都不到，哪怕一颗 MCU 都够算。那为什么最终选了 RK3588？

原因不在 NPU 算力，而在三件事：第一，工业相机通常走 GigE 或 USB3.0 接口，主控芯片要有足够的 PCIe 和 USB 带宽；第二，现场需要和 PLC 通信，需要串口、GPIO 这些丰富的外设接口；第三，部署现场环境复杂，软件的远程升级、日志采集、异常自恢复能力，都要靠成熟的多核 Linux 生态支撑。

于是推算过程变成：模型算力需求极低，但接口需求高、Linux 生态需求高，最终落在 RK3588 这个档位，而不是 MCU。这就是场景反推的典型路径：不要只看算力，要看整机要承担的所有工作。

4.2 园区 12 路摄像头行为识别：算力乘多路，解码比推理更吃资源

另一个项目是园区边缘节点，一台设备要接入 12 路 400 万像素摄像头，做人形检测、翻越围栏告警。每路控制在 8FPS，模型是 YOLOv7-tiny 量化为 INT8，单帧约 2GFLOPs。

先算推理总量：12 路 × 8FPS × 2GFLOPs = 每秒 192GFLOPs 的推理量。按 50% 有效利用率，需求约 0.4TOPS。这个数字真的不高。但问题出在另一条线上：12 路 400 万像素 H.265 视频实时解码，在 CPU 上解码会吃掉大量资源。所以真正决定选型的，是这颗芯片是否带有足够强的硬件视频解码单元，以及内存带宽能不能撑住 12 路码流同时送入 NPU。

最后方案不是选一颗算力最高的芯片，而是选了 RK3588 这样的平台：它有独立的硬件编解码模块，多路 4K 解码不占太多 CPU，NPU 6TOPS 跑 12 路轻量检测也绰绰有余。整机功耗控制在 20W 内，用自然散热就能稳定运行。这个项目如果只看宣传 TOPS 去选一个大算力平台，既浪费钱又徒增散热压力。

4.3 本地部署大模型做现场质检辅助：内存带宽决定体验

还有一类场景越来越常见：现场不能把数据传到云端，又想在边缘设备上跑一个 7B 级别的语言模型，做质检文本总结或操作规范问答。

这里必须先算模型体积。7B 参数模型用 INT8 量化，权重约 7GB；用 INT4 量化，约 4GB。运行时的激活值、KV Cache、推理框架开销还要额外占 4-6GB。所以内存最小得 16GB，比较稳妥是 32GB。同时，大模型推理是典型的带宽敏感型任务，生成速度跟内存带宽强相关。带 LPDDR5 多通道的设备，生成 token 速度明显快于 LPDDR4X 的老平台。

算力方面，7B 模型即便量化后，单次前向推理也有大几十到上百 GFLOPs，想要每秒生成 5-10 个 token，需要几十 TOPS 的算力和高速内存带宽配合。这个量级已经不是 RK3588 这种 6TOPS 设备能从容应付的了，必须上 Jetson Orin 级别或者配备大显存 GPU 的边缘服务器。

所以本地大模型部署的选型公式可以简化成一句话：内存容量先保底，内存带宽决定速度，算力决定天花板。三者顺序别搞反。

5. 工具链成熟度：能不能落地，就看这一步

我在帮人选型时经常说一句话：选 AI 芯片，七成是在选工具链，三成才是在选硬件。芯片本身的峰值算力只是纸面属性，它配套的模型转换工具、推理框架、算子支持度、量化精度损失、生态资料，才是决定你的模型能不能在两周内跑通的关键。

边缘 NPU 厂商的工具链差异非常大。有的芯片标称算力很猛，但官方给的转换工具对某些模型支持度差，遇到自定义算子就要手写底层实现，项目周期直接被拉长。尤其是 transformer 结构在视觉任务里越来越流行，很多边缘 NPU 对 self-attention、GELU 这类算子的支持还不够完善，同样一个模型在不同平台上的转换流畅度可能天差地别。

所以在最终敲定型号之前，我强烈建议花一到两天做一件小事：拿到芯片厂商的评估板，把你目标模型放进去走一遍完整转换流程，实测推理帧率、内存占用、量化后的精度，以及推理框架对多线程、多路调度的支持情况。不要只看官方文档，不要只看别人跑通的 Benchmark。

这个预先测试至少要覆盖三个方面：

• 模型转换：ONNX 导出是否顺利？官方示例代码改造成自己的模型要花多久？遇到不支持算子时是直接报错，还是有清晰的替代方案？
• 量化损失：用 INT8 量化后，精确率、召回率掉了多少？如果掉得厉害，工具链是否支持 QAT（量化感知训练）？这决定你有没有挽救余地。
• 运行时稳定性：连续跑几天会不会内存泄漏？NPU 和 CPU 的负载分配能不能手动控制？会不会出现多路并发时其中一个任务占满全部资源？

工具链真正成熟的产品，往往不是参数最亮眼的，而是让你把模型跑起来最不痛苦的。

6. 一次就选对的核对单与两个保命经验

最后分享一套我已经固定下来的选型流程，你可以直接抄作业。

第一步，把场景约束写成 8 行以内的需求表：任务内容、输入分辨率、帧率、并发路数、响应延迟、功耗限制、工作温度、接口需求。

第二步，把需求表换成技术指标：模型名称与输入尺寸、可接受的量化精度、单帧运算量、目标帧率和路数、内存带宽需求、内存容量需求。

第三步，计算出所需算力区间，加上 1.3-1.5 倍余量，落到芯片档位。

第四步，在档位里对比 3-5 个候选平台的工具链资料，看看目标模型是不是官方支持范围内的常见结构。

第五步，申请或采购一至两块评估板，实际跑一遍转换和推理测试，保留帧率和功耗数据。

第六步，用测试结果反向校验最初的需求表，确认所有约束都满足，再进入整机设计。

这套流程看着繁琐，但能帮你避免大量后期返工。我见过太多项目，开发到最后发现芯片算力不够，换平台等于所有软件重写。前期多花一周做验证，比后期多花两个月返工划算得多。

还有两个保命经验，值得单独拎出来说。

第一个经验：永远不要相信峰值 TOPS 能稳定达到。实际项目中，NPU 利用率能长期维持 60% 以上已经算优秀，很多场景连 40% 都不到。选型时把和模型无关的负载单独列出来，不要把它们塞进算力需求计算里稀里糊涂带过去。

第二个经验：边缘选型不是选参数最强的，是选你能长期维护的。芯片再强，如果厂商工具链更新频率低、社区资料少、采购渠道不稳定，项目后期完蛋的过程会很痛苦。做边缘 AI 设备，活得久比跑得快更重要。

实际操作中，我做得最多的动作，其实是把那一页需求表反复拿出来跟团队对质：真的需要 4K 输入吗？真的需要 30FPS 吗？真的要在边缘跑大模型吗？很多需求一追问就会发现是伪需求，算力需求也随之大幅缩水。场景反推芯片这件事，本质上就是不断逼问需求的真实性，再用严谨的计算让选型落地。