端侧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到25FPS，1280x720下能到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 完整决策表长这样：可以直接复制去用的打分卡

下面是我团队现在还在用的完整评分卡。建议你直接复制到自己的项目文档里，先把六个维度的默认描述读一遍，再结合项目情况修正：

把所有维度打分填进去，乘以对应权重，最后得数如果在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"这个问题最后会消失，因为它变成了一个清晰的分工问题，而不是站队问题。