最近在社区里又看到一个老问题被翻出来“你们项目端侧跑 YOLO 还是直接云端调 Flash”底下两拨人吵得不可开交。一拨说端侧才是AI视觉落地的大势另一拨甩出云端轻量模型的 API 价格讽刺对方的板子成本够调几百万次。说实在的这种架吵得挺没营养因为两边往往连项目约束条件都没对齐。我是做国产 AI 视觉 SoC 方案出身这几年在端侧部署、NPU 工具链、模型量化、云端多模态 API 对接上都踩过不少坑最后发现“端侧还是云端”根本不是技术信仰问题而是一个需求拆解问题。这篇就把我沉淀下来的决策方法和一张表完整分享出来。1. 先别急着站队多数人纠结的根本不是技术而是需求没量化1.1 两难局面是怎么来的以前做视觉项目没什么可纠结的。端侧 SoC 算力弱、工具链稀烂想本地跑实时检测基本是做梦云端呢要么自己搭 GPU 服务要么去调老牌视觉 API跟现在的状态完全是两码事。但最近两年局面变了一端是国产 AI 视觉 SoC 的 NPU 算力从几年前的 2-3 TOPS 一路涨到 6 TOPS、十几 TOPS 甚至更高YOLO 这类检测模型本身也在变小变轻从 YOLOv5 到 YOLOv8n/YOLOv10n模型文件只有几 MB 到十几 MBINT8 量化后跑在 6 TOPS 的板子上已经可以做到实时的边缘另一端是 Flash 系的多模态模型 API 陆续开放图片可以直接丢进去让模型输出“画面里有什么”按 token 计费单次调用看起来只花几分钱对不熟悉端侧开发的人来说这条路的吸引力确实大。问题也就出在这。很多人一看“云端调用一次只要几分钱”立刻觉得比买开发板、啃量化工具链划算。但他们忘了视频流是持续的一秒钟 25 帧一天下来就是一帧一帧堆出来的调用量这个账拿“单次调用成本”去估误差大得离谱。我见过不止一个项目前期评估时信心满满地走云端纯调用路线结果设备一部署上去月度 token 账单直接击穿预算上限最后灰溜溜地回头做端侧。1.2 容易被忽略的“伪需求”陷阱我平时接项目复盘时发现很多团队在技术选型阶段吵来吵去根源是需求描述本身就模糊。你去问客户“你这个项目要端侧还是云端”客户给你的回答一定是“都行”“稳定就行”“快就行”。这种说法没法做技术判断。真正需要拆开的维度至少有三个数据敏感性图像数据能不能出设备、出局域网有没有隐私红线很多行业客户自己都说不清但这是所有决策里优先级最高的一条。实时性要求这个 AI 能力是要在 100 毫秒内做出闭环动作比如闸机放行、机械臂抓取还是只要能在一两秒内给出结果就行访问模式与成本结构设备是 7x24 小时开机、持续产生的视频流还是低频偶发事件、几十分钟才触发一次这两种模式对“按需计费”意味着完全不同的成本曲线。还有一条更隐蔽的变量项目团队自己会什么。如果你团队没人懂量化、没人碰过 NPU 工具链端侧路线从零开始啃的周期很可能要四周起步云端路线则把工程复杂度转移成了持续性的 token 成本和网络依赖。团队能力短板不是不能补但必须在需求评估时就算进去否则排期一定崩。1.3 决策前的准备工作先录一段真实业务场景视频在拿任何模型做验证之前我强烈建议先做一件事录一段目标现场的原始视频越长越好、越贴近真实光照越好。然后拿这段视频去压测两种路线——端侧板子上跑推理或者截帧去调云端接口统计每一帧的处理耗时、失败率、结果质量。我在大量项目里发现真实场景下的表现和 Demo 数据集上的数字经常是两码事因为现场的光线、遮挡、目标密集程度、网络波动这些东西在 Demo 里根本不会出现。这一步做完你会发现“端侧 vs 云端”的争论已经从口头变成数字后面所有的选型判断才有基础。2. 端侧 YOLO 的真实能力边界算力标称、量化掉点与视频流的容量账2.1 从 TOPS 数字到真实帧率先把冷水泼透国产 SoC 的规格书上都印着大大的 NPU TOPS 数字但很多人第一次上手时信心满满跑起来却傻眼了标称 6 TOPS 的板子跑 YOLOv8s 640 输入实际帧率只有 20 几帧跟想象的“一秒几百帧”差距巨大。原因很简单——TOPS 是 INT8 峰值算力而且很多芯片标的是稀疏加速后的理论值。真实推理要考虑数据搬运、DDR 带宽、算子利用率、后处理耗时实际能拿到的算力通常只有标称值的五六成。我一般给朋友估算时用这样一个粗糙公式单帧 INT8 计算量约等于模型浮点运算量的两倍因为 INT8 MAC 操作数翻倍YOLOv8s 在 640x640 输入下大约 28 GFLOPs换算是 14 GMACs。在 6 TOPS 的 NPU 上纯计算时间理论上是 2.3 毫秒左右但一加上特征图搬运、中间层激活、最后 NMS 后处理分摊实际单帧延迟落在 30 到 80 毫秒才是常态。这里给出我实测过的参考区间注意不同工具链版本和固件会有明显差异但量级是靠谱的SoC 等级NPU 标称算力INT8YOLOv8s 640 实测参考帧率整板典型功耗区间入门级轻量 SoC3-6 TOPS15-30 FPS2-5 W中端视觉 SoC6-10 TOPS25-45 FPS4-10 W高端边缘 SoC10-25 TOPS45-90 FPS8-20 W我实际项目里还会做一步很多国产 NPU 对 640 输入不友好降到 416x416 或 320x320 之后帧率能涨近一倍代价是远距离小目标基本废了。所以“帧率不够”时不要盲目怀疑板子先看你的业务真实需要多大输入尺寸。2.2 量化掉点与 NPU 算子生态mAP 缩水只是开始把 PyTorch 模型转到 NPU 工具链比如瑞芯微的 RKNN-Toolkit2、算能的 flatbuffer、地平线的 mapper 这类常规流程都要做 INT8 量化。量化后的模型普遍会掉点掉多少看数据集敏感度。我遇到比较多的情况是整体 mAP 只降了 2-3 个点但业务里最关心的小目标召回率直接砍掉 10 个百分点。所以只盯 mAP 是骗自己你必须拿自己业务关心的那一两个类别、那一个尺寸范围去单独评估。此外还要注意两点不是所有算子 NPU 都支持。有些自定义结构比如特殊的注意力模块工具链不支持会自动切成 CPU 算子这一下就打破了 NPU 推理的流水线延迟抖动会很难看。所以选模型结构时不要图新要图“工具链适配”。NMS 这类后处理大多在 CPU 上跑。类别越多、检测框越多CPU 耗时越长。如果同一路视频流的画面经常塞满目标后处理时间可能比 NPU 推理时间还长整体帧率会被拉下来一大截。实测时一定要在“目标密集场景”下测不要拿空镜头当基准。3. 云端 Flash 类模型的隐性账本延迟、token 与并发曲线3.1 先澄清一个概念这里的 Flash 不是存储颗粒开始讲云端之前必须先澄清一个很容易被搞混的事。搜索“Flash”能找到大量跟存储相关的内容比如 NAND Flash 和 NOR Flash 的区别、SPI Flash 下载固件报错常见的“flash download failed”这类 Keil 烧录报错、Flash ID 查询之类的嵌入式老问题。这些跟电商、智能家居、MCU 启动流程相关的话题是另一个领域的日常。而本文要对比的 Flash指的是以 Gemini Flash 系列、通义千问 Flash、智谱 Flash 等为代表的轻量级多模态大模型 API 档位它们主打低延迟、低价、够用的视觉理解能力。这两者容易混淆但完全不是一回事。做嵌入式出身的同学第一次听“云端调 Flash”时脑子里的画面还停留在存储颗粒上这就没法聊了。3.2 一次云端视觉理解的耗时拆解很多人以为“调用云端大模型”就像本地函数调用一样发个请求就出结果。实际上一次完整的云端视觉推理时间链路是这样的设备拍图 - 图片编码压缩 - 上行传输 - 云端排队 - 图像 token 化 - 视觉编码器推理 - 语言模型生成文本 - 网络回传 - 本地解析每一环都在吃时间。实际测下来从按下请求到拿到完整文本200 毫秒算非常快绝大多数场景落在 500 毫秒到 3 秒这个区间。这还是在网络稳定的前提下如果设备端是 4G 网络或者 Wi-Fi 信号不佳一张 1080p 图片上传就要大几百毫秒整体延迟再翻倍。所以如果你心里想的是“视频监控里每个目标出现都要实时上报”这个延迟模型根本不成立。云端 Flash 类模型适合的是“已经发生的事做理解总结”不适合“正在发生的实时闭环控制”。3.3 token 成本的结构性陷阱按帧调用是个无底洞云端多模态模型按 token 计费图片会被切分成视觉 token 输入不同分辨率档位、不同平台计费策略都不同。粗略估算一张 1080p 图片折算成视觉 token 大约在一千到两千这个量级。光看单次价格确实便宜但算上真实业务量就完全不同了。这里给一个保守估算模型。假设一套设备每天只在业务高峰期调用 500 次每次输入图片加输出文本合计约 2500 token一个月 30 天就是 3750 万 token。按现在各家 Flash 档位大致的挂牌价区间去乘一个月的费用大约是几百元这个量级。看起来也还好但请注意这只是一台设备。一个项目动辄几十台上百台设备月度成本直接上万。这才是“云端调用”最大的坑它按次累积且完全跟着在线率和并发走。对低频事件型应用这个成本可以忽略不计对高频视频流应用云端路线在数学上就已经不成立了。所以选型时必须先算清楚单位设备每天预计调用次数而不是纠结单次价格。3.4 并发与抖动别忽略业务洪峰和限流云端 API 还有一个常被低估的问题并发限流。很多平台的免费额度档位或基础档位有 RPM 限制突发流量一来直接 429。真实业务里早晚高峰往往是集中爆发时段几十台设备同时告警、同时调 API如果本地没有做令牌桶限流和失败重试体验会非常不稳定。另外云端模型是共享资源池公共 API 的排队时间在不同时段差异很大。我实际测过同一接口凌晨两点的延迟和晚上八点的延迟能差出一倍这还是在同一网络环境下。所以涉及云端路线的项目设计方案时必须有超时、退避、队列三个机制否则上线第一天就会被高延迟打穿。4. 一张表定生死我的完整决策表和三条硬性判据4.1 这张表的使用方法我把这几年积累的选型逻辑全部收敛成一张表。用法有讲究不是把两列参数加权评分然后取平均而是逐行确认命中任何一条硬性判据就直接锁死路线都不需要继续讨论。这能省掉大量无效开会时间。下面是完整决策表评估维度端侧 YOLO云端 Flash 类模型我的选型判据单帧端到端延迟30-120 ms取决于 SoC、输入尺寸、量化300-3000 ms网络 RTT 排队 推理 回传要求闭环在 200 ms 以内、不能抖动时直接选端侧运行成本结构硬件一次性投入为主电费可忽略按 token 累积在线时长越长、调用越频繁越贵7x24 高频持续推理选端侧每天少于几百次调用才考虑云端数据敏感度数据不出设备本地闭环图片必须出设备上云有人像、车牌、内部场地等隐私红线直接锁死端侧网络依赖完全离线可用断网即停摆设备部署在弱网、断网、园区内网隔离环境必须端侧目标类别范围封闭集只能识别训练过的类别开放集可以描述任意物体和场景类别固定且提前已知端侧类别会漂移、无法穷举云端或混合多模态语义理解只能输出坐标和类别语义要自己拼能输出场景描述、物体关系、行为判断希望输出“人话”和结构化文案云端有明显优势扩容方式单板算力固定扩容靠加板子云端可水平扩展加预算即可设备数量少但单点要求高或并发峰值不可预测云端更灵活功耗约束3-20 W 范围可按芯片档位选通信模组持续在线也要耗电加上每次传输的峰值功耗电池供电或严格功耗预算的场景端侧优先算法迭代频率要重新训练、量化、烧录固件改 Prompt 或换模型版本即可上线算法策略会频繁调且没有专职算法工程师云端更省事信息输入密度单帧单图分析可传多帧、多图输出全文总结需要跨时间窗口总结规律云端完胜这张表我用了很久每次选型评审拿它逐行过一遍基本不会有“拍脑袋决定”的争议。它最大的价值不是告诉你要选哪边而是逼你把约束条件全部摆出来。4.2 两条硬性红线与一条场景默认这张表背后还有三条默认规则比表本身更重要第一数据绝对不能出设备或出局域网的项目端侧是唯一答案。这没有讨论空间不管云端模型多强、多便宜在合规面前都是零分。这类项目如果逆着来后续出问题就不是技术问题了。第二需要亚 200 毫秒稳定延迟的场景端侧自然胜出。云端模型再快光物理链路里的光速和路由跳数都摆在那再叠加上图片压缩上传就很难做到。比如闸机、机械臂抓取、AGV 避障这类要闭环控制的场景不用犹豫。第三这两个条件都没有命中就开始算成本结构。我常用一个很简单的公式单帧云端成本乘以每路每秒调用次数再乘以并发路数和在线时长得出月成本拿这个数去对比端侧硬件增量成本和开发调试周期。如果云端月成本低于几千块、设备量又不大说实话直接走云端调 API 也没毛病没必要为了“技术情怀”硬啃端侧。4.3 混合方案从来不是妥协而是最优解还有一个容易被忽略的点端侧和云端不是互斥关系。我最后落地的很多项目采用的都是“端侧做主用云端做兜底”的混合架构。端侧 YOLO 把能识别的基础目标先处理掉遇到识别不了、可信度不足、分类不确定的场景再抽取关键帧交给云端做开放集理解最后把结果合并回来。这种方案既保住了延迟和隐私底线又用云端的开放语义能力补齐了端侧的封闭集短板成本还被压在可控范围内。5. 实战复盘一个园区抓拍项目从两难走到“端侧做主、云端兜底”5.1 项目约束三条红线把方向直接锁死去年我经手的一个园区出入口与周界抓拍项目正好就是一次标准的两难场景。客户几十个点位分散在园区各处网络环境不是很好电源线路不稳定而且现场涉及大量员工面部信息和车辆信息这些图像数据绝不能出本地局域网是绝对的隐私红线。就这一条云端纯调用路线就出局了一半。剩下的一半是“异常事件”这个需求它是个开放集——消防通道被占用、垃圾乱堆、车辆停在禁停区、陌生人在某处逗留过久……这些语义用封闭集的 YOLO 类别去穷举类目会膨胀到没法维护而且总会有没见过的场景。这正好是云端多模态模型的优势区。所以我们面临的状态是基础目标检测必须端侧做开放语义理解又需要云端能力纯二选一根本无解。5.2 决策过程三步走不吵无谓的架我按自己的方法论走了三步。第一步硬性红线锁定数据不出局域网端侧做主框架这个方向直接从表里锁死。 第二步识别端侧的能力盲区端侧 YOLO 固定跑人形、车辆、烟火等几个封闭类识别正常目标对高置信度的常规目标直接本地处理不再上抛。第三步云端兜底边界只有端侧检测到“低置信度目标”或“不在模型类别内但画面变化异常”的帧才压缩后通过加密通道发给云端 Flash 类模型让模型输出“画面里发生了什么”的结构化文本。成本核算下来一台设备每天真正触发兜底调用的次数通常不到一百次一个月总量也就三千次上下。这个量级在 Flash 类模型的计费框架里一个月费用可以忽略不计和纯端侧硬件成本相比完全不是一个量级的管理复杂度。5.3 落地链路与踩过的三个坑落地的技术链路大概是这样的板载 SoC 上跑 YOLO 检测检测结果进入本地业务逻辑模块常规事件直接触发本地告警或抓图存储只有异常低置信度事件进入队列攒够五秒的关键帧后再统一交给云端理解云端返回文本结果解析成结构化 JSON 后与本地事件绑定。这个链路听上去并不复杂但实际落地时我踩了三个坑都是文档里不会写的东西。第一个坑一开始我把云端兜底做成了同步调用。检测线程发现一个低置信度目标直接阻塞等待云端返回结果网络一抖后面的视频帧全部堆积整个识别流水线被拖死。后来改成独立队列 异步消费检测线程写队列就完事兜底线程按自己的节奏处理问题立刻消失。第二个坑云端返回的 JSON 结构不稳定。不同请求返回的字段结构偶尔不一样有时候检测结果是一个数组有时候被包成对象尤其是没有强制用 schema 模式时模型输出真的能给你惊喜。处理方式是两段式先让模型按固定结构输出本地再做一层 Schema 校验解析不了就丢弃重试不让脏数据进入业务逻辑。第三个坑重复告警。同一目标在视频里逗留了半分钟被不同帧重复触发多次兜底产生多条几乎一样的告警。后来在本地加了一个帧哈希 时间窗去重同一目标来源的相似帧在三十秒窗口内只允许进入一次兜底流程。这一步做完告警量直接降了一个数量级。5.4 这个混合方案的收益账最终这个方案跑通后客户对两件事非常满意一是基础检测从不过度依赖网络即使在园区网络波动期间人形、车辆、烟火这些核心功能依然在本地正常运作二是开放集语义理解没有缺席那些之前没法穷举的异常场景因为云端 Flash 类模型的兜底而全部能被描述出来。对开发团队来说这个方案的隐性收益更大算法迭代周期被大幅压缩。基础类别要改的时候才走重新训练量化流程大部分新增语义只要调整云端 Prompt 就能上线完全不用重新烧录端侧固件。6. 这些坑我都踩过一遍后的实话现在接项目时我的第一个问题已经不再是“你打算用 YOLO 还是调 Flash”而是“数据能不能出境、结果多快必须回来、这个月你愿意为推理付多少钱”。这三个问题的答案基本决定了端侧、云端还是混合的路线。经过这么多项目的折腾我有几个掏心窝的体会想分享给同样在做 AI 视觉 SoC 开发的人。第一个体会选型文档写不出来的关键变量是团队自身。你团队有没有人玩得转 NPU 工具链有没有人扛得住量化调优的周期如果没有强行上端侧的后期成本很可能超过你省下的那点云端调用费。技术路线没有高低之分只有匹配不匹配。第二个体会通用模型的单次调用能力再强视觉任务里的关键路径仍然需要实时检测。哪怕你最后决定全走云端也建议在端侧留一个 YOLO 做“运动感知”或“画面变化检测”用它的输出去决定到底哪一帧值得上云。这个前置过滤器能省下的 token 费用比任何模型调优都来得快。第三个体会无论走哪条路线建立“真实场景回放”测试习惯是最值的投入。拿一段现场录制的视频在板子上循环播放压测跑一个晚上看稳定性同样这段视频截帧去云端模拟调用看失败率和延迟分布。这两组数据比任何评测集数字都更能代表上线后的真实体验。第四个体会成本不是算一次就完了。云端调用费用、端侧误检导致的无效上云这些数据要周期性复盘最好每个月看一次趋势。我见过太多项目上线时成本漂亮运行三个月后因为模型行为变化或场景变化成本悄悄翻了三倍还没人发现。最后再分享一个小技巧做技术验证时千万别只在实验室网络环境里测。去现场、用真实设备、走客户的网络链路完整跑一遍“端侧检测 异步队列 云端兜底”的链路把所有异常分支都打上日志。图像类项目最怕的不是模型不准而是链路中各环节互相等待导致的雪崩这个坑在纯端侧和纯云端方案里都不明显混合方案里却几乎是必然遇到的。端侧 YOLO 和云端 Flash 类模型本质上只是工具箱里的两种工具没必要为它们站队。用一张表把需求拆清楚把约束条件量化出来答案会自己浮出水面。