基盤モデル (FM) の民主化がさらに普及し、AI 拡張サービスの需要が高まるにつれ、サービスとしてのソフトウェア (SaaS) プロバイダーは、組織内のデータ サイエンティスト向けに、複数のテナントをサポートする機械学習 (ML) プラットフォームの使用を検討しています。そして外部の顧客。 顧客向けに高度にパーソナライズされた効果的なコンテンツを生成するために FM を使用することの価値を認識する企業が増えています。 独自のデータに基づいて FM を微調整すると、ページ訪問コンテキストを使用した販売メールの生成、企業のサービスに合わせた検索回答の生成、過去の会話のトレーニングによる顧客サポートの自動化など、特定のユースケースに合わせてモデルの精度を大幅に高めることができます。
生成 AI モデル ホスティングをサービスとして提供することで、社内の AI 専門知識を必要とせずに、あらゆる組織がコスト効率の高い方法で FM を簡単に統合、パイロット テスト、大規模に導入できるようになります。 これにより、企業は、非常にパーソナライズされた販売およびマーケティング コンテンツ、インテリジェントな検索、カスタマイズされた顧客サービス ワークフローなどの AI ユースケースを実験できるようになります。 信頼できる顧客データに基づいて微調整されたホスト型生成モデルを使用することで、企業は次のレベルのパーソナライズされた効果的な AI アプリケーションを提供し、顧客との関わりを深め、顧客へのサービスを向上させることができます。
アマゾンセージメーカー は、リアルタイム、非同期、バッチ変換などのさまざまな ML 推論オプションを提供します。 この投稿では、FM を大規模にコスト効率よくホスティングするための規範的なガイダンスを提供することに焦点を当てています。 具体的には、FM 向けのリアルタイム推論のさまざまなオプションを検討しながら、リアルタイム推論の迅速かつ応答性の高い世界について説明します。
推論の場合、マルチテナント AI/ML アーキテクチャでは、データとモデルの要件に加え、これらのモデルから推論を実行するために必要なコンピューティング リソースを考慮する必要があります。 マルチテナント AI/ML モデルの展開方法を検討することが重要です。理想的には、CPU と GPU を最適に利用するには、モデルが確実に分散されるようにすることで、サービスのスループットを向上させ、コストを削減できる推論ソリューションを構築できなければなりません。コンピューティング インフラストラクチャ全体で効率的な方法で実行されます。 さらに、顧客は、すべてを最初から構築する必要がなく、ベストプラクティスの推論アーキテクチャを導入できるソリューションを求めています。
SageMaker Inference は、フルマネージドの ML ホスティング サービスです。 FedRAMP などの規制基準を満たしながら、生成 AI アプリケーションの構築をサポートします。 SageMaker は、高スループットの推論ワークロードに対してコスト効率の高いスケーリングを可能にします。 AWS Inferentia、AWS Graviton、NVIDIA GPU、Intel CPU などのハードウェアでのリアルタイム推論、非同期推論、バッチ推論など、さまざまなワークロードをサポートします。 SageMaker を使用すると、最適化、ワークロードの分離、コンテナ化を完全に制御できます。 マルチモデルおよびマルチコンテナのデプロイメントをサポートし、大規模なサービスとしての生成型 AI ソリューションを構築できます。
基盤モデルを大規模にホストする際の課題
以下は、大規模な推論のために FM をホストする際の課題の一部です。
- 大きなメモリフットプリント – 数百億または数千億のモデルパラメータを持つ FM は、単一のアクセラレータ チップのメモリ容量を超えることがよくあります。
- トランスフォーマーは遅い – FM の自己回帰デコードは、特に長い入出力シーケンスの場合、メモリ I/O 操作を悪化させます。 これにより、許容できない待ち時間が発生し、リアルタイム推論に悪影響を及ぼします。
- 費用 – FM には、大容量のメモリと高い計算能力の両方を提供する ML アクセラレータが必要です。 どちらも犠牲にすることなく高スループットと低レイテンシを達成することは特殊なタスクであり、ハードウェアとソフトウェアのアクセラレーションの共同最適化についての深い理解が必要です。
- 市場投入までの時間の延長 – FM の最適なパフォーマンスには厳密なチューニングが必要です。 この特殊なチューニング プロセスとインフラストラクチャ管理の複雑さにより、市場投入までの時間が延長されます。
- ワークロードの分離 – 大規模な FM のホスティングでは、爆発半径の最小化と騒々しい近隣への対応に課題が生じます。 モデル固有のトラフィック パターンに応じて各 FM を拡張するには、大変な作業が必要です。
- 数百の FM まで拡張可能 – 数百の FM を同時に動作させると、かなりの運用オーバーヘッドが生じます。 効果的なエンドポイント管理、適切なスライシングとアクセラレータの割り当て、モデル固有のスケーリングは、デプロイされるモデルが増えるにつれて複雑になるタスクです。
フィットネス機能
アプリケーションによってレンダリングされるエンドユーザーに影響を与えるため、適切なホスティング オプションを決定することは重要です。 この目的のために、次の概念を借りています。 フィットネス機能これは、AWS Partner Thought Works の Neal Ford と彼の同僚が仕事の中で考案した造語です。 進化的アーキテクチャの構築。 フィットネス機能は、目的に基づいてさまざまなホスティング オプションの規範的な評価を提供します。 フィットネス機能は、アーキテクチャの計画的な進化を可能にするために必要なデータを取得するのに役立ちます。 ソリューションが設定された目標の達成にどれだけ近づいているかを評価するための測定可能な値を設定します。 フィットネス機能は、アーキテクチャが進化するにつれて、望ましい変更プロセスを導くことができ、また適応させるべきです。 これにより、アーキテクトはチームの自律性を維持しながらチームをガイドするツールを提供します。
大規模かつコスト効率よく適切な FM 推論オプションを選択する場合、次の適合関数を考慮することを提案します。
- 基礎モデルのサイズ – FM は変圧器に基づいています。 モデルのサイズが非常に大きいため、トランスフォーマーは長いテキスト シーケンスを生成する際に時間がかかり、メモリを大量に消費します。 大規模言語モデル (LLM) は FM の一種であり、テキスト シーケンスの生成に使用される場合、膨大な量のコンピューティング パワーが必要となり、利用可能な高帯域幅メモリ (HBM) とコンピューティング容量へのアクセスが困難になります。 これは、利用可能なメモリ帯域幅の大部分が、モデルのパラメータのロードと 自己回帰デコードプロセス。 その結果、たとえ膨大な量の計算能力があっても、FM はメモリ I/O と計算の制限によって制限されます。 したがって、モデルのサイズによって、モデルが単一のアクセラレータに適合するか、より高いスループットで推論を実行するためにインスタンス上でモデル シャーディングを使用する複数の ML アクセラレータが必要かなど、多くの決定が決まります。 3 億を超えるパラメータを持つモデルでは、モデルが単一のアクセラレータ デバイスに収まらない可能性があるため、通常、複数の ML アクセラレータが必要になります。
- パフォーマンスと FM 推論レイテンシ – 多くの ML モデルとアプリケーションはレイテンシが重要であり、推論レイテンシはサービス レベル目標で指定された範囲内に収まる必要があります。 FM 推論のレイテンシーは、次のような多数の要因に依存します。
- FMモデルサイズ – 実行時の量子化を含むモデルのサイズ。
- Hardware – コンピューティング (TFLOPS)、HBM のサイズと帯域幅、ネットワーク帯域幅、インスタンス内の相互接続速度、ストレージ帯域幅。
- ソフトウェア環境 – モデルサーバー、モデル並列ライブラリ、モデル最適化エンジン、集合通信パフォーマンス、モデルネットワークアーキテクチャ、量子化、MLフレームワーク。
- プロンプト – 入力および出力の長さとハイパーパラメータ。
- スケーリングレイテンシ – トラフィックに応じてスケールするまでの時間。
- コールドスタートの待ち時間 – モデル ロードの事前ウォーミングなどの機能により、FM をロードする際のコールド スタートの待ち時間を短縮できます。
- ワークロードの分離 – これは、AI モデルとアルゴリズムの機密性と完全性の保護、AI 推論中のデータの機密性の保護、不正アクセスやリスク管理の観点からの AI 知的財産 (IP) の保護など、規制およびコンプライアンスの観点からのワークロード分離要件を指します。 たとえば、爆発半径を意図的に小さくしたり、近隣の騒音を防ぐことで、セキュリティ イベントの影響を軽減できます。
- コスト効率 – スケーラブルなフレームワーク上で FM モデルと ML アプリケーションをデプロイおよび維持することは重要なビジネス プロセスであり、コストはモデル ホスティング インフラストラクチャ、ホスティング オプション、ML フレームワーク、ML モデルの特性、最適化、スケーリング ポリシーに関する選択によって大きく異なる場合があります。 、 もっと。 コストを確実に抑えるために、ワークロードはハードウェア インフラストラクチャを最適に利用する必要があります。 この適合性関数は、特に総所有コスト (TCO) の一部であるインフラストラクチャ コストを指します。 インフラストラクチャのコストは、ストレージ、ネットワーク、コンピューティングの合計コストです。 運用コスト、セキュリティおよびコンプライアンスのコストなど、TCO の他の要素を理解することも重要です。 運用コストは、ML インフラストラクチャの運用、監視、保守にかかるコストを合計したものです。 運用コストは、シナリオごとに必要なエンジニアの人数とエンジニアの年収を一定期間集計して算出します。 トラフィックがない場合は、コストを節約するためにモデルごとに自動的にゼロにスケールされます。
- スケーラビリティ - これも:
- マルチテナント プラットフォームで推論するために数百の FM を管理する際の運用オーバーヘッド。
- 複数の FM を XNUMX つのエンドポイントにパックし、モデルごとに拡張する機能。
- ワークロード パターンに基づいてインスタンス レベルおよびモデル コンテナ レベルのスケーリングを有効にします。
- エンドポイントごとに数百の FM への拡張をサポートします。
- フリート内のモデルの初期配置と不十分なアクセラレータの処理をサポートします。
フィットネス関数での次元の表現
スパイダー チャート (レーダー チャートとも呼ばれる) を使用して、適応度関数のディメンションを表します。 スパイダー チャートは、複数の固有のディメンションにわたってデータを表示する場合によく使用されます。 これらの次元は通常定量的であり、通常はゼロから最大値までの範囲になります。 各ディメンションの範囲は相互に正規化されているため、スパイダー チャートを描画するとき、ゼロからディメンションの最大値までの線の長さはすべてのディメンションで同じになります。
次の図は、SageMaker でアーキテクチャを選択する際の意思決定プロセスを示しています。 スパイダー チャート上の各半径は、推論ソリューションを構築するときに優先するフィットネス関数の XNUMX つです。
理想的には、すべての辺が正三角形 (五角形) の形状が必要です。 これは、すべてのフィットネス機能を最適化できることを示しています。 しかし現実には、その形状を達成するのは困難です。XNUMX つのフィットネス関数を優先すると、他の半径のラインに影響を及ぼします。 これは、生成 AI アプリケーションにとって何が最も重要かに応じて常にトレードオフが存在し、グラフが特定の半径に向かって偏ることになることを意味します。 これは、各機能をどのように見るかによっては、優先順位を下げて他の基準を優先してもよい基準です。 私たちのグラフでは、各適応度関数のメトリックの重みはそのように定義されています。値が低いほど、その適応度関数にとって最適ではなくなります (モデル サイズは例外で、この場合、値が大きいほど、モデルのサイズが大きくなります)。モデル)。
たとえば、大規模な要約モデル (Anthropic Claude など) を使用して、ケース データと顧客履歴に基づいてサービス ケースと顧客エンゲージメントの作業概要を作成するユース ケースを考えてみましょう。 次のようなスパイダーチャートがあります。
これには機密の顧客データが含まれる可能性があるため、このワークロードを他のモデルから分離し、単一モデルのエンドポイントでホストすることを選択しています。これにより、FM ごとに個別のエンドポイントを立ち上げて管理する必要があるため、拡張が困難になる可能性があります。 モデルを使用している生成 AI アプリケーションは、サービス エージェントによってリアルタイムで使用されるため、レイテンシーとスループットが優先されるため、P4De などのより大きなインスタンス タイプを使用する必要があります。 この状況では、分離、遅延、スループットが優先されるため、コストを高くする必要がある可能性があります。
別の使用例は、多数の顧客向けにカスタマイズされた Q&A チャットボット アプリケーションを構築するサービス組織です。 次のスパイダー チャートは、それらの優先順位を反映しています。
各チャットボット エクスペリエンスは、特定の顧客ごとに調整する必要がある場合があります。 使用されているモデルは比較的小規模 (FLAN-T5-XXL、Llama 7B、および k-NN) で、各チャットボットは毎日異なるタイムゾーンで指定された時間帯に動作します。 このソリューションには、リアルタイムの推論で使用されるすべての知識ベース項目を含むデータベースと統合された検索拡張生成 (RAG) も含まれる場合があります。 このチャットボットを通じて交換される顧客固有のデータはありません。 チャットボットは定義されたスケジュールに従って動作するため、コールド スタートの遅延は許容できます。 このユースケースでは、マルチモデル エンドポイント アーキテクチャを選択でき、より小さいインスタンス タイプ (G5 など) を使用してコストを最小限に抑え、各エンドポイントで複数のモデルを大規模にホストすることで運用オーバーヘッドを削減できる可能性があります。 ワークロードの分離を除いて、この使用例ではフィットネス機能にほぼ同等の優先順位が与えられる可能性があり、トレードオフはある程度最小限に抑えられます。
最後の例は、Stable Diffusion 2.0 のようなモデル (3.5 億パラメータ モデル) を使用した画像生成アプリケーションです。 私たちのスパイダーチャートは次のとおりです。
これは、数千の FM と顧客にサービスを提供するサブスクリプション ベースのアプリケーションです。 各顧客は画像出力の迅速な対応を期待しているため、応答時間は迅速である必要があります。 毎秒何十万ものリクエストが発生するため、スループットも重要です。そのため、インスタンス タイプは、十分な GPU とメモリを備えた P4D など、より大きなインスタンス タイプにする必要があります。 このため、モデルの複数のコピーをホストするマルチコンテナー エンドポイントを構築して、あるリクエスト セットから別のリクエスト セットへのイメージ生成のノイズを除去することを検討できます。 このユースケースでは、レイテンシーとスループットを優先し、ユーザーの需要に対応するには、コンピューティングのコストとワークロードの分離がトレードオフになります。
FM ホスティング オプションの選択にフィットネス機能を適用する
このセクションでは、大規模な SageMaker FM で適切な FM ホスティング オプションを選択する際に、前述のフィットネス関数を適用する方法を示します。
SageMaker 単一モデルのエンドポイント
SageMaker 単一モデルのエンドポイントを使用すると、専用インスタンスでホストされるコンテナ上で XNUMX つの FM をホストできるため、低レイテンシーと高スループットが実現します。 これらのエンドポイントは完全に管理されており、自動スケーリングをサポートしています。 単一モデルのエンドポイントを、インスタンスのタイプや数などのエンドポイント インフラストラクチャ構成を渡すプロビジョニングされたエンドポイントとして構成できます。SageMaker は、コンピューティング リソースを自動的に起動し、自動スケーリング ポリシーに応じてそれらをスケールインおよびスケールアウトします。 複数の単一モデルのエンドポイントを使用して数百のモデルをホストするように拡張でき、 セルベースのアーキテクチャ 弾力性が向上し、爆発半径が減少します。
プロビジョニングされた単一モデルのエンドポイントのフィットネス関数を評価する場合は、次の点を考慮してください。
- 基礎モデルのサイズ – これは、単一の ML アクセラレータのメモリに収まらないモデルがあり、インスタンス内に複数のアクセラレータが必要な場合に適しています。
- パフォーマンスと FM 推論レイテンシ – これは、遅延が重要な生成 AI アプリケーションに関連します。
- ワークロードの分離 – アプリケーションに必要な場合があります アマゾン エラスティック コンピューティング クラウド (Amazon EC2) セキュリティコンプライアンスの理由によるインスタンスレベルの分離。 各 FM は個別の推論エンドポイントを取得し、EC2 インスタンスを他のモデルと共有しません。 たとえば、ネットワーク分離を備えた専用のセキュリティ グループ構成を使用して、HIPAA 関連のモデル推論ワークロード (PHI 検出モデルなど) を別のエンドポイントに分離できます。 GPU ベースのモデル推論ワークロードを、p2dn などの Nitro ベースの EC4 インスタンスに基づく他のワークロードから分離して、信頼性の低いワークロードから分離できます。 Nitro System ベースの EC2 インスタンスは、仮想化と分離に対する独自のアプローチを提供し、機密データの処理を AWS オペレーターやソフトウェアから常に保護し、分離することができます。 それは最も重要な次元を提供します 機密コンピューティング システム ソフトウェアとクラウド オペレーターからのデフォルトの固有の保護セットとして。 このオプションは、サードパーティのモデルプロバイダーが提供する AWS Marketplace モデルの SageMaker へのデプロイもサポートしています。
SageMakerマルチモデルエンドポイント
セージメーカー マルチモデル エンドポイント (MME) を使用すると、GPU コアで複数のモデルを共同ホストしたり、複数のモデル間でエンドポイントの背後にある GPU インスタンスを共有したり、受信トラフィックに基づいてモデルを動的にロードおよびアンロードしたりできます。 これにより、コストを大幅に節約し、最高のコストパフォーマンスを実現できます。
インスタンス上の単一の ML アクセラレータにすべて収まる小規模なモデルをホストする必要がある場合は、MME が最適な選択肢です。 この戦略は、インスタンス内の共有コンテナーを通じて提供でき、同じサイズ (パラメーター数が 1 億未満) のモデルが多数 (最大数千) あり、すべてのモデルにアクセスする必要がない場合に検討する必要があります。同時。 使用する必要があるモデルをロードし、それを別のモデル用にアンロードできます。
MME は、共有コンテナを使用して複数のモデルをロードするため、同じ ML フレームワークを使用するモデルを共同ホストするように設計されています。 したがって、モデル フリートに ML フレームワーク (PyTorch や TensorFlow など) が混在している場合は、SageMaker エンドポイント InferenceComponents
の方が良い選択です。 話し合います InferenceComponents
詳細はこの投稿で後ほど説明します。
最後に、MME は、頻繁に呼び出されるモデルを優先して、使用頻度の低いモデルをオフロードできるため、時折のコールド スタート遅延ペナルティを許容できるアプリケーションに適しています。 アクセス頻度の低いモデルのロングテールがある場合、マルチモデル エンドポイントはこのトラフィックを効率的に処理し、大幅なコスト削減を可能にします。
MME をいつ使用するかを評価するときは、次の点を考慮してください。
- 基礎モデルのサイズ – インスタンス上の単一の ML アクセラレータの HBM に適合するモデルがあるため、複数のアクセラレータは必要ない場合があります。
- パフォーマンスと FM 推論レイテンシ – モデルが要求されてもメモリにない場合でも、コールド スタートのレイテンシーを許容できる生成 AI アプリケーションがある場合があります。
- ワークロードの分離 – すべてのモデルが同じコンテナを共有することを検討してください。
- スケーラビリティ – 次の点を考慮してください。
- 複数のモデルを XNUMX つのエンドポイントにパックし、モデルおよび ML インスタンスごとに拡張できます。
- ワークロード パターンに基づいてインスタンス レベルの自動スケーリングを有効にすることができます。
- MME は、エンドポイントごとに数千のモデルへの拡張をサポートします。 モデルごとの自動スケーリングとデプロイメント構成を維持する必要はありません。
- 推論リクエストによってモデルがリクエストされたときはいつでも、ホット デプロイメントを使用できます。
- 推論リクエストに従ってモデルを動的にロードしたり、メモリ不足に応じてアンロードしたりできます。
- 基礎となるリソースをモデルと時間を共有できます。
- コスト効率 – モデルの動的なロードとアンロードによってモデル間でリソースを時間を共有し、コストを節約することを検討します。
InferenceComponents を使用した SageMaker 推論エンドポイント
新しい SageMaker 推論エンドポイント InferenceComponents
は、単一のエンドポイントで複数の FM をホストし、モデルごとにスケーリングするためのスケーラブルなアプローチを提供します。 リソース (アクセラレーター、メモリ、CPU) を割り当て、モデルごとに自動スケーリング ポリシーを設定するためのきめ細かい制御を提供して、保証されたスループットと予測可能なパフォーマンスを実現します。また、複数のモデルにわたるコンピューティングの使用率を個別に管理できます。 ホストする必要があるさまざまなサイズとトラフィック パターンのモデルが多数あり、モデルのサイズにより単一のアクセラレータのメモリに収まらない場合、これが最適なオプションです。 また、コストを節約するためにゼロにスケールすることもできますが、アプリケーションのレイテンシー要件は、モデルのコールド スタート時間を考慮できる十分な柔軟性を備えている必要があります。 このオプションを使用すると、顧客または FM ごとのコンテナー レベルの分離が十分である限り、コンピューティングを最大限に柔軟に利用できます。 新しい SageMaker エンドポイントの詳細については、 InferenceComponents
、詳細な投稿を参照してください Amazon SageMaker の最新機能を使用して、モデルのデプロイメントコストを平均 50% 削減します.
エンドポイントをどのような場合に使用するかを決定するときは、次の点を考慮してください。 InferenceComponents
:
- 基礎モデルのサイズ – これは、単一の ML アクセラレータのメモリに収まらないため、インスタンス内に複数のアクセラレータが必要なモデルに適しています。
- パフォーマンスと FM 推論レイテンシ – これは、遅延が重要な生成 AI アプリケーションに適しています。
- ワークロードの分離 – コンテナーレベルの分離で十分なアプリケーションがある場合があります。
- スケーラビリティ – 次の点を考慮してください。
- 複数の FM を XNUMX つのエンドポイントにパックし、モデルごとに拡張できます。
- ワークロード パターンに基づいて、インスタンス レベルおよびモデル コンテナ レベルのスケーリングを有効にすることができます。
- この方法では、エンドポイントあたり数百の FM へのスケーリングがサポートされます。 モデルまたはコンテナーごとに自動スケーリング ポリシーを構成する必要はありません。
- フリート内のモデルの初期配置と不十分なアクセラレータの処理をサポートします。
- コスト効率 – トラフィックがない場合は、コストを節約するためにモデルごとにゼロにスケールできます。
同じエンドポイントに複数の FM をパッキング: モデルのグループ化
SageMaker でどのような推論アーキテクチャ戦略を採用するかは、アプリケーションの優先順位と要件によって異なります。 一部の SaaS プロバイダーは、厳格な分離要件を課す規制された環境に販売しています。これらのプロバイダーは、一部またはすべての FM に専用モデルでデプロイするオプションを提供できるオプションを必要としています。 しかし、コストを最適化し、スケールメリットを得るには、SaaS プロバイダーは、SageMaker リソースの共有セット全体で複数の FM をホストするマルチテナント環境も必要です。 おそらくほとんどの組織は、SageMaker アーキテクチャの一部として単一モデルのエンドポイントとマルチモデルまたはマルチコンテナのエンドポイントの両方を備えたハイブリッド ホスティング環境を持っているでしょう。
この分散推論環境を構築するときに実行する必要がある重要な作業は、アーキテクチャのタイプごとにモデルをグループ化することであり、SageMaker エンドポイントで設定する必要があります。 最初に決定する必要があるのは、ワークロードの分離要件に関するものです。セキュリティ上の理由、爆発半径や騒音の多い隣人のリスクの軽減、会議の目的など、独自の専用エンドポイントに存在する必要がある FM を分離する必要があります。遅延に対する厳格な SLA。
次に、FM が単一の ML アクセラレータに適合するか、複数のアクセラレータが必要か、モデルのサイズ、トラフィック パターンを判断する必要があります。 中央機能をサポートするために集合的に機能する同様のサイズのモデルは、エンドポイント上で複数のモデルを共同ホストすることによって論理的にグループ化できます。これは、これらのモデルが中央チームによって管理される単一のビジネス アプリケーションの一部となるためです。 同じエンドポイントで複数のモデルを共同ホストする場合、グループ化の作業を実行して、どのモデルが単一のインスタンス、単一のコンテナー、または複数のコンテナーに配置できるかを決定する必要があります。
MME のモデルのグループ化
MME は、小規模なモデル (単一のアクセラレータに収まるパラメーターが 1 億未満) に最適で、サイズと呼び出しレイテンシが同様です。 モデル サイズの多少の変動は許容されます。 例えば、 Zendeskの モデルの範囲は 10 ~ 50 MB で、これは問題なく機能しますが、10 倍、50 倍、または 100 倍のサイズの変動は適切ではありません。 モデルが大きいと、十分なメモリ領域を収容するために小さいモデルのロードとアンロードの回数が増加する可能性があり、その結果、エンドポイントでの遅延が増加する可能性があります。 大規模なモデルのパフォーマンス特性の違いにより、CPU などのリソースが不均一に消費される可能性があり、インスタンス上の他のモデルに影響を与える可能性があります。
MME 上でグループ化されるモデルには、推論のためにモデル間でコンピューティングを共有できるように、時差のあるトラフィック パターンが必要です。 アクセス パターンと推論レイテンシでは、モデルを切り替える際のコールド スタート時間を考慮する必要もあります。
MME のモデルをグループ化するための推奨基準の一部を次に示します。
- 小型モデル – パラメータが 1 億未満のモデルを使用する
- モデルサイズ – 同様のサイズのモデルをグループ化し、同じエンドポイントで共同ホストする
- 呼び出しレイテンシー – コールド スタートを許容できる、同様の呼び出しレイテンシ要件を持つグループ モデル
- Hardware – 同じ基礎となる EC2 インスタンス タイプを使用してモデルをグループ化する
InferenceComponents を使用したエンドポイントのモデルのグループ化
SageMaker エンドポイント InferenceComponents
EC1 インスタンス内で複数の ML アクセラレータまたはデバイスを必要とする、大規模な FM (2 億を超えるパラメータ) を大規模にホストするのに最適です。 このオプションは、コンテナー レベルの分離で十分な遅延の影響を受けやすいワークロードやアプリケーションに適しています。 以下は、複数のエンドポイントのモデルをグループ化するための推奨基準の一部です。 InferenceComponents
:
- Hardware – 同じ基礎となる EC2 インスタンス タイプを使用してモデルをグループ化する
- モデルサイズ – モデルのサイズに基づいてモデルをグループ化することが推奨されますが、必須ではありません
まとめ
この投稿では、XNUMX つのリアルタイム ML 推論オプション (単一エンドポイント、マルチモデル エンドポイント、および InferenceComponents
) SageMaker で、コスト効率よく大規模な FM を効率的にホストします。 XNUMX つのフィットネス関数を使用すると、大規模な FM に適切な SageMaker ホスティング オプションを選択できます。 推奨されるグループ化基準を使用して、FM をグループ化し、SageMaker 推論エンドポイントで共同ホストします。 説明したフィットネス機能に加えて、次の表を使用して、どの共有 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、BYOC (MME 契約あり) | SageMaker 事前構築済み、SageMaker 互換の BYOC |
ルーティングオプション | ランダムまたは最小限の接続 | ランダム、人気ウィンドウに固執 | ランダムまたは最小限の接続 |
モデルに対するハードウェアの割り当て | 単一モデル専用 | 共有 | 各コンテナ専用 |
サポートされているモデルの数 | 単発講座 | 数千 | 何百 |
応答ストリーミング | サポート | サポートされていません | サポート |
データ収集 | サポート | サポートされていません | サポートされていません |
シャドーテスト | サポート | サポートされていません | サポートされていません |
複数のバリアント | サポート | 適用されない | サポートされていません |
AWSマーケットプレイスモデル | サポート | 適用されない | サポートされていません |
著者について
メヘラン・ナジャフィ博士、 大規模な AI/ML および SaaS ソリューションに焦点を当てた AWS のシニア ソリューション アーキテクトです。
ダワル・パテル AWSのプリンシパル機械学習アーキテクトです。 彼は、分散コンピューティングや人工知能に関連する問題について、大企業から中規模の新興企業に至るまでの組織と協力してきました。 彼は、NLPおよびコンピュータービジョンドメインを含むディープラーニングに焦点を当てています。 彼は、顧客がSageMakerで高性能モデルの推論を実現するのを支援します。
リエラ・デヘスス は AWS のプリンシパル ソリューション アーキテクトであり、ワシントン DC、メリーランド州、バージニア州地域のさまざまな企業顧客のクラウドへの移行を支援してきました。 顧客擁護者および技術アドバイザーとして、彼女は Heroku/Salesforce などの組織が AWS プラットフォームで成功を収められるよう支援しています。 彼女は IT 業界の女性の熱烈な支持者であり、テクノロジーとデータを創造的に使用して日常の課題を解決する方法を見つけることに非常に情熱を持っています。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
- プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
- プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
- 情報源: https://aws.amazon.com/blogs/machine-learning/scale-foundation-model-inference-to-hundreds-of-models-with-amazon-sagemaker-part-1/
- :持っている
- :は
- :not
- :どこ
- $UP
- 1
- 10
- 100
- 11
- 25
- 50
- 7
- a
- 能力
- できる
- 私たちについて
- 加速
- 加速器
- 加速器
- ことができます。
- アクセス
- アクセス
- アクセス
- 対応する
- 精度
- 達成する
- 達成する
- 越えて
- 追加されました
- 添加
- 逆に
- 顧問
- 支持者
- 影響を及ぼす
- 影響
- エージェント
- AI
- AIモデル
- aiのユースケース
- AI / ML
- アルゴリズム
- すべて
- 割り当てる
- 配分
- 許す
- ことができます
- また
- 常に
- Amazon
- Amazon EC2
- アマゾンセージメーカー
- Amazon Webサービス
- 金額
- an
- および
- 毎年恒例の
- 別の
- 回答
- 人間原理
- どれか
- 申し込み
- 申し込む
- アプローチ
- 適切な
- 建築家
- 建築
- です
- AREA
- 周りに
- 人工の
- 人工知能
- AS
- 評価する
- 評価中
- 評価
- 確実な
- At
- 増強された
- オート
- 自動的に
- 自動化する
- 自治
- 利用できます
- 平均
- AWS
- AWSインフェレンティア
- AWS Marketplace
- 帯域幅
- ベース
- ベース
- 基礎
- BE
- なぜなら
- になる
- 背後に
- さ
- BEST
- より良いです
- の間に
- 10億
- 億
- ブースト
- 借り入れ
- 両言語で
- 境界
- 持って来る
- ビルド
- 建物
- ビジネス
- ビジネス プロセス
- ビジネス
- 焙煎が極度に未発達や過発達のコーヒーにて、クロロゲン酸の味わいへの影響は強くなり、金属を思わせる味わいと乾いたマウスフィールを感じさせます。
- by
- 計算された
- 呼ばれます
- 缶
- 容量
- 場合
- 例
- 原因となる
- 中央の
- 課題
- 挑戦
- 変化する
- 特性
- チャート
- チャットボット
- チャットボット
- チェック
- チップ
- 選択
- 選択肢
- 選択する
- 選択する
- 閉じる
- クラウド
- 共催
- コード
- 造られた
- 冷たい
- 同僚
- 集団
- 集合的に
- 組み合わせた
- comes
- コミュニケーション
- 企業
- 会社の
- 互換性のあります
- 複雑さ
- 複雑さ
- コンプライアンス
- コンポーネント
- 計算
- 計算的
- 計算能力
- 計算
- コンピュータ
- Computer Vision
- コンピューティング
- コンピューティングパワー
- コンセプト
- 秘密
- 設定された
- 検討
- 見なさ
- 考えると
- 消費する
- 消費
- コンテナ
- コンテナ
- コンテンツ
- コンテキスト
- コントロール
- 会話
- 基本
- 費用
- コスト削減
- コスト効率の良い
- コスト
- 可能性
- 結合しました
- 作ります
- 基準
- 重大な
- 顧客
- 顧客データ
- 顧客サービス
- カスタマーサービス
- Customers
- カスタマイズ
- サイクル
- データ
- データ処理
- データベース
- 中
- dc
- 決めます
- 決定
- 意思決定
- 決定
- デコード
- 専用の
- 深いです
- 深い学習
- 定義済みの
- 配信する
- 需要
- 需要
- 民主化
- によっては
- 依存
- 展開します
- 展開
- 展開する
- 展開
- 配備
- 指定された
- 設計
- 希望
- 詳細な
- 細部
- 検出
- 決定する
- 決定する
- 決定
- デバイス
- Devices
- の違い
- 異なります
- 難しさ
- 次元
- 大きさ
- 話し合います
- 議論する
- ディスプレイ
- 配布
- 分散コンピューティング
- 異なる
- ドメイン
- ドント
- ドロー
- 原因
- 間に
- ダイナミック
- 動的に
- 各
- 簡単に
- 経済
- 規模の経済
- 効果的な
- 効率的な
- 効率良く
- どちら
- enable
- 可能
- 有効にする
- エンドポイント
- 従事する
- 婚約
- エンジン
- エンジニア
- 高めます
- 十分な
- 確保
- 確保する
- Enterprise
- 企業
- 環境
- 環境
- 特に
- 評価します
- さらに
- イベント
- あらゆる
- 日常
- すべてのもの
- 進化
- 進化する
- 例
- 超えます
- 例外
- 交換した
- 運動
- 期待する
- 体験
- 実験
- 専門知識
- 探る
- エクステント
- 外部
- 要因
- 要因
- スピーディー
- 賛成
- 特徴
- より少ない
- ファイナル
- もう完成させ、ワークスペースに掲示しましたか?
- 発見
- 終わり
- 名
- フィット
- フィットネス
- 五
- 艦隊
- 柔軟性
- フレキシブル
- 焦点を当て
- 焦点を当てて
- フォロー中
- 次
- フォード
- Foundation
- フレームワーク
- フレームワーク
- 頻繁に
- から
- フル
- 完全に
- function
- 機能
- 利得
- 一般に
- 生成する
- 生成
- 世代
- 生々しい
- 生成AI
- 取得する
- GitHubの
- 与えられた
- 与える
- 目標
- GPU
- GPU
- グラフ
- 大きい
- 大いに
- グループ
- ガイダンス
- ガイド
- ハンドリング
- Hardware
- 持ってる
- 持って
- he
- ヘビー
- 重いもの
- 助けます
- 助けました
- ことができます
- それゆえ
- ハイ
- より高い
- 非常に
- 彼の
- 歴史的
- history
- host
- 主催
- ホスティング
- HOT
- HOURS
- 認定条件
- How To
- HTTP
- HTTPS
- 何百
- ハイブリッド
- if
- 説明する
- 画像
- 計り知れない
- 影響
- 影響
- 重要
- 課す
- in
- 含ま
- 含めて
- 入ってくる
- Incorporated
- 増加した
- 増加
- 個別に
- インフラ関連事業
- 初期
- 統合する
- 整合性
- インテル
- 知的
- 知的財産
- インテリジェンス
- インテリジェント-
- 内部
- に
- 本質的な
- 紹介します
- 呼び出された
- 巻き込む
- 関係する
- IP
- 分離
- IT
- リーディングシート
- JPG
- 知識
- 言語
- 大
- 大企業
- より大きい
- レイテンシ
- 後で
- 最新の
- 起動
- 学習
- 最低
- 長さ
- less
- レベル
- 図書館
- フェイスリフト
- ような
- 限定的
- 制限
- LINE
- ライン
- ラマ
- 負荷
- ローディング
- 負荷
- 論理的に
- 長い
- 見
- 探して
- たくさん
- ロー
- 下側
- 機械
- 機械学習
- 製
- 維持する
- 保守
- make
- 管理します
- マネージド
- 管理
- 管理する
- 方法
- 多くの
- マーケティング
- 市場
- メリーランド
- 大規模な
- 五月..
- 手段
- ご相談
- メモリ
- 方法
- メトリック
- かもしれない
- 最小化
- ミックス
- ML
- モデル
- モニタリング
- 他には?
- 最も
- マルチ
- マルチモデル エンドポイント
- の試合に
- 多数
- しなければなりません
- 必要
- 必要
- 必要
- ニーズ
- 隣人
- ネットワーク
- 新作
- 次の
- Nitro
- NLP
- いいえ
- 数
- Nvidia
- 客観
- 目的
- 入手する
- 時折
- of
- 提供
- オファー
- 頻繁に
- on
- ONE
- 操作する
- 動作
- オペレーティング
- オペレーショナル
- 業務執行統括
- 演算子
- 最適な
- 最適化
- 最適化
- オプション
- オプション
- or
- 注文
- 組織
- 組織
- その他
- その他
- 私たちの
- でる
- 出力
- outputs
- が
- 全体
- 自分の
- 所有権
- パック
- ページ
- 並列シミュレーションの設定
- パラメータ
- 部
- パートナー
- パス
- 情熱的な
- パターン
- 五角形
- 以下のために
- 実行する
- パフォーマンス
- 実行
- 期間
- 期間
- カスタマイズ
- 視点
- 博士号
- パイロット
- 配置
- 計画されました
- プラットフォーム
- プラットフォーム
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- ポリシー
- 方針
- 人気
- 部分
- ポスト
- :
- 電力
- 予測可能な
- 圧力
- 流行している
- 予防
- 校長
- 優先順位をつける
- 優先順位
- 多分
- 問題
- プロセス
- 処理
- 財産
- 提案する
- 保護
- 提供します
- 提供
- プロバイダ
- は、大阪で
- 提供
- 目的
- パイトーチ
- 質問と回答
- クイック
- レーダー
- 範囲
- 測距
- リアル
- への
- 現実
- 実現
- 理由は
- 推奨される
- 減らします
- 電話代などの費用を削減
- 縮小
- 参照する
- 指し
- 反映
- 規制
- レギュレータ
- 関連する
- 相対的に
- 関連した
- 残っている
- レンダリングされた
- 表す
- 要求
- リクエスト
- 必要とする
- の提出が必要です
- 要件
- 必要
- リソースを追加する。
- リソース
- 応答
- 反応する
- 結果
- 結果として
- 結果
- 右
- 厳しい
- リスク
- リスク管理
- ラン
- ランタイム
- SaaSの
- 犠牲にする
- セージメーカー
- SageMaker の推論
- 給与
- セールス
- 同じ
- Save
- 貯蓄
- ド電源のデ
- 規模
- 秤
- スケーリング
- シナリオ
- スケジュール
- 科学者たち
- スクラッチ
- を検索
- 二番
- セクション
- 安全に
- セキュリティ
- 選択
- 販売
- シニア
- 敏感な
- 別
- 役立つ
- サービス
- サービス
- サービング
- セッションに
- いくつかの
- 形状
- シャーディング
- シェアする
- shared
- シェアリング
- 彼女
- すべき
- 表示する
- 作品
- 側面
- 重要
- 著しく
- 同様の
- 同時に
- 座る
- 状況
- サイズ
- 大きさの
- サイズ
- 遅く
- より小さい
- So
- ソフトウェア
- サービスとしてのソフトウェア
- 溶液
- ソリューション
- 解決する
- 一部
- 時々
- スペース
- 専門の
- 特定の
- 特に
- 指定の
- スピード
- スピン
- 安定した
- 規格
- start
- スタートアップ
- スティッキー
- ストレージ利用料
- 戦略
- 厳格な
- かなりの
- 成功
- 首尾よく
- そのような
- 十分な
- 適当
- サポート
- サポーター
- サポート
- スイッチ
- テーブル
- テーラード
- 取る
- 仕事
- タスク
- チーム
- チーム
- 技術的
- テクノロジー
- 十
- テンソルフロー
- test
- 클라우드 기반 AI/ML및 고성능 컴퓨팅을 통한 디지털 트윈의 기초 – Edward Hsu, Rescale CPO 많은 엔지니어링 중심 기업에게 클라우드는 R&D디지털 전환의 첫 단계일 뿐입니다. 클라우드 자원을 활용해 엔지니어링 팀의 제약을 해결하는 단계를 넘어, 시뮬레이션 운영을 통합하고 최적화하며, 궁극적으로는 모델 기반의 협업과 의사 결정을 지원하여 신제품을 결정할 때 데이터 기반 엔지니어링을 적용하고자 합니다. Rescale은 이러한 혁신을 돕기 위해 컴퓨팅 추천 엔진, 통합 데이터 패브릭, 메타데이터 관리 등을 개발하고 있습니다. 이번 자리를 빌려 비즈니스 경쟁력 제고를 위한 디지털 트윈 및 디지털 스레드 전략 개발 방법에 대한 인사이트를 나누고자 합니다.
- より
- それ
- アプリ環境に合わせて
- それら
- その後
- そこ。
- したがって、
- ボーマン
- 彼ら
- サードパーティ
- この
- 考え
- 数千
- 三
- 介して
- スループット
- 時間
- <font style="vertical-align: inherit;">回数</font>
- 〜へ
- 一緒に
- ツール
- トータル
- に向かって
- トラフィック
- トレーニング
- 最適化の適用
- トランスフォーマー
- トリトン
- 信頼されている
- チューニング
- type
- 一般的に
- 無許可
- 根本的な
- わかる
- 理解する
- ユニーク
- つかいます
- 使用事例
- 中古
- ユーザー
- 通常
- 活用する
- 活用
- 値
- 価値観
- さまざまな
- 変化する
- 非常に
- 詳しく見る
- バージニア州
- ビジョン
- 訪問
- 欲しいです
- ました
- 方法
- we
- ウェブ
- Webサービス
- 重量
- WELL
- この試験は
- 何ですか
- いつ
- たびに
- かどうか
- which
- while
- 誰
- 意志
- 喜んで
- 以内
- 無し
- レディース
- 仕事
- 働いていました
- ワークフロー
- 作品
- 世界
- でしょう
- You
- あなたの
- ゼファーネット
- ゼロ
- ゾーン