アマゾンセージメーカー は、すべての開発者とデータ サイエンティストに、機械学習 (ML) モデルを大規模に迅速に構築、トレーニング、デプロイできる機能を提供するフルマネージド サービスです。 ML は推論で実現されます。 SageMaker は 4 つの推論オプションを提供します。
これら 4 つのオプションは、オンライン推論オプションとバッチ推論オプションに大別できます。オンライン推論では、リクエストは到着時に処理されることが期待され、消費側アプリケーションは各リクエストが処理された後の応答を期待します。これは、同期 (リアルタイム推論、サーバーレス) または非同期 (非同期推論) のいずれかで発生します。同期パターンでは、使用側アプリケーションはブロックされ、応答を受信するまで続行できません。これらのワークロードは、オンライン クレジット カード詐欺検出などのリアルタイム アプリケーションであることが多く、応答はミリ秒から数秒のオーダーで予想され、リクエストのペイロードは小さい (数 MB)。非同期パターンでは、アプリケーション エクスペリエンスはブロックされず (たとえば、モバイル アプリを介した保険請求の送信)、通常はより大きなペイロード サイズやより長い処理時間が必要になります。オフライン推論では、推論リクエストの集約 (バッチ) がまとめて処理され、バッチ全体が処理された後にのみ応答が提供されます。通常、これらのワークロードはレイテンシの影響を受けず、大量 (数 GB) のデータを含み、定期的にスケジュールされます (たとえば、1 日の終わりにセキュリティ カメラの映像に対して物体検出を実行したり、勤務時間に給与データを処理したりします)月の終わり)。
最低限のところで、 SageMaker リアルタイム推論 モデル、作業に使用するフレームワーク/コンテナ、およびデプロイされたエンドポイントをサポートするインフラストラクチャ/インスタンスで構成されます。この投稿では、単一モデル エンドポイントを作成して呼び出す方法を説明します。
モデル展開オプションの選択
適切な推論タイプを選択するのは難しい場合がありますが、次の簡単なガイドが役立ちます。これは厳密なフローチャートではないため、別のオプションの方が適していると思われる場合は、それらを自由に使用してください。特に、リアルタイム推論は、一貫した低レイテンシ (ミリ秒または数秒のオーダー) とスループットに敏感なワークロードがある場合に、モデルをホストするための優れたオプションです。構成しながら、エンドポイントの背後でインスタンスのタイプとカウントを制御できます。 自動スケーリング トラフィックを処理するポリシー。エンドポイントの作成に使用できる他にも 2 つの SageMaker Inference オプションがあります。非同期推論は、ペイロード サイズが大きく、ほぼリアルタイムの遅延帯域幅がある場合に使用します。これは、特に前処理時間が長い NLP モデルやコンピューター ビジョン モデルに適したオプションです。サーバーレス推論は、断続的なトラフィックがあり、インフラストラクチャのスケーリングを管理したくない場合に最適なオプションです。エンドポイントを作成するためのレシピは、選択した推論タイプに関係なく同じままです。この投稿では、リアルタイムのインスタンスベースのエンドポイントの作成に焦点を当てますが、ユースケースに基づいて他の推論オプションのいずれかに簡単に適応させることができます。最後に、バッチ推論はオフラインで行われるため、推論を取得したいデータのセットを提供すると、それが実行されます。これも同様にインスタンスベースであるため、ワークロードに最適なインスタンスを選択できます。稼働中のエンドポイントがないため、ジョブの期間に対してのみ料金が発生します。ギガバイトのデータを処理するのに適しており、ジョブの所要時間は数日かかる場合があります。構造化データの操作を容易にする組み込み機能と、構造化データを自動的に配布する最適化機能があります。ユースケースの例としては、傾向モデリング、予測メンテナンス、チャーン予測などがあります。特定のイベントに反応する必要がないため、これらはすべてオフラインで一括して実行できます。
SageMaker Endpoints でのモデルのホスト
SageMaker Real-Time Endpoints の核心は、エンドポイントをサポートするために選択したモデルとインフラストラクチャで構成されます。 SageMaker はコンテナを使用してモデルをホストします。つまり、提供する各モデルに使用するフレームワークの環境を適切にセットアップするコンテナが必要です。たとえば、Sklearn モデルを使用している場合は、Sklearn を適切に設定するコンテナ内でモデルのスクリプト/データを渡す必要があります。幸いなことに、SageMaker は以下を提供します。 管理されたイメージ TensorFlow、PyTorch、Sklearn、HuggingFace などの一般的なフレームワーク用。これらの画像は、高レベルの SageMaker Python SDK そしてモデルのスクリプトとデータをこれらのコンテナに注入します。 SageMaker にサポートされているコンテナがない場合は、次のこともできます。 独自のコンテナを構築する 独自のカスタム イメージをプッシュし、モデルに必要な依存関係をインストールします。
SageMaker は、トレーニング済みモデルと事前トレーニング済みモデルの両方をサポートします。前の段落でモデル スクリプト/データについて話しているとき、この問題について言及しています。スクリプトをコンテナーにマウントすることも、事前トレーニングされたモデル アーティファクト (たとえば、`モデル.ジョブライブラリ` for SKLearn)、これを画像とともに SageMaker に提供できます。 SageMaker Inference を理解するために、エンドポイント作成のプロセスで作成する 3 つの主要なエンティティがあります。
- SageMaker モデル エンティティ – ここでは、トレーニング済みのモデル データ/モデル スクリプトと、AWS が所有しているか自分で構築しているかに関係なく、作業しているイメージを渡すことができます。
- エンドポイント構成の作成 – ここでインフラストラクチャを定義します。つまり、インスタンスのタイプ、数などを選択します。
- エンドポイントの作成 – これは、応答を取得するために呼び出すモデルをホストする REST エンドポイントです。マネージド SageMaker イメージと独自のカスタム構築イメージを利用してエンドポイントをデプロイする方法を見てみましょう。
リアルタイムエンドポイントの要件
- エンドポイントを作成する前に、ホストするモデルのタイプを理解する必要があります。 TensorFlow、PyTorch、MXNet などのフレームワーク モデルの場合は、次のいずれかを利用できます。 事前に構築されたフレームワークイメージ.
カスタム モデルの場合、または SageMaker が推論のために実行するコンテナを完全に柔軟に作成したい場合は、独自のコンテナを構築できます。
SageMakerエンドポイント で構成されています SageMakerモデル & エンドポイント構成。
Boto3 を使用している場合は、両方のオブジェクトを作成します。それ以外の場合、SageMaker Python SDK を利用している場合は、 .deploy(..)
機能。
SageMaker エンティティ:
- SageMakerモデル:
- 推論画像の詳細、モデルアーティファクトの場所が含まれます。 Amazon シンプル ストレージ サービス (Amazon S3)、 ネットワーク構成、および AWS Identity and Access Management(IAM) エンドポイントによって使用されるロール。
- SageMaker では、モデル アーティファクトを圧縮する必要があります。
.tar.gz
ファイル。 SageMaker はこれを自動的に抽出します.tar.gz
ファイルを/opt/ml/model/
コンテナ内のディレクトリ。 TensorFlow、PyTorch、MXNet などのフレームワーク コンテナーのいずれかを利用している場合、コンテナーは TAR 構造が次のようになることを期待します。- TensorFlow
- パイトーチ
- MXNet
- スクラーン
- TensorFlow
- フレームワーク イメージを利用する場合、独自の前後処理を実装できるカスタム エントリ ポイント スクリプトを提供できます。この例では、推論スクリプトは /code ディレクトリの下の model.tar.gz にパッケージ化されています。
- SageMaker では、モデル アーティファクトを圧縮する必要があります。
- 推論画像の詳細、モデルアーティファクトの場所が含まれます。 Amazon シンプル ストレージ サービス (Amazon S3)、 ネットワーク構成、および AWS Identity and Access Management(IAM) エンドポイントによって使用されるロール。
-
- エンドポイント構成
- SageMaker モデルをエンドポイントにデプロイするために必要なインフラストラクチャ情報が含まれています。
- たとえば、ここでは作成した SageMaker モデルと、インスタンス タイプと初期インスタンス数を指定します。
フレームワークとBYOC
-
- SageMaker イメージの取得
- この部分は必ずしも必要なわけではなく、SageMaker Python SDK によって推定器を介して抽象化されます。ただし、SageMaker で管理されているイメージを取得して拡張できるようにしたい場合は、SDK 経由で利用可能なイメージを取得できます。以下は、推論のために TF 2.2 イメージを取得する例です。
- フレームワーク
- TensorFlow、PyTorch、MXNet などのフレームワーク モデルをデプロイする場合、必要なのはモデル アーティファクトだけです。
- モデル アーティファクトからモデルを直接デプロイするためのドキュメントを参照してください。 TensorFlow, パイトーチまたは MXNet.
- SageMaker イメージの取得
-
- 1P と BYOC の選択
- 前のフレームワークセクションで見たように、SageMaker SDK はイメージの処理も抽象化します。 Sklearn、TensorFlow、および PyTorch 用の既製の推定ツールがあり、選択したバージョンに基づいて画像を自動的に選択します。次に、トレーニング/推論スクリプトを渡すことができます。 スクリプトモード これらの推定器に。
- すべてのパッケージとイメージが SageMaker でサポートされているわけではないため、この場合は次のことを行う必要があります。 自分のコンテナを持ち込む (BYOC))。これは、モデルを提供するための適切な環境をセットアップする Dockerfile を構築することを意味します。この例としては Spacy NLP モジュールがありますが、このフレームワークにはマネージド SageMaker コンテナはありません。したがって、Spatiy をインストールする Dockerfile を提供する必要があります。コンテナ内では、モデル推論スクリプトもマウントします。 Bring Your Own Container 形式で提供するコンポーネントについて簡単に説明します。これらのコンポーネントはほとんどの例で一貫しているためです。
- 「nginx.conf」 nginx フロントエンドの構成ファイルです。これらの部分を調整する場合を除き、このファイルを編集する必要はありません。
- 「predictor.py」 これは、Flask Web サーバーとアプリケーションのモデル コードを実際に実装するプログラムです。コンテナー内にさらに Python ファイルまたは関数を含めることができ、このファイル内で呼び出すことができます。
- "仕える" コンテナがホスティングのために開始されるときに開始されるプログラムです。これは単に gunicorn サーバーを起動し、predictor.py で定義された Flask アプリの複数のインスタンスを実行します。 nginx.conf と同様に、さらに調整を実行する必要がない限り、このファイルを編集する必要はありません。
- "電車" コンテナがトレーニングのために実行されるときに呼び出されるプログラムです。このプログラムを変更してトレーニング アルゴリズムを実装します。 Spacy のような事前トレーニングされたモデルまたはフレームワークを使用する場合、このファイルは必要ありません。
- 「wsgi.py」 Flask アプリを呼び出すために使用される小さなラッパーです。 predictor.py ファイルの名前を変更しない限り、このファイルをそのまま使用できるはずです。その場合は、ここで適切にマップされていることを確認してください。
- 1P と BYOC の選択
-
- カスタム推論スクリプト
- SageMaker Framework コンテナは、カスタム エントリ ポイント script/inference.py を使用して、リクエストの前後処理とモデルの読み込みを柔軟に処理できます。
- カスタム inference.py スクリプトの作成に関するドキュメントを参照してください。 TensorFlow, パイトーチ & MXNet.
- カスタムコンテナ
- カスタム推論スクリプト
SageMaker エンドポイントと対話できるさまざまな方法
SageMaker をプログラムで使用するためのオプションが多数あり、デプロイされたモデルを呼び出して推論を取得できます。の AWS コマンドラインインターフェイス (AWS CLI)、 REST API、 AWS CloudFormation, AWS クラウド開発キット (AWS CDK))、AWS SDK は AWS が提供する一般的なツールであり、他の AWS サービスで広くサポートされています。 SageMaker については、SageMaker Python SDK もあります。ここで、SageMaker Endpoint を作成、呼び出し、管理するためのさまざまなオプションを比較してみましょう。
に加えて SageMaker CLI、SDK を介してプログラムで SageMaker のエンドポイントと対話できる方法は 2 つあります。いくつかの違いを見てみましょう SageMaker Python SDK & Boto3 Python SDK:
- 高レベルの SageMaker 「Python」 SDK – この SDK は、特に Python を使用してプログラムで SageMaker API を呼び出すことを目的とした高レベルの抽象化を提供するオープンソース ライブラリです。この SDK の良い点は、sagemaker API を呼び出すのが非常に簡単であること、API の同期/非同期モードでの呼び出し (ポーリングの回避に役立つ) などの多くの重労働がすでに行われていること、リクエスト/レスポンス スキーマが単純化されていること、コードがはるかに少ないことなどです。よりシンプルなコード。 SageMaker Python SDK は、SageMaker を操作するための高レベルの抽象化をいくつか提供します。このパッケージは、SageMaker 上のさまざまな ML プロセスを簡素化することを目的としています。
- 低レベル AWS SDK (Boto3 SDK) – この SDK は、ユーザーがサポートされているプログラミング言語から選択し、プログラムで任意の AWS サービスを呼び出すことができるようにすることで、下位レベルで動作します。これは SageMaker に固有のものではなく、すべての AWS サービスに一般的に使用できます。低レベルの AWS SDK は、.NET、Python、Java、Node.js などのさまざまなプログラミング言語で利用できます。使用される人気のある SDK の 3 つは、ML のデータ サイエンティスト コミュニティで人気のある botoXNUMX python SDK です。この SDK の良い点は、非常に軽量であり、デフォルトでインストールされている場所で利用できることです。 AWSラムダ ランタイム。さらに、この SDK を使用して、SageMaker の外部の AWS サービスと対話することができます。
これらの SDK は両方とも同じタスクに利用できますが、場合によっては、一方をもう一方よりも多く使用した方が直感的です。簡単なテストには SageMaker Python SDK が推奨されますが、パフォーマンスをより適切に制御するために実稼働ユースケースには AWS SDK/Boto3 が推奨されます。たとえば、SageMaker はサービスとして、Sklearn、PyTorch、TensorFlow などの一般的なフレームワーク用に事前構築および保守されたイメージを提供します。 SageMaker SDK を使用して深層学習イメージを取得し、次を使用してモデルをトレーニングすると特に便利です。 推定者、単純な API 呼び出しを使用してモデルを簡単にデプロイします。これを実際に示す例は次のとおりです。 こちら.
一方で、事前にトレーニングされたモデルや別のフレームワークを使用している場合もあります。これには大幅なカスタマイズが必要ですが、SageMaker SDK が常にそれを提供するとは限りません。エンドポイントをデプロイするために実行する必要がある 3 つの重要な手順と、対応する botoXNUMX API 呼び出しがあります。 モデルの作成, エンドポイント構成の作成, エンドポイントの作成。最初の 3 つのエンティティは、サポートされているフレームワークを使用した SageMaker SDK で抽象化されましたが、Boto3 SDK でそれらの詳細が表示されます。 BotoXNUMX SDK を使用してエンドポイントを作成および管理する手順を示す広範な例が見つかります。 こちら.
SageMaker ホスティングに関する考慮事項
SageMaker Real-Time Inference には、考慮できる 1 つの主な最適化があります。2/ パフォーマンスの最適化、XNUMX/ コストの最適化です。まずは見てみましょう パフォーマンスの最適化レイテンシーに敏感なワークロードを扱う場合と同様に、ミリ秒単位が重要です。レイテンシーとスループットを最適化するために調整できるさまざまなノブがあります。インスタンスレベルでは、次を使用できます。 推論レコメンダーは、ワークロードに適したインスタンスのタイプと数を選択するのに役立つ、組み込みの負荷テスト ツールです。コンピューティングを適切に組み合わせて利用すると、パフォーマンスとコストの両方が向上します。コンテナーおよびフレームワーク レベルで調整することもできます。
自問する質問は次のとおりです。
- どのようなフレームワークを使用していますか?
- コンテナ内で調整できる環境変数はありますか?
この例としては、最大化が挙げられます。 SageMaker コンテナを使用した TensorFlow のパフォーマンス。 コンテナレベルの最適化の別の例は次のとおりです。 gRPCの活用 エンドポイントの背後で REST するのではなく。最後に、スクリプト レベルで最適化することもできます。推論コードは特定のブロックで余分に時間がかかっていませんか?スクリプトの各行のタイミングを計ることは、コード内のボトルネックを把握するのに役立ちます。
見る方法は3つあります 使用率の向上 リアルタイム エンドポイントの:
- マルチモデルエンドポイント (MME)
- 単一のエンドポイントの背後で数千のモデルをホストできます。これは、モデルごとに専用のエンドポイントが必要ないユースケースに最適です。 MME は、モデルのサイズとレイテンシが同様で、同じ ML フレームワークに属している場合に最適に機能します。これらは通常、常に同じモデルを呼び出す必要がない場合に使用できます。それぞれのモデルを SageMaker エンドポイントに動的にロードして、リクエストに対応できます。. MME の動作を示す例は次のとおりです。 こちら。 MME でモデルをホストするためのさまざまな注意点とベスト プラクティスについて詳しく知りたい場合は、投稿を参照してください。 こちら.
- マルチコンテナエンドポイント(MCE)
- シリアル推論パイプライン (SIP)
- 推論ロジックにステップのパイプラインがある場合は、シリアル推論パイプライン (SIP) を利用できます。 SIP を使用すると、単一のエンドポイントの背後で 2 ~ 15 個のコンテナを連結できます。 SIP は、前処理ステップと後処理ステップがある場合にうまく機能します。シリアル推論パイプラインの設計パターンについて詳しく知りたい場合は、投稿を参照してください。 こちら.
留意すべき 2 番目の主要な最適化は次のとおりです。 コスト。リアルタイム推論は、SageMaker エンドポイントの作成内の 3 つのオプションのうちの 1 つです。 SageMaker Endpoint は、削除されない限り、常に実行されています。したがって、エンドポイントの使用率を向上させてコスト上のメリットをもたらすことを検討する必要があります。
SageMaker も提供しています 貯蓄プラン。 Savings Plan を使用すると、コストを最大 64% 削減できます。これは、一定の使用量 (1 時間あたりのドル) に対する 3 年または XNUMX 年間の契約です。これを参照してください 詳細については。そしてこれを見てください Amazon SageMaker での推論のコストを最適化するために。
まとめ
この投稿では、SageMaker でさまざまなモデル ホスティング オプションを選択するためのベスト プラクティスをいくつか紹介しました。 SageMaker Endpoint の要件について説明し、フレームワークと BYOC の要件と機能を対比しました。さらに、リアルタイム エンドポイントを活用して実稼働環境で ML モデルをホストできるさまざまな方法についても説明しました。コスト効率の高い方法で、高いパフォーマンスを実現します。
対応するものを参照してください GitHubリポジトリ そして例を試してみてください。
著者について
ラグーラメシャ Amazon SageMaker サービスチームの ML ソリューションアーキテクトです。 彼は、お客様が ML 本番ワークロードを大規模に構築、デプロイ、および SageMaker に移行するのを支援することに重点を置いています。 機械学習、AI、コンピューター ビジョンの分野を専門とし、UT ダラスでコンピューター サイエンスの修士号を取得しています。 余暇には、旅行と写真を楽しんでいます。
ラム・ベギラージュ SageMaker サービスチームの ML アーキテクトです。 彼は、お客様が Amazon SageMaker で AI/ML ソリューションを構築および最適化するのを支援することに重点を置いています。 余暇には、旅行と執筆が大好きです。
マーク・カープ SageMaker サービスチームの ML アーキテクトです。 彼は、顧客が大規模な ML ワークロードを設計、展開、管理するのを支援することに重点を置いています。 余暇には、旅行や新しい場所の探索を楽しんでいます。
ダワル・パテル AWS のプリンシパル機械学習アーキテクトです。 大企業から中規模の新興企業まで、さまざまな組織と協力して、分散コンピューティングと人工知能に関連する問題に取り組んできました。 彼は、NLP やコンピューター ビジョン ドメインなどのディープ ラーニングに焦点を当てています。 彼は、お客様が Amazon SageMaker で高性能のモデル推論を実現するのを支援しています。
サウラブ・トリカンデ Amazon SageMaker Inference のシニア プロダクト マネージャーです。 彼は顧客と協力することに情熱を傾けており、機械学習を民主化するという目標に動機付けられています。 彼は、複雑な ML アプリケーションのデプロイ、マルチテナント ML モデル、コストの最適化、およびディープ ラーニング モデルのデプロイをよりアクセスしやすくすることに関連する主要な課題に焦点を当てています。 余暇には、ハイキング、革新的なテクノロジーの学習、TechCrunch のフォロー、家族との時間を楽しんでいます。