機械学習 (ML) アプリケーションはデプロイが複雑で、多くの場合、ハイパースケール機能が必要であり、超低レイテンシーの要件と厳しいコスト予算が必要です。 不正行為の検出、製品の推奨、トラフィックの予測などのユース ケースは、ミリ秒が重要であり、ビジネスの成功にとって重要な例です。 厳格なサービス レベル アグリーメント (SLA) を満たす必要があり、通常の要求では、前処理、データ変換、機能エンジニアリング、モデル選択ロジック、モデル集約、後処理などの複数の手順が必要になる場合があります。
最適化されたコストとコンピューティング効率で ML モデルを大規模にデプロイすることは、困難で面倒な作業になる可能性があります。 各モデルには、外部データ ソースや、基盤となるコンピューティング リソースの CPU/GPU パワーなどのランタイム環境に基づいて、独自のメリットと依存関係があります。 アプリケーションは、単一の推論リクエストを処理するために複数の ML モデルを必要とする場合があります。 特定のシナリオでは、リクエストが複数のモデルにまたがって流れる場合があります。 万能のアプローチはありません。ML の実践者は、繰り返される ML ホスティングの課題に対処するための実証済みの方法を探すことが重要です。 これにより、ML モデル ホスティングの設計パターンが進化しました。
この投稿では、ML アプリケーションを構築するための一般的な設計パターンについて説明します。 アマゾンセージメーカー.
ML アプリケーションを構築するための設計パターン
ML アプリケーションのホスティングに使用する次の設計パターンを見てみましょう。
単一モデル ベースの ML アプリケーション
これは、ML ユースケースでリクエストを処理するために単一のモデルが必要な場合に最適なオプションです。 このモデルは、入力トラフィックに基づいてスケーリングできる専用のコンピューティング インフラストラクチャにデプロイされます。 このオプションは、クライアント アプリケーションに低レイテンシ (ミリ秒または秒単位) の推論要件がある場合にも理想的です。
マルチモデル ベースの ML アプリケーション
ホスティングの費用対効果を高めるために、この設計パターンを使用すると、同じテナント インフラストラクチャで複数のモデルをホストできます。 複数の ML モデルがホストまたはコンテナーのリソースを共有できます。これには、最も使用される ML モデルをメモリにキャッシュすることが含まれ、メモリとコンピューティング リソースの使用率が向上します。 デプロイすることを選択したモデルのタイプに応じて、モデルの共同ホスティングでは次の方法を使用できます。
- マルチモデル ホスティング – このオプションを使用すると、単一のエンドポイントで共有サービス コンテナーを使用して複数のモデルをホストできます。 この機能は、共有サービング コンテナーを介して提供できる類似のモデルが多数あり、すべてのモデルに同時にアクセスする必要がない場合に最適です。
- マルチコンテナ ホスティング – このオプションは、複数のモデルが異なるサービス スタック上で同様のリソース ニーズで実行されている場合、および個々のモデルにエンドポイント インスタンスの全容量を利用するための十分なトラフィックがない場合に最適です。 マルチコンテナ ホスティングを使用すると、異なるモデルまたはフレームワークを使用する複数のコンテナを XNUMX つのエンドポイントにデプロイできます。 モデルは、独自の独立したサービング スタックを使用して、完全に異種混合にすることができます。
- モデル アンサンブル – 多くの運用ユースケースでは、特定のダウンストリーム モデルに入力を供給する多くのアップストリーム モデルが存在することがよくあります。 ここでアンサンブルが役に立ちます。 アンサンブル パターンでは、XNUMX つまたは複数の基本モデルからの出力を混合して、 一般化エラー 予測の。 基本モデルは多様で、さまざまなアルゴリズムでトレーニングできます。 アンサンブル アプローチを使用すると、モデルの予測誤差が減少するため、モデル アンサンブルは単一モデルよりも優れたパフォーマンスを発揮できます。
以下は、アンサンブル パターンとそれに対応する設計パターン図の一般的なユース ケースです。
- スキャターギャザー – スキャッター ギャザー パターンでは、推論のリクエストが多数のモデルにルーティングされます。 次に、アグリゲーターを使用して応答を収集し、単一の推論応答に抽出します。 たとえば、画像分類のユース ケースでは、タスクを実行するために XNUMX つの異なるモデルを使用する場合があります。 スキャッター ギャザー パターンを使用すると、XNUMX つの異なるモデルで実行された推論の結果を組み合わせて、最も可能性の高い分類モデルを選択できます。
- モデル集計 – 集計パターンでは、複数のモデルからの出力が平均化されます。 分類モデルの場合、複数のモデルの予測が評価されて、最も多くの票を獲得したクラスが決定され、アンサンブルの最終出力として扱われます。 たとえば、一連の果物をオレンジまたはリンゴに分類する XNUMX クラスの分類問題で、XNUMX つのモデルがオレンジに投票し、XNUMX つのモデルがリンゴに投票した場合、集約された出力はオレンジになります。 集計は、個々のモデルの不正確さに対処し、出力をより正確にするのに役立ちます。
- 動的選択 – アンサンブル モデルのもう XNUMX つのパターンは、指定された入力属性に対してモデル選択を動的に実行することです。 たとえば、果物の画像の特定の入力で、入力にオレンジが含まれている場合、モデル A はオレンジに特化しているため、使用されます。 入力にリンゴが含まれる場合、モデル B はリンゴに特化しているため使用されます。
- シリアル推論 ML アプリケーション – 推論パイプラインとも呼ばれるシリアル推論パターンでは、ユースケースには、推論を生成するために事前トレーニング済みの ML モデルを呼び出す前に、受信データを前処理する要件があります。 さらに、場合によっては、生成された推論をさらに処理して、下流のアプリケーションで簡単に使用できるようにする必要があります。 推論パイプラインを使用すると、モデルのトレーニング中に使用したものと同じ前処理コードを再利用して、予測に使用される推論リクエスト データを処理できます。
- ビジネスの論理 – ML の製品化には、常にビジネス ロジックが関係します。 ビジネス ロジック パターンには、ML モデルの推論ではない ML タスクを実行するために必要なすべてが含まれます。 これには、モデルのロードが含まれます。 Amazon シンプル ストレージ サービス (Amazon S3)、たとえば、入力を検証するためのデータベース ルックアップ、フィーチャ ストアから事前に計算されたフィーチャの取得など。 これらのビジネス ロジックの手順が完了すると、入力が ML モデルに渡されます。
ML 推論オプション
モデルのデプロイでは、ユース ケースからさかのぼって作業することが重要です。 予測の頻度は? アプリケーションへのライブ トラフィックと、クライアントへのリアルタイムの応答を期待していますか? 同じユース ケースのデータの異なるサブセット用にトレーニングされた多くのモデルがありますか? 予測トラフィックは変動しますか? 推論のレイテンシーは懸念事項ですか? これらの詳細に基づいて、次の展開オプションを使用して、前述のすべての設計パターンを実装できます。
- リアルタイム推論 – リアルタイム推論は、リアルタイム、インタラクティブ、低レイテンシーの要件がある推論ワークロードに最適です。 リアルタイム ML 推論ワークロードには、アプリケーションが XNUMX つの要求を処理するために XNUMX つの ML モデルのみを必要とする単一モデル ベースの ML アプリケーション、またはアプリケーションが単一の要求を処理するために複数の ML モデルを必要とするマルチモデル ベースの ML アプリケーションが含まれる場合があります。リクエスト。
- ほぼリアルタイム (非同期) の推論 – ほぼリアルタイムの推論により、着信要求をキューに入れることができます。 これは、数百 MB の入力に対して推論を実行するために利用できます。 これはほぼリアルタイムで動作し、ユーザーは推論のために入力を使用し、エンドポイントからの出力を S3 バケットから読み取ることができます。 NLP やコンピューター ビジョンを使用する場合、前処理に長い時間が必要な大きなペイロードがある場合に特に便利です。
- バッチ推論 – バッチ推論は、大規模なデータセットで推論をオフラインで実行するために利用できます。 オフラインで実行されるため、バッチ推論は最小のレイテンシーを提供しません。 ここで、推論リクエストは、バッチ推論ジョブのスケジュールされたトリガーまたはイベントベースのトリガーで処理されます。
- サーバーレス推論 – サーバーレス推論は、トラフィックの急増の間にアイドル期間があり、アイドル期間後の最初の呼び出しで数秒の余分な待ち時間 (コールド スタート) を許容できるワークロードに最適です。 たとえば、フォームを処理したり、ドキュメントのデータを分析したりするためのチャットボット サービスまたはアプリケーションです。 この場合、推論リクエストの量に基づいて計算能力を自動的にプロビジョニングおよびスケーリングできるオンライン推論オプションが必要になる場合があります。 また、アイドル時間中は、計算能力を完全にオフにして、料金が発生しないようにする必要があります. サーバーレス推論は、コンピューティング リソースを自動的に起動し、トラフィックに応じてそれらをスケールインおよびスケールアウトすることにより、サーバーの選択と管理という未分化の重労働を取り除きます。
フィットネス関数を使用して適切な ML 推論オプションを選択する
アプリケーションによってレンダリングされるエンドユーザーに影響を与えるため、適切なホスティング オプションを決定することは重要です。 この目的のために、次の概念を借りています。 フィットネス機能、Neal Ford と AWS パートナーの ThoughtWorks の彼の同僚が彼らの仕事で造語したものです。 進化的アーキテクチャの構築. フィットネス機能は、顧客の目的に基づいて、さまざまなホスティング オプションの規範的な評価を提供します。 フィットネス関数は、アーキテクチャの計画的な進化を可能にするために必要なデータを取得するのに役立ちます。 測定可能な値を設定して、設定した目標の達成にソリューションがどれだけ近づいているかを評価します。 フィットネス機能は、アーキテクチャが進化して望ましい変更プロセスを導くように適応させることができ、また適応させる必要があります。 これにより、チームの自律性を維持しながらチームを導くツールがアーキテクトに提供されます。
ML モデルとアプリケーションをホストするための適切な ML 推論オプションを選択する際に、顧客が気にする主なフィットネス関数は XNUMX つあります。
適応度関数 | Description |
費用 |
スケーラブルなフレームワークに ML モデルと ML アプリケーションをデプロイして維持することは重要なビジネス プロセスであり、モデル ホスティング インフラストラクチャ、ホスティング オプション、ML フレームワーク、ML モデルの特性、最適化、スケーリング ポリシー、もっと。 コストを抑えるために、ワークロードはハードウェア インフラストラクチャを最適に利用する必要があります。 このフィットネス関数は、全体的な総所有コスト (TCO) の一部であるインフラストラクチャ コストを具体的に指します。 インフラストラクチャ コストは、ストレージ、ネットワーク、およびコンピューティングの合計コストです。 運用コスト、セキュリティおよびコンプライアンス コストなど、TCO の他の要素を理解することも重要です。 運用コストは、ML インフラストラクチャの運用、監視、および維持の合計コストです。 運用コストは、各シナリオに基づいて必要なエンジニアの数とエンジニアの年間給与を特定の期間にわたって集計して計算されます。 セルフマネージド ML ソリューションを使用しているお客様 アマゾン エラスティック コンピューティング クラウド (Amazon EC2)、 Amazon エラスティック コンテナ サービス (Amazon ECS)、および Amazon Elastic Kubernetesサービス (Amazon EKS) は運用ツール自体を構築する必要があります。 SageMaker を使用しているお客様は、TCO を大幅に削減できます。 SageMaker 推論はフルマネージド サービスであり、推論用の ML モデルをデプロイするためのすぐに使用できる機能を提供します。 インスタンスのプロビジョニング、インスタンスの正常性の監視、セキュリティ更新やパッチの管理、運用指標の発行、ML 推論ワークロードの監視の構築を行う必要はありません。 高可用性と回復力を確保する機能が組み込まれています。 SageMaker は、ルートボリュームの暗号化や Amazon Elastic Blockストア (Amazon EBS) ボリューム、 アマゾン バーチャル プライベート クラウド (Amazon VPC) サポート、 AWS プライベートリンク、カスタマー マネージド キー、 AWS IDおよびアクセス管理 (IAM) きめ細かなアクセス制御、 AWS クラウドトレイル 監査、トレーニング用のノード間暗号化、タグベースのアクセス制御、ネットワーク分離、インタラクティブ アプリケーション プロキシ。 これらのセキュリティ機能はすべて、SageMaker ですぐに使用できるため、企業は 3 年間で数十か月の開発作業を節約できます。 SageMaker は HIPAA 対応サービスであり、PCI、SOC、GDPR、および ISO の下で認定されています。 SageMaker は FIPS エンドポイントもサポートしています。 TCO の詳細については、次を参照してください。 Amazon SageMaker の総所有コスト. |
推論のレイテンシ | 多くの ML モデルとアプリケーションはレイテンシー クリティカルであり、推論のレイテンシーはサービス レベル目標によって指定された範囲内に収まる必要があります。 推論のレイテンシーは、モデルのサイズと複雑さ、ハードウェア プラットフォーム、ソフトウェア環境、ネットワーク アーキテクチャなど、さまざまな要因に依存します。 たとえば、大規模で複雑なモデルは、推論の実行に時間がかかる場合があります。 |
スループット (XNUMX 秒あたりのトランザクション数) | モデルの推論では、ML アプリケーションのパフォーマンス チューニングとビジネス目標の達成のために、スループットを最適化することが重要です。 チップ設計における数学演算の低レベルの実装を含む、ML のすべての側面で急速に進歩し続けるにつれて、ハードウェア固有のライブラリはパフォーマンスの最適化においてより大きな役割を果たします。 ペイロード サイズ、ネットワーク ホップ、ホップの性質、モデル グラフ機能、モデル内の演算子、インスタンスをホストするモデルの CPU、GPU、メモリ プロファイルなど、さまざまな要因が ML モデルのスループットに影響します。 |
スケーリング構成の複雑さ | ML モデルまたはアプリケーションが、さまざまなトラフィックの需要を処理できるスケーラブルなフレームワークで実行されることが重要です。 また、CPU および GPU リソースを最大限に利用できるようにし、コンピューティング リソースの過剰なプロビジョニングを防ぎます。 |
予想されるトラフィック パターン | ML モデルまたはアプリケーションには、継続的なリアルタイムのライブ トラフィックから、XNUMX 秒あたり数千のリクエストの定期的なピーク、まれな予測不可能なリクエスト パターンから大規模なデータセットでのオフライン バッチ リクエストまで、さまざまなトラフィック パターンがあります。 ML モデルに適したホスティング オプションを選択するには、予想されるトラフィック パターンから逆算することをお勧めします。 |
SageMaker を使用したモデルのデプロイ
セージメーカー は、すべての開発者とデータ サイエンティストに大規模な ML モデルを迅速に構築、トレーニング、デプロイする機能を提供する、完全マネージド型の AWS サービスです。 SageMaker 推論を使用すると、ML モデルをホストされたエンドポイントにデプロイして、推論結果を取得できます。 SageMaker は、ワークロードの要件を満たす幅広いハードウェアと機能を提供し、ハードウェア アクセラレーションを備えた 70 を超えるインスタンス タイプを選択できます。 SageMaker は、ワークロードに最適なものがわからない場合に備えて、SageMaker Inference Recommender と呼ばれる新機能を使用して、推論インスタンス タイプの推奨を提供することもできます。
リアルタイム推論、非同期、バッチ、さらにはサーバーレス エンドポイントなど、ユース ケースに最適なデプロイ オプションを選択できます。 さらに、SageMaker は、カナリア、 青/緑, 影、およびモデル展開の A/B テストに加えて、マルチモデル、マルチコンテナー エンドポイント、およびエラスティック スケーリングを使用した費用対効果の高い展開。 SageMaker 推論を使用すると、エンドポイントのパフォーマンスメトリクスを アマゾンクラウドウォッチ, エンドポイントを自動的にスケーリングする トラフィックに基づいて、可用性を失うことなく本番環境でモデルを更新します。
SageMaker には、モデルをデプロイするための XNUMX つのオプションが用意されているため、予測を開始できます。
- リアルタイム推論 – これは、ミリ秒のレイテンシ要件、最大 6 MB のペイロード サイズ、および最大 60 秒の処理時間を持つワークロードに適しています。
- バッチ変換 – これは、事前に利用可能な大量のデータ バッチに対するオフライン予測に最適です。
- 非同期推論 – これは、1 秒未満のレイテンシ要件、最大 15 GB のペイロード サイズ、および最大 XNUMX 分の処理時間のないワークロード向けに設計されています。
- サーバーレス推論 – サーバーレス推論を使用すると、基盤となるインフラストラクチャを構成または管理する必要なく、推論用の ML モデルをすばやくデプロイできます。 さらに、断続的なワークロードに最適な、推論リクエストの処理に使用されるコンピューティング容量に対してのみ料金が発生します。
次の図は、SageMaker ホスティング モデルのデプロイ オプションと、関連するフィットネス関数の評価を理解するのに役立ちます。
各展開オプションについて詳しく見ていきましょう。
SageMaker でのリアルタイム推論
SageMaker リアルタイム推論は、トラフィックが持続していて、最大 6 MB のペイロードサイズと最大 60 秒の処理時間で、リクエストに対してより低く一貫したレイテンシーが必要な場合に推奨されます。 モデルを SageMaker ホスティング サービスにデプロイし、推論に使用できるエンドポイントを取得します。 これらのエンドポイントは完全に管理されており、自動スケーリングをサポートしています。 リアルタイム推論は、製品やサービスのパーソナライズされたレコメンデーションやトランザクションの不正検出のユース ケースなど、予測可能なトラフィック パターンで低レイテンシの同期応答が期待されるユース ケースでよく使用されます。
通常、クライアントアプリケーションはリクエストを SageMaker HTTPS エンドポイントに送信して、デプロイされたモデルから推論を取得します。 モデルの複数のバリアントを同じ SageMaker HTTPS エンドポイントにデプロイできます。 これは、本番環境でモデルのバリエーションをテストする場合に役立ちます。 Auto Scaling を使用すると、ワークロードの変化に応じて、モデル用にプロビジョニングされたインスタンスの数を動的に調整できます。
次の表は、フィットネス関数に基づいて SageMaker リアルタイム推論を評価するためのガイダンスを提供します。
適応度関数 | Description |
費用 |
リアルタイム エンドポイントは、推論リクエストに対する同期応答を提供します。 エンドポイントは常に実行されており、リアルタイムの同期推論応答を提供するために利用できるため、インスタンスの使用に対して料金が発生します。 複数のエンドポイントを展開すると、特にエンドポイントが基盤となるインスタンスを十分に活用していない場合、コストが急速に増加する可能性があります。 モデルに適したインスタンスを選択することで、モデルに最もパフォーマンスの高いインスタンスを最小のコストで確保できます。 可能な限り低いコストで安定した予測可能なパフォーマンスを維持するために、トラフィックに応じて容量を動的に調整するには、自動スケーリングをお勧めします。 SageMaker は、Graviton2 および Graviton3 ベースの ML インスタンスファミリーへのアクセスを拡張します。 AWS グラビトン プロセッサは、64 ビットの Arm Neoverse コアを使用してアマゾン ウェブ サービスによってカスタム構築され、Amazon EC2 で実行されるクラウド ワークロードに最高の価格パフォーマンスを提供します。 Graviton ベースのインスタンスを使用すると、ML モデルを SageMaker にデプロイする際のコストとパフォーマンスを最適化するためのオプションが増えます。 SageMaker もサポート Inf1インスタンス、高性能で費用対効果の高い ML 推論を提供します。 1 ~ 16 で AWS Inferentia チップ インスタンスごとに、Inf1 インスタンスはパフォーマンスをスケールインし、AWS GPU ベースのインスタンスと比較して、最大 50 倍のスループットと最大 1% 低い推論あたりのコストを実現できます。 SageMaker で InfXNUMX インスタンスを使用するには、以下を使用してトレーニング済みモデルをコンパイルできます。 Amazon SageMaker ネオ Inf1 インスタンスを選択して、コンパイル済みモデルを SageMaker にデプロイします。 探索することもできます SageMaker の Savings Plans オンデマンド価格と比較して最大 64% のコスト削減の恩恵を受けることができます。 エンドポイントを作成すると、SageMaker はエンドポイントをホストする各 ML コンピューティング インスタンスに EBS ストレージ ボリュームをアタッチします。 ストレージ ボリュームのサイズは、インスタンス タイプによって異なります。 リアルタイム エンドポイントの追加コストには、プロビジョニングされたストレージの月間 GB のコストに加えて、エンドポイント インスタンスで処理される GB データと処理される GB データが含まれます。 |
推論のレイテンシ | リアルタイムの推論は、ミリ秒のレイテンシ要件を持つ永続的なエンドポイントが必要な場合に最適です。 最大 6 MB のペイロード サイズと最大 60 秒の処理時間をサポートします。 |
スループット |
推論スループットの理想値は、モデル、モデルの入力サイズ、バッチ サイズ、エンドポイント インスタンス タイプなどの要因に左右されます。 ベスト プラクティスとして、入力リクエストとリソース使用率の CloudWatch メトリクスを確認し、適切なインスタンス タイプを選択して最適なスループットを実現します。 ビジネス アプリケーションは、スループットを最適化するか、レイテンシを最適化することができます。 たとえば、動的バッチ処理は、リアルタイムの推論を使用して、レイテンシーの影響を受けやすいアプリのスループットを向上させるのに役立ちます。 ただし、バッチ サイズには制限があり、それがなければ推論のレイテンシーに影響を与える可能性があります。 スループットを向上させるためにバッチ サイズを大きくすると、推論のレイテンシが大きくなります。 したがって、リアルタイム推論は、レイテンシーの影響を受けやすいアプリケーションにとって理想的なオプションです。 SageMaker は、非同期推論とバッチ変換のオプションを提供します。これらは、ビジネス アプリケーションがわずかに高いレイテンシーを許容できる場合に、リアルタイム推論と比較してスループットが高くなるように最適化されています。 |
スケーリング構成の複雑さ |
SageMaker リアルタイム エンドポイントのサポート 自動スケーリング 箱から出して。 ワークロードが増加すると、Auto Scaling によってより多くのインスタンスがオンラインになります。 ワークロードが減少すると、Auto Scaling によって不要なインスタンスが削除されるため、コンピューティング コストの削減に役立ちます。 Auto Scaling を使用しない場合は、ピーク トラフィックに備えてプロビジョニングするか、モデルが使用できないリスクを負う必要があります。 モデルへのトラフィックが XNUMX 日を通して安定していない限り、余分な未使用の容量が発生します。 これにより、使用率が低下し、リソースが浪費されます。 SageMaker を使用すると、予想されるトラフィック パターンに基づいてさまざまなスケーリング オプションを設定できます。 特定の CloudWatch メトリクスに基づいてスケーリングする場合は、単純なスケーリングまたはターゲット追跡スケーリングが理想的です。 これを行うには、特定のメトリックを選択し、しきい値を設定します。 このオプションの推奨指標は平均です 高度な構成が必要な場合は、ステップ スケーリング ポリシーを設定して、アラーム違反のサイズに基づいてスケーリングするインスタンスの数を動的に調整できます。 これは、需要が特定のレベルに達したときに、より積極的な応答を構成するのに役立ちます。 日、週、月、または年の特定のスケジュールに従って需要が発生することがわかっている場合は、スケジュールされたスケーリング オプションを使用できます。 これにより、XNUMX 回限りのスケジュール、定期的なスケジュール、または cron 式を、開始時刻と終了時刻とともに指定することができます。これにより、Auto Scaling アクションの開始と停止の境界が形成されます。 詳細については、 Amazon SageMaker で自動スケーリング推論エンドポイントを設定する および 自動スケーリングを使用して負荷テストを行い、Amazon SageMaker エンドポイントを最適化する. |
交通パターン | リアルタイムの推論は、継続的または定期的なトラフィック パターンを持つワークロードに最適です。 |
SageMaker での非同期推論
SageMaker 非同期推論は、着信リクエストをキューに入れ、非同期的に処理する SageMaker の新しい機能です。 このオプションは、大きなペイロード サイズ (最大 1 GB)、長い処理時間 (最大 15 分)、およびほぼリアルタイムのレイテンシ要件を持つ要求に最適です。 非同期推論のワークロードの例には、異常を検出するために高解像度の生物医学画像や心エコー図などのビデオを処理するヘルスケア企業が含まれます。 これらのアプリケーションは、3 日のさまざまな時間に着信トラフィックのバーストを受信し、低コストでほぼリアルタイムの処理を必要とします。 これらのリクエストの処理時間は数分程度になる可能性があるため、リアルタイムの推論を実行する必要はありません。 代わりに、自動キューイングと事前定義された同時実行しきい値を使用して、Amazon S3 などのオブジェクト ストアから入力ペイロードを非同期的に処理できます。 処理時に、SageMaker は以前に返された Amazon SXNUMX の場所に推論レスポンスを配置します。 必要に応じて、成功またはエラーの通知を受け取るように選択できます。 Amazon シンプル通知サービス (AmazonSNS)。
次の表は、フィットネス関数に基づいて SageMaker 非同期推論を評価するためのガイダンスを提供します。
適応度関数 | Description |
費用 | 非同期推論は、大きなペイロードとバースト トラフィックを伴うコスト重視のワークロードに最適です。 非同期推論を使用すると、処理するリクエストがないときにインスタンス数をゼロに自動スケーリングすることでコストを節約できるため、エンドポイントがリクエストを処理しているときにのみ料金が発生します。 インスタンスがゼロのときに受信したリクエストは、エンドポイントのスケールアップ後に処理のためにキューに入れられます。 |
推論のレイテンシ | 非同期推論は、ほぼリアルタイムのレイテンシ要件に最適です。 リクエストはキューに入れられ、コンピューティングが利用可能になるとすぐに処理されます。 これにより、通常、数十ミリ秒のレイテンシが発生します。 |
スループット | 非同期推論は、アプリケーションがスループットを犠牲にする必要がないため、レイテンシの影響を受けにくいユースケースに最適です。 非同期推論エンドポイントはリクエストをドロップするのではなく、キューに入れるため、トラフィックのスパイク中にリクエストがドロップされることはありません。 |
スケーリング構成の複雑さ |
SageMaker のサポート 自動スケーリング 非同期エンドポイント用。 リアルタイムでホストされるエンドポイントとは異なり、非同期推論エンドポイントは、最小容量をゼロに設定することにより、インスタンスをゼロにスケールダウンすることをサポートします。 非同期エンドポイントの場合、SageMaker は、デプロイされたモデル (バリアント) のターゲット追跡スケーリング用のポリシー設定を作成することを強くお勧めします。 数分間のコールド スタート ペナルティを許容できるユース ケースでは、オプションで、未処理のリクエストがないときにエンドポイント インスタンス数をゼロにスケールダウンし、新しいリクエストが到着したときにスケールアップして、エンドポイントはアクティブにリクエストを処理しています。 |
交通パターン | 非同期エンドポイントは、着信要求をキューに入れ、非同期的に処理します。 これらは、断続的またはまれなトラフィック パターンに適したオプションです。 |
SageMaker でのバッチ推論
SageMaker バッチ変換は、事前に利用可能な大量のデータ バッチのオフライン予測に最適です。 バッチ変換機能は、データを変換して推論を生成するための高性能で高スループットの方法です。 これは、大量のデータ バッチを処理するシナリオ、XNUMX 秒未満のレイテンシーを必要としないシナリオ、またはトレーニング データの前処理と変換の両方が必要なシナリオに最適です。 広告、マーケティング、ヘルスケアなどの特定のドメインのお客様は、多くの場合、高スループットがユース ケースの目的であり、待機時間が問題にならないハイパースケール データセットでオフライン予測を行う必要があります。
バッチ変換ジョブが開始されると、SageMaker はコンピューティング インスタンスを初期化し、それらの間で推論ワークロードを分散します。 ジョブが完了するとリソースが解放されるため、ジョブの実行中に使用された分だけ料金が発生します。 ジョブが完了すると、SageMaker は指定した S3 バケットに予測結果を保存します。 通常、バッチ推論タスクは、水平方向のスケーリングに適しています。 クラスター内の各ワーカーは、他のワーカーと情報を交換する必要なく、データの異なるサブセットを操作できます。 AWS は、水平スケーリングを可能にする複数のストレージおよびコンピューティング オプションを提供します。 SageMaker バッチ変換のワークロードの例には、オフライン ジョブを定期的に実行するようにスケジュールできる、顧客離れを予測するためのバンキング アプリケーションなどのオフライン アプリケーションが含まれます。
次の表は、フィットネス関数に基づいて SageMaker バッチ変換を評価するためのガイダンスを提供します。
適応度関数 | Description |
費用 | SageMaker バッチ変換を使用すると、大小のバッチ データセットで予測を実行できます。 使用期間に基づいて、選択したインスタンス タイプに対して課金されます。 SageMaker は、ジョブの開始時にリソースのプロビジョニングを管理し、ジョブが完了するとそれらを解放します。 追加のデータ処理コストはありません。 |
推論のレイテンシ | イベントベースまたはスケジュールされた呼び出しを使用できます。 レイテンシーは、推論データのサイズ、ジョブの同時実行数、モデルの複雑さ、コンピューティング インスタンスの容量によって異なる場合があります。 |
スループット |
バッチ変換ジョブは、ペタバイトのデータから非常に小さなデータセットまで、さまざまなデータセットに対して実行できます。 大きなデータセットを小さなデータのチャンクにサイズ変更する必要はありません。 次のようなパラメーターに最適な値を使用することで、バッチ変換ジョブを高速化できます。 最大ペイロードMB, MaxConcurrentTransformsまたは バッチ戦略. の理想値 バッチ処理は、待ち時間を犠牲にして一定時間内により多くの推論を完了するのに役立つため、スループットを向上させ、リソースを最適化できます。 モデルのデプロイを最適化してスループットを向上させるための一般的なガイドラインは、スループットが低下するまでバッチ サイズを大きくすることです。 |
スケーリング構成の複雑さ | SageMaker バッチ変換は、レイテンシーの影響を受けないオフライン推論に使用されます。 |
交通パターン | オフライン推論の場合、バッチ変換ジョブは、イベント ベースのトリガーを使用してスケジュールまたは開始されます。 |
SageMaker でのサーバーレス推論
SageMaker サーバーレス推論を使用すると、基盤となるインフラストラクチャを構成または管理することなく、推論用の ML モデルをデプロイできます。 モデルが受け取る推論リクエストの量に基づいて、SageMaker サーバーレス推論はコンピューティング能力を自動的にプロビジョニング、スケーリング、オフにします。 その結果、アイドル時間ではなく、推論コードを実行するための計算時間と処理されたデータの量に対してのみ料金が発生します。 SageMaker の組み込みアルゴリズムと ML フレームワークを提供するコンテナーを使用して、モデルをサーバーレス推論エンドポイントにデプロイするか、独自のコンテナーを使用することを選択できます。 トラフィックが予測可能で安定した場合、コンテナ イメージを変更することなく、サーバーレスの推論エンドポイントから SageMaker リアルタイム エンドポイントに簡単に更新できます。 サーバーレス推論では、呼び出し回数、障害、レイテンシー、ホストメトリクス、CloudWatch のエラーなどの組み込みメトリクスを含む、他の SageMaker 機能も利用できます。
次の表は、フィットネス関数に基づいて SageMaker サーバーレス推論を評価するためのガイダンスを提供します。
適応度関数 | Description |
費用 | 従量制モデルでは、トラフィック パターンがまれまたは断続的である場合、サーバーレス推論は費用対効果の高いオプションです。 エンドポイントが要求を処理する期間に対してのみ料金が発生するため、トラフィック パターンが断続的である場合はコストを節約できます。 |
推論のレイテンシ |
サーバーレス エンドポイントは、低い推論レイテンシ (ミリ秒から秒単位) を提供し、使用パターンに基づいて数秒以内に数万から数千の推論を即座にスケーリングできるため、断続的または予測不可能なトラフィックを伴う ML アプリケーションに最適です。 サーバーレス エンドポイントはオンデマンドでコンピューティング リソースをプロビジョニングするため、エンドポイントでは、アイドル期間後の最初の呼び出しで数秒の余分な待機時間 (コールド スタート) が発生する場合があります。 コールド スタート時間は、モデルのサイズ、モデルのダウンロードにかかる時間、コンテナーの起動時間によって異なります。 |
スループット | サーバーレス エンドポイントを構成するときに、メモリ サイズと同時呼び出しの最大数を指定できます。 SageMaker サーバーレス推論は、選択したメモリに比例してコンピューティング リソースを自動的に割り当てます。 より大きなメモリ サイズを選択すると、コンテナはより多くの vCPU にアクセスできます。 原則として、メモリ サイズは少なくともモデル サイズと同じ大きさにする必要があります。 選択できるメモリ サイズは、1024 MB、2048 MB、3072 MB、4096 MB、5120 MB、および 6144 MB です。 選択したメモリ サイズに関係なく、サーバーレス エンドポイントでは 5 GB のエフェメラル ディスク ストレージを利用できます。 |
スケーリング構成の複雑さ | サーバーレス エンドポイントは、コンピューティング リソースを自動的に起動し、トラフィックに応じてスケールインおよびスケールアウトするため、インスタンス タイプを選択したり、スケーリング ポリシーを管理したりする必要がなくなります。 これにより、サーバーの選択と管理という差別化されていない重労働が取り除かれます。 |
交通パターン | サーバーレス推論は、トラフィック パターンがまれまたは断続的なワークロードに最適です。 |
SageMaker でのモデルホスティング設計パターン
SageMaker 推論エンドポイントは、ML モデルをホストするために Docker コンテナを使用します。 コンテナーを使用すると、Docker をサポートするすべてのプラットフォームで一貫して実行される標準化されたユニットにソフトウェアをパッケージ化できます。 これにより、プラットフォーム間での移植性、不変のインフラストラクチャの展開、および変更管理と CI/CD の実装が容易になります。 SageMaker は、Apache MXNet、TensorFlow、PyTorch、Sklearn、Hugging Face などの一般的なフレームワーク用のビルド済みマネージド コンテナを提供します。 利用可能な SageMaker コンテナ イメージの完全なリストについては、次を参照してください。 利用可能なディープラーニングコンテナの画像. SageMaker にサポートされているコンテナーがない場合は、独自のコンテナー (BYOC) を構築し、独自のカスタム イメージをプッシュして、モデルに必要な依存関係をインストールすることもできます。
モデルを SageMaker にデプロイするには、コンテナー (SageMaker マネージド フレームワーク コンテナーまたは BYOC) と、コンテナーをホストするコンピューティング インスタンスが必要です。 SageMaker は、モデルを単一のコンテナでホストしたり、共有コンテナで共同ホストしたりできる一般的な ML モデル ホスティング デザイン パターンの複数の高度なオプションをサポートしています。
リアルタイム ML アプリケーションでは、単一のモデルまたは複数のモデルを使用して、単一の予測リクエストを処理できます。 次の図は、ML アプリケーションのさまざまな推論シナリオを示しています。
前述の各推論シナリオに適した SageMaker ホスティング オプションを調べてみましょう。 フィットネス関数を参照して、特定のユース ケースに適したオプションであるかどうかを評価できます。
単一モデル ベースの ML アプリケーションのホスティング
デプロイシナリオに応じて、SageMaker ホスティングサービスを使用して単一モデルベースの ML アプリケーションをホストするオプションがいくつかあります。
単一モデルのエンドポイント
SageMaker 単一モデル エンドポイントを使用すると、専用インスタンスでホストされているコンテナで XNUMX つのモデルをホストして、低レイテンシーと高スループットを実現できます。 これらのエンドポイントは完全に管理されており、自動スケーリングをサポートしています。 単一モデルのエンドポイントを、インスタンスのタイプや数などのエンドポイント インフラストラクチャ構成を渡すプロビジョニング済みエンドポイントとして構成するか、SageMaker がコンピューティング リソースを自動的に起動し、トラフィックに応じてスケールインおよびスケールアウトするサーバーレス エンドポイントとして構成することができます。インスタンス タイプを選択するか、スケーリング ポリシーを管理します。 サーバーレス エンドポイントは、トラフィックが断続的または予測不能なアプリケーション向けです。
次の図は、単一モデルのエンドポイントの推論シナリオを示しています。
次の表は、プロビジョニングされた単一モデル エンドポイントの適合度関数を評価するためのガイダンスを示しています。 サーバーレス エンドポイントのフィットネス関数の評価については、この投稿のサーバーレス エンドポイントのセクションを参照してください。
適応度関数 | Description |
費用 | 選択したインスタンス タイプの使用に対して課金されます。 エンドポイントは常に実行され、利用可能であるため、コストがすぐに加算される可能性があります。 モデルに適したインスタンスを選択することで、モデルに最もパフォーマンスの高いインスタンスを最小のコストで確保できます。 可能な限り低いコストで安定した予測可能なパフォーマンスを維持するために、トラフィックに応じて容量を動的に調整するには、自動スケーリングをお勧めします。 |
推論のレイテンシ | 単一モデルのエンドポイントは、ミリ秒のレイテンシー要件を備えたリアルタイムのインタラクティブな同期推論を提供します。 |
スループット | スループットは、モデルの入力サイズ、バッチ サイズ、エンドポイント インスタンス タイプなど、さまざまな要因の影響を受ける可能性があります。 入力リクエストとリソース使用率について CloudWatch メトリクスを確認し、最適なスループットを達成するために適切なインスタンス タイプを選択することをお勧めします。 SageMaker は、リソースを管理し、ML モデルをデプロイする際の推論パフォーマンスを最適化する機能を提供します。 あなたはできる Neo を使用してモデルのパフォーマンスを最適化する、または Inf1 インスタンスを使用して、エンドポイントに GPU インスタンスを使用して SageMaker がホストするモデルのスループットを向上させます。 |
スケーリング構成の複雑さ | 自動スケーリングはすぐにサポートされます。 SageMaker は、適切な スケーリング構成 実行することによって 負荷テスト. |
交通パターン | 単一モデルのエンドポイントは、トラフィック パターンが予測可能なワークロードに最適です。 |
複数のモデルの共同ホスティング
多数のモデルを扱っている場合、専用のコンテナーとインスタンスを使用して個々のエンドポイントに各モデルをデプロイすると、コストが大幅に増加する可能性があります。 さらに、特に、すべてのモデルを同時に呼び出す必要はないが、常に使用できるようにする必要がある場合、本番環境で非常に多くのモデルを管理することも困難になります。 基盤となる同じコンピューティング リソースで複数のモデルを共同ホストすると、大規模な ML 展開の管理が容易になり、エンドポイントとその基盤となるコンピューティング リソースの使用量が増えるため、ホスティング コストが削減されます。 SageMaker は、同種モデル用のマルチモデル エンドポイント (MME) や異種モデル用のマルチコンテナ エンドポイント (MCE) などの高度なモデル共同ホスティング オプションをサポートしています。 同種モデルは共有サービス コンテナーで同じ ML フレームワークを使用しますが、異種モデルでは、単一のエンドポイントで異なるモデルまたはフレームワークを使用する複数のサービス コンテナーをデプロイできます。
次の図は、SageMaker を使用したモデルの共同ホスティング オプションを示しています。
SageMakerマルチモデルエンドポイント
セージメーカー MME 単一のエンドポイントで共有サービス コンテナーを使用して複数のモデルをホストできます。 これは、同じユース ケース、フレームワーク、または推論ロジックに対応する多数のモデルを展開するための、スケーラブルで費用対効果の高いソリューションです。 MME は、呼び出し元によって呼び出されたモデルに基づいて、要求を動的に処理できます。 また、SageMaker がメモリへのモデルのロードと、モデルへのトラフィック パターンに基づいたスケーリングを管理するため、デプロイのオーバーヘッドも削減されます。 この機能は、共有サービング コンテナーを介して提供できる類似のモデルが多数あり、すべてのモデルに同時にアクセスする必要がない場合に最適です。 マルチモデル エンドポイントは、モデル間でのメモリ リソースのタイム シェアリングも可能にします。 これは、モデルのサイズと呼び出しレイテンシがほぼ同じである場合に最適に機能し、MME がすべてのモデルでインスタンスを効果的に使用できるようにします。 SageMaker MME は、CPU と GPU でバックアップされたモデルの両方のホスティングをサポートしています。 GPU でサポートされたモデルを使用することで、エンドポイントとその基盤となる高速化されたコンピューティング インスタンスの使用を増やすことで、モデルのデプロイ コストを削減できます。 MME の実際の使用例については、次を参照してください。 マルチテナントSaaSユースケースの機械学習推論をスケーリングする方法.
次の表は、MME の適合度関数の評価に関するガイダンスを提供します。
適応度関数 | Description |
費用 |
MME を使用すると、共有サービス コンテナーを使用して、単一のエンドポイントで数千のモデルをホストできます。 これにより、単一モデルのエンドポイントを使用する場合と比較してエンドポイントの使用率が向上し、ホスティング コストが大幅に削減されます。 たとえば、ml.c10.large インスタンスを使用してデプロイするモデルが 5 個ある場合、 SageMaker の料金、単一モデルの永続エンドポイントを 10 個持つコストは、10 * $0.102 = 1.02 時間あたり $XNUMX です。 一方、10 モデルをホストする 10 つの MME を使用すると、1 倍のコスト削減を達成できます: 0.102 * 0.102 ドル = XNUMX 時間あたり XNUMX ドル。 |
推論のレイテンシ |
デフォルトでは、MME は頻繁に使用されるモデルをメモリとディスクにキャッシュして、低レイテンシの推論を提供します。 キャッシュされたモデルは、新しく対象となるモデルに対応するためにコンテナーがメモリまたはディスク領域を使い果たした場合にのみ、ディスクからアンロードまたは削除されます。 MME では、モデルの遅延読み込みが可能です。つまり、モデルが初めて呼び出されたときにメモリに読み込まれます。 これにより、メモリ使用率が最適化されます。 ただし、最初のロードで応答時間のスパイクが発生し、コールド スタートの問題が発生します。 したがって、MME は、使用頻度の低いモデルを呼び出すときに発生するコールド スタート関連のレイテンシ ペナルティを許容できるシナリオにも適しています。 ML アプリケーションのレイテンシとスループットの目標を達成するには、GPU インスタンスが CPU インスタンスよりも優先されます (GPU が提供する計算能力を考えると)。 GPU の MME サポートにより、XNUMX つの SageMaker エンドポイントの背後に何千もの深層学習モデルをデプロイできます。 MME は、GPU コアで複数のモデルを実行し、複数のモデルにわたってエンドポイントの背後で GPU インスタンスを共有し、着信トラフィックに基づいてモデルを動的にロードおよびアンロードできます。 これにより、コストを大幅に削減し、最高のコストパフォーマンスを実現できます。 ユース ケースで XNUMX 秒あたりのトランザクション数 (TPS) またはレイテンシの要件が非常に高くなる場合は、専用のエンドポイントでモデルをホストすることをお勧めします。 |
スループット |
MME 推論スループットの理想値は、モデル、ペイロード サイズ、エンドポイント インスタンス タイプなどの要因によって異なります。 インスタンス メモリの量が多いほど、より多くのモデルをロードして、推論リクエストを処理する準備を整えることができます。 モデルのロードに時間を費やす必要はありません。 vCPU の量が多いほど、より多くの固有のモデルを同時に呼び出すことができます。 MME は、モデルをインスタンス メモリとの間で動的にロードおよびアンロードします。これは、I/O パフォーマンスに影響を与える可能性があります。 GPU を搭載した SageMaker MME は、 NVIDIATriton推論サーバーは、推論提供プロセスを簡素化し、高い推論パフォーマンスを提供するオープンソースの推論提供ソフトウェアです。 SageMaker は、モデルを GPU アクセラレーション インスタンス上の NVIDIA Triton コンテナのメモリにロードし、推論リクエストを処理します。 GPU コアは、インスタンス内のすべてのモデルで共有されます。 モデルがコンテナメモリにすでにロードされている場合、SageMaker はモデルを再度ダウンロードしてロードする必要がないため、後続のリクエストはより高速に処理されます。 本番環境への導入を成功させるには、適切なパフォーマンス テストと分析を行うことをお勧めします。 SageMaker はマルチモデル エンドポイントの CloudWatch メトリクスを提供するため、エンドポイントの使用状況とキャッシュ ヒット率を判断して、エンドポイントの最適化に役立てることができます。 |
スケーリング構成の複雑さ | SageMaker マルチモデル エンドポイントは、自動スケーリングを完全にサポートします。これは、モデルのレプリカを管理して、トラフィック パターンに基づいてモデルが確実にスケーリングされるようにします。 ただし、エンドポイントを自動スケーリングするためのインスタンスの最適なサイズを決定するために、適切な負荷テストを行うことをお勧めします。 あまりにも多くのモデルがアンロードされないようにするには、MME フリートのサイズを適切に設定することが重要です。 いくつかの大きなインスタンスに数百のモデルをロードすると、場合によってはスロットルが発生する可能性があり、より多くの小さなインスタンスを使用することが推奨される場合があります。 SageMaker で自動化されたモデルのスケーリングを利用するには、次のことを確認してください。 インスタンスの自動スケーリングの設定 追加のインスタンス容量をプロビジョニングします。 カスタム パラメーターまたは XNUMX 分あたりの呼び出し (推奨) を使用してエンドポイント レベルのスケーリング ポリシーを設定し、エンドポイント フリートにインスタンスを追加します。 自動スケール イベントをトリガーするために使用される呼び出し率は、エンドポイントによって提供されるモデルの完全なセットにわたる予測の集計セットに基づいています。 |
交通パターン | MME は、共有サービング コンテナーを介して提供でき、同時にすべてのモデルにアクセスする必要がない、同じサイズのモデルが多数ある場合に最適です。 |
SageMaker マルチコンテナエンドポイント
セージメーカー MCE 単一のエンドポイントで異なるモデルまたはフレームワークを使用する最大 15 個のコンテナーのデプロイをサポートし、それらを個別にまたは順番に呼び出して、低レイテンシーの推論とコスト削減を実現します。 モデルは、独自の独立したサービング スタックを使用して、完全に異種混合にすることができます。 90 つのインスタンスで異なるフレームワークから複数のモデルを安全にホストすることで、コストを最大 XNUMX% 節約できます。
MCE 呼び出しパターンは次のとおりです。
- 推論パイプライン – MME 内のコンテナは、線形シーケンスで呼び出すことができます。 シリアル推論パイプライン. これらは通常、前処理、モデル推論、および後処理を独立したコンテナーに分離するために使用されます。 現在のコンテナからの出力は、次のコンテナへの入力として渡されます。 それらは、SageMaker では単一のパイプライン モデルとして表されます。 推論パイプラインは MME としてデプロイできます。この場合、パイプライン内のコンテナーの XNUMX つが、呼び出されるモデルに基づいて動的に要求を処理できます。
- 直接呼び出し –と 直接呼び出し、MCE でホストされている特定の推論コンテナーに要求を送信できます。
次の表は、MCE の適合度関数の評価に関するガイダンスを示しています。
適応度関数 | Description |
費用 | MCE を使用すると、15 つのエンドポイントで最大 XNUMX 個の異なる ML コンテナーを実行し、それらを個別に呼び出すことができるため、コストを節約できます。 このオプションは、似たようなリソース ニーズを持つ異なるサービス スタックで複数のモデルを実行している場合、および個々のモデルにエンドポイント インスタンスの全容量を利用するための十分なトラフィックがない場合に最適です。 したがって、MCE は単一モデルのエンドポイントよりも費用対効果が高くなります。 MCE は同期推論応答を提供します。つまり、エンドポイントは常に利用可能であり、インスタンスの稼働時間に対して料金が発生します。 インスタンスの数とタイプに応じて、コストが加算される場合があります。 |
推論のレイテンシ | MCE は、アクセス頻度は低いものの、低レイテンシーの推論が必要なモデルごとに異なる ML フレームワークとアルゴリズムを使用して ML アプリを実行する場合に最適です。 モデルは常に低レイテンシーの推論に使用でき、コールド スタートの問題はありません。 |
スループット | MCE はマルチコンテナー エンドポイントで最大 15 個のコンテナーに制限されており、リソースの競合のため GPU 推論はサポートされていません。 直接呼び出しモードを使用するマルチコンテナ エンドポイントの場合、SageMaker は他の一般的なエンドポイントと同様にインスタンス レベルのメトリクスを提供するだけでなく、コンテナごとのメトリクスもサポートします。 ベスト プラクティスとして、入力リクエストとリソース使用率の CloudWatch メトリクスを確認し、適切なインスタンス タイプを選択して最適なスループットを実現します。 |
スケーリング構成の複雑さ | MCE は自動スケーリングをサポートしています。 ただし、自動スケーリングを構成するには、各コンテナー内のモデルが各推論要求で同様の CPU 使用率とレイテンシーを示すことをお勧めします。 これが推奨されるのは、マルチコンテナー エンドポイントへのトラフィックが CPU 使用率の低いモデルから CPU 使用率の高いモデルに移行しても、全体的な呼び出し量が同じままである場合、エンドポイントはスケールアウトせず、十分なインスタンスが存在しない可能性があるためです。高 CPU 使用率モデルへのすべての要求を処理します。 |
交通パターン | MCE は、エンドポイント インスタンスの全容量を飽和させるのに十分なトラフィックがない可能性があるさまざまなフレームワーク (TensorFlow、PyTorch、Sklearn など) でモデルをホストするために、継続的または定期的なトラフィック パターンを持つワークロードに最適です。 |
マルチモデル ベースの ML アプリケーションのホスティング
多くのビジネス アプリケーションでは、複数の ML モデルを使用して、XNUMX つの予測リクエストをコンシューマーに提供する必要があります。 たとえば、ユーザーにレコメンデーションを提供したい小売会社です。 このユース ケースの ML アプリケーションでは、さまざまなカテゴリの製品を推奨するために、さまざまなカスタム モデルを使用する必要がある場合があります。 企業が個々のユーザー情報を使用してレコメンデーションにパーソナライズを追加したい場合、カスタム モデルの数はさらに増加します。 各カスタム モデルを個別のコンピューティング インスタンスでホストすることは、法外なコストがかかるだけでなく、すべてのモデルが頻繁に使用されるわけではない場合、ホスティング リソースが十分に活用されないことにつながります。 SageMaker は、マルチモデル ベースの ML アプリケーションに効率的なホスティング オプションを提供します。
次の図は、SageMaker を使用した単一エンドポイントのマルチモデル ホスティング オプションを示しています。
シリアル推論パイプライン
推論パイプラインは、データに対する推論のリクエストを処理する 2 ~ 15 個のコンテナの線形シーケンスで構成される SageMaker モデルです。 推論パイプラインを使用して、事前トレーニング済みの SageMaker 組み込みアルゴリズムと、Docker コンテナーにパッケージ化された独自のカスタム アルゴリズムの任意の組み合わせを定義してデプロイします。 推論パイプラインを使用して、前処理、予測、後処理のデータ サイエンス タスクを組み合わせることができます。 XNUMX つのコンテナーからの出力は、次のコンテナーへの入力として渡されます。 パイプライン モデルのコンテナーを定義するときは、コンテナーが実行される順序も指定します。 それらは、SageMaker では単一のパイプライン モデルとして表されます。 推論パイプラインは MME としてデプロイでき、パイプライン内のコンテナーの XNUMX つが、呼び出されるモデルに基づいて動的に要求を処理できます。 実行することもできます バッチ変換 推論パイプラインを使用するジョブ。 推論パイプラインは完全に管理されています。
次の表は、シリアル推論パイプラインを使用して ML モデル ホスティングの適合度関数を評価するためのガイダンスを示しています。
適応度関数 | Description |
費用 | シリアル推論パイプラインを使用すると、15 つのエンドポイントで最大 XNUMX 個の異なる ML コンテナーを実行できるため、推論コンテナーをホストする費用対効果が向上します。 この機能を使用するための追加費用はありません。 エンドポイントで実行されているインスタンスに対してのみ料金が発生します。 インスタンスの数とタイプに応じて、コストが加算される場合があります。 |
推論のレイテンシ | ML アプリケーションが推論パイプラインとしてデプロイされると、異なるモデル間のデータはコンテナー スペースを離れません。 コンテナが同じ EC2 インスタンスに配置されているため、機能の処理と推論は低レイテンシーで実行されます。 |
スループット | 推論パイプラインモデル内で、SageMaker は呼び出しを一連の HTTP リクエストとして処理します。 パイプラインの最初のコンテナが最初のリクエストを処理し、中間レスポンスがリクエストとして XNUMX 番目のコンテナに送信され、パイプラインのコンテナごとに同様の処理が行われます。 SageMaker はクライアントに最終的な応答を返します。 スループットは、モデル、モデルの入力サイズ、バッチ サイズ、エンドポイント インスタンス タイプなどの要因の影響を受けます。 ベスト プラクティスとして、入力リクエストとリソース使用率の CloudWatch メトリクスを確認し、適切なインスタンス タイプを選択して最適なスループットを実現します。 |
スケーリング構成の複雑さ | シリアル推論パイプラインは、自動スケーリングをサポートしています。 ただし、自動スケーリングを構成するには、各コンテナー内のモデルが各推論要求で同様の CPU 使用率とレイテンシーを示すことをお勧めします。 これが推奨されるのは、マルチコンテナー エンドポイントへのトラフィックが CPU 使用率の低いモデルから CPU 使用率の高いモデルに移行しても、全体的な呼び出し量が同じままである場合、エンドポイントはスケールアウトせず、十分なインスタンスが存在しない可能性があるためです。高 CPU 使用率モデルへのすべての要求を処理します。 |
交通パターン |
シリアル推論パイプラインは、同じエンドポイントで順次実行されるモデルを使用した予測可能なトラフィック パターンに最適です。 |
モデル アンサンブルのデプロイ (Triton DAG):
SageMaker は、 NVIDIATriton推論サーバー Triton 推論サーバー コンテナー. これらのコンテナには、NVIDIA Triton Inference Server、一般的な ML フレームワークのサポート、および SageMaker でのパフォーマンスを最適化できる便利な環境変数が含まれています。 NVIDIA Triton コンテナー イメージを使用すると、ML モデルを簡単に提供し、NVIDIA Triton が提供するパフォーマンスの最適化、動的バッチ処理、およびマルチフレームワーク サポートの恩恵を受けることができます。 Triton は、GPU と CPU の使用率を最大化し、推論のコストをさらに削減します。
ML アプリケーションが複数のモデルを使用して予測リクエストを処理するビジネス ユース ケースでは、各モデルが異なるフレームワークを使用するか、別のインスタンスでホストされている場合、ワークロードとコストの増加、および全体的なレイテンシの増加につながる可能性があります。 SageMaker NVIDIA Triton Inference Server は、TensorFlow GraphDef、TensorFlow SavedModel、ONNX、PyTorch TorchScript、TensorRT、Python/C++ モデル形式など、すべての主要なフレームワークからのモデルのデプロイをサポートしています。 Triton モデル アンサンブルは、XNUMX つ以上のモデルのパイプライン、または前処理ロジックと後処理ロジック、およびそれらの間の入力テンソルと出力テンソルの接続を表します。 アンサンブルへの単一の推論リクエストが、パイプライン全体の実行をトリガーします。 Triton には、個々の推論リクエストを組み合わせて推論スループットを向上させる複数の組み込みのスケジューリングおよびバッチ処理アルゴリズムもあります。 これらのスケジューリングとバッチ処理の決定は、推論を要求するクライアントに対して透過的です。 モデルは CPU または GPU で実行できるため、最大限の柔軟性が得られ、異種コンピューティング要件がサポートされます。
マルチモデル エンドポイントで複数の GPU 対応モデルをホストすることは、 SageMaker Triton 推論サーバー. NVIDIA Triton Inference Server が拡張され、 MME API コントラクト、MME と統合します。 さまざまなフレームワーク バックエンドのモデル リポジトリ構成を作成する NVIDIA Triton Inference Server を使用して、自動スケーリングで MME をデプロイできます。 この機能により、AI アプリケーションでの独自のエンドユーザー エクスペリエンスに対応するように微調整された数百の超パーソナライズされたモデルをスケーリングできます。 この機能を使用して、フラクショナル GPU を使用する推論アプリケーションに必要なコスト パフォーマンスを達成することもできます。 詳細については、次を参照してください。 Amazon SageMaker マルチモデル エンドポイントを使用して GPU で複数の深層学習モデルを実行する.
次の表は、Triton 推論コンテナーで GPU をサポートする MME を使用して、ML モデル ホスティングの適合度関数を評価するためのガイダンスを提供します。 単一モデルのエンドポイントとサーバーレス エンドポイントのフィットネス関数の評価については、この投稿の前のセクションを参照してください。
適応度関数 | Description |
費用 | Triton Inference Server を使用した GPU サポートを備えた SageMaker MME は、XNUMX つの SageMaker エンドポイントの背後に多数の深層学習モデルをデプロイするためのスケーラブルで費用対効果の高い方法を提供します。 MME を使用すると、複数のモデルがエンドポイントの背後で GPU インスタンスを共有します。 これにより、複数のモデルをホストする直線的に増加するコストを解消し、すべてのモデルでインフラストラクチャを再利用できます。 インスタンスの稼働時間に対して支払います。 |
推論のレイテンシ |
SageMaker with Triton Inference Server は、超低 (XNUMX 桁ミリ秒) の推論レイテンシーでスループットとハードウェア使用率を最大化するために構築されています。 サポートされている幅広い ML フレームワーク (TensorFlow、PyTorch、ONNX、XGBoost、NVIDIA TensorRT など) とインフラストラクチャ バックエンド (NVIDIA GPU、CPU、および AWSインフェレンティア. SageMaker Triton Inference Server を使用した GPU の MME サポートにより、XNUMX つの SageMaker エンドポイントの背後に何千もの深層学習モデルをデプロイできます。 SageMaker は、モデルを GPU アクセラレーション インスタンス上の NVIDIA Triton コンテナのメモリにロードし、推論リクエストを処理します。 GPU コアは、インスタンス内のすべてのモデルで共有されます。 モデルがコンテナメモリにすでにロードされている場合、SageMaker はモデルを再度ダウンロードしてロードする必要がないため、後続のリクエストはより高速に処理されます。 |
スループット |
MME は、Triton Inference Server を使用して、複数のディープ ラーニングまたは ML モデルを GPU 上で同時に実行する機能を提供します。 これにより、SageMaker のフルマネージド モデルのデプロイで提供される NVIDIA Triton マルチフレームワークの高性能推論を簡単に使用できます。 Triton は、NVIDIA GPU、x86、Arm® CPU、および AWS Inferentia ベースの推論をすべてサポートしています。 動的なバッチ処理、同時実行、最適なモデル構成、モデル アンサンブル、ストリーミング オーディオおよびビデオ入力を提供して、スループットと使用率を最大化します。 ネットワークやペイロード サイズなどのその他の要因は、推論に関連するオーバーヘッドで最小限の役割を果たす場合があります。 |
スケーリング構成の複雑さ |
MME は、自動スケーリング ポリシーを使用して水平方向にスケーリングし、次のような指標に基づいて追加の GPU コンピューティング インスタンスをプロビジョニングできます。 Triton 推論サーバーを使用すると、Triton を使用してモデルを含むカスタム コンテナを簡単に構築し、SageMaker に取り込むことができます。 SageMaker Inference はリクエストを処理し、使用量の増加に応じてコンテナを自動的にスケーリングし、AWS での Triton を使用したモデルのデプロイを容易にします。 |
交通パターン |
MME は、モデルが同じエンドポイントで DAG として実行される予測可能なトラフィック パターンに最適です。 SageMaker は MME エンドポイントへのトラフィック シェーピングを処理し、GPU インスタンスで最適なモデル コピーを維持して、最高の価格パフォーマンスを実現します。 モデルが読み込まれるインスタンスにトラフィックをルーティングし続けます。 使用率が高いためにインスタンス リソースが容量に達した場合、SageMaker はコンテナから使用頻度の低いモデルをアンロードして、リソースを解放し、より頻繁に使用されるモデルをロードします。 |
ベストプラクティス
次のベスト プラクティスを検討してください。
- モデル間の高い凝集度と低いカップリング – 凝集度の高い (単一ビジネス機能を駆動する) 同じコンテナーでモデルをホストし、それらをカプセル化して、アップグレードと管理を容易にします。 同時に、他のモデルに影響を与えることなく XNUMX つのモデルを簡単にアップグレードできるように、これらのモデルを互いに分離 (異なるコンテナーでホスト) します。 XNUMX つのエンドポイントの背後で異なるコンテナーを使用する複数のモデルをホストし、個別に呼び出すか、モデルの前処理ロジックと後処理ロジックをシリアル推論パイプラインとして追加します。
- 推論のレイテンシ – 単一ビジネス機能駆動型のモデルをグループ化し、それらを XNUMX つのコンテナーでホストして、ホップ数を最小限に抑え、したがって全体的な待ち時間を最小限に抑えます。 グループ化されたモデルが複数のフレームワークを使用する場合など、他にも注意事項があります。 複数のコンテナーでホストすることを選択することもできますが、同じホストで実行して、待ち時間を短縮し、コストを最小限に抑えることができます。
- 凝集度の高い ML モデルを論理的にグループ化する – 論理グループは、同種のモデル (すべての XGBoost モデルなど) または異種のモデル (少数の XGBoost と少数の BERT など) で構成される場合があります。 複数のビジネス機能で共有されるモデルで構成されている場合もあれば、XNUMX つのビジネス機能のみを満たすことに固有のモデルである場合もあります。
- 共有モデル – 論理グループが共有モデルで構成されている場合、モデルのアップグレードの容易さとレイテンシーは、SageMaker エンドポイントの設計において重要な役割を果たします。 たとえば、レイテンシーが優先される場合は、すべてのモデルを単一の SageMaker エンドポイントの背後にある単一のコンテナーに配置して、複数のホップを回避することをお勧めします。 欠点は、モデルのいずれかをアップグレードする必要がある場合、このモデルをホストしている関連するすべての SageMaker エンドポイントをアップグレードすることになります。
- 非共有モデル – 論理グループがビジネス機能固有のモデルのみで構成され、他のグループと共有されていない場合、パッケージングの複雑さと待ち時間の次元が達成の鍵となります。 これらのモデルは、単一の SageMaker エンドポイントの背後にある単一のコンテナーでホストすることをお勧めします。
- ハードウェア (CPU、GPU) の効率的な使用 – CPU を効率的に使用できるように、CPU ベースのモデルをグループ化し、同じホストでホストします。 同様に、GPU ベースのモデルをグループ化して、それらを効率的に使用およびスケーリングできるようにします。 同じホストで CPU と GPU の両方を必要とするハイブリッド ワークロードがあります。 CPU のみのモデルと GPU のみのモデルを同じホストでホストすることは、高い結束力とアプリケーションの待機時間の要件によって推進される必要があります。 さらに、コスト、スケーリング能力、および障害発生時の影響範囲が、検討すべき重要な要素です。
- フィットネス機能 – ML ホスティング オプションを選択するためのガイドラインとしてフィットネス関数を使用します。
まとめ
ML ホスティングに関しては、万能のアプローチはありません。 ML の実践者は、ML ホスティングの課題に対処するために適切な設計パターンを選択する必要があります。 フィットネス関数を評価すると、適切な ML ホスティング オプションを選択するための規範的なガイダンスが得られます。
各ホスティング オプションの詳細については、このシリーズの次の投稿を参照してください。
著者について
ダワル・パテル AWSのプリンシパル機械学習アーキテクトです。 彼は、分散コンピューティングや人工知能に関連する問題について、大企業から中規模の新興企業に至るまでの組織と協力してきました。 彼は、NLPおよびコンピュータービジョンドメインを含むディープラーニングに焦点を当てています。 彼は、顧客がSageMakerで高性能モデルの推論を実現するのを支援します。
ディーパリ・ラジャレ アマゾン ウェブ サービスの AI/ML スペシャリスト テクニカル アカウント マネージャーです。 彼女は企業のお客様と協力して、ベスト プラクティスを使用した機械学習ソリューションの実装に関する技術的なガイダンスを提供しています。 余暇には、ハイキング、映画、家族や友人との付き合いを楽しんでいます。
サウラブ・トリカンデ Amazon SageMaker Inference のシニア プロダクト マネージャーです。 彼は顧客と協力することに情熱を傾けており、機械学習を民主化するという目標に動機付けられています。 彼は、複雑な ML アプリケーションのデプロイ、マルチテナント ML モデル、コストの最適化、およびディープ ラーニング モデルのデプロイをよりアクセスしやすくすることに関連する主要な課題に焦点を当てています。 余暇には、Saurabh はハイキングを楽しんだり、革新的なテクノロジーについて学んだり、TechCrunch をフォローしたり、家族と過ごしたりしています。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
- 情報源: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- 能力
- できる
- 私たちについて
- 加速された
- アクセス
- アクセス
- アクセス可能な
- 対応する
- 正確な
- 達成する
- 達成する
- 越えて
- Action
- 積極的に
- 添加
- NEW
- さらに
- 住所
- 進める
- 高度な
- 利点
- 広告運用
- 影響を及ぼす
- 後
- 凝集
- アグリゲーター
- 積極的な
- 協定
- AI
- AI / ML
- アラーム
- アルゴリズム
- すべて
- 許可
- ことができます
- 既に
- 常に
- Amazon
- Amazon EC2
- アマゾンセージメーカー
- Amazon Webサービス
- 量
- 分析
- 分析します
- および
- とインフラ
- 毎年恒例の
- 別の
- アパッチ
- API
- Apple
- 申し込み
- アプローチ
- 適切な
- アプリ
- 建築
- ARM
- 人工の
- 人工知能
- 側面
- 評価
- 関連する
- 属性
- オーディオ
- 監査
- オート
- 自動化
- オートマチック
- 自動的に
- 賃貸条件の詳細・契約費用のお見積り等について
- 利用できます
- 平均
- AWS
- バック
- 支持された
- バンキング
- ベース
- ベース
- なぜなら
- になる
- になる
- 背後に
- さ
- 恩恵
- BEST
- ベストプラクティス
- より良いです
- の間に
- 生物医学
- ブロック
- 借り入れ
- 境界
- ボックス
- 違反
- ブレーク
- 持って来る
- もたらす
- 予算
- ビルド
- 建物
- 内蔵
- 内蔵
- ビジネス
- ビジネスアプリケーション
- ビジネス プロセス
- ビジネス
- キャッシュ
- 計算された
- コール
- 呼ばれます
- 発信者
- 候補
- 機能
- 容量
- これ
- 場合
- 例
- カテゴリ
- 原因
- 一定
- 認証
- 課題
- 変化する
- 変更
- 特性
- 荷担した
- チャットボット
- チェック
- チップ
- 選択
- 選択肢
- 選択する
- 選択する
- class
- 分類
- 分類します
- クライアント
- クライアント
- 閉じる
- クラウド
- クラスタ
- コード
- 造られた
- 同僚
- 収集する
- 戦闘
- 組み合わせ
- 組み合わせる
- 組み合わせた
- コマンドと
- 企業
- 会社
- 比べ
- コンプリート
- 完全に
- 複雑な
- 複雑さ
- コンプライアンス
- コンポーネント
- 構成
- 妥協
- 計算能力
- 計算
- コンピュータ
- Computer Vision
- コンピューティング
- コンセプト
- 懸念
- 同時
- 接続
- 整合性のある
- 消費
- 消費者
- コンテナ
- コンテナ
- 含まれています
- 続ける
- 続ける
- 連続的な
- コントロール
- 基本
- 対応する
- 費用
- コスト削減
- コスト効率の良い
- コスト
- 可能性
- 作ります
- 作成します。
- 重大な
- 重大な
- 電流プローブ
- カスタム
- 顧客
- Customers
- DAG
- データ
- データ処理
- データサイエンス
- データサイエンティスト
- データベース
- データセット
- 中
- 取引
- 決定
- 専用の
- 深いです
- 深い学習
- デフォルト
- 定義
- 配信する
- 需要
- 需要
- 民主化
- によっては
- 依存
- 展開します
- 展開
- 展開する
- 展開
- 配備
- 設計
- デザインパターン
- 設計
- 詳細
- 細部
- 検出
- 決定する
- Developer
- 開発
- 図
- 異なります
- 難しい
- 大きさ
- 直接
- 明確な
- 配布
- 分散コンピューティング
- 異なる
- デッカー
- ドキュメント
- そうではありません
- ドメイン
- ドント
- ダウン
- ダウンロード
- 下側
- ドリブン
- 落とした
- 落ちる
- 間に
- ダイナミック
- 各
- 前
- 容易
- 簡単に
- 効果的な
- 効果的に
- 有効
- 効率
- 効率的な
- 効率良く
- 努力
- どちら
- 排除
- enable
- 可能
- 暗号化
- 端から端まで
- エンドポイント
- エンジニアリング
- エンジニア
- 十分な
- 確保
- 確実に
- Enterprise
- 企業
- 全体
- 環境
- エラー
- エラー
- 特に
- 評価
- 評価
- さらに
- イベント
- すべてのもの
- 進化
- 例
- 例
- 交換
- 展示
- 期待する
- 予想される
- 体験
- エクスペリエンス
- 探る
- 表現
- 外部
- 余分な
- 顔
- 要因
- 不良解析
- かなり
- 家族
- 家族
- 速いです
- 特徴
- 特徴
- 摂食
- 少数の
- ファイナル
- 名
- 初回
- フィットネス
- 艦隊
- 柔軟性
- フロー
- 変動します
- 焦点を当てて
- フォロー中
- 次
- フォード
- フォーム
- フォーム
- 分数
- フレームワーク
- フレームワーク
- 詐欺
- 不正検出
- 無料版
- 周波数
- 頻繁に
- 友達
- から
- 果物
- フル
- 完全に
- function
- 機能性
- 機能性
- 機能
- さらに
- GDPR
- 生成された
- 生成
- 取得する
- 与える
- 与えられた
- 目標
- 目標
- 良い
- GPU
- GPU
- グラフ
- 素晴らしい
- 大きい
- 大いに
- グループ
- グループの
- 成長する
- ガイド
- ハンドル
- ハンドル
- ハンディ
- Hardware
- 持って
- 健康
- ヘルスケア
- 助けます
- 助け
- ことができます
- こちら
- ハイ
- ハイパフォーマンス
- 高解像度の
- より高い
- ヒット
- 水平な
- host
- 主催
- ホスティング
- ホスティング費用
- ホスティングサービス
- 認定条件
- しかしながら
- HTML
- HTTPS
- 何百
- ハイブリッド
- 理想
- アイデンティティ
- アイドル
- 画像
- 画像分類
- 画像
- 不変
- 影響
- 影響を受けた
- 影響
- 実装する
- 実装
- 実装
- 重要
- 改善します
- 改善
- in
- include
- 含ま
- 含めて
- 入ってくる
- 増える
- 増加した
- 増加
- の増加
- 独立しました
- 単独で
- 個人
- 情報
- インフラ
- 初期
- 革新的な
- 革新的な技術
- インストールする
- を取得する必要がある者
- 統合する
- 統合
- インテリジェンス
- 相互作用的
- 巻き込む
- ISO
- 分離
- IT
- ジョブ
- Jobs > Create New Job
- キー
- キー
- 知っている
- 既知の
- 大
- より大きい
- レイテンシ
- 起動する
- 起動
- 発射
- つながる
- 主要な
- リード
- LEARN
- 学習
- コメントを残す
- ツェッペリン
- レベル
- ライブラリ
- フェイスリフト
- 限定的
- 制限
- リスト
- ライブ
- 負荷
- ローディング
- 負荷
- 場所
- 長い
- より長いです
- 見て
- 負け
- たくさん
- ロー
- 機械
- 機械学習
- 製
- メイン
- 維持する
- 維持
- 主要な
- make
- 作る
- 作成
- 管理します
- マネージド
- 管理
- マネージャー
- 管理する
- 管理する
- 多くの
- マーケティング
- 数学的
- 問題
- 最大化します
- 手段
- 大会
- メモリ
- 方法
- メソッド
- メトリック
- メトリック
- かもしれない
- 最小限の
- 最小
- 分
- 混合
- ML
- モード
- モデル
- モニター
- モニタリング
- 月
- ヶ月
- 他には?
- 最も
- やる気
- 動画
- マルチモデル エンドポイント
- の試合に
- 多数
- 自然
- 必要
- 必要
- ニーズ
- ネットワーク
- 新作
- 次の
- NLP
- 通知
- 通知
- 数
- Nvidia
- オブジェクト
- 客観
- 目的
- 入手
- 時折
- 提供
- オファー
- オンライン
- ONE
- オンライン
- オープンソース
- 操作する
- 動作
- オペレーティング
- オペレーショナル
- 業務執行統括
- 演算子
- 最適な
- 最適化
- 最適化
- 最適化
- 最適化
- 最適化
- オプション
- オプション
- オレンジ
- 注文
- 組織
- その他
- 傑出した
- 全体
- 自分の
- 所有権
- パッケージ
- 包装
- パラメータ
- 部
- 特定の
- パートナー
- 渡された
- 情熱的な
- パッチ
- パターン
- パターン
- 支払う
- ピーク
- 実行する
- パフォーマンス
- 実行
- 期間
- periodic
- 期間
- 個人化
- カスタマイズ
- 選ぶ
- パイプライン
- 場所
- 場所
- 計画されました
- プラン
- プラットフォーム
- プラットフォーム
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- プレイ
- さらに
- ポリシー
- 方針
- 人気
- 可能
- ポスト
- 投稿
- 電力
- 練習
- プラクティス
- 予測可能な
- 予測
- 予測
- 予測
- 優先
- 前に
- ブランド
- 校長
- 優先順位
- プライベート
- 問題
- 問題
- プロセス
- 処理済み
- ラボレーション
- 処理
- プロセッサ
- プロダクト
- プロダクトマネージャー
- 生産
- 製品
- プロフィール
- 適切な
- 提供します
- 提供
- は、大阪で
- 提供
- 準備
- 代理
- 目的
- プッシュ
- パイトーチ
- すぐに
- 範囲
- 測距
- 急速に
- レート
- 価格表
- リーチ
- 達します
- 読む
- 準備
- リアル
- 現実の世界
- への
- 受け取ります
- 受け
- 受け取り
- 推奨する
- おすすめ
- 提言
- 推奨される
- 推薦する
- お勧めする
- 繰り返し
- 減らします
- 軽減
- 指し
- 関係なく
- レギュラー
- 関連する
- リリース
- 関連した
- 残っている
- 倉庫
- で表さ
- 表し
- 要求
- リクエスト
- 必要とする
- の提出が必要です
- 要件
- 要件
- 必要
- リソースを追加する。
- リソース
- 応答
- REST
- 結果
- 結果として
- 結果
- 小売
- 収益
- レビュー
- リスク
- 職種
- ルート
- ルート
- ルール
- ラン
- ランニング
- SaaSの
- セージメーカー
- SageMaker の推論
- 給与
- 同じ
- Save
- 節約
- 貯蓄
- ド電源のデ
- 規模
- 秤
- スケーリング
- シナリオ
- スケジュール
- 予定の
- 科学
- 科学者
- 二番
- 秒
- セクション
- セクション
- しっかりと
- セキュリティ
- 選択
- 選択
- シニア
- 敏感な
- シーケンス
- シリアル
- シリーズ
- 役立つ
- サーバレス
- サーバー
- 仕える
- サービス
- サービス
- サービング
- セッションに
- 設定
- いくつかの
- シェーピング
- シェアする
- shared
- シフト
- すべき
- 作品
- 重要
- 著しく
- 同様の
- 同様に
- 簡単な拡張で
- サイズ
- サイズ
- 小さい
- より小さい
- So
- ソフトウェア
- 溶液
- ソリューション
- 一部
- ソース
- スペース
- 専門家
- 専門の
- 特定の
- 特に
- 指定の
- スピード
- 支出
- スパイク
- 安定した
- スタック
- スタック
- start
- 開始
- 開始
- スタートアップ
- スタートアップ
- 着実
- 手順
- ステップ
- まだ
- 停止する
- ストレージ利用料
- 店舗
- 作戦
- ストリーミング
- 厳格な
- 強く
- それに続きます
- 成功
- 成功した
- そのような
- 十分な
- 適当
- サポート
- サポート
- サポート
- 発生します
- テーブル
- 取る
- 取り
- ターゲット
- 対象となります
- 仕事
- タスク
- チーム
- チーム
- TechCrunchの
- 技術的
- テクノロジー
- テナント
- テンソルフロー
- test
- テスト
- アプリ環境に合わせて
- 自分自身
- それによって
- したがって、
- 数千
- 三
- しきい値
- 介して
- 全体
- スループット
- 時間
- <font style="vertical-align: inherit;">回数</font>
- 〜へ
- 一緒に
- あまりに
- ツール
- トータル
- TPS
- 追跡
- トラフィック
- トレーニング
- 訓練された
- トレーニング
- トランザクションの
- 取引
- 最適化の適用
- 変換
- 変換
- トランジット
- トランスペアレント
- トリガー
- トリトン
- 順番
- 典型的な
- 一般的に
- 下
- 根本的な
- わかる
- ユニーク
- ユニット
- 予測できない
- 未使用
- アップデイト
- 更新版
- アップグレード
- アップグレード
- uptime
- 使用法
- つかいます
- 使用事例
- ユーザー
- users
- 通常
- 活用する
- 利用された
- 検証
- 値
- 価値観
- バリアント
- さまざまな
- 、
- ビデオ
- 動画
- 詳しく見る
- バーチャル
- ビジョン
- ボリューム
- 投票
- 票
- 無駄
- ウェブ
- Webサービス
- 週間
- この試験は
- 何ですか
- which
- while
- ワイド
- 広い範囲
- 意志
- 以内
- 無し
- 仕事
- 働いていました
- ワーカー
- 労働者
- ワーキング
- 作品
- 世界
- でしょう
- XGブースト
- 年
- You
- あなたの
- ゼファーネット
- ゼロ