2022 年 9 月末にリリースされた Triton Inference Server の各機能などについて、概要をお届けします。「Triton Inference Server って何?」という方は、以下の記事などをご確認ください。
What’s New in 2.26.0 (NGC 22.09)
リリース ノート本体は https://github.com/triton-inference-server/server/releases/tag/v2.26.0 です。このリリースには以下の機能や改善などが含まれています。
- Triton Core ライブラリとの連携を容易にするための Developer Tools が新しくできました (ベータ)
- Metrics に CPU 関連の情報が追加されました
- 動的にログ設定を変更するインターフェイスとして logging protocol extension が追加されました
- TensorRT バックエンド利用時、
LD_PRELOADに加えてコマンドライン オプション経由でも、カスタム プラグインを指定できるようになりました - OpenVINO バックエンドで、設定の自動補完を有効化できるようになりました
- Python バックエンド内でのログ出力が、Triton のログ機構に統合されました
- Model Analyzer に quick search のためのアルゴリズムが追加されました
- Perf Analyzer に GPU metrics の収集機能が追加されました
今月は全体的に細かい更新が多いですが、ログ操作周り、特に Python バックエンド内でのロギングが統合されたのは、地味ながら大きな変更ではないでしょうか。また、Triton Core ライブラリとの連携を容易にするための Developer Tools も、独自のスタンドアロン アプリケーションに Triton の機能を組み込みたい場合に、大きな助けとなりそうです。
Developer Tools の詳細は、公式の README.md に詳しく書かれていますが、従来から存在した In-Process API に対するラッパー ライブラリである、というのが最もシンプルな説明となります。In-Process API を直接利用することで、自由に Triton の持つコア機能をそれぞれのアプリケーションへ組み込み、例えば通信プロトコルのオーバーヘッドを回避する形でアプリケーションを実装したりできます。一方で、低レイヤーの API ということもあり、利用には多少の習熟が必要でした。今回の対応により、より抽象化されたわかりやすい形で API が提供されるようになるため、より簡単にアプリケーションへの機能組み込みを実現できるようになります。
また、Python バックエンドのロギング機構が整理され、triton_python_backend_utils.Logger を利用することで、より素直な形でログ出力を行うことができるようになります。これまでは print() などを利用することもあったかと思いますが、これ以降は統合された API でロギングが可能となります。更なる詳細はドキュメントをご覧ください。
What’s New 以外のアップデート
今月の、What’s New で言及されていない更新点は以下の通りです。
- 複数の Triton を同じマシン上に起動する際、HTTP および gRPC のそれぞれについて、共通のポート番号を利用できるようになります (PR#4732)
- OpenVINO のバージョンが 2022.1 に更新されました (PR#4751)
- プラットフォームごとのデバイス対応状況についてドキュメントが整備されました (PR#4760)
最初の共通のポート番号を利用できる件は、分かりづらいのでここで少し解説します。
従来、Triton Inference Server のコンテナーが起動しているマシン上に、ホスト側の同じポートを指定する形でもうひとつコンテナーを起動しようとすると、ポートを listen できずにエラーを吐いて起動に失敗していました。例えば Unavailable - Socket '0.0.0.0:8001' already in use のようなメッセージとともに起動失敗する、という挙動です。一般的なサーバー アプリケーションとしてはよくある挙動ですが、今回の対応によって、このエラーを回避し、同一ポートで複数のサーバー プロセスがリクエストを待ち受けられるようになります。
具体的には、同一ポート待ち受けを有効化したいプロトコルに対して、Triton 起動時に有効化のオプションを追加するだけです。HTTP で許可したい場合 --reuse-http-port=1 を、gRPC で許可したい場合 --reuse-grpc-port=1 を指定します。同時に指定しても OK です。例えば、tritonserver --model-repository /models --http-port 8000 --grpc-port 8001 --metrics-port 8002 --reuse-http-port=1 --reuse-grpc-port=1 とした場合、HTTP および gRPC のどちらも、複数の Triton が listen できるようになります。なおコマンドから推測できるかもしれませんが、metrics のエンドポイントは一意になる必要があるため、ポートの再利用はできません。
この機能の用途ですが、現時点では負荷分散目的の利用が想定されています。そのため、起動するコンテナーには、いずれも同じモデルが同じようにデプロイされている必要があります。仮に異なるモデルがデプロイされているような場合、あるリクエストは問題なく動作し、別のリクエストはモデルが見つからずエラーとなる、といった問題が発生します。
まとめ
今月は、細かい使い勝手を向上させるような更新が多く含まれていました。詳細について言及していませんが、Model Analyzer の探索ロジックが改善されたことも、Triton を本番適用していくためには重要です。今後も継続的に改善が続けられると思いますので、定期的に更新内容をご確認いただければ幸いです。また機能要望などあれば、公式リポジトリに issue を上げていただけるとありがたいです。
