今月も 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 の環境向けの対応強化など、すぐに活用いただける機能が増えてきたかと思います。過去検討していたけど懸念が払拭できず導入を斷念された方でも、隨時機能拡張や改善が行われていますので、定期的にご確認ください。
その他、疑問點や問題點がある場合や、日本語で要望を書きたいという方など、お気軽にお知らせいただければと思います。
