短時間のベンチマークで良好に見えるロボット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・前後処理を追加調査"]指標と取得手段の比較
| 指標・手段 | 主な対象 | 用途 | 注意点 |
|---|---|---|---|
| tegrastats | 温度、利用率、周波数、RAM・SWAP、電力 | 長時間の状態監視 | 製品やボードで項目が異なる |
| thermal sysfs | thermal zone、冷却デバイス、トリップポイント | 熱制御とスロットリングの調査 | 対象機でセンサー構成を確認する |
| アプリ計測 | キュー、前処理、推論、後処理、出力 | エンドツーエンド性能の評価 | 推論単体の値とは一致しない |
| Nsight Systems | CPU・CUDA・GPUのタイムライン | 競合や遅延区間の原因分析 | 常時監視より詳細調査向け |
| p95・p99遅延 | 遅延分布の上側 | 制御周期の評価 | 平均値だけでは見えない遅延を捉える |
電力モードとクロック設定
nvpmodelはJetsonの電力モードを選択し、jetson_clocksはCPU、GPU、EMCなどのクロックを制御します。性能評価時と実運用時の設定を明示し、異なる条件の結果を混同しないことが必要です。
jetson_clocksで高いクロックを維持する設定は、短時間の性能比較には利用できます。しかし、消費電力と発熱を増やし、長時間運用での熱余裕を減らす可能性があります。したがって、標準設定として無条件に採用せず、冷却条件、電源構成、温度、電力、クロック、遅延をまとめて評価します。具体的なクロック範囲や挙動は製品と電力モードによって異なります。
推論負荷を閉ループで制御する
固定フレームレートで入力を無制限に処理すると、処理が遅れた際にキューが蓄積します。制御入力には、p99遅延、期限超過率、キュー長、温度、実効クロックを使います。負荷を下げる候補は次の順に段階化します。
- 推論投入レートを制限する
- 処理対象フレームを間引く、またはスキップする
- 入力解像度を下げる
- モデルサイズや精度を下げる、モデルを切り替える
- 温度と遅延が安定した後、段階的に元へ戻す
どの段階を優先するかは、制御周期、認識頻度、精度要求によって決まります。復帰時に一時的な改善だけで負荷を戻さないよう、段階的な復帰と履歴を持たせます。推論レート、解像度、切り替え条件、ヒステリシス幅は、実機測定とシステム仕様から決めるべきで、共通の数値を事前に置くことはできません。
flowchart TD
A["推論負荷を投入"] --> B["温度・クロック・p99遅延・期限超過率・キュー長を監視"]
B --> C{"許容範囲内か"}
C -->|"はい"| D["現在の設定を維持"]
D --> B
C -->|"いいえ"| E["推論投入レートを制限"]
E --> F{"まだ許容範囲外か"}
F -->|"はい"| G["処理対象フレームを間引く・スキップ"]
F -->|"いいえ"| B
G --> H{"まだ許容範囲外か"}
H -->|"はい"| I["入力解像度を下げる"]
H -->|"いいえ"| B
I --> J{"まだ許容範囲外か"}
J -->|"はい"| K["モデルサイズまたはモデル精度を下げる"]
J -->|"いいえ"| B
K --> B
B --> L{"温度と遅延が安定したか"}
L -->|"はい"| M["履歴とヒステリシスを考慮して段階的に復帰"]
L -->|"いいえ"| B
M --> Bベンチマークと実機試験を分ける
TensorRT単体の測定では、ウォームアップ後に一定回数を反復し、レイテンシとスループットを分けて評価します。ただし、この値はセンサー入力、前処理、キュー待ち、後処理、通信を含むロボットのエンドツーエンド性能とは別です。
実機試験では、短時間だけでなく温度状態が変化する時間を含めて測定します。tegrastatsなどのシステム状態とアプリケーションのタイムスタンプを同じ時刻軸に置き、温度上昇、電力変化、実効クロック低下、p99遅延増加が重なる区間を探します。同時にキュー長、CPU利用率、メモリ帯域、I/O待ちも確認します。これにより、熱・電力起因の低下とソフトウェア起因の低下を切り分けやすくなります。
採用判断
次の条件があるなら、閉ループの負荷制御を採用する価値があります。
- 冷却条件や温度が運用中に変化する
- センサー入力の到着ペースに推論が追いつかなくなる可能性がある
- p95・p99遅延や期限超過率に許容範囲がある
- 電力モードと冷却条件のトレードオフを管理する必要がある
- フレーム、解像度、モデル品質を段階的に変更できる
負荷変動が小さく制御周期にも余裕がある場合でも、温度・電力・クロック・遅延を記録しておけば、モデルや筐体を変更した際の比較基準になります。
まとめ
長時間運用の要点は、温度、電力、利用率、実効クロック、アプリケーション遅延を同じ時系列で関連付けることです。平均FPSではなく、p99遅延、期限超過率、キュー長、欠落フレームを見て、必要に応じて推論レート、フレーム数、解像度、モデル品質を段階的に調整します。最終的な閾値と設定は、Jetsonの型式、JetPack、冷却方式、電源構成、ロボットの制御・安全要求を含む実機評価で決めます。
参考情報
- Tegrastats Utility — NVIDIA Jetson Linux Developer Guide
- Power Management — NVIDIA Jetson Linux Developer Guide
- Thermal Management — NVIDIA Jetson Linux Developer Guide
- Thermal sysfs Interface — Linux Kernel Documentation
- TensorRT Developer Guide — Best Practices and Benchmarking
- Nsight Systems User Guide
- DeepStream Performance — NVIDIA Metropolis Documentation
性能の最大値より、制御周期を継続して守れるかを測ることが、運用設計の出発点になります。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。
