NVIDIA VSSの全体像を整理してみた

はじめに

こんにちは！クラスメソッド製造ビジネステクノロジー部のtanaka-takeruです。

先日、NVIDIAの VSS（Video Search and Summarization） のBlueprint（NVIDIAが公開しているリファレンス実装）をBrevで起動してみました。今回は改めてVSSの全体像と何ができるのかについて整理してみます。
まず公式ドキュメントのシステム構成を押さえ、そのうえで、VSSが提供する代表的なワークフローの流れをたどっていきます。

この記事でわかること：

• VSSのシステム構成（どんなマイクロサービスで構成され、どう連携するか）
• 5つの代表的なワークフロー（Q&A・長尺要約・アラート検証・リアルタイムアラート・検索）が、それぞれ何をするのか

先に主要な登場人物だけ紹介しておきます。

• VSS（Video Search and Summarization）：動画の検索・要約・Q&A・アラートを自然言語で行うためのブループリント
• LLM（Large Language Model）：文章を読み書きするモデル。VSSの推奨構成ではNemotron系などが使われますが、プロファイルや設定によって変更できます。
• VLM（Vision Language Model）：映像・画像を見て言葉にするモデル。Cosmos Reason系など、VSSが対応するモデルから選択できます。
• NIM（NVIDIA Inference Microservices）：モデルをAPIとして提供するNVIDIAの仕組み。VSSはローカルにデプロイしたNIMだけでなく、設定に応じてリモートの推論エンドポイントも利用できます。

少し長いですが、気になるところだけでもお付き合いいただければ幸いです。

システム構成

まずは公式のシステム構成図から見ていきます。VSSのドキュメントは以下です。

• NVIDIA Video Search and Summarization — Documentation

公式のハイレベルアーキテクチャ図は、次のページで確認できます。

• VSS High Level Architecture（公式）

図からわかることは、VSSは単一のモデルではなく、役割の異なる複数のマイクロサービスの集合体 であることです。公式ドキュメントでは、これらのサービスを大きく3つの領域に分けています。

VSS is organized into three areas of processing and analysis: real-time video intelligence (feature extraction, embeddings, and stream understanding with results published to a message broker), downstream analytics (enrichment of metadata into trajectories, incidents, and verified alerts), and agentic and offline processing (orchestrated tools for search, Q&A, summarization, and clip retrieval, including via the Model Context Protocol).

出典: video-search-and-summarization — README

次の3つの領域に分かれているイメージです。

• ① real-time video intelligence：映像から特徴を抽出する。物体検出（RT-CV）、埋め込み生成（RT-Embedding）、VLMによる解釈（RT-VLM）を担います。
• ② downstream analytics：抽出したメタデータを分析し（Behavior Analytics）、意味のある出来事に加工する。
• ③ agentic and offline processing：レポート・Q&A・検索といったツールを束ね、自然言語の要求を処理する。

この3領域に沿って、図に出てくる主なコンポーネントをまとめます。

表中のモデルやミドルウェアは代表例であり、実際の構成はVSSのバージョン、プロファイル、設定によって変わります。また、Blueprintではこれらが常に全部動いているわけではありません。たとえばbaseプロファイルはQ&Aとレポート生成を扱い、長尺要約はlvsプロファイルが担当します。各プロファイルでは、そのワークフローに不要な検出・埋め込みサービスなどは起動しない設計になっています。

各ワークフローをシーケンス図で整理する

システム構成を概観したところで、ここから何ができるのかを掘り下げていきます。VSSでは、これらの部品を組み合わせたAgent Workflows（エージェント・ワークフロー）を複数用意しています。

We provide multiple reference Agent Workflows which demonstrate how the individual components can be leveraged by an agent:

出典: video-search-and-summarization — README

要約したいのか、アラートを出したいのか、検索したいのかなど、目的によってコンポーネントを組み合わせてワークフローを実現します。

1. Q&A・レポート生成（短尺クリップ）
2. 長尺動画の要約
3. アラート検証
4. リアルタイムアラート
5. 動画検索（alpha）

まずは一番シンプルな、Q&Aとレポート生成から見ていきます。

ワークフロー1：Q&A・レポート生成

先日の記事で動かしてみた流れはこちらに該当します。短い動画を1本アップロードして、「この映像で何が起きていますか」と質問するイメージです。公式のクイックスタートでは、次のように説明されています。

Video retrieval, VLM-based Q&A, and report generation on short video clips

出典: Q&A and Report Generation — VSS Documentation

ユーザの入力がどのように流れていくかを、シーケンス図にまとめてみます。

図に出てくる登場人物を簡単に整理しておきます（以降のシーケンス図でも共通です）。

• VSS Agent UI：ユーザーの窓口（Web UI）
• VSS Agent：要求を受けてどの部品をどの順に呼ぶかを采配する司令塔
• VLM（例：Cosmos Reason）：映像・画像を見て言葉にする
• LLM（例：Nemotron）：文章の読み書き
• VIOS / VST：動画データの管理

映像を見るのはVLM、それを読んで書くのはLLMという役割分担となっており、これがVSSの応答の基本形といえます。

Q&Aではvideo_understandingツールが質問に沿ってVLM分析を行います。レポート生成では専用のプロンプトとテンプレートを用い、VLMの分析結果をMarkdownやPDFに整形します。VLMの呼び出し回数はプロファイルや設定によって変わリます。

※動画の長さとトークンの話

NVIDIAは、標準的なVLMが一度に処理する動画について、通常は1分未満の短いクリップになると説明しています。

Standard VLMs are limited to processing short video clips, usually less than 1 minute, depending on the number of subsampled frames and level of detail required.

「1分」は固定された上限ではなく目安として押さえておくと良いと考えます。後ほど詳しくみていきます。

ワークフロー2：長尺動画の要約

大きな動画データを要約して内容をテキストで出力するワークフローです。動画データを複数のチャンクに分割して処理することが特徴です。

The Video Summarization Workflow enables analysis and summarization of video content without being constrained by the standard VLM context window limitations, allowing for the analysis of long-form video content.

出典: Long Video Summarization — VSS Documentation

流れを図にすると、次のようになります。

まず、長尺動画を、VLMが処理できるchunk_duration秒に刻みます。各チャンクを設定されたVLMが詳しくキャプションし、Video Summarization MicroserviceのCA-RAGが時刻付きイベントとして集約します。その後、設定されたSummarization LLMが全体要約を生成します。VLMとLLMは設定によって差し替えられます。

chunk_duration が重要なパラメータとなります。チャンクを短くすれば、VLMを呼ぶ回数は増えますが、その分こまかく見えます。長くすれば、呼び出し回数は減りますが、各チャンクの中でフレームの間引きが増え、細部を取りこぼしやすくなります。

補足：解像度・fps・動画時間とトークンの関係について
実際にVLMへ渡すサンプリングフレーム数と、各フレームに求める情報の詳しさによってトークンの量が決まります。

現行VSSの一部プロファイルで標準採用されるCosmos3 Nano Reasonerを使う場合の見積もりをご紹介します（VSS全般や他のVLMにそのまま適用できる式ではありません）。
まず、Cosmos3 Nano Reasonerは動画を単純に「静止画の列」として別々にトークン化するのではなく、空間方向の32×32ピクセルと時間方向の2フレームをまとめた単位、すなわち32 × 32 × 2 = 2,048 pixel-frame相当を、1個の視覚トークンへ変換します。

したがって、視覚トークン数はおおむね次のように見積もることができます。

総視覚トークン ≈ サンプリングフレーム数 × 幅 × 高さ / 2,048

ここで重要なのは、元動画の総フレーム数ではなく、前処理後にVLMへ実際に渡されるフレーム数であることです。このフレーム数と、解像度を増やすほど、視覚トークン数と推論コストは増加します。実際の値は、解像度の丸めや前処理にも左右されます。Cosmos3のモデル別APIリファレンスでは、32×32×2のパッチが1マルチモーダルトークンに対応し、16K以下のマルチモーダルトークンで最も良好に動作することが示されています。NVIDIA Cosmos3 Reasoner API

先ほどの式に基づいて、動画として入力した場合の1フレームあたりのトークン数は、おおむね次のようになります。Cosmos3では2フレームを一組として処理するため、単独画像を入力した場合のトークン数とは異なります。

入力解像度	動画1フレームあたりのトークン数
720p（1280×720）	約460
1080p（1920×1080）	約1,020
2048×2048	約2,048

※偶数枚のフレームを仮定しており、32ピクセル単位の端数を切り上げて計算しています。
※2048×2048はここでの計算例であり、入力解像度の上限を示すものではありません。

例えば、1080p相当のフレーム・2fpsを1分の長さでサンプリングし、縮小せずに全120フレームをVLMへ渡すとした時、32×32×2のパッチによって、トークン数は概ね次のようになります。

120 / 2 × 1920 / 32 × 1080 / 32
= 60 × 60 × 34
= 121,500トークン

これは、VSSの性能測定で使われている7,840トークン/推論の構成より約16倍大きな入力です。性能測定では、448×448の80フレームを10秒チャンクとして処理し、1回の推論につき7,840視覚トークンを使用しています。NVIDIA RTVI-VLM Performance

また、ややこしいですが、解像度・fps・時間が常にトレードオフになるわけではありません。VSSには次の2つのフレーム選択方式があります。

• FPS指定モードでは、サンプリングフレーム数 ≈ fps × チャンク時間となるため、解像度・fps・時間のすべてがトークン数に影響します。
• 標準の固定フレーム数モードでは、各チャンクから一定数のフレームを等間隔で取得します。この場合、chunk_durationを長くしてもフレーム数が同じなら、トークン数はほぼ増えません。その代わり、フレーム間隔が広がってしまうため、時間方向の情報が粗くなります。

長尺要約では、このチャンク単位の解析結果を後段で集約する構成になっています。
NVIDIAはGPU利用効率の観点から、Video Summarization Microserviceについて30〜60秒のチャンクを推奨しています。NVIDIA Video Summarization Microservice — Best Practices

ワークフロー3：アラート検証（Alert Verification）

次に、流れ続ける動画データから任意のイベントを検出するタスクです。VLMによる連続推論はGPU負荷が高くなるため、物体検出モデル等とVLMを組み合わせて使います。

Realtime processing of videos using perception (object detection, tracking) and behavior analytics to generate alerts, which are subsequently verified with VLM to reduce false positives

出典: Alert Verification — VSS Documentation

シーケンス図です。

ここでは、RT-CVが設定された推論FPSでストリームを連続処理します。そして、検出結果をルールに照らして怪しいと判断したアラート候補だけをVLMに入力し、それが本当かどうかを確認します。物体検出モデルで広く候補を拾って（見逃しを減らす）、VLMで確認する（誤検知を減らす）。この分業により、GPU負荷の高いVLMの呼び出しを最小限に抑えてストリーミング処理を実現します。

では、拾いたいイベントの決め方についてですが、3つに分けて定義できます。

• 何を検出するか：イベントのキーとなるオブジェクトをテキストで指定します（例：fallen bottle）。Grounding DINOはオープン語彙なので、自然言語で対象を足せます。
• 何が起きたらアラートか：Behavior Analyticsの設定で、例えばあるゾーン侵入した・5個以上存在した・あるゾーンに滞留しているといったルールを書きます。
• 本物かどう確認するか：VLM検証の設定で、確認用のプロンプトを書きます（例：「倒れたボトルが実際に写っているか。yes/noで」）。

ちなみに、このワークフローはライブのRTSP映像が前提ですが、録画済みの動画も使えます。NVStreamerというツールで動画ファイルをRTSPストリームとして入力でき、同じパイプラインを通せます。検証段階では撮影しておいた動画データをバッチで処理して実現性を確認することができます。

ワークフロー4：リアルタイムアラート（Real-Time Alerts）

先述のルールでは表現しにくい異常もあります。例えば「いつもと違う作業」「不安全な姿勢」などぼんやりと言語化したい場合です。こうした場合は、物体検出と固定ルールだけで候補を作るのではなく、VLMが、サンプリングした映像区間を直接評価するReal-Time Alertsが選択肢になります。

Continuous processing of video streams through VLM for anomaly detection

出典: Real-Time Alerts — VSS Documentation

シーケンス図です。

先ほどのアラート検証（ワークフロー3）よりも上流にVLMが配置されており、VLMが直接、連続的に映像を見て異常を判定します。そのぶん、候補区間だけをVLMで検証する構成よりGPU負荷が高くなります。そのため、このプロファイルは、デフォルトで同時処理1ストリームとなっています。
※ただし、これはプロファイルの標準設定とGPU要件に基づく値であり、VSSやRTVI-VLMの原理的な上限ではありません。複数ストリームへの対応可否は、ハードウェア、モデル、入力フレーム数、解像度、デプロイ設定によって変わります。アラート検証はVLMの呼び出しを候補区間に絞れるため、両方式を比較するときは、柔軟にイベントを定義できるメリットと運用可能な計算資源をあわせて見積もる必要があります。

異常の定義は、人間が自然言語で書きます（「PPE未着用の人が入ったら」「箱が倒れたら」など）。VLMに丸投げして異常を勝手に決めさせるのではなく、何を異常とみなすかは人間が言葉で指定し、それが起きたかどうかの判定をVLMが担う、という分担です。

ここは、VLMの得意・不得意を踏まえて書き方を選ぶとよさそうです。私が短いクリップで試した範囲での感覚になりますが、VLMは「◯◯が写っているか」という有無の判定は比較的正確な一方で、「いつもと違うこと全般」のように曖昧に問うと回答がぶれてしまう印象でした。柔軟といえど、ルールは具体的かつ明確な条件で指示して、yes/noで答えられる形に寄せるほど安定しやすい、と考えています（まだ少数データからの考察です）。

ワークフロー5：動画検索（Video Search）※α版

最後は、1本を読むのでも、監視するのでもなく、大量の録画から「あの場面」を探す ワークフローです。まだα版です。

Natural language search across video archives using video embeddings (alpha)

出典: Video Search — VSS Documentation

この検索ワークフローには複数の経路があります。以下はそのうち、Vision Agent ChatからEmbed Searchを実行し、Critic Agentで候補を確認する経路を簡略化した図です。直接検索APIを使う経路や、Attribute Search、Fusion Search、Search by Imageは省略しています。

これまでのQ&Aが「1本を読んで答える」だったのに対し、検索は「複数の動画データから探して並べる」ワークフローです。図で示したEmbed Searchでは、各動画をあらかじめ埋め込み（embedding） でベクトル化して蓄積し、検索クエリも同じ空間のベクトルに変換して近い候補を取得します。

現行のSearch Workflowには、次の4つの検索方法があります。

• Embed Search：動画埋め込みと自然言語クエリの類似度で検索
• Attribute Search：RT-CVが抽出したオブジェクト属性を検索
• Fusion Search：埋め込みと属性の結果を組み合わせて検索
• Search by Image：入力画像に似た場面を検索

検索品質を評価する際は、埋め込み空間の分布とタスクへの適合性を確認する必要があります。特に、出来事の順序、回数、否定条件などは、単純なコサイン類似度だけで判別できるとは限りません。想定する実データを用い、RecallやPrecisionなどで評価することが重要です。

参考として、別途Qwen系モデルを用いた少数の実験では、異なる動画クリップ間の類似度が0.97〜0.99に集中したことがあり、原因の仮説として異方性が考えられました。異方性とは、ベクトルが特定の方向に偏って分布する現象です。
※前処理やプーリング、正規化なども原因の候補であり、異方性と断定できたわけではなく、また、Cosmos-Embed1やVSSの性質を示す結果でもありません。仮説の検証には、多数のサンプルに対する類似度分布や主成分・固有値などの分析が必要です。

現行のSearchプロファイルではCritic Agentがデフォルトで有効になっており、上位候補をVLMで検索条件に照らして確認し、confirmedまたはrejectedを付けます。これは公式に用意された検索精度向上の仕組みです。NVIDIA VSS — Search Workflow

おわりに

VSSのシステム構成から始めて、5つのワークフローをシーケンス図で整理してみました。初めてVSSを見たときには、サービスの多さや特有の概念に迷いましたが、ユースケースとデータの流れでまとめてみると全体像を整理できたと思います。

また、VSSではVLMやLLMの推論エンドポイントを設定でき、対応するローカルNIMやリモートサービスを用途に応じて選択できます。つまり、モデルを差し替えられる設計になっています。

タスクを実現するためにコアとなるコンポーネントはLLM/VLMになってきますので、進め方として

やりたいことを最小十分なタスクに分解
↓
コアであるLLM/VLMで解くことができるかを小さく検証
↓
運用フェーズに合わせてVSSプラットフォームでオーケストレーション

という風に、段階的に検討することで、手戻りなく運用に近づけると感じました。

単一工程の最適化にとどまる場合は、VLM単体の導入で良いかもしれませんが、動画情報を各種製造データの一つとして捉え、ラインや工場単位で横展開して紐付けることに、VSSの真価があるのではと思います。
各ワークフローを実際に動かしながら理解を深めていきたいと思います。