基于视频识别的大模型项目实战心得
基于视频识别的大模型项目实战心得：从流媒体、模型调用到系统环境的完整经验总结
最近我们接到一个基于视频识别的 AI 项目，核心目标是：对实时视频画面进行描述分析，用于实现一个可交互的展示效果。
这类项目本身并不稀奇，但将“流媒体处理 + 大模型视觉理解 + 基础图像识别 + 展示框架”串成完整链路后，确实值得做一些经验总结:
一、系统是怎么拆解的？
项目整体我拆成三部分：
1. 流媒体采集（抽帧）
实时视频通常采用抽帧方式进行处理：
- 固定 FPS 抽帧（如 1～10 FPS）
- 或基于运动检测的动态抽帧
- 或直接抽 I 帧（关键帧）
抽到的帧图像会放入消息队列（Kafka/RabbitMQ/Redis Stream 都可以）。
2. AI 分析模块（模型调用）
分析模块订阅抽帧队列，对每一帧调用视觉大模型，生成描述信息。
分析结果再写入“展示队列”，供前端交互环境消费。
3. 展示模块
只负责消费结果队列，展示画面与结构化信息，实现现场可交互效果。
这套流程最大的优点就是解耦：
流媒体、模型推理、展示互不阻塞，性能与稳定性更好。
二、大模型视觉能力：必须注意的几点
这次我们用的是 Qwen3-VL 7B 模型，运行在 4090 24G 显卡 上。
它确实能理解画面，但实际落地时，我们总结了几个非常关键的注意点。
1. Prompt（提示词）一定要可动态配置
提示词不是“一劳永逸”的，它本质是告诉大模型“我到底想让你怎么理解”。
在不同场景下，需要不断迭代优化。
因此：
提示词必须做成动态配置，而不是写死在代码里。
2. 大模型存在幻觉，必须做内容过滤
幻觉不是缺陷，而是模型机制本身决定的。
比如：
- 明明画面里有 4 个人，它说 5 个
- 明明衣服是蓝色，它说成黑色
- 明明没有文字，它却描述出不存在的字幕
所以我们在生产环境必须做：
- 基于规则的过滤
- 基于轻量模型的二次校验
- 或构建黑白名单逻辑
否则大模型说什么你就信什么，迟早“翻车”。
3. 大模型 ≠ 精准识别工具，需要传统算法辅助
这一点特别重要。
即便是 4090 + Qwen3-VL-7B，有些任务大模型仍不可靠：
- 人数统计容易偏差
- 衣服颜色判断容易飘
- 边缘目标识别能力弱
- 遮挡、光照变化会严重影响模型表现
原因不是算力不够，而是：
7B 级别的大模型本身不是为精准视觉识别设计的。
所以最佳实践是：
大模型负责“理解”，传统模型负责“看清”。
我们在项目中采用了组合拳：
- OpenCV：抽帧图像质量检测（模糊、曝光等）
- YOLOv8：做基础物体/人数检测，给大模型辅助信息
- 大模型：输出自然语言表达、复杂语义理解
最终效果比裸用大模型好了一个量级。
三、环境部署经验：Ubuntu 更稳，Windows 有坑
现在大模型部署普遍采用 vLLM 的 OpenAI API 模式，用起来确实方便。不过，我们在 Ubuntu 和 Windows 上都试过，经验很明确：
1. 用 Ubuntu：基本一路顺畅
Linux 对 GPU 驱动、vLLM、Pytorch 的兼容是业界事实标准，问题最少，性能最佳。
强烈推荐生产环境一律上 Ubuntu。
2. 用 Windows：在 WSL + Docker 下要注意显卡透传
如果你非要在 Windows 上跑大模型，那以下几点特别重要：
① WSL 的 NVIDIA 驱动兼容性有限
主要表现为：
- 某些版本识别不到 GPU
- GPU 信息不完整
- 训练推理性能下降
② Docker Desktop 通常只透传默认 GPU（0 号 GPU）
即便你在 docker run 中写了：
--gpus '"device=1"'
在多数 Windows + WSL 环境下，这个配置会不生效。
最终表现就是：
- Windows 下 Docker 实际只能使用第一张 GPU
- 多 GPU 调度困难甚至失效
这不是理论，是我们踩坑后的真实经验。
四、总结：大模型要落地，必须“组合拳”
大模型不是万能的，它像一个聪明的大脑，但眼睛未必够好。
要在视频 AI 项目中做出可靠效果，通常需要三种力量协同：
- 传统视觉算法（OpenCV） —— 保证图像质量
- 目标检测（YOLO 类） —— 保证看清画面
- 大模型（Qwen3-VL 等） —— 负责理解与表达
再加上：
- 合理的系统拆解
- 健壮的信息队列
- 正确的部署环境
最终才能做出一个真正稳定、可靠、可展示的 AI 视频系统。