コンテンツにスキップ

NVR/VMS デモの人物検索

Search タブには、幅を変更できる左側の条件パネルと、右側の共通の結果カードがあります。パネルの初期幅は 320 ピクセルです。3 つのモードがあります。

  • Image search は、Live のシングルビューでライブ、一時停止中のライブ、録画の映像上で領域をドラッグすると自動的に開きます。選択した切り抜きが左側に表示され、すぐに検索が始まります。
  • Text search は初期モードです。編集が 350 ms 止まった後、または Enter を押した時点で検索します。日本語 IME の変換中の文字列は、確定するまで送信しません。
  • Person search には、年齢層、肌の色、髪の色、上下の服の種類と色、眼鏡、バッグの種類のチェックボックスがあります。各カテゴリでチェックできる値は最大 1 つで、もう一度クリックするとその条件を外します。変更するとすぐに検索します。Clear conditions はすべての選択を外します。

人物の条件からは英語の説明文を生成して画面に表示し、既存のテキスト埋め込みによる検索を使います。検索で見つかるのは外見が似た人物で、属性の厳密な一致や、確認済みの年齢/肌の色ではありません。属性の分類器や、収集時の追加の推論は使いません。条件はモードを切り替えても個別に保持されますが、アプリケーションを再起動すると保持されません。テキストや人物の条件が空の場合は、クエリを送信せずに結果を消去します。

クエリを更新すると、新しい結果が届くまで直前の結果を表示したままにします。モードを変更すると結果を消去します。置き換えられた要求やサムネイルの読み込みが、新しい結果を更新することはありません。各カードには、カメラ、タイムスタンプ、コサイン類似度、最大 4 枚のサムネイル、一致したすべての画像の選択欄を表示します。Play nearby video はカード内でその場面を再生し、一時停止とシークの操作ができます。同時に再生できるカードは 1 枚だけです。結果が置き換わると再生を停止し、Search を離れると保留中の検索とデバウンスのタイマーも取り消します。録画を削除すると結果は無効になります。

AI Statistics タブには、完了した各段階の処理時間と、カメラごとの更新頻度が表示されます。検出/トラッキングの既定値はカメラごとに 2 Hz です。収集では人物ごとに 5 秒に 1 回埋め込みを要求し、負荷が高いと頻度を下げます。モデルの選択、上限付きのキュー、優先度、ベンチマークのコマンドについては、AI の性能と 16 カメラ構成 を参照してください。これはサンプリングによるベストエフォートの索引付けで、既存の録画を遡って処理することはありません。

埋め込みモデルの選択

AI Statistics で、EmbeddingGemma 2 (GPU)、MobileCLIP2-S2 (GPU FP16)、MobileCLIP2-S2 (NPU BF16)、MobileCLIP2-S2 (GPU + NPU) のいずれかを選びます。選択は次回のアプリケーション起動時に反映されます。それまでは、現在実行中のモデルとその検索結果が有効なままです。デスクトップの既存の起動時のポリシーにより、古い録画とその検索データは消去されます。選択時に履歴の埋め込みを再計算することはありません。

MobileCLIP2は、このリポジトリの共通ネイティブランタイムを使い、NVRと同一プロセスで実行します。AMDVA_BUILD_MOBILECLIP=ONでビルドし、GPUデバイス入出力用のプロファイルを準備して、Ryzen AIの環境を読み込んでから起動します。手順はMobileCLIPサンプルを参照してください。既存のEmbeddingGemmaのlibraryとbundleに加えて、次を設定します。

"embedding_model": "mobileclip2-s2",
"mobileclip_backend": "gpu+npu",
"mobileclip_bundle": "/path/to/mobileclip-device",
"embedding_batch": 4

embedding_modelの既定値はembeddinggemma2です。mobileclip_backendはgpu、npu、両方で収集するgpu+npuから選びます。旧設定のmobileclip_libraryとmobileclip_workerは読み込めますが、実行には使いません。examples/nvr/scripts/run.sh CONFIG.jsonで起動すると、ryzen_ai_venv、AMDVA_RYZEN_AI_VENV、VIRTUAL_ENVからRyzen AI環境を選び、旧Torchライブラリのパスを除いてからHIP/ORTを起動します。MobileCLIPのワーカーや画像IPCはありません。ビルド機能、依存ライブラリ、準備済みプロファイルが足りない場合はエラーとし、自動で別のバックエンドへ切り替えません。

両方のバックエンドでGPU前処理を使い、従来のPillow互換のレターボックスとバイリニア補間を再現します。GPU上のRGBクロップ画像を保持し、サムネイル用のCPU読み戻しとは分離します。GPUはデバイス入出力のFP16 MIGraphXプロファイルを使います。NPUでは、HIP共有ホストメモリへGPUが直接入力を書き、その領域を参照するORTのCPUテンソルをVitis AI EPへ渡します。コピーなしの検証範囲はEPの入口までです。EP内部のコピーや変換は監査対象に含めません。

NPUの前処理は専用のnonblocking HIPストリームを使います。CPUから渡した検索画像だけは入口で一度アップロードします。GPUは1〜4枚に対応し、2〜3枚は4枚へパディングします。NPUは1枚です。embedding_batchはGPUの希望バッチ数として1または4を指定します。テキストはCPUエンコーダーと77トークンのトークナイザーを使い、EmbeddingGemma用のプロンプトは付けません。EmbeddingGemmaの縦長プロファイルは維持します。

MobileCLIP は 512 次元のベクトルを返します。これを既存の 768 個の float の格納形式にゼロで拡張するため、カタログを移行せずにコサイン類似度を保てます。同一プロセス入力のバージョン、モデルのマニフェスト、バックエンド、切り抜きの上限によって、別個の検索空間を識別します。各クエリベクトルは、モデルと画像バックエンドが一致する記録とだけ比較します。GPU FP16 と NPU BF16 の結果は異なることがあり、日本語の検索精度もモデルの系統によって異なります。ReID の特徴量は独立したままです。gpu+npu モードでは、GPU と NPU が共有の上限付きキューから独立して処理を取り出します。NPU は対象となる切り抜きを 1 つ、GPU は最大 embedding_batch（1 または 4）個を取り出します。どちらも、もう一方のデバイスやバッチが埋まるのを待ちません。NPU に空きがあれば NPU を優先し、同じ人物を両方のデバイスで同時に処理することはありません。各切り抜きは、実際にエンコードしたバックエンドのフィンガープリントで 1 回だけ保存します。両方のワーカーの初期化に成功する必要があります。バックエンドが欠けている場合は、暗黙に単一デバイスのモードに切り替えず、エラーとして報告します。

検出・追跡の頻度と、人物ごとのEmbedding間隔で処理を調整します。モデル間で共有するGPU実行枠、GPU/NPUの使用率制限、EmbeddingGemmaの20%待機、間隔の自動延長はありません。旧設定のsearch.mobileclip_gpu_budget_percentとsearch.mobileclip_npu_budget_percentは有効な値なら警告付きで読み込みますが、動作には使わず保存時も出力しません。以降のEmbeddingには新しい追跡画像が必要です。各バックエンドの実行中ジョブは最大1件とし、待機中の画像は新しいものに置き換えます。AI Statisticsで実際の完了間隔、画像の経過時間、置換数、未処理の期限超過を確認できます。実行ポリシーも参照してください。

領域のクエリは両方のデバイスで同時にエンコードし、各ベクトルは対応するバックエンドの記録だけを検索します。テキストのクエリには、両方の名前空間で共通の CPU FP32 テキストエンコーダーを使います。ヒットは既存のカメラ/人物の規則で統合し、バックエンド内のコサインスコアの順に並べます。異なるバックエンドのベクトルを直接比較することはありません。類似度スコアの分布は FP16 と BF16 で異なることがあります。Image embedding GPU と Image embedding NPU の行にはデバイスごとの呼び出し回数、バッチサイズ、時間を表示し、Image embedding には完了した個々の収集ジョブを集計して表示します。GPU と NPU のジョブは重なることがあるため、それらの時間を足して経過時間とみなしてはいけません。GPU/NPU それぞれの処理中の行と、保留中のキューの行から、受け付けた処理と待機中の処理が分かります。

SDKの利用側は、GPU画像の所有権を保持するSearchImage、拡張されたSearchOptions、浮動小数点の Options::ai_fps / AI 頻度のインターフェースに合わせて再ビルドする必要があります。

ネイティブランタイムの準備

dependencies.lock.json で固定した EmbeddingGemma 2 ROCm のリビジョン 351303e293e11bafe4aa09f8303ba8b4d294d128 を使ってください。ローカルにある古いバイナリは、ライブラリのバージョンが同じでも、プロファイルの常駐方針が異なる場合があります。そのリビジョンの docs/build.md に従い、フレームワークのランタイムに合わせた ROCm 7.2、MIGraphX、ROCm LibTorch を使ってビルドとインストールを行ってください。Python はモデルの準備に使います。NVR はネイティブの C ABI を通じて libeg2 を直接呼び出します。

上流のダウンロード手順に従ってモデルを取得した後、正方形の画像プロファイルとテキストプロファイルを準備します。

eg2 prepare --model /path/to/google --output artifacts/nvr-search \
  --budgets 70 --batches 1 --aspect 1 1
eg2 prepare-text --model /path/to/google --output artifacts/nvr-search \
  --batches 1 --lengths 32 128

これらのコマンドは embeddinggemma2-rocm の準備環境で実行します。NVR の設定の出力パスは、生成されたバンドルを指す必要があります。長いクエリには、それに対応する準備済みのテキストシーケンスプロファイルが必要です。エラーは Search に表示します。モデルの読み込みとウォームアップは、ライブ推論のスケジューラーが始まる前に終わるため、初期化中に HIP グラフのキャプチャが同時に行われることはありません。

インストールしたネイティブランタイムでは、次のように起動します。

source scripts/env.sh
export EG2_ROOT=/path/to/embeddinggemma2-rocm/install
export EG2_TORCH_ROOT=/path/to/venv/lib/python3.12/site-packages/torch
source examples/nvr/scripts/search-env.sh
build/examples/nvr/amdva-nvr /path/to/config.json

この環境設定用スクリプトは、インストールした eg2-hip のエイリアスを他の HIP ライブラリより前に置き、libamdhip64.so とそのバージョン付き SONAME が同じランタイムに解決されるようにします。また、gfx1150 に必要な実験的な AOTriton のアーキテクチャ経路を有効にします。他の GPU アーキテクチャには、それぞれ準備・検証したバンドルが必要です。

サンプルの NVR 設定では検索を有効にしています。search を省略した設定では以前の動作のままです。ライブラリが見つからない場合や、プロファイルに対応していない場合は、エラーを表示して検索サービスを無効にします。受信と録画は引き続き開始します。

"search": {
  "enabled": true,
  "library": "libeg2.so",
  "bundle": "../artifacts/nvr-search",
  "device": 0,
  "image_size": 384,
  "interval_ms": 5000,
  "queue_limit": 128
}

ディレクトリを含むパスは設定ファイルからの相対パスです。ライブラリ名だけを指定した場合は動的ローダーの検索パスを使います。image_size は 32–1024 で、縦横の両方に適用します。元の画像は縦横比を保ち、拡大することはありません。正方形のモデル入力は黒のパディングで中央に配置し、トークン予算 70 を使います。DB に保存する画像にはパディングがありません。バンドルのマニフェストや前処理を変更すると別の埋め込みの名前空間を選ぶため、互換性のないベクトルどうしが比較されることはありません。

タイミング、保存、再生

人物のボックスには各辺に 10% の余白を加え、映像の範囲で切り詰めます。専用の GPU 経路でソースを BGRA に変換し、切り抜きを上限付きの RGB にバイリニアで縮小します。ネイティブモデルの入力と PNG エンコードのために読み戻すのは、この上限付きの RGB 画像だけです。ライブと再生の描画経路は引き続き VA、DMA-BUF、EGL を使います。コピー監査ツールは、切り抜きの読み戻しとネイティブの埋め込みの転送を別々に数えます。他のスレッドや経路での申告されていない転送は、引き続き拒否します。

SQLite は、PNG、768 次元の正規化された FP32 の埋め込み、ソースのメタデータを 1 つの行にアトミックに保存します。同梱の sqlite-vec 拡張が、選択したモデルの名前空間に対してコサイン距離を計算します。この全件走査はデモ程度の規模の履歴を想定しており、無制限のアーカイブ向けの近似索引ではありません。クエリは上位 500 枚の画像と最大 50 個のグループを返します。同じカメラで 10 秒以内の間隔にある近傍の画像を 1 つのグループにまとめ、グループの範囲は最初のヒットから 60 秒までに制限します。グループは最も高い類似度の順に並べます。類似度は順位付けのスコアで、確率や同一人物であることの主張ではありません。

フレームのタイムスタンプは、録画と同じ元の PTS と受信側の実時刻の基準点から求め、別々のデコード起点やバックグラウンドのキーフレームにも対応します。画像は、それを含む録画が確定した後に検索できるようになります。このため、最近の観測が表示されるまでに約 1 セグメント分の遅延が生じます。新しいセグメントが確定しても検索は自動で再実行されないため、更新するには再度送信してください。

再生範囲は、グループのヒットの前後 5 秒を含み、利用できる録画の範囲に制限されます。欠落部分には既存の前方への解決の動作を使います。再生範囲の終端を排他的に扱うため、要求した区間を超えるフレームは表示されません。プレーヤーが保護するのは、再生中のファイルと先読み中のファイルだけです。存在しない録画や壊れた録画には、既存の再生の通知を使います。

容量上限による削除、保持期間の期限切れ、手動削除では、関連する画像とベクトルも削除します。処理中の結果が、削除した区間のエントリを再作成することはありません。起動時と検索時に、中断された録画や外部で失われた録画との整合を取ります。PNG とベクトルのデータは管理対象のストレージに含まれ、SQLite のインクリメンタル vacuum により削除後に解放したページを返します。データベースの移行は追加のみで、古いカタログではインクリメンタル vacuum を 1 回有効にします。利用側は、更新されたストリーミングのヘッダーに合わせて再ビルドする必要があります。

ドラッグすると、マウスを押してから切り抜きが完了するまで、表示中のライブまたは再生のサーフェスを固定します。ドラッグすると再生は一時停止し、離すと領域を送信して Search に切り替えます。クリックは再生/一時停止の操作のままで、Esc で選択を取り消します。座標はレターボックスの部分を除き、表示の拡大率を考慮し、描画したタイムスタンプの文字を含みません。切り抜きは、サーフェスが再利用される前に非同期に取り出します。

検証

search-contract は、切り抜きの寸法、パディング、グループの境界、コサインによる検索、モデルの分離、画像の保存、削除、保護、遅れて完了した処理を確認します。設定のテストでは、既定値、範囲、保存を確認します。既存の再生/カタログ/レンダラーのテストも引き続き適用できます。

ハードウェアでエンドツーエンドに実行するには、人物が映っている互換性のある映像を配信し、専用の設定で対応する RTSP の URL と新しい録画ルートを指定します。そのうえで次を実行します。

source scripts/env.sh
# Also source examples/nvr/scripts/search-env.sh with the native runtime paths set.
build/examples/nvr/amdva-search-validate /path/to/test-config.json

この検証ツールは、収集、英語/日本語のテキストクエリ、カードでの再生、録画の領域のドラッグを確認します。MP4/MKV のテスト用素材には amdva-rtsp-files を使ってください。デモは 2560×1440 までのプログレッシブ 8 ビットの H.264/H.265 入力を受け付けます。それより大きい入力には、別途縮小したテスト用のコピーが必要です。元のファイルは変更しません。

--exercise-deletion は、破棄してよい録画ルートでのみ追加してください。このオプションはクローズ済みのテスト用録画を削除し、その検索用画像が削除されたことを確認します。コピー監査のライブラリをプリロードすると、検証ではモデルのウォームアップ後に監査を始め、ライブ/描画の経路で申告されていないコピーが発生しないことを確認します。QT_SCALE_FACTOR=1.5 を設定すると、小数の表示拡大率での選択を確認できます。

ローカルのハードウェア検証では、~/work/videos/M01_1440p30_10min_hevc.mp4 と M02_1440p30_10min_hevc.mp4 を、それぞれ 90 秒の 1080p H.264 のコピーにして使いました。どちらの言語のテキストでも、これらの美術館の場面に映る紫のスカートを検索できました。表示中のカメラと非表示のカメラからの収集、インライン再生、録画の領域検索、取り消し、録画の削除を確認しました。この短い統合テストでは、長時間のスループットや大規模アーカイブでの検索性能は確認できません。

人物のトラッキングと ReID

人物カードを有効にするには、search.reid_model にコンパイル済みの OSNet MSMT17 チェックポイントを指定します。パスが空または省略されている場合は、元の時間ベースのグループ化のままです。サンプルの設定では ../artifacts/reid-model/osnet-x1-msmt17.mxr を使います。設定したモデルを読み込めない場合は、検索サービスがエラーを表示して停止し、暗黙に別の同一人物判定のアルゴリズムへ切り替えることはありません。受信と録画は継続します。

ネイティブの固定カメラ用トラッカーは、BoT-SORT 方式の高/低信頼度の対応付け、矩形のハンガリアン法による割り当て、タイムスタンプに基づく中心/サイズのカルマンフィルターによる動き予測、平滑化した OSNet の外見特徴量を実装しています。これはサンプリングした推論に合わせたローカルの C++ 実装で、上流の Python トラッカーやそのベンチマーク設定ではありません。カメラの動きの補正は無効です。PTZ カメラや移動するカメラには追加の作業が必要です。ReID を有効にすると、ライブのオーバーレイには確定した人物検索の ID を使い、それらの人物に対応付けられたままの低信頼度の検出も含めて表示します。ReID を使わない場合は、既存の画像を使わないトラッカーがライブの ID を提供します。

検出では、対応付けに信頼度 0.1 を使います（旧来の検出メタデータは 0.25 のままです）。高信頼度の対応付けは 0.5 から、新しいトラックは 0.6 から始まります。2 回一致した観測で人物を確定します。動きによる対応付けではトラックを 2 秒間保持し、低スコアからの復帰は 1 秒に制限します。見失った確定済みのトラックは、コサイン類似度が 0.85 以上、候補間の差が双方向で 0.05 以上、移動量が人物の身長の 3 倍以内であれば、30 秒以内に再接続できます。再接続では人物 ID を保ったまま新しいトラックレットを始めます。曖昧な一致では別の人物として扱います。これらの控えめな初期しきい値は、設置場所ごとの評価が必要です。似た服装や大きな遮蔽によって誤ることもあります。

検出とトラッキングは、カメラごとに ai_fps（0.1–10 Hz、既定値 2）で実行します。動きの予測と期限切れの判定には、想定したフレーム番号ではなくフレームのタイムスタンプを使います。トラッキングワーカーは、キューにあるフレームをそのカメラの最新のフレームに置き換えます。意味検索のワーカーは、これとは別に人物ごとに最新の切り抜きを保持します。意味検索用の収集には、確定済みで高信頼度の観測が必要です。ReID を有効にすると、保存する切り抜きと ReID の切り抜きには、旧来の 10% の余白ではなく人物のボックスそのものを使います。ReIDは元のVAフレームと人物ROIを常設のappsrc → amdpreproc → appsinkへ渡します。VPEで余白なしに切り出し・リサイズし、HIPでImageNetのRGB正規化を行います。バッチ1ではGPUテンソルを直接MIGraphXへ渡し、大きなバッチはGPU間コピーで組み立てます。CPUでの画素の前処理と入力のGPUへのアップロードは行わず、L2正規化した512次元の特徴量だけをCPUへ戻します。CPUのRGB画像はサムネイルと意味検索用に残します。リサイズ処理の変更に合わせてosnet-person-amdpreproc-roi-v2の名前空間を使います。古いDB行は残りますが、以前のReID空間を検索するには以前の実装が必要です。過去の録画の自動再処理は行いません。これらの特徴量は、テキストと領域のクエリに使う 768 次元の EmbeddingGemma のベクトルとは別のものです。ReID のバッチが埋まらない場合は最後の有効な画像を繰り返し、パディング分の出力は破棄します。

ReID を有効にすると、非表示のカメラでも 5 秒ごとのキーフレームのスナップショットではなく、ハードウェアでの連続したデコードと推論を続けます。16 個の非表示用の専用スロットにより、表示/非表示の組み合わせにかかわらず、想定する合計 16 台のカメラに対応します。これはスケジューリング上の容量であり、任意の入力形式、フレームレート、人数でのスループットを保証するものではありません。ReID を使わない場合、非表示のカメラの解析は旧来のキーフレーム間隔のままです。

検索結果はカメラと人物 ID ごとにまとめます。カードには一致したトラックレットの区間の選択欄があり、人物がいない時間帯を通して再生せずに済みます。テキストと任意の領域のクエリには選択した埋め込みモデルを使い、保存した画像のどれが同じ人物かは ReID で判定します。領域のクエリで同じ人物が確実に見つかるわけではなく、特に複数の人物を含む場合はその傾向があります。ID は、カメラ、受信側の録画セッション、アプリケーションの再起動をまたいでは引き継がれません。データベースの移行では人物/トラックレットの ID と ReID の特徴量を追加し、既存の観測はそのまま残します。埋め込みの名前空間には ReID のモデルのバイト列と前処理のバージョンが含まれるため、互換性のない履歴が混ざることはありません。以前の時間ベースでグループ化した履歴は、元の設定を使うと利用できます。

OSNet の準備と確認

dependencies.lock.json の person_reid エントリにあるソースのリビジョンと重みの URL からダウンロードし、記載された SHA-256 の値を確認してください。重みは ImageNet だけで学習したチェックポイントではなく、MSMT17 で ReID 用に学習したものが必要です。モデルの準備には既存の .deps/model-export の Python 環境を使います。本番の推論はネイティブの C++/MIGraphX で行い、Python は読み込みません。

source scripts/env.sh
export PATH="$PWD/build/src/gst:$PATH"
.deps/model-export/bin/python examples/nvr/scripts/export_reid_model.py \
  --source /path/to/torchreid/models/osnet.py \
  --weights /path/to/osnet-msmt17.pth --output artifacts/reid-model
LD_PRELOAD="$PWD/build/src/gst/libamdva_copy_audit.so" \
  build/examples/nvr/amdva-reid-validate \
  artifacts/reid-model/osnet-x1-msmt17.mxr /path/to/hevc.mp4

エクスポートスクリプトは、分類器以外の互換性のないパラメーターを拒否し、ハッシュと前処理を記録します。ネイティブの検証ツールはHEVC映像をVAでデコードし、元のフレームのROIをamdpreprocへ渡します。2つのROIを交互に切り替えて100回要求し、部分バッチや複数バッチでの順序と特徴量の一致を確認します。さらに100個の小さいROIを処理し、入力アップロードとコピー監査違反がないことを確認します。コサイン類似度0.9999以上の判定はバッチ間の再現性に対するもので、旧CPUリサイズやPyTorch前処理との一致を保証するものではありません。実行結果も参照してください。検索の契約テストでは、検出の順序、低スコアからの復帰、仮のトラック、短時間での再出現、曖昧さ、古いタイムスタンプ、期限切れ、同一人物のグループ化、保存を確認します。M01/M02 の統合テストでは、非表示のカメラからの収集、小数の表示拡大率、再生、領域検索、コピー監査、削除も確認します。これらの確認では、ラベル付きデータセットでの IDF1 やカメラをまたいだ同一人物判定の精度は確認できません。

ライブの人物のオーバーレイは、黒い縁取り付きの 3 論理ピクセルの色付きの枠、16 ピクセル固定のベクター文字、不透明度 45% の黒いラベルパネルを使います。枠と文字の色は、人物 ID から求めた固定の色相です。ラベルには ID と現在の検出の信頼度だけを表示します（例: #2 23%）。確定済みの低スコアの対応付け（0.1–0.5）も表示したままにします。低スコアの検出だけでは新しい人物を作りません。トラッキングのスナップショットは 1 秒で期限切れとなり、デコーダーの世代や画像の寸法が変わった場合は拒否します。検証ツールでは AMDVA_VALIDATE_CAPTURE=1 でこのオーバーレイをキャプチャできます。フレームバッファーの読み戻しを使うのはこの任意の検証用キャプチャだけで、通常のライブのレンダラーでは使いません。

MobileCLIP の統合確認（2026-10-24）

ネイティブのワーカーは、GPU と NPU の画像バッチ 1/3/4（パディングや分割を含む）、英語/日本語のテキストの呼び出し、正規化した 512 次元の出力の確認に合格しました。2 つの 1440p の RTSP 入力で、3 つの埋め込みの選択すべてが、ライブでの収集、テキストクエリ、録画のインライン再生、ライブ/一時停止中のライブ/録画での領域検索、削除に合格しました。これは機能の確認であり、検索精度や 16 カメラでのスループットの確認ではありません。UI の検証では 1.3 Hz / 0.7 s の目標値を確認し、3 つのモデルの選択すべてを保存し、実行中のエンコーダーを変えずに初期のモデルに戻しました。ローカルのログは artifacts/mobileclip-switch/ にあります。

デバイスごとの独立した割り当てを導入する前に、組み合わせのモードは、両方のバックエンドの名前空間にデータが入った 2 カメラ・1440p の実行（収集の確認で GPU 224 件 / NPU 81 件の観測）、4 通りの UI の選択の保存、同じテキスト/領域/削除の手順に合格しました。40 秒間の統計の実行では、GPU の呼び出しの平均が 25.24 ms、NPU の呼び出しが 13.63 ms、組み合わせた収集の経過時間が 25.26 ms で、論理バッチは平均 3.59 枚でした。デバイスごとの行にはそのデバイスに送った処理だけが含まれるため、足し合わせて直列の遅延とみなさないでください。これらは短時間の機能確認であり、スループットのベンチマークではありません。ログは artifacts/mobileclip-combined/ 以下にあります。

MobileCLIP の独立スケジューリングの確認（2026-10-25）

16 ソース・1440p のテストでは、2 Hz のトラッキング、意図的に短くした 100 ms の人物ごとの要求間隔、GPU/NPU の予算 100% を使いました。約 90 秒間、表示するカメラを 16 台、4 台、0 台と変えた間、サンプリングした埋め込みとトラッキングのキューの破棄カウンターは 0 のままでした。サンプリングした埋め込みキューの深さは最大で 128 中 51 でした。最後のサンプルでは 4,838 件の観測が保存され、検索のエラーはありませんでした。両方のバックエンドの名前空間にデータが入りました。最後の移動ウィンドウでの平均は、GPU の呼び出しが 29.74 ms（バッチ 4）、NPU の呼び出しが 17.86 ms（バッチ 1）でした。これらの数値はこの短時間の実行の結果であり、すべての入力の負荷での保証ではありません。デモで設定した人物ごとの間隔は変更していません。

UI の検証では、GPU/NPU の予算 35%/80% を適用して保存し、その後両方を元の設定に戻しました。別の 2 カメラの実行では、英語/日本語のテキストクエリ、インライン再生、ライブ/一時停止中のライブ/録画での領域検索、削除に合格しました。33 件の CTest すべてに合格し、最後の初期化の変更後に、スケジューラー、設定、検索の契約テストにも合格しました。ローカルのログは artifacts/mobileclip-budget/ 以下にあります。

NPU のみのモードも、16 ソースと変更しない 5 秒の人物ごとの間隔で 40 秒間確認しました。保存された観測は 487 件、サンプリングした埋め込みキューの深さは最大 65/128 で、埋め込み/トラッキングのキューの破棄は 0 件でした。

検索モードの検証（2026-10-25）

34 件の CTest すべてに合格しました。これには、デバウンスによる置き換え、Enter での送信、日本語 IME の確定、空の条件、モードの切り替え、排他/解除のチェックボックス、生成される説明文、取り消しを確認する UI のみの新しいテストが含まれます。検索の契約テストは、最後のレイアウト調整の後に再実行しました。2 カメラ・1440p の MobileCLIP GPU+NPU の実行では、チェックボックスによる人物検索、逐次の英語/日本語のテキストクエリ、結果の再生、録画/ライブ/一時停止中のライブでの領域検索、削除に合格しました。紫のスカートのクエリでは、確認した上位の結果に一致する服装が含まれていました。これは機能の抜き取り確認であり、属性の精度のベンチマークではありません。ログと確認したスクリーンショットは artifacts/search-modes/ にあります。