企业官网建设流程全解析

1. 视频联网平台为什么不能把每一路视频都丢给大模型

1.1 从一次真实的平台告警说起

去年帮一个园区做视频联网平台的智能化升级，客户提的需求很直接：园区里已经接入了两千多路摄像头，想上大模型做全场景理解，什么打架斗殴、烟火检测、人员聚集、车辆违停，最好一个模型全包了。听起来很美好，但我拿到需求的第一反应是——先算一笔账。

两千路视频，假设每路按 5 帧每秒抽帧送进大模型做推理，那就是每秒一万次推理请求。就算用上目前比较能打的视觉大模型，单张图片推理延迟按 500 毫秒算，单卡并发撑死也就几十路。要覆盖两千路，光 GPU 就得堆几十张卡，这还没算上视频解码、网络传输、结果回传的开销。客户听完这个账，沉默了几秒，问了一句特别实在的话：“那我这平台到底是做视频联网的，还是做大模型推理集群的？”

这个问题其实点到了要害。视频联网平台的核心价值在于“联网”二字——把分散在不同区域、不同厂商、不同协议的摄像头统一接入、统一管理、统一调度。它的本质是一个流媒体分发与设备管理平台，而不是一个 AI 推理平台。如果硬要把大模型塞进这个链路里，让它去盯每一路视频，结果就是平台被拖垮，大模型也被用废。

1.2 大模型在视频场景里的三个“水土不服”

大模型不是万能钥匙，它在视频联网场景里有三个天然的短板，我在实际项目里都踩过。

第一个是算力成本与并发能力的矛盾。大模型的参数量摆在那里，推理一次消耗的显存和算力是传统小模型的几十倍甚至上百倍。视频联网平台动辄几百上千路，这种量级下，全量接入大模型在经济上根本不成立。我见过有团队试图用模型量化、蒸馏来压成本，效果确实有，但压到能覆盖千路级别时，精度已经掉得没法看了。

第二个是实时性与准确率的取舍。视频监控场景对实时性要求很高，尤其是周界入侵、烟火检测这类，延迟超过两三秒基本就失去意义了。大模型推理链路长，从解码、预处理、推理到后处理，端到端延迟很难压到秒级以内。而传统小模型在边缘端跑，几十毫秒就能出结果，这个差距在实战里是致命的。

第三个是场景泛化与误报率的平衡。大模型的优势在于泛化能力强，能理解开放场景，但这也意味着它在特定场景下的误报率可能比专门训练的小模型高。比如一个训练好的烟火检测小模型，在特定园区环境下误报率可以压到很低，但换成通用大模型，它可能会把夕阳、红色广告牌都识别成火情。这种误报在安防场景里是灾难性的，保安一天被折腾几十次，系统就没人用了。

1.3 大小模型协同的核心思路：让合适的模型干合适的活

那是不是大模型在视频联网平台里就没用了？当然不是。关键在于分工。

我后来给那个园区设计的方案，核心思路就一句话：小模型负责“盯”，大模型负责“想”。小模型部署在边缘端或者中心推理服务器上，以高频率、低延迟的方式对每一路视频做初步筛查，只把“有嫌疑”的片段和图片推给大模型做二次研判。大模型不需要盯每一路视频，它只需要处理小模型筛选出来的那百分之几甚至千分之几的“可疑事件”。

这个思路听起来简单，但落地时有很多细节要抠。比如小模型怎么选、阈值怎么定、推给大模型的素材怎么组织、大模型返回的结果怎么和原视频流关联、整个链路的延迟怎么控制。这些问题我在后面会逐一拆开讲。

提示：大小模型协同不是简单的“小模型筛一遍、大模型再看一遍”，而是一套完整的事件驱动架构。小模型是触发器，大模型是决策器，中间还需要一个可靠的调度层来管理事件队列、优先级和回压。

2. 大小模型协同的架构设计与关键选型

2.1 整体架构：三层分工，各司其职

我最终落地的架构分三层，从下到上分别是边缘感知层、事件调度层、大模型研判层。

边缘感知层部署在园区机房或者靠近摄像头的边缘服务器上，跑的是轻量级的小模型，比如 YOLO 系列、MobileNet 系列，或者专门训练的场景模型。这一层的任务是全量覆盖——每一路视频都要过，不能漏。小模型的推理频率可以根据场景调整，一般周界类场景 5 到 10 帧每秒就够了，交通类场景可能需要 15 帧以上。

事件调度层是整个架构的“中枢神经”。它接收小模型输出的告警事件，做去重、聚合、优先级排序，然后决定哪些事件推给大模型、哪些直接落库、哪些丢弃。这一层还负责背压控制——当大模型处理不过来时，要能自动降低推送频率或者只推高优先级事件，避免队列无限堆积。

大模型研判层就是真正调用大模型的地方。这里的大模型可以是云端 API，也可以是私有化部署的视觉大模型。它接收的是事件调度层整理好的事件包，里面包含关键帧图片、短视频片段、小模型的初步判断结果、摄像头位置信息等。大模型的任务是做二次确认和语义理解，比如判断“这个烟雾是炊烟还是火情”“这个聚集是正常排队还是异常聚集”。

2.2 小模型选型：别追求 SOTA，追求“稳”和“省”

小模型选型这块，我踩过最大的坑就是盲目追新。一开始用了某个刚出的检测模型，论文指标很漂亮，但实际部署时发现对硬件要求高、推理框架兼容性差，折腾了两周才跑通，结果精度还不如之前用的老模型稳定。

后来我总结了一个选型原则：在满足精度要求的前提下，优先选推理速度快、硬件兼容性好、社区活跃的模型。具体来说，检测类任务 YOLOv5/v8 的 n/s 版本是稳妥选择，分类任务 MobileNetV3 或者 EfficientNet-Lite 够用，分割任务如果边缘端跑不动，可以考虑用轻量级分割模型或者干脆用检测框代替。

还有一个关键点是模型量化。边缘端设备算力有限，FP32 推理往往跑不动，需要转成 FP16 或者 INT8。量化会带来精度损失，但通过校准集调优，一般能把损失控制在可接受范围内。我的经验是，INT8 量化后精度掉 1 到 2 个百分点是正常的，如果掉超过 5 个点，要么是校准集没选好，要么是这个模型本身不适合量化。

2.3 大模型选型：视觉理解能力是硬指标

大模型这块，选型逻辑和小模型完全不同。小模型看的是速度和成本，大模型看的是理解能力和输出稳定性。

视频联网场景里，大模型主要做几类任务：场景描述（“画面里发生了什么”）、事件确认（“这是不是真的火情”）、行为分析（“这个人的行为是否异常”）、多图关联（“这两个摄像头拍到的是不是同一个人”）。这些任务对模型的视觉理解能力要求很高，不是随便一个文本大模型加个视觉编码器就能搞定的。

我实测下来，目前视觉理解能力比较强的大模型，在烟火确认、人员聚集判断这类任务上，准确率能到 90% 以上，但前提是提示词要设计好。比如判断烟火，不能只问“画面里有没有火”，要问“画面中是否有明火或浓烟，注意区分夕阳、红色灯光、炊烟等干扰因素”。提示词的质量直接决定大模型的输出质量，这块后面会专门讲。

另外，大模型的输出格式稳定性也很重要。有些模型返回的是自由文本，解析起来很麻烦；有些模型支持 JSON 模式输出，那就省事很多。选型时一定要确认模型是否支持结构化输出，这能省掉大量后处理代码。

2.4 边缘计算与中心调度的分工边界

边缘计算在大小模型协同里扮演什么角色？我的理解是：边缘负责“快”，中心负责“准”。

边缘端部署小模型，优势是延迟低、带宽省、隐私好。视频流不用全部回传中心，只在边缘做初步分析，只把可疑片段传上去。但边缘端的算力有限，跑不了大模型，所以复杂研判还得靠中心。

中心端部署大模型，优势是算力强、模型大、能力强。但中心端不能直接接摄像头，那样带宽和延迟都受不了。所以中心端只接收边缘端筛选后的事件包，处理完再把结果回写。

这个分工边界怎么定？我的经验是看事件密度。如果一个园区每天小模型产生的告警事件在几百条以内，中心端大模型完全处理得过来；如果每天几万条，那就需要在边缘端做更激进的过滤，或者在大模型前面再加一层轻量级分类模型做二次筛选。

3. 实操落地：从事件产生到大模型研判的完整链路

3.1 小模型侧：如何配置推理频率和告警阈值

小模型的推理频率和告警阈值是两个最关键的参数，直接决定了整个系统的灵敏度和负载。

推理频率方面，我的经验值是：周界入侵类场景 5 到 8 帧每秒，烟火检测类 3 到 5 帧每秒，人员聚集类 1 到 2 帧每秒就够了。为什么这么定？因为周界入侵需要捕捉快速移动的目标，帧率太低会漏检；烟火是缓变事件，不需要太高帧率；人员聚集变化更慢，低频抽帧完全够用。

告警阈值方面，不能设得太低，否则误报爆炸；也不能设太高，否则漏报。我的做法是先设一个保守阈值，跑一周，统计误报和漏报情况，再逐步调整。比如烟火检测，初始置信度阈值设 0.7，跑一周发现误报主要来自夕阳和红色广告牌，那就针对性地补充负样本重新训练，或者把阈值提到 0.8，同时增加“连续多帧检测到才告警”的逻辑。

这里有个细节：告警去重。同一个事件在连续多帧里都会被检测到，如果每帧都推一条告警，大模型会被淹没。我的做法是在边缘端做事件聚合——同一个摄像头、同一个目标、时间窗口内（比如 10 秒）的多次检测合并成一个事件，只推一次。

3.2 事件调度层：队列管理与背压控制

事件调度层是很多人容易忽略的一层，但它其实是整个协同架构的“保险丝”。

我用的方案是基于消息队列做事件缓冲，RabbitMQ 或者 Kafka 都可以。小模型产生的告警事件先入队，调度器从队列里取事件，按优先级排序后推给大模型。优先级怎么定？我的规则是：烟火、入侵等高危事件优先，聚集、违停等低危事件次之；同一摄像头短时间内重复事件合并；超过一定时间未处理的事件自动降级或丢弃。

背压控制是调度层的核心功能。当大模型处理速度跟不上事件产生速度时，队列会堆积。这时候调度层要能自动降级——比如只推高危事件、降低推送频率、或者直接丢弃低优先级事件。我一般会设一个队列水位线，比如队列长度超过 1000 就触发降级，超过 5000 就只保留高危事件。

还有一个实战技巧：给大模型调用加超时和重试。大模型 API 偶尔会超时或者返回异常，如果不做处理，事件就丢了。我的做法是设置 3 秒超时，超时后重试一次，重试还失败就落库标记为“待人工复核”，不让事件无声无息地消失。

3.3 大模型侧：提示词设计与输出解析

大模型研判的效果，七分靠提示词，三分靠模型本身。我在烟火确认这个任务上前后改了十几版提示词，最终稳定下来的版本大概是这样的：

你是一个安防视频分析助手。请分析提供的图片，判断画面中是否存在真实的烟火事件。 注意区分以下干扰因素： - 夕阳或朝霞造成的红色天空 - 红色广告牌、红色车辆、红色衣物 - 炊烟、蒸汽、雾霾 - 灯光反射 请按以下 JSON 格式输出： { "has_fire": true/false, "has_smoke": true/false, "confidence": 0.0-1.0, "reason": "简要说明判断依据", "interference": "如果存在干扰因素，说明是什么" }

这个提示词的关键点有三个：明确任务边界、列出干扰因素、强制结构化输出。实测下来，加了干扰因素说明后，误报率能降一半以上。

输出解析这块，一定要做容错处理。大模型有时候会返回不完整的 JSON，或者多输出一段解释文字。我的做法是用正则先提取 JSON 部分，解析失败就降级为关键词匹配，再失败就标记为“解析异常”转人工。不要假设大模型每次都返回完美格式，那是理想情况，不是工程现实。

3.4 结果回写与视频流关联

大模型研判完的结果，需要回写到视频联网平台，和原视频流关联起来。这块的难点在于事件溯源——怎么知道这个大模型结果对应的是哪一路视频、哪个时间段。

我的做法是在事件包里带上完整的溯源信息：摄像头 ID、通道号、事件开始时间、事件结束时间、关键帧时间戳、小模型告警 ID。大模型返回结果后，调度层根据这些信息把结果写回数据库，同时触发平台侧的告警联动——比如弹窗、录像标记、通知推送。

这里有个坑：时间同步。边缘端和中心端的时间如果不一致，事件关联就会错乱。我吃过这个亏，后来在所有边缘节点上都配了 NTP 同步，误差控制在 100 毫秒以内，问题就解决了。

4. 实战中踩过的坑与排查技巧

4.1 小模型误报太多，大模型被淹没

这是最常见的问题。小模型阈值设低了，误报率飙升，大模型每天要处理几千条无效事件，成本高不说，真正的高危事件还可能被淹没。

排查思路：先看误报的类型分布。如果误报集中在某几类干扰源（比如夕阳、灯光），那就针对性补充负样本重新训练小模型；如果误报分散、没有明显规律，那可能是阈值设得太低，适当提高阈值，同时增加“连续多帧确认”逻辑。

我的经验值是：小模型的误报率控制在 5% 以内，大模型的负载就是可控的。如果小模型误报率超过 10%，整个协同架构的经济性就不成立了。

4.2 大模型返回结果不稳定，同一张图两次判断不一致

大模型的输出确实存在随机性，同一张图两次调用可能给出不同结果。这在安防场景里是不能接受的。

解决办法有两个：一是降低温度参数，把 temperature 设到 0 或者 0.1，让输出尽量确定；二是多次调用投票，对同一个事件调三次大模型，取多数结果。第一种方法成本低，但有些模型即使 temperature 为 0 也有随机性；第二种方法成本高，但结果更稳。我一般对高危事件用投票，低危事件用低温单次调用。

4.3 边缘端设备算力不足，小模型跑不动

边缘端设备五花八门，有的用 Jetson，有的用 RK3588，有的就是普通 x86 服务器。算力差异很大，同一个模型在不同设备上的表现可能差好几倍。

我的做法是按设备能力分级部署。高算力设备跑完整版小模型，中等算力设备跑量化版，低算力设备只跑轻量级检测或者干脆只做视频转发。不要指望一个模型适配所有设备，那是自找麻烦。

4.4 常见问题速查表

提示：这张表是我在实际运维中总结的，建议打印出来贴在工位上。大部分问题都能在这张表里找到对应方案，剩下的就是细节调优了。

4.5 一个容易被忽略的细节：大模型调用的成本控制

大模型 API 是按 token 或者按次收费的，如果小模型误报多，大模型调用量就大，成本会失控。我见过一个项目，上线第一个月大模型调用费用超预算三倍，就是因为小模型误报没控制好。

控制成本的手段有几个：提高小模型精度（最根本）、增加事件去重和聚合（减少无效调用）、对大模型调用做限流（防止突发流量）、低危事件用便宜模型、高危事件用贵模型（分级调用）。这几个手段组合起来，成本能压到原来的三分之一左右。

5. 这套方案适合什么场景，不适合什么场景

5.1 适合的场景：事件稀疏、精度要求高、成本敏感

大小模型协同这套架构，最适合的是事件稀疏但精度要求高的场景。比如园区安防、森林防火、工地安全监测，这些场景里异常事件是少数，大部分时间画面是正常的。小模型全量筛查，只把异常推给大模型，大模型的负载就很低，成本可控，精度也有保障。

另一个适合的场景是成本敏感的项目。如果预算有限，不可能堆几十张 GPU 卡做大模型全量推理，那大小模型协同就是唯一可行的方案。用少量算力跑小模型做全量覆盖，用少量大模型调用做精准研判，整体成本能控制在合理范围内。

5.2 不适合的场景：事件密集、实时性要求极高

反过来，如果场景里异常事件非常密集，比如交通流量检测这种每时每刻都有大量目标需要识别的场景，小模型筛完还是有很多事件要推给大模型，那大模型就成了瓶颈，这套架构就不适用了。这种场景更适合用专门训练的小模型直接做端到端处理，不需要大模型介入。

实时性要求极高的场景也不适合。比如某些工业检测场景要求毫秒级响应，大模型推理链路根本达不到这个速度。这种场景只能用边缘端小模型，大模型最多做离线分析和模型迭代。

5.3 扩展方向：从单点协同到多级协同

这套架构还可以进一步扩展。比如在边缘端和大模型之间再加一层区域级小模型集群，做更精细的二次筛选；或者把大模型的能力下沉，用蒸馏后的小模型在边缘端做部分研判，进一步降低中心端负载。

还有一个方向是多模态融合。现在的大模型主要是视觉理解，未来可以结合音频、雷达、红外等多模态数据，让大模型做更全面的研判。比如烟火检测，结合红外热成像数据，准确率能再上一个台阶。

我个人在实际操作中的体会是，大小模型协同不是一劳永逸的方案，而是一个需要持续调优的过程。小模型的阈值、大模型的提示词、调度层的策略，都需要根据实际运行数据不断调整。上线只是开始，真正的功夫在运维和迭代上。