「Amazon SageMakerを使用して数百のモデルにスケールされたファウンデーションモデルの推論 – パート1」

「Amazon SageMakerを活用した数百のモデルにスケールされたファンデーションモデルの推論 - パート1」

ファンデーションモデル（FMs）の民主化が進み、AIを活用したサービスへの需要が高まるにつれ、ソフトウェアとしてのサービス（SaaS）プロバイダーは、組織内のデータサイエンティストや外部の顧客向けのマルチテナントをサポートする機械学習（ML）プラットフォームの利用を模索しています。多くの企業が、顧客に対して高度に個別化された効果的なコンテンツを生成するために、FMsを使用する価値を認識してきています。自社のデータでFMsを微調整することは、特定のユースケースにおけるモデルの精度を大幅に向上させることができます。たとえば、ページ訪問コンテキストを使用した営業メールの生成、企業のサービスに合わせた検索回答の生成、または過去の会話のトレーニングによる顧客サポートの自動化などです。

ジェネラティブAIモデルホスティングをサービスとして提供することで、どの組織でも社内のAIの専門知識を必要とせずに、費用効果の高い方法でFMsを大規模に統合し、パイロットテストし、デプロイすることができます。これにより、企業はハイパーカスタマイズされた営業やマーケティングコンテンツ、インテリジェントな検索、カスタマイズされた顧客サービスのワークフローなど、AIのユースケースを実験することができます。信頼性の高い顧客データで微調整されたホストされたジェネラティブモデルを使用することで、企業は顧客への更なる個別化された効果的なAIアプリケーションを提供することができます。

Amazon SageMakerでは、リアルタイム、非同期、バッチ変換など、さまざまなML推論オプションを提供しています。この記事では、FMsのホスティングをコスト効果の高い方法でスケーリングするための具体的なガイダンスに焦点を当てています。具体的には、リアルタイム推論の迅速かつ柔軟な世界について考察し、FMsのリアルタイム推論のさまざまなオプションを探っています。

推論において、マルチテナントのAI/MLアーキテクチャはデータとモデルの要件、およびこれらのモデルからの推論に必要な計算リソースを考慮する必要があります。マルチテナントのAI/MLモデルを展開する方法を検討する上で重要なポイントは、実際には、CPUとGPUを最適に活用するためのインフェリンシングソリューションの設計が必要であり、これにより、モデルが効率的に計算インフラストラクチャ全体に分散されることで、サービスのスループットを向上させ、コストを削減することができます。さらに、顧客は、すべてをゼロから作り上げる必要なく、ベストプラクティスの推論アーキテクチャを展開することを支援するソリューションを求めています。

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

SageMaker Inferenceは、フルマネージドのMLホスティングサービスです。FedRAMPなどの規制基準を満たしながら、ジェネラティブAIアプリケーションの構築をサポートしています。 SageMakerは、高スループットの推論ワークロードに対して、コスト効率の良いスケーリングを実現します。 AWS Inferentia、AWS Graviton、NVIDIA GPU、Intel CPUといったハードウェア上で、リアルタイム、非同期、バッチの推論など、さまざまなワークロードをサポートします。 SageMakerでは、最適化、ワークロードの分離、コンテナ化に対する完全な制御が可能です。マルチモデルおよびマルチコンテナの展開をサポートし、スケールできるジェネラティブAIサービスソリューションを構築することができます。

大規模なファウンデーションモデルのホスティングにおける課題

スケールでの推論のためのFMsのホスティングには、次のような課題があります：

• 大規模なメモリフットプリント – 十数億から数百億のモデルパラメータを持つFMsは、単一のアクセラレータチップのメモリ容量を超えることがよくあります。
• 変換は遅い – 特に長い入力と出力シーケンスを持つFMsにおける自己回帰デコーディングは、メモリのI/O操作を悪化させます。これにより、受け入れがたい遅延期間が発生し、リアルタイム推論に悪影響を及ぼします。
• コスト – FMsには高いメモリと高い計算能力を提供するMLアクセラレータが必要です。いずれも犠牲にすることなく高いスループットと低いレイテンシを実現するためには、ハードウェアとソフトウェアの加速度最適化に関する深い理解が必要です。
• 市場投入までの時間がかかる – FMsから最適なパフォーマンスを引き出すには、厳密なチューニングが必要です。この特殊なチューニングプロセスは、インフラストラクチャ管理の複雑さと組み合わさり、市場投入までの時間が延びます。
• ワークロードの分離 – 大規模なFMsのホスティングでは、カオス領域を最小限に抑えることが課題となります。モデルごとのトラフィックパターンに対応して各FMをスケーリングする能力は、非常に重要です。
• 数百のFMsへのスケーリング – 同時に何百ものFMsを運用することは、大きな運用負荷を伴います。エンドポイントの効果的な管理、適切なスライシングとアクセラレータの割り当て、モデルごとのスケーリングなどのタスクは、モデルの展開が増えるにつれて複雑化します。

フィットネス関数

適切なホスティングオプションを選択することは重要です。なぜなら、それはアプリケーションによってレンダリングされるエンドユーザーに影響を及ぼすからです。この目的のために、AWSパートナーのThought WorksのNeal Ford氏と彼の同僚が「Building Evolutionary Architectures」という著作で提唱したフィットネス関数の概念を利用しています。フィットネス関数は、目標に基づいてさまざまなホスティングオプションの評価を提供します。フィットネス関数は、アーキテクチャの計画された進化を可能にするために必要なデータを取得するのに役立ちます。設定した目標を達成するために、ソリューションがどれだけ近いかを評価するための測定可能な値を設定します。フィットネス関数は、アーキテクチャの進化に合わせて適応され、望ましい変化プロセスをガイドするためのツールを提供します。これにより、アーキテクトはチームの自律性を維持しながらチームをガイドすることができます。

以下のフィットネス関数を検討することを提案します。これは、スケールとコスト効率を考慮して正しいFM推論オプションを選択する際に検討するべきです：

• Foundationモデルのサイズ – FMはtransformerに基づいています。transformerは、モデルのサイズの大きさにより、長いテキストシーケンスの生成時に遅く、メモリを多く消費します。Large language models（LLMs）はFMの一種であり、テキストシーケンスを生成する際には膨大な計算能力が必要であり、利用可能な高帯域幅メモリ（HBM）や計算能力にアクセスする際にも困難が生じます。大部分の利用可能なメモリ帯域幅は、モデルのパラメータの読み込みや自己回帰的なデコーディングプロセスによって消費されるため、FMはメモリI/Oと計算制限に制約を受けます。そのため、モデルのサイズは、モデルが単一のアクセラレータに収まるか、モデルシャーディングを使用して複数のMLアクセラレータを使用するかなど、多くの決定に関与します。30億パラメータ以上のモデルでは、一般的に複数のMLアクセラレータが必要になる場合があります。
• パフォーマンスとFMの推論レイテンシ – 多くのMLモデルとアプリケーションはレイテンシが重要であり、サービスレベルの目標で指定された範囲内の推論レイテンシである必要があります。FMの推論レイテンシは、以下の要素に依存します：
  • FMモデルのサイズ – ランタイムでの量子化も含めたモデルのサイズ。
  • ハードウェア – 計算能力（TFLOPS）、HBMのサイズと帯域幅、ネットワーク帯域幅、インスタンス内部接続速度、ストレージ帯域幅など。
  • ソフトウェア環境 – モデルサーバー、モデルパラレルライブラリ、モデル最適化エンジン、集合通信パフォーマンス、モデルネットワークアーキテクチャ、量子化、およびMLフレームワーク。
  • プロンプト – 入力および出力の長さ、ハイパーパラメータ。
  • スケーリングレイテンシ – トラフィックに応答するためのスケーリングにかかる時間。
  • コールドスタートレイテンシ – FMの読み込み時のコールドスタートレイテンシを低減するためのプリウォーミングなどの機能。
• ワークロードの分離 – これは規制やコンプライアンスの観点からのワークロードの分離要件を指します。AIモデルとアルゴリズムの機密性と完全性、AI推論中のデータの機密性、およびAIの知的財産（IP）の未承認アクセスやリスク管理の観点からの保護を含みます。例えば、ブラスト影響範囲の故意の削減やノイズの近傍の防止により、セキュリティイベントの影響を軽減できます。
• コスト効率 – スケーラブルなフレームワーク上でFMモデルとMLアプリケーションを展開および維持するためには、選択したモデルホスティングインフラストラクチャ、ホスティングオプション、MLフレームワーク、MLモデルの特性、最適化、スケーリングポリシーなどによって、コストが大きく変動する場合があります。ワークロードは、ハードウェアインフラを最適に活用し、コストを抑えるために努力する必要があります。このフィットネス関数は、インフラストラクチャコストに特に焦点を当てており、全体的な総所有コスト（TCO）の一部です。インフラストラクチャコストは、ストレージ、ネットワーク、および計算の組み合わせたコストです。また、運用コストやセキュリティおよびコンプライアンスコストなど、TCOの他のコンポーネントを理解することも重要です。運用コストは、MLインフラストラクチャの運用、監視、および保守のために必要なエンジニアの数と、エンジニアの年間給与を特定の期間に集約したものです。トラフィックがない場合はゼロまで自動的にスケールダウンしてコストを節約します。
• スケーラビリティ – これには以下が含まれます：
  • 多テナントプラットフォームでの数百のFMの推論を管理する際の操作的負荷。
  • 単一のエンドポイントに複数のFMを詰め込み、モデルごとにスケールする能力。
  • ワークロードパターンに基づいたインスタンスレベルおよびモデルコンテナレベルのスケーリングのサポート。
  • エンドポイントごとに数百のFMをスケーリングするサポート。
  • モデルの初期配置とアクセラレータが不足している場合のモデルフリートのハンドリングのサポート。

フィットネス関数での次元の表現

私たちは、フィットネス関数で次元を表現するために、スパイダーチャート（またはレーダーチャート）を使用します。スパイダーチャートは、複数の独自の次元にわたるデータを表示する際によく使用されます。これらの次元は通常量的であり、通常ゼロから最大値までの範囲を持ちます。各次元の範囲は互いに正規化されているため、スパイダーチャートを描く際には、ゼロから次元の最大値までの長さがすべての次元において同じになります。

次のチャートは、SageMaker上でアーキテクチャを選択する際の意思決定プロセスを示しています。スパイダーチャート上の各半径は、推論ソリューションを構築する際に優先順位を付けるフィットネス関数の1つです。

理想的には、すべての辺が等辺三角形（五角形）である形状が望ましいです。これは、すべてのフィットネス関数に対して最適化が可能であることを示しています。しかし現実的には、この形状を実現することは困難です。1つのフィットネス関数に優先順位を付けると、他の半径の線に影響が出ます。つまり、一部のフィットネス関数に優先度を付けることで、他のフィットネス関数とのトレードオフが常に存在します。これは、生成AIアプリケーションにおいて重要な要素が何かによって、常に特定の半径に偏ったグラフを持つことを意味します。各関数ごとに選ぶ視点に応じて、他のフィットネス関数よりも優先度を下げる可能性のある基準です。このチャートでは、各フィットネス関数のメトリックの重みが以下のように定義されます。値が低いほど、そのフィットネス関数にとって最適ではないことを意味します（ただし、モデルのサイズを除く）。

例えば、使用ケースとして、Anthropic Claudeなどの大型要約モデルを使用して、ケースデータと顧客履歴に基づいて作業要約を作成したい場合を考えてみましょう。次のスパイダーチャートがあります。

顧客データの取り扱いに関わるため、他のモデルからこのワークロードを分離することを選択し、個別のモデルエンドポイントにホストすることになります。ただし、各FMに対して個別のエンドポイントをスピンアップして管理する必要があるため、スケーリングは困難になる場合があります。モデルをリアルタイムでサービスエージェントが使用しているため、レイテンシとスループットが優先されます。そのため、P4Deのような大型インスタンスタイプを使用する必要があります。この状況では、優先度が分離、レイテンシ、およびスループットにあるため、コストが高くなる可能性があります。

もう1つの使用ケースは、多数の顧客にカスタマイズされたQ&Aチャットボットアプリケーションを構築するサービス組織です。次のスパイダーチャートは彼らの優先事項を反映しています。

各チャットボット体験は、それぞれの特定の顧客に合わせる必要があるかもしれません。使用されるモデルは比較的小さなもの（FLAN-T5-XXL、Llama 7B、k-NNなど）ですし、各チャットボットは毎日異なるタイムゾーンの指定された時間帯に運営されます。ソリューションには、リアルタイムで推論に使用するナレッジベースアイテムが含まれたデータベースと組み合わせたRetrieval Augmented Generation (RAG)も組み込まれているかもしれません。このチャットボットを介して特定の顧客データは交換されていません。コールドスタートの遅延は許容可能です。なぜなら、チャットボットは定義されたスケジュールで運営されるからです。この使用ケースでは、マルチモデルエンドポイントアーキテクチャを選択し、G5のような小型インスタンスタイプを使用することでコストを削減し、スケールできるエンドポイント上で複数のモデルをホストすることで運用のオーバーヘッドを削減することができるかもしれません。ワークロードの分離以外は、この使用ケースではフィットネス関数の優先度がより均等であり、トレードオフもある程度最小限に抑えられています。

最後の例は、3.5〇〇億パラメータのStable Diffusion 2.0のようなモデルを使用する画像生成アプリケーションです。次のスパイダーチャートがあります。

このサブスクリプションベースのアプリケーションでは、数千のFMと顧客にサービスを提供しています。各顧客は画像の出力を迅速に期待しているため、応答時間が速くなければなりません。さらに、同時に何十万ものリクエストがあるため、スループットも重要です。そのため、GPUとメモリが十分なP4Dのような大型インスタンスタイプを選択する必要があります。この場合、一つのリクエストセットから別のリクエストセットへのイメージ生成をデノイズするためにモデルの複数のコピーをホストするマルチコンテナエンドポイントの構築を考えることができます。この使用ケースでは、レイテンシとスループットを優先し、ユーザーの要求に対応するために計算コストとワークロードの分離のトレードオフが発生することになります。

FMホスティングオプションの選択にフィットネス関数を適用する

このセクションでは、SageMaker FMsでスケールに対応した正しいFMホスティングオプションを選択するために、前述のフィットネス関数をどのように適用するかを説明します。

SageMakerシングルモデルエンドポイント

SageMakerシングルモデルエンドポイントでは、低遅延と高スループットのために専用インスタンス上でコンテナにFMをホストすることができます。これらのエンドポイントは完全に管理されており、オートスケーリングをサポートしています。シングルモデルエンドポイントをプロビジョニングエンドポイントとして設定することができます。この場合、インスタンスのタイプや数などのエンドポイントのインフラストラクチャー構成をエンドポイントに渡し、SageMakerはオートスケーリングポリシーに応じて自動的に計算リソースを起動およびスケーリングします。複数のシングルモデルエンドポイントを使用して数百のモデルをホストし、増強された弾力性とブラスト半径の削減のためのセルベースのアーキテクチャを採用することができます。

プロビジョニングされたシングルモデルエンドポイントのフィットネス関数を評価する際は、以下の点を考慮してください：

• Foundationモデルのサイズ – シングルMLアクセラレータのメモリに収まらないモデルに適しています。そのため、複数のアクセラレータがインスタンス内に必要です。
• パフォーマンスとFM推論の遅延 – 遅延がクリティカルな生成AIアプリケーションに関連します。
• ワークロードの分離 – アプリケーションがセキュリティコンプライアンスの理由でAmazon Elastic Compute Cloud（Amazon EC2）インスタンスレベルの分離が必要な場合があります。各FMには別々の推論エンドポイントが割り当てられ、EC2インスタンスを他のモデルと共有しません。例えば、HIPAA関連のモデル推論ワークロード（PHI検出モデルなど）をネットワーク分離された専用セキュリティグループ設定を持つ別のエンドポイントに分離できます。信頼性の低いワークロードから分離するために、p4dnのようなNitroベースのEC2インスタンスを使用してGPUベースのモデル推論ワークロードを分離することもできます。NitroシステムベースのEC2インスタンスは仮想化と分離のユニークなアプローチを提供し、AWSオペレータやソフトウェアから機密データ処理を常時保護および分離することができます。また、このオプションは、SageMaker上でサードパーティのモデルプロバイダが提供するAWS Marketplaceのモデルの展開もサポートします。

SageMakerマルチモデルエンドポイント

SageMakerマルチモデルエンドポイント（MME）では、複数のモデルを1つのGPUコア上で共有し、複数のモデル間でGPUインスタンスをエンドポイントの背後で共有し、トラフィックに基づいてモデルを動的にロードおよびアンロードすることができます。これにより、コストを大幅に節約し、最適な価格性能を実現することができます。

MMEは、単一のMLアクセラレータのHBMに収まるような小さなモデルをホストする必要がある場合に最適です。この戦略は、数千の類似のサイズ（10億パラメータ以下）のモデルを、単一のインスタンス内の共有コンテナを介して提供し、すべてのモデルに同時にアクセスする必要がない場合に考慮するべきです。使用するモデルをロードしてから別のモデルにアンロードすることができます。

MMEはまた、同じMLフレームワークを使用するモデルを共有コンテナを使用して共有することを目的としています。したがって、PyTorchとTensorFlowなどの複数のMLフレームワークがモデルフリートに混在している場合は、InferenceComponentsを使用したSageMakerエンドポイントの方が適しています。このポストでは、InferenceComponentsについて後で詳しく説明します。

最後に、MMEはたまに起動の遅延が発生しても許容できるアプリケーションに適しています。使用頻度が低いモデルは頻繁に呼び出されるモデルの代わりにオフロードできます。使用頻度が低いモデルの長いテールがある場合、マルチモデルエンドポイントはこのトラフィックを効率的に処理し、大幅なコスト削減を実現できます。

MMEの使用時に考慮する点は以下の通りです：

• Foundationモデルのサイズ – シングルMLアクセラレータのHBMに収まるモデルがある場合、複数のアクセラレータは必要ありません。
• パフォーマンスとFM推論の遅延 – モデルがリクエストされた際にメモリに存在しない場合でも、ランタイムが許容できる場合があります。
• ワークロードの分離 – すべてのモデルを同じコンテナで共有することを考慮してください。
• スケーラビリティ – 次のことを考慮してください：
  • 複数のモデルを1つのエンドポイントにパックし、モデルごとおよびMLインスタンスごとにスケールすることができます。
  • ワークロードパターンに基づいてインスタンスレベルのオートスケーリングを有効にすることができます。
  • MMEはエンドポイントごとに数千モデルまでスケールできます。モデルごとのオートスケーリングとデプロイメント構成を維持する必要はありません。
  • 推論リクエストによってモデルが要求された場合には、ホットデプロイメントを使用できます。
  • 推論リクエストに応じてモデルを動的にロードし、メモリの圧力に応じてアンロードすることができます。
  • モデルとリソースをタイムシェアリングすることができます。
• コスト効率 – モデルの動的なロードおよびアンロードによるリソースのタイムシェアリングを考慮し、コスト削減を実現します。

InferenceComponentsを使用したSageMaker推論エンドポイント

InferenceComponentsを使用した新しいSageMaker推論エンドポイントは、単一のエンドポイントで複数のFMをホストし、モデルごとにスケーリングするスケーラブルなアプローチを提供します。リソース（アクセラレータ、メモリ、CPU）を細かく制御し、モデルごとに自動スケーリングポリシーを設定することで、確実なスループットと予測可能なパフォーマンスを得ることができます。また、複数のモデル間で計算リソースの利用を個別に管理することができます。もし、単一のアクセラレータのメモリに収まらないさまざまなサイズとトラフィックパターンのモデルをホストする必要がある場合、このオプションが最適です。また、コストを節約するためにゼロまでスケーリングすることも可能ですが、モデルの起動時間を考慮に入れる必要があります。このオプションは、顧客またはFMごとのコンテナレベルの分離が十分である限り、計算リソースの柔軟性を最大限に活用することを可能にします。新しいSageMakerエンドポイントの詳細については、詳細な投稿Amazon SageMakerの最新機能を使用して、モデル展開コストを平均50%削減するを参照してください。

InferenceComponentsを使用したエンドポイントを使用する際に考慮すべき点は次のとおりです。

• Foundationモデルのサイズ – 単一のMLアクセラレータのメモリに収まらないモデルに適しています。
• パフォーマンスとFMの推論レイテンシ – レイテンシに敏感な生成AIアプリケーションに最適です。
• ワークロードの分離 – コンテナレベルの分離が十分なアプリケーションがあるかもしれません。
• スケーラビリティ – 次を考慮してください：
  • 単一のエンドポイントに複数のFMを詰め込み、モデルごとにスケーリングできます。
  • ワークロードパターンに基づいてインスタンスレベルおよびモデルコンテナレベルでスケーリングを有効にできます。
  • この方法はエンドポイントあたりの数百のFMへのスケーリングをサポートしています。各モデルまたはコンテナの自動スケーリングポリシーを設定する必要はありません。
  • モデルの初期配置と不十分なアクセラレータの処理をサポートしています。
• コスト効率 – トラフィックがない場合にモデルごとにゼロまでスケーリングでき、コストを節約できます。

同じエンドポイントに複数のFMを詰め込む: モデルのグループ化

SageMakerで採用する推論アーキテクチャ戦略は、アプリケーションの優先事項と要件に依存します。一部のSaaSプロバイダは、厳しい分離要件を要求する規制環境に販売しており、一部またはすべてのFMを専用モデルで展開できるオプションが必要です。ただし、コストを最適化しスケールの経済性を得るために、SaaSプロバイダは複数のFMを共有のSageMakerリソースにホストするマルテナント環境も持つ必要があります。ほとんどの組織は、SageMakerアーキテクチャの一部として、単一モデルのエンドポイントと複数モデルまたは複数コンテナのエンドポイントの両方を持つハイブリッドホスティング環境を持つことでしょう。

この分散推論環境を設計する際に行う必要がある重要な演習は、SageMakerエンドポイントに設定するための各種アーキテクチャ用にモデルをグループ化することです。最初の決定として、ワークロードの分離要件を確認する必要があります。セキュリティ上の理由、ブラスト半径とノイズネイバリスクの削減、またはレイテンシの厳密なSLAの達成など、専用のエンドポイントに配置する必要があるFMを分離する必要があります。

次に、モデルが単一のMLアクセラレータに収まるか、複数のアクセラレータが必要か、モデルのサイズとトラフィックパターンを特定する必要があります。同じサイズのモデルは、集約された中央機能をサポートするために論理的に一緒にグループ化できます。複数のモデルを同じエンドポイントにホストする場合、グループ化の演習を実施して、どのモデルが単一のインスタンス、単一のコンテナ、または複数のコンテナに配置できるかを決定する必要があります。

MME用のモデルのグループ化

MMEは、単一のアクセラレータに収まる数十億パラメータ未満の小さなモデルに最適です。モデルのサイズと呼び出しレイテンシが似ている場合に適しています。サイズにわずかなバリエーションがある場合も許容されます。たとえば、Zendeskのモデルは10-50 MBで機能しますが、サイズが10、50、または100倍大きいばらつきは適していません。大きなモデルは、十分なメモリスペースを確保するために、より小さなモデルのロードとアンロードの回数が増え、エンドポイントでの追加のレイテンシが発生する可能性があります。大きなモデルのパフォーマンス特性の違いは、CPUなどのリソースを均等に消費することがあり、他のモデルに影響を与える可能性があります。

MM内でグループ化されるモデルには、推論のために複数のモデル間で計算を共有できるように、交差するトラフィックパターンが必要です。アクセスパターンと推論の待ち時間も、モデルの切り替え時の冷間起動時間を考慮する必要があります。

MMEのモデルをグループ化するためのいくつかの推奨基準は次のとおりです:

• 小さいモデル – 10億パラメータ以下のモデルを使用します
• モデルサイズ – 似たサイズのモデルをグループ化して同じエンドポイントにホストします
• 呼び出しの待ち時間 – 冷間起動が許容でき、似た呼び出しの待ち時間要件を持つモデルをグループ化します
• ハードウェア – 同じ基礎となるEC2インスタンスタイプを使用してモデルをグループ化します

推論コンポーネントを使用したエンドポイントのモデルグループ化

InferenceComponentsを使用したSageMakerエンドポイントは、1兆パラメータ以上の大規模なFMsを大規模にホストするために、複数のMLアクセラレータまたはデバイスをEC2インスタンスで必要とする場合に適しています。このオプションは、レイテンシに敏感なワークロードやコンテナレベルの分離が十分なアプリケーションに適しています。推奨されるInferenceComponentsの基準の一部は以下のとおりです:

• ハードウェア – 同じ基礎となるEC2インスタンスタイプを使用してモデルをグループ化します
• モデルサイズ – モデルサイズに基づいてモデルをグループ化することを推奨しますが、必須ではありません

まとめ

この記事では、SageMakerでリアルタイムのML推論オプション（単一エンドポイント、複数モデルエンドポイント、およびInferenceComponentsエンドポイント）の3つを効率的に大規模にコスト効果的にホストする方法を説明しました。FMsを大規模にホストするための適切なSageMakerホスティングオプションを選択するのに役立つ、5つの適合性関数を使用することができます。推奨されるグループ化の基準を使用して、FMsをSageMakerの推論エンドポイントで共同ホストします。今回取り上げた適合性関数に加えて、使用ケースに最適な共有SageMakerホスティングオプションを決定するために、以下の表を使用することもできます。各FMホスティングオプションのコードサンプルは、以下のGitHubリポジトリで入手できます：単一のSageMakerエンドポイント、複数モデルエンドポイント、およびInferenceComponentsエンドポイント。

.	シングルモデルエンドポイント	マルチモデルエンドポイント	InferenceComponentsを使用したエンドポイント
モデルライフサイクル	管理のためのAPI	Amazon S3パスを介して動的に	管理のためのAPI
サポートされるインスタンスタイプ	CPU、シングルおよびマルチGPU、AWS Inferentiaベースのインスタンス	CPU、シングルGPUベースのインスタンス	CPU、シングルおよびマルチGPU、AWS Inferentiaベースのインスタンス
メトリックの粒度	エンドポイント	エンドポイント	エンドポイントとコンテナ
スケーリングの粒度	MLインスタンス	MLインスタンス	コンテナ
スケーリングの動作	独立したMLインスタンスのスケーリング	モデルはメモリからロードおよびアンロードされます	独立したコンテナスケーリング
モデルのピン設定	.	メモリに基づいてモデルをアンロードできます	各コンテナを常にロードまたはアンロードするように構成できます
コンテナの要件	SageMakerのプリビルト、SageMaker互換のBring Your Own Container（BYOC）	MMS、Triton、MMEコンテラ剋でのBYOC	SageMakerのプリビルト、SageMaker互換のBYOC
ルーティングオプション	ランダムまたは最小接続	ランダム、人気ウィンドウ付きのスティッキールーティング	ランダムまたは最小接続
モデルのハードウェア割り当て	単一モデルに専用	共有	各コンテナに専用
サポートされるモデル数	1つ	数千	数百
応答ストリーミング	サポートされています	サポートされていません	サポートされています
データのキャプチャ	サポートされています	サポートされていません	サポートされていませ

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