Data Science

Triton Inference Server 2022 年 12 月 – 2023 年 2 月のリリース概要

Reading Time: 2 minutes

2022 年 12 月から 2023 年 2 月にかけてリリースされた Triton Inference Server の各機能などについて、概要をお届けします。「Triton Inference Server って何?」という方は、以下の記事などをご確認ください。

What’s New

今回の期間中リリースされたリリースノートの本体は、それぞれ以下の通りです。

各リリースには、以下の機能や変更が含まれていました。

  • Windows 上でのビルドが改善されました (2.29.0)
  • Dynamic batcher の挙動をカスタマイズできるようになりました (2.30.0)
  • Python クライアントにおける gRPC のバージョン要件が緩和されました (2.30.0)
    • 1.42.0 に固定されていたものが、1.41.0 以上、になっています
  • Model Analyzer で ensemble model がサポートされました (2.31.0)
  • gRPC の標準的なヘルスチェック プロトコルをサポートしました (2.31.0)
    • 一般的なツール (e.g., grpc-health-probe, Kubernetes liveness probes, etc) を利用可能になります
    • 詳細: PR#5267
  • Python バックエンドのモデル ロード中、断続的に発生しうるハングアップの問題を解消しました (2.31.0)

この期間で特筆すべきリリースは、dynamic batcher の挙動をカスタマイズ可能になった点と、Model Analyzer で ensemble model のサポートが入った点の 2 つです。

Dynamic batcher のカスタマイズは、その名の通り、dynamic batching で構築されるバッチの構築ルールをカスタマイズするものです。たとえば、リクエストあたりのバイト数をもとにバッチを構成したい、といった要求に対応することができるようになります。カスタマイズされたルールは、一定の規約に従い実装した共有ライブラリ (.so) を、対象モデルの config.pbtxt へパラメーターとして渡すことで有効化されます。具体的には、

parameters: { key: "TRITON_BATCH_STRATEGY_PATH", value: {string_value: "/path/to/libtriton_volumebatching.so"}}

のようなイメージです。以下のサンプルは、バッチに含まれるリクエストのバイト総量を計算し、指定した上限を超えないようにするものです。
https://github.com/triton-inference-server/backend/tree/r23.02/examples/batching_strategies/volume_batching
(概要などは https://github.com/triton-inference-server/backend/tree/r23.02/examples を参照してください)

なお本稿執筆時点で、以下の注意点があります。

  • TRITONBACKEND_ModelBatcherInitialize() による初期化中にエラーが発生すると、ログ メッセージ上ではエラー詳細が分からなくなる
  • TRITONBACKEND_ModelBatchIncludeRequest() でエラーを発生させると、エラー発生元のリクエストがキューに残り続け、エラー メッセージがログに出続ける
    • この事象自体はバグのようですが、そもそも custom batching 内部で入力の validation を行うことは想定されていないようです

2 つ目のポイントである、Model Analyzer での ensemble model サポートです。これまで、複数ステップからなる ensemble model に対する解析は、うまく実行できない状態となっていました。今回の対応では、一部制限はあるものの、複数ステップからなるパイプラインについても Model Analyzer による最適化が可能となります。なお、現時点における主な制限は以下の 3 つです。

  • 探索モードは quick のみのサポート
  • ステップ数 (= ensemble_scheduling に指定可能な step の個数) の最大値は 3
    • この制限は 23.03 で 4 に緩和されています
  • cpu_only オプションの設定不可

また、今回対象となるのはあくまで ensemble model であり、Python バックエンドでサポートされる BLS については対象外のようですので、ご注意ください。(と書いたものの、実は 23.04 で BLS もサポート対象になっています。詳細は後日。)

What’s New 以外のアップデート

今回、What’s New で言及されていない主な更新点は以下の通りです。

  1. TCMalloc がデフォルトでインストールされるようになります (PR#5118, PR#5161)
  2. TensorFlow の custom operator がロードされるタイミングを、モデル ロード時まで遅延させられるようになります (PR#4944)
  3. コンテナー イメージをカスタマイズする compose.py に、--skip-pull オプションが追加されました (PR#5186)
  4. 2.30.0 (NGC 23.01) から、CUDA のメジャー バージョンが 11.8 から 12.0 にアップグレードされています

TCMalloc のデフォルト インストール

TCMalloc は、PR#5118 でデフォルト ON となっていましたが、その後ロールバックなどを経て、「デフォルトでインストール済み、必要に応じて有効化する」という状況に落ち着いているようです。この変更は、ドキュメントにも記載されている通り、API を経由して動的にモデルをロード、アンロードする際、実際にはリークでないものの、リークを疑わせるようなメモリ消費増大への対策として導入されています。これは、デフォルトの malloc ではうまくメモリを解放できないことがあることによります。有効化手順等は、Model Control Mode EXPLICIT の後半を参照ください。

TensorFlow の custom operator ロード タイミング

従来、サーバー起動時にまとめてロードされていた、TensorFlow の custom operator を、モデル ロードのタイミングで個別にロードできるようになる、というものです。サーバー起動時にまとめてロードさせる場合は、これまでと同様、LD_PRELOAD に必要な共有ライブラリ (.so) を指定してサーバー起動すれば OK です。対象の custom operator を使用するモデルをロードするタイミングまで、ロードを遅らせる場合、個々の config.pbtxt に以下の設定を追加することになります。

model_operations { op_library_filename: "path/to/libtfcustom.so" }

この設定の定義は model_config.proto#L1688-L1701 をご覧ください。なお現時点では、サーバーを停止させるまで、モデルごとにロードされた custom operator をアンロードする方法がないようです。そのため、リソースの生存期間等については十分ご注意ください。

compose.py への --skip-pull オプション追加

compose.py への --skip-pull オプション追加については、オプション名が表す通りの変更内容です。コンテナー イメージをカスタマイズする際、これまでは、都度イメージをダウンロードしていたのですが、このオプションを指定することによって、事前にダウンロードしておいたイメージがある場合、ローカルのイメージをベースに利用することができるようになります。これにより、実行時間の短縮効果が期待できます。ただし、このオプションを指定している場合、ダウンロードを「一切」しないようですので、必要なイメージがすべて揃っているかどうか、あらかじめご確認いただく必要があるようです。

PyTriton のリリース: Flask / FastAPI like API

また最後に、この記事が対象とする期間から外れていますが、先月開催された GTC に合わせて、Flask や FastAPI like な インターフェースを提供するラッパー ライブラリである PyTriton がリリースされたので、ここで紹介させてください。

Triton Inference Server そのものは、主にコンテナーでの実行が想定されているため、気軽に試そうとするには docker などのコンテナー ランタイムをインストールする必要があり、ややハードルが高かったかと思います。今回、PyTriton は pip でのインストールがサポートされており、より簡単に Triton を試せるようになっています。内部実装の詳細や、使い方については後日記事化しようと思いますが、ざっくり以下のステップで Triton が利用可能になります。

  1. PyTriton をインストール
  2. 推論を実行する Python の関数を定義し、デコレーター @batch を付与
  3. pytriton.triton.Triton をインスタンス化し、bind() でモデル名や設定等を定義し、推論実行用の関数をセット
  4. pytriton.triton.Triton.serve() でサーバー起動

クライアントは Triton のクライアント ライブラリをそのまま利用することもできそうですし、PyTriton にも pytriton.client.ModelClient として同梱されているため、追加インストール等不要で利用することもできるようです。

まとめ

今回は、Triton の機能を拡張、カスタマイズできるようにする機能が追加されたり、細かいオーバーヘッドなどを削減し、最適化に寄与するような変更がいくつか入っていたように思います。また、PyTriton のような利便性を高めるライブラリも追加され、より使いやすいツール群として整備が進められていることを感じられたのではないでしょうか。今後も継続的に改善は続けられると思いますので、定期的に更新内容をご確認いただければ幸いです。また機能要望などあれば、公式リポジトリに issue を上げていただけるとありがたいです。

Tags