Triton チュートリアル - 最適化

ここに画像の説明を挿入

Triton シリーズのチュートリアル:

記事ディレクトリ

Triton チュートリアル --- 最適化

Triton Inference Server には、レイテンシを短縮し、モデルのスループットを向上させるために使用できる機能が多数あります。このセクションでは、これらの機能について説明し、それらを使用してモデルのパフォーマンスを向上させる方法を示します。前提条件として、クイックスタートに従って、サンプルモデルリポジトリを使用して Triton およびクライアントサンプルを実行する必要があります。

このセクションでは、個々のモデルのレイテンシーとスループットのトレードオフを理解することに重点を置きます。「モデルアナライザー」セクションでは、モデルの GPU メモリ使用率を理解し、単一の GPU で複数のモデルを実行する最適な方法を決定できるようにするツールについて説明します。

Triton でモデルのパフォーマンスを測定するのに適したクライアントアプリケーションをすでに持っている場合を除き、パフォーマンスアナライザーについてはよく知っておく必要があります。パフォーマンスアナライザーは、モデルのパフォーマンスを最適化するための重要なツールです。

最適化機能とオプションを示す実行例として、TensorFlow Inception モデルを使用します。これは、クイックスタートに従って入手できます。ベースラインとして、perf_analyzer を使用して、パフォーマンス機能を有効にしていない基本モデル構成を使用してモデルのパフォーマンスを決定します。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 62.6 infer/sec, latency 21371 usec
Concurrency: 2, throughput: 73.2 infer/sec, latency 34381 usec
Concurrency: 3, throughput: 73.2 infer/sec, latency 50298 usec
Concurrency: 4, throughput: 73.4 infer/sec, latency 65569 usec

結果は、最適化されていないモデル構成が 1 秒あたり約 73 推論のスループットを提供することを示しています。同時リクエストが 1 つから 2 つになるとスループットが劇的に増加し、その後スループットが横ばいになることに注目してください。同時リクエストの場合、応答がクライアントに返されてからサーバーが次のリクエストを受信するまでの間、Triton はアイドル状態になります。Triton は 1 つのリクエストの処理を別のリクエストの通信とオーバーラップさせるため、同時実行によりスループットが増加します。Triton と同じシステム上で perf_analyzer を実行しているため、通信遅延を完全に隠すには 2 つのリクエストで十分です。

最適化設定

ほとんどのモデルで、最大のパフォーマンス向上をもたらす Triton 機能は動的。この例は、概念的な詳細をより明確に示しています。モデルがバッチ処理をサポートしていない場合は、モデルインスタンスに進んでください。

動的バッチプログラム

動的バッチャーは、個々の推論リクエストをより大きなバッチに結合します。これは多くの場合、個々のリクエストを個別に実行するよりも効率的です。動的バッチャーが Triton を停止できるようにするには、次の行をinception_graphdef モデル構成ファイルの末尾に追加し、Triton を再起動します。

dynamic_batching {
    
     }

動的バッチャーにより、Triton は推論のために結合されるより多くの同時リクエストを処理できるようになります。これを確認するには、perf_analyzer を 1 ～ 8 の同時リクエストで実行します。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 66.8 infer/sec, latency 19785 usec
Concurrency: 2, throughput: 80.8 infer/sec, latency 30732 usec
Concurrency: 3, throughput: 118 infer/sec, latency 32968 usec
Concurrency: 4, throughput: 165.2 infer/sec, latency 32974 usec
Concurrency: 5, throughput: 194.4 infer/sec, latency 33035 usec
Concurrency: 6, throughput: 217.6 infer/sec, latency 34258 usec
Concurrency: 7, throughput: 249.8 infer/sec, latency 34522 usec
Concurrency: 8, throughput: 272 infer/sec, latency 35988 usec

8 つの同時リクエストの場合、動的バッチャーを使用すると、動的バッチャーを使用しない場合と比較してレイテンシーの増加なく、Triton は 1 秒あたり 272 回の推論を実行できます。

perf_analyzer にさまざまなリクエスト同時実行値のデータを収集させる代わりに、いくつかの単純なルールを使用できます。これらのルールは通常、perf_analyzer が Triton と同じシステムで実行されている場合に適用されます。最初のルールは、待ち時間を最小限に抑え、リクエストの同時実行数を 1 に設定し、動的バッチャーを無効にして、モデルインスタンスを1 つだけ使用することです。2 番目のルールは、スループットを最大にするために、リクエストの同時実行数をに設定することです2 * <maximum batch size> * <model instance count>。モデルインスタンスについては以下で説明しますが、現在はモデルインスタンスを使用して作業しています。したがって、の場合maximum-batch-size 4、リクエストの同時実行2 * 4 * 1 = 8数。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 8
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 8, throughput: 267.8 infer/sec, latency 35590 usec

モデルインスタンス

Triton では、推論に使用する各モデルのレプリカの数を指定できます。デフォルトでは、各モデルのコピーを 1 つ取得しますが、インスタンスグループを使用してモデル構成で任意の数のインスタンスを指定できます。一般に、モデルのインスタンスが 2 つあると、メモリ転送操作 (例: CPU から GPU へ/GPU から) が推論計算とオーバーラップできるため、パフォーマンスが向上します。複数のインスタンスにより、GPU 上でより多くの推論作業を同時に実行できるため、GPU の使用率も向上します。小規模なモデルでは、3 つ以上のインスタンスからメリットが得られる場合があるため、perf_analyzer を試してみることができます。

inception_graphdef モデルの 2 つのインスタンスを指定するには: Triton を停止し、以前にモデル構成に追加した動的バッチ設定を削除し (動的バッチャーと複数のモデルインスタンスの組み合わせについては以下で説明します)、次の行をモデル構成ファイルに追加します。トリトンを再起動します。

instance_group [ {
    
     count: 2 }]

次に、ベースラインと同じオプションを使用して perf_analyzer を実行します。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 70.6 infer/sec, latency 19547 usec
Concurrency: 2, throughput: 106.6 infer/sec, latency 23532 usec
Concurrency: 3, throughput: 110.2 infer/sec, latency 36649 usec
Concurrency: 4, throughput: 108.6 infer/sec, latency 43588 usec

この場合、モデルのインスタンスが 2 つあることで、1 つのインスタンスと比較して、スループットが 1 秒あたり約 73 推論から 1 秒あたり約 110 推論に増加しました。

動的バッチャーと複数のモデルインスタンスは、たとえば、次の内容を含むようにモデル構成ファイルを変更することによって、同時に有効にすることができます。

dynamic_batching {
    
     }
instance_group [ {
    
     count: 2 }]

上記の動的バッチプログラムと同じオプションを指定して perf_analyzer を実行すると。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 16
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 16, throughput: 289.6 infer/sec, latency 59817 usec

動的バッチャーと 1 つのインスタンスのみを使用した場合と比較して、2 つのインスタンスではスループットは向上しないものの、レイテンシは増加していることがわかります。これは、このモデルでは動的バッチャーのみが GPU を最大限に利用できるため、追加のモデルインスタンスを追加してもパフォーマンス上の利点が得られないために発生します。一般に、動的バッチャーと複数のインスタンスの利点はモデル固有であるため、perf_analyzer を試して、スループットとレイテンシの要件を最もよく満たす設定を決定する必要があります。

フレームワーク固有の最適化

Triton には、サポートされているモデルフレームワークのサブセットにのみ適用される最適化設定がいくつかあります。これらの最適化設定は、モデル構成の最適化戦略によって制御されます。エンドツーエンドのディスカッションについては、このガイドを参照してください。

TensorRT 最適化を備えた ONNX (ORT-TRT)

特に強力な最適化は、TensorRT を ONNX モデルで使用することです。ONNX モデルに適用される TensorRT 最適化の例として、ONNX DenseNet モデルを使用します。これは、クイックスタートに従って取得できます。ベースラインとして、perf_analyzer を使用して、パフォーマンス機能を有効にしていない基本モデル構成を使用してモデルのパフォーマンスを決定します。

$ perf_analyzer -m densenet_onnx --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 113.2 infer/sec, latency 8939 usec
Concurrency: 2, 138.2 infer/sec, latency 14548 usec
Concurrency: 3, 137.2 infer/sec, latency 21947 usec
Concurrency: 4, 136.8 infer/sec, latency 29661 usec

モデルの TensorRT 最適化を有効にするには: Triton を停止し、モデル構成ファイルの末尾に次の行を追加して、Triton を再起動します。

optimization {
    
     execution_accelerators {
    
    
  gpu_execution_accelerator : [ {
    
    
    name : "tensorrt"
    parameters {
    
     key: "precision_mode" value: "FP16" }
    parameters {
    
     key: "max_workspace_size_bytes" value: "1073741824" }
    }]
}}

Triton が起動したら、コンソール出力を確認し、Triton が「Staring endpoints」メッセージを出力するまで待つ必要があります。TensorRT 最適化が有効になっている場合、ONNX モデルの読み込みが大幅に遅くなる可能性があります。運用環境では、モデルのウォームアップを使用して、このモデルの起動/最適化の速度低下を回避できます。次に、ベースラインと同じオプションを使用して perf_analyzer を実行します。

$ perf_analyzer -m densenet_onnx --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, 190.6 infer/sec, latency 5384 usec
Concurrency: 2, 273.8 infer/sec, latency 7347 usec
Concurrency: 3, 272.2 infer/sec, latency 11046 usec
Concurrency: 4, 266.8 infer/sec, latency 15089 usec

TensorRT の最適化により、スループットが 2 倍向上し、レイテンシが半分に削減されます。TensorRT が提供する利点はモデルによって異なりますが、一般に、大幅なパフォーマンスの向上が得られます。

ONNX と OpenVINO の最適化

CPU 上で実行される ONNX モデルは、OpenVINO を使用して高速化することもできます。ONNX モデルの OpenVINO 最適化を有効にするには、モデル構成ファイルの末尾に次の行を追加します。

optimization {
    
     execution_accelerators {
    
    
  cpu_execution_accelerator : [ {
    
    
    name : "openvino"
  }]
}}

TensorFlow および TensorRT の最適化 (TF-TRT)

TensorFlow モデルに適用される TensorRT 最適化は、上で説明した TensorRT および ONNX と同様に機能します。TensorRT の最適化を有効にするには、モデル構成を適切に設定する必要があります。TensorFlow モデルの TensorRT 最適化では、計算精度の選択など、いくつかのオプションを有効にすることができます。

optimization {
    
     execution_accelerators {
    
    
  gpu_execution_accelerator : [ {
    
    
    name : "tensorrt"
    parameters {
    
     key: "precision_mode" value: "FP16" }}]
}}

これらのオプションについては、モデル構成 protobuf のModelOptimizationPolicyセクションで詳しく説明されています。

TensorFlow モデルに適用される TensorRT 最適化の例として、TensorFlow Inception モデルを使用します。これは、クイックスタートに従って入手できます。ベースラインとして、perf_analyzer を使用して、パフォーマンス機能を有効にしていない基本モデル構成を使用してモデルのパフォーマンスを決定します。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 62.6 infer/sec, latency 21371 usec
Concurrency: 2, throughput: 73.2 infer/sec, latency 34381 usec
Concurrency: 3, throughput: 73.2 infer/sec, latency 50298 usec
Concurrency: 4, throughput: 73.4 infer/sec, latency 65569 usec

モデルの TensorRT 最適化を有効にするには: Triton を停止し、上記の行をモデル構成ファイルの最後に追加してから、Triton を再起動します。Triton が起動したら、コンソール出力を確認し、サーバーが「Staring endpoints」メッセージを出力するまで待つ必要があります。次に、ベースラインと同じオプションを使用して perf_analyzer を実行します。TensorRT の最適化は推論リクエストの受信時に実行され、時間がかかる可能性があるため、perf_analyzer の初回実行はタイムアウトになる可能性があることに注意してください。運用環境では、モデルのウォームアップを使用して、このモデルの起動/最適化の速度低下を回避できます。この問題が発生した場合は、perf_analyzer を再度実行してください。

$ perf_analyzer -m inception_graphdef --percentile=95 --concurrency-range 1:4
...
Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 140 infer/sec, latency 8987 usec
Concurrency: 2, throughput: 195.6 infer/sec, latency 12583 usec
Concurrency: 3, throughput: 189 infer/sec, latency 19020 usec
Concurrency: 4, throughput: 191.6 infer/sec, latency 24622 usec

TensorRT の最適化により、スループットが 2.5 倍向上し、レイテンシが半分以上削減されます。TensorRT が提供する利点はモデルによって異なりますが、一般に、大幅なパフォーマンスの向上が得られます。

TensorFlow JIT グラフの最適化

Tensorflow を使用すると、ユーザーは GlobalJitLevel 設定を通じてモデルグラフを実行するときに最適化レベルを指定できます。詳細については、 config.protoを参照してください。Triton で TensorFlow モデルを実行する場合、ユーザーは以下に示すようにレベルを指定することでこの設定を行うことができます。

optimization {
    
    
  graph {
    
     level: 1
}}

ユーザーは、Triton を起動する前に TF_XLA_FLAGS 環境変数を設定することによって、XLA 最適化を利用することもできます。GPU と CPU の自動クラスタリングを使用して Triton を起動する例:

$ TF_XLA_FLAGS="--tf_xla_auto_jit=2 --tf_xla_cpu_global_jit" tritonserver --model-repository=...

上記の TensorRT 最適化の場合と同様、これらの最適化は最初の推論リクエストの実行時に発生します。実稼働システムでのモデルの起動の速度の低下を軽減するには、モデルのウォームアップを使用できます。

TensorFlow 自動 FP16 最適化

TensorFlow には、モデル設定で有効にできる FP16 最適化を提供するオプションがあります。上記の TensorRT 最適化と同様に、この最適化は gpu_execution_accelerator プロパティを使用して有効にすることができます。

optimization {
    
     execution_accelerators {
    
    
  gpu_execution_accelerator : [
    {
    
     name : "auto_mixed_precision" }
  ]
}}

モデル構成 protobuf のModelOptimizationPolicy セクションで、これらのオプションについて詳しく説明します。

TensorRT について上記で説明した手順に従い、perf_analyzer を使用して最適化の有無にかかわらずパフォーマンスを評価することで、この自動 FP16 最適化がモデルにどのようなメリットをもたらすかを確認できます。

NUMA に最適化された

最新の CPU の多くは、複数のコア、メモリ、相互接続で構成されており、スレッドとデータの割り当て方法に応じて異なるパフォーマンス特性を示します。Triton を使用すると、この NUMA 構成を記述するシステムのホストポリシーを設定し、モデルインスタンスをさまざまなホストポリシーに割り当てて、これらの NUMA プロパティを活用できます。

ホストポリシー

Triton では、起動時にポリシー名に関連付けられたホストポリシーを指定できます。インスタンスグループのホストポリシーフィールドを使用して同じポリシー名のインスタンスが指定されている場合、そのホストポリシーがモデルインスタンスに適用されます。指定しない場合、ホストポリシーフィールドはインスタンスのプロパティに基づいてデフォルト名に設定されることに注意してください。

ホストポリシーを指定するには、コマンドラインオプションで次を指定できます。

--host-policy=<policy_name>,<setting>=<value>

現在サポートされている設定は次のとおりです。

uma-node: ホストポリシーがバインドされる NUMA ノード ID。ホストポリシーは、指定されたノードへのメモリ割り当てを制限します。
cpu-cores: 実行する CPU コア。このホストポリシーが設定されたインスタンスは、CPU コアの 1 つで実行されます。

システムが GPU 0 を 0 ～ 15 の CPU コアを備えた NUMA ノード 0 にバインドするように構成されていると仮定すると、次は「gpu_0」の uma-node ポリシーと cpu-cores ポリシーの設定を示しています。

$ tritonserver --host-policy=gpu_0,numa-node=0 --host-policy=gpu_0,cpu-cores=0-15 ...