翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
モデルホスティング FAQs
SageMaker 推論ホスティングに関するよくある質問への回答については、以下のFAQ項目を参照してください。
ホスティング全般
以下のFAQ項目は、 SageMaker 推論に関する一般的な質問に回答します。
A: モデルを構築してトレーニングした後、Amazon SageMaker にはモデルをデプロイするための 4 つのオプションが用意されているため、予測を開始できます。リアルタイム推論は、レイテンシー要件がミリ秒単位、ペイロードサイズが最大 6 MB、処理時間が最大 60 秒のワークロードに適しています。バッチ変換は、事前に利用可能な大量のデータをオフラインで予測する場合に最適です。非同期推論は、1 秒未満のレイテンシーを必要とせず、ペイロードサイズが最大 1 GB、処理時間が最長 15 分のワークロード向けに設計されています。サーバーレス推論では、基盤となるインフラストラクチャを設定したり管理したりすることなく、推論用の機械学習モデルを迅速にデプロイできます。また、推論リクエストの処理に使用したコンピューティング能力に対してのみ支払いが発生するため、断続的なワークロードに最適です。
A: 次の図は、 SageMaker ホスティングモデルのデプロイオプションを選択するのに役立ちます。
前の図では、次の決定プロセスを順を追って説明しています。リクエストをバッチ処理する場合は、バッチ変換を選択するとよいでしょう。それ以外の場合、モデルへのリクエストごとに推論を受け取りたい場合は、非同期推論、サーバーレス推論、またはリアルタイム推論を選択するとよいでしょう。処理時間が長い場合やペイロードが大きく、リクエストをキューに入れる場合は、非同期推論を選択できます。ワークロードに予測不能なトラフィックや断続的なトラフィックがある場合は、サーバーレス推論を選択できます。持続的なトラフィックで、リクエストのレイテンシーを低く一定に抑える必要がある場合は、リアルタイム推論を選択できます。
A: SageMaker 推論でコストを最適化するには、ユースケースに適したホスティングオプションを選択する必要があります。Amazon SageMaker Savings Plans
A: パフォーマンスを向上させ、コストを削減するために適切なエンドポイント設定のレコメンデーションが必要な場合は、Amazon SageMaker Inference Recommender を使用する必要があります。以前は、モデルをデプロイするデータサイエンティストは、手動でベンチマークを実行して適切なエンドポイント設定を選択する必要がありました。まず、70 種類以上のインスタンスタイプの中からモデルのリソース要件とサンプルペイロードに基づいて適切な機械学習インスタンスタイプを選択し、次に異なるハードウェアに合わせてモデルを最適化する必要がありました。次に、広範囲にわたる負荷テストを実施して、レイテンシーとスループットの要件が満たされていること、およびコストが低いことを検証する必要がありました。推論レコメンダーは、以下のことを行うのに役立つため、このような複雑さを解消できます。
-
インスタンスレコメンデーションがあれば数分で始められます。
-
インスタンスタイプ全体で負荷テストを実施して、エンドポイント設定に関する推奨事項を数時間以内に取得します。
-
コンテナとモデルサーバーのパラメーターを自動的に調整し、特定のインスタンスタイプに合わせてモデル最適化を実行します。
A: SageMaker エンドポイントは、モデルサーバーを含むコンテナ化されたウェブサーバーを使用するHTTPRESTエンドポイントです。これらのコンテナは、機械学習モデルのリクエストをロードして処理します。これらにはポート 8080 の /invocations と /ping に応答するウェブサーバーを実装する必要があります。
一般的なモデルサーバーには、 TensorFlow Serving、Multi Model Server TorchServe などがあります。 SageMaker フレームワークコンテナには、これらのモデルサーバーが組み込まれています。
A: Inference SageMaker のすべてが containerized です。 SageMaker はSKlearn、 TensorFlow、、 などの一般的なフレームワーク用のマネージドコンテナを提供します HuggingFace。これらのイメージの包括的な最新リストについては、「Available Images
カスタムフレームワークによっては、そのためにコンテナを構築する必要がある場合があります。このアプローチは、Bring Your Own Container または と呼ばれますBYOC。このBYOCアプローチでは、フレームワークまたはライブラリをセットアップするための Docker イメージを提供します。次に、イメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュして、 でイメージを使用することができます SageMaker。BYOC アプローチの例については、「Overivew of Containers for Amazon SageMaker
イメージをゼロから構築する代わりに、コンテナを拡張することもできます。 SageMaker が提供するベースイメージの 1 つを取得し、その上に依存関係を Dockerfile に追加できます。
A: トレーニングした独自のフレームワークモデルを の外部に持ち込んで SageMaker 、任意の SageMaker ホスティングオプションにデプロイする容量 SageMaker を提供します。
SageMaker では、モデルをmodel.tar.gzファイルにパッケージ化し、特定のディレクトリ構造を持つ必要があります。各フレームワークには独自のモデル構造があります (構造の例については、次の質問を参照してください)。詳細については、、、および の SageMaker Python TensorFlow
TensorFlow、 PyTorch、 などの構築済みのフレームワークイメージから選択MXNetしてトレーニング済みモデルをホストできますが、独自のコンテナを構築してトレーニング済みモデルを SageMaker エンドポイントでホストすることもできます。チュートリアルについては、Jupyter ノートブックの例「Building your own algorithm container
A: SageMaker モデルアーティファクトを.tar.gzファイルで圧縮するか、tarball がこの.tar.gzファイルをコンテナの /opt/ml/model/ ディレクトリに SageMaker 自動で抽出します。tarball にはシンボリックリンクや不要なファイルが含まれていてはなりません。 TensorFlow、、 などのフレームワークコンテナのいずれかを使用している場合 PyTorchMXNet、コンテナはTAR構造を次のように想定します。
TensorFlow
model.tar.gz/ |--[model_version_number]/ |--variables |--saved_model.pb code/ |--inference.py |--requirements.txt
PyTorch
model.tar.gz/ |- model.pth |- code/ |- inference.py |- requirements.txt # only for versions 1.3.1 and higher
MXNet
model.tar.gz/ |- model-symbol.json |- model-shapes.json |- model-0000.params |- code/ |- inference.py |- requirements.txt # only for versions 1.6.0 and higher
A: リクエストボディの入力データのContentTypeMIMEタイプ (エンドポイントに送信するデータのMIMEタイプ）。モデルサーバーは ContentType を使用して、指定されたタイプを処理できるかどうかを判断します。
Accept は推論レスポンスMIMEのタイプ (エンドポイントが返すデータのMIMEタイプ) です。モデルサーバーは Accept タイプを使用して、指定されたタイプを返す処理ができるかどうかを判断します。
一般的なMIMEタイプには、text/csv、application/json、および がありますapplication/jsonlines。
A: 変更せずにモデルコンテナにリクエストを SageMaker 渡します。コンテナにはリクエストを逆シリアル化するロジックが含まれている必要があります。組み込みアルゴリズムに定義されている形式については、「Common Data Formats for Inference」を参照してください。独自のコンテナを構築する場合、または SageMaker フレームワークコンテナを使用する場合は、選択したリクエスト形式を受け入れるロジックを含めることができます。
同様に、 SageMaker も変更せずにレスポンスを返し、クライアントはレスポンスを逆シリアル化する必要があります。組み込みアルゴリズムの場合は、特定の形式でレスポンスが返されます。独自のコンテナを構築する場合、または SageMaker フレームワークコンテナを使用する場合は、選択した形式でレスポンスを返すロジックを含めることができます。
Invoke Endpoint API呼び出しを使用して、エンドポイントに対して推論を行います。
入力をペイロードとして InvokeEndpoint に渡すときはAPI、モデルが想定する正しいタイプの入力データを指定する必要があります。InvokeEndpoint API 呼び出しでペイロードを渡すと、リクエストバイトがモデルコンテナに直接転送されます。例えば、イメージの場合は、ContentType に application/jpeg を使用して、モデルがこのタイプのデータに対して推論を実行できることを確認できます。これはJSON、、CSV、ビデオ、またはユーザーが処理する可能性のあるその他のタイプの入力に適用されます。
考慮すべきもう 1 つの要素は、ペイロードサイズの制限です。リアルタイムエンドポイントとサーバーレスエンドポイントでは、ペイロードの上限は 6 MB です。動画を複数のフレームに分割し、フレームごとにエンドポイントを個別に呼び出すことができます。ユースケースが許せば、最大 1 GB のペイロードをサポートする非同期エンドポイントを使用して、ペイロード内の動画全体を送信することもできます。
非同期推論を使用して大きな動画でコンピュータービジョン推論を実行する方法を示す例については、こちらのブログ記事
リアルタイム推論
以下のFAQ項目は SageMaker 、リアルタイム推論に関する一般的な質問に回答します。
A: SageMaker エンドポイントは、、 SageMaker Python AWS SDKs、、 SDK AWS Management Console AWS CloudFormationなどの が AWSサポートするツールを通じて作成できます AWS Cloud Development Kit (AWS CDK)。
エンドポイントの作成には、 SageMaker モデル、 SageMaker エンドポイント設定、エンドポイントの 3 つの主要なエンティティがあります SageMaker 。 SageMaker モデルは、使用しているモデルデータとイメージを指します。エンドポイント設定は、インスタンスタイプやインスタンス数を含む本番稼働用バリアントを定義します。その後、create_endpoint
A: いいえ、さまざまな AWS SDKs を使用するか (利用可能な については「呼び出し/作成」を参照SDKs）、対応するウェブAPIsを直接呼び出すこともできます。
A: マルチモデルエンドポイントは、 SageMaker が提供するリアルタイム推論オプションです。マルチモデルエンドポイントを使用すると、1 つのエンドポイントで数千のモデルをホストできます。マルチモデルサーバー
A: SageMaker リアルタイム推論は、マルチモデルエンドポイント、マルチコンテナエンドポイント、シリアル推論パイプラインなど、さまざまなモデルデプロイアーキテクチャをサポートします。
マルチモデルエンドポイント (MME） — ユーザーは、コスト効果の高い方法で何千ものハイパーパーソナライズされたモデルをデプロイMMEできます。すべてのモデルは共有リソースフリートにデプロイされます。MME は、モデルのサイズとレイテンシーが類似していて、同じ ML フレームワークに属している場合に最適です。これらのエンドポイントは、常に同じモデルを呼び出す必要がない場合に最適です。各モデルを SageMaker エンドポイントに動的にロードして、リクエストを処理することができます。
マルチコンテナエンドポイント (MCE） — MCE1 つの SageMaker エンドポイントのみを使用しながら、コールドスタートなしで、さまざまな ML フレームワークと機能を備えた 15 種類のコンテナをデプロイできます。これらのコンテナは直接呼び出すことができます。MCE は、すべてのモデルをメモリに保持する場合に最適です。
シリアル推論パイプライン (SIP） – を使用してSIP、1 つのエンドポイントで 2～15 個のコンテナを連鎖できます。SIP は、前処理とモデル推論を 1 つのエンドポイントで組み合わせたり、低レイテンシーのオペレーションを行ったりするのに最も適しています。
サーバーレス推論
以下のFAQ項目では、Amazon SageMaker Serverless Inference に関する一般的な質問に回答します。
A: Amazon SageMaker Serverless Inference を使用したモデルのデプロイ は、ML モデルのデプロイとスケーリングを容易にする専用のサーバーレスモデルサービスオプションです。サーバーレス推論エンドポイントは、コンピューティングリソースを自動的に開始し、トラフィックに応じてスケールインおよびスケールアウトできるため、インスタンスタイプを選択したり、プロビジョンドキャパシティを実行したり、スケーリングを管理したりする必要がなくなります。オプションで、サーバーレスエンドポイントのメモリ要件を指定できます。課金されるのは、推論コードの実行期間と処理されたデータ量だけで、アイドル期間には課金されません。
A: サーバーレス推論を使用すると、事前に容量をプロビジョニングしたり、スケーリングポリシーを管理したりする必要がなくなるため、開発者のエクスペリエンスが簡素になります。サーバーレス推論は、使用パターンに基づいて数秒で数十から数千の推論まで瞬時にスケーリングできるため、トラフィックが断続的または予測不可能な ML アプリケーションに最適です。例えば、給与処理会社が使用するチャットボットサービスでは、月末には問い合わせが増え、その月の残りの期間はトラフィックが断続的に発生するとします。このようなシナリオでは、1 か月分のインスタンスをプロビジョニングしても、結局はアイドル期間分の料金を支払うことになるため、費用対効果が高くありません。
サーバーレス推論は、トラフィックを事前に予測したり、スケーリングポリシーを管理したりすることなく、すぐに自動的かつ迅速にスケーリングできるため、このようなユースケースに対処するのに役立ちます。さらに、推論コードの実行とデータ処理にかかるコンピューティング時間に対してのみ支払いが発生するため、トラフィックが断続的に発生するワークロードに最適です。
A: サーバーレスエンドポイントの最小RAMサイズは 1024 MB (1 GB) で、選択できる最大RAMサイズは 6144 MB (6 GB) です。選択できるメモリサイズは、1024 MB、2048 MB、3072 MB、4096 MB、5120 MB、6144 MBです。サーバーレス推論は、選択したメモリに比例してコンピューティングリソースを自動的に割り当てます。より大きなメモリサイズを選択した場合、コンテナはより多くの にアクセスできますvCPUs。
モデルサイズに応じて、エンドポイントのメモリサイズを選択します。一般に、メモリサイズは少なくともモデルサイズと同じ大きさである必要があります。レイテンシー に基づいてモデルに適したメモリを選択するために、ベンチマークが必要になる場合がありますSLAs。メモリサイズ増分の料金は異なります。詳細については、「Amazon の SageMaker 料金
バッチ変換
次のFAQ項目は、 SageMaker バッチ変換に関する一般的な質問に答えます。
A: CSV、RecordIO、 などの特定のファイル形式で SageMaker はTFRecord、データを単一レコードまたは複数レコードのミニバッチに分割し、これをペイロードとしてモデルコンテナに送信できます。の値が の場合MultiRecord、 BatchStrategyは各リクエストの最大レコード数を上限まで SageMaker 送信しますMaxPayloadInMB。の値が の場合SingleRecord、 BatchStrategyは各リクエストで個々のレコード SageMaker を送信します。
A: バッチ変換の最大タイムアウトは 3600 秒です。レコード (ミニバッチあたり) の最大ペイロードサイズは 100 MB です。
A: を使用している場合はCreateTransformJobAPI、、、 MaxConcurrentTransformsなどのパラメータに最適な値を使用することでMaxPayloadInMB、バッチ変換ジョブの完了にかかる時間を短縮できますBatchStrategy。MaxConcurrentTransforms の理想的な値は、バッチ変換ジョブに含まれるコンピューティングワーカーの数と同じです。コンソールを使用している場合は、バッチ変換ジョブ設定ページの「追加設定」セクションでこれらの最適なパラメータ値を指定できます。 は SageMaker、組み込みアルゴリズムに最適なパラメータ設定 SageMaker を自動的に見つけます。カスタムアルゴリズムの場合は、これらの値を execution-parameters エンドポイントを通じて指定します。
A: バッチ変換は CSVと をサポートしていますJSON。
非同期推論
以下のFAQ項目は、 SageMaker 非同期推論に関する一般的な質問に回答します。
非同期推論を使用して、受信した推論リクエストをキューに入れて非同期に処理します。このオプションは、ペイロードサイズが大きいリクエストや、到着時に処理する必要があるリクエストの処理時間が長いリクエストに最適です。オプションで、リクエストをアクティブに処理していないときにインスタンス数をゼロにスケールダウンするように Auto Scaling 設定を構成できます。
A: Amazon は、非同期エンドポイントの自動スケーリング (自動スケーリング) SageMaker をサポートしています。自動スケーリングは、ワークロードの変動に応じて、モデルにプロビジョニングされたインスタンスの数を動的に調整します。が SageMaker サポートする他のホストモデルとは異なり、非同期推論を使用すると、非同期エンドポイントインスタンスをゼロにスケールダウンすることもできます。インスタンスがゼロの場合に受信されるリクエストは、エンドポイントがスケールアップされると処理のためにキューに入れられます。詳細については、「Autoscale an asynchronous endpoint」を参照してください。
Amazon SageMaker Serverless Inference も自動的にゼロにスケールダウンします。はサーバーレスエンドポイントのスケーリング SageMaker を管理するため、これは表示されませんが、トラフィックが発生していない場合は、同じインフラストラクチャが適用されます。
