Amazon SageMaker でのシリアル推論の設計パターン

機械学習 (ML) が主流になり、広く採用されるにつれて、ML を利用したアプリケーションは、さまざまな複雑なビジネス上の問題を解決するためにますます一般的になってきています。 これらの複雑なビジネス上の問題を解決するには、多くの場合、複数の ML モデルを使用する必要があります。 これらのモデルを順番に組み合わせて、前処理、データ変換、モデル選択、推論生成、推論統合、後処理などのさまざまなタスクを実行できます。 組織は、これらの複雑な ML ワークフローを調整するための柔軟なオプションを必要としています。 シリアル推論パイプラインは、これらのワークフローを一連のステップに配置する設計パターンの XNUMX つであり、各ステップは、前のステップによって生成された出力を強化またはさらに処理し、出力をパイプラインの次のステップに渡します。

さらに、これらのシリアル推論パイプラインは以下を提供する必要があります。

• 柔軟でカスタマイズされた実装 (依存関係、アルゴリズム、ビジネス ロジックなど)
• 生産実装のための再現性と一貫性
• インフラストラクチャ管理を最小限に抑えることによる、差別化されていない手間のかかる作業

この投稿では、シリアル推論パイプラインの一般的なユース ケースをいくつか見て、これらのユース ケースごとにいくつかの実装オプションについて説明します。 アマゾンセージメーカー. また、これらの各実装オプションに関する考慮事項についても説明します。

次の表は、シリアル推論、実装に関する考慮事項、およびオプションのさまざまなユース ケースをまとめたものです。 これらについては、この投稿で説明します。

以下のセクションでは、各ユースケースについて詳しく説明します。

推論コンテナーを使用したシリアル推論パイプライン

シリアル推論パイプラインのユースケースには、推論を生成するために事前トレーニング済みの ML モデルを呼び出す前に、受信データを前処理する必要があります。 さらに、場合によっては、生成された推論をさらに処理して、下流のアプリケーションで簡単に使用できるようにする必要があります。 これは、モデルを適合させる前にストリーミング データ ソースをリアルタイムで処理する必要があるユース ケースの一般的なシナリオです。 ただし、このユースケースはバッチ推論にも現れる可能性があります。

SageMaker は、推論コンテナをカスタマイズし、それらを使用してシリアル推論パイプラインを構築するオプションを提供します。 推論コンテナは、 SageMaker 推論ツールキット に基づいて構築されています SageMaker マルチモデルサーバー (MMS)、ML モデルを提供するための柔軟なメカニズムを提供します。 次の図は、推論コンテナーを使用してシリアル推論パイプラインを実装する方法の参照パターンを示しています。

SageMaker MMS は、モデルのロード、入力データの前処理、モデルからの予測の取得、および出力データの後処理のために、次の関数を実装する Python スクリプトを想定しています。

• input_fn（） – 入力データのデシリアライズと前処理を担当
• model_fn（） – アーティファクトからトレーニング済みモデルをロードする責任があります Amazon シンプル ストレージ サービス （Amazon S3）
• predict_fn（） – モデルから推論を生成する責任
• output_fn（） – 出力データのシリアル化と後処理 (推論) を担当

推論コンテナーをカスタマイズする詳細な手順については、次を参照してください。 独自の推論コンテナーを適応させる.

推論コンテナーは、シリアル推論パイプラインのユース ケースの理想的な設計パターンであり、主な考慮事項は次のとおりです。

• 高い凝集度 – 処理ロジックと対応するモデルが単一のビジネス機能を駆動し、同じ場所に配置する必要がある
• 全体的なレイテンシが低い – 推論リクエストを行ってからレスポンスを受信するまでの経過時間

シリアル推論パイプラインでは、処理ロジックとモデルが同じ XNUMX つのコンテナー内にカプセル化されるため、呼び出し呼び出しの多くはコンテナー内に残ります。 これにより、全体のホップ数が減少し、パイプラインの全体的なレイテンシと応答性が向上します。

また、実装の容易さが重要な基準となるユースケースでは、パイプラインのさまざまな処理ステップを同じコンテナー内に配置することで、推論コンテナーが役立ちます。

SageMaker 推論パイプラインを使用したシリアル推論パイプライン

シリアル推論パイプラインのユース ケースの別のバリエーションでは、パイプラインのさまざまなステップ (データの前処理、推論の生成、データの後処理、フォーマットとシリアル化など) をより明確に分離する必要があります。 これには、さまざまな理由が考えられます。

• デカップリング – パイプラインのさまざまなステップには明確に定義された目的があり、基礎となる依存関係が関係しているため、個別のコンテナーで実行する必要があります。 これは、パイプラインを適切に構造化するのにも役立ちます。
• フレームワーク – パイプラインのさまざまなステップでは、特定の目的に合ったフレームワーク (scikit や Spark ML など) を使用するため、別のコンテナーで実行する必要があります。
• リソースの分離 – パイプラインのさまざまなステップには、さまざまなリソース消費要件があるため、柔軟性と制御を高めるために別のコンテナーで実行する必要があります。

さらに、もう少し複雑なシリアル推論パイプラインの場合、リクエストを処理して推論を生成するために複数のステップが必要になる場合があります。 したがって、運用上の観点からは、これらのステップを別々のコンテナーでホストして機能をより分離し、アップグレードと拡張を容易にすることが有益な場合があります (他のモデルや処理ステップに影響を与えずに XNUMX つのステップを変更します)。

ユース ケースがこれらの考慮事項の一部と一致する場合は、 SageMaker推論パイプライン シリアル推論パイプラインを構築するための簡単で柔軟なオプションを提供します。 次の図は、SageMaker 推論パイプラインを使用して専用コンテナでホストされている複数のステップを使用してシリアル推論パイプラインを実装する方法の参照パターンを示しています。

SageMaker 推論パイプラインは、データに対する推論のリクエストを処理する 2 ～ 15 個のコンテナの線形シーケンスで構成されます。 推論パイプラインは、事前トレーニング済みの SageMaker 組み込みアルゴリズムまたは Docker コンテナーにパッケージ化されたカスタム アルゴリズムを使用するオプションを提供します。 コンテナは同じ基盤となるインスタンスでホストされるため、全体的なレイテンシが短縮され、コストが最小限に抑えられます。

次のコード スニペットは、複数の処理ステップとモデルを組み合わせてシリアル推論パイプラインを作成する方法を示しています。

まず、パイプラインの一部として使用する予定の Spark ML および XGBoost ベースのモデルを構築して指定します。

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

次に、モデルはパイプライン モデル定義内で順番に配置されます。

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

次に、推論パイプラインは、ホスト ML インスタンスのタイプと数を指定することで、リアルタイムの推論のためにエンドポイントの背後にデプロイされます。

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

組み立てられた推論パイプライン全体は、外部の前処理なしで、リアルタイムの予測を行うか、バッチ変換を直接処理するために使用できる SageMaker モデルと見なすことができます。 推論パイプラインモデル内で、SageMaker は外部アプリケーションから発信された HTTP リクエストのシーケンスとして呼び出しを処理します。 パイプラインの最初のコンテナーは、最初の要求を処理し、いくつかの処理を実行してから、パイプラインの XNUMX 番目のコンテナーへの要求として中間応答をディスパッチします。 これは、パイプライン内のコンテナーごとに発生し、最終的に呼び出し元のクライアント アプリケーションに最終的な応答を返します。

SageMaker 推論パイプラインは完全に管理されています。 パイプラインがデプロイされると、SageMaker は定義されたすべてのコンテナをそれぞれの アマゾン エラスティック コンピューティング クラウド エンドポイントまたはバッチ変換ジョブの一部としてプロビジョニングされた (Amazon EC2) インスタンス。 さらに、コンテナは同じ EC2 インスタンスに配置され、ホストされているため、全体的なパイプラインのレイテンシが短縮されます。

SageMaker 推論パイプラインを使用したシリアル モデル アンサンブル

アンサンブル モデルは、複数の ML モデルを組み合わせて推論プロセスの一部として使用し、最終的な推論を生成する ML のアプローチです。 アンサンブル モデルの動機には、精度の向上、特定の入力機能に対するモデルの感度の低下、単一モデルのバイアスの削減などが含まれます。 この投稿では、複数の ML モデルがシリアル推論パイプラインの一部として順次結合される、シリアル モデル アンサンブルに関連するユース ケースに焦点を当てます。

特定のテーマやトピックに基づいてユーザーがアップロードした画像をグループ化する必要があるシリアル モデル アンサンブルに関連する特定の例を考えてみましょう。 このパイプラインは、次の XNUMX つの ML モデルで構成できます。

• モデル1 – 画像を入力として受け入れ、画像の解像度、向きなどに基づいて画像の品質を評価します。 次に、このモデルは画質のアップスケールを試み、特定の品質しきい値を満たす処理済みの画像を次のモデル (モデル 2) に送信します。
• モデル2 – モデル 1 によって検証された画像を受け入れ、実行します 画像認識 オブジェクト、場所、人、テキスト、およびその他のカスタム アクションと画像内の概念を識別します。 識別されたオブジェクトを含むモデル 2 からの出力は、モデル 3 に送信されます。
• モデル3 – モデル 2 からの出力を受け取り、テーマに基づいて画像をグループ化するためのトピック モデリングなどの自然言語処理 (NLP) タスクを実行します。 たとえば、場所や特定された人物に基づいて画像をグループ化できます。 出力 (グループ化) は、クライアント アプリケーションに送り返されます。

次の図は、SageMaker 推論パイプラインを使用して、シリアル モデル アンサンブルでホストされる複数の ML モデルを実装する方法の参照パターンを示しています。

前述のように、SageMaker 推論パイプラインは管理されているため、シリアル アンサンブル パイプラインの構築に関連する未分化の重労働を減らしながら、ML モデルの選択と開発に集中できます。

さらに、デカップリング、モデル開発のためのアルゴリズムとフレームワークの選択、および展開に関して前述したいくつかの考慮事項は、ここでも関連しています。 たとえば、各モデルは個別のコンテナーでホストされるため、各モデルと全体的なユース ケースに最適な ML フレームワークを柔軟に選択できます。 さらに、デカップリングと運用の観点から、他のモデルに影響を与えることなく、個々のステップをより簡単にアップグレードまたは変更し続けることができます。

SageMaker 推論パイプラインは、 SageMakerモデルレジストリ モデルのカタログ化、バージョン管理、メタデータ管理、運用環境への管理された展開をサポートし、一貫した運用のベスト プラクティスをサポートします。 SageMaker 推論パイプラインも統合されています アマゾンクラウドウォッチ 推論パイプラインでマルチコンテナー モデルを監視できるようにします。 可視化することもできます リアルタイムメトリック パイプライン内の各コンテナーの呼び出しとレイテンシーをよりよく理解できるため、トラブルシューティングとリソースの最適化に役立ちます。

SageMaker 推論パイプラインを使用したシリアル推論パイプライン (グループからの対象モデル呼び出しによる)

SageMakerマルチモデルエンドポイント (MME) は、単一のエンドポイントの背後に多数の ML モデルを展開するための費用対効果の高いソリューションを提供します。 マルチモデル エンドポイントを使用する動機には、要求の特性 (発信元、地理的な場所、ユーザーの個人設定など) に基づいて特定のカスタマイズされたモデルを呼び出すことや、単に同じエンドポイントの背後で複数のモデルをホストしてコストの最適化を実現することが含まれます。

マルチモデル対応の XNUMX つのエンドポイントに複数のモデルをデプロイすると、すべてのモデルがコンピューティング リソースとモデル サービング コンテナーを共有します。 SageMaker 推論パイプラインは MME にデプロイできます。MME では、パイプライン内のコンテナの XNUMX つが、呼び出される特定のモデルに基づいてリクエストを動的に処理できます。 パイプラインの観点から、モデルには同一の前処理要件があり、同じ機能セットを期待していますが、特定の動作に合わせてトレーニングされています。 次の図は、この統合されたパイプラインがどのように機能するかの参照パターンを示しています。

MME では、クライアント アプリケーションから発信される推論リクエストで、呼び出す必要があるターゲット モデルを指定する必要があります。 パイプラインの最初のコンテナーは、最初の要求を処理し、いくつかの処理を実行してから、複数のモデルをホストするパイプラインの XNUMX 番目のコンテナーへの要求として中間応答をディスパッチします。 推論リクエストで指定されたターゲット モデルに基づいて、モデルが呼び出されて推論が生成されます。 生成された推論は、パイプライン内の次のコンテナーに送信され、さらに処理されます。 これは、パイプライン内の後続のコンテナごとに発生し、最終的に SageMaker は呼び出し元のクライアント アプリケーションに最終的な応答を返します。

複数のモデル アーティファクトが S3 バケットに保持されます。 特定のモデルが呼び出されると、SageMaker はそれをエンドポイントをホストするコンテナに動的にロードします。 モデルがコンテナのメモリにすでにロードされている場合、SageMaker は Amazon S3 からモデルをダウンロードする必要がないため、呼び出しは高速です。 インスタンスのメモリ使用率が高く、新しいモデルが呼び出されたためにロードする必要がある場合、未使用のモデルはメモリからアンロードされます。 ただし、アンロードされたモデルはインスタンスのストレージ ボリュームに残り、S3 バケットから再度ダウンロードすることなく、後でコンテナのメモリに再度ロードできます。

MME を使用する際の重要な考慮事項の XNUMX つは、モデル呼び出しの待機時間の動作を理解することです。 前に説明したように、モデルは呼び出されると、エンドポイントをホストするインスタンスのコンテナのメモリに動的にロードされます。 したがって、モデルの呼び出しは、初めて呼び出されるときに時間がかかる場合があります。 モデルがすでにインスタンス コンテナーのメモリにある場合、その後の呼び出しは高速になります。 インスタンスのメモリ使用率が高く、新しいモデルをロードする必要がある場合、未使用のモデルはアンロードされます。 インスタンスのストレージ ボリュームがいっぱいになると、未使用のモデルがストレージ ボリュームから削除されます。 SageMaker は、特定のアクションを実行する必要なく、モデルのロードとアンロードを完全に管理します。 ただし、この動作を理解することは重要です。これは、モデル呼び出しの待機時間、したがって全体的なエンド ツー エンドの待機時間に影響を与えるためです。

パイプライン ホスティング オプション

SageMaker は複数の インスタンスタイプ ユースケース、スループット、およびコスト要件に基づいて、ML モデルをデプロイし、推論パイプラインを構築するために選択できるオプション。 たとえば、CPU または GPU に最適化されたインスタンスを選択して、単一のコンテナーまたは複数のコンテナーにわたってシリアル推論パイプラインを構築できます。 ただし、柔軟性を高めるために、同じパイプライン内の CPU または GPU ベースのインスタンスでモデルを実行するための柔軟性とサポートが必要な場合があります。

NVIDIA Triton Inference Server を使用して、異種コンピューティング要件の SageMaker で推論用のモデルを提供できるようになりました。 チェックアウト AmazonSageMakerのNVIDIATriton InferenceServerを使用して高速でスケーラブルなAIをデプロイする 詳細については。

まとめ

組織が ML を利用した新しいソリューションを発見して構築するとき、これらのパイプラインをオーケストレーションするために必要なツールは、特定のユースケースに基づいてサポートできるほど柔軟であると同時に、継続的な運用オーバーヘッドを簡素化および削減する必要があります。 SageMaker は、要件に基づいて、これらのシリアル推論ワークフローを設計および構築するための複数のオプションを提供します。

シリアル推論パイプラインを使用して構築しているユース ケースについて、ご連絡をお待ちしております。 質問やフィードバックがある場合は、コメントで共有してください。

著者について

ラーフル・シャルマ AWS Data Lab のシニア ソリューション アーキテクトであり、AWS のお客様が AI/ML ソリューションを設計および構築するのを支援しています。 AWS に入社する前、Rahul は金融および保険セクターで数年間過ごし、顧客がデータおよび分析プラットフォームを構築するのを支援してきました。

アナンド・プラカシュ AWS Data Lab のシニア ソリューション アーキテクトです。 Anand は、顧客が AI/ML、データ分析、およびデータベース ソリューションを設計および構築して、本番環境への道を加速するのを支援することに重点を置いています。

ダワル・パテル AWSのプリンシパル機械学習アーキテクトです。 彼は、分散コンピューティングや人工知能に関連する問題について、大企業から中規模の新興企業に至るまでの組織と協力してきました。 彼は、NLPおよびコンピュータービジョンドメインを含むディープラーニングに焦点を当てています。 彼は、顧客がSageMakerで高性能モデルの推論を実現するのを支援します。

サウラブ・トリカンデ はAmazonSageMakerInferenceのシニアプロダクトマネージャーです。 彼は顧客と協力し、機械学習をより利用しやすくすることに情熱を注いでいます。 余暇には、ハイキングを楽しんだり、革新的なテクノロジーについて学んだり、TechCrunchをフォローしたり、家族と過ごしたりしています。