Amazon SageMaker の最新機能を使用して、モデルのデプロイメントコストを平均 50% 削減 | アマゾン ウェブ サービス

組織はモデルを実稼働環境にデプロイする際、次のような最新のアクセラレータで実行される基盤モデル (FM) のパフォーマンスを最適化する方法を常に探しています。 AWSインフェレンティア GPU との統合により、コストを削減し、応答遅延を短縮して、エンドユーザーに最高のエクスペリエンスを提供できます。 ただし、一部の FM は、デプロイ先のインスタンスで利用可能なアクセラレータを十分に活用しておらず、ハードウェア リソースの非効率的な使用につながっています。 組織によっては、利用可能なアクセラレータをすべて有効活用するために複数の FM を同じインスタンスにデプロイしていますが、これには時間がかかり、管理が難しい複雑なインフラストラクチャ オーケストレーションが必要です。 複数の FM が同じインスタンスを共有する場合、各 FM には独自のスケーリングのニーズと使用パターンがあるため、インスタンスをいつ追加または削除する必要があるかを予測することが困難になります。 たとえば、あるモデルは特定の時間帯に使用量が急増するユーザー アプリケーションに電力を供給するために使用され、別のモデルはより一貫した使用パターンを持つ場合があります。 コストの最適化に加えて、顧客は遅延を削減することで最高のエンドユーザー エクスペリエンスを提供したいと考えています。 これを行うために、多くの場合、FM の複数のコピーをデプロイして、ユーザーからのリクエストに並行して対応します。 FM 出力は単一の文から複数の段落に及ぶ可能性があるため、推論リクエストが完了するまでにかかる時間は大幅に異なり、リクエストがインスタンス間でランダムにルーティングされる場合、レイテンシーの予測不能なスパイクにつながります。 アマゾンセージメーカー は、導入コストと遅延の削減に役立つ新しい推論機能をサポートするようになりました。

推論コンポーネントベースのエンドポイントを作成し、機械学習 (ML) モデルを SageMaker エンドポイントにデプロイできるようになりました。 推論コンポーネント (IC) は ML モデルを抽象化し、CPU、GPU、または AWS ニューロン アクセラレータとモデルごとのスケーリング ポリシー。 推論コンポーネントには次の利点があります。

• SageMaker はモデルを ML インスタンスに最適に配置してパックすることで使用率を最大化し、コスト削減につながります。
• SageMaker は、ML アプリケーションの要件を満たすために、構成に基づいて各モデルをスケールアップおよびスケールダウンします。
• SageMaker は、アイドル状態のコンピューティングを最小限に抑えながら容量を確保するために、インスタンスを動的に追加および削除するようにスケールします。
• モデルのコピーをゼロにスケールダウンして、他のモデル用のリソースを解放できます。 重要なモデルを常にロードし、トラフィックを処理できる状態に保つように指定することもできます。

これらの機能を使用すると、モデルの導入コストを平均 50% 削減できます。 コスト削減効果は、ワークロードとトラフィック パターンによって異なります。 単一のエンドポイントに複数のモデルをパックすることで使用率を最大化し、コストを節約できる方法を説明する簡単な例を見てみましょう。 観光客が現地の習慣やベスト プラクティスを理解できるように支援するチャット アプリケーションがあるとします。このアプリケーションは、Llama 2 の 00 つのバージョンを使用して構築されています。01 つはヨーロッパの訪問者向けに微調整され、もう 11 つはアメリカの訪問者向けに調整されています。 ヨーロッパ モデルのトラフィックは 59:12 ～ 00:23 UTC の間、アメリカ モデルのトラフィックは 59:XNUMX ～ XNUMX:XNUMX UTC の間に予想されます。 これらのモデルを、半分の時間アイドル状態になる独自の専用インスタンスにデプロイする代わりに、コストを節約するために単一のエンドポイントにデプロイできるようになりました。 ヨーロッパ モデルの容量を解放する必要がない場合は、アメリカ モデルをゼロにスケールダウンすることができ、またその逆も可能です。 これにより、ハードウェアを効率的に利用し、無駄を避けることができます。 これは XNUMX つのモデルを使用した単純な例ですが、このアイデアを簡単に拡張して、ワークロードに応じて自動的にスケールアップおよびスケールダウンする単一のエンドポイントに数百のモデルをパックすることができます。

この投稿では、IC ベースの SageMaker エンドポイントの新機能を紹介します。 また、推論コンポーネントと API を使用して複数のモデルをデプロイする方法についても説明します。 最後に、新しい可観測性機能のいくつかと、モデルの自動スケーリング ポリシーを設定し、エンドポイントのインスタンス スケーリングを管理する方法について詳しく説明します。 新しい簡素化されたインタラクティブなユーザー エクスペリエンスを通じてモデルをデプロイすることもできます。 また、推論ワークロードのレイテンシーとパフォーマンスを最適化するための高度なルーティング機能もサポートしています。

ビルディングブロック

これらの新しい機能がどのように機能するかを詳しく見て理解しましょう。 以下は、SageMaker ホスティングに関する新しい用語の一部です。

• 推論コンポーネント – モデルをエンドポイントにデプロイするために使用できる SageMaker ホスティング オブジェクト。 以下を指定して推論コンポーネントを作成できます。
  • SageMaker モデル、または SageMaker 互換のイメージおよびモデル アーティファクトの仕様。
  • コンピューティング リソース要件。CPU コア、ホスト メモリ、アクセラレータの数など、モデルの各コピーのニーズを指定します。
• モデルコピー – リクエストを処理できる推論コンポーネントの実行時コピー。
• マネージド インスタンスの自動スケーリング – エンドポイントに使用されるコンピューティング インスタンスの数をスケールアップまたはスケールダウンする SageMaker ホスティング機能。 インスタンスのスケーリングは、推論コンポーネントのスケーリングに反応します。

新しい推論コンポーネントを作成するには、コンテナイメージとモデルアーティファクトを指定するか、すでに作成した SageMaker モデルを使用できます。 また、モデルを実行する必要があるホスト CPU コア、ホスト メモリ、アクセラレータの数などのコンピューティング リソース要件を指定する必要もあります。

推論コンポーネントをデプロイするときに、次のものを指定できます。 MinCopies モデルが必要な量だけロードされていることを確認し、リクエストに対応できるようにします。

推論コンポーネントのコピーがゼロになるようにポリシーを設定するオプションもあります。 たとえば、IC に対してロードを実行していない場合、モデルのコピーはアンロードされます。 これにより、アクティブなワークロードに置き換えられるリソースが解放され、エンドポイントの使用率と効率が最適化されます。

推論リクエストが増加または減少すると、IC のコピーの数も自動スケール ポリシーに基づいてスケールアップまたはスケールダウンできます。 SageMaker は配置を処理して、可用性とコストを考慮してモデルのパッキングを最適化します。

さらに、マネージド インスタンスの自動スケーリングを有効にすると、SageMaker はトラフィックを処理するために特定の時間にロードする必要がある推論コンポーネントの数に応じてコンピューティング インスタンスをスケーリングします。 SageMaker はインスタンスをスケールアップし、インスタンスと推論コンポーネントをパックして、モデルのパフォーマンスを維持しながらコストを最適化します。 マネージド インスタンス スケーリングの使用をお勧めしますが、必要に応じて、アプリケーションの自動スケーリングを通じてスケーリングを自分で管理するオプションもあります。

SageMaker は、推論コンポーネントが不要になった場合に推論コンポーネントのバランスを再調整し、インスタンスをスケールダウンしてコストを節約します。

API のウォークスルー

SageMaker は、と呼ばれる新しいエンティティを導入しました。 InferenceComponent。 これにより、ML モデルのホストの詳細がエンドポイント自体から切り離されます。 の InferenceComponent を使用すると、使用する SageMaker モデルやコンテナの詳細やモデル アーティファクトなど、モデルをホストするための主要なプロパティを指定できます。 また、デプロイするコンポーネント自体のコピーの数、および必要なアクセラレータ (GPU、Inf、または Trn アクセラレータ) または CPU (vCPU) の数も指定します。 これにより、将来デプロイする予定の任意の数のモデルに対して単一のエンドポイントを使用できる柔軟性が向上します。

推論コンポーネントを含むエンドポイントを作成するための Boto3 API 呼び出しを見てみましょう。 この投稿の後半で説明するパラメーターがいくつかあることに注意してください。

以下はコード例です。 CreateEndpointConfig:

sagemaker_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ExecutionRoleArn=role, ProductionVariants=[{ "VariantName": variant_name, "InstanceType": instance_type, "InitialInstanceCount": initial_instance_count, "ModelDataDownloadTimeoutInSeconds": model_data_download_timeout_in_seconds, "ContainerStartupHealthCheckTimeoutInSeconds": container_startup_health_check_timeout_in_seconds, {"ManagedInstanceScaling": { "Status": "ENABLED", "MinInstanceCount": initial_instance_count, "MaxInstanceCount": max_instance_count, } }, }],
)

以下はコード例です。 CreateEndpoint:

sagemaker_client.create_endpoint( EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name,
)

以下はコード例です。 CreateInferenceComponent:

sm_client.create_inference_component( InferenceComponentName=inference_component_name, EndpointName=endpoint_name, VariantName=variant_name, Specification={ "Container": { "Image": inference_image_uri, "ArtifactUrl": s3_code_artifact, }, "StartupParameters": { "ModelDataDownloadTimeoutInSeconds": 300, "ContainerStartupHealthCheckTimeoutInSeconds": 600, }, "ComputeResourceRequirements": {"NumberOfAcceleratorDevicesRequired": 1, "MinMemoryRequiredInMb": 1024} }, RuntimeConfig={"CopyCount": 1},
)

このデカップリングは、 InferenceComponent エンドポイントへの接続により柔軟性が提供されます。 同じインフラストラクチャ上で複数のモデルをホストし、要件の変化に応じてモデルを追加または削除できます。 各モデルは必要に応じて個別に更新できます。 さらに、ビジネス ニーズに応じてモデルを拡張できます。 InferenceComponent モデルごとに容量を制御することもできます。 つまり、ホストする各モデルのコピーの数を決定できます。 この予測可能なスケーリングは、各モデルの特定のレイテンシ要件を満たすのに役立ちます。 全体、 InferenceComponent ホストされたモデルをより詳細に制御できるようになります。

次の表では、エンドポイントを作成して呼び出すための高レベルのアプローチを並べて比較しています。 InferenceComponent とと InferenceComponent。 現在、CreateModel() は IC ベースのエンドポイントではオプションであることに注意してください。

の導入 InferenceComponent モデル レベルでスケーリングできます。見る インスタンスと IC の自​​動スケーリングを詳しく調べる 詳しい方法については InferenceComponent オートスケーリングで動作します。

SageMaker エンドポイントを呼び出すときに、新しいパラメーターを指定できるようになりました InferenceComponentName 望むものを打つために InferenceComponentName。 SageMaker は、リクエストされたインスタンスをホストするインスタンスへのリクエストのルーティングを処理します。 InferenceComponentName。 次のコードを参照してください。

smr_client = boto3.client("sagemaker-runtime") response_model = smr_client.invoke_endpoint( InferenceComponentName=inference_component_name, EndpointName=endpoint_name, Body=payload, ContentType="application/json", )

デフォルトでは、SageMaker はエンドポイントをサポートするインスタンスへのリクエストのランダムなルーティングを使用します。 最も未処理のリクエストのルーティングを有効にしたい場合は、エンドポイントの設定でルーティング戦略を設定できます。 RoutingConfig:

sm_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ExecutionRoleArn=role, ProductionVariants=[{ "VariantName": variant_name, "InstanceType": instance_type, "InitialInstanceCount": initial_instance_count, ... 'RoutingConfig': { 'RoutingStrategy': 'LEAST_OUTSTANDING_REQUESTS' } }],
)

最も未処理のリクエストのルーティングは、リクエストを処理する能力がより高い特定のインスタンスにルーティングされます。 これにより、より均一な負荷分散とリソース使用率が提供されます。

に加えて CreateInferenceComponentでは、次の API が利用できるようになりました。

• DescribeInferenceComponent
• DeleteInferenceComponent
• UpdateInferenceComponent
• ListInferenceComponents

InferenceComponent のログとメトリクス

InferenceComponent ログは次の場所にあります /aws/sagemaker/InferenceComponents/<InferenceComponentName>。 コンテナ内の stderr および stdout に送信されるすべてのログは、次のログに送信されます。 アマゾンクラウドウォッチ.

IC ベースのエンドポイントの導入により、追加のインスタンス メトリック、推論コンポーネント メトリック、呼び出しメトリックを表示できるようになりました。

SageMaker インスタンスの場合、 GPUReservation および CPUReservation メトリクスを使用して、デプロイした推論コンポーネントに基づいてエンドポイント用に予約されたリソースを確認します。 これらのメトリクスは、エンドポイントと自動スケーリング ポリシーのサイズを決定するのに役立ちます。 エンドポイントにデプロイされたすべてのモデルに関連付けられた集計メトリックを表示することもできます。

SageMaker は、推論コンポーネント レベルでのメトリクスも公開します。これにより、デプロイした推論コンポーネントのリソースの使用状況をより詳細に表示できます。 これにより、次のような総リソース使用率を把握できます。 GPUUtilizationNormalized および GPUMemoryUtilizationNormalized デプロイした推論コンポーネントごとに、コピーが XNUMX 個または多数ある可能性があります。

最後に、SageMaker は呼び出しメトリクスを提供し、推論コンポーネントの呼び出しを集合的に追跡するようになりました (Invocations) またはインスタンス化されたコピーごと (InvocationsPerCopy)

メトリクスの包括的なリストについては、以下を参照してください。 SageMakerエンドポイント呼び出しメトリクス.

モデルレベルの自動スケーリング

説明した自動スケーリング動作を実装するには、SageMaker エンドポイント設定と推論コンポーネントを作成するときに、初期インスタンス数と初期モデル コピー数をそれぞれ定義します。 エンドポイントと対応する IC を作成した後、IC レベルで自動スケーリングを適用するには、まずスケーリング ターゲットを登録し、次にスケーリング ポリシーを IC に関連付ける必要があります。

スケーリング ポリシーを実装するときは、次を使用します。 SageMakerInferenceComponentInvocationsPerCopy、これは SageMaker によって導入された新しいメトリクスです。 これは、モデル コピーごとの XNUMX 分あたりの平均呼び出し数を取得します。

aas_client.put_scaling_policy( PolicyName=endpoint_name, PolicyType='TargetTrackingScaling', ServiceNamespace=service_namespace, ResourceId=resource_id, ScalableDimension=scalable_dimension, TargetTrackingScalingPolicyConfiguration={ "PredefinedMetricSpecification": { "PredefinedMetricType": "SageMakerInferenceComponentInvocationsPerCopy", }, "TargetValue": autoscaling_target_value, "ScaleInCooldown": 300, # default "ScaleOutCooldown": 300, # default },
)

スケーリング ポリシーを設定した後、SageMaker は各自動スケーリング ターゲットに対して 3 つの CloudWatch アラームを作成します。1 つは 15 分間アラームが発生した場合にスケールアウトをトリガーするもの (15 分間のデータ ポイントが 1 つ)、もう 1 つはアラームが 2 分間発生した場合にスケールインをトリガーするものです。 (XNUMX 分間のデータ ポイントが XNUMX 個)、次のスクリーンショットに示すように。 スケーリング アクションをトリガーする時間は、通常、エンドポイントが CloudWatch にメトリクスを公開するのに時間がかかり、また、 AutoScaling 反応する。 クールダウン期間は、スケールインまたはスケールアウト アクティビティが完了してから、別のスケールアウト アクティビティを開始できるまでの時間 (秒単位) です。 スケールアウトのクールダウンがエンドポイントの更新時間よりも短い場合は、SageMaker エンドポイントを更新できないため、効果はありません。 更新 状態。

IC レベルの自動スケーリングを設定する場合は、次のことを確認する必要があることに注意してください。 MaxInstanceCount パラメータが、このエンドポイントが処理できる IC の最大数以下です。 たとえば、エンドポイント構成でインスタンスが XNUMX つだけを持つようにエンドポイントが構成されており、このインスタンスがモデルのコピーを最大 XNUMX つしかホストできない場合、 MaxInstanceCount ただし、SageMaker が提供するマネージド自動スケーリング機能を使用して、必要なモデルのコピー数に基づいてインスタンス数を自動的にスケーリングし、より多くのコンピューティング リソースのニーズを満たすこともできます。 次のコード スニペットは、エンドポイント構成の作成中にマネージド インスタンスのスケーリングを設定する方法を示しています。 このようにして、IC レベルの自動スケーリングでモデルのコピーをホストするためにより多くのインスタンス数が必要な場合、SageMaker はインスタンス数を自動的にスケールアウトして、IC レベルのスケーリングを成功させます。

sagemaker_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ExecutionRoleArn=role, ProductionVariants=[{ "VariantName": variant_name, "InstanceType": instance_type, "InitialInstanceCount": initial_instance_count, "ModelDataDownloadTimeoutInSeconds": model_data_download_timeout_in_seconds, "ContainerStartupHealthCheckTimeoutInSeconds": container_startup_health_check_timeout_in_seconds, {"ManagedInstanceScaling": { "Status": "ENABLED", "MinInstanceCount": initial_instance_count, "MaxInstanceCount": max_instance_count, } }, }],
)

同じエンドポイントに対して複数の自動スケーリング ポリシーを適用できます。つまり、IC で作成されたエンドポイントに従来の自動スケーリング ポリシーを適用し、他のエンドポイント メトリックに基づいてスケールアップおよびスケールダウンできるようになります。 詳細については、以下を参照してください。 Amazon SageMaker の Auto Scaling で機械学習の展開を最適化する。 ただし、これは可能ですが、スケーリングを自分で管理するよりも、マネージド インスタンスのスケーリングを使用することをお勧めします。

まとめ

この投稿では、予測可能なパフォーマンスを提供しながら、コンピューティング インスタンスの使用率を最大化し、数百のモデルに拡張し、コストを最適化するのに役立つ SageMaker 推論の新機能を紹介しました。 さらに、API のウォークスルーを提供し、ワークロードに合わせて推論コンポーネントを構成およびデプロイする方法を示しました。

私達はまたサポートします 高度なルーティング機能 推論ワークロードのレイテンシーとパフォーマンスを最適化します。 SageMaker は、コストとパフォーマンスを考慮して推論ワークロードを最適化し、モデルレベルの粒度で管理できるようにします。 私たちは、 ノートのセット ここでは、異なるコンテナーを使用し、GitHub で自動スケーリング ポリシーを適用して、1 つの異なるモデルをデプロイする方法を示します。 今すぐノートブック XNUMX から始めて、新しい SageMaker ホスティング機能を実際に試してみることをお勧めします。

著者について

ジェームズ・パーク アマゾン ウェブ サービスのソリューション アーキテクトです。 彼は Amazon.com と協力して AWS 上のテクノロジー ソリューションを設計、構築、デプロイしており、特に AI と機械学習に興味を持っています。 余暇には、新しい文化、新しい経験を探し、最新のテクノロジー トレンドを把握することを楽しんでいます。 あなたは彼を見つけることができます LinkedIn.

メラニー・リー博士号は、オーストラリアのシドニーに拠点を置く AWS のシニア AI/ML スペシャリスト TAM です。 彼女は、企業顧客が AWS 上の最先端の AI/ML ツールを使用してソリューションを構築できるよう支援し、ベストプラクティスを使用した ML ソリューションの設計と実装に関するガイダンスを提供します。 余暇には、自然を探索したり、家族や友人と時間を過ごすのが大好きです。

マーク・カープ Amazon SageMaker Service チームの ML アーキテクトです。 彼は、お客様が大規模な ML ワークロードを設計、デプロイ、管理できるよう支援することに重点を置いています。 余暇には、旅行や新しい場所の探索を楽しんでいます。

アランタン SageMaker のシニア プロダクト マネージャーであり、大規模なモデルの推論に取り組んでいます。 彼は機械学習を分析の分野に適用することに情熱を注いでいます。 仕事以外では、アウトドアを楽しんでいます。

ラグーラメシャ Amazon SageMaker サービスチームのシニア ML ソリューションアーキテクトです。 彼は、顧客が ML 本番ワークロードを大規模に構築、デプロイ、SageMaker に移行できるよう支援することに重点を置いています。 彼は機械学習、AI、コンピューター ビジョンの分野を専門とし、テキサス大学ダラス校でコンピューター サイエンスの修士号を取得しています。 自由時間には、旅行や写真撮影を楽しんでいます。

ルピンダー・グレワル AWS のシニア Ai/ML スペシャリスト ソリューション アーキテクトです。 彼は現在、SageMaker でのモデルと MLOps の提供に注力しています。 この役職に就く前は、モデルの構築とホスティングを行う機械学習エンジニアとして働いていました。 仕事以外では、テニスや山道でのサイクリングを楽​​しんでいます。

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

サウラブ・トリカンデ Amazon SageMaker Inference のシニア プロダクト マネージャーです。 彼は顧客と協力することに情熱を傾けており、機械学習を民主化するという目標に動機付けられています。 彼は、複雑な ML アプリケーションのデプロイ、マルチテナント ML モデル、コストの最適化、およびディープ ラーニング モデルのデプロイをよりアクセスしやすくすることに関連する主要な課題に焦点を当てています。 余暇には、Saurabh はハイキングを楽しんだり、革新的なテクノロジーについて学んだり、TechCrunch をフォローしたり、家族と過ごしたりしています。

ラクシュミーラマクリシュナン AWSのAmazonSageMaker Machine Learning（ML）プラットフォームチームのプリンシパルエンジニアであり、製品の技術的リーダーシップを提供しています。 彼は9年以上Amazonでいくつかのエンジニアリングの役割を果たしてきました。 彼は、インドのカルナタカにある国立工科大学で情報技術の工学士号を取得し、ミネソタ大学ツインシティーズ校でコンピューターサイエンスの修士号を取得しています。

デビッド・ニゲンダ は、Amazon SageMaker チームのシニア ソフトウェア開発エンジニアであり、現在、本番環境の機械学習ワークフローの改善と、新しい推論機能の立ち上げに取り組んでいます。 余暇には、彼は子供たちについていくように努めています。

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
• 情報源： https://aws.amazon.com/blogs/machine-learning/reduce-model-deployment-costs-by-50-on-average-using-sagemakers-latest-features/