ロボットのエッジ計算持続性能｜熱スロットリング検証

結論は、実際のロボット負荷を熱平衡に達するまで動かして合否を決めることです。センサー入力、前処理、推論、後処理、制御メッセージを同時に実行し、P50・P95・P99遅延を温度、電力、CPU・GPU・メモリクロック、メモリ使用量、フレーム欠落と同じ時系列に記録します。

JetsonではNVIDIAのPlatform Power and Performanceで電力・熱管理を版ごとに確認できます。構成選定はCPU・GPU・NPU比較、配置はロボットのエッジAI、入力設計はロボットセンサー、駆動部の熱はロボット関節の熱管理として分けます。

TOPSは演算上限でありロボットの持続応答時間ではない

TOPSは演算形式と数値精度に依存する指標です。カメラ復号、コピー、CPU前処理、メモリ競合、推論、後処理、計画、ROS 2通信を含むカメラから指令までの時間は自動的に分かりません。

冷えた開放ベンチでの短い測定では、ファン、ヒートシンク、密閉筐体が熱を持った後のクロックも分かりません。巡回終了間際にも制御期限を守れるかが採用条件です。

報告書にはモジュールSKU、キャリア、Jetson Linux・JetPack、CUDA、TensorRT、カーネル、モデルハッシュ、精度、電力モード、ファン設定、ヒートシンク、筐体を記載します。Jetson Thor r39.2機能表が示すように製品系列とリリースで対応機能は変わります。

対応するOrin版では、例えば`sudo nvpmodel -q`で現在モードを確認し、`/etc/nvpmodel.conf`と同じ版の資料でモードIDと周波数上限を照合します。最大クロックを強制した結果と、実機で使う電力モードの結果は分けて保存します。

本番のカメラ台数・解像度・フレーム率、LiDAR解析、時刻同期、前処理、検出器やVLA、後処理、地図更新、ログ、通信、制御発行を全て有効にします。エンジンだけを反復するとCPU・メモリ・I/O競合が消え、結果が良く見えます。

NVIDIA Jetson Test Planは負荷中のCPU・GPU・EMC周波数を確認し、`tegrastats`で周波数、温度、電力、メモリを監視します。各処理境界のタイムスタンプも加え、期限超過した段階を特定します。

試験時間を一律10分にせず、温度とクロックが平衡になるまで、または実任務のデューティサイクル全体のうち長い方を採用します。最高外気温、日射、汚れたフィルター、吸気制限、電池電圧、隣接発熱部品も含めます。

NVIDIAの熱アラート検証は長時間の複数負荷で温度を上げ、trip pointとthrottle alertを確認します。製品試験では前後のクロック低下、P99上昇、フレーム欠落、回復時間も記録します。

TensorRT 11.2.1ベンチマークガイドを使う場合、エンジン、入力shape、バッチ、ストリーム数、精度、ウォームアップ、測定区間を固定します。転送を除いたエンジン遅延をアプリ全体の遅延として扱ってはいけません。

スループットが高くてもP99が制御周期を超えることがあります。開始5分と熱安定後の区間を比較し、遅延分布を温度・クロックに重ねて持続性能の低下率を報告します。

サーマルスロットリングは温度上限を守るためにハードウェアがクロックを下げる動作です。アプリケーションのレート制限はソフトウェアが意図して実行頻度を下げる方策であり、ログ上で区別します。

合格表には高温安定時のP95・P99、期限超過率、センサー欠落、最低クロック、最高温度、平均・ピーク電力、メモリ余裕、再起動・回復を含めます。Jetson以外の計算機にも同等の温度・電力・クロック・メモリ情報を要求します。

いいえ。数値精度、メモリ帯域、前後処理、センサーI/O、電力モード、サーマルスロットリングで全体遅延は変わります。実パイプラインの持続P95・P99を測ります。

一律の時間はありません。温度とクロックが安定するまで、または任務の全デューティサイクルを再現するまでの長い方を使います。

できません。システムの温度・電力・クロック・メモリは分かりますが、センサーから行動までの遅延、欠落、期限超過はアプリ側のタイムスタンプが必要です。

2026-08-07