端侧YOLO还是云端Flash？一张决策表搞定AI视觉架构选型

这个项目端侧跑YOLO还是云端调Flash上周方案评审会老板把问题一抛整个会议室安静了三秒钟。不是大家没想法而是这个问题背后缠着的东西太多芯片算力、模型能力、带宽成本、交付周期、客户对数据能不能出设备的敏感度每一项都能让方案在中途翻车。我后来把这两条路的账算了很久最后用一张决策表把架构选型固定下来。今天不聊虚的直接把这张表、每个维度的打分逻辑以及三个真实项目的复盘过程完整写出来。先交代语境避免误会。我这里说的国产AI视觉SoC指的是RK3588、算能、地平线、爱芯这类带NPU的芯片平台跑的是嵌入式Linux或RTOS方案端侧YOLO指YOLOv5/v8/v11这类目标检测模型经过量化、剪枝后部署到板端NPU云端Flash不是存储芯片而是DeepSeek Flash、Gemini Flash、Qwen Flash这类轻量级云端视觉语言模型能看图说话、回答开放问题而不只是给你框一个目标。这篇文章适合正在做视觉硬件方案的嵌入式工程师、硬件产品经理以及被AI盒子到底该卖端侧方案还是云端方案反复折腾的解决方案同学。往下看之前先记住一个结论这不是一道二选一的选择题多数情况下正确答案是混合架构只是你还没找到把端和云切开的那条线。1. 两难到底是怎么来的算力、模型和客户需求的三方拉扯1.1 端侧SoC纸面算力的幻觉TOPS很高但项目处处是雷先说端侧。现在国产AI视觉SoC的纸面算力确实不像前几年那么寒酸了RK3588的NPU标称6TOPS算能BM1684能到16TOPS地平线征程系列也一路往上加。很多方案商老板一看规格书第一反应是这么高算力YOLOv8随便跑于是拿着几十帧的演示Demo去跟客户谈。实际一上项目就露馅。第一规格书上的TOPS通常是在特定输入分辨率、特定算子上测出来的理论峰值你跑真实的YOLO模型INT8量化后有效利用率能打五折就算优化得不错。第二YOLO模型的瓶颈往往不是NPU算力而是内存带宽和DDR访问。输入分辨率1920x1080特征图在NPU里来回搬运带宽一卡NPU空转等着数据帧率照样上不去。第三模型前处理、后处理NMS非极大值抑制、跟踪算法这些部件NPU一般不擅长得跑到CPU上。一个6TOPS的芯片如果CPU核也就那样后处理写得不讲究照样把整个流水线拖垮。所以端侧的真实状况是一个YOLOv8s INT8模型优化得不错的情况下在6TOPS级别芯片上能做到1080P输入下15到25FPS1280x720下能到30FPS左右。但如果你要把输入分辨率抬高或者同时跑两路视频流算力余量立刻见底。这不是芯片厂商吹牛而是端侧系统集成本来就会吃掉大量资源。换句话说端侧的天花板比你想的低但地板也比你想的稳。1.2 YOLO生态的强大和尴尬能框出东西但看不懂画面YOLO这个生态成熟到你几乎不需要从零写任何东西。网络结构、损失函数、训练代码、标注工具GitHub上应有尽有。把KITTI标注转成YOLO格式、标注自己的数据集、跑训练、导出ONNX、再量化成rknn或者地平线工具链能吃的格式这一整套流程被社区反复打磨过踩坑记录满天飞大概率你不会卡死。但YOLO本质是一个封闭集合检测器它能告诉你目标框在哪、属于哪个预训练类别但它不理解场景。它能把人和头盔分别框出来但它不知道一个人正在操作一台没有防护罩的机器这件事是有风险的。你要它识别长尾物体类比如某种特定品牌的矿泉水瓶、某种罕见型号的PCB元件就得自己标注大量样本、重新训练、重新标定精度整套人力成本算下来非常可观。更要命的是客户现场永远会出现训练集里没有的场景强逆光、同色物体重叠、遮挡、雨天反光。YOLO在这些情况下不是掉几个点而是漏检或误检而且它自己不知道它错了。1.3 云端Flash模型把理解画面的门槛打了下来另一边Flash这类轻量级云端视觉语言模型这两年进步幅度是跨越式的。它不需要你为每个新类别训练模型你只要把图片传上去在Prompt里写清楚找出画面中的所有安全帽并返回JSON格式的坐标它就能输出结构化结果还能顺带回答这个工人有没有把手套戴好这种需要理解能力的问题。这带来一个认知变化以前检测一个物体需要训练一个专门的视觉模型现在只要云端的多模态引擎能理解画面很多理解型需求直接能用通用模型解决不需要单独训练。这个能力把很多中小团队的交付门槛大幅降低也让云从单纯的数据中心变成了外挂大脑。但全新的问题也随之而来Flash模型毕竟跑在云端每一帧图片都要走一遍网络链路单次推理延迟再好也在几百毫秒到几秒之间加上队列排队、网络抖动到了真实设备上用户体感往往不稳定。更麻烦的是成本模型按Token计费你让它在工厂产线上7x24小时盯着画面哪怕每秒只上传一帧一个月下来的账单也会让你重新审视方案。2. 端侧跑YOLO三座天花板和一块稳固的地板2.1 模型轻量化的真实收益剪枝、蒸馏和INT8量化对付端侧算力天花板常规路子无非三条剪枝、蒸馏、量化。剪枝是把网络里不重要的通道或卷积核删掉。以YOLOv8为例用结构化剪枝可以去掉三成左右的通道精度损失一般能控制在1个点以内但推理速度提升并没有想象中那么大因为NPU在底层做矩阵运算时通道数如果不是对齐的利用率反而下降。所以现实里端侧工程师用剪枝更多是为了把模型压到芯片的舒适区而不是追求极端体积。蒸馏则是一个大模型教小模型的思路用YOLOv8x或者YOLO11x这类大模型当老师把软标签蒸馏给YOLOv8n学生模型。收益在于小模型的精度能逼近大模型但训练流程复杂不是所有团队都愿意投入。做工业项目时我会把蒸馏当成精度不够时的最后手段而不是默认选项。真正投入产出比最高的还是INT8量化。把权重从FP32压到INT8体积缩小四倍推理速度普遍能提升两到三倍。但量化是一个玄学工程同一个模型用COCO预训练权重直接转INT8可能掉点在2个点以内换成你自制的数据集如果标注样本分布不均匀某些类别可能直接崩掉。所以我的经验是量化前先做校准集统计让校准数据尽量贴近现场真实光线和角度不要图省事直接用训练集的子集。多花一个下午整理校准集能省后续现场调优的几天时间。2.2 被忽略的确定性端侧方案最大的价值不是性能是可预期很多对比文章只谈性能不谈确定性这是我认为端侧最值钱但大家最容易忽略的地方。端侧方案的延迟是确定的模型跑在本地NPU上推理时间稳定帧率可预测10毫秒就是10毫秒30毫秒就是30毫秒。掉帧规律也是可预测的只要输入分辨率不变性能波动不会超过5%。这对做实时控制类场景极其重要比如安全光栅联动、AGV避障、闸机联动系统必须在规定时间内出结果不是在网络好的时候出结果。成本也是确定的。一台设备部署完模型跑多少帧都不额外花钱。没有按Token计费没有按月账单没有客户现场网络信号不好导致功能瘫痪这类售后问题。这对于设备厂商来说意味着硬件毛利可以算清楚。摄像头设备卖出去了端侧版本的边际成本为零而云方案每一路视频流都在烧钱。这个确定性溢价是我在决策表里给端侧加分最多的地方。2.3 那端侧到底不行在哪语义理解和开放类别是硬伤端侧的天花板也得说清楚。YOLO解决的是Where and What即物体在哪、是什么预训练类但解决不了场景发生了什么以及这个状态是否异常。举个例子垃圾满溢检测。传统YOLO可以训练一个垃圾袋类别但垃圾满溢是一个状态判断它依赖垃圾和垃圾桶边缘的比例关系、垃圾桶周围是否有散落垃圾这些是YOLO很难稳定建模的。你可以硬凑出一个满地垃圾类别但现场一百个摄像头有一百种垃圾形态标注成本高到不现实。这种情况端侧模型表现极不稳定今天能用明天换个光照就失灵。另外新增类别的迭代周期是端侧的硬伤。端侧模型每增加一个类别就要重新标注、训练、量化、发布固件、OTA升级走完一轮少则一周多则一个月。如果客户的需求是先把当前常见问题覆盖后面随时可能加新类别用端侧YOLO你会被需求变更拖死。这个迭代速度维度恰恰是云端Flash模型碾压端侧的领域改一段Prompt十分钟内就能上线一个新识别逻辑不用动设备固件。3. 云端调Flash省了训练但每一帧都在产生账单3.1 Flash模型能顶哪些活检测、理解、判断一次完成云端Flash模型在工作流里扮演的角色比传统云检测API聪明得多。它可以不依赖固定类别列表直接在Prompt里描述任务模型基于对图像内容的语义理解输出结构化内容。比如让大模型找出画面里所有人并判断是否佩戴口罩返回JSON它能一次性完成检测、分类、状态判断三个动作。传统做法里这三个动作至少需要三个模型串起来每个模型的错误还会互相累积放大。还有一个很实际的优势多语言和文本生成。Flash模型能输出自然语言描述比如画面中左侧货架第二层出现疑似缺货状态这在生成日报、告警摘要、交接班记录时太好用了。端侧YOLO顶多输出一组坐标和类别ID你还要写一堆模板去拼装这些信息Flash模型可以直接把发生了什么翻译成人类可读的文本。从交付角度讲给客户Demo时Flash模型能直接说人话这种展示效果往往比跑了一堆边界框更打动人。3.2 三笔隐性成本单帧延迟、Token账单和链路复杂度但云端方案的成本账必须拉出来细算。第一是单帧延迟。不要看模型厂商公布的单次推理X毫秒那是纯GPU推理时间。实际端到端延迟包含设备采集图片、压缩、HTTP上传、排队、云端推理、回传、客户端解析整套链路下来国内网络良好情况下单张图最少要300到500毫秒网络波动时轻松超过2秒。如果你要做连续视频流分析这个延迟根本无法支撑实时告警类产品。所以说Flash模型适合每秒抽一帧或者事件触发后抓拍几张图不适合跑连续视频流。第二是Token成本。Flash模型虽然单价低但图像输入占据的视觉Token数量很大一张1080P图往往要被切块或编码成上千Token跑一轮视觉问答的价格会明显高于纯文本请求。你再乘上每天运行8小时每2秒一帧的量一天的调用量是14400次一个月30万次级别账单会让项目验收都成问题。我在项目里算过账一个100路的摄像头项目如果全部走云端Flash模型每月成本等于多请两三个运维工程师老板听到这个数字当场脸色就会变。第三是链路复杂度。端侧只要设备通电就能跑云方案要处理设备证书、密钥管理、专线或公网链路、云端高可用、数据备份、版本发布策略。对于小团队来说这相当于把一个硬件项目硬生生做成了一个互联网后端项目团队能力和运维精力都会被拖进去。这是很多方案商决定还是端侧吧的最现实理由。3.3 什么场景下云端是唯一选项长尾、开放和语义理解话说回来有些场景端侧就是再努力也白搭。一类是开放类别场景比如识别货架上有没有出现异常商品异常商品种类是无穷的你不可能训练一个包含所有可能的YOLO模型。还有一类是语义判断场景比如判断厨师在操作时有没有戴口罩——口罩检测YOLO能做但操作时这个时间状语包含的上下文YOLO无能为力需要理解前后帧的动作关系。还有一类是从一段视频里搜索某个事件的复盘场景这种非实时但需要高精度的需求用云端模型把整个片段跑一遍完全可行。在这些场景里坚持纯端侧方案就是跟物理规律较劲不如直接承认云端的不可替代性。4. 我给团队定的决策表六个维度、三个权重档、一条边界线4.1 不是拍脑袋打分六个维度都来自项目里真实卡过壳的地方网上讲技术选型的文章很多但多数只停留在如果你要低延迟选端侧如果要复杂理解选云端这种废话层面。真正到项目里你要的不是方向是阈值和计算方式。我做这张表的时候把过去几个项目里真实卡过壳的问题全部列出来最后收敛成六个维度实时性要求系统对响应延迟的容忍度目标类别开放性需要识别的物体/状态是固定列表还是开放集合环境稳定性光照、角度、背景是否可控数据敏感性客户对画面内容出设备的容忍程度单位成本预算每路视频每月能承担多少云资源费用端侧算力冗余当前芯片方案跑基础YOLO后还有多少余量每个维度按1到5打分1分代表强烈倾向端侧5分代表强烈倾向云端。打完分之后对这个分数做加权平均得到一个0到5之间的云端倾向指数。指数越接近1毫不犹豫走端侧越接近5果断上云端在3.0到3.5之间就是你最需要认真设计端云协同架构的地带。4.2 权重怎么定按产品定位选三档模板不要每次临时拍权重分配是最容易吵起来的环节。我的办法是预先定义三套权重模板按产品定位套用不在评审会上临时吵可靠性优先型适用于安防、工业安全、医疗辅助类设备。实时性权重提到0.30数据敏感性0.20环境稳定性0.20类别开放性0.15成本0.05算力冗余0.10。这套模板的哲学是稳定压倒一切云端能不用就不用云端的角色只是兜底。功能优先型适用于智慧零售分析、内容审核、体验类产品。类别开放性提到0.30成本0.20实时性0.15环境稳定性0.15数据敏感性0.10算力冗余0.10。这套模板的哲学是客户要的是能做别人做不到的事端侧做基础检测云端正真体现产品差异化。均衡型适用于大多数工业视觉项目。实时性0.20类别开放性0.20环境稳定性0.20数据敏感性0.15成本0.15算力冗余0.10。所有维度雨露均沾适合需求还比较模糊、需要继续探索的产品阶段。计算方式很简单每个维度打分乘以对应权重再求和。比如一个场景的打分是实时性2类别开放性4环境稳定性2数据敏感性4成本3算力冗余3套用功能优先型权重总分就是2×0.15 4×0.30 2×0.15 4×0.10 3×0.20 3×0.10 3.1落在端云协同区间。这个3.1不是一个精确的科学结论但它把大家的争论从我觉得云端好变成你来说说为什么实时性只值2分讨论质量立刻不一样了。4.3 完整决策表长这样可以直接复制去用的打分卡下面是我团队现在还在用的完整评分卡。建议你直接复制到自己的项目文档里先把六个维度的默认描述读一遍再结合项目情况修正维度1分强烈端侧3分中间地带5分强烈云端打分依据实时性要求需要毫秒级响应如闸机联动、安全急停秒级响应可接受如常规巡检分钟级甚至事后分析可接受客户验收时对延迟的红线目标类别开放性固定≤10类未来三年不会变10-100类允许季度级别新增开放世界无固定类别列表需求文档里可识别类型描述环境稳定性固定工位、固定光源半开放场景光线有波动户外全开放、光照天气随机现场勘测记录和样本统计数据敏感性客户强制要求数据不得出设备可脱敏后上传需要审批客户明确无所谓合同合规条款往下不展开单位成本预算零新增运营成本每路每月10-50元可接受每路每月百元以上不敏感财务测算表端侧算力冗余跑完YOLO后NPU占用小于50%占用接近80%需要优化现有芯片完全跑不动用rknn或工具链实测profiling把所有维度打分填进去乘以对应权重最后得数如果在2.5以下直接端侧4.0以上直接云端中间地带再看下面的工程方案。有一点必须强调这张表的输出不能替代验证它的作用是把拍脑袋变成先吵清楚再拍脑袋。实际项目里最好每做完一个POC就把实际数据回填到打分依据列让下一轮决策越来越准。4.4 这张表最重要的不是分数是边界线思维很多同事第一次看到这张表第一反应是分数算出来有什么用边界还不是要人定。对这个质疑是成立的表格本身不是万能的。但它的真正价值在于逼着团队把决策拆成一个个可以讨论的切片原来大家争的是端侧好还是云好这种本质抽象的问题现在争的是实时性要求到底算一分还是两分这种具体问题。具体问题是可以靠测试数据回答的抽象问题只能靠嗓门。另一个价值是防止过度设计。我一向主张方案里冗余度过高也是一种技术债。如果一个项目算出来指数是1.8那就安心做端侧不要为了体现技术含量硬塞一个云平台进去让客户买单反之如果算出来是4.5也要敢于跟客户坦白说这块本地芯片跑不了别为了卖硬件硬把模型塞进去然后现场每天死机。5. 三个真实项目的决策复盘表格怎么用答案差很多5.1 智能安防摄像头实时性卡死方案端侧胜出第一个项目是给一个厂区做智能摄像头改造核心需求是有人翻越围墙立刻告警还要联动探照灯。打分过程是这样的实时性要求客户说得非常明确翻越动作从触发到告警要控制在一秒以内这就直接给了1分目标类别就是人翻越这个单一事件固定得不能再固定打1分环境是围墙周边半固定场景白天晚上光线变化大但位置固定打2分数据敏感性方面客户是制造企业厂区画面不太愿意出园区打2分成本预算客户明确表示不想背云账单打1分算力冗余我们用RK3588实测跑YOLOv8s INT8单路1080P大概20多FP再跑一个翻越判定逻辑依然有余量打1分。套用可靠性优先权重1×0.30 1×0.15 2×0.20 2×0.20 1×0.05 1×0.10 1.30。总分远低于2.5结论非常清晰纯端侧。最后交付时云端一个接口都没有接客户非常满意因为没有任何月度费用。这个项目的痛点是如果不在决策表阶段把实时性这个维度压到1分方案很容易被云端大模型做告警分析更聪明这种话术带偏最终做出一套每月烧钱但现场联动延迟半秒的失败方案。5.2 工业质检类别极度开放云端Flash成了主力第二个项目是PCB板外观缺陷检测。这个项目一开始团队很自信觉得YOLO就能搞定毕竟YOLO在工业视觉里用得很多。实际一标数据就发现不行客户说的缺陷包括划痕、污点、少锡、错件、引脚歪斜并且经常出现这个算不算缺陷需要资深质检员判断的灰色地带。标注团队做到第二周就崩溃了因为同一个缺陷不同标注入给的框都不一样训练出来的模型在验证集上连95%都到不了现场根本不敢用。打分时目标类别开放性直接给到4分因为缺陷语义其实是开放的环境稳定性反而很好固定工位、固定光源打2分实时性要求并不高产线节拍允许3到5秒出结果打3分数据敏感性处于中间态客户虽然要求上传到他们的私有云但允许脱敏后送外部处理打3分成本预算客户项目预算充足愿意为良率提升付费打4分端侧算力我们用现有的盒子跑YOLOv8n精度完全不够打4分。套用功能优先型权重3×0.15 4×0.30 2×0.15 3×0.10 4×0.20 4×0.10 3.45。指数落在端云协同偏云端的地带。最终方案是端侧YOLOv8n做第一道粗筛只负责把明显正常的板子放行疑似缺陷图全部上传云端Flash模型做最终判定并让大模型输出缺陷类型和可能成因描述。实际效果是端侧放行了70%的正常样本节省了大量云端调用量而剩下的30%用云端模型判定准确率和可解释性都远好过纯端侧方案。5.3 智慧零售收银审核端云协同才是正解第三个项目是连锁便利店的收银合规审核需求是判断收银员有没有扫完商品再收钱、有没有漏扫高价商品。零售场景最大的痛点是商品种类几千种而且不断上新品YOLO模型根本没法维护这么庞大的类别表。所以类别开放性这项直接5分但实时性要求又很特殊不需要当场告警而是事后按小时汇总审核这就给了比较宽松的分数打4分。环境相对固定摄像头位置不动但光线和客流变化大打3分。数据敏感性很微妙顾客人脸信息肯定要处理但收银角度摄像头通常拍的是收银台台面涉及隐私的程度比巡店摄像头低打3分。成本方面连锁客户对单店月成本很敏感但愿意为防损效果付费打3分。端侧算力用的是老款芯片跑YOLO都很勉强打4分。套用功能优先型权重4×0.15 5×0.30 3×0.15 3×0.10 3×0.20 4×0.10 3.85。这个分数逼我们认真做端云协同不是简单把图全传到云端而是做了一个三阶段流水线。端侧一个极轻量的模型只做两件事——判断收银台有没有发生扫码动作和有没有商品被拿起把这些事件连同几秒短视频片段存到本地缓存云端模型只处理这些事件片段判断该笔交易是否合规。这样既避开了类别开放的坑又控制了计算量最后云端每天处理的事件片段只占全天视频的5%左右月成本可控。这个项目让我确信端云协同不是中间方案而是真正的最优解关键取决于你有没有把什么该留端侧什么该上云这个分工想清楚。6. 端云协同的工程落地把两难拆成三阶段的协作流6.1 事件分级端侧不是只做检测还要做制片人如果决策表告诉你需要端云协同那接下来的问题就是端侧和云端各自干什么。我的经验是两层模型不能各干各的端侧必须承担事件生产者的职责云端更像事件审核员。具体做法是把检测目标按风险等级分级A类事件必须在端侧即时处理并响应比如安全联锁、越界报警这类事件压根不上云保证时延B类事件由端侧触发抓拍把前后各几秒的片段截取下来压缩后传给云端做深度理解C类事件则完全交给云端做周期性扫描比如每小时分析一次画面里有没有安全隐患。这么分完之后端侧YOLO的核心任务不再是尽可能识别所有东西而是判断什么值得上云。这个视角转化很关键模型精度要求大大降低因为它只需要把A类和B类候选框找出来不需要把每个目标的细分类别都处理到位云端模型也不需要处理海量无用请求只需要在送来的一小段高质量片段上做语义分析。两边各干各擅长的事这才是端云协同的真正含义。6.2 关键片段上传别干每一帧都上云这种蠢事见过太多团队做端云协同第一步就是把视频流持续推向云端然后被账单吓傻。正确做法是让端侧先做时间维度上的抽稀再做空间维度上的裁剪。时间抽稀很好理解没用的事件不传检测到场景变化或目标出现才触发上传。空间裁剪则要精细一些假设端侧YOLO在整张图中找到了一个目标框那上传给云端的不是整张1080P原图而是目标框周围适当外扩的局部区域比如外扩20%保证上下文。这样每张上传图的数据量能缩小到原来的五分之一甚至十分之一同时保留足够信息让云端模型判断。后端接一个缓存队列如果网络不好就暂存在本地后面再回传。别小看这个设计它能让云端成本直接降一个数量级。6.3 端侧与云端的逻辑解耦模型更新节奏要分开管理最后一条工程经验是端侧固件和云端Prompt/模型版本必须解耦否则团队会被版本管理拖死。我的做法是固定一个端侧版本发布周期通常一个季度一次因为端侧模型升级要过工具链、真机测试、OTA灰度周期长且风险高。云端模型则走快速迭代比如今天发现某个Prompt在特定场景下误报率高改一版Prompt明天就能灰度上线如果换了新版Flash模型甚至可以A/B测试。两者之间用一个稳定的中间Schema解耦端侧产出的结构化事件片段统一按JSON Schema输出云端消费这个Schema只要Schema不变两边就可以各自升级。打个比方端侧是电视台云端是编辑部双方只要约定好字播稿格式电视台换主持人、编辑部换主编互不影响。6.4 最后分享一个可复用的验证技巧做这个决策表之前强烈建议你先花一天时间做一次双跑测试拿一段真实的现场视频分别用端侧YOLO和云端Flash模型跑一遍。不要只记录平均精度要记录两个东西延迟分布和错误类型。延迟分布决定能不能用于实时控制错误类型决定让它干什么活。如果YOLO的错误集中在漏检云端Flash的错误集中在分类不准那么分工就很清楚YOLO当守门员负责把人跟目标找出来Flash当裁判负责判断具体状态。我后来所有项目的初始参数都来自这第一天的双跑测试它让决策表从一开始就不是拍脑袋而是有实测数据垫底。这套流程走下来你会发现端侧跑YOLO还是云端调Flash这个问题最后会消失因为它变成了一个清晰的分工问题而不是站队问题。