推論レイテンシーをプロファイルして調整する

計測しなければ調整できません。設定を変更する前に、信頼できる負荷をかけて実際のレイテンシとスループットを記録してください。📏

Tritonにはperf_analyzerが付属しています。これはモデルに大量のリクエストを送り、レイテンシとスループットを報告するツールで、設定を比較するのに役立ちます。

perf_analyzerでモデルを指定すると、合成リクエストが送信され、1秒あたりの推論数とレイテンシの内訳が表示されます。

最も役立つフラグは同時実行数を変化させます。これは実行中のリクエスト数を表し、負荷が増えたときにスループットとレイテンシがどう変化するかを明らかにします。

同時実行数が増えると、スループットは上昇してから横ばいになりますが、レイテンシは増え続けます。その曲線の折れ曲がる点が、実用上の運用ポイントです。

平均値では問題が隠れてしまいます。p95レイテンシを確認してください。これは95%のリクエストが下回る値であり、ユーザーが実際に感じるのはテールレイテンシだからです。

レイテンシが高すぎる場合はmax_queue_delay_microsecondsを下げます。高負荷時のスループットが低すぎる場合は、値を上げてより大きなバッチを作ります。

GPUの使用率が低い場合はインスタンスを追加します。メモリに余裕がない場合やスループットが停止する場合は、1つ減らします。一度に1つの設定だけを変更し、再度計測してください。

調整は飛躍ではなく、繰り返しの作業です。1つの設定を変更し、perf_analyzerを再実行して比較します。数値が実際に改善した場合だけ、その変更を残します。

まず予算を決めます。たとえばp95を50ミリ秒未満にする、といった具合です。その制限内に収まる範囲で、バッチサイズとインスタンス数をできるだけ増やします。

サーバーの数値だけでは全体像を把握できません。ネットワークの経路やクライアントコードも時間を追加するため、ユーザーのいる場所からのエンドツーエンドのレイテンシも計測してください。

perf_analyzerで同時実行数を変化させ、p95におけるスループットとレイテンシの曲線を読み取り、予算内でキューの遅延とインスタンス数を一度に1つずつ調整しました。🙌