機械学習 (ML) モデルのデプロイは、今日のビジネスにとって非常に厳しいパフォーマンスとレイテンシの要件を持つ可能性があります。 不正行為の検出や広告の配置などのユースケースは、ミリ秒が重要であり、ビジネスの成功に不可欠な例です。 厳格なサービス レベル アグリーメント (SLA) を満たす必要があり、通常の要求では、前処理、データ変換、モデル選択ロジック、モデル集約、後処理などの複数の手順が必要になる場合があります。 大規模な場合、これは多くの場合、低レイテンシを維持しながら大量のトラフィックを維持することを意味します。 一般的な設計パターンには、シリアル推論パイプライン、アンサンブル (スキャッター ギャザー)、およびビジネス ロジック ワークフローが含まれます。これにより、要求のワークフロー全体が有向非巡回グラフ (DAG) として実現されます。 ただし、ワークフローが複雑になるにつれて、全体的な応答時間の増加につながり、エンド ユーザー エクスペリエンスに悪影響を及ぼし、ビジネス目標を危険にさらす可能性があります。 Triton は、入力テンソルと出力テンソルが接続されたパイプラインで複数のモデルが構成されるこれらのユース ケースに対応できるため、これらのワークロードに対処するのに役立ちます。
ML モデルの推論に関連して目標を評価するとき、多くのオプションを検討できますが、これほど有能で実績のあるものはほとんどありません。 アマゾンセージメーカー Triton推論サーバー. Triton Inference Server を備えた SageMaker は、超低 (XNUMX 桁ミリ秒) の推論レイテンシーでスループットとハードウェア使用率を最大化するように設計されているため、多くのお客様に人気があります。 幅広いサポート対象の ML フレームワーク (TensorFlow、PyTorch、ONNX、XGBoost、NVIDIA TensorRT など) とインフラストラクチャ バックエンド (NVIDIA GPU、CPU、および AWSインフェレンティア. さらに、Triton Inference Server は、完全に管理されたエンドツーエンドの ML サービスである SageMaker と統合されており、モデルのホスティングにリアルタイムの推論オプションを提供します。
この投稿では、不正検出アンサンブル ワークロードを Triton Inference Server を使用して SageMaker にデプロイする方法について説明します。
ソリューションの概要
どのプロジェクトでも、プロジェクトの総コストを概算するために、要件のリストと工数の見積もりが不可欠です。 組織の意思決定をサポートする投資収益率 (ROI) を見積もることは重要です。 ワークロードを Triton に移行する際に考慮すべき考慮事項には、次のようなものがあります。
労力の見積もりはソフトウェア開発の鍵であり、その測定は多くの場合、不完全で不確実でノイズの多い入力に基づいています。 ML ワークロードも例外ではありません。 複数の要因が ML 推論のアーキテクチャに影響を与えるそのうちのいくつかは次のとおりです。
- クライアント側のレイテンシ バジェット – 推論応答に対するクライアント側のラウンドトリップの最大許容待機時間を指定します。通常はパーセンタイルで表されます。 数十ミリ秒近くのレイテンシ バジェットを必要とするワークロードの場合、ネットワーク転送は高価になる可能性があるため、エッジでモデルを使用する方が適しています。
- データ ペイロードの配布サイズ – ペイロードと呼ばれることが多い メッセージ本文は、クライアントからモデルに送信されるリクエスト データと、モデルからクライアントに送信されるレスポンス データです。 ペイロード サイズは多くの場合、レイテンシに大きな影響を与えるため、考慮する必要があります。
- データフォーマット – これは、ペイロードが ML モデルに送信される方法を指定します。 形式は、JSON や CSV など、人が読める形式にすることができますが、多くの場合、圧縮されてサイズが小さいバイナリ形式もあります。 これは、圧縮のオーバーヘッドと転送サイズのトレードオフです。つまり、ネットワーク経由で転送されるバイトを節約するために、CPU サイクルと待ち時間が圧縮または解凍に追加されます。 この投稿では、JSON 形式とバイナリ形式の両方を利用する方法を示します。
- 必要なソフトウェア スタックとコンポーネント – スタックは、オペレーティング システム、ランタイム、ソフトウェア レイヤーなど、ML アプリケーションをサポートするために連携して動作するコンポーネントのコレクションです。 Triton には、組み込みの一般的な ML フレームワークが付属しています。 バックエンド、ONNX、TensorFlow、FIL、OpenVINO、ネイティブ Python など。 作成することもできます カスタム バックエンド 独自の自家製コンポーネント用。 この投稿では、XGBoost モデルとデータの前処理について説明します。これらは、NVIDIA が提供する FIL と Python Triton バックエンドにそれぞれ移行します。
これらすべての要因は、ワークロードのパフォーマンスを評価する上で重要な役割を果たすはずですが、このユースケースでは、ML モデルを Triton Inference Server を使用して SageMaker でホストされるように移行するために必要な作業に焦点を当てています。 具体的には、Python で記述された前処理ロジックを備えた XGBoost モデルで構成される不正検出アンサンブルの例を使用します。
NVIDIATriton推論サーバー
Triton Inference Server は、チームが GPU または CPU ベースのインフラストラクチャ上の任意のフレームワークからトレーニング済みの AI モデルをデプロイ、実行、スケーリングできるようにゼロから設計されています。 さらに、動的バッチ処理、同時実行、最適なモデル構成、モデル アンサンブル、ストリーミング入力のサポートなどの機能を使用して、大規模な高性能推論を提供するように最適化されています。
次の図は、NVIDIA Triton アンサンブル パイプラインの例を示しています。
ワークロードでは、Triton が SageMaker ホスティングと共に提供する機能を考慮して、提供されるメリットを最大化する必要があります。 たとえば、Triton は HTTP だけでなく、 C API、必要に応じてペイロードの最適化と同様に柔軟性を可能にします。 前述のように、Triton は、TensorFlow、PyTorch、ONNX、XGBoost、NVIDIA TensorRT など、いくつかの一般的なフレームワークをすぐにサポートします。 これらのフレームワークは Triton バックエンドを通じてサポートされており、まれにバックエンドがユース ケースをサポートしていない場合、 Triton を使用すると、独自のものを実装して簡単に統合できます.
次の図は、NVIDIA Triton アーキテクチャの例を示しています。
SageMaker 上の NVIDIA Triton
SageMakerホスティング サービスは、モデルのデプロイとサービスを容易にすることを目的としたSageMaker機能のセットです。 さまざまなユースケースに合わせて調整されたMLモデルを簡単に展開、自動スケーリング、監視、および最適化するためのさまざまなオプションを提供します。 これは、永続的でサーバーレスオプションで常に利用できるものから、一時的、長時間実行、またはバッチ推論のニーズまで、あらゆるタイプの使用パターンに合わせてデプロイメントを最適化できることを意味します。
SageMaker ホスティングの傘の下には、対応するサポート対象の ML フレームワークに適したモデル サーバー ソフトウェアが事前にパッケージ化された SageMaker 推論ディープ ラーニング コンテナー (DLC) のセットもあります。 これにより、モデル サーバーをセットアップしなくても、高い推論パフォーマンスを実現できます。これは、多くの場合、モデル デプロイの最も複雑な技術的側面であり、一般に、データ サイエンティストのスキル セットの一部ではありません。 Triton 推論サーバーは現在 利用できます SageMaker DLC で。
この幅広いオプション、モジュール性、さまざまなサービングフレームワークの使いやすさにより、SageMakerとTritonは強力にマッチしています。
NVIDIA FIL バックエンドのサポート
Tritonの22.05バージョンリリース、NVIDIA は、XGBoost、LightGBM、Scikit-learn、cuML など、いくつかの一般的な ML フレームワークによってトレーニングされたフォレスト モデルをサポートするようになりました。 Triton の FIL バックエンドを使用する場合は、提供するモデル アーティファクトがサポートされていることを確認する必要があります。 たとえば、FIL はサポートしています。 model_type xgboost, xgboost_json, lightgbmまたは treelite_checkpoint提供されたモデルが XGBoost バイナリ形式、XGBoost JSON 形式、LightGBM テキスト形式、または Treelite バイナリ形式であるかどうかをそれぞれ示します。
FIL は XGBoost モデルをサポートしているため、このバックエンド サポートはこの例で使用するために不可欠です。 チェックする唯一の考慮事項は、デプロイするモデルがバイナリまたは JSON 形式をサポートしていることを確認することです。
モデル形式が適切であることを確認するだけでなく、他の考慮事項も考慮する必要があります。 Triton の FIL バックエンドは、開発者がワークロードを調整し、モデルの実行パフォーマンスを最適化するための構成可能なオプションを提供します。 構成 dynamic_batching FIL の並列計算を効率的に使用してバッチ全体を一緒に推論するために、Triton がクライアント側の要求を保持し、それらをサーバー側でバッチ処理できるようにします。 オプション max_queue_delay_microseconds Triton がバッチを形成するまで待機する時間のフェールセーフ コントロールを提供します。 FILにはShapley Explainerが付属しており、構成によってアクティブ化できます treeshap_output; ただし、Shapley の出力は、出力サイズが原因でパフォーマンスが低下することに注意してください。 もう一つの重要な側面は、 storage_type メモリフットプリントとランタイムの間のトレードオフのために。 たとえば、ストレージを SPARSE として使用するとメモリ消費量を削減できますが、DENSE を使用すると、メモリ使用量が増える代わりにモデルの実行パフォーマンスが低下する可能性があります。 これらのそれぞれに最適な選択を決定することは、ワークロードと待機時間の予算に依存するため、すべてのオプションを詳しく調べることをお勧めします FIL バックエンド FAQ と FIL で利用可能な構成のリスト.
Triton でモデルをホストする手順
ワークロードを Triton に移行する際の考慮事項の例として、不正検出のユース ケースを見てみましょう。
ワークロードを特定する
このユース ケースでは、小売顧客のチェックアウト プロセス中に使用される不正検出モデルがあります。 推論パイプラインは、前処理のためのデータ準備を含む前処理ロジックを備えた XGBoost アルゴリズムを使用しています。
現在および目標のパフォーマンス指標と、適用される可能性のあるその他の目標を特定する
エンド ツー エンドの推論時間が長すぎて許容できない場合があります。 目標は、同じ量のリクエストとそれぞれのスループットに対して、数十ミリ秒のレイテンシーから XNUMX 桁のレイテンシーに移行することです。 あなたは、データの前処理と XGBoost モデルによって多くの時間が費やされていると判断しました。 ネットワークやペイロード サイズなどのその他の要因は、エンドツーエンドの推論時間に関連するオーバーヘッドにおいて最小限の役割しか果たしません。
Triton が要件に基づいてワークロードをホストできるかどうかを判断するために遡って検討します
Triton が要件を満たすことができるかどうかを判断するには、主に XNUMX つの懸念事項に注意する必要があります。 XNUMX つ目は、Triton が HTTP や C API などの受け入れ可能なフロント エンド オプションでサービスを提供できるようにすることです。
前述のように、Triton がアーティファクトを提供できるバックエンドをサポートしているかどうかを判断することも重要です。 Triton は多くの機能をサポートしています。 バックエンド PyTorch や TensorFlow などのさまざまなフレームワークをサポートするように調整されています。 モデルがサポートされていること、および Triton が期待する適切なモデル形式であることを確認してください。 これを行うには、まず Triton バックエンドがサポートするモデル形式を確認します。 多くの場合、これにはモデルの変更は必要ありません。 また、モデルを別の形式に変換する必要がある場合もあります。 ソースとターゲットの形式に応じて、さまざまなオプションが存在します。 Treelite のバイナリ チェックポイント形式を使用するための Python ピクル ファイル.
このユースケースでは、 FIL バックエンド 変更を加えることなく XGBoost モデルをサポートでき、 Python バックエンド 前処理のために。 Triton のアンサンブル機能を使用すると、ホスティング インスタンス間のコストのかかるネットワーク呼び出しを回避することで、ワークロードをさらに最適化できます。
計画を作成し、ホスティングに Triton を使用するために必要な労力を見積もる
モデルを Triton に移行する計画について話しましょう。 すべての Triton デプロイメントには以下が必要です。
- Triton バックエンドに必要なモデル アーティファクト
- トリトン構成ファイル
- 適切な構造のモデル リポジトリ フォルダー
この投稿の後半で、これらの展開の依存関係を作成する方法の例を示します。
計画を実行して結果を検証する
適切に構造化されたモデル リポジトリに必要なファイルとアーティファクトを作成したら、デプロイを調整してテストし、ターゲット メトリックに到達したことを検証する必要があります。
この時点で、次を使用できます SageMaker推論レコメンダー 要件に基づいて最適なエンドポイント インスタンス タイプを決定します。 さらに、Triton はビルドを最適化してパフォーマンスを向上させるツールを提供します。
製品の導入
それでは、実装の詳細を見てみましょう。 このために、期待できることの例を提供する XNUMX つのノートブックを用意しました。 の 最初のノート 指定された XGBoost モデルのトレーニングと、トレーニングと推論時間の両方に使用される前処理ロジックを示します。 の XNUMX 番目のノート Triton での展開に必要なアーティファクトを準備する方法を示します。
最初のノートブックは、組織が持っている既存のノートブックを示しています。 急流 ライブラリのスイートと RAPIDS Conda カーネル。 このインスタンスは、AWS が提供する G4DN インスタンス タイプで実行されます。これは、NVIDIA T4 プロセッサを使用して高速化された GPU です。
この例の前処理タスクは、GPU アクセラレーションの恩恵を受けており、cuML および cuDF ライブラリを頻繁に使用しています。 この例を次のコードに示します。ここでは、cuML を使用したカテゴリカル ラベルのエンコードを示しています。 また、 label_encoders.pkl エンコーダーをシリアル化し、推論時の前処理に使用できるファイル。
最初のノートブックは、XGBoost モデルをトレーニングし、それに応じてアーティファクトを保存することで終了します。
このシナリオでは、トレーニング コードは既に存在しており、トレーニング時にモデルを変更する必要はありません。 また、トレーニング中の前処理には GPU アクセラレーションを使用しましたが、推論時の前処理には CPU を使用する予定です。 詳細については、記事の後半で説明します。
では、XNUMX 番目のノートブックに移り、Triton の展開を成功させるために何が必要かを思い出してください。
まず、バックエンドに必要なモデル アーティファクトが必要です。 このアンサンブル用に作成する必要があるファイルは次のとおりです。
- アーティファクトの前処理 (
model.py,label_encoders.pkl) - XGBoost モデル アーティファクト (
xgboost.json)
Triton の Python バックエンドでは、依存関係として Conda 環境を使用する必要があります。 この場合、Python バックエンドを使用して生データを前処理してから、FIL バックエンドで実行されている XGBoost モデルにフィードします。 もともと RAPIDS cuDF および cuML ライブラリを使用してデータの前処理を行っていましたが (前に GPU を使用して参照したように)、ここでは (CPU を使用して) 推論時間の前処理の依存関係として Pandas と Scikit-learn を使用します。 これには次の XNUMX つの理由があります。
- 依存関係の Conda 環境を作成する方法と、それを 期待される形式 Triton の Python バックエンドによる。
- XGBoost モデルが FIL バックエンドの GPU で実行されている間に、CPU の Python バックエンドで実行されている前処理モデルを示すことで、Triton のアンサンブル パイプラインの各モデルが異なるフレームワーク バックエンドで実行され、異なるハードウェアで異なるフレームワークで実行される方法を示します。構成。
- RAPIDS ライブラリ (cuDF、cuML) が対応する CPU (Pandas、Scikit-learn) とどのように互換性があるかを強調しています。 このようにして、方法を示すことができます
LabelEncoderscuML で作成されたものは Scikit-learn で使用でき、その逆も可能です。 推論時に大量の表形式データを前処理することが予想される場合でも、RAPIDS を使用して GPU アクセラレーションを実行できることに注意してください。
を作成したことを思い出してください。 label_encoders.pkl 最初のノートブックのファイル。 カテゴリ エンコーディングについては、 model.py 前処理用のファイル。
Triton Python バックエンドに必要な model.py ファイルを作成するには、 バックエンドで必要なフォーマット 着信テンソルを処理し、前に参照したラベル エンコーダーを使用する Python ロジックを含めます。 を確認できます。 file 前処理に使用します。
XGBoost モデルの場合、これ以上何もする必要はありません。 最初のノートブックでモデルをトレーニングしました。Triton の FIL バックエンドでは、XGBoost モデルに追加の作業は必要ありません。
次に、Triton 構成ファイルが必要です。 Triton アンサンブルの各モデルには、 config.pbtxt ファイル。 さらに、 config.pbtxt アンサンブル全体のファイル。 これらのファイルにより、Triton は期待される入力や出力などの情報を含むアンサンブルに関するメタデータを認識できるようになり、アンサンブルに関連付けられた DAG を定義するのにも役立ちます。
最後に、モデルを Triton にデプロイするには、モデル リポジトリ フォルダーが適切なフォルダー構造を持つ必要があります。 Triton には、モデル リポジトリのレイアウトに関する特定の要件があります。 最上位のモデル リポジトリ ディレクトリ内に、各モデルには、対応するモデルの情報を含む独自のサブディレクトリがあります。 Triton の各モデル ディレクトリには、モデルのバージョンを表す数値サブディレクトリが少なくとも XNUMX つ必要です。 このユースケースでは、結果の構造は次のようになります。
これら XNUMX つの前提条件が整ったら、デプロイ用のパッケージとして圧縮ファイルを作成し、 Amazon シンプル ストレージ サービス （Amazon S3）。
前のステップで Amazon S3 にアップロードしたモデルリポジトリから SageMaker モデルを作成できるようになりました。
このステップでは、追加の環境変数も提供します SAGEMAKER_TRITON_DEFAULT_MODEL_NAMETriton によってロードされるモデルの名前を指定します。 このキーの値は、Amazon S3 にアップロードされたモデル パッケージのフォルダー名と一致する必要があります。 単一モデルの場合、この変数はオプションです。 アンサンブル モデルの場合、Triton が SageMaker で起動するには、このキーを指定する必要があります。
さらに、設定することができます SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT および SAGEMAKER_TRITON_THREAD_COUNT スレッド数を最適化するため。 両方の構成値は、CPU で実行されているスレッドの数を調整するのに役立つため、コア数が多い CPU ではこれらの値を増やすことで、使用率を向上させることができます。 ほとんどの場合、デフォルト値で問題なく機能しますが、ワークロードの効率をさらに向上できるかどうかを試してみる価値があるかもしれません。
前のモデルでは、エンドポイントに必要なインスタンスのタイプと数を指定できるエンドポイント構成を作成します。
最後に、前述のエンドポイント設定を使用して新しい SageMaker エンドポイントを作成し、デプロイが完了するのを待ちます。 ステータスが InService デプロイが成功した後。
それでおしまい！ エンドポイントのテストと検証の準備が整いました。 この時点で、さまざまなツールを使用して、インスタンスの種類と構成を最適化し、可能な限り最高のパフォーマンスを得ることができます。 次の図は、Triton 上の XGBoost モデルに FIL バックエンドを使用することによって達成できるゲインの例を示しています。
まとめ
この投稿では、Triton Inference Server を使用して XGBoost アンサンブル ワークロードを SageMaker にデプロイする方法について説明しました。 ワークロードを SageMaker 上の Triton に移行することは、投資に対する有益な利益になる可能性があります。 テクノロジーの採用と同様に、審査プロセスと計画が重要です。ワークロードを移行する際に考慮すべきことをガイドする XNUMX つのステップのプロセスについて詳しく説明しました。 さらに、SageMaker 上の Triton で Python 前処理と XGBoost モデルを使用するアンサンブルをデプロイするために必要な手順を深く掘り下げました。
SageMaker は、ML ライフサイクルの各段階から未分化の重労働を取り除くツールを提供するため、モデルのデプロイを完全に最適化するために必要な迅速な実験と調査が容易になります。 Triton Inference Server の SageMaker ホスティング サポートにより、低レイテンシーで高い XNUMX 秒あたりのトランザクション数 (TPS) のワークロードが可能になります。
この例で使用されているノートブックは、次の場所にあります。 GitHubの.
著者,
ジェームズ・パーク アマゾン ウェブ サービスのソリューション アーキテクトです。 彼は Amazon.com と協力して、AWS でテクノロジー ソリューションを設計、構築、デプロイしており、特に AI と機械学習に関心があります。 余暇には、新しい文化、新しい経験を探し、最新のテクノロジー トレンドを把握することを楽しんでいます。
ジャホン・リュウ NVIDIAのクラウドサービスプロバイダーチームのソリューションアーキテクトです。 彼は、クライアントがNVIDIAアクセラレーションコンピューティングを活用してトレーニングと推論の課題に対処する機械学習とAIソリューションを採用するのを支援しています。 余暇には、折り紙、DIYプロジェクト、バスケットボールを楽しんでいます。
クシチズ・グプタ NVIDIA のソリューション アーキテクトです。 彼は、NVIDIA が提供する GPU AI テクノロジについてクラウドの顧客を教育し、機械学習およびディープ ラーニング アプリケーションの高速化を支援することに喜びを感じています。 仕事以外では、ランニング、ハイキング、野生動物の観察を楽しんでいます。
ブルーノ・アギアル・デ・メロ は、Amazon.com のソフトウェア開発エンジニアであり、科学チームが ML ワークロードを構築、展開、リリースするのを支援しています。 彼は、特にレイテンシに制約のあるユースケースでは、モデルの実行パフォーマンスがモデルの品質パフォーマンスと同じくらい重要であるという洞察に基づいて検討および測定する必要がある ML モデリング / 設計フェーズ内のインストルメンテーションおよび制御可能な側面に関心を持っています。 余暇には、ワイン、ボードゲーム、料理を楽しんでいます。
エリウス・トリアナ NVIDIAのDeveloperRelationsManagerです。 彼は、AmazonとAWSの製品リーダー、開発者、科学者をNVIDIAの技術者と製品リーダーと結び付けて、Amazon ML / DLワークロード、EC2製品、AWSAIサービスを加速させています。 さらに、Eliuthは情熱的なマウンテンバイカー、スキーヤー、ポーカープレーヤーです。
