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

メモリ帯域 on Physical AI Hub