99POS

Demo 很流畅，量产掉一半

Demo 在开发板上跑得好好的，换到量产盒子帧率掉一半。查了一圈才发现：模型里有几个算子 NPU 不支持，被工具链切回 CPU 上跑，每一帧数据都在内存里来回搬。

端侧识别的性能问题，一大半不是算力不够，是算力放错了地方。要纠偏，先把整条链路摊开看。

一条视频流的五道工序

识别不是「模型跑在芯片上」一句话的事。一帧画面从进设备到出结果，要过五道工序，每道有自己的归属：

两个最常见的放错：识别推理扔给 GPU，和收银界面渲染抢同一块资源；前处理裸跑在 CPU 单线程上，把整条链路拖住——瓶颈根本不在推理。

NPU：能效最高，但它得认识你的算子

NPU 是为卷积和矩阵乘定制的电路。同样一份推理负载，NPU 的功耗明显低于 GPU——这对被动散热、全年开机的收银设备是硬指标，不是锦上添花。

限制同样硬：NPU 只跑工具链认识的算子。模型里有一个不支持的算子，网络就从那里被切开，切出去的部分回退到 CPU 或 GPU，数据跨单元搬运。搬运的代价经常比计算本身还大——切分点落在哪一层、跨单元的数据量多大，比「几成算子在 NPU 上」更能预测帧率。

所以「模型能不能上 NPU」是个算子问题，不是算力问题。答案在工具链的转换报告里，不在 TOPS 数字里。

GPU：通用、省心，但端侧经不起满载

GPU 的长处是通用和生态：算子覆盖广，框架拿来就能跑，调试工具齐全。模型迭代快的阶段、结构里有动态控制流或自定义算子的部分，落在 GPU 上是合理选择。

代价是功耗和发热。端侧 GPU 长时间满载，在被动散热的收银盒子里撑不住；加风扇，门店环境的粉尘和噪音问题跟着来。

还有一个常被忽略的角色冲突：收银设备的 GPU，本职是渲染界面。推理挤上来之后，界面掉帧和识别掉帧会同时出现，排查时两边各说各话，谁都觉得自己是受害方。

什么任务给谁：看本职，不看谁强

不说「NPU 比 GPU 强」，说各自的本职：

• 检测、分类、分割的卷积主体：给 NPU。这是它为之设计的负载，能效优势最大。
• 动态控制流、变长输入、自定义算子：留 CPU 或 GPU，等工具链支持后再迁移。
• 多路视频接入：先算编解码单元的路数上限，别让解码偷偷占掉内存带宽。
• 界面渲染：GPU 的本职，尽量别让推理来抢。

一个模型不必整体落在同一个单元上。工具链的切分报告会写明每一层去了哪——那份报告比任何规格表都值得细读。

接手项目时的四步排查

按顺序走，每步一个产出：

1. 跑模型转换，拿切分报告。 看哪些层离开了 NPU、去了哪。回退层的数据量和切分位置，比 TOPS 数字更能预测实际帧率。
2. 量各级耗时分布。 解码、前处理、推理、后处理各占多少。前处理拖垮整条链路的情况，不比推理瓶颈少。
3. 确认渲染和推理是不是在抢同一块 GPU。 在抢，先把两边负载拆清楚再谈优化，否则怎么调都是按下一边、翘起另一边。
4. 多路场景先算解码上限。 路数加上去，先撞墙的是解码单元还是 NPU，决定扩容方案往哪边走。

这套分工的局限

NPU 工具链每家互不通用，模型要逐家转换、逐家验证；模型一迭代，这套流程就得重走。「转换与验证」要当成团队里的固定工作，不是一次性任务。

算子支持表随工具链版本变。上个月不支持的算子这个月可能支持，反过来也一样。切分报告要在当前用的工具链版本上重新生成，旧报告不作数。

常见问题

NPU 和 GPU 在端侧识别里有什么区别？

分工不同。NPU 是为卷积和矩阵乘定制的加速器，能效高但只跑工具链认识的算子；GPU 通用、算子覆盖广、生态成熟，但长时间满载的功耗和发热在端侧设备里撑不住。选谁看任务本职，不看谁强。

模型能直接跑在 NPU 上吗？

不能，要先用厂商工具链转换。转换会产出切分报告，写明哪些层在 NPU、哪些回退到 CPU 或 GPU。回退层多的模型，先解决算子问题，再谈性能优化。

NPU 不支持的算子怎么处理？

三条路：换成等价的受支持算子（改模型结构）、让该层留在 CPU 或 GPU 上（接受搬运开销）、升级工具链版本。选哪条，看回退层的数据量和模型迭代频率。

前处理和后处理跑在什么上？

通常都在 CPU。缩放、颜色空间转换这些前处理，和非极大值抑制这类后处理，在端侧常是隐形瓶颈；优化 NPU 之前，先把这两段的耗时量出来。

GPU 在收银设备里干什么？

本职是渲染收银界面。识别推理放到 GPU 上会和渲染抢资源，两边同时掉帧。GPU 跑识别适合开发调试阶段，量产形态里推理主体应该落在 NPU。

数据来源

本文为端侧识别算力分工的通用工程说明，不引用任何具体型号的官方参数；各任务的算子支持情况，以对应厂商当前版本工具链的转换报告为准。