1. 视频联网平台为什么不能把每一路画面都丢给大模型1.1 从一次真实的容量估算说起先算一笔账这笔账我在多个项目里反复算过每次结论都一样大模型不能直接扛全量视频流。假设一个中等规模的视频联网平台接入 3000 路 1080P 摄像头帧率 25fps。如果要对每一路做实时语义理解哪怕只抽帧到 1fps那也是每秒 3000 次推理请求。一次多模态大模型推理输入一张 1080P 图像加一段提示词输出结构化描述在单张主流推理卡上大概需要 300ms 到 800ms。按 500ms 算单卡每秒只能处理 2 路。3000 路需要 1500 张卡。这个数字没有任何工程可行性。采购成本、机房功耗、散热、运维复杂度任何一项都足以让方案在评审会上被直接毙掉。更别说很多场景要求的是 25fps 全帧率分析那需求还要再乘 25 倍。所以问题的本质不是大模型好不好用而是算力预算和业务需求之间的错配。大模型强在语义理解、跨模态推理、开放词汇识别弱在吞吐和单位成本。视频联网平台的需求恰恰相反海量并发、低延迟、7x24 稳定运行、单位成本要压到极低。提示任何声称用大模型直接分析全部视频流的方案先让他把每秒推理次数和单次延迟报出来再乘以路数基本就露馅了。1.2 大小模型协同到底解决什么问题大小模型协同的核心思路是把任务按难度和频率分层。小模型负责高频、固定、轻量的过滤和初筛大模型负责低频、开放、需要语义推理的复核和决策。打个比方这就像小区门口的保安和物业经理。保安小模型24 小时盯着监控和门禁处理 99% 的日常情况——有人刷卡进门、有车驶入地库、有异常徘徊。只有当保安发现这个人行为可疑但说不清哪里不对时才呼叫物业经理大模型来研判。物业经理不需要盯着每一个进出的人他只在关键时刻出手。落到视频联网平台上典型的分工是这样的层级承担角色典型任务延迟要求算力占比边缘层轻量检测模型人形检测、车辆检测、区域入侵100ms60%边缘/中心小模型分类器属性识别、行为初判、目标跟踪300ms30%中心层大模型/多模态模型复杂事件研判、跨镜追踪、语义检索秒级可接受10%这个 6:3:1 的比例不是拍脑袋来的是我在多个项目里根据实际事件分布调出来的。真实场景中95% 以上的视频帧是无事发生的小模型的作用就是把这 95% 快速过滤掉只把真正有信息量的 5% 往上送。1.3 边缘计算在这里扮演什么角色边缘计算不是可选项是必选项。原因很直接带宽和延迟。3000 路 1080P 视频如果全部回传到中心机房做分析按每路 4Mbps 码率算总带宽需求是 12Gbps。这还只是单份如果要做多路复用、存储、转发实际带宽需求要翻倍。很多园区的出口带宽根本撑不住。边缘计算的做法是在摄像头侧或者就近的边缘节点上部署轻量模型本地完成初筛只把结构化结果比如某区域检测到人形时间戳、坐标、置信度和关键帧回传。数据量从 12Gbps 降到几十 Mbps降了两个数量级。边缘节点的硬件选型也有讲究。我一般推荐这几档入门档ARM 架构边缘盒子4 到 8 路接入跑轻量检测模型功耗 10W 以内适合小型网点。主力档带入门级 GPU 或 NPU 的边缘服务器16 到 64 路接入可跑检测加分类功耗 50 到 150W适合园区、楼宇。重载档多卡边缘服务器128 路以上可跑小模型加轻量大模型功耗 300W 以上适合大型枢纽。选型的关键不是堆算力而是匹配实际并发路数和模型复杂度。我见过太多项目买了高配边缘服务器结果只跑了 8 路检测算力利用率不到 10%纯属浪费。2. 大小模型协同的架构设计与任务分层2.1 三层架构感知层、研判层、决策层一个能落地的大小模型协同架构我习惯拆成三层。这个分层不是学术概念是工程上必须清晰的职责边界否则后期维护会一团乱。感知层部署在边缘只做一件事把视频流变成结构化事件。输入是 RTSP 流输出是 JSON 格式的事件对象包含时间、位置、目标类型、置信度、关键帧路径。这一层不关心这件事意味着什么只关心发生了什么。研判层部署在中心或区域节点接收感知层的事件做二次分析。这里跑的是小模型分类器和规则引擎负责判断事件的严重程度、是否需要升级、是否需要关联其他摄像头。比如感知层报检测到人形研判层要判断这个人在禁区内还是区外停留了多久是否在非工作时间。决策层才是大模型出场的地方。只有研判层标记为需要语义理解的事件才会送到大模型。大模型负责回答开放性问题这个人的行为是否构成异常这段描述和用户查询是否匹配综合多个摄像头的信息这个事件的完整经过是什么。三层之间的数据流是单向的、有过滤的。感知层每秒产生几千条事件研判层过滤后可能只剩几十条决策层每秒可能只处理几条。这个漏斗结构是整套架构能跑起来的关键。2.2 任务分层的判断标准哪些任务给小模型哪些给大模型不能凭感觉。我总结了一个判断框架四个维度第一任务是否封闭。如果目标类别是固定的、可枚举的比如人、车、非机动车三类小模型足够。如果目标类别是开放的比如找出所有看起来不正常的画面那必须大模型。第二输出是否需要语义。如果输出是坐标、类别、置信度这种结构化数据小模型。如果输出是自然语言描述、推理链条、跨模态匹配结果大模型。第三延迟容忍度。要求 100ms 内响应的小模型。秒级甚至分钟级可接受的大模型。第四调用频率。每秒调用上千次的小模型。每分钟调用几次的大模型。按这个框架过一遍大部分任务的分层就很清楚了。我整理了一张对照表任务类型推荐模型理由人形/车辆检测小模型类别封闭、高频、低延迟区域入侵判断小模型规则几何判断为主无需语义目标属性识别小模型颜色、车型等固定属性跨镜目标追踪小模型特征库特征比对可离线建库行为异常研判大模型开放语义、需要上下文自然语言检索大模型跨模态匹配事件报告生成大模型自然语言输出多事件关联分析大模型需要推理链条2.3 Agent 在协同架构中的位置Agent 这个概念现在很热但在视频联网平台里它的定位要搞清楚。Agent 不是替代小模型或大模型的它是编排层。具体来说Agent 负责的是接收用户或系统的意图拆解成子任务决定调用哪个模型、哪个工具、按什么顺序最后把结果组装成用户能理解的输出。举个例子。用户说帮我查一下昨天下午三点到五点东门附近有没有可疑人员。这个请求 Agent 会这样拆解析时间范围昨天 15:00 到 17:00解析空间范围东门附近需要映射到具体摄像头 ID调用检索工具从事件库里捞出这个时空范围内所有感知层事件调用小模型对候选事件做初步筛选排除明显正常的调用大模型对筛选后的事件做语义研判判断是否可疑组装结果生成自然语言回复附上关键帧和视频片段这个流程里Agent 是调度者小模型是过滤器大模型是研判者。三者缺一不可但职责不能混。注意很多团队一上来就想用 Agent 做所有事结果 Agent 变成了一个巨大的提示词工程既慢又不稳定。Agent 的价值在编排不在推理。2.4 为什么不做端到端大模型方案有人会问既然大模型这么强为什么不干脆端到端从视频流直接到大模型输出除了前面算的算力账还有几个工程上的硬伤稳定性。大模型输出有随机性同样的输入可能给出不同结果。视频监控场景要求确定性同一个事件今天判为异常明天不能判为正常。可解释性。安防场景经常需要回溯为什么系统判定这是异常。小模型的判断可以追溯到具体的检测框和置信度大模型的判断往往是一段自然语言难以作为证据。成本可控性。小模型的算力成本是固定的、可预测的。大模型的调用成本随 token 数波动如果全量走大模型账单会失控。响应确定性。小模型的延迟是稳定的大模型的延迟受负载、输入长度影响波动很大。实时告警场景不能接受这种波动。所以大小模型协同不是退而求其次而是在工程约束下的最优解。3. 核心环节的实操落地3.1 边缘侧小模型的部署与调优边缘侧是整个协同架构的地基这里出问题上面全塌。我按实际部署顺序讲。第一步模型选型。边缘侧优先选轻量检测模型参数量控制在 10M 以内输入分辨率 640x640 足够。不要迷信大输入分辨率1080P 输入对检测精度的提升有限但算力消耗是 640 的 3 倍以上。实测下来640 输入在大多数监控场景下 mAP 只比 1080 低 2 到 3 个百分点但帧率能翻倍。第二步量化。边缘设备算力有限FP32 推理太奢侈。INT8 量化是标配精度损失通常在 1 个百分点以内速度提升 2 到 4 倍。量化时要注意校准集的选择必须用真实场景的图片不能用公开数据集否则量化后的模型在实际场景里会掉点。第三步推理引擎选择。这个要看硬件。NVIDIA 系用 TensorRTARM 系用 NCNN 或 MNN国产 NPU 用厂商自带的 SDK。不要试图用一套引擎通吃所有硬件适配成本远高于收益。第四步多路复用。一个边缘节点要处理多路视频必须做批处理。把多路的帧攒成一个 batch 一起推理能显著提升吞吐。batch size 的选择要平衡延迟和吞吐我一般从 4 开始试逐步加到 16找到延迟还能接受的临界点。第五步抽帧策略。不是每一帧都需要检测。相邻帧之间差异很小全帧率检测是浪费。我一般用两种策略固定间隔抽帧比如每 5 帧抽 1 帧或者基于运动检测的动态抽帧画面有变化才检测。后者更省算力但实现复杂一些。# 边缘侧抽帧与批处理的核心逻辑示意 import time class FrameSampler: def __init__(self, interval5, batch_size8): self.interval interval self.batch_size batch_size self.buffer [] self.frame_count 0 def should_process(self, frame): self.frame_count 1 if self.frame_count % self.interval ! 0: return None self.buffer.append(frame) if len(self.buffer) self.batch_size: batch self.buffer self.buffer [] return batch return None这段逻辑看着简单但 interval 和 batch_size 的取值直接决定边缘节点的实际承载路数。我踩过的坑是interval 设太小算力扛不住设太大快速移动的目标会漏检。经验值是 interval 取 3 到 5配合运动检测做动态调整。3.2 事件上报与过滤机制边缘侧检测到目标后不能无脑上报。如果每个检测框都往中心送中心会被淹没。必须做过滤和聚合。过滤规则我一般设这几条置信度阈值低于 0.5 的检测直接丢弃误报太多。区域过滤只在配置的关注区域内的事件才上报区域外的忽略。时间去重同一目标在连续帧里被反复检测到只上报一次用目标 ID 去重。频率限制同一摄像头同一类型事件每秒最多上报 N 条防止刷屏。事件聚合是更高级的过滤。比如一个人走进画面边缘侧可能连续检测到 30 帧如果每帧都上报就是 30 条事件。聚合后应该变成 1 条事件附带首次出现时间最后出现时间轨迹摘要。聚合的实现通常用目标跟踪算法给每个目标分配一个 ID跟踪期间只维护一条事件记录目标离开画面后再上报完整事件。这样上报量能降一个数量级。上报的数据格式要统一我一般用这样的结构{ event_id: cam001_20240115_153022_001, camera_id: cam001, timestamp: 2024-01-15T15:30:22.500Z, event_type: person_detected, confidence: 0.87, bbox: [320, 180, 480, 520], track_id: t_8823, duration_ms: 4200, keyframe_path: /snapshots/cam001/20240115/153022.jpg, zone_id: zone_east_gate }这个结构里track_id和duration_ms是聚合的关键keyframe_path是给大模型做二次分析用的。没有关键帧大模型就没法做视觉研判。3.3 大模型研判的提示词设计大模型在协同架构里的调用频率不高但每次调用都很关键。提示词设计直接决定研判质量。我的经验是提示词要结构化不要开放式。开放式提示词会让大模型自由发挥输出不稳定。结构化提示词把任务拆成明确的字段让大模型填空。一个典型的事件研判提示词长这样你是一个视频监控事件研判助手。请根据以下信息判断事件性质。 事件信息 - 摄像头位置东门入口 - 事件类型人员检测 - 检测时间2024-01-15 15:30:22 - 持续时长4.2秒 - 目标数量1 - 附加信息该人员在禁停区域停留超过3秒 请输出JSON格式结果 { is_abnormal: true/false, severity: low/medium/high, reason: 简要说明判断依据, suggested_action: 建议的处理动作 }这个提示词的关键点明确角色、明确输入、明确输出格式。大模型不需要发挥创造力它需要的是稳定地完成分类任务。提示提示词里的输出格式一定要用 JSON并且给出字段说明。这样后端可以直接解析不需要再做自然语言处理。我见过用纯文本输出的方案后端解析起来痛苦不堪。3.4 关键帧的选取与传输大模型做视觉研判需要图像但不是随便一张就行。关键帧的选取有讲究。选取原则选目标最清晰、遮挡最少、姿态最完整的那一帧。实现上可以在跟踪过程中持续计算目标的清晰度分数比如拉普拉斯方差选分数最高的帧作为关键帧。传输优化关键帧不需要原始分辨率。大模型对图像的理解能力在 720P 左右就基本饱和了再高分辨率收益递减。我一般把关键帧缩放到 720PJPEG 质量 85单张大小控制在 200KB 以内。这样传输快大模型处理也快。存储策略关键帧要保留一段时间用于事后回溯。我一般保留 7 天热数据放 SSD冷数据转对象存储。存储成本要算进整体预算3000 路每天产生的事件关键帧按每路每天 100 张算一天就是 30 万张7 天 210 万张按每张 200KB 算需要 420GB。这个量级用对象存储很划算。4. 常见问题与排查技巧实录4.1 边缘侧漏检与误报的排查漏检和误报是边缘侧最常见的两类问题排查思路完全不同。漏检排查按这个顺序查先看原始视频流是否正常。有时候是 RTSP 流本身丢帧不是模型的问题。再看抽帧策略。interval 设太大快速移动目标会漏。临时把 interval 调到 1 验证。然后看模型输入。分辨率、归一化参数是否和训练时一致这个最容易出错。最后看置信度阈值。阈值设太高会漏检临时调到 0.3 验证。误报排查重点查这几项训练数据是否覆盖当前场景。用公开数据集训的模型换到实际场景误报率会飙升。是否有干扰源。树影晃动、灯光变化、雨雪天气都会触发误报。区域配置是否正确。把非关注区域也纳入检测范围误报自然多。置信度阈值是否太低。适当提高阈值能压误报但要平衡漏检。我整理了一张速查表现象可能原因排查动作特定时段漏检光照变化检查该时段视频补充训练数据特定区域漏检摄像头角度调整摄像头或重新标定区域小目标漏检输入分辨率不足提高输入分辨率或改用切片推理频繁误报干扰源加区域掩码排除干扰区域夜间误报多红外模式补充红外场景训练数据误报集中在某类目标类别混淆检查混淆矩阵补充难例4.2 大模型调用超时与成本失控大模型调用有两个典型问题超时和成本。超时通常是因为输入太长或并发太高。解决思路控制输入长度。关键帧分辨率降到 720P提示词精简到必要字段。设置超时熔断。超过 5 秒没返回就放弃走降级逻辑比如直接用小模型的判断结果。做请求队列。大模型调用串行化避免并发打满。成本失控通常是因为调用量没控制住。解决思路严格过滤。只有研判层标记为需要语义理解的事件才调用大模型比例控制在 5% 以内。结果缓存。相同或相似的事件复用之前的研判结果。用事件特征的哈希做缓存键。分级调用。简单研判用轻量大模型复杂研判才用重量级模型。我实测下来一个 3000 路规模的平台如果过滤做得好大模型的实际调用量每天在几千次量级成本完全可控。如果调用量到了几十万次那一定是过滤逻辑出了问题要回去查。4.3 跨摄像头目标关联的难点跨镜追踪是视频联网平台的高价值功能但也是难点。核心问题是怎么判断不同摄像头里的目标是同一个人。小模型层面靠特征比对。每个目标提取一个特征向量通常是 ReID 特征在特征库里做最近邻搜索。这个方案在光照、角度差异不大时效果好差异大时准确率会掉。大模型层面可以做语义级的关联。比如把多个摄像头的事件描述送给大模型让它判断这些描述是否指向同一个目标。这个方案准确率高但成本也高只适合少量关键事件的关联。实际落地时我一般用两级策略先用小模型做粗筛召回 Top-K 候选再用大模型做精排。这样兼顾了成本和准确率。注意跨镜追踪的特征库要定期更新和清理。目标离开画面后特征应该保留一段时间比如 24 小时用于关联之后清理掉否则库会越来越大检索越来越慢。4.4 系统稳定性与降级策略大小模型协同的系统稳定性设计比功能实现更重要。因为一旦挂了整个监控就瞎了。降级策略我一般设计三级一级降级大模型不可用时研判层直接用规则引擎兜底。规则引擎虽然笨但稳定能覆盖 80% 的常见场景。二级降级研判层不可用时感知层的事件直接上报由人工研判。这时候系统退化成传统的报警系统。三级降级边缘节点不可用时视频流直接回传中心由中心的小模型处理。这时候带宽压力大但功能不丢。每一级降级都要有明确的触发条件和恢复条件并且要有告警。降级不是静默的运维必须知道系统当前处于什么状态。健康检查要覆盖全链路边缘节点的推理服务、事件上报通道、研判层的规则引擎、大模型的 API 可用性。任何一环异常都要能快速定位。我在实际项目里踩过最大的坑是边缘节点和中心的时间不同步。事件时间戳对不上导致跨镜关联完全失效。后来强制所有节点走 NTP 同步并且在上报时带上本地时间和同步状态问题才解决。这个坑不踩一次是想不到的写在这里给后来人提个醒。4.5 模型更新与灰度发布模型不是一次部署就完事的需要持续迭代。但视频监控系统不能停机更新必须支持灰度发布。我的做法是边缘节点支持双模型槽位新模型部署到备用槽位通过配置切换流量。先切 10% 的摄像头到新模型观察一周指标正常再逐步扩大。任何异常立即切回旧模型。灰度期间要重点监控的指标漏检率、误报率、推理延迟、资源占用。这四个指标任何一个恶化超过阈值都要暂停灰度。模型版本管理也要规范。每个模型文件要有版本号、训练数据版本、评估指标、部署时间。出问题时能快速定位是哪个版本引入的。这套流程看着繁琐但比直接全量更新然后出事要省心得多。我见过一次全量更新后误报率翻三倍的案例回滚花了两个小时期间运维电话被打爆。灰度发布虽然慢但稳。5. 一些实操中的个人体会大小模型协同这件事技术方案本身不复杂难的是边界划分和工程细节。我做了几个项目下来最大的体会是不要追求大模型做所有事的优雅要接受小模型干脏活累活的现实。小模型就像工地上的工人干的活不高级但量大、必需、不能停。大模型像请来的专家关键时刻出手平时不用在场。一个健康的系统是工人和专家各司其职而不是让专家去搬砖。另一个体会是过滤逻辑的价值被严重低估。很多团队把精力全花在模型精度上却忽略了哪些数据该送上去这个更根本的问题。实际上一个好的过滤逻辑能让系统吞吐提升一个数量级成本降一半而模型精度可能只影响几个百分点。工程上架构的价值往往大于单点算法的价值。最后说一个具体的技巧边缘节点的事件上报一定要带足够的上下文。不要只报检测到人要报在哪个区域、什么时间、持续多久、目标什么状态。这些上下文是小模型能提供、大模型需要的。上下文越丰富大模型的研判越准整个协同链条的效率越高。我见过太多方案边缘侧只报一个检测框中心拿到后一脸懵还得回头去调原始视频白白浪费了协同架构的优势。