Triton チュートリアル — Triton レスポンス キャッシング
Triton シリーズのチュートリアル:
- クイックスタート
- Triton を使用して独自のモデルをデプロイする
- トリトンの建築
- 模型倉庫
- ストレージエージェント
- モデル設定
- 最適化
- 動的バッチ処理
- レートリミッター
- モデル管理
- カスタム演算子
- バックエンドとモデルの分離
概要
このドキュメントでは、推論リクエストは、Triton に送信されるリクエストを構成するモデル名、モデル バージョン、および入力テンソル (名前、形状、データ型、およびテンソル データ) です。推論結果は、推論の実行によって生成される出力テンソル (名前、形状、データ型、およびテンソル データ) です。Triton は、応答キャッシュを使用して、以前に実行された推論リクエストによって生成された推論結果を保持します。Triton は応答のキャッシュを維持するため、キャッシュにヒットした推論リクエストは結果を生成するためにモデルを実行する必要がなく、代わりにキャッシュから結果を取得します。一部のユースケースでは、これにより推論リクエストのレイテンシーが大幅に短縮される可能性があります。
Triton は、推論リクエストのハッシュを使用して、モデル名、モデル バージョン、モデル入力を含む応答キャッシュにアクセスします。ハッシュがキャッシュ内で見つかった場合、対応する推論結果がキャッシュからフェッチされ、リクエストに使用されます。これが発生すると、Triton は推論結果を生成するためにモデルを実行する必要がありません。ハッシュがキャッシュ内に見つからない場合、Triton はモデルを実行して推論結果を生成し、その結果を後続の推論リクエストで (再) 使用できるようにキャッシュに記録します。
使用法
特定のモデルでキャッシュを使用するには、サーバー側とモデルのモデル構成の両方でキャッシュを有効にする必要があります。詳細については、以下のセクションを参照してください。
サーバー側でのキャッシュの有効化
Triton サーバーの起動時に対応する構成を指定して<cache_implementation>、サーバー側で応答キャッシュを有効にします。
CLI を介して、これは設定に変換されますtritonserver --cache-config <cache_implementation>,<key>=<value> ...。例えば：
tritonserver --cache-config local,size=1048576
インプロセス C API アプリケーションの場合、これは call に変換されますTRITONSERVER_SetCacheConfig(const char* cache_implementation, const char* config_json)。
これにより、ユーザーはサーバーの起動時にキャッシュをグローバルに有効/無効にすることができます。
モデルのキャッシュを有効にする
デフォルトでは、応答キャッシュが --cache-config フラグでグローバルに有効になっている場合でも、応答キャッシュを使用するモデルはありません。
特定のモデルで応答キャッシュを使用するには、そのモデルのモデル構成でも応答キャッシュが有効になっている必要があります。
# config.pbtxt
response_cache {
enable: true
}
これにより、ユーザーは特定のモデルのキャッシュを有効/無効にすることができます。
各モデルの応答キャッシュを有効にする方法の詳細については、モデル設定のドキュメントを参照してください。
キャッシュの実装
バージョン 23.03 以降、Triton にはTRITONCACHE APIユーザーが選択したキャッシュ実装と通信するためのセットが含まれています。
キャッシュ実装は、必要な TRITONCACHE API を実装する共有ライブラリであり、サーバーの起動時に動的にロードされます (有効な場合)。タグ 23.03 以上の場合、tritonserver パブリッシュ コンテナには、すぐに使用できる次のキャッシュ実装が付属しています。
地元：
/opt/tritonserver/caches/local/libtritoncache_local.so
これらの を使用してTRITONCACHE API、 tritonserver は新しい--cache-config CLIフラグ、ユーザーが使用するキャッシュ実装とその構成方法を柔軟にカスタマイズできるようにします。--backend-configflagと同様に、予期される形式は であり--cache-config <cache_name>,<key>=<value>、キャッシュ実装で必要な場合は、複数回指定して複数のキーを指定できます。
ローカルキャッシュ
ローカル キャッシュの実装は、バージョン 23.03 より前に内部で使用されていた応答キャッシュと同等です。より具体的な実装の詳細については、 「ローカル キャッシュの実装」を参照してください。
ゼロ以外の SIZE を指定する--cache-config local,size=SIZEと、Triton は要求されたサイズを CPU メモリに割り当て、すべての推論リクエストとすべてのモデルでキャッシュを共有します。
カスタムキャッシュ
新しい TRITONCACHE API インターフェイスを使用すると、ユーザーは独自のキャッシュを実装して、あらゆるユースケースの特定のニーズを満たすことができるようになりました。キャッシュ開発者が実装する必要があるインターフェイスを確認するには、TRITONCACHE API ヘッダー ファイル を参照してください。ローカル キャッシュ実装はリファレンス実装として使用できます。
カスタム キャッシュの開発と構築が成功したら、結果の共有ライブラリ (例: libtritoncache_<name>.so) を、ローカル キャッシュ実装が存在する場所と同様のキャッシュ ディレクトリに配置する必要があります。デフォルトでは、このディレクトリは です/opt/tritonserver/cachesが、必要に応じて を使用してカスタム ディレクトリを--cache-dir指定。
この例をまとめると、カスタム キャッシュの名前が「custom」(名前は任意) の場合、デフォルトで Triton は でキャッシュ実装を/opt/tritonserver/caches/custom/libtritoncache_custom.so見つける。
埋め込む
応答キャッシュは、多数のリクエストの繰り返し (キャッシュ ヒット) が予想されるユースケースを対象としており、キャッシュのメリットが得られます。ここでの「重要」という用語はユースケースによって異なりますが、簡単に解釈すると、予想されるキャッシュのヒット/ミスの比率と、応答の計算にかかる平均時間を考慮することになります。
キャッシュ ヒットが頻繁に発生し、計算コストがかかる場合は、キャッシュによって全体のパフォーマンスが大幅に向上します。
すべてまたはほとんどのリクエストが一意である場合 (キャッシュ ミス)、キャッシュ管理のオーバーヘッドにより、キャッシュが全体的なパフォーマンスに悪影響を与える可能性があります。
既知の制限事項
-
CPU メモリ内にある入力テンソルのみをハッシュしてキャッシュにアクセスできます。推論リクエストに CPU メモリにない入力テンソルが含まれている場合、リクエストはハッシュされないため、応答はキャッシュされません。
-
すべての出力テンソルが CPU メモリに配置されている応答のみがキャッシュの対象となります。応答内の出力テンソルのいずれかが CPU メモリにない場合、応答はキャッシュされません。
-
キャッシュには、投機的リクエスト ハッシュを使用してのみアクセスされます。したがって、2 つの異なる推論リクエストが同じハッシュを生成した場合 (ハッシュ衝突)、Triton は推論リクエストに対してキャッシュされた結果を誤って使用する可能性があります。ハッシュ値は 64 ビット値であるため、衝突が発生する可能性は非常に低いです。
-
成功した推論リクエストのみがその応答をキャッシュします。推論中にリクエストが失敗するかエラーを返した場合、そのレスポンスはキャッシュされません。
-
デフォルトのスケジューラまたは動的バッチ スケジューラを経由するリクエストのみがキャッシュの対象となります。Sequence Batcher は現在、応答のキャッシュをサポートしていません。
-
応答キャッシュは現在、分離モデルをサポートしていません。