SageMaker でのモデル ホスティング パターン: SageMaker でのモデルのテストと更新のベスト プラクティス

アマゾンセージメーカー は、開発者とデータ サイエンティストが機械学習 (ML) モデルを迅速に構築、トレーニング、デプロイできるフル マネージド サービスです。 SageMaker を使用すると、ホストされているエンドポイントに ML モデルをデプロイし、リアルタイムで推論結果を得ることができます。 エンドポイントのパフォーマンス メトリックを簡単に表示できます。 アマゾンクラウドウォッチ, エンドポイントを自動的にスケーリングする トラフィックに基づいて、可用性を失うことなく本番環境でモデルを更新します。 SageMaker は、ユースケースに応じて、次のいずれかの方法で推論用の ML モデルをデプロイするためのさまざまなオプションを提供します。

• ミリ秒単位で提供する必要がある同期予測には、SageMaker を使用します リアルタイム推論
• トラフィックの急増の間にアイドル期間があり、コールド スタートを許容できるワークロードの場合は、 サーバーレス推論
• 最大 1 GB の大きなペイロード サイズ、長い処理時間 (最大 15 分)、およびほぼリアルタイムのレイテンシー要件 (数秒から数分) を持つリクエストの場合は、SageMaker を使用します。 非同期推論
• データセット全体の予測を取得するには、SageMaker を使用します バッチ変換

リアルタイム推論は、リアルタイム、インタラクティブ、低レイテンシーの要件がある推論ワークロードに最適です。 モデルを SageMaker ホスティング サービスにデプロイし、推論に使用できるエンドポイントを取得します。 これらのエンドポイントは、完全に管理されたインフラストラクチャとサポートによって支えられています 自動スケーリング. を使用して複数のモデルを XNUMX つのエンドポイントに組み合わせることで、効率とコストを改善できます。 マルチモデル エンドポイント or マルチコンテナ エンドポイント.

パフォーマンスの測定、改善の測定、または A/B テストの実行のために、同じモデルの複数のバリアントを本番環境にデプロイする特定のユース ケースがあります。 このような場合、SageMaker マルチバリアント エンドポイントは、モデルの複数の本番バリアントを同じ SageMaker エンドポイントにデプロイできるため便利です。

この投稿では、SageMaker のマルチバリアント エンドポイントと最適化のベスト プラクティスについて説明します。

SageMaker リアルタイム推論オプションの比較

次の図は、SageMaker によるリアルタイム推論オプションの概要を示しています。

単一モデルのエンドポイントを使用すると、専用インスタンスまたはサーバーレスでホストされているコンテナーに XNUMX つのモデルをデプロイして、低レイテンシーと高スループットを実現できます。 モデルを作成し、 検索する a SageMaker がサポートするイメージ TensorFlow、PyTorch、Scikit-learn などの一般的なフレームワーク向け。 モデルのカスタム フレームワークを使用している場合は、次のこともできます。 自分の容器を持ってきて 依存関係をインストールします。

SageMaker は、マルチモデル エンドポイント (MME) やマルチコンテナ エンドポイント (MCE) などのより高度なオプションもサポートしています。 MME は、数百から数万のモデルを扱っており、各モデルを個別のエンドポイントとして展開する必要がない場合に役立ちます。 MME を使用すると、インスタンスでホストされる共有サービス コンテナーを使用して、同じエンドポイント内で費用対効果が高くスケーラブルな方法で複数のモデルをホストできます。 基盤となるインフラストラクチャ (コンテナとインスタンス) は変わりませんが、モデルは、使用状況とエンドポイントで使用可能なメモリの量に応じて、共通の S3 の場所から動的にロードおよびアンロードされます。 低レイテンシで高スループットの推論を実現するには、このエンドポイントへのターゲット モデルを使用した API 呼び出しをアプリケーションに含める必要があります。 モデルごとに個別のエンドポイントに料金を支払う代わりに、単一のエンドポイントの価格で多くのモデルをホストできます。

MCE を使用すると、15 つのエンドポイントで最大 XNUMX 個の異なる ML コンテナーを実行し、それらを個別に呼び出すことができます。 これらの ML コンテナーをさまざまなサービス スタック (ML フレームワーク、モデル サーバー、アルゴリズムなど) で構築して、コストを節約するために同じエンドポイントで実行できます。 コンテナをつなぎ合わせることができます シリアル推論パイプライン またはコンテナを個別に呼び出します。 これは、異なるトラフィック パターンと同様のリソース ニーズを持つ複数の異なる ML モデルがある場合に最適です。 MCE を使用する場合の例には、次のようなものがありますが、これらに限定されません。

• インスタンスの全容量を飽和させるのに十分なトラフィックがない、異なるフレームワーク (TensorFlow、PyTorch、Scikit-learn など) にわたるモデルのホスティング
• 異なる ML アルゴリズム (レコメンデーション、予測、分類など) とハンドラー関数を使用した同じフレームワークからのモデルのホスティング
• A/B テストのようなシナリオのための、異なるフレームワーク バージョン (TensorFlow 1.x と TensorFlow 2.x など) で実行されている同様のアーキテクチャの比較

SageMaker マルチバリアント エンドポイント (MVE) を使用すると、本番バリアントを使用して、同じエンドポイントの背後で複数のモデルまたはモデル バージョンをテストできます。 各プロダクション バリアントは、ML モデルと、モデルをホストするためにデプロイされたリソース (サービング コンテナーやインスタンスなど) を識別します。

SageMaker マルチバリアントエンドポイントの概要

本番環境の ML ワークフローでは、データ サイエンティストと ML エンジニアは、データ/モデル/コンセプトのドリフトに基づく再トレーニング、ハイパーパラメーターの調整、機能の選択、フレームワークの選択など、さまざまな方法でモデルを改良します。 新しいモデルと実稼働トラフィックを持つ古いモデルの間で A/B テストを実行することは、新しいモデルの検証プロセスの効果的な最終ステップになる可能性があります。 A/B テストでは、モデルのさまざまなバリアントをテストし、各バリアントが互いにどのように機能するかを比較します。 次に、最もパフォーマンスの高いモデルを選択して、以前のモデルを、以前のバージョンよりも優れたパフォーマンスを提供する新しいバージョンに置き換えます。 本番バリアントを使用することで、これらの ML モデルと異なるモデル バージョンを同じエンドポイントの背後でテストできます。 これらの ML モデルは、さまざまなデータセット、さまざまなアルゴリズム、および ML フレームワークを使用してトレーニングできます。 それらを異なるインスタンス タイプにデプロイします。 またはこれらのオプションの任意の組み合わせ。 SageMaker エンドポイントに接続されたロードバランサーは、呼び出しリクエストを複数の本番バリアントに分散する機能を提供します。 たとえば、各バリアントのトラフィック分散を指定することで、プロダクション バリアント間でトラフィックを分散したり、リクエストごとに特定のバリアントを直接呼び出したりできます。

Auto Scaling ポリシーを構成して、XNUMX 秒あたりのリクエスト数などのメトリクスに基づいてバリアントを自動的にスケールインまたはスケールアウトすることもできます。

次の図は、MVE がどのように機能するかをより詳細に示しています。

MVE のデプロイも非常に簡単です。 必要なのは、モデル オブジェクトをイメージとモデル データを使用して定義することだけです。 create_model SageMaker Python SDK から構築し、使用してエンドポイント構成を定義します。 production_variant それぞれ独自の異なるモデルとリソース要件 (インスタンスの種類と数) を持つプロダクション バリアントを作成するためのコンストラクト。 これにより、さまざまなインスタンス タイプでモデルをテストすることもできます。 デプロイするには、 endpoint_from_production_variant エンドポイントを作成するための構造。

エンドポイントの作成中に、SageMaker はエンドポイント設定で指定されたホスティング インスタンスをプロビジョニングし、本番バリアントで指定されたモデルと推論コンテナをホスティング インスタンスにダウンロードします。 コンテナーを起動し、ping を使用してヘルス チェックを実行した後に成功の応答が返された場合、エンドポイントの作成が完了したことを示すメッセージがユーザーに送信されます。 次のコードを参照してください。

sm_session.create_model(
	name=model_name,
	role=role,
	container_defs={'Image':  image_uri, 'ModelDataUrl': model_url}
	)

sm_session.create_model(
	name=model_name2,
	role=role,
	container_defs={'Image':  image_uri, 'ModelDataUrl': model_url2 }
	)

variant1 = production_variant(
	model_name=model_name,
	instance_type="ml.c5.4xlarge",
	initial_instance_count=1,
	variant_name="Variant1",
	initial_weight=1
	)

variant2 = production_variant(
	model_name=model_name2,
	instance_type="ml.m5.4xlarge",
	initial_instance_count=1,
	variant_name="Variant2",
	initial_weight=1
	)

sm_session.endpoint_from_production_variants(
	name=endpoint_name,
	production_variants=[variant1,  variant2]
	)

前の例では、それぞれ独自の異なるモデルを持つ XNUMX つのバリアントを作成しました (これらは異なるインスタンス タイプと数を持つこともできます)。 私たちは initial_weight 両方のバリアントで 1: これは、リクエストの 50% が Variant1、残りの 50% を Variant2. 両方のバリアントの重みの合計は 2 で、各バリアントには 1 の重みが割り当てられています。これは、各バリアントが合計トラフィックの 50% を受け取ることを意味します。

エンドポイントの呼び出しは、一般的な SageMaker 構造に似ています invoke_endpoint; データをペイロードとしてエンドポイントを直接呼び出すことができます。

sm_runtime.invoke_endpoint(
	EndpointName=endpoint_name,
	ContentType="text/csv",
	Body=payload
	)

SageMaker は次のようなメトリクスを発行します Latency および Invocations CloudWatch のバリアントごと。 SageMaker が発行するメトリクスの完全なリストについては、以下を参照してください。 Amazon CloudWatchでAmazon SageMakerを監視する. CloudWatch にクエリを実行してバリアントごとの呼び出し数を取得し、呼び出しがデフォルトでバリアント間でどのように分割されているかを確認できます。

モデルの特定のバージョンを呼び出すには、バリアントを TargetVariant への呼び出しで invoke_endpoint:

sm_runtime.invoke_endpoint(
	EndpointName=endpoint_name,
	ContentType="text/csv",
	Body=payload,
	TargetVariant="Variant1"
	)

を使用して、各バリアントの精度、適合率、再現率、F1 スコア、レシーバー動作特性/曲線下面積などの指標を確認することで、各プロダクション バリアントのパフォーマンスを評価できます。 Amazon SageMakerモデルモニター. 次に、次を呼び出して各バリアントに割り当てられた重みを更新することにより、最適なモデルへのトラフィックを増やすことを決定できます。 エンドポイントの重みと容量を更新する. これにより、エンドポイントの更新を必要とせずに、トラフィックの分散が本番バリアントに変更されます。 そのため、初期セットアップからのトラフィックの 50% ではなく、トラフィックの 75% を Variant2 を使用して各バリアントに新しい重みを割り当てることによって UpdateEndpointWeightsAndCapacities。 次のコードを参照してください。

sm.update_endpoint_weights_and_capacities(
	EndpointName=endpoint_name,
	DesiredWeightsAndCapacities=[
	{
		"DesiredWeight": 25,
		"VariantName": variant1["VariantName"]
	},
	{
		"DesiredWeight": 75,
		"VariantName": variant2["VariantName"]
	}
] )

バリアントのパフォーマンスに満足したら、トラフィックの 100% をそのバリアントにルーティングできます。 たとえば、次の重みを設定できます。 Variant1 を 0 にして重みを Variant2 1. 次に、SageMaker はすべての推論リクエストの 100% を Variant2. その後、エンドポイントを安全に更新して削除できます Variant1 エンドポイントから。 エンドポイントに新しいバリアントを追加することで、本番環境で新しいモデルのテストを続けることもできます。 これらのエンドポイントが受信するトラフィックに基づいて自動的にスケーリングするようにこれらのエンドポイントを構成することもできます。

マルチバリアント エンドポイントの利点

SageMaker MVE を使用すると、次のことができます。

• 同じ SageMaker エンドポイントを使用して、モデルの複数のバリアントをデプロイしてテストします。 これは、本番環境でモデルのバリエーションをテストする場合に役立ちます。 たとえば、モデルを本番環境にデプロイしたとします。 少量のトラフィック (たとえば 5%) を新しいモデルに転送することで、モデルのバリエーションをテストできます。
• CloudWatch で各バリアントの運用メトリクスを監視することにより、トラフィックを中断することなく、本番環境でモデルのパフォーマンスを評価します。
• 可用性を失うことなく、本番環境でモデルを更新します。 すでに本番環境にデプロイされているモデルをサービス停止にすることなく、エンドポイントを変更できます。 たとえば、新しいモデル バリアントを追加したり、既存のモデル バリアントの ML コンピューティング インスタンス構成を更新したり、モデル バリアント間のトラフィックの分散を変更したりできます。 詳細については、次を参照してください。 エンドポイントの更新 および エンドポイントの重みと容量を更新する.

マルチバリアント エンドポイントを使用する場合の課題

SageMaker MVE には次の課題があります。

• 負荷テストの労力 – 各バリアントのテストとモデル マトリックスの比較には、かなりの労力とリソースを投入する必要があります。 A/B テストが成功したと見なされるには、テストから収集されたメトリックの統計分析を実行して、統計的に有意な結果があるかどうかを判断する必要があります。 パフォーマンスの低いバリアントの探索を最小限に抑えることは困難になる可能性があります。 あなたは潜在的に使用することができます 多腕の盗賊 最適化手法を使用して、機能していない実験にトラフィックが送信されるのを回避し、テスト時にパフォーマンスを最適化します。 負荷テストの場合は、探索することもできます AmazonSageMaker推論レコメンダー レイテンシーとスループット、カスタム トラフィック パターン、および選択したインスタンス (最大 10) の本番環境要件に基づいて、広範なベンチマークを実施します。
• モデル バリアントとエンドポイント間の密結合 – モデルの展開頻度によっては、エンドポイントが最終的に updating 更新中の各生産バリアントのステータス。 SageMaker もサポート 展開のガードレールを使用して、生産中の現在のモデルから制御された方法で新しいモデルに簡単に切り替えることができます。 このオプションは カナリア および 線形 更新中に現在のモデルから新しいモデルへのトラフィックの移行をきめ細かく制御できるようにするトラフィック移行モード。 自動ロールバックなどの組み込みの保護機能により、問題を早期に発見し、本番環境に重大な影響を与える前に自動的に修正措置を講じることができます。

マルチバリアント エンドポイントのベスト プラクティス

SageMaker MVE を使用してモデルをホストする場合は、次の点を考慮してください。

• SageMaker は、新しいモデルを A/B テスト環境に簡単にデプロイでき、使用した分だけ料金が発生するため、新しいモデルのテストに最適です。 エンドポイントの実行中に各インスタンスで消費されたインスタンス時間ごとに課金されます。 テストが完了し、エンドポイントまたはバリアントを広範に使用しなくなったら、コストを節約するために削除する必要があります。 モデルは Amazon シンプル ストレージ サービス （Amazon S3）。
• モデルをデプロイするには、最適なインスタンス タイプとサイズを使用する必要があります。 SageMaker は現在提供しています MLコンピューティングインスタンス さまざまなインスタンスファミリーで。 エンドポイント インスタンスは常に実行されています (インスタンスが稼働している間)。 したがって、適切なタイプのインスタンスを選択すると、ML モデルの総コストとパフォーマンスに大きな影響を与える可能性があります。 負荷テスト ライブ エンドポイントの自動スケーリングの有無にかかわらず、適切なインスタンス タイプとフリート サイズを決定するベスト プラクティスです。過剰なプロビジョニングや不要なキャパシティーへの追加料金の支払いを避けるためです。
• CloudWatch でモデルのパフォーマンスとリソースの使用率をモニタリングできます。 構成できます ProductionVariant 使用する アプリケーションの自動スケーリング. スケーリング ポリシーのメトリックとターゲット値を指定するには、ターゲット追跡スケーリング ポリシーを構成します。 定義済みのメトリックまたはカスタム メトリックのいずれかを使用できます。 ポリシー構成の構文の詳細については、次を参照してください。 ターゲット追跡スケーリングポリシー構成. 自動スケーリングの構成については、を参照してください。 Amazon SageMakerモデルを自動的にスケーリングする. バリアントのターゲット追跡スケーリング ポリシーをすばやく定義するために、特定の CloudWatch メトリクスを選択し、しきい値を設定できます。 たとえば、メトリックを使用します SageMakerVariantInvocationsPerInstance バリアントの各インスタンスが呼び出される XNUMX 分あたりの平均回数を監視するか、メトリクスを使用する CPUUtilization CPU によって処理される作業の合計を監視します。 次の例では、 SageMakerVariantInvocationsPerInstance 各インスタンスが InvocationsPerInstance メトリック 70:

{
	"TargetValue": 70.0,
	"PredefinedMetricSpecification":
	{
		"PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
	}
}

• モデルのデプロイ後にモデル アーティファクトを変更または削除したり、推論コードを変更したりすると、予測できない結果が生じます。 モデルを本番環境にデプロイする前に、推論コード スニペット ( model_fn, input_fn, predict_fn, output_fn) SageMaker ノートブック インスタンスやローカル サーバーなどのローカル開発環境。 モデル アーティファクトを変更または削除するか、推論コードを変更する必要がある場合は、新しいエンドポイント構成を提供してエンドポイントを変更します。 新しいエンドポイント構成を提供した後、古いエンドポイント構成に対応するモデル アーティファクトを変更または削除できます。
• SageMaker を使用できます バッチ変換 生産バリアントをテストします。 バッチ変換は、大規模なデータセットから推論を得るのに理想的です。 新しいモデル バリアントごとに個別の変換ジョブを作成し、検証データセットを使用してテストできます。 変換ジョブごとに、一意のモデル名と出力ファイルの Amazon S3 内の場所を指定します。 結果を分析するには、次を使用します。 推論パイプラインのログとメトリクス.

まとめ

SageMaker を使用すると、エンドポイントで複数の本番バリアントを実行することにより、本番環境で ML モデルを簡単に A/B テストできます。 SageMaker の機能を使用して、さまざまなトレーニング データセット、ハイパーパラメータ、アルゴリズム、または ML フレームワークを使用してトレーニングされたモデルをテストできます。 さまざまなインスタンス タイプでどのように機能するか。 または上記のすべての組み合わせ。 エンドポイントのバリアント間のトラフィック分散を提供できます。SageMaker は、指定された分散に基づいて推論トラフィックをバリアントに分割します。 または、特定の顧客セグメントのモデルをテストする場合は、推論リクエストを処理するバリアントを指定できます。 TargetVariant ヘッダー、および SageMaker は、指定したバリアントにリクエストをルーティングします。 A/B テストの詳細については、次を参照してください。 本番環境でモデルを安全に更新.

参考文献

著者について

ディーパリ・ラジャレ アマゾン ウェブ サービスの AI/ML スペシャリスト テクニカル アカウント マネージャーです。 彼女は企業のお客様と協力して、ベスト プラクティスを使用した機械学習ソリューションの実装に関する技術的なガイダンスを提供しています。 余暇には、ハイキング、映画、家族や友人との付き合いを楽しんでいます。

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

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