「Amazon SageMakerの最新機能を使用することで、モデルのデプロイコストを平均で50％削減します」

『Amazon SageMakerの最新機能を活用して、モデルのデプロイコストを平均50％削減』

組織がモデルを本番環境に展開する際、最新のアクセラレータ（AWS InferentiaやGPUなど）で実行されるファウンデーションモデル（FM）のパフォーマンスを最適化する方法を常に求めています。そのためには、コストを削減しレスポンス待ち時間を短縮してエンドユーザに最高の体験を提供する必要があります。しかし、一部のFMはデプロイされたインスタンスで利用可能なアクセラレータを完全に活用していないため、ハードウェアリソースの無駄な使用が生じることがあります。一部の組織では、利用可能なアクセラレータをより効果的に活用するため、同じインスタンスに複数のFMを展開していますが、これには手間と管理の困難を伴う複雑なインフラストラクチャのオーケストレーションが必要です。複数のFMが同じインスタンスを共有する場合、各FMはそれぞれ独自のスケーリングニーズと使用パターンを持っており、いつインスタンスを追加または削除する必要があるかを予測することは困難です。たとえば、1つのモデルは使用時間帯によって使用が急増するユーザーアプリケーションのパワーリングに使用される場合があり、他のモデルはより一貫した使用パターンを持つ場合もあります。コストの最適化に加えて、顧客はレイテンシを低減して最高のエンドユーザ体験を提供したいと考えています。そのためには、しばしばFMの複数のコピーを並列でリクエストに対応するために展開します。FMの出力は一文から複数の段落までの範囲になる可能性があるため、リクエストがランダムにインスタンス間でルーティングされるとレイテンシの予測不可能なスパイクが生じます。 Amazon SageMakerでは、新しい推論機能をサポートしており、デプロイメントのコストとレイテンシを低減するのに役立ちます。

これにより、予測エンドポイントの作成とMLモデルの展開が可能になります。インファレンスコンポーネント（IC）はMLモデルを抽象化し、各モデルにCPU、GPU、AWS Neuronアクセラレータおよびスケーリングポリシーを割り当てることができます。インファレンスコンポーネントには以下の利点があります。

• SageMakerは、最適な場所とモデルを選択し、利用可能なMLインスタンスに最大限の利用率を提供します。
• SageMakerは、設定に基づいて各モデルをスケールアップおよびスケールダウンし、MLアプリケーションの要件を満たします。
• SageMakerは、空き計算を最小限に抑えながら、必要に応じてインスタンスを動的に追加および削除して容量を確保します。
• 他のモデルのリソースを解放するために、モデルのコピーをゼロにスケールダウンすることもできます。また、重要なモデルを常にロードしてトラフィックを処理できるように指定することもできます。

これらの機能により、平均してモデルのデプロイメントコストを50%削減できます。コストの節約効果は、ワークロードとトラフィックパターンによって異なります。単純な例を挙げて、複数のモデルを1つのエンドポイントに詰め込むことで最大限の利用とコスト削減を実現する方法を説明しましょう。エンドポイントには、ヨーロッパ訪問者向けにチューニングされたLlama 2のバリエーション2つが含まれる、地元の習慣やベストプラクティスを理解するのに役立つチャットアプリケーションがあるとします。ヨーロッパのモデルはUTC時間帯の00:01〜11:59の間にトラフィックが予想され、アメリカのモデルはUTC時間帯の12:00〜23:59の間にトラフィックが予想されます。これらのモデルを半分の時間がアイドル状態になる専用インスタンスに展開する代わりに、コストを節約するために1つのエンドポイントに展開できます。アメリカのモデルは必要ないときにゼロにスケールダウンしてヨーロッパのモデルのために容量を確保し、逆も同様です。これにより、ハードウェアを効率的に活用し、無駄を防ぐことができます。これは2つのモデルを使用した単純な例ですが、これを考えを容易に拡張して、ワークロードに応じて自動的にスケールアップおよびスケールダウンする1つのエンドポイントに何百ものモデルを詰め込むことができます。

この記事では、ICベースのSageMakerエンドポイントの新機能について説明します。また、インファレンスコンポーネントとAPIを使用して複数のモデルを展開する方法を紹介します。さらに、新しい監視機能やモデルの自動スケーリングポリシーの設定方法、エンドポイントのインスタンススケーリングの管理方法について詳細を説明します。また、新しい簡素化されたインタラクティブなユーザーエクスペリエンスを介してモデルを展開することもできます。さらに、インファレンスワークロードのレイテンシとパフォーマンスを最適化するための高度なルーティング機能もサポートしています。

• 「Amazon SageMaker のルーティング戦略を使用して、リアルタイムの推論レイテンシを最小限に抑えましょう」
• 「Amazon SageMakerを使用して、クラシカルなMLおよびLLMsを簡単にパッケージ化してデプロイする方法、パート2：SageMaker Studioでのインタラクティブなユーザーエクスペリエンス」
• 「Amazon SageMakerを使用してクラシカルなMLとLLMsを簡単にパッケージ化し、デプロイする方法 – パート1：PySDKの改善」

ビルディングブロック

これらの新機能がどのように機能するかを詳しく見てみましょう。以下は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を使用しない場合と使用する場合のエンドポイントの作成と呼び出しの高レベルなアプローチを比較しています。ICベースのエンドポイントでは、CreateModel()はオプションとなります。

ステップ	モデルベースのエンドポイント	インフェレンスコンポーネントベースのエンドポイント
1	CreateModel(…)	CreateEndpointConfig(…)
2	CreateEndpointConfig(…)	CreateEndpoint(…)
3	CreateEndpoint(…)	CreateInferenceComponent(…)
4	InvokeEndpoint(…)	InvokeEndpoint(InferneceComponentName=‘value’…)

InferenceComponentの導入により、モデルレベルでのスケーリングが可能となりました。詳細については、Delve into instance and IC auto scalingをご覧ください。

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に表示されるすべてのログは、Amazon CloudWatchでこれらのログに送信されます。

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

SageMakerインスタンスでは、展開したインファレンスコンポーネントに基づいてエンドポイントに予約されたリソースを示すGPUReservationおよびCPUReservationメトリクスをトラッキングすることができます。これらのメトリクスは、エンドポイントとオートスケーリングポリシーのサイジングに役立ちます。また、エンドポイントに展開されたすべてのモデルに関連する集計メトリクスも表示できます。

SageMakerはまた、インファレンスコンポーネントレベルでメトリクスを公開しており、展開されたインファレンスコンポーネントごとのリソース利用のより詳細なビューを示すことができます。これにより、展開した各インファレンスコンポーネントのGPUUtilizationNormalizedおよびGPUMemoryUtilizationNormalizedなどの集計リソース利用量のビューを取得できます。

最後に、SageMakerは呼び出しメトリクスを提供し、インファレンスコンポーネントの呼び出しを集計的にトラッキングします（Invocations）またはインスタンス化された各コピーごとにトラッキングします（InvocationsPerCopy）

メトリクスの詳細なリストは、SageMakerエンドポイント呼び出しメトリクスを参照してください。

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

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

スケーリングポリシーを実装する際に、私たちはSageMakerが導入した新しいメトリクスSageMakerInferenceComponentInvocationsPerCopyを使用します。これは、1分あたりの平均モデルコピーごとの呼び出し数をキャプチャします。

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,  # デフォルト        "ScaleOutCooldown": 300,  # デフォルト    },)

スケーリングポリシーを設定した後、SageMakerは各オートスケーリングターゲットに対して2つのCloudWatchアラームを作成します：アラームが3分間（3つの1分間データポイント）アラームの場合にスケールアウトをトリガーするためのアラーム1つと、アラームが15分間（15つの1分間データポイント）アラームの場合にスケールインをトリガーするためのアラーム1つ、以下のスクリーンショットに示すように。スケーリングアクションのトリガー時間は、通常はそれらの分数よりも1〜2分長くなります。これは、エンドポイントがメトリクスをCloudWatchに公開するために時間がかかり、AutoScalingが反応するためにも時間がかかるためです。クールダウン期間は、スケールインまたはスケールアウトのアクティビティが完了してから次のスケールアウトのアクティビティを開始するまでの時間（秒単位）です。スケールアウトのクールダウンがエンドポイントの更新時間よりも短い場合、効果はありません。なぜなら、SageMakerエンドポイントが更新中の状態である場合は、更新が不可能だからです。

ICレベルの自動スケーリング設定時には、MaxInstanceCountパラメータがこのエンドポイントが処理できるICの最大数以下であることを確認する必要があります。例えば、エンドポイントの設定でインスタンスが1つしか設定されておらず、このインスタンスがモデルの最大4つのコピーをホストできる場合、MaxInstanceCountは4以下でなければなりません。ただし、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における自動スケーリングを使用してマシンラーニング展開を最適化するを参照してください。ただし、これは可能ですが、スケーリングを自分で管理する代わりに、マネージドなインスタンススケーリングの使用をお勧めします。

結論

この記事では、SageMakerの推論における新機能を紹介しました。これにより、コンピュートインスタンスの利用率を最大化し、数百のモデルにスケーリングし、コストを最適化し、予測可能なパフォーマンスを提供することができます。さらに、APIの手順を説明し、ワークロードに適した推論コンポーネントを設定および展開する方法を紹介しました。

また、推論ワークロードのレイテンシとパフォーマンスを最適化するための高度なルーティング機能もサポートしています。SageMakerは、コストとパフォーマンスを最適化し、モデルレベルの管理のための詳細な操作性を提供できます。GitHubで異なるコンテナを使用し、自動スケーリングポリシーを適用する3つの異なるモデルを展開する手順を作成しました。新しいSageMakerのホスティング機能を使って、まずノートブック1から始めて手を動かしてみてください！

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!