今月も Triton Inference Server のリリース内容について、概要をお届けします。「Triton Inference Server って何?」という方は、以下の記事などをご確認ください。
What’s New in 2.21.0 (NGC 22.04)
リリースノート本体は https://github.com/triton-inference-server/server/releases/tag/v2.21.0 です。今月のリリースには以下の機能や改善などが含まれています。
- 一定条件を満たす場合、ヘッダー相当のメタデータを省略したバイナリ形式のリクエストを投げられるようになりました
- モデル アンサンブルで optional input が利用できるようになったようです
- Python バックエンド以外は引き続き optional input 未対応のようです
- C++ カスタム バックエンドで、独自の metrics を追加定義できるようになりました
- これにより、標準提供されている以外に、独自の情報を metrics endpoint 経由で出力できるようになります
- 1 つの Triton から、複数のクラウドストレージを同時に参照できるようになりました
- たとえば、Amazon S3 を 2 か所、Google Cloud Storage を 2 か所指定して、すべての場所からモデルをロードすることができるようになります
- ONNX Runtime バックエンドでデバイス未指定時、デフォルトの挙動が変わります
- 従来のデフォルト動作は CPU のみ利用でしたが、今回のリリース以降は GPU がデフォルト デバイスになります
- コンテナーを自前ビルドする際、build.py が使用する一時ディレクトリを明示できるようになりました
- build.py および compose.py で、PyTorch と TensorFlow1 向けにも CPU-only コンテナーを作成可能になりました
先月までと比較して、今月は更新が多めです。特に重要なものとしては、「バイナリ形式のリクエストでメタデータ省略可能に」、「C++ カスタム バックエンドで独自 metrics の追加をサポート」あたりでしょうか。
以前から推論リクエスト時のデータ送信には、バイナリ フォーマットが利用できていました。一方で入力テンソルの形状やデータ型などを、メタデータとして同時に送信する必要がありました。送信データサイズによっては無視できるサイズではありますが、本体をバイナリで送信するのに対して、メタデータ部分は JSON フォーマットであるため、JSON テキストをパースするオーバーヘッドが発生してしまう状況でした。今回の更新で、一定条件 (=入力テンソルが 1 つ、かつデータ形状が、[1] (データ型: BYTE の場合) もしくは可変長の次元が高々 1 つ (データ型: BYTE 以外の場合)) を満たす場合、リクエスト ヘッダー Inference-Header-Content-Length に 0 を指定すれば、Content-Length などからデータサイズを推定して処理してくれるようになります。
また、C++ カスタム バックエンドでの独自 metrics 対応については、TRITONSERVER_MetricFamilyNew などの関数が追加され、独自の metrics を追加できるようになっています。詳細は Metrics – Custom Metrics にもある通り、identity_backend や Triton のコア API 定義である tritonserver.h をご覧ください。(注.tritonserver.h には 22.04 時点で関数定義されているのですが、ドキュメントや identity_backend の参考実装は 22.05 以降のブランチにのみ入っているようなので、バージョン等にはご注意いただければと思います)
What’s New に言及されていないアップデート
What’s New に加えて、今月は多数の更新が含まれています。
- PyTorch バックエンドで、 同一デバイスのインスタンス間で weight sharing できるようになりました (PR – pytorch_backend#54)
- PyTorch バックエンド利用時の入力テンソル名規約が拡張されました (PR – pytorch_backend#51)
- Triton 起動時にポートの衝突を検知する機構が追加されました (PR#4071)
- Triton が利用するアドレスを明示できるようになりました (PR#4136)
- Triton ビルド時に HTTP を無効化してビルドしても、metrics API には HTTP でアクセス可能になりました (PR#4175)
PyTorch バックエンドでの weight sharing については、Concurrent Model Execution でモデルのコピーを複数デプロイする際のメモリ消費を削減する機構になります。Triton では、instance_group.count で指定される数だけ同一モデルのコピーを作成して、並列実行度を上げることができます。一方でこれまでは、各コピーでモデル パラメーターのメモリ領域は個別に確保されていました。今回の対応で、同一デバイス上のコピー間でモデルのメモリ領域を共有するようになります。結果として、ロード時や推論時のメモリ消費を削減することが可能になります。なお注意点として、RNN 系のように中間状態を持つようなモデルでは、中間状態まで共有されてしまうため、weight sharing は使わないようにしてください。
PyTorch バックエンドでは、従来 TorchScript の制約から、INPUT__0 や OUTPUT__0 のように、機械的に付与された名称しか入出力テンソル名として利用できませんでした。(Special Conventions for PyTorch Backend) 今回の対応で、入力テンソル名については、元のモデルの forward() で定義されている引数名を入力テンソル名として利用可能になります。たとえば以下のようなモデルから生成された TorchScript をデプロイする場合、
class PseudoModel(nn.Module):
def forward(self, x, y):
x = 2 * x
y = y / 2
return x, y
これまでは以下のように、config.pbtxt には INPUT__0 のような名称しか指定できませんでした。
input [
{
name: "INPUT__0"
data_type: TYPE_FP32
dims: [ 10 ]
},
{
name: "INPUT__1"
data_type: TYPE_FP32
dims: [ 10 ]
}
]
今後は、以下のように x などを入力テンソル名として指定できます。
input [
{
name: "x"
data_type: TYPE_FP32
dims: [ 10 ]
},
{
name: "y"
data_type: TYPE_FP32
dims: [ 10 ]
}
]
なお、INPUT__0 形式と、forward() の引数名形式は同時に利用できない点にはご注意ください。たとえば後者のように、x などを入力テンソル名として指定した場合、クライアントからのリクエストに含める入力テンソル名も、INPUT__0 から x に変更する必要があります。(そのまま INPUT__0 でリクエストするとエラーになります。config.pbtxt で指定した名称が利用されます)
まとめ
今月は、性能に影響を与える改善を含め、更新が多めのリリースでした。その他にも、運用時の問題回避に有益な機能や、CPU only の環境向けの対応強化など、すぐに活用いただける機能が増えてきたかと思います。過去検討していたけど懸念が払拭できず導入を断念された方でも、随時機能拡張や改善が行われていますので、定期的にご確認ください。
その他、疑問点や問題点がある場合や、日本語で要望を書きたいという方など、お気軽にお知らせいただければと思います。
