ロボットの推論遅延を評価するには、物理的な観測が得られてから、対応するコマンドが実際に反映されるまでの経過時間を測ります。ニューラルネットワークのランタイムは一つの区間だけです。露出、センサーバッファリング、転送、デコード、前処理、キューイング、ポストプロセッシング、ミドルウェア、コントローラースケジューリング、アクチュエーターの適用も同様に重要になり得ます。
有用な予算は、同期されたタイムスタンプで1フレームまたは状態サンプルを追跡することです。処理にかかった時間と、使用時点でのデータの経過時間を区別し、定義した負荷条件で観測した中央値、上位パーセンタイル、最大値を報告します。スループットや毎秒フレーム数だけでは、ロボットがコマンドを適用した時点で元の観測データがどれほど古いかは分かりません。
このガイドを ROS 2 リアルタイム制御ガイド および ロボット VLA 評価ガイドと組み合わせてご利用ください。知覚やポリシーの処理時間が変動しても、下位の制御ループは定めた時間内に動作するよう設計する必要があります。
物理的な開始と終了のタイムスタンプを定義する
開始点はアプリケーションのコールバック実行時ではなく、カメラの露光、LiDARの取得、ロボット状態のサンプリングなどの物理的な時点に置きます。終了点は、コントローラーやドライブがコマンドを受け入れる時点、または実際に適用する時点として明示します。ソフトウェア関数の開始から戻りまでしか測らないと、転送やハードウェアの遅延を取りこぼします。
共有クロックを使うか、クロックのオフセットやドリフトを特性付けしてください。利用可能な場合はハードウェアタイムスタンプが望ましいです。入力から出力までのシーケンス識別子を保持し、どのフレームが各アクションを生み出したかを証明できるようにしましょう。同一性がなければ、高速コールバックは古いバッファ付きフレームを処理している可能性があります。
センサー取得から推論開始までにもデータは古くなる
ローリングシャッター、露光時間、フレーム表示、センサー側の画像処理が遅延を増やします。30フレーム毎秒で動作するカメラは、異なる行時間を表すフレームを提供でき、ホスト転送前にすでにフレームのごく一部をキャプチャに費やしています。
トリガーモード、露光、バッファの深さ、フレームを捨てる条件、タイムスタンプの基準点を記録します。最新フレームだけを使う処理では古いフレームを捨ててデータの経過時間を短くできます。一方、すべてのフレームをキューで処理すると、過負荷時には使うフレームが次第に古くなります。どちらの方針も普遍的に正しいわけではありません。制御の結果が決定します。
| 処理段階 | 開始時点 | 終了時点 | 見落としやすい遅延 |
|---|---|---|---|
| 取得 | 物理的な露光 | センサーフレームの準備完了 | 読み出しとISP処理 |
| 転送 | DMAまたはパケット送信 | ホスト側バッファで利用可能 | コピーとバスの待ち行列 |
| 前処理 | フレーム選択 | 入力テンソル準備完了 | デコードとサイズ変更 |
| 推論 | リクエストをキューに投入 | 出力同期 | ホストとデバイスの作業 |
| コマンド適用 | 出力のデコード | ドライブがコマンドを受け入れる | ミドルウェアと制御フェーズ |
コピー数やキュー数はモデル計算を上回ることがあります
画像のデコード、色変換、リサイズ、正規化、ホストからデバイスへのコピー、テンソルレイアウトの変更など、それぞれバッファを作成することがあります。ゼロコピー設計は転送を減らすことができますが、寿命やアラインメントの制約を加えます。フレームワークがメモリ間の転送をなくしたと決めつけず、実際にデータがどこへ移動するかを計測してください。
キューでの待ち時間を、実際の処理時間とは分けて計測します。CPUスレッド競合、コールバックエグゼキュータ、GPUストリーム、非同期ドライバは、見える関数間の待機を隠すことができます。キューの深さを限定し、到着する入力が前の作業を置き換えるか、スキップするか、待機するかを定義します。
モデルレイテンシには明示的な同期が必要です
GPUの起動APIはしばしば非同期です。ホスト側のAPI呼び出しだけを測ると、推論の完了時間ではなく、処理をキューに入れるまでの時間しか記録できないことがあります。適切なデバイスイベントを使用するか、出力境界で同期しつつ、アプリケーションパス全体にウォールクロック測定を保持します。
現在の TensorRT性能ベンチマークのドキュメント では、スループット、ホストレイテンシ、転送、GPU計算時間、エンキュー時間が分離されています。推論のみのメトリクスは分離に有用ですが、ロボットのセンサーやコントローラーの段階は、アプリケーションが測定しない限り含まれません。
スループットとレイテンシは異なる問いに答えます
スループットは単位時間あたりの完了推論数です。レイテンシとは、1回のリクエストに対する経過時間のことです。バッチや並行ストリームは、集合スループットを向上させる一方で、個々のロボットフレームで見られる待ち時間や競合時間を増加させる可能性があります。同じスケジューリング設定で両方報告してください。
入力の生成が処理を上回ってキューが伸びると、スループットが高くても、使われるデータの経過時間は際限なく長くなり得ます。コマンド適用時のフレーム年齢と推論数を並べてプロットします。制御に関しては、より低いレートの最新の観測の方が、順序通りに提供されるすべての古い観測よりも有用であることが多いです。
| 指標 | 何を示すか | 統計値 | ロボットへの影響 |
|---|---|---|---|
| モデル計算 | デバイス側の処理時間 | 中央値と上位側の遅延 | ポリシー更新周期の逸脱 |
| エンドツーエンドの遅延 | 一つの観測からコマンド適用までにかかる時間 | P50、P95、P99、最大値 | 反応の遅れ |
| データの経過時間 | 使用時点で観測データがどれほど古いか | 分布 | 古い観測に基づくコマンド |
| スループット | 一定時間に完了するリクエスト数 | 毎秒の完了数 | キューの成長 |
| ジッター | タイミングの変化 | 範囲とパーセンタイル | 制御の不均一さ |
テールレイテンシは稀な物理的故障を決定します
平均レイテンシはスケジューラの一時停止、初回使用コンパイル、キャッシュミス、熱的スロットリング、動的形状、ネットワークの再トライを隠します。ウォームアップを別々に記録し、まれに起きる計算資源の競合を捉えられるよう、十分な時間測定します。P95およびP99は、それらのパーセンタイルを解釈するのに十分なサンプル数でのみ報告してください。
観測した最大値を追跡します。ただし、システム設計や解析による裏付けがない限り、それを「証明済みの上限」と呼んではいけません。外れ値は電力、温度、クロック、CPU負荷、メモリ負荷、ネットワークおよびプロファイルの変化と相関します。いくつかの遅いコマンドが衝突やグラスプの失敗を支配することもあります。
オンボード、エッジ、クラウドの各パスには異なる予算があります
オンボード推論は広域ネットワークの変動を回避しつつ、電力と熱の制限をロボットと共有します。エッジサーバーは無線、スイッチング、キュー機能を追加しつつ、より多くの計算能力を提供します。クラウドパスはルーティングやサービスの競合を追加し、切断や応答遅延に対する明確な動作が必要です。
実際の展開領域およびローミングや干渉下での往復分布を測定します。フレームの年齢制限を超えた状態でコマンドを送信しないでください。ロボットでシーケンスチェックとデッドラインチェックを使い、遅延しても有効に認証された応答が現在の状態を変えないようにしましょう。
最適化は精度、負荷、スケジューリングのトレードを優先します
数値精度の低減、量子化、枝刈り、入力解像度の低減、フレームスキップは計算量を減らしますが、モデルの出力も変わり得ます。目標ハードウェア上で最適化後、タスクの精度と故障モードを検証します。較正結果が変わったエンジンや、必要な演算子をサポートしないエンジンは、元のポリシーと同等ではありません。
現在の TensorRTベストプラクティスガイド では、クロック、電源、熱状態、転送、ソフトウェア設定の制御を推奨しており、再現可能な数値を保つことが推奨されています。ビルドした推論エンジンのハードウェアとドライバー環境を固定します。ベンダーのベンチマーク値を、構成の異なるロボットで測った値とそのまま比較しないでください。
ポリシーレートとサーボレートは分離されるべきです
ビジョンや VLA ポリシーは数十ヘルツで更新される一方で、関節制御は1秒間に数百回から数千回動作します。下位レイヤーは有界参照の補間、トラッキングの監視、古いコマンドの拒否が可能です。ハードタイミング経路の中から神経推論を待つべきではありません。
ロボット アクションチャンクガイドで説明する行動の予測区間と整合させます。予測時間、実行した先頭部分、コマンドの経過時間を記録します。推論が期限を過ぎた場合は、任意の古いアクションを繰り返し演じるのではなく、ホールド、減速、より安全な状態への遷移などのテスト済みのバックアップを選びましょう。
現実的なストレス下でのタイミングの検証
代表的なカメラ、ログ、ネットワーク、マッピング、UIのワークロードを同時に運用しましょう。温度、パワーモード、動的な形状、オブジェクト数、バックグラウンドの通信量を変化させます。ロボットの応答を測定しながら、フレームのドロップ、遅延パケット、推論オーバーランを注入します。
各段階でターゲットと測定された分布を含むバージョン化されたレイテンシ予算を維持しましょう。モデル、前処理、ミドルウェア、ドライバー、ファームウェア、またはコンピュートの変更後に再確認してください。段階最適化は、センサーからアクチュエータへの完全な経路とタスク結果が改善された場合にのみ受け入れるべきです。
- センサーによる物理的な取得時点と、コマンドが適用された時点にタイムスタンプを付けます。
- 各段階でシーケンスの同一性を持ち続けてください。
- キュー待ち、ホスト側の処理、デバイス側の処理を分けて計測します。
- 遅延分布の上位側、スループット、データの経過時間を報告します。
- 過負荷、発熱、ネットワーク損失、フォールバックの動作をテストしてください。
よくある質問
モデルが10msで動作した場合、ロボットは10msで反応しますか？
いいえ。キャプチャ、転送、前処理、キュー、後処理、通信、コントローラスケジューリング、アクチュエータ応答はモデル計算外に残ります。
FPSとレイテンシーは同じ指標なのでしょうか？
いいえ。FPSはスループットです。パイプラインは、個々のフレームがキューで待機し、ロボットに遅れて到達する間に1秒間に多くのフレームを完了できます。
なぜ平均レイテンシが不十分なのでしょうか？
稀な失速が最も重要な物理的な故障を引き起こすことがあります。パーセンタイル、最大観測値、サンプル数、および外れ値に関連する条件を報告してください。
古いフレームは単純に削除されることはありますか？
多くの場合、最新のみのポリシーは年齢を下げますが、削除すると時間的サンプリングやモデルの挙動が変わります。タスクとコントローラーでドロップルールを検証してください。
クラウド推論はロボットにも使えますか？
ネットワークの変動を許容する締め切りやバックアップのタスクもサポートできます。実際の経路を測定し、ロボットのコマンド年齢制限を超える応答は却下します。
推論タイミング証拠境界
レイテンシーの数値は、定義されたセンサー、モデル、ハードウェア、ソフトウェア、負荷および測定境界に適用されます。推論ベンチマークだけでは、ロボットの反応時間が制限されている証拠にはなりません。