企业官网建设流程全解析

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位浮点格式，相比FP16（16位浮点）和FP32（32位浮点），它的数据位宽更窄，同样的硬件电路，单位时间内能做更多的运算，同时内存带宽的占用也更低。旗舰显卡的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 GFLOPs，6 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 不同平台的特性和适用场景对比

我把目前国内端侧用得比较多的几个平台做了一张对比表，方便你按场景筛选。

拿这几个平台做个简单分析。

高通骁龙在手机端几乎就是默认选项。它的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模型不能直接拿去端侧跑，必须先做量化。

量化就是把连续的浮点数值映射到有限的定点整数上。这个映射过程一定会带来信息损失，关键是让损失可控。业内做量化分成两种路线。

第一种是训练后量化PTQ（Post-Training Quantization）。原理很简单：拿一批校准数据，统计模型每一层的激活值分布，然后计算出缩放因子，把浮点权重和激活映射到INT8。这种方法不需要重新训练模型，步骤少，速度快，特别适合模型已经训练好、不方便重新动的情况。

第二种是量化感知训练QAT（Quantization-Aware Training）。做法是在训练阶段就把量化的效果模拟进去，让模型在训练过程中适应低精度带来的噪声。这种方法精度通常比PTQ好，但需要重新训练模型，成本高、周期长。

实操中我的建议是：先试PTQ。如果PTQ量化后精度损失在可接受范围内（比如mAP下降不超过两个点），那就没必要上QAT。只有当PTQ效果确实不行，再考虑用QAT微调。多数常规视觉模型，在做好校准数据采样的情况下，PTQ都能满足要求。

校准数据的选取是PTQ里最关键的环节，也是很多人容易忽视的地方。校准数据集必须足够代表真实推理时模型会遇到的输入分布。比如你部署的是工业质检模型，校准数据就该从产线实际采集的图像里抽，而不是拿训练集随便凑。我之前遇到过量化后模型在测试集上mAP降了5个点，怎么调都调不回来，最后发现是校准数据里全是正常样本，缺少缺陷样本，导致模型对异常特征的响应被量化过程抹平了。换了校准数据之后，精度损失直接降到1个点以内。

4.2 从ONNX到端侧格式的转换链路

不管用什么框架训练模型，到端侧部署时基本都要先转成ONNX（Open Neural Network Exchange，一种跨框架的中间表示格式），再从ONNX转成目标平台的专用格式。比如瑞芯微用的是RKNN格式，地平线用的是通过OM（Open 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执行的算子标出来，逐个确认是否可以修改模型结构规避。

第二看内存带宽是否打满。有些模型的中间特征图特别大，比如高分辨率输入下，特征图的反复读写对内存带宽的消耗非常大。如果确认是带宽瓶颈，可以尝试减小输入分辨率（前提是精度还能接受），或者换一个内存带宽更高的平台。

第三看是否多个模型在串行推理。如果一个任务要跑多个模型，比如先做目标检测，再对每个目标做分类，两个模型的推理是串行的，整体延迟就是两个模型的延迟之和。这种情况下可以考虑模型融合，把两个模型合并成一个多任务模型，减少加载和调度开销。

我把常见的性能问题和排查思路整理成了表格，方便现场排查对照。

5.2 量化后精度损失严重怎么办

量化后精度下降是端侧部署里最头疼的问题之一。

如果你发现量化后模型精度掉得厉害，第一件事是检查校准数据。校准数据的样本量和多样性都要有保证。一般来说，校准集最好覆盖到模型会遇到的各类典型场景，数量上两三百张到一千张都比较常见。太少的话统计出来的激活值分布不准，量化参数自然就偏了。

第二件事是检查模型里有没有某些层对量化特别敏感。有些层的权重分布范围特别大，强行量化到INT8会严重损失精度。遇到这种层，可以尝试在目标平台的工具链里把这些层单独设成FP16或FP32精度执行，让它们“逃过”量化。很多平台工具链支持这种混合精度量化配置，能有效缓解精度损失。

第三件事是关注模型里的归一化层。BatchNorm层在推理阶段可以融合进卷积层，这个大部平台会自动处理。但有一些平台融合得不彻底，导致量化后性能异常。如果遇到这个问题，可以考虑在导出ONNX之前，手动把BatchNorm融合到前面的卷积层里。

5.3 设备发热降频导致性能跳水

端侧设备散热条件普遍一般，高性能推理持续跑一段时间后，芯片温度上来就会触发降频保护，性能直接掉一半还多。

我在一个长期运行的边缘设备上遇到过这个问题。第一天测试性能完全达标，第二天早上看数据发现晚上推理速度掉得厉害，查了一圈才发现是设备放在封闭机柜里，长时间运行后温度过高，芯片自动降频。

解决办法从两个方向入手。一是优化软件，降低推理功耗。比如利用NPU的低功耗模式，在空闲时让设备进入休眠；二是改善硬件散热，加散热片、加风扇、优化机箱通风。如果都没法做，那就只能降低目标帧率，给芯片留出余量，让它在长期运行下也不会触发降频。

另外，很多端侧平台提供了功耗管理接口，可以限制芯片的最高功耗。合理配置功耗档位，有时候能换来更稳定的性能输出。芯片在高功耗档位下性能高但发热快，在低功耗档位下温度稳定但性能下降。找到一个平衡点，让设备可以长时间稳定工作在目标帧率附近，才是正确的调优思路。

5.4 模型更新与版本管理

模型部署上线之后不是一劳永逸的。算法迭代很快，你可能每个月都要更新模型版本。端侧设备的模型更新，比云端要麻烦得多——设备分布在不同地方，网络条件也千差万别。

我的经验是，在方案设计阶段就要把模型热更新机制考虑进去。模型文件单独存放在一个分区，和程序本体分开，更新时只替换模型文件，不回写整个固件。同时做好版本管理，在模型文件命名或配置里带上版本号，防止设备加载到旧版本的模型。远程更新时，一定先在小范围灰度更新一批设备，确认稳定后再全面铺开，否则出了问题全部设备都要返工。

端侧部署这条路，真不是把模型文件拷到设备上就能跑的。从平台选型、算力理解、模型量化，到工具链适配、性能调优、稳定性保障，每一步都有大量细节和坑。我在这个领域折腾了几年，摸爬滚打总结出来的经验，很大一部分就体现在这篇文章里。

我个人在实际操作中的体会是：端侧平台和算力的问题，千万不要等到模型训练完才开始考虑。项目立项的第一天，就应该把“最后的部署平台是什么”这个问题想清楚。平台选对了，后面所有工作都顺；平台选错了，后面每一步都是在还债。

这篇先把平台这个维度讲透了，后面我会继续写端侧算力的深度调优、量化实战的细节、以及主流工具链的分步使用教程，大家有什么实际项目中遇到的具体问题，也欢迎一起交流。