VSS实时VLM微服务详解:vLLM+DeepStream如何实现流式视频理解
VSS实时VLM微服务详解vLLMDeepStream如何实现流式视频理解【免费下载链接】video-search-and-summarizationNVIDIA AI Blueprint for video search and summarization (VSS) is a GPU-accelerated reference architecture for building video analytics agents with real-time verified alerts, visual QA, and automated reporting. The VSS Blueprint uses vision language models (VLMs) such as NVIDIA Cosmos, LLMs such as NVIDIA Nemotron, RAG, and NVIDIA NIMs.项目地址: https://gitcode.com/GitHub_Trending/vi/video-search-and-summarizationVSSVideo Search and Summarization是 NVIDIA 开源的 GPU 加速视频智能分析蓝图其中的**实时 VLM 微服务RTVI-VLM**负责流式视频理解它用 DeepStream 加速管线接收 RTSP 实时视频流结合 vLLM 推理引擎运行视觉语言模型VLM将摄像头画面实时转成文字描述、异常告警Incident并通过 Kafka 推送给下游告警与报表系统。本文带你快速理解这套视频→文字流式管线的工作原理、架构设计与部署要点。为什么实时视频理解这么难传统做法是把整段视频下载下来再处理但监控、仓储、城市安防等场景需要的是秒级响应画面刚发生异常告警就要立刻触发。这要求系统同时解决三个问题低延迟解码摄像头 RTSP 流必须实时、高效解码且多个业务请求共享同一路解码避免 GPU 浪费视频切块与抽帧长视频要切成带重叠的短视频块chunk按合理帧率采样后再送模型平衡精度与吞吐高吞吐推理视觉语言模型参数大、推理慢必须依赖 vLLM 这类支持连续批处理continuous batching和 KV Cache 复用的高性能推理引擎。RTVI-VLM 正是针对这三个问题给出的工程化答案。架构拆解DeepStream 加速管线五个阶段RTVI-VLM 的核心是一条基于 GStreamer/DeepStream 的加速管线源码见 vlm_pipeline.py处理流程分为五个阶段阶段职责RTSP Decode接收并硬解码摄像头流同一 RTSP 流的多个字幕请求若解码参数一致可共享同一条解码管线Mux将多路流多路复用统一送入后续处理Video Segment Creation按chunk_duration/chunk_overlap_duration把流切成带重叠的视频块例如 60 秒一块、10 秒重叠InfervLLM帧采样后送入 vLLM 引擎运行 Cosmos、Nemotron Omni 等 VLM 模型生成描述MsgBrokerNvSchema将结果以 NvSchema Protobuf 格式发布到 Kafka / MQTT / Redis对外由一个 FastAPI REST 服务rtvi_vlm_server.py统一封装核心端点包括POST /v1/streams/add注册 RTSP 实时流POST /v1/generate_captions发起字幕/告警生成支持streamtrue以 **SSEServer-Sent Events**流式返回每一块的生成结果POST /v1/chat/completionsOpenAI 兼容接口方便现有 LLM 客户端直接调用。多个客户端可以对同一路实时流并发提问每个请求拥有独立的 prompt 与 SSE 输出流而底层只跑一份解码管线这就是共享 RTSP 解码带来的效率提升。vLLM 推理引擎与支持的模型RTVI-VLM 的推理内核是 vLLM。仓库为它做了大量适配vllm_compatible_model.py 以及 docker/rtvi_vlm/patches/ 下的运行时补丁包括多模态编码器缓存、张量 IPC 传递、Qwen 系列视觉注意力优化等保证视频帧输入下的批处理效率。通过VLM_MODEL_TO_USEMODEL_PATH两个变量即可切换模型来源支持本地 vLLM 兼容权重、NGC 模型构件和远程 OpenAI 兼容端点模型家族示例加载方式Cosmos Reason2 / Reason3默认Cosmos3 Nano Reasoner (bf16)ngc:nim/nvidia/cosmos3-nano-reasoner:bf16-finalNemotron OmniNemotron-3-Nano-Omni-30B-A3B-Reasoning(-FP8)git:Hugging Face 地址需VLM_TRUST_REMOTE_CODEtrueQwen VL / OmniQwen3-VL-30B-A3B-Instruct、Qwen3-Omnigit:Hugging Face 地址Omni 类模型还支持原生音频理解VLM_MODEL_SUPPORTS_AUDIOtrue即画面与声音一起交给模型分析。完整模型清单与 GPU 适配说明见官方文档 docs/real-time-vlm.mdx。三步部署 RTVI-VLM 服务 服务以容器镜像交付已验证支持 H100、L40S、RTX PRO 6000 Blackwell、DGX Spark、Jetson AGX Thor 等平台。以最简单的 Docker Compose 方式部署为例克隆仓库并进入服务目录git clone https://gitcode.com/GitHub_Trending/vi/video-search-and-summarization cd video-search-and-summarization/services/rtvi/rt-vlm/docker创建.env至少配置端口、镜像、模型与消息总线BACKEND_PORT8000 RTVI_IMAGEnvcr.io/nvstaging/vss-core/vss-rt-vlm:3.3.0-26.08.1 VLM_MODEL_TO_USEcosmos-reason3 MODEL_PATHngc:nim/nvidia/cosmos3-nano-reasoner:bf16-final MESSAGE_BUSkafka MESSAGE_BUS_TOPICmdx-vlm-captions NGC_API_KEYnvapi-XXXXXX启动并验证docker compose up # 交互式 API 文档 curl http://localhost:8000/docsCompose 编排文件位于 services/rtvi/rt-vlm/docker/compose.yaml会自动带起 RTVI-VLM、Kafka、Redis 三个容器。Kubernetes 用户可直接使用独立 Helm Chart deploy/helm/services/rtvi/charts/rtvi-vlm。更详细的部署与排障步骤见 services/rtvi/rt-vlm/README.md。内存不足调低VLLM_GPU_MEMORY_UTILIZATION、减小VLM_MAX_MODEL_LEN或用NVIDIA_VISIBLE_DEVICESgpuid指定空闲 GPU。流式输出与告警Kafka 里的三类消息这是 RTVI-VLM 最有价值的部分——推理结果不只返回给 API 调用方还以NvSchema Protobuf 消息持续发布到消息总线供告警服务、行为分析等下游微服务消费Topic默认值内容mdx-vlm-captions每个视频块完成推理后发出的 VisionLLM 字幕消息含描述文本、帧时间戳、传感器信息mdx-vlm-incidents仅在检测到异常时发出的 Incident 告警消息mdx-vlm-errors流处理失败时的错误事件告警触发逻辑很直接在 prompt 中要求模型输出结构化 Yes/No 判断例如是否有工人未佩戴安全帽Anomaly Detected: Yes/No服务解析出肯定答复后即向 Incident Topic 发布告警并附带sensorId、时间区间、category、模型推理说明reasoning等字段。这样视频流就变成了事件流正是 VSS 实现**实时验证告警real-time verified alerts**的关键一环。关键调优参数速查生产环境建议关注以下环境变量完整清单见 docs/real-time-vlm.mdx 配置章节VLLM_GPU_MEMORY_UTILIZATIONvLLM 可占用的显存比例OOM 时首选调整项VLLM_MAX_NUM_SEQS/VLLM_MAX_NUM_BATCHED_TOKENS批内并发序列数与批处理 token 上限决定推理吞吐VLLM_MM_PROCESSOR_VIDEO_NUM_FRAMES单次送入多模态处理器的最大帧数默认 256VLLM_ENABLE_PREFIX_CACHING前缀缓存多路请求共享同一 system prompt 时可显著省算力VLM_DEFAULT_NUM_FRAMES_PER_SECOND_OR_FIXED_FRAMES_CHUNK每块抽帧策略默认 30直接影响延迟/精度平衡VLM_INPUT_WIDTH/VLM_INPUT_HEIGHT送入模型的帧分辨率分辨率越高精度越好但推理越慢。服务还内置健康探针/v1/live、/v1/ready与 Prometheus 指标端点/v1/metrics可无缝接入 VSS 的可观测性体系。小结RTVI-VLM 展示了DeepStream 负责快速解码分段 vLLM 负责高吞吐推理 Kafka 负责事件分发的经典 GPU 视频 AI 架构DeepStream 管线解决实时解码与共享复用的问题让多业务并发时 GPU 不浪费vLLM 引擎通过批处理与前缀缓存把大参数 VLM 的推理成本压到可实时化的水平NvSchema Kafka把视频理解结果变成标准化事件流与 VSS 的告警、报表、检索微服务无缝衔接。想动手实践从 services/rtvi/rt-vlm/ 目录入手配合上面的三步部署即可跑通第一路实时视频理解再结合 VSS 仓库中的告警服务与 Agent 工作流就能搭出一套完整的视频智能分析系统。【免费下载链接】video-search-and-summarizationNVIDIA AI Blueprint for video search and summarization (VSS) is a GPU-accelerated reference architecture for building video analytics agents with real-time verified alerts, visual QA, and automated reporting. The VSS Blueprint uses vision language models (VLMs) such as NVIDIA Cosmos, LLMs such as NVIDIA Nemotron, RAG, and NVIDIA NIMs.项目地址: https://gitcode.com/GitHub_Trending/vi/video-search-and-summarization创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考