1. 端侧推理平台到底是个什么东西先把话说透我在接触深度学习部署的头两年一直觉得“端侧平台”是个模糊的营销词。直到我自己把一个训练好的模型往实际设备上搬被各种算力、内存、功耗问题反复折磨之后才真正理解这四个字背后的分量。这篇是深度学习实践系列里关于端侧平台和算力的第一篇重点落在“平台”这个维度上。后面还会有专门讲算力调优、模型量化和工具链的文章。今天先把地基打牢——端侧平台是什么、它的算力表达到底该怎么看、选型时真正的坑在哪。1.1 先给端侧平台画个边界端侧平台通俗点说就是模型真正跑推理时所在的那个硬件环境。它和云端训练平台是两个完全不同的物种。云端你有A100、H100这种大家伙电费不用自己掏散热有专门机房跑了三天三夜也没人心疼。端侧呢你可能面对的是一台手机处理器功耗预算大概在3到5瓦一个智能摄像头里面的SoC总共才几瓦功耗还要分给图像采集、ISP处理一块工业控制板内存可能只有512MB甚至是一个MCU级别的单片机跑的是TinyML内存按KB算这就是端侧平台的本质特征在严格的功耗、内存、体积、成本约束下把深度学习模型跑起来还要跑得够快、够稳。从硬件形态上说端侧平台大致可以分成三个梯队第一梯队是手机SoC典型代表是高通骁龙平台、联发科天玑平台以及苹果的A系列和M系列芯片。这些芯片内部除了CPU和GPU基本都集成了专门的NPU神经网络处理单元。手机端侧的算力这几年卷得很厉害旗舰芯片的NPU算力普遍在30到70 TOPS这个区间。第二梯队是嵌入式AI SoC比如瑞芯微的RK3588系列、地平线的征程系列、寒武纪的思元系列还有NVIDIA的Jetson平台。这类平台是工业视觉、智能安防、机器人、自动驾驶这些场景的主力军。性能跨度特别大低的只有1到2 TOPS高的能做到两三百TOPS比如Jetson AGX Orin。第三梯队是MCU级别的超低功耗平台比如ARM Cortex-M系列搭配NPU加速器或者一些专用的语音唤醒芯片。这类平台算力通常以GOPS为单位跑的是极轻量级的模型比如关键词唤醒、简单的人体感应分类。1.2 为什么模型要往端侧搬你可能会有个疑问现在云服务器这么便宜5G网络这么快模型放云端推理不香吗为什么非要在端侧这个“小身板”上折腾这个问题我当年也想不明白直到做了几个实际项目才体会到端侧部署不是赶时髦是业务需求逼出来的。第一个理由是延迟。端侧推理的延迟是可以稳定控制的。摄像头抓一帧图像本地推理只要几十毫秒如果上传云端网络抖动一下可能就是几百毫秒到几秒。对于一些实时性要求高的场景——比如工业质检的在线判定、自动驾驶的目标检测——这个延迟差距是致命的。第二个理由是隐私或者叫数据不出域。医疗影像、人脸信息、企业内部的生产数据这些数据一旦上传到云端就要面对合规问题和数据泄露风险。在端侧完成推理只把结论传出去敏感数据始终留在本地设备里这在很多行业是硬性需求。第三个理由是带宽成本。一台边缘设备每天24小时不间断采集数据如果全部传给云端处理流量费和存储成本相当可观。我做过一个视频分析项目单路1080P视频一天的数据量大概在20GB左右十路摄像头就是200GB一个月就是6TB。这个量级的数据传到云端再传回来成本完全不可控。而在端侧直接把视频流消化掉只上报告警事件流量可以压缩到原来的万分之一。第四个理由是可靠性。工厂车间、野外基站、矿井巷道这些地方的网络环境真的不能指望。一旦断网云端推理链路就全断了而端侧推理是本地闭环网络断了照样能干活。所以现在的主流架构基本都变成了“云训练端侧推理”的两段式。云端从事实时训练和复杂模型的迭代端侧负责把成熟模型高效地部署落地。这也直接带火了一个概念——端侧算力。2. 算力数字背后的门道提到端侧平台绕不开的一个词就是算力。芯片厂商在发布会上都喜欢堆算力数字50 TOPS、100 TOPS听起来一个比一个猛。但你要是真把这些数字当成性能的唯一依据去选型大概率会踩坑。2.1 TOPS、FLOPS、GOPS都是什么先把这个最基础的概念捋清楚。TOPS的全称是Tera Operations Per Second每秒万亿次操作。注意这里的“次操作”通常指的是整数操作而且在AI推理的场景里基本默认是INT8精度下的乘累加运算。FLOPS的全称是Floating Point Operations Per Second每秒浮点运算次数。这个指标更多用在云端训练场景比如我们常说的A100的FP16算力是312 TFLOPS。端侧平台很少标FLOPS因为端侧推理主力精度就是INT8用浮点算力衡量意义不大。GOPS就是Giga Operations Per Second每秒十亿次操作。MCU级别的芯片比如某些语音唤醒芯片算力就是几GOPS到几十GOPS的水平。顺便说一句这些单位之间的换算关系是1 TOPS 1000 GOPS 1000000 MOPS。厂商最喜欢用TOPS来宣传因为数字大看着有冲击力但实际部署时你真正关心的不是峰值算力而是这个算力你能用出来多少。2.2 5090 FP8算力指标引发的思考最近圈子里关于5090的FP8算力指标讨论得很热闹为什么5090要用FP8而不是FP16来标注算力这里涉及一个重要的行业趋势——低精度推理正在成为主流。FP8是一种8位浮点格式相比FP1616位浮点和FP3232位浮点它的数据位宽更窄同样的硬件电路单位时间内能做更多的运算同时内存带宽的占用也更低。旗舰显卡的FP8算力往往能比FP16翻倍所以厂商喜欢拿这个数来宣传。但这里有个容易被忽略的点FP8精度对模型量化要求更高不是所有模型都能直接切成FP8跑。而且端侧平台的NPU很多根本不支持FP8主力精度是INT8甚至还有INT4、INT2这种极端量化精度。所以我看到5090 FP8指标的第一反应不是“这卡真猛”而是“如果端侧平台也能跟上这个精度生态那就好了”。对于做端侧部署的人你需要建立的概念是算力数值和精度是强绑定的。同一块芯片FP16算力、INT8算力、INT4算力是完全不同的数字而且通常INT8算力是FP16算力的两倍左右INT4又是在INT8基础上翻倍。厂商宣传时为了方便往往直接挑最大的数字写你要学会自己换算把算力放到同一个精度基准下去对比。2.3 算力利用率才是真正的大考讲个我自己的真实案例。之前在一个瑞芯微RK3588平台上部署一个YOLOv5s目标检测模型芯片标称NPU算力6 TOPS。我当时天真地以为这个模型的浮点运算量大概是8 GFLOPs6 TOPS跑它还不是轻松拿捏帧率怎么也得三位数起步。真跑起来才发现实际推理时间大约35毫秒折合帧率不到30 FPS。跟理论上限差了十万八千里。问题出在哪主要是几个瓶颈。内存带宽是个大问题。NPU算得再快数据要从内存里搬进搬出。如果内存带宽跟不上算力再高也只能等着。这就好比一个厨师刀工再快配菜员只够一个个往案板上送菜那出菜速度还是被配菜员卡死。RK3588虽然算力标到6 TOPS但它的LPDDR4/4X内存带宽也就十几GB每秒跑大一点的模型带宽很快就被吃满了。算子覆盖率是另一个问题。不是所有算子都能在NPU上跑总有一些算子工具链不支持需要落到CPU上执行。CPU兜底一次整条推理链路的延迟就被拖一截而且NPU和CPU之间的数据交换也有额外开销。我那个模型里就有几个切片和拼接操作没被NPU完全支持一度落到CPU上执行单次推理增加了七八毫秒的延迟。数据搬运的耗时也不容忽视。输入图像的预处理、数据排布格式转换、输出后处理这些环节往往也是在CPU上完成的。整个流水线如果协调不好NPU算得快CPU处理不过来照样形成瓶颈。所以我的心得是选型阶段看的算力是理论峰值真正能落地的算力是芯片厂商的工具链、内存架构、算子库综合决定的。这就是为什么我不建议光看算力选芯片的原因——下一段展开讲。3. 端侧平台选型别只看算力数字选端侧平台这事儿跟买电脑完全不是一个逻辑。买电脑你关注CPU主频和显卡型号基本就够了但选端侧SoC算力只是一个非常粗的筛子真正的决策变量是下面这几个。3.1 工具链成熟度决定了你晚上几点下班工具链这东西没有对比就没有伤害。我最早用某个冷门厂家的芯片SDK文档能用“聊胜于无”来形容很多算子要自己写自定义实现一份模型适配搞了两周还没搞定。后来换到工具链成熟的平台同样的模型半天就能转换完跑起来该支持的算子基本都支持剩下的坑在论坛和文档里都能找到答案。工具链的完整度主要看这么几个维度的成熟度。模型转换工具是否好用这是第一关。你的模型拿过来之后能不能方便地转换成目标平台支持的格式转换过程中报错信息是否清晰遇到不支持的算子有没有明确的提示和替代方案量化工具是否靠谱直接影响精度。端侧推理几乎必做INT8量化。工具链提供的量化工具好不好用校准过程是否自动化量化后精度损失能不能控制在合理范围内这些直接决定了模型能不能上线需要多少人工介入。调试和性能分析工具是否完善。代码跑出问题来有没有定位的工具性能不达标能不能看到每个算子耗时定位瓶颈到底是在NPU还是CPU还是内存搬运一个没有profiler的平台基本等于让一个近视眼不戴眼镜走夜路。开发文档的质量和社区活跃度也值得认真考察。出问题搜不到解决方案文档里全是残缺的示例这种平台的坑只有踩的人自己知道有多痛。我现在选平台有个习惯先上网搜这个平台的踩坑帖如果一个平台搜出来的大多是说“文档太差、技术支持不行”那我基本就放弃了。3.2 不同平台的特性和适用场景对比我把目前国内端侧用得比较多的几个平台做了一张对比表方便你按场景筛选。平台系列典型芯片算力范围INT8核心优势典型场景高通骁龙骁龙8 Gen系列30~70 TOPS生态成熟图像处理强手机端首选手机AI应用、AR/VR联发科天玑天玑9000系列30~50 TOPS性价比高功耗控制好手机AI应用NVIDIA JetsonOrin NX、AGX Orin100~275 TOPS算力强劲CUDA生态兼容性好部署工具链完善机器人、自动驾驶、边缘服务器瑞芯微RK3588、RK35766 TOPS性价比极高国产化文档较全智能安防、工业视觉、商显互动地平线征程5、征程6128~560 TOPS自动驾驶专用车规级工具链自研自动驾驶、智能座舱海思昇腾系列视具体型号而定国产化程度高算力覆盖广安防、边缘计算、行业AI拿这几个平台做个简单分析。高通骁龙在手机端几乎就是默认选项。它的NPU性能这几年提升幅度很大最新的旗舰芯片跑大模型都开始支持了。加上高通在图像处理、Hexagon DSP这些异构计算单元上的积累做手机端AI应用生态壁垒相当高。缺点是文档和工具链有不少是要签NDA才能拿全的个人开发者能接触到的资源相对有限。NVIDIA Jetson系列是AI开发者的老朋友了。它的核心优势在于和PC端训练环境的一致性——你在工作站上用PyTorch、TensorRT调通的代码迁移到Jetson上几乎是无痛的。TensorRT的算子优化做得很到位性能释放也激进。缺点是价格不便宜而且功耗相对偏高真要做电池供电的便携设备会比较吃力。我做机械臂视觉抓取项目时用过Jetson Orin NX体验确实顺滑但一想到它的功耗就觉得还是更适合“插着电干活”的移动机器人这类场景。瑞芯微RK3588是国产平台的性价比之选8核CPU加上6 TOPS NPU整颗芯片几百块钱就能拿下。虽然单颗芯片的绝对性能不算强但架不住便宜量大而且对INT8模型的支持做得挺好。我做过一个流水线质检项目就是RK3588加的工业相机方案推理速度完全够用成本还不到Jetson方案的六分之一。它的短板是峰值算力有限大模型或者高分辨率输入就有些吃力了。地平线征程系列原本是冲着自动驾驶去的不过现在在机器人、边缘计算领域也开始有应用。征程5的算力超过120 TOPS征程6更是翻了四倍多。它的工具链是自研的对Transformer模型的支持在国产平台里算是做得不错的。如果你要跑BEV、多模态这种大模型征程系列值得关注。3.3 选型决策的四步法我在实际项目里总结了一套选型决策的方法不算什么高深理论就是一套流程化的验证思路。第一步先框算算力需求。拿你要部署的模型跑一遍浮点运算量统计比如用ptflops这类工具得到模型单次推理的运算量。然后乘上期望的帧率再加上20%到30%的冗余量就得到你需要的最低算力。公式是实际需求算力 模型运算量FLOPs× 目标帧率FPS× 1.3。注意这里要确保模型运算量和芯片算力的精度基准一致——一般统一按INT8来算。第二步筛选平台。根据算力需求、功耗限制、成本预算、行业合规要求比如是否要求国产芯片把可选平台缩小到两到三个。第三步是拿真实模型做适配性验证。模型转换、量化、在目标板上跑通这一步建议在正式选型前就必须完成不要只看文档参数。我去年的一个项目候选芯片A的理论算力比候选芯片B高了将近一倍但实际跑模型时A的框架对某个算子支持极差推理速度反而不如B差点就踩坑里。第四步是验证量产稳定性。批量采购不是看单颗芯片参数还要看供货周期、批量价格梯度、长期维护支持。有些小厂芯片单看参数很香但供应链说断就断项目做一半换芯片的滋味谁换谁知道。4. 模型落地端侧的关键实操平台选定之后真正的工作才刚开始。这一节我把自己从模型训练完到端侧跑通的全流程拆开来讲重点说几个核心环节的实操要点。4.1 模型量化的两种路线选择端侧平台的NPU基本都是定点计算INT8是主流精度。所以你训练完的FP32模型不能直接拿去端侧跑必须先做量化。量化就是把连续的浮点数值映射到有限的定点整数上。这个映射过程一定会带来信息损失关键是让损失可控。业内做量化分成两种路线。第一种是训练后量化PTQPost-Training Quantization。原理很简单拿一批校准数据统计模型每一层的激活值分布然后计算出缩放因子把浮点权重和激活映射到INT8。这种方法不需要重新训练模型步骤少速度快特别适合模型已经训练好、不方便重新动的情况。第二种是量化感知训练QATQuantization-Aware Training。做法是在训练阶段就把量化的效果模拟进去让模型在训练过程中适应低精度带来的噪声。这种方法精度通常比PTQ好但需要重新训练模型成本高、周期长。实操中我的建议是先试PTQ。如果PTQ量化后精度损失在可接受范围内比如mAP下降不超过两个点那就没必要上QAT。只有当PTQ效果确实不行再考虑用QAT微调。多数常规视觉模型在做好校准数据采样的情况下PTQ都能满足要求。校准数据的选取是PTQ里最关键的环节也是很多人容易忽视的地方。校准数据集必须足够代表真实推理时模型会遇到的输入分布。比如你部署的是工业质检模型校准数据就该从产线实际采集的图像里抽而不是拿训练集随便凑。我之前遇到过量化后模型在测试集上mAP降了5个点怎么调都调不回来最后发现是校准数据里全是正常样本缺少缺陷样本导致模型对异常特征的响应被量化过程抹平了。换了校准数据之后精度损失直接降到1个点以内。4.2 从ONNX到端侧格式的转换链路不管用什么框架训练模型到端侧部署时基本都要先转成ONNXOpen Neural Network Exchange一种跨框架的中间表示格式再从ONNX转成目标平台的专用格式。比如瑞芯微用的是RKNN格式地平线用的是通过OMOpen Model格式体系NVIDIA则是TensorRT的engine格式。转换链路里最常见的坑是算子兼容。训练框架里很常见的操作到了ONNX标准里可能没有一一对应的算子或者目标平台的推理引擎又不支持这个ONNX算子。解决办法往往需要在模型结构上做调整比如把一些自定义层改写成标准层组合。我举一个实际例子。之前做目标检测模型部署模型里用了一个自定义的NMS非极大值抑制实现。转ONNX没问题但转RKNN时发现NPU不支持只能把NMS从模型里拆出来放到CPU上跑后处理。这个改动本身不复杂但有一个细节容易踩坑拆出来的NMS输入是模型输出的原始预测框数据量很大在NPU和CPU之间来回搬运数据要额外消耗时间。后来我优化了一下在模型输出端提前做一次粗过滤只把置信度高的框传给CPU做NMS数据量一下少了一个数量级整体推理速度提上来不少。转换过程中如果遇到不支持的算子先不要硬着头皮改模型结构。先看看能不能用ONNX的算子集版本替换、用等价算子组合替代或者干脆把这些算子放到CPU执行。如果CPU兜底的代价太大再考虑改模型结构。4.3 异构计算单元的协同调度现在的端侧SoC基本都是异构架构——CPU、GPU、NPU、DSP各管一摊。合理利用这些计算单元是压榨端侧性能的重要途径。我在RK3588平台上做过一个视频结构化项目整个流水线是这么拆的图像解码用CPU图像预处理缩放、归一化、颜色空间转换用NPU内置的预处理模块模型推理用NPU后处理目标框过滤、追踪逻辑用CPU。这样分工每个计算单元都在干自己擅长的事整体吞吐量比全丢给NPU要高出不少。异构调度的核心思想是让每一个计算单元都有活干同时尽可能减少单元之间的数据搬运。数据搬运是最耗时间的隐形杀手尤其是在内存带宽不那么充裕的端侧平台上。设计流水线时尽量让数据“原地待着”比如NPU算完的结果直接留在内存里CPU读取时不要做格式转换能省则省。还有一个很容易被忽略的点CPU的大核和小核调度。端侧SoC的CPU通常是大小核架构后处理这种逻辑密集型的任务要绑在大核上跑而数据搬运、IO等待这类的任务放小核上就行。如果系统默认调度把所有任务都丢给大核不仅性能上不去功耗还会飙升设备很快就烫了。4.4 弄懂NPU是怎么干活的用NPU和用GPU的思路不太一样。GPU是“一堆通用计算单元并行干活”什么算子都能跑NPU则更专一主要擅长跑卷积、矩阵乘这类运算。你可以把NPU想象成一个只会做乘法累加的特种车间干这个活效率极高但是你要是让它去做别的它反而不如CPU灵活。这个特性带来两个实操启示。第一你要想尽办法让模型的算子尽量落在NPU擅长的那一类运算上。比如把一些普通的卷积替换成可分离卷积把大卷积核改成小卷积核串联这些操作在NPU上性能表现往往会更好。第二NPU的内存布局是固定的。绝大多数情况下你没法直接在NPU内存上做任意操作数据必须按NPU要求的格式排布好才能喂进去。所以前处理和后处理环节的数据格式转换一定要在设计阶段就想清楚避免运行时反复做无意义的拷贝和转换。5. 部署现场踩过的坑与排查思路模型部署这事真刀真枪干起来一定会遇到问题。我把自己踩过的几个典型坑整理出来并附带排查思路给干同样事情的同行们避个雷。5.1 推理速率上不去的几种常见原因现象目标帧率是30 FPS实际跑出来只有18 FPS性能差了一大截。优先排查这几个地方。第一看这个模型本身对目标平台的支持度。在转换时就要留意模型的算子有没有大量落到CPU兜底。如果是找一遍转换日志把CPU执行的算子标出来逐个确认是否可以修改模型结构规避。第二看内存带宽是否打满。有些模型的中间特征图特别大比如高分辨率输入下特征图的反复读写对内存带宽的消耗非常大。如果确认是带宽瓶颈可以尝试减小输入分辨率前提是精度还能接受或者换一个内存带宽更高的平台。第三看是否多个模型在串行推理。如果一个任务要跑多个模型比如先做目标检测再对每个目标做分类两个模型的推理是串行的整体延迟就是两个模型的延迟之和。这种情况下可以考虑模型融合把两个模型合并成一个多任务模型减少加载和调度开销。我把常见的性能问题和排查思路整理成了表格方便现场排查对照。问题现象可能原因排查方法解决建议推理时间不稳定偶尔卡顿系统任务抢占CPU查看CPU负载确认是否有后台任务将推理进程绑定大核提高进程优先级帧率始终上不去算子落到CPU执行查看转换日志中的算子分配改写模型结构将特殊算子替换为NPU支持算子图像预处理耗时过高用了低效的缩放/归一化方式剖析预处理耗时改用NPU内置预处理模块或优化数据格式内存占用过高导致程序崩溃模型中间结果缓存过多监控内存占用曲线复用内存缓冲区减少中间张量存储5.2 量化后精度损失严重怎么办量化后精度下降是端侧部署里最头疼的问题之一。如果你发现量化后模型精度掉得厉害第一件事是检查校准数据。校准数据的样本量和多样性都要有保证。一般来说校准集最好覆盖到模型会遇到的各类典型场景数量上两三百张到一千张都比较常见。太少的话统计出来的激活值分布不准量化参数自然就偏了。第二件事是检查模型里有没有某些层对量化特别敏感。有些层的权重分布范围特别大强行量化到INT8会严重损失精度。遇到这种层可以尝试在目标平台的工具链里把这些层单独设成FP16或FP32精度执行让它们“逃过”量化。很多平台工具链支持这种混合精度量化配置能有效缓解精度损失。第三件事是关注模型里的归一化层。BatchNorm层在推理阶段可以融合进卷积层这个大部平台会自动处理。但有一些平台融合得不彻底导致量化后性能异常。如果遇到这个问题可以考虑在导出ONNX之前手动把BatchNorm融合到前面的卷积层里。5.3 设备发热降频导致性能跳水端侧设备散热条件普遍一般高性能推理持续跑一段时间后芯片温度上来就会触发降频保护性能直接掉一半还多。我在一个长期运行的边缘设备上遇到过这个问题。第一天测试性能完全达标第二天早上看数据发现晚上推理速度掉得厉害查了一圈才发现是设备放在封闭机柜里长时间运行后温度过高芯片自动降频。解决办法从两个方向入手。一是优化软件降低推理功耗。比如利用NPU的低功耗模式在空闲时让设备进入休眠二是改善硬件散热加散热片、加风扇、优化机箱通风。如果都没法做那就只能降低目标帧率给芯片留出余量让它在长期运行下也不会触发降频。另外很多端侧平台提供了功耗管理接口可以限制芯片的最高功耗。合理配置功耗档位有时候能换来更稳定的性能输出。芯片在高功耗档位下性能高但发热快在低功耗档位下温度稳定但性能下降。找到一个平衡点让设备可以长时间稳定工作在目标帧率附近才是正确的调优思路。5.4 模型更新与版本管理模型部署上线之后不是一劳永逸的。算法迭代很快你可能每个月都要更新模型版本。端侧设备的模型更新比云端要麻烦得多——设备分布在不同地方网络条件也千差万别。我的经验是在方案设计阶段就要把模型热更新机制考虑进去。模型文件单独存放在一个分区和程序本体分开更新时只替换模型文件不回写整个固件。同时做好版本管理在模型文件命名或配置里带上版本号防止设备加载到旧版本的模型。远程更新时一定先在小范围灰度更新一批设备确认稳定后再全面铺开否则出了问题全部设备都要返工。端侧部署这条路真不是把模型文件拷到设备上就能跑的。从平台选型、算力理解、模型量化到工具链适配、性能调优、稳定性保障每一步都有大量细节和坑。我在这个领域折腾了几年摸爬滚打总结出来的经验很大一部分就体现在这篇文章里。我个人在实际操作中的体会是端侧平台和算力的问题千万不要等到模型训练完才开始考虑。项目立项的第一天就应该把“最后的部署平台是什么”这个问题想清楚。平台选对了后面所有工作都顺平台选错了后面每一步都是在还债。这篇先把平台这个维度讲透了后面我会继续写端侧算力的深度调优、量化实战的细节、以及主流工具链的分步使用教程大家有什么实际项目中遇到的具体问题也欢迎一起交流。
