1. 3000路视频接进大模型为什么第一天就崩了先说一个我亲身经历的场景。某园区视频联网平台接入了大约3000路摄像头客户兴致勃勃要上大模型智能分析——想让模型看懂每一路画面识别异常行为、生成事件描述、自动派单。方案评审的时候大家都觉得没问题模型能力摆在那儿识别准确率也够看。结果真跑起来第一天就崩了。崩的方式很典型不是模型不准而是根本跑不动。3000路视频假设每路每秒抽1帧送进大模型做推理那就是每秒3000次请求。哪怕用最便宜的视觉大模型单次推理按1秒算你也需要3000张GPU同时在线。这个成本没有任何一个园区项目扛得住。更别说网络带宽、推理延迟、并发排队这些连锁问题。这就是大模型盯3000路视频这个想法最致命的误区把大模型当成了一个可以无限并发的万能识别器。它确实聪明但它贵、它慢、它不适合做高频的、海量的、重复性的初筛工作。那正确的姿势是什么答案就是标题里的四个字——大小模型协同。让便宜、快、能扛并发的小模型去做看这件事让聪明但昂贵的大模型去做想这件事。小模型负责从3000路里筛出可能有问题的那几十路大模型只对这几十路做深度理解和决策。这一进一出成本能降两个数量级效果反而更好。这篇内容我想聊的就是这套协同架构在视频联网平台里到底怎么落地。核心关键词包括大模型、大小模型协同、视频联网平台、Agent、边缘计算。适合正在做视频平台智能化改造的工程师、架构师也适合想搞清楚大模型到底该怎么用的产品和技术负责人。我会从架构分层、边缘侧小模型选型、大模型Agent编排、并发与成本控制、踩坑经验几个角度把这件事讲透。2. 大小模型协同的分工逻辑谁看画面谁做决策2.1 为什么不能让大模型做全量初筛要理解协同先得理解大模型和小模型的本质差异。这不是强和弱的区别而是通用和专用、慢思考和快反应的区别。大模型尤其是多模态大模型的优势在于语义理解、跨模态推理、开放场景泛化。你给它一张图它能告诉你这个人在翻越围栏手里还拿着东西可能是违规闯入。这种能力是小模型给不了的。但它的代价是单次推理需要大量算力延迟通常在几百毫秒到几秒并发能力受限于GPU显存和算力。小模型传统CV模型、轻量检测模型的优势在于快、便宜、可并发、可边缘部署。一个YOLO系列的检测模型在边缘盒子上跑单帧推理可以做到几十毫秒一路视频一个模型实例3000路就是3000个轻量实例分布式铺开完全可行。但它的短板是只能识别训练过的固定类别遇到没见过的场景就抓瞎也说不清楚为什么。所以分工逻辑就很清楚了小模型做感知层7×24小时盯着每一路视频做目标检测、区域入侵、越界、遗留物、人群聚集这类结构化事件初筛。它的任务是发现可疑不是下结论。大模型做认知层只接收小模型上报的疑似事件片段关键帧短视频结构化标签做深度理解、上下文关联、自然语言描述、决策建议。它的任务是理解并决策。这个分工的本质是把大模型从高频劳动者变成专家顾问。专家顾问一天看几十个案子价值最大化让他去流水线上拧螺丝纯属浪费。2.2 一个具体的流量漏斗模型我用一个数字化的漏斗来说明这套协同到底省了多少。假设3000路视频每路每分钟产生1个疑似事件这个比例已经很高了实际大部分时间是空画面。那么层级处理对象处理量单次成本技术手段感知层全部视频帧3000路×实时极低边缘小模型过滤层疑似事件约3000次/分钟低规则引擎轻量分类认知层确认事件约50-100次/分钟高大模型Agent从3000路全量到每分钟几十次大模型调用这就是漏斗的价值。而且过滤层还能再筛一道小模型报的疑似里有大量误报树叶晃动、光影变化、小动物用规则引擎和轻量分类模型再过滤一遍真正送到大模型的可能只有几十次。提示漏斗的每一层都要有独立的误报率指标。感知层误报率高没关系因为后面有过滤但如果过滤层漏掉了真事件那就是事故。所以过滤层的召回率要优先于准确率。2.3 协同不是简单的串联而是闭环很多人以为大小模型协同就是小模型检测→大模型分析这么一条直线。实际上真正好用的架构是闭环的。大模型在认知层做出的判断可以反过来优化小模型。比如大模型发现某类误报特别多某个摄像头因为逆光总是误报这个反馈可以写回规则引擎调整该摄像头的灵敏度阈值。再比如大模型识别出新的异常类型可以触发小模型的增量训练流程把新场景纳入检测范围。这个闭环让系统越用越准。我见过一个项目上线三个月后感知层的有效事件占比从最初的不到10%提升到了40%以上靠的就是大模型反馈驱动的持续调优。3. 边缘侧小模型怎么选、怎么部署才扛得住并发3.1 边缘计算在视频平台里的真实定位边缘计算这个词被说烂了但在视频联网平台里它的定位非常具体把算力推到离摄像头最近的地方减少回传带宽和中心算力压力。3000路视频如果全部回传到中心做分析光是带宽就是天文数字。1080P视频按4Mbps算3000路就是12Gbps的持续回传这还没算分析算力。而边缘计算的做法是在园区、楼栋、甚至摄像头侧部署边缘盒子视频在本地就完成初筛只把疑似事件片段回传中心。回传量可能只有原来的百分之一。边缘侧跑的就是小模型。这里的小模型选型有几个硬指标推理延迟单帧要在50ms以内否则多路并发时排队严重。模型体积要能塞进边缘盒子的有限内存通常控制在几十MB到几百MB。功耗边缘设备往往没有强散热功耗要可控。精度在目标场景下的召回率要够宁可误报不可漏报。3.2 小模型选型的实操对比我实际用过几类方案给你一个横向对比方案类型代表技术优势劣势适用场景传统检测模型YOLO系列轻量版快、成熟、生态好泛化差、需标注固定场景检测轻量分类模型MobileNet类极快、体积小只能分类不能定位事件二次过滤蒸馏小模型大模型蒸馏而来泛化较好训练成本高中等复杂度场景专用加速模型针对NPU优化能效比高绑定硬件大规模边缘部署我的经验是感知层用YOLO轻量版做检测过滤层用MobileNet类做分类这个组合性价比最高。YOLO负责哪里有东西MobileNet负责这个东西是不是真的异常。两层加起来边缘盒子上单路视频的CPU占用可以控制在合理范围。3.3 边缘部署的并发账怎么算这是很多人算不明白的地方。我给你一个实际的计算方法。假设一个边缘盒子算力是某款主流边缘芯片INT8算力约几个TOPS。一个YOLO轻量模型单帧推理需要约1-2 GOPS。那么理论上这个盒子每秒能跑几千帧。但实际要考虑视频解码开销每路视频解码本身就要占算力。内存带宽多路并发时内存带宽是瓶颈。调度开销多路轮询的上下文切换。实测下来一个中等算力的边缘盒子稳定跑8-16路视频的实时检测是比较现实的。那么3000路视频就需要约200-400个边缘节点。这个数字听起来多但边缘盒子成本远低于GPU服务器总体成本反而低得多。注意边缘节点的部署密度要结合网络拓扑。不要为了省盒子把太多路视频集中到一个节点一旦这个节点挂了影响面太大。建议单节点不超过16路且做冗余。3.4 边缘与中心的协同协议边缘小模型检测到疑似事件后怎么把信息传给中心这里有个设计要点传什么。不要传原始视频流太占带宽。正确的做法是传事件关键帧1-3张压缩后事件短视频片段前后各几秒低码率结构化标签事件类型、置信度、时间戳、摄像头ID、目标框坐标边缘节点的元信息模型版本、设备状态中心收到这些事件包后先过规则引擎和过滤层再决定是否送大模型。这个协议设计好了带宽和中心算力都能省一大截。4. 大模型Agent在认知层到底怎么编排4.1 Agent不是调一次大模型API那么简单很多人一说大模型接入就是调个API返回结果。这在认知层是远远不够的。Agent的价值在于它能编排多步推理、调用工具、维护上下文。在视频平台里一个事件从疑似到确认再到处置往往需要多步理解事件画面多模态理解关联历史这个摄像头之前有没有类似事件关联周边相邻摄像头同时段有没有异常判断严重程度是否需要立即处置生成处置建议派单给谁、说什么记录归档结构化存储这六步如果每步都单独调大模型成本和延迟都受不了。Agent的作用就是把这些步骤编排成一个工作流用一次或少数几次大模型调用完成中间用工具调用查数据库、查规则库补充信息。4.2 一个可落地的Agent编排结构我实际用过的结构是这样的入口事件包进入Agent。工具层Agent可以调用几个工具——历史事件查询、摄像头元数据查询、规则库查询、相似事件检索。推理层大模型基于事件画面工具返回的信息做综合判断。输出层结构化的事件结论自然语言描述处置建议。关键在于工具层的设计。大模型本身不知道这个摄像头在哪、之前发生过什么这些信息要通过工具调用喂给它。工具调用要快、要准、要控制返回信息量否则上下文塞爆了反而影响推理质量。4.3 大模型选型的现实考量认知层用什么大模型这里有几个现实约束私有化部署 vs API调用涉及视频数据的项目很多客户要求数据不出场那就得私有化部署。私有化部署对显存要求高要考虑量化版本。多模态能力认知层要理解画面必须用多模态大模型。纯文本模型看不了图。成本认知层调用量虽然比感知层少但单次成本高要算清楚每分钟几十次调用的月度成本。微调需求通用大模型对特定行业场景比如工业检测、特定违规行为的理解可能不够需要大模型微调。微调能显著提升特定场景的准确率但需要标注数据和训练资源。我的建议是先用通用多模态大模型跑通流程收集真实事件数据再针对性微调。不要一上来就微调因为你还不知道真实场景里模型会在哪里出错。4.4 Agent的记忆与上下文管理Agent要记得之前发生过什么这就是Agent记忆的问题。在视频平台里记忆分两层短期记忆当前事件相关的上下文比如这个摄像头最近10分钟的事件。长期记忆历史事件库用于相似事件检索和模式发现。短期记忆直接塞进上下文长期记忆通过检索向量数据库按需调用。这个设计能避免上下文无限膨胀同时让Agent具备经验。5. 并发、成本与延迟协同架构的工程账5.1 并发瓶颈到底在哪一层很多人以为瓶颈在大模型其实不一定。我实测下来瓶颈可能在三个地方边缘解码3000路视频的解码本身就很吃资源如果边缘盒子解码能力不足检测再快也没用。事件回传大量事件同时回传时网络和中心接收服务可能成为瓶颈。大模型排队认知层如果并发太高请求会排队延迟飙升。所以优化要分层做。边缘侧优化解码用硬件解码中心侧优化事件接收消息队列削峰认知层优化大模型调用批处理缓存。5.2 成本控制的几个狠招成本是这个项目能不能落地的关键。我总结几个实操有效的招事件去重同一个事件在短时间内被多个摄像头或多次检测到合并成一次大模型调用。结果缓存相似事件同一摄像头、同一类型、相近时间复用大模型结论不重复调用。分级调用不是所有事件都送最强的大模型。低优先级事件用轻量模型或规则处理高优先级才送大模型。批处理把多个事件打包成一次大模型调用如果模型支持多图输入摊薄单次成本。这几招用下来大模型调用量能再降一半以上。5.3 延迟预算怎么分配一个事件从发生到处置端到端延迟要控制在可接受范围。我一般这样分配预算环节延迟预算说明边缘检测100ms小模型推理事件回传200ms网络传输过滤层100ms规则轻量分类大模型推理3s认知层处置下发500ms派单系统总延迟控制在4秒以内对于大部分安防场景是可接受的。如果要求实时性更高比如危险行为即时告警那就要把部分认知能力下沉到边缘用轻量模型做快速判断大模型只做异步的深度分析。6. 踩过的坑那些文档里不会写的教训6.1 误报率不是越低越好刚做的时候我们拼命优化小模型想把误报率降到最低。结果发现误报率降下来后漏报率上去了。后来才明白感知层的目标是不漏不是不误。因为后面有过滤层和大模型兜底感知层多报一点没关系漏了才是大问题。所以感知层的阈值要调得敏感一些。6.2 大模型的幻觉在安防场景是致命的大模型会编。它可能把一只猫说成可疑人员把正常走动说成翻越行为。在安防场景这种幻觉会导致大量无效派单运维人员很快就失去信任。解决办法有两个一是用结构化输出约束大模型让它只能从预定义的事件类型里选不能自由发挥二是关键结论要有人工复核或规则校验大模型说有人翻越要结合小模型的目标框位置、运动轨迹做交叉验证。6.3 边缘节点的运维是个大坑几百个边缘节点铺下去运维成本很高。节点掉线、模型版本不一致、时间不同步这些问题在大规模部署时都会暴露。我的经验是边缘节点必须支持远程升级和状态上报而且要有一个统一的节点管理平台。否则出了问题你连哪个节点挂了都不知道。6.4 别忽视时间同步多摄像头协同分析时时间戳必须对齐。如果边缘节点时间不同步大模型关联相邻摄像头同时段异常时就会出错。部署时一定要配NTP而且要监控时间偏差。6.5 数据标注是持续投入小模型要准就得持续标注。大模型反馈的误报和漏报都要变成标注数据反哺小模型训练。这是一个持续的过程不是一次性投入。项目预算里要留出这部分。7. 从3000路到30000路架构的可扩展性设计7.1 水平扩展的关键无状态化要让架构从3000路扩展到30000路核心是无状态化。边缘节点是无状态的配置从中心下发事件接收服务是无状态的消息队列削峰大模型调用是无状态的结果缓存。只有无状态才能水平加机器。7.2 分区分域30000路视频不可能用一个中心处理。要按区域、按业务分域每个域有自己的边缘节点和事件接收服务域之间通过消息总线通信。这样单域故障不影响全局。7.3 大模型的服务化与弹性认知层的大模型要服务化支持弹性扩缩容。事件高峰期多开实例低谷期回收。如果用的是云上大模型API天然支持弹性如果是私有化部署要考虑容器化和调度。8. 我个人在实际操作中的几点体会做了几个视频平台的智能化项目后我最大的体会是大模型不是用来替代传统CV的而是用来补位的。传统CV做它擅长的快、准、专大模型做它擅长的理解、推理、泛化两者协同才是当前阶段最务实的方案。另一个体会是不要追求一步到位。先跑通边缘小模型检测→中心大模型分析的最小闭环哪怕只接几十路视频验证效果和成本模型再逐步扩展。我见过太多项目一上来就要接几千路结果卡在工程细节上半年都上不了线。最后分享一个小技巧在过滤层加一个事件聚合逻辑。同一个区域、同一时间段的多路视频事件先聚合再送大模型。这样大模型看到的是这个区域发生了什么而不是这一路发生了什么理解质量会高很多调用量也省了。这套架构不是银弹它有自己的适用边界。如果你的场景是几十路视频、要求实时性极高、或者场景非常固定那可能纯小模型就够了不需要大模型。但如果你的场景是海量视频、需要语义理解、需要开放场景泛化那大小模型协同就是目前最靠谱的答案。