Ultralytics 8.4.157がCUDA Graphリプレイを導入、YOLO26nのFP16テストでレイテンシーが約20%短縮

Ultralyticsは9月20日、8.4.157をリリースし、YOLOモデルのTensorRTエクスポートと実行経路を改善した。パッケージはPyPIでも公開されている。今回の効果は、演算精度のキャリブレーションとカーネル起動時のオーバーヘッドの調整によるものだ。既存のモデル重みを引き続き使えるが、デプロイ環境での処理を改めて測定する必要がある。[リリースノート](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.157)、[パッケージ履歴](https://pypi.org/project/ultralytics/8.4.157/)。

最初の変更はTensorRT 11の混合精度変換にある。従来はランダムノイズを使ってキャリブレーションしていたため、前段の活性化値が大きくなり、一部の畳み込みがFP32のまま残る可能性があった。新版では同梱の実画像を使い、表現範囲に収まる演算をFP16に変換する。このエクスポートの改善を適用するには、エンジンの再ビルドが必要になる。[エクスポート処理のコード](https://github.com/ultralytics/ultralytics/blob/v8.4.157/ultralytics/utils/export/engine.py)。

もう一つの変更は、条件を満たす固定形状エンジンの読み込み時にCUDA Graphをキャプチャすることだ。以降は入力を固定バッファーにコピーし、グラフをリプレイすることで、カーネルを毎回起動するコストを減らす。動的形状、DLA、非最大値抑制（NMS）を組み込んだエンジンでは、この経路を使わない。実行の投入が拒否された場合もフォールバックし、空のグラフをリプレイして古い出力が残ることを防ぐ。固定サイズかつ小さいバッチで動作する画像処理サービスには、スケジューリングのコストを削減する具体的な手段となる。サイズが変わるリクエストには、別途バッチ処理の戦略を選ぶ必要がある。[実行処理のコード](https://github.com/ultralytics/ultralytics/blob/v8.4.157/ultralytics/nn/backends/tensorrt.py)。

メンテナーがRTX PRO 6000 Blackwell、TensorRT 11.3、640ピクセルの入力でテストしたところ、YOLO26nのバッチサイズ1のFP16エンジンのレイテンシーは0.526ミリ秒から0.421ミリ秒へと約20%短縮した。YOLO26sではバッチサイズ1のINT8で約18%短縮した一方、バッチサイズ8のINT8ではほとんど改善がなかった。測定対象はエンジンの呼び出しとデバイスの同期のみで、精度の確認には小規模なcoco128を使っているため、結果をそのままサービス全体のスループットと見なすことはできない。[最終テスト](https://github.com/ultralytics/ultralytics/pull/26223)。

リリースノートにはSiLU活性化の融合に関する書き換えが引き続き記載されているが、最終レビューでは撤回された。メンテナーは、この融合には誤コンパイルのリスクがあり、分類スコアだけを比較するテストではバウンディングボックスの座標の誤りを見逃す可能性もあると指摘した。そのため、今回の更新は実際にマージされた内容に基づいて評価すべきだ。[レビュー記録](https://github.com/ultralytics/ultralytics/pull/26223)。

技術的な検証では、ハードウェア、バッチサイズ、入力サイズを固定し、ウォームアップ後のレイテンシー、データセット全体での精度、エンドツーエンドの処理時間を比較するのが望ましい。公式ドキュメントもINT8の効果はキャリブレーションデータとハードウェアに依存すると注意を促しており、演算精度を下げても、あらゆるワークロードで高速化するとは限らない。リアルタイムのカメラサービスでの推論を例に取ると、デコード、リサイズ、データ転送、後処理が依然として処理時間の大半を占める可能性がある。エンジンの処理が0.1ミリ秒短くなっても、画像1枚全体の処理時間が同じ割合で短くなるとは限らない。導入担当者は更新前後のビルド設定を保存し、エンジンとアプリケーションの速度測定を分けて記録するとよい。[デプロイに関するドキュメント](https://docs.ultralytics.com/integrations/tensorrt)。