電力管理 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などのクロックを制御します。性能評価時と実運用時の設定を明示し、異なる条件の結果を混同しないことが必要です。

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の改善幅も、モデルと実装によって異なります。