一台在摄像头旁边就要实时判断"要不要报警"的分析盒子里，同时养着两种"眼睛"------跑得快但容易看走眼的小模型，和看得准但跑不快的大模型。这篇文章讲清楚它们到底怎么分工、怎么交接，以及照着哪些配置就能把这套机制接进自己的系统。
全文的核心机制：一个目标被框出、裁剪，交给大模型回答"是不是"------这一个动作，在系统里被安排在两个完全不同的位置。
先把问题摆清楚
在一台边缘 AI 盒子里，视频分析要在本地芯片上实时跑完：检测、追踪、分类。这些"小模型"体积小、速度快，能同时吃满几十路摄像头，但天生粗糙------一片反光、一块广告牌上的人像，都可能被认成目标，报警一多就没人愿意点开看了。
真正能理解语义的判断，得靠视觉语言大模型------这套系统里用的是 Qwen3VL。但它推理一次要几百毫秒到几秒，不可能对着几十路摄像头的每一帧都跑一遍。于是工程上没有二选一，而是让两种模型分了工，并存成两种模式：
复核模式：小模型继续冲在最前面。它喊"有情况"了，大模型才凑近看一眼，一票决定这条报警是真是假。
直检模式：没有现成的小模型可用，或者要判断的本来就是一句话才能说清的语义（"是否在打架"），大模型自己顶到最前面当探头。
下面先看两种模式共用的地基------小模型流水线长什么样，再分别拆开这两种模式，最后是一份对照清单和照着配的接入步骤。
绝大多数帧，走的都是这条老路
小模型 · 主战场
解码出来的每一帧，先过检测模型，框出画面里可能的目标；框会被送进追踪模块，绑上一个跨帧不变的 ID；再往下是分类 / 属性识别，给目标打上更细的标签，比如"未戴安全帽""烟雾""车辆"；最后进入区域判断这一层，结合画布上画的电子围栏、方向规则，决定这个目标是否构成一次触发。
这一整条链路，每一步用的都是编译进端侧芯片（NPU 或 ONNX Runtime）的传统模型：轻量、专用、延迟以毫秒计。它把海量的画面收窄成少数几个"候选报警"------这也是接下来复核模式的起点。
这一整条链路都在端侧芯片上跑传统小模型，每一跳传递的数据都比上一跳更"浓缩"------从像素，到框，到 ID，到标签，最后到一次触发。
产品实拍 · 算法编排
同一条链路在真实系统里的样子------一个"未戴安全帽"任务的节点链：视频解码 → 目标检测算法 → 追踪算法 → 类别筛选 → 目标分类算法 → 目标判断 → 灵敏度计算 → 事件上报。每个方框都是流程图里能拖拽、能单独配参数的一个节点。
产品实拍 · 实时展示
同一条链路真正跑起来的样子：蓝框是画好的电子围栏，红框是检测到的目标，左上角是每一节点的实际耗时------检测 15.57ms、追踪 0.28ms、分类 1.13ms，整条小模型链路合计不到 20 毫秒。
先报警，后过一遍大模型的眼
复核模式
候选报警走到告警节点时，如果这个节点上打开了大模型复核，事情不会立刻上报。系统会先把报警框朝四周各扩出一圈边距，从原始画面里裁出一张目标图，再拼一句提示词丢给大模型：
判断图片中是否存在【xxx】目标或对应行为，回答是或者否
"xxx"怎么填是分优先级的：运营人员写的审核描述 → 没写就用分类标签 → 再没有就用算法名兜底。大模型只需要回答"是"或"否"------答"是"，报警照常走完出图、录像、推送这一整套流程；答"否"，这条报警就在这一步被悄悄拦下，压根不会出现在事件列表里。
这里还有一处特意做的取舍：只要过程中任何一步出问题------画面拿不到、大模型没起来、请求超时------系统都选择放行而不是拦截。对一套报警系统来说，多看错一次的代价，远小于漏掉一次真实报警，所以复核这一步是"宁可信其有"。
大模型自己顶上去，当一次探头
直检模式
这种模式反过来：大模型不再是把关人，而是流水线里一个可以独立配置的"动作节点"，和检测、追踪这些小模型节点是平级的组件。在编排一条分析任务时，直接选中"语言视觉大模型"这个节点，就相当于告诉系统------这一段判断交给大模型来做。
它具体看哪一块画面，取决于它在流程图里接在什么后面------按下面的顺序自动判定，不用手动指定：
1、后面接着检测节点：直接复用检测框，往外扩一点后逐个裁出候选目标图------相当于"小模型先取景，大模型来定性"。
2、没接检测节点，但画了监控区域：按区域坐标裁图，只看指定的那一片画面。
3、两者都没配：退而求其次，把整帧缩放后完整地丢给自己判断------这是唯一会出现"整张画面被判成一次报警"的情况。
命中之后生成的报警，会被打上一个"已由大模型判定"的标记。这个标记很关键：后面的区域规则校验、以及复核模式里的复核逻辑，看到这个标记都会直接放行，不会再把同一件事问大模型第二遍。
。
产品实拍 · 添加大模型节点
左：在算法动作面板里选中"语言视觉大模型"。右：一条"城墙破坏行为识别"任务的完整 Pipeline------开始节点直接接语言视觉大模型，再接结束节点，没有检测、没有跟踪，大模型独自撑起整条链路。
产品实拍 · 命中事件
"河道漂浮物识别"任务命中后的实时事件：左上角耗时栏写着 Qwen3VL: 3142.38ms------和上一节小模型链路的"不到 20 毫秒"放在一起看，就是这套系统不敢让大模型跑每一帧的原因。
视频这么快，大模型怎么跟得上？
直检模式的大模型一次推理动辄几百毫秒到几秒------上面那张截图里 Qwen3VL 自己就用了 3142 毫秒。系统没有指望让大模型变快，而是从根上不让它看完整的视频流，卡住了也选择丢帧，而不是排队硬等。
▸ 先在源头限流 ：每个任务能配一个"取帧频率"，比如 fps=0.1 表示大约 10 秒才取一帧喂给大模型，不匹配节奏的帧压根不会被送进来。
▸ 推理和视频流水线是分开的：大模型节点跑在自己独立的线程上，视频解码往它的队列里塞帧是"扔了就走"，不会被大模型的速度拖慢。
▸ 队列满了就丢最新帧，不排队等：这个队列有个上限，大模型处理不过来、队列堆满时，新来的帧直接被丢弃------跟复核模式里"出问题就放行"是同一种取舍：宁可漏看，也不堆积延迟。
▸ 推理前先把图缩小：画面边长超过 960 像素会先等比缩放，减少每次推理本身的耗时。
这套机制也不是没有代价：远程接口有 timeout_ms 兜底超时，但本地 NPU 推理完全没有超时------一次卡住会一直占着这个线程；而且本地推理是全局串行的，同一时刻整台设备只能有一路大模型在跑，多个直检任务会互相排队等。
谁先看见目标，决定了整套机制怎么跑
复核模式 vs 直检模式
本质上，两种模式的区别只有一句话：**复核模式里，小模型先发现目标，大模型再确认；直检模式里，大模型自己发现目标。**但这一点区别，会一路影响到触发方式、失败时的行为、乃至要不要走区域规则。
产品实拍 · 能力选择路径
想接进去，照着做
两种模式都能独立开启，也可以在同一台盒子的不同任务里并存。下面是各自需要配置的东西。
接入复核模式：给已有报警加一道复核
前提是这条任务本身已经能正常出报警------检测、跟踪、分类、区域规则都跑通了，只是误报有点多。
1、在告警节点上打开 enableLlmReview 开关。
2、按需填写 llmReviewContent，比如"未戴安全帽""明火"；不填的话会自动退化，依次用分类标签、算法名兜底。
3、选择大模型来源：本地部署就填 llmAtomicCode 指向端侧的 Qwen3VL 权重；接远程服务就配一组 OpenAI 兼容参数------base_url 、api_key 、model 、endpoint ，以及 max_tokens / temperature / top_p 这类生成参数。
4、保存后，下一次真实报警都会先带着裁剪图问一次"是不是"，回答"否"就会被拦下，不会出现在事件列表里。
接入直检模式：让大模型自己当一次探头
适合完全没有对应小模型、或者判断内容偏语义的场景。
1、在算法编排里新增一个"语言视觉大模型"动作节点，可以单独用，也可以接在检测节点后面。
2、写好用来判断的提示词或关键词，比如"打架""火焰""未戴口罩"。
3、决定取图方式（跟上文三选一的判定顺序一致）：想要"小模型找目标、大模型定类别"，接在检测节点下游；想要"只盯一片区域"，改成在任务里画监控区域；两者都不配，就退化成整帧判断，适合"画面里有没有人"这类粗粒度问题。
4、同样二选一：本地权重或远程 OpenAI 兼容接口。
5、命中后产出的报警自带"已由大模型判定"标记，会跳过区域规则和二次复核，直接进入出图、上报流程。
产品实拍 · 远程接口配置
切到"OpenAI 接口"推理方式后的配置面板，字段和上面两条接入指南里的标注一一对应：base_url、api_key、model、endpoint，默认端点是 /chat/completions。
说到底，这不是"大模型取代小模型"的故事，而是一套关于延迟、成本和准确率的分工------能靠规则和轻量模型解决的，就不劳烦大模型；解决不了的，再把语义判断交出去。这也是边缘 AI 现阶段一个挺现实的答案：不是每一帧画面都需要被理解，只有值得再看一眼的那一帧，才配得上一次大模型推理。
边缘 AI 的架构，说到底都是延迟、成本和准确率之间的取舍