企业官网建设流程全解析

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路全量到每分钟几十次大模型调用，这就是漏斗的价值。而且过滤层还能再筛一道：小模型报的"疑似"里，有大量误报（树叶晃动、光影变化、小动物），用规则引擎和轻量分类模型再过滤一遍，真正送到大模型的可能只有几十次。

提示：漏斗的每一层都要有独立的误报率指标。感知层误报率高没关系，因为后面有过滤；但如果过滤层漏掉了真事件，那就是事故。所以过滤层的召回率要优先于准确率。

2.3 协同不是简单的"串联"，而是"闭环"

很多人以为大小模型协同就是"小模型检测→大模型分析"这么一条直线。实际上真正好用的架构是闭环的。

大模型在认知层做出的判断，可以反过来优化小模型。比如大模型发现某类误报特别多（某个摄像头因为逆光总是误报），这个反馈可以写回规则引擎，调整该摄像头的灵敏度阈值。再比如大模型识别出新的异常类型，可以触发小模型的增量训练流程，把新场景纳入检测范围。

这个闭环让系统越用越准。我见过一个项目，上线三个月后，感知层的有效事件占比从最初的不到10%提升到了40%以上，靠的就是大模型反馈驱动的持续调优。

3. 边缘侧小模型怎么选、怎么部署才扛得住并发

3.1 边缘计算在视频平台里的真实定位

边缘计算这个词被说烂了，但在视频联网平台里它的定位非常具体：把算力推到离摄像头最近的地方，减少回传带宽和中心算力压力。

3000路视频如果全部回传到中心做分析，光是带宽就是天文数字。1080P视频按4Mbps算，3000路就是12Gbps的持续回传，这还没算分析算力。而边缘计算的做法是：在园区、楼栋、甚至摄像头侧部署边缘盒子，视频在本地就完成初筛，只把"疑似事件片段"回传中心。回传量可能只有原来的百分之一。

边缘侧跑的就是小模型。这里的小模型选型有几个硬指标：

• 推理延迟：单帧要在50ms以内，否则多路并发时排队严重。
• 模型体积：要能塞进边缘盒子的有限内存，通常控制在几十MB到几百MB。
• 功耗：边缘设备往往没有强散热，功耗要可控。
• 精度：在目标场景下的召回率要够，宁可误报不可漏报。

3.2 小模型选型的实操对比

我实际用过几类方案，给你一个横向对比：

我的经验是：感知层用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的价值在于它能编排多步推理、调用工具、维护上下文。

在视频平台里，一个事件从"疑似"到"确认"再到"处置"，往往需要多步：

1. 理解事件画面（多模态理解）
2. 关联历史（这个摄像头之前有没有类似事件）
3. 关联周边（相邻摄像头同时段有没有异常）
4. 判断严重程度（是否需要立即处置）
5. 生成处置建议（派单给谁、说什么）
6. 记录归档（结构化存储）

这六步如果每步都单独调大模型，成本和延迟都受不了。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 延迟预算怎么分配

一个事件从发生到处置，端到端延迟要控制在可接受范围。我一般这样分配预算：

总延迟控制在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做它擅长的（快、准、专），大模型做它擅长的（理解、推理、泛化），两者协同，才是当前阶段最务实的方案。

另一个体会是：不要追求一步到位。先跑通"边缘小模型检测→中心大模型分析"的最小闭环，哪怕只接几十路视频，验证效果和成本模型，再逐步扩展。我见过太多项目一上来就要接几千路，结果卡在工程细节上，半年都上不了线。

最后分享一个小技巧：在过滤层加一个"事件聚合"逻辑。同一个区域、同一时间段的多路视频事件，先聚合再送大模型。这样大模型看到的是"这个区域发生了什么"，而不是"这一路发生了什么"，理解质量会高很多，调用量也省了。

这套架构不是银弹，它有自己的适用边界。如果你的场景是几十路视频、要求实时性极高、或者场景非常固定，那可能纯小模型就够了，不需要大模型。但如果你的场景是海量视频、需要语义理解、需要开放场景泛化，那大小模型协同就是目前最靠谱的答案。