企业官网建设流程全解析

前阵子帮一家做智能分拣设备的朋友做方案评审，聊到核心矛盾点的时候，对方直接甩了一句话给我：“同样的功能，到底是让板子上的NPU跑YOLO，还是直接把图片送到云端调Flash推理接口？算了两个月都没算明白。”这句话特别典型。做国产AI视觉SoC的开发者，手里拿的是RK3588、算能、地平线、爱芯这类平台，芯片本身有NPU，能跑YOLO系检测模型；但需求清单里又经常混着“识别出这是什么故障”“判断这个行为是否违规”这种需要语义理解的活儿，本地小模型搞不定，只能往云端送。于是两拨开发者的日常就变成了：端侧派说不联网、实时性好，云端派说精度高、迭代快，两边吵了三个月，项目还在POC阶段。这篇我就把这个两难问题彻底拆开——先对齐概念，再给一张可以直接抄的决策表，然后分别讲清楚端侧YOLO和云端Flash各自的落地要点和隐性成本，最后用一次真实项目复盘说明为什么绝大多数产品最后都会走向混合式架构。

1. 两难的本质：端侧YOLO和云端Flash根本不是在解决同一个问题

1.1 先对齐概念：端侧跑YOLO到底指的是什么

在国产AI视觉SoC的语境里，“端侧跑YOLO”不是一个笼统的说法，它有明确的物理含义：把YOLOv5s、YOLOv8n这类目标检测模型，通过瑞芯微RKNN-Toolkit2、算能TPU-MLIR、地平线OpenExplorer、爱芯工具链这类转换工具，量化和编译成NPU可执行的格式，然后在设备本地完成每一帧图像的推理。整个过程不依赖外网，时延可以压到几十毫秒甚至几毫秒，帧率做到25FPS、30FPS都是常规操作。

我见过不少第一次接触端侧部署的开发者，以为“端侧跑YOLO”就是把训练好的PyTorch权重拷到板子上，用Python跑一下就行。实际流程完全是另一回事：模型训练完导出ONNX，中间要处理各种算子兼容问题；然后做INT8量化，精度掉一两个点正常，掉太多就得准备校准数据集重来；量化后的模型经过NPU编译器映射到底层指令，这步又可能碰到算子和内存对齐的报错。等模型能跑起来，还要处理前后处理放CPU还是NPU的问题。这一整套下来，两三个星期属于正常节奏。

但端侧YOLO的价值也正在于此：数据完全在本地闭环，没有传输延迟，没有网络抖动，没有按调用次数计费的恐慌。对实时检测、工业质检、安防监控这类场景，这就是刚需。它的核心定位是“在资源受限的设备上，以最低成本完成结构化信息的提取”——提取出来的是坐标框、类别、置信度，理解语义这件事不是它的强项。

1.2 云端调Flash又是什么

“云端调Flash”这个说法在标题里容易让人疑惑，其实在2025年的技术语境下，它通常指两类东西：一是像千问3.8 Flash这样定位为低延迟、高吞吐的快速推理模型档位，二是基于FlashAttention v2这类高效注意力实现托底的大模型服务。无论哪种，从开发者视角来看，它都意味着同一件事：把图像或视频帧通过网络发送到云端GPU推理服务，通过HTTP/gRPC接口拿到结果，而结果往往不是坐标框，而是语义描述——缺陷类型、行为判断、对话回复、结构化文本。

Flash档位的核心优势是速度。相比满血大模型，Flash版在参数量和注意力计算上做了精简和优化，单次推理时延可以控制在几百毫秒到一两秒，而且云端并发能力高，吞吐量能扛住业务高峰。关键是，这种档位通常有成本优势，API按调用次数计费时单价更低，所以很多实时性要求不苛刻的场景都会选用。

但它有一个天然的结构性代价：数据要离开设备。只要走公网，就存在延迟波动、带宽消耗、数据传输安全、断网不可用这四座大山。我见过不少团队在做技术验证时觉得云端效果惊艳，一上现场就翻车——老产线车间里网络信号不稳定，实时性要求又是毫秒级，云端再快也救不回来。所以云端Flash的定位恰恰和端侧YOLO互补：“在算力无限、上下文丰富的环境里，把检测和推理问题升级为理解和判断问题”。

1.3 开发者为什么在它们之间反复摇摆

真正的纠结在于：现实中绝大多数AI视觉产品并不是“纯检测”或“纯理解”的单极需求，而是组合需求。

举个例子，一个视觉分拣系统，最核心的任务确实是“定位物料位置、分类物料种类”，这部分端侧YOLO可以完美覆盖。但客户随后问了一句：“那我这个物料表面是划伤还是脏污？如果是划伤，大概是什么方向造成的？”这就涉及细粒度分类和语义描述，端侧模型很难做。再比如智慧养殖项目，端侧YOLO能检测出“有一只猪在某个位置”，但判断“这只猪现在的行为是不是打架”，仅靠目标框完全不够。于是出现了两条路线：一条是在端侧堆更强模型、收集更多标注数据硬扛；另一条是直接把画面关键帧传云端，让Flash模型理解。

前者的坑在于边际成本陡增——端侧新场景的标注和训练迭代周期长，往往一个新缺陷就要两三个月；后者的坑在于网络依赖和费用黑洞——流量费加推理费，一台设备一年下来可能比板子本身还贵。两边的优势恰好是对方的劣势，这在架构选型时就让人非常难受。

2. 一张表定生死：7个维度打完分，选型自己会冒出来

我一直觉得架构选型不应该靠争论解决，应该靠打分解决。帮朋友做评审的时候，我用了一套七个维度的评分方式，每个维度5分制，倾向端侧给高分，倾向云端给高分，最后总分说话。下面这张表我用过很多次，直接放出来给大家抄作业。

2.1 评分规则和阈值

每一行先根据项目实际情况打分，然后横向求和。注意打分时不要打“中间分”打得太随意——我的建议是只有确实两边都可以时才给3分，否则必须逼自己选边站。求和之后看结果：端侧总分30分以上，说明你的场景本质上是实时密集型，优先走端侧路线；云端总分30分以上，说明系统核心价值在语义理解，可以大胆依赖云端；两边都在25分上下，那就别犹豫，直接按照我后面第五节讲的混合式来设计。

2.2 两个容易被低估的维度

有些维度在实际评估中经常被拍脑袋略过，但恰恰是它们决定了方案后期能不能活下去。一个是“全周期成本”，一个是“团队能力”。

全周期成本这块，我拿一个16路视频分析网关来算。端侧方案硬件增加的成本分摊到网关单价里大概几百到一千多块钱，但换来的是未来三年不用为推理付费；云端方案硬件几乎不加成本，但16路摄像头如果每3秒推一帧做一次分析，每天24小时跑，一个月下来推理请求量是46万次左右，哪怕单次API调用只要0.002元，一年也接近1.1万元，三年就是3.3万。这还不算流量费用和失败的补偿回传。你说哪种贵？

“团队能力”更致命。有的团队嵌入式经验很足，但大模型应用开发几乎是空白；有的团队天天调Prompt和RAG，却搞不定RKNN量化掉点。关键是要诚实地评估自己团队的能力面板，然后选择一条阻力最小的路线。强扭的瓜不甜，工程上尤其如此。如果你所在团队连模型debuge的完整链路都没走过，直接上端侧YOLO大概率会在算子适配和精度调优阶段损耗大量时间；反过来，如果团队没写过服务端接口，云端方案也会因为各种工程质量问题而长期不稳定。

2.3 典型打分结果长什么样

我拿几个常见项目套这个表，方便大家理解不同项目的走向。

工业固定工位质检仪：实时性必须端侧5分，运行环境是产线有线内网可接受但客户不想被网络限制给4分，数据敏感（产品图纸不能出厂房）给5分，帧率要求高（每件过检都要抓拍分析）给5分，模型复杂度主要是粗分类给3分，团队是纯嵌入式给4分，全周期成本端侧一次买断更符合甲方预算给4分——端侧合计30分，云端只拿到5分，这个项目就没必要在云端上纠结。

智慧园区轮询巡检机器人：时延可以接受300ms以上给云端4分，运行环境园区Wi-Fi覆盖尚可但不能保证全线稳定给3分，数据敏感性中等（园区公共区域画面可脱敏上云）给3分，帧率低频（十几秒一帧）给云端4分，模型复杂度涉及“是否违规停车”“是否占道经营”这类语义判断给云端5分，团队服务端能力偏强给云端4分，成本上云端按次调用量不大可控给云端4分——这是典型的云端主导型项目。

上面两种评分结果都很清晰。难的是那种时延要求高、环境网络差、又有强语义理解需求的项目——比如手持巡检仪，要实时框定设备区域，又要把表盘读数、异常状态用自然语言描述出来。这种项目端侧得分和云端得分往往各占一半，直接选任何一边都会别扭，这就是必须上混合式架构的典型信号。

3. 端侧YOLO的硬仗：模型搬上国产NPU之前，先想好这几件事

如果你的决策表最终指向端侧，那么恭喜你，你避开了流量账但走进了另一条技术窄路。国产NPU工具链这几年进步明显，但距离“导出ONNX就能一条龙跑起来”还有不少距离。下面是你在正式动手前最需要提前想清楚的四件事。

3.1 选YOLO版本和压缩策略，先跟算力对齐

端侧部署第一步不是下载代码，而是看你的NPU算力在什么量级。以常见的国产视觉SoC大致分类：1TOPS到3TOPS这个区间，老老实实用YOLOv5s或YOLOv8n，分辨率尽量控制在640×640以内；6TOPS左右，比如瑞芯微RK3576、晶晨A311D2这个级别，YOLOv8s可以跑但比较吃力，建议YOLOv8n加上大分辨率抠图；6TOPS以上到几十TOPS，像RK3588、算能BM1684X、地平线旭日X5这些，才有余量跑YOLOv8m甚至YOLOv10这类新结构。

版本选择上也别追新。YOLOv8n之所以稳，是因为它结构规整，SiLU激活和C2f模块在主流NPU上都有比较好的支持，量化表现也比较可控。YOLOv6和YOLOv8的部署表现也还行，但每次换版本都意味着导出的ONNX结构不同，某些算子需要重新做适配。我的建议是：先选定一个核心YOLO版本把端到端链路打通，再根据实测帧率决定要不要升级模型或者精简通道；而不是一开始就上大模型然后到处砍算子。

3.2 ONNX到NPU的算子战争：SiLU不是不行，但坑是真的多

国产NPU工具链普遍要求先把PyTorch模型导出为ONNX，再转成平台私有格式。这个过程中最耗时间的就是算子兼容性适配。YOLO系模型最常见的几个坑排序如下：SiLU/Swish激活函数在旧版本工具链上不支持，需要在导出时替换成ReLU或自定义激活实现；大stride卷积和某些上采样方式可能触发编译器不支持的分支报错；Deformable Conv——现在很多高精度检测模型喜欢用它，但大多数端侧NPU对它的支持极差，遇到基本只能改结构或者换模型；还有动态尺寸问题，NPU通常希望输入是固定H和W，动态shape导出基本都会卡住。

处理算子问题有一个通用套路：先完整跑一遍转换流程，把所有报错算子记录下来，逐个判断是改模型结构还是改ONNX计算图。改模型结构是优先级最高的选择——比如把SiLU换成ReLU6，精度影响通常在一个点以内，但兼容性提升巨大。改计算图则需要懂一点点ONNX底层知识，用onnxruntime做子图替换或者插入自定义节点，操作难度高一些但能保住原模型结构。整体原则：优先选择算子代换而不是让工具链团队去适配你的自定义算子，后者的时间成本通常高到项目无法承受。

3.3 量化不是玄学：PTQ和QAT谁更适合你

INT8量化几乎是端侧部署的必经之路，FP16虽然在部分NPU上支持，但实际速度优势和内存优势都不明显。量化最怕的是精度掉点失控，很多团队遇到掉点第一反应是换数据集重新校准，实际上更系统化的排查思路是：先区分是PTQ校准集分布不好，还是模型本身对量化敏感。

PTQ（训练后量化）是多数人第一次接触的量化方式，只需要准备几百张代表性图片做校准，操作简单，但碰上小目标或者分布稀疏的检测任务，精度掉点容易超过5个点。这时候很多人不知道可以针对敏感层做混合精度量化——只把最敏感的少数层保持FP16或INT16，其余层INT8，精度就能拉回来大半。这是最省时间的路。

如果PTQ无论如何都救不回来，再考虑QAT（量化感知训练）。QAT需要在训练阶段模拟量化误差，让模型权重和激活的分布主动去适应量化噪声，效果确实比PTQ稳定，但训练流程改动大、需要额外标定和微调周期，基本要投入一到两周的GPU时间和人力。我的实操经验是：先花两三天做PTQ和混合精度尝试，效果不行再进QAT，不要一上来就上QAT，也不要一掉点就放弃。

3.4 别忽略后处理：Decode和NMS是帧率杀手

很多团队把模型推理优化得飞快，最后帧率还是上不去，一查瓶颈在CPU上的后处理——YOLO输出的特征图要解码成框坐标，再做NMS去重，这几段在Python里跑200毫秒都正常。NPU负责的只是“推理”，前后处理如果全放CPU，帧率会被拉下一大截。

主流优化方案是把后处理阶段中的Decode操作尽可能固化进NPU编译图，也就是用工具链提供的自定义算子把decode做进模型内部；NMS则按需选择，要么用NPU厂商提供的NMS实现，要么接受精度损失做简化版去重。实在改不动的，后处理代码也要从Python改成C/C++实现，用NEON或者平台的SIMD指令做加速。别小看这步，我见过把后处理改成C++后整体帧率直接翻倍的项目。

这里顺便提一句和文件系统相关的坑：模型文件本身该放NOR Flash还是NAND Flash？小体积模型直接放NOR，启动加载快，掉电不丢；超过几十MB的模型放NAND，但要注意读取速度差异和坏块管理。很多开发者在烧录模型时踩到“flash download failed - target dll has been cancelled”这类报错，大概率是烧录工具和调试器驱动冲突，跟方案选型没关系。这类问题一般先关掉所有占用调试口的软件再重试即可，不用在架构层面纠结。

3.5 一张实测对照：RK3588形态的板卡端到端性能

用RK3588（6TOPS左右NPU）跑YOLOv8n，640×640输入，INT8量化后由RKNN工具链转换，单路视频流实测结果大致是：NPU推理时间18到25毫秒，CPU前后处理优化后8到12毫秒，整个pipeline大约30到35毫秒，折算下来28到33FPS。如果跑两个模型或者接入四路摄像头，就要开始考虑模型分时调度和NPU内存分配问题了。这类数据各大NPU平台其实都有参考值，但实际性能受DDR带宽、图像解码单元、系统负载影响很大，上板之前不要轻信官方标称值，最好拿自己的模型和数据跑个Benchmark再下单。

4. 云端Flash不是“把图片传上去就行”：工程上的五个隐形账

如果决策表指向云端，也不能觉得万事大吉。云端方案看起来容易，实际工程化过程中的隐形账不少。这里不讲模型怎么训练，只讲从设备端到服务端之间那一段容易翻车的地带。

4.1 选对模型档位：为什么Flash档适合视觉设备接入

云端推理领域，并不是每次都要调用满血大模型。Flash档位的意义在于把单次推理时延压缩到几百毫秒级别，同时保证不错的语义理解能力。对图片理解场景，Flash档的视觉编码能力已经能胜任“描述画面内容”“判断属性”“提取结构化信息”等大多数任务，成本却只有大模型的几分之一甚至更低。

选择档位时不要只看价格，还要看可用并发和限流策略。有的云厂商虽然单价低，但给设备端分配并发额度很抠，设备一多就跑不满。我的建议是签服务前先做压测：模拟全部存量设备同时上报一个峰值请求，看Flash接口的P95时延是否还能满足需求，这比单纯比较单价更接近真实体验。

4.2 网络协议与帧压缩：别让流量费吃掉全部预算

把一帧1920×1080的JPEG图片送上云端，按质量参数85压缩，大小通常在200KB到500KB不等。一个每天上传1万帧的终端，光上行流量一个月就是60GB到150GB。有些团队没细算流量成本，等月底看到账单直接傻眼。

工程上最常见的优化是“降采样再压缩”：检测分析任务根本不需要完整的1080P画面，把图片从云端调用之前先压缩到1280×720甚至640×360，JPEG质量压到70，人眼看起来糊但对大模型理解影响不大，流量成本直接砍掉70%以上。另外一个关键是选对传输协议，gRPC配合HTTP/2多路复用比分几次HTTP/1.1请求高效得多，同样一批图片合在一个请求里提交还能进一步降低握手开销。

4.3 云端快不等于真实时延低

很多人在云端跑单次请求，发现只要400毫秒就返回结果了，于是推断实时性完全没问题。这是最大的认知误区——单次请求的时延是一个在理想网络环境下的数字，而真实产品的时延等于“设备端采集+压缩+上传排队+网络传输+云端排队+模型推理+结果回传+设备端响应”的全链路总和。这其中，上传排队和云端排队往往是两个隐形大头。

16路摄像头并发上传时，设备端网络往往是百兆甚至更低，4G/5G环境的上行带宽还会波动。高峰期云端接口如果没预留充足的并发容量，请求排队导致的等待时间可能比模型推理时间还长。所以做云端方案时，第一个要定下的参数不是模型，而是“端到端P95时延目标”，然后倒推每一段允许的耗时上限。

4.4 断网和抖动必须有降级策略

任何依赖云端的视觉设备都要有降级策略，这不是可选项而是必选项。最简单的降级策略是本地缓存加延迟重传——断网时把特征帧存在设备本地，网络恢复后按时间戳补传，让云端分析不缺失关键事件。更聪明一点的降级是“关键帧本地备用模型兜底”：在设备端保留一个很小的YOLO模型只检测重大异常，一旦断网超过阈值就切换本地模型保证最核心的报警功能不失效。

我见过一个反例：某项目纯云端方案，现场断网五分钟，恰好那五分钟发生了需要告警的事件，结果整个事件漏报，客户差点把整个系统推翻重来。从那以后我的经验是：凡是上云方案，产品需求里必须强制写一条“弱网和断网状态下的最小可用能力”，不落实这条不能进量产。

4.5 限流、鉴权和费用失控：容易被忽略的三个运营问题

设备量上去以后，运营侧的问题浮出水面。限流策略没做好，某个设备固件bug导致疯狂刷新token，直接触发云端账号封禁；鉴权设计没做好，泄露的API key被人盗刷；费用预估没做好，月中就发现预算跑完。这些和模型精度没半点关系，但翻车概率远高于模型翻车。

我的建议是：云端API接入必须走独立的设备鉴权体系，每台设备一个动态凭证，禁用一个万能key；费用侧设置预算告警阈值，达到80%就触发企业微信或短信通知；同时在设备端做出力控制，对同一画面不重复调用，带上时间戳和场景指纹做去重。这些都是花半天时间能搞定的小工程，能省下大量后期运维的麻烦。

5. 混合式架构：本地YOLO做减法，云端Flash做加法

前面铺垫了这么多，其实到了核心答案区——大多数最终落地的方案，都不是纯端侧也不是纯云端，而是“本地YOLO筛一遍、云端Flash精分析”的混合式。原因不复杂：检测任务是确定性的、高频的、对时延敏感的，适合在端侧解决；理解任务是模糊的、低频的、对上下文要求高的，适合交给云端。

5.1 混合式为什么是工业级方案的终态

以安防摄像头为例。传统方案是把所有视频帧全量上云，让云端模型持续分析，这种做法的带宽和算力消耗极大。混合式的做法是端侧先不间断跑YOLO，检测到画面中出现了人、车或者某个目标区域的框和置信度超过阈值，才截取关键帧上传到云端，让Flash模型判断“发生了什么”。这样做，云端调用量下降了90%以上，流量费用随之大幅降低；而端侧YOLO负责的实时性和稳定性完全不受网络影响，只在关键事件产生的瞬间依赖一下网络。

混合式的另一个优势是模型迭代解耦。端侧YOLO识别错了目标类别没关系，云端的Flash可以纠正；云端Flash理解错了也没关系，因为端侧YOLO已经把“哪个区域有东西”这个坐标信息给定死了，云端只需要聚焦分析该区域的内容。两边各干各最擅长的事，能力反而形成互补。

5.2 一个参考工作流：从触发到上云再到回传

用文字描述一套我在多个项目中验证过的混合式工作流，不做图，大家看文字就能搭起来：

• 第一步，设备端YOLO模型常驻推理，每帧都做目标检测，检测结果里的类别和坐标暂存内存。
• 第二步，根据业务规则判断是否需要上云，比如检测到新的目标类别、目标框面积发生变化超过阈值、发生周期性定时抓拍等，事件条件满足则从对应区域裁剪图像块，压缩到指定分辨率。
• 第三步，把裁剪出的图像块和必要的上下文JSON（设备ID、时间戳、本地检测类别、置信度、GPS坐标）打包，异步发送到云端网关。
• 第四步，云端Flash模型基于图像块和上下文做细粒度分析，输出结构化结果（缺陷类型、行为判定、置信度等级）。
• 第五步，结果写入消息队列，回传到设备端或业务平台；设备端拿到结果后更新本地状态，比如标记这个缺陷已被识别、不再重复上报。

这个流程的关键在于“端侧决定什么时候上云、云端决定怎么理解”。上云的触发不准，要么漏报要么冗余；理解得不准，端侧筛得再准也没用。所以混合式不是简单堆两个模型，而是对端侧触发规则和云端Prompt/模型指令做联合调优。

5.3 端侧触发规则的配置示例

触发规则我会建议做成可配置的，不要写死在固件里。下面是一个精简的事件触发配置示例，字段含义全部用中文注释说明，方便不同平台的开发者理解：

{ "device_id": "dev-0421", "model_params": { "confidence_threshold": 0.55, "nms_threshold": 0.45 }, "event_rules": [ { "rule_name": "缺陷检测触发", "target_classes": ["scratch", "dent", "stain"], "trigger": "confidence > 0.60", "region_crop": true, "upload_resolution": [640, 640], "jpeg_quality": 70, "cooldown_seconds": 5 }, { "rule_name": "周期性巡检", "trigger": "cron */300 * * * * *", "region_crop": false, "upload_resolution": [1280, 720], "jpeg_quality": 75, "cooldown_seconds": 0 } ] }

• confidence_threshold和nms_threshold：端侧YOLO后处理的两个核心参数，阈值越高，上云事件越少，漏报风险越高，一般建议多跑几天实际场景数据再做调整。
• event_rules：每条规则对应一类触发行为，目标类别、触发条件、裁剪方式、上传分辨率和冷却时间都可以独立配置。
• cooldown_seconds：冷却时间是最容易被忽略的字段。没有冷却时间的话，一个持续3秒的检测事件可能触发几十次上云调用，流量直接被吃掉，加5秒冷却，同一事件在一个冷却窗口内只上报一次，费用立省80%。
• cron表达式：用来实现周期性抓拍分析，比如每5分钟整图巡检一次，它和事件触发互为补充。

5.4 混合架构容易踩的三个坑

混合架构看起来清晰，实际落地时同样有自己专属的坑。第一个坑是数据回传的队列积压。设备端上云请求走的是异步队列，如果网络恢复瞬间积压了大量补传任务，会迅速挤占正常优先级的上云请求。解决办法是给队列区分优先级，实时事件请求优先，延时补传请求靠后，队列长度超过阈值时直接丢弃过期事件。

第二个坑是时间戳对齐。端侧检测到事件的时间、图像实际采集的时间、云端分析完成的时间，这三个时间如果不一致，后续做视频取证和事件追溯时会很痛苦。统一约定：所有上报请求必须带设备本地UTC时间戳，云端处理时以这个时间戳为准做关联，而不是请求到达时间。

第三个坑是端侧模型和云端模型对同一目标的认知要尽可能一致。端侧YOLO把目标识别为“人”，云端Flash却判断“这只是一个塑料模特”，两边结论冲突时业务层到底信谁？我建议的设计是：涉及安全级别高的结论，必须以云端判断为准，但端侧检测结果要作为上下文一同送入云端，让云端模型可以综合判断而不是凭空分析。

6. 一次真实项目复盘：手持质检仪从纯端侧到混合式，准确率从90.2%到98.6%

讲理论讲得再多，不如一个真实项目复盘来得直观。这里说的是一个手持质检仪项目，产品形态是一台带国产AI视觉SoC的便携设备，用来对设备表面的瑕疵做快速检测和分类。整个选型过程刚好完整经历了“纯端侧→纯云端→混合式”三个阶段，非常有代表性。

6.1 项目初始的技术选型

设备采用的是某国产6TOPS级SoC，端侧跑YOLOv8n做瑕疵区域定位和粗分类，目标是实时识别“脏污、划伤、凹陷”三类问题。项目初期甲方明确要求数据不能出厂房，所以整个系统被设计成纯端侧离线方案。YOLOv8n在设备上完成初次检测后，本地决策输出结果，现场试用准确率约90.2%，看起来已经能用了。

但真正跑起来以后发现90.2%的准确率卡在了一个边界场景上：脏污和旧涂层脱落、划伤和纤维丝痕在画面里长得极其接近，端侧YOLO只能输出“有东西”，根本无法区分具体缺陷成因。客户要求的是“判断是不是划伤、划伤大概多深、属于操作问题还是来料问题”，这已经远远超出目标检测模型的能力范围。

6.2 第二阶段：直接上云，准确率上去了但体验下来了

为了满足新需求，团队试过纯云端方案：端侧先用YOLO检测到缺陷区域并定位，截取缺陷区域图像块通过Wi-Fi上传到云端Flash模型，让大模型直接给出“划伤、脏污、凹陷、涂层脱落”的细分类判断，并附带一句话的原因描述。准确率很快提升到97%以上，看起来成功。

但代价立刻显现：每次上传要等1到3秒，而且质检员往往在厂房里走动，不同位置网络状况差异很大，经常出现上传超时或返回结果太慢的情况。一两次卡顿还能忍，连续几台设备都出现类似问题后，质检员开始直接用手机拍照找技术负责人，项目推进马上陷入了僵局。这就是前面说的“云端快不等于真实时延低”的工程现实，单次请求400毫秒不代表任务完成时间只有400毫秒。

6.3 第三阶段：本地YOLO做减法，云端Flash做加法的混合改造

最后定型的方案回到了混合式。端侧YOLO依然常驻运行，但任务收敛为两件事：一是实时定位缺陷区域，画框标出位置和初步类别；二是判断这个区域是否值得上云，判断依据是置信度、变化幅度和人为触发。云端Flash模型只做一件事：对端侧裁剪出的图像块做细粒度缺陷分类和成因推断，并结合端侧传入的坐标信息输出结构化JSON结果。

信息流做了严格分层：端侧输出的坐标框和置信度是“感知层”结果，云端输出的缺陷类型和原因是“认知层”结果；两边的结果都会展示给质检员，但最终判定以云端分析为主。改造后准确率提升到98.6%，单台设备每天除正常巡检外只上传40到80张缺陷图块，一个月流量费大约13元左右，完全在可接受范围内。

6.4 这次复盘的三个选型铁律

把这个项目的整个演进过程打散，能提炼出三条特别值得所有做国产AI视觉SoC开发的同行记住的选型铁律：

第一条，先区分问题和任务，再选模型和平台。能靠目标检测解决的，优先用目标检测；必须靠语义理解解决的，千万不要为了“离线”而硬扛。端侧YOLO和云端Flash从来不是同类选型，而是在“感知”和“认知”两个不同层次上的各自最优解。

第二条，纯端侧和纯云端都是理想状态，混合式才是真实世界。纯端侧死在模型能力边界上，纯云端死在网络和成本上；混合式用端侧兜住实时性和稳定性，用云端补足理解力，残酷地说，这是一条既符合技术理性、也符合商业理性的折中路。

第三条，成本和体验要在POC阶段就算清楚，别等量产再算。比如图片上传分辨率、JPEG压缩质量、冷却时间、月调用量、单次API价格、流量单价这些参数，在第一个Demo跑通之前就写进方案里，并留出30%到50%的冗余。等项目跑起来再回头看，这些数字可能会救你于水火。

最后再说几句实际的

做了这么多年端侧视觉项目，我个人最大的体会是：两难的本质不是技术不行，而是需求里同时站着两个不同层次的问题，而我们总想用一套方案去解决两个问题。国产AI视觉SoC的NPU再强，它也只是一个感知器官，能高效地“看见”；云端Flash再快，它也隔着一张网，适合承担“思考”。真正成熟的架构，是让感知层用足端侧算力、让认知层用好云端智能、让两者之间靠数据和规则有机衔接。

如果你现在正卡在这个选择上，我的建议特别简单——把前面那张七维决策表打一遍分，别急着写代码。分数出来之后，该端侧还是该云端，或者该混合，方向基本就定了。实在拿不准的，优先从混合式起步：端侧模型选小但够用的，云端接口做成可切换的，这样不管是模型迭代还是网络环境变化，你都有退路。

最后再分享一个我亲自踩出来的小经验：所有涉及上云的方案，第一个月不要直接订长周期流量套餐，先跑真实业务观察调用量。很多项目的实际调用峰值和低谷差距大到你怀疑人生，这时候，按量付费加预算告警才是性价比最高的姿势。等数据攒够了再调整套餐结构和并发额度，才不会多花冤枉钱。