オンデバイス推論 on Physical AI Hub

ロボットAIの電力・熱設計：長時間運用で推論性能を安定させる監視方法

Sun, 27 Sep 2026 14:06:14 +0900

短時間のベンチマークで良好に見えるロボットAIが、長時間運用でも同じ応答性を保てるとは限りません。

先に結論

Jetsonなどのエッジ計算機を搭載したロボットでは、平均FPSだけで長時間運用の安定性を判断してはいけません。温度、電力、CPU・GPU・メモリ帯域の利用率と周波数、アプリケーション遅延を同じ時系列で記録し、p95・p99遅延、最大遅延、期限超過率、キュー長を重視します。

温度上昇や電力制約と実効クロック低下が、p99遅延の増加と同時に起きていれば、熱または電力に起因する性能低下を疑います。温度やクロックが安定しているのにキューだけが伸びる場合は、CPU競合、メモリ帯域、I/O、前処理・後処理などを追加で調べます。状態が悪化したときは、推論レート、処理対象フレーム、入力解像度、モデル品質を段階的に下げる閉ループ制御が有効です。

なぜ長時間の監視が必要か

短時間のベンチマークは、起動直後の温度や一時的な冷却条件を反映します。一方、実際のロボットでは筐体や周囲の温度、電力モード、センサー入力、制御処理などが時間とともに変化します。Jetsonの熱管理機構は温度センサー、thermal zone、冷却デバイス、トリップポイントを使い、条件に応じて周波数制御やスロットリングを行うことがあります。

そのため、瞬間的な推論時間やFPSだけでは制御周期を守れるか分かりません。安全制約や周期処理を持つシステムでは、平均値よりも遅延分布の上側を見ます。p99遅延、最大遅延、期限超過率、連続した欠落フレーム数の許容値は、対象ロボットの制御仕様と安全要求から決めます。製品、冷却方式、筐体条件が異なるため、温度や電力の一律な閾値は設定できません。

監視するメトリクス

Jetsonのシステム状態は、tegrastatsで一定間隔に取得できます。RAM、SWAP、CPU・GPU・EMCなどの利用率と周波数、温度、電力情報が対象です。電力監視ではVDD_INなどの入力・レール単位の値を利用できますが、利用可能なセンサー名や値の意味は、モジュール、キャリアボード、ソフトウェア設定によって異なります。VDD_INがモジュール入力だけを示すのか、キャリアボードや周辺機器を含むのかは、対象機の回路構成とセンサー実装を確認してください。

温度の調査では、tegrastatsの温度値に加えてthermal sysfsを確認します。Linuxのthermal frameworkは、thermal zoneの温度、冷却デバイス、トリップポイントをsysfs経由で公開します。これにより、単に温度が高いかだけでなく、温度管理機構の状態を確認できます。

推論レイテンシはtegrastatsだけでは測れません。アプリケーション側で、入力受付、キュー待ち、前処理、推論、後処理、出力にタイムスタンプを付け、p50・p95・p99、スループット、期限超過率、キュー長を記録します。NVTXの範囲を付ければ、Nsight SystemsでCPU・CUDA・GPUのタイムラインと処理区間を対応付けられます。

flowchart TB
  S["同じ時刻軸で記録"]
  S --> T["温度センサー・thermal zone"]
  S --> P["利用可能な電力センサー\n例: VDD_IN"]
  S --> C["CPU・GPU・メモリ帯域の利用率と実効クロック"]
  S --> M["RAM・SWAP"]
  S --> A["入力受付から出力までのアプリケーション区間"]
  A --> Q["キュー待ち・前処理・推論・後処理・出力"]
  Q --> L["p95・p99・最大遅延\n期限超過率・キュー長・欠落フレーム"]
  T --> R["時間相関を確認"]
  P --> R
  C --> R
  L --> R
  R --> H{"温度上昇・クロック低下・遅延増加が重なるか"}
  H -->|"はい"| X["熱または電力制約の候補として調査"]
  H -->|"いいえ。キューだけ増加"| Y["CPU競合・メモリ帯域・I/O・前後処理を追加調査"]

温度、電力、実効クロック、キュー長、p99遅延などを同じ時系列に置くと、熱・電力制約とソフトウェア要因を切り分けやすくなります。VDD_INなどの電力値は、対象モジュールや回路構成に応じて測定範囲を確認します。

指標と取得手段の比較

指標・手段	主な対象	用途	注意点
tegrastats	温度、利用率、周波数、RAM・SWAP、電力	長時間の状態監視	製品やボードで項目が異なる
thermal sysfs	thermal zone、冷却デバイス、トリップポイント	熱制御とスロットリングの調査	対象機でセンサー構成を確認する
アプリ計測	キュー、前処理、推論、後処理、出力	エンドツーエンド性能の評価	推論単体の値とは一致しない
Nsight Systems	CPU・CUDA・GPUのタイムライン	競合や遅延区間の原因分析	常時監視より詳細調査向け
p95・p99遅延	遅延分布の上側	制御周期の評価	平均値だけでは見えない遅延を捉える

電力モードとクロック設定

nvpmodelはJetsonの電力モードを選択し、jetson_clocksはCPU、GPU、EMCなどのクロックを制御します。性能評価時と実運用時の設定を明示し、異なる条件の結果を混同しないことが必要です。

ロボット推論をエッジとクラウドに分担させる設計判断

Sun, 20 Sep 2026 23:22:26 +0900

ロボットのクラウド利用は、計算資源の問題だけでなく、通信が途切れた瞬間の振る舞いまで含めて考える必要があります。

先に結論

ロボットのクラウド推論は、通信遅延や切断が起きても安全性と制御性能を損なわない、非同期・非安全系の処理に限定するのが基本です。アクチュエータの最終制御、緊急停止、衝突回避の最終判断、ウォッチドッグ、最低限の状態推定はロボット上に残します。一方、学習、ログの再処理、フリート分析、モデルや地図の配布、遅延を許容できる高位計画はクラウドと相性がよい領域です。

クラウドを制御ループの一部に使う場合は、単に平均遅延を測るだけでは不十分です。許容遅延、ジッター、結果の有効期限、タイムアウト、通信断時の動作、古い結果の破棄条件、ローカルフォールバックをタスクごとに定義し、故障時の挙動まで検証する必要があります。

なぜ配置の境界が問題になるのか

クラウドロボティクスは、ロボット単体では不足する計算資源や知識をクラウド側で補完し、遠隔計算やデータ共有を利用する考え方です。大規模な計算や複数ロボットのデータを集約できる一方、通信接続、遅延、帯域幅、信頼性、セキュリティが制約になります。

エッジコンピューティングは、データ生成源の近くに計算資源を置く方式です。クラウドへの往復を減らし、遅延、通信量、クラウド接続への依存を抑えやすい点に意味があります。プライバシーの観点でも、すべてのセンサーデータを遠隔へ送らず、近傍で処理する構成を検討できます。

つまり設計上の対立は、クラウドかエッジかの二択ではありません。計算資源や知識共有を得る代わりに通信へ依存するか、応答性と接続独立性を優先してロボットや近接エッジへ処理を置くか、というトレードオフです。

前提となる用語

ここでいうオンデバイスは、センサーやアクチュエータを持つロボット本体で処理することです。構内エッジや地域エッジは、ロボットに近いネットワーク上の計算資源を指します。クラウドは、ロボットから離れた計算・ストレージ基盤です。

また、安全系とは、処理の遅延や失敗が安全な停止や危険回避に直接影響する機能を指します。非安全系とは、結果が遅れたり利用できなかったりしても、ロボットの安全な基本動作を直ちに損なわない処理です。

内部の仕組みと分担

安全系の基本経路は、センサー、ローカル状態推定、衝突監視、ローカル制御器、アクチュエータという閉ループにします。クラウドへの接続状態に左右されず、最低限の状態推定と停止判断を継続できることが前提です。リアルタイム処理では、予測不能なメモリ割り当て、ブロッキング、非決定的な処理を避け、期限内に完了できる実装が重視されます。

クラウド側には、センサーデータの要約やログ、学習用データ、フリート全体の分析を送ります。クラウド推論の結果は、高位計画やモデル更新などに利用できます。ただし、結果を受け取っただけで直ちにアクチュエータを動かすのではなく、期限内か、現在の状態と整合するかを確認し、無効なら破棄してローカル側へ戻します。

画像理解や意味認識のように計算負荷が高い処理はクラウドに置ける場合があります。しかし閉ループで利用するなら、ロボット側に低遅延の代替処理、安全な停止、または低機能モードを用意できることが条件です。

flowchart TD
  A["処理対象"] --> B{"安全性に直接影響するか"}
  B -->|"はい"| C["オンデバイスに配置"]
  B -->|"いいえ"| D{"許容遅延・ジッター・有効期限が厳しいか"}
  D -->|"はい"| E["オンデバイスまたは近接エッジに配置"]
  D -->|"いいえ"| F["クラウド配置を検討"]
  F --> G["タイムアウトを定義"]
  G --> H["期限切れの結果を破棄"]
  H --> I["ローカルフォールバックまたは安全停止"]

処理の安全性、許容遅延、ジッター、結果の有効期限を基準に、オンデバイス・近接エッジ・クラウドの配置を判断する。

処理カテゴリ別の配置

処理	基本配置	理由・条件
アクチュエータ制御	オンデバイス	通信遅延や切断を前提にできない
緊急停止・衝突回避の最終判断	オンデバイス	安全動作をローカルで完結させる
ウォッチドッグ	オンデバイス	接続状態に依存せず異常を検出する
最低限の状態推定	オンデバイス	制御継続に必要な状態を確保する
高負荷の画像理解・意味認識	エッジまたはクラウド	代替処理や安全停止を用意できる場合に限定
高位計画	エッジまたはクラウド	結果の遅延を許容できる場合
ログ再処理・フリート分析	クラウド	即時の安全動作を決めない
学習・モデルや地図の配布	クラウド	集約計算と配布に向く

通信品質に応じたフォールバック

クラウド推論を採用する処理には、まず結果の有効期限を設定します。期限を過ぎた結果は、通信が復旧して届いたとしても現在の状態に対して古い可能性があるため、破棄します。要求を送ってから一定時間以内に返らない場合も、待ち続けるのではなく、代替モデル、速度制限、低機能モード、安全停止、手動介入など、あらかじめ定めた動作へ遷移させます。

リアルタイムなロボットAI基盤：推論・制御・通信の実行予算を設計する

Sun, 14 Jun 2026 01:15:54 +0900

AI推論のベンチマーク値だけで、ロボット全体のリアルタイム性を判断できるのかが気になるテーマです。

先に結論

ロボットのAI処理に、制御30%、推論50%といった普遍的な固定比率はありません。先に制御ループの期限を予約し、センサー入力、アクチュエータ出力、ROS 2通信、スケジューリング干渉、安全余裕を見積もります。その残りをAIに割り当てるのではなく、AIにも独立した周期と期限を設定し、制御が推論の完了を同期的に待たない構成にするのが基本です。

判断には平均推論時間ではなく、前処理、メモリ転送、GPU実行、同期、後処理、ROS 2メッセージ処理まで含むエンドツーエンドのp99.9、最大値、ジッター、期限超過率を使います。AIが期限に間に合わない場合は、直近の有効な結果を使うか、安全なフォールバックへ切り替えます。

なぜ実行予算が必要か

ロボットでは、平均的に速い処理より、まれな期限超過をどう扱うかが重要です。AIが通常は短時間で完了しても、CPUやGPU、メモリ帯域、ドライバ、ログ処理などの競合で一部の周期が遅れれば、制御の決定性は崩れます。実行予算は、周期や締切の中で各処理が使える時間を明示するための枠組みです。

ハードリアルタイム経路では、処理時間の上限を見積もり、動的メモリ割り当て、ページフォールト、無制限に待つロック、非リアルタイムなシステムコールを避けます。これらは平均値には表れにくい遅延要因です。

前提となる仕組み

ROS 2のExecutorは、待機集合から実行可能なサブスクリプション、タイマー、サービス、アクションなどを取り出してコールバックを実行します。SingleThreadedExecutorは単一スレッド、MultiThreadedExecutorは複数スレッドを使います。ただし、一般的なExecutorはハードな優先度順やFIFO実行を保証しません。

Callback Groupには、同時実行を制限するMutually Exclusiveと、同時実行を許すReentrantがあります。これはコールバック間の関係を制御しますが、設定だけで締切やリアルタイム性が保証されるわけではありません。

QoSにはReliability、History、Deadline、Lifespan、Livelinessなどがあります。通信の信頼性、キュー保持、更新期限、データ鮮度を設計できますが、QoSのDeadlineはデータ更新を監視する機能であり、Executorのコールバック開始時刻や処理完了時刻を保証するものではありません。

予算の分け方

まず制御周期を定め、次の順で予算を予約します。

制御計算、センサー入力、アクチュエータ出力
リアルタイム通信処理
スケジューリングや共有資源による干渉
安全・ジッター余裕
AIの前処理、推論、後処理

AIを制御周期の「残り時間」に詰め込むと、推論遅延が制御期限を直接圧迫します。制御スレッドまたはリアルタイム向けExecutorはAIの結果を待たず、利用可能な結果の鮮度を確認して使う構成にします。AIの前処理やROS 2通信は別の実行資源に分け、GPU推論は可能な範囲で非同期に投入します。

設計上の仮置きとして、100 Hz、10 ms周期なら、制御とI/Oを2 ms、ROS 2通信処理を1 ms、AIのエンドツーエンド処理を6 ms、安全・ジッター余裕を1 msと置けます。ただし、これは標準値でも推奨値でもありません。対象のCPU、GPU、モデル、I/O、ROS 2構成を測定して再設定する必要があります。

flowchart LR
  subgraph CYCLE["100 Hz・10 ms周期の仮置き例"]
    CTRL["制御・I/O\n2 ms"] --> COMM["ROS 2通信処理\n1 ms"]
    COMM --> AI["AIエンドツーエンド処理\n6 ms"]
    AI --> MARGIN["安全・ジッター余裕\n1 ms"]
  end
  SENSOR["センサー入力"] --> CTRL
  AI -->|"期限内に取得"| FRESH["鮮度を確認して\n制御で利用"]
  AI -->|"期限超過"| FALLBACK["直近の有効値\nまたは安全なフォールバック"]
  FRESH --> ACT["アクチュエータ出力"]
  FALLBACK --> ACT
  CTRL -.->|"AIの完了を同期的に待たない"| FRESH

制御とI/O、通信、安全余裕を先に確保し、AIを独立した期限で実行する予算設計の仮置き例。2・1・6・1 msは推奨標準値ではなく、対象ハードウェアでの計測後に再設定する。

何を測るべきか

AIの計測点は、センサー取得、ROS 2受信、前処理開始、ホストからデバイスへの転送、GPUカーネルの開始・終了、同期、デバイスからホストへの転送、後処理、制御入力、アクチュエータ出力です。GPU処理は非同期に実行できるため、推論APIの呼び出し時間だけでは実際の完了時間を表しません。

Jetsonの推論性能を決める量子化・メモリ・電力の最適化手順

Tue, 05 May 2026 00:55:40 +0900

量子化や高クロック化は、設定を変えるだけで結果が決まるわけではありません。実機で何を測るかが、最初の分岐になります。

先に結論

Jetsonの推論最適化は、一般的な速度倍率を当てはめず、実機でモデル単体とエンドツーエンドの両方を計測して決めます。まず入力形状を固定し、FP16・バッチ1を基準にします。その後、INT8の精度とレイテンシ、バッチサイズ、メモリ転送と同期、CUDA Graph、電力モードを一項目ずつ比較します。

INT8はメモリ使用量や推論時間を削減できる可能性がありますが、常にFP16より高速になるわけではありません。ロボット制御のように応答時間を優先するなら小さいバッチ、高スループット処理なら大きいバッチを候補にします。最終判断では、レイテンシ、スループット、精度、ピークメモリ、消費電力、温度、連続稼働時の安定性を同時に確認します。

なぜ実機計測が必要か

TensorRTの性能は、精度モードだけでなく、レイヤー実装、workspace、選択されたtactic、入出力形状、データ変換の組み合わせで決まります。対象Jetsonの世代、JetPack、TensorRT、CUDAの組み合わせによって、INT8演算子の対応やTensor Coreの利用可否も異なります。したがって、モデルの種類だけから最適設定を決めることはできません。

JetsonではCPUとGPUが物理メモリを共有します。離散GPUのようなPCIe転送だけでなく、共有DRAMの帯域競合、キャッシュ、バッファの再配置、同期も性能に影響します。モデル単体のベンチマークが良くても、カメラ取得、前処理、後処理を含めると別の場所がボトルネックになる場合があります。

用語と仕組み

FP32、FP16、INT8は、計算やテンソルを表す精度の選択肢です。低精度化によって、条件によっては演算量やテンソルのメモリ使用量を減らせます。INT8では、キャリブレーションでスケールを推定する方式と、モデルにQ/DQノードを含めて量子化を明示する方式があります。いずれも量子化後のモデル精度を評価しなければなりません。

バッチサイズは一度に処理する入力数です。大きくするとGPU利用効率やスループットが向上する可能性がある一方、1リクエストあたりの待ち時間、キューイング遅延、メモリ使用量が増えます。リアルタイム制御ではバッチ1または小さいバッチ、まとめ処理では大きいバッチを比較します。

入力形状が一定なら固定形状のエンジンを優先します。可変形状が必要な場合は、TensorRTのoptimization profileに最小・最適・最大形状を設定し、実際に使う形状ごとに測定します。

メモリ転送と実行制御

基本的な流れは、入力取得、前処理、TensorRT推論、後処理、出力受け渡しです。前処理から後処理までのテンソルをGPU側に保持し、バッファを再利用できれば、毎フレームのCPU・GPU間コピーや不要な形式変換を減らせます。ただし、Jetsonではゼロコピーや共有バッファが常に最速とは限りません。アクセスパターンと同期コストを実測します。

ホストとデバイス間の移動が必要なら、ページロックされたホストメモリ、非同期コピー、CUDA streamを候補にします。コピーと前処理、またはコピーと推論を重ね合わせられるかを確認します。Nsight Systemsでは、CPU処理、CUDA API、メモリ転送、カーネル、同期を同じタイムラインで確認できます。

入力形状、バッファアドレス、実行経路が安定した反復推論では、TensorRTのCUDA Graphも候補です。実行シーケンスを再利用して、カーネル起動や実行制御のオーバーヘッドを削減できる可能性があります。動的形状や実行時に変化するアドレスがある場合は、適用条件を確認します。

flowchart LR
  A["条件を固定\nJetson型番・JetPack・TensorRT・CUDA\n入力形状・評価データ・電力設定"] --> B["FP16・バッチ1を基準測定"]
  B --> C["モデル単体を測定"]
  B --> D["エンドツーエンドを測定"]
  C --> E["INT8を構築・精度検証"]
  D --> E
  E --> F["バッチサイズを比較\nレイテンシ・スループット・キューイング遅延・ピークメモリ"]
  F --> G["転送と同期をプロファイリング\nCPU・CUDA API・コピー・カーネル・同期"]
  G --> H["バッファ再利用・非同期化・GPU側保持を評価"]
  H --> I["条件が合えばCUDA Graphを評価"]
  I --> J["電力モードとクロック設定を比較"]
  J --> K["総合判断\nレイテンシ・精度・メモリ・電力・温度・連続稼働時の安定性"]
  K --> L{"目標要件を満たすか"}
  L -- "いいえ" --> F
  L -- "はい" --> M["設定と測定結果を記録"]

実機で条件を固定し、モデル単体とエンドツーエンドを測定したうえで、量子化、バッチ、メモリ転送、CUDA Graph、電力設定を一項目ずつ評価する流れ。

再現性のある評価手順

条件を固定する：Jetson型番、JetPack、TensorRT、CUDA、入力形状、評価データ、電力設定を記録します。
基準を測る：FP16・バッチ1を、trtexecなどでモデル単体として測定し、続いて前処理・推論・後処理を含むエンドツーエンドで測ります。
INT8を検証する：キャリブレーションまたはQ/DQ方式で構築し、精度、レイテンシ、変換処理、対応演算子を確認します。
バッチを比較する：バッチ1、小さいバッチ、大きいバッチを、レイテンシ、スループット、キューイング遅延、ピークメモリで比較します。
転送と同期を調べる：GPU側テンソル保持、非同期化、stream、共有バッファ、必要に応じてCUDA Graphを一つずつ比較します。
電力と連続稼働を測る：nvpmodelの電力モードとjetson_clocksのクロック設定を比較し、温度やサーマルスロットリングも確認します。

選択肢の比較

選択肢	向いている要件	利点	注意点
FP16	基準測定、低レイテンシ	比較の出発点にしやすい	INT8よりメモリや計算量が大きい場合がある
INT8	メモリ制約、速度・省電力の改善	低精度化の効果を期待できる	精度、演算子対応、再量子化を検証する
バッチ1・小バッチ	制御、カメラ入力	待ち時間とキューイングを抑えやすい	スループットが伸びない可能性がある
大きいバッチ	まとめ処理、分析	GPU利用効率とスループットに有利な可能性	レイテンシとピークメモリが増える
固定形状	入力サイズが一定	条件を限定して測定しやすい	可変入力には向かない
動的形状	入力サイズが変化	複数形状を扱える	profileごとの性能測定が必要
GPU側保持・非同期化	前処理から後処理までGPUを使う構成	コピーや同期を減らせる可能性	共有バッファの同期を確認する
低電力モード	バッテリー、温度、連続稼働重視	電力と熱を抑える候補になる	目標レイテンシを満たすか測る

制約と判断基準

「INT8なら必ず高速」「バッチを増やせば必ず高性能」と決めつけてはいけません。対象演算子のINT8対応、Tensor Coreの利用可否、再量子化や入出力変換、TensorRT tacticによって結果は変わります。固定形状と動的形状の差、ゼロコピーの効果、CUDA Graphの改善幅も、モデルと実装によって異なります。

Jetson上でVLMと物体検出を組み合わせる推論パイプライン設計

Mon, 05 Jan 2026 23:57:34 +0900

JetsonでVLMを使うとき、毎フレーム処理させるべきか、それとも役割を分けるべきかが設計上の分岐点になります。

先に結論

Jetsonでカメラ認識システムを構築するなら、物体検出モデルを高頻度で動かす一次視覚ループ、VLMを必要時だけ呼び出す二次推論ループとして分離するのが基本です。検出器は物体の位置、既知クラス、信頼度、追跡情報を継続的に供給し、VLMは未知物体の説明、属性や関係性の解釈、自然言語による確認を担当します。

VLMを毎フレーム実行すると計算量やメモリ使用量、レイテンシが増えやすくなります。一方、検出器だけでは説明や文脈理解が難しい場合があります。両者を同期処理で直列化するのではなく、検出器とトラッカーを継続させたままVLMを非同期実行することが、リアルタイム性と柔軟な認識を両立する判断になります。

なぜ分担が必要なのか

物体検出器は、既知クラスについて画像中の位置、クラス、信頼度を取得する処理に向きます。ロボットが周囲の物体を追跡し、制御系へ一定間隔で位置情報を渡す用途では、検出器を一次ループに置くのが自然です。

VLMは画像と言語を組み合わせ、画像の説明、質問応答、属性理解、物体間の関係性の解釈などを扱います。したがって、両者は完全な代替ではなく補完関係です。ただし、テキストでカテゴリを指定するオープンセット検出器もあるため、境界は固定的ではありません。必要な出力が「どこに何があるか」なのか、「どのような状態で、何と関係しているか」なのかを先に分けます。

基本用語と内部の仕組み

一次ループは、カメラ入力から前処理、物体検出、トラッキングまでを高頻度で処理する経路です。ここで座標、クラス、信頼度、追跡ID、時刻情報を更新します。二次ループは、一次ループが発生させたイベントを契機に、VLMへ画像と質問や指示文を渡す経路です。

呼び出し条件には、検出信頼度の低下、未知クラス候補、属性や関係性の確認要求、シーン変化、一定間隔の再評価を使えます。毎フレームではなく、不確実性や変化が生じたときに実行することで、VLMの処理量を抑えられます。

VLMへは毎回フルフレームを渡す必要はありません。検出器が得たROI、クラス候補、信頼度、追跡ID、時刻情報を優先し、周囲との位置関係など空間的文脈が必要な場合だけフルフレームを追加します。ROIは対象を絞れますが、周辺情報を失う可能性があるため、質問の内容に応じて切り替えます。

flowchart LR
  A["カメラ入力"] --> B["前処理"] --> C["物体検出"] --> D["トラッカー"]
  D --> E["検出メタデータ更新\n座標・クラス・信頼度・追跡ID・時刻"]
  E --> F["結果統合"]
  E --> G["イベント判定"]
  G --> G1["信頼度低下・未知物体候補\n属性や関係性の確認・シーン変化"]
  G1 --> H["非同期キュー"]
  E --> I["ROI・クラス候補・信頼度\n追跡ID・時刻情報"]
  A -. "空間的文脈が必要な場合" .-> J["フルフレーム"]
  I --> H
  J --> H
  H --> K["VLM推論\n画像またはROI＋質問・指示文"]
  K --> L["VLM結果をメタデータとして追加"]
  L --> F
  F --> M["安全監視"] --> N["制御系・状況理解・オペレーター向け情報"]
  D -. "VLM処理中も継続動作" .-> E

物体検出器とトラッカーを高頻度で継続動作させ、イベント発生時だけVLMを非同期実行する構成。VLMの出力は検出結果を置き換えず、メタデータとして統合します。

VLMの結果は検出結果を置き換えるのではなく、メタデータとして統合する設計が扱いやすいでしょう。VLM処理中も検出器とトラッカーを動かします。DeepStreamのようなGStreamerベースの基盤では、映像入力、前処理、推論、トラッキング、メタデータ処理を接続できます。キューで検出経路とVLM経路を分離すれば、VLMの遅延が検出器や制御系を停止させにくくなります。ただし、特定のVLMプラグインが標準提供されることや、VLMを毎フレーム処理できることを意味しません。