Amazon SageMaker のマルチフレームワーク モデルによるコスト効率の高い ML 推論 

機械学習 (ML) は、幅広い業界に影響を与え、毎日何十億人ものユーザーに影響を与える、最も成功し、普及しているテクノロジのアプリケーションの XNUMX つであることが証明されています。 あらゆる業界に ML が急速に導入される中、企業は、リソースの使用率を最大化し、関連するコストを削減しながら、低レイテンシの予測と高可用性をサポートするという課題に直面しています。 各 ML フレームワークには独自の依存関係があり、各フレームワークのデプロイ手順が異なるため、本番環境で異なるフレームワークに構築されたモデルをデプロイし、各エンドポイントを管理することはますます複雑になります。

アマゾンセージメーカー マルチコンテナ エンドポイント (MCE) を使用すると、異なるフレームワークでモデルをグループ化し、それらを同じホストにデプロイして、単一のエンドポイントを作成できます。 モデルの構築に使用しているさまざまなフレームワークにコンテナーを提供できます。SageMaker はこれらのコンテナーをすべて取得し、XNUMX つのエンドポイントの背後に配置します。 たとえば、PyTorch と TensorFlow モデルを、同じまたはまったく異なるユース ケースに対応する XNUMX つの専用エンドポイントにロードすることができます。これらのモデルの両方で、リソースを限界まで利用していない断続的な着信トラフィックがあります。 このようなシナリオでは、コンテナーを使用して、MCE を使用してそれらを XNUMX つのエンドポイントにまとめることができます。これにより、リソースの使用率が向上すると同時に、両方のモデルが異なるエンドポイントからサービスを提供することで発生するコストが削減されます。

マルチコンテナ エンドポイントは、さまざまな ML フレームワーク、モデル サーバー、および同じまたは異なるユース ケースに対応するアルゴリズム上に構築された最大 15 個のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションを提供します。これらのコンテナとモデルのすべてにまたがります。 これらのモデルはすべて、直接呼び出しによって個別にアクセスすることも、シリアル呼び出しを使用してパイプラインにステッチすることもできます。この場合、XNUMX つのモデルの出力が次のモデルの入力になります。

この投稿では、SageMaker でマルチフレームワーク モデルを使用してコスト効率の高い ML 推論を実行する方法について説明します。

MCE 呼び出しパターン

SageMaker MCE の直接呼び出しは、関連のないモデルを MCE エンドポイントに組み込んでいる場合や、MCE エンドポイントの背後にあるモデル間で A/B テストを実行してパフォーマンスを測定している場合に役立ちます。 API 呼び出しで特定のコンテナーを直接呼び出して、そのモデルから予測を取得できます。

シリアル呼び出しを使用すると、2 ～ 15 個のコンテナーをつなぎ合わせることができ、XNUMX つの出力が順番に次のコンテナーの入力になります。 これは、たとえば、中間予測に Scikit-learn モデルが使用され、最終的な推論のために結果が TensorFlow モデルに供給される複数ステップの予測パイプラインがある場合に理想的なユース ケースです。 それらを異なるエンドポイントとしてデプロイし、別のアプリケーションまたはジョブでオーケストレーションして複数の API 呼び出しを行う代わりに、それらを SageMaker MCE としてデプロイし、ロジックを抽象化し、SageMaker が XNUMX つのコンテナ間のデータ転送を管理するシリアル呼び出し用にセットアップできます。自動的に別のコンテナーに変換し、最終的なコンテナーの出力を、API 要求を行っているクライアントに送信します。

SageMaker MCE シリアル呼び出しは、SageMaker シリアル推論パイプラインとは根本的に異なります (詳細は以下のセクションで説明します)。 シリアル推論パイプラインは、データの前処理、モデル アンサンブルの構築、呼び出すモデルを決定するための条件付きチェックの実装、予測の後処理などの複雑な ML ワークフローを調整することをより目的としており、予測がダウンストリーム アプリケーションに送信される前にビジネス ロジックが関与します。 . 対照的に、MCE シリアル呼び出しは、2 ～ 14 個のモデルを推論用のパイプラインにステッチするように設計されており、各モデルは前のモデルの予測を入力として受け取ります。

MCE 内のすべてのコンテナは常にサービス中であり、メモリ内にあるため、エンドポイントの呼び出し中にコールド スタートは発生しません。 また、各モデルが個々のコンピューティング リソースを占有するのではなく、モデルが XNUMX つのエンドポイントの背後にデプロイされ、基盤となるコンピューティング インスタンスを共有するため、MCE はエンドポイントの使用率とコストを改善します。

いくつかのユースケースを見て、SageMaker MCE を使用して ML 推論を最適化する方法を見てみましょう。

SageMaker MCE のユースケース

感情分類に 24 つのモデルがあり、7 つは英語用、もう XNUMX つはドイツ語用であり、これらのモデルは XNUMX 日のさまざまな時間にトラフィックが入ってくるさまざまな地域にサービスを提供しているとします。 XNUMX つのエンドポイントを XNUMX 時間年中無休で実行する代わりに、MCE を使用して両方を XNUMX つのエンドポイントにデプロイし、直接呼び出しを使用してそれらにアクセスできるため、リソースの使用率とコストを最適化できます。 次のコードを参照してください。

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

この例では、XNUMX つのモデルがあります (englishModel および germanModel)、SageMaker でコンテナを定義します create_model を構築して定義する InferenceExecutionConfig 「直接」として。 これで、推論のためにエンドポイントを呼び出して、 TargetContainerHostname どちらかとして englishModel or germanModel API 呼び出しを行うクライアントに応じて:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

MCE 内で直接呼び出しを使用して A/B テストを実行し、モデル間のパフォーマンスを比較することもできます。

次の図は、アーキテクチャを示しています。

同様に、他の ML ユース ケースでは、トレーニング済みのモデルがリクエストの処理に使用される場合、モデルは推論のためにアルゴリズムに渡す前に、前処理 (特徴付けなど) が必要な形式でデータを受け取ります。 ML アルゴリズムが連鎖している場合、最終結果に到達する前に、XNUMX つのモデルの出力が次のモデルの入力として機能します。 この場合、SageMaker MCE シリアル パイプラインを構築できます。このパイプラインでは、コンテナは、 create_model 各モデルを異なるエンドポイントにデプロイし、独立したロジックを記述して、これらすべてのモデルと API 呼び出しの間のデータの流れを促進する代わりに、構築します。 次の図は、このアーキテクチャを示しています。

このユース ケースでは、次のコードを使用します。

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

この例では、XNUMX つの処理コンテナーがあります (Processing-1 および Processing-2) 特徴処理とデータ変換用、および XNUMX つの推論コンテナー (Inference-1 および Inference-2) を使用して、前処理されたデータに対して ML モデル予測を実行します。 の PipelineModel インスタンスを使用すると、データに対する推論のリクエストを処理する XNUMX つのコンテナーの線形シーケンスで構成される推論パイプラインを定義できます。 コンテナーは同じインスタンスに配置されているため、低レイテンシーで推論を実行できます。

多数のモデルのマルチモデル エンドポイントをスケーリングする

SageMaker マルチモデル エンドポイントの利点は、モデル統合の規模に応じて増加します。 XNUMX つのエンドポイントで XNUMX つのモデルをホストする場合のコスト削減を確認できます。また、数百または数千のモデルを使用するユース ケースの場合、削減額ははるかに大きくなります。

MCE エンドポイントのスケーリングも、 SageMakerVariantInvocationsPerInstance モデルエンドポイントの各インスタンスが呼び出されて定義された XNUMX 分あたりの平均回数を示します TargetScaling ポリシー。 SageMaker は、ワークロードの変化に応じて、モデル用にプロビジョニングされたインスタンスの数を動的に調整します。 ワークロードが増加すると、自動スケーリングにより、より多くのインスタンスがオンラインになり、ターゲット モデルとコンテナーがロードされて、リクエストの処理が継続されます。 ワークロードが減少すると、自動スケーリングによって不要なインスタンスが削除され、モデル コンテナーがオフロードされるため、コンテナーがリソースを使い果たしてしまうことがなく、使用していないインスタンスに対して料金が発生することはありません。 特定のモデルに対する最初のリクエストを完了するまでに、モデルをダウンロードするための追加のレイテンシ (コールド スタートと呼ばれます) が発生します。 Amazon シンプル ストレージ サービス (Amazon S3) をメモリにロードします。 モデルは既に読み込まれているため、後続の呼び出しは追加のオーバーヘッドなしで終了します。 次のコードを参照してください。

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

前のポリシー構成の例に続いて、 SageMakerVariantInvocationsPerInstance 各インスタンスが InvocationsPerInstance 70のメトリック。

次のような独自のカスタムメトリクスに基づいて SageMaker MCE をスケーリングすることもできます。 CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationまたは DiskUtilization、特定のリソースの使用率に基づいてインスタンスの数をスケールアップまたはスケールダウンします。 詳細については、次を参照してください。 Amazon SageMakerモデルを自動的にスケーリングする.

MCE へのトラフィックが CPU 使用率の高いモデルから CPU 使用率の低いモデルに移行しても、全体的な呼び出し量が同じままである場合、エンドポイントははスケールアウトされず、CPU 使用率の高いモデルへのすべての要求を処理するのに十分なインスタンスがない可能性があります。

セキュア MCE

直接呼び出しを使用する MCE の場合、メモリとストレージ ボリュームを共有することにより、複数のコンテナーが XNUMX つのインスタンスでホストされます。 コンテナーを保護し、ターゲット コンテナーへの要求の正しいマッピングを維持し、ユーザーにターゲット コンテナーへの正しいアクセスを提供することが重要です。 制限できます invoke_endpoint を使用して、MCE 内の限られた一連のコンテナーにアクセスする sagemaker:TargetContainerHostname AWS IDおよびアクセス管理 (IAM) 条件キー。 SageMaker が使用する IAMの役割 許可または拒否されるアクションとリソース、およびアクションが許可または拒否される条件を指定するために使用する IAM アイデンティティベースのポリシーを提供します。 次のポリシーは、エンドポイント内の特定のコンテナーへの呼び出しを制限する方法を示しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Amazon CloudWatch メトリクスを使用してマルチモデル エンドポイントを監視する

価格とパフォーマンスのトレードオフを行うには、独自のアプリケーションからのモデルと代表的なトラフィックを使用してマルチモデル エンドポイントをテストする必要があります。 SageMaker は追加のメトリクスを提供します アマゾンクラウドウォッチ マルチモデル エンドポイントの場合、エンドポイントの使用状況とキャッシュ ヒット率を判断し、エンドポイントを最適化できます。 メトリックは次のとおりです。

• モデル読み込み待機時間 – 推論を実行するためにターゲット モデルがダウンロードまたはロードされるのを呼び出しリクエストが待機する時間間隔。
• モデルのアンロード時間 – コンテナからモデルをアンロードするのにかかる時間間隔 UnloadModel API呼び出し。
• モデルのダウンロード時間 – Amazon S3 からモデルをダウンロードするのにかかる時間間隔。
• モデル読み込み時間 – コンテナを通じてモデルをロードするのにかかる時間間隔 LoadModel API呼び出し。
• モデルキャッシュヒット –の数 InvokeEndpoint モデルがすでにロードされているエンドポイントに送信されたリクエスト。 取る Average 統計は、モデルがすでに読み込まれているリクエストの比率を示します。
• ロード済みモデル数 – エンドポイントのコンテナーにロードされたモデルの数。 このメトリクスはインスタンスごとに発行されます。 の Average 1 分間の統計は、インスタンスごとに読み込まれたモデルの平均数を示します。 Sum statistic は、エンドポイントのすべてのインスタンスにロードされたモデルの総数を示します。 エンドポイントの複数のコンテナーにモデルを読み込むことができるため、このメトリックが追跡するモデルは必ずしも一意ではありません。

インスタンスで実行されている各コンテナで使用されるその他のメトリックもいくつかあります。 Invocations の数を示す InvokeEndpoint エンドポイント内のコンテナに送信されたリクエスト ContainerLatency SageMaker から見た、エンドポイントがターゲットコンテナまたはシリアル呼び出しのすべてのコンテナに応答するのにかかった時間を与える。 CPUUtilization および MemoryUtilizaton CPU ユニットとメモリの割合を示します。

まとめ

この投稿では、SageMaker マルチコンテナエンドポイントがコストとリソース使用率の最適化にどのように役立つかについて説明しました。 MCE を使用する場合の例には、次のようなものがありますが、これらに限定されません。

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

SageMaker MCE は、リアルタイム エンドポイントに最大 15 個のコンテナをデプロイし、低レイテンシの推論とコスト削減のためにそれらを個別に呼び出すことをサポートします。 モデルは、独自の独立したサービング スタックを使用して、完全に異種混合にすることができます。 これらのコンテナーは、要求ごとに順次または個別に呼び出すことができます。 異なるフレームワークからの複数のモデルを 90 つのインスタンスで安全にホストすると、専用の単一インスタンス エンドポイントでモデルをホストする場合と比較して、コストを最大 XNUMX% 節約できます。

著者について

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

ヴィクラムエランゴ は、米国バージニア州を拠点とするアマゾン ウェブ サービスのシニア AI/ML スペシャリスト ソリューション アーキテクトです。 Vikram は、機械学習アプリケーションを大規模に構築および展開するための設計およびソート リーダーシップを提供して、グローバルな金融および保険業界の顧客を支援します。 彼は現在、自然言語処理、責任ある AI、推論の最適化、企業全体での ML のスケーリングに注力しています。 余暇には、旅行、ハイキング、料理、家族とのキャンプを楽しんでいます。

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