アマゾンセージメーカー マルチモデル エンドポイント (MME) を使用すると、単一のエンドポイントで複数のモデルを費用対効果の高い方法でデプロイおよびホストし、エンドポイントを水平方向にスケーリングしてスケーリングを実現できます。 次の図に示すように、これは、機械学習 (ML) インフラストラクチャ内にモデルのマルチテナンシーを実装するための効果的な手法です。 私たちは、Software as a Service (SaaS) ビジネスがこの機能を使用して、ML モデルにハイパーパーソナライゼーションを適用しながら、コストを削減するのを見てきました。
MME の仕組みの概要については、AWS Summit ビデオをご覧ください。 ML を次のレベルにスケーリング: SageMaker で数千のモデルをホスト. MME が可能にする高度にパーソナライズされたマルチテナントのユース ケースの詳細については、次を参照してください。 マルチテナントSaaSユースケースの機械学習推論をスケーリングする方法.
この投稿の残りの部分では、SageMaker MME の技術アーキテクチャを深く掘り下げ、マルチモデル エンドポイントを最適化するためのベスト プラクティスを共有します。
MMEに最適なユースケース
SageMaker マルチモデル エンドポイントは、共有サービング コンテナを介して提供できる多数のモデルをホストするのに適しています。同時にすべてのモデルにアクセスする必要はありません。 エンドポイント インスタンス メモリのサイズによっては、新しいモデルをロードしてメモリの効率的な使用を最大化するために、モデルがメモリからアンロードされることがあります。したがって、アプリケーションは、アンロードされたモデルで時折発生するレイテンシ スパイクを許容する必要があります。
MME は、共有コンテナーを使用して複数のモデルをロードするため、同じ ML フレームワークを使用する共同ホスティング モデル用にも設計されています。 したがって、モデル フリートに ML フレームワーク (PyTorch や TensorFlow など) が混在している場合は、SageMaker 専用エンドポイントまたはマルチコンテナ ホスティングを選択することをお勧めします。
最後に、MME は、モデルが最初の呼び出しで読み込まれ、頻繁に使用されないモデルをメモリからオフロードして新しいモデルを読み込むことができるため、時折のコールド スタート レイテンシ ペナルティを許容できるアプリケーションに適しています。 したがって、頻繁にアクセスされるモデルとあまりアクセスされないモデルが混在している場合、マルチモデル エンドポイントは、より少ないリソースとより高いコスト削減で、このトラフィックを効率的に処理できます。
また、お客様がすべてのモデルに適合するのに十分な総メモリ容量を備えた MME クラスターを展開し、それによってモデルのオフロードを完全に回避しながら、共有された推論インフラストラクチャによりコスト削減を実現するシナリオもいくつか見てきました。
モデル サービング コンテナ
SageMaker Inference Toolkit、または MME と互換性のあるコンテナを提供する事前構築済みの SageMaker モデルを使用する場合、コンテナには マルチモデルサーバー (JVM プロセス) が実行されています。 マルチ モデル サーバー (MMS) をモデル サービス コンテナーに組み込む最も簡単な方法は、次を使用することです。 コンテナを提供する SageMaker モデル MME と互換性があります (Job Type=inference および CPU/GPU=CPU のものを探します)。 MMS は、ディープ ラーニング モデルを提供するためのオープン ソースの使いやすいツールです。 単一のホストで複数のモデルを提供および管理するための Web サーバーを備えた REST API を提供します。 ただし、MMS の使用は必須ではありません。 を実装している限り、独自のモデル サーバーを実装できます。 MME に必要な API.
MME プラットフォームの一部として使用される場合、MMS または独自のモデル サーバーへのすべての予測、ロード、およびアンロード API 呼び出しは、MME データ プレーン コントローラーを介してチャネル化されます。 データ プレーン コントローラーからの API 呼び出しは、インスタンスの外部からの不正アクセスを防ぐために、ローカル ホストのみで行われます。 MMS の主な利点の XNUMX つは、モデルをロード、アンロード、および呼び出すための標準化されたインターフェイスを有効にし、幅広いディープ ラーニング フレームワークと互換性があることです。
MMS の高度な設定
モデル サービスに MMS を使用する場合は、次の高度な構成を検討して、MME インスタンスのスケーラビリティとスループットを最適化してください。
モデルごとの推論の並列処理を増やす
MMS は、モデルごとに XNUMX つ以上の Python ワーカー プロセスを作成します。 モデルごとのデフォルトの労働者 設定パラメータ。 これらの Python ワーカーは、提供された前処理、予測、および後処理関数を実行することによって、個々の推論要求を処理します。 詳細については、 カスタム サービス ハンドラ GitHubレポ。
複数のモデル ワーカーを使用すると、特定のモデルで処理できる予測の並列性が向上します。 ただし、多数のモデルが多数の CPU を持つインスタンスでホストされている場合は、MME の負荷テストを実行して、最適な値を見つける必要があります。 default_workers_per_model メモリまたは CPU リソースの枯渇を防ぐため。
トラフィック スパイクの設計
エンドポイント インスタンス内の各 MMS プロセスには、 ジョブキューのサイズ パラメータ (デフォルトは 100)。 これにより、すべてのワーカー プロセスがビジー状態のときに MMS がキューに入れる要求の数が決まります。 モデルごとの最適なワーカー数を決定した後、このパラメーターを使用してエンドポイント インスタンスの応答性を微調整します。
モデルあたりの最適なワーカーの比率では、ほとんどの場合、デフォルトの 100 で十分です。 ただし、エンドポイントへのリクエスト トラフィックが異常に急増する場合、エンドポイントがアプリケーションに制御を渡すのを早く失敗させたい場合はキューのサイズを小さくするか、エンドポイントにスパイクを吸収させたい場合はキューのサイズを大きくすることができます。 .
インスタンスあたりのメモリ リソースを最大化する
モデルごとに複数のワーカー プロセスを使用する場合、既定では、各ワーカー プロセスはモデルの独自のコピーを読み込みます。 これにより、他のモデルで使用可能なインスタンス メモリが減少する可能性があります。 構成パラメーターを設定してワーカー プロセス間で単一のモデルを共有することにより、メモリ使用率を最適化できます。 preload_model=true. ここでは、メモリ効率の向上と (モデル インスタンスが XNUMX つであるため) 推論の並列処理の削減をトレードオフしています。 この設定と複数のワーカー プロセスは、モデルのレイテンシは低いが、推論リクエストごとの前処理と後処理 (ワーカー プロセスによって実行される) が多いユース ケースに適しています。
MMS の詳細設定の値を設定する
MMS は config.properties ファイルを使用して構成を保存します。 MMS は、次の順序でこの config.properties ファイルを見つけます。
- Status
MMS_CONFIG_FILE環境変数が設定されると、MMS は環境変数から構成をロードします。 - Status
--mms-configパラメーターが MMS に渡されると、パラメーターから構成が読み込まれます。 - ある場合は
config.propertiesユーザーが MMS を起動した現在のフォルダーに、config.properties現在の作業ディレクトリからのファイル。
上記のいずれも指定されていない場合、MMS は組み込みの構成を既定値で読み込みます。
以下は、明示的な構成ファイルを使用して MMS を開始するコマンド ラインの例です。
エンドポイントのパフォーマンスを監視するための主要な指標
MME の最適化に役立つ主要な指標は、通常、CPU とメモリの使用率、および推論のレイテンシに関連しています。 インスタンス レベルのメトリックは MMS によって発行されますが、レイテンシ メトリックは MME から取得されます。 このセクションでは、MME を理解して最適化するために使用できる一般的なメトリックについて説明します。
エンドポイント インスタンス レベルの指標 (MMS 指標)
ノーザンダイバー社の MMS メトリックのリスト、CPUUtilization および MemoryUtilization は、インスタンスまたは MME クラスターのサイズが適切かどうかを評価するのに役立ちます。 両方の指標のパーセンテージが 50 ～ 80% の場合、MME は適切なサイズです。
通常、CPUUtilization が低く、MemoryUtilization が高い場合は、MME クラスターが過剰にプロビジョニングされていることを示しています。これは、呼び出される頻度が低いモデルがアンロードされていないことを示しているためです。 これは、MME 用にプロビジョニングされたエンドポイント インスタンスの数が最適よりも多いためである可能性があり、そのため、アクセス頻度の低いモデルがメモリ内に残るために、最適よりも多い集約メモリが利用可能です。 逆に、これらのメトリクスの使用率が 100% に近い場合は、クラスターが十分にプロビジョニングされていないことを意味するため、クラスターの自動スケーリング ポリシーを調整する必要があります。
プラットフォーム レベルのメトリック (MME メトリック)
ノーザンダイバー社の MME メトリックの完全なリスト、推論リクエストのレイテンシーを理解するのに役立つ重要な指標は ModelCacheHit です。 このメトリックは、モデルがすでにメモリーにロードされている呼び出しリクエストの平均比率を示します。 この比率が低い場合は、MME クラスターのプロビジョニングが不十分であることを示しています。これは、一意のモデル呼び出しの数に対して MME クラスターに十分な総メモリ容量がない可能性があり、モデルが頻繁にメモリからアンロードされる原因となっているためです。
現場からの教訓と MME を最適化するための戦略
多数のお客様による MME の大規模な使用の一部から、次の推奨事項を確認しました。
小さいインスタンスでの水平方向のスケーリングは、大きいインスタンスでの垂直方向のスケーリングよりも優れています
少数のエンドポイント インスタンスで高い XNUMX 秒あたりの要求 (RPS) を実行すると、モデルの呼び出しが抑制される場合があります。 XNUMX 秒あたりの呼び出し (インスタンスで同時に発生する可能性のあるロードとアンロード) の数には内部的な制限があるため、小さいインスタンスの数を多くすることを常にお勧めします。 小さいインスタンスをより多く実行すると、エンドポイントのこれらの制限の合計容量が大きくなります。
小さいインスタンスで水平方向にスケーリングするもう XNUMX つの利点は、MMS を実行する際に並列処理のレベルが高く、メモリ内のモデルの数が多い場合に、インスタンスの CPU とメモリ リソースを使い果たすリスクを軽減できることです (この投稿で前述したように)。
スラッシングを避けることは共同責任です
スラッシング MME では、個々のインスタンスまたはクラスター内の集合体で、メモリ不足のためにモデルが頻繁にメモリからアンロードされ、再ロードされる場合があります。
使用状況の観点からは、個々のエンドポイント インスタンスのサイズを適切に調整し、MME クラスターの全体的なサイズを適切に調整して、インスタンスごとに十分なメモリ容量を確保し、ユース ケースのクラスターの合計でも十分なメモリ容量を確保する必要があります。 MME プラットフォームのルーター フリートも、キャッシュ ヒットを最大化します。
より少ない、より大きなメモリ インスタンスにあまりにも多くのモデルをビン パッキングすることに積極的にならないでください。
インスタンスで認識すべきリソースはメモリだけではありません。 次の負荷テストの結果に見られるように、CPU などの他のリソースが制約要因になる可能性があります。 他のいくつかのケースでは、あまりにも多くのモデルがロードされ、基礎となる ML フレームワーク (TensorFlow など) がモデルごとに利用可能な倍数のスレッドを生成することの組み合わせにより、プロセス ID などの他のカーネル リソースがインスタンスで使い果たされることも確認されています。 vCPU。
次のパフォーマンス テストは、モデルのレイテンシに影響を与える CPU 制約の例を示しています。 このテストでは、大きなインスタンスを持つ単一のインスタンス エンドポイントは、XNUMX つのモデルすべてをメモリに保持するのに十分なメモリを持っていますが、XNUMX つの小さなインスタンスを持つエンドポイントと比較すると、負荷がかかった状態でのモデルのレイテンシが比較的悪化しました。
単一インスタンス エンドポイント モデルのレイテンシ
単一インスタンス エンドポイントの CPU とメモリの使用率
XNUMX インスタンス エンドポイント モデルのレイテンシ
XNUMX つのインスタンスのエンドポイントの CPU とメモリの使用率
パフォーマンスとコスト効率の両方を実現するには、MME クラスターのサイズを適切に調整し、多数の小さなインスタンスを使用します。これにより、全体として最適なメモリと CPU 容量が得られ、メモリ インスタンスは少なくても大きいため、コストは比較的同等になります。
MMEを最適化するためのメンタルモデル
MME のサイズを適切に設定する際に常に考慮すべき XNUMX つの重要な指標があります。
- モデルの数とサイズ
- 特定の時間に呼び出される一意のモデルの数
- インスタンスのタイプとサイズ
- エンドポイントの背後にあるインスタンス数
最初の XNUMX つのポイントから始めます。これは、XNUMX 番目と XNUMX 番目のポイントに影響を与えるからです。 たとえば、独自のモデルの数またはサイズに対してエンドポイントの背後に十分なインスタンスがない場合、エンドポイントの総メモリが少なくなり、エンドポイント レベルでのキャッシュ ヒット率とスラッシングが低下します。メモリ内外でモデルを頻繁にロードおよびアンロードします。
同様に、一意のモデルの呼び出しが、エンドポイントの背後にあるすべてのインスタンスの総メモリよりも多い場合、キャッシュ ヒットは低くなります。 これは、インスタンスのサイズ (特にメモリ容量) が小さすぎる場合にも発生する可能性があります。
モデルがメモリに収まる場合でも、CPU やカーネル プロセス、スレッド制限などの他のリソースが使い果たされる可能性があるため、非常に大きなメモリ インスタンスで垂直方向にスケーリングすると、問題が発生する可能性があります。 MME に最適なインスタンスの数とサイズを取得するために、本番前の水平スケーリングの負荷テストを行います。
まとめ
この投稿では、MME プラットフォームの理解を深めました。 MME が適している技術的なユース ケースを学び、MME プラットフォームのアーキテクチャを確認しました。 MME アーキテクチャ内の各コンポーネントの役割と、どのコンポーネントのパフォーマンスに直接影響を与えることができるかについて、より深く理解できました。 最後に、ユース ケースに合わせて MME を最適化するために調整できる構成パラメーターと、最適なパフォーマンスを維持するために監視する必要があるメトリックについて詳しく説明しました。
MME の使用を開始するには、以下を確認してください。 XGBoost を使用した Amazon SageMaker マルチモデル エンドポイント & XNUMXつのエンドポイントの背後にあるXNUMXつのコンテナで複数のモデルをホストする.
著者について
サイードジャフリー AWS のプリンシパル ソリューション アーキテクトです。 彼は、中規模の組織、大企業、金融サービス、ISV などのさまざまな企業と協力して、コスト効率が高くスケーラブルな AI/ML アプリケーションをクラウドで構築および運用できるよう支援しています。
サウラブ・トリカンデ Amazon SageMaker Inference のシニア プロダクト マネージャーです。 彼は顧客と協力することに情熱を傾けており、機械学習を民主化するという目標に動機付けられています。 彼は、複雑な ML アプリケーションのデプロイ、マルチテナント ML モデル、コストの最適化、およびディープ ラーニング モデルのデプロイをよりアクセスしやすくすることに関連する主要な課題に焦点を当てています。 余暇には、Saurabh はハイキングを楽しんだり、革新的なテクノロジーについて学んだり、TechCrunch をフォローしたり、家族と過ごしたりしています。
