運用環境での推論のためのエンドポイント
適用対象:
Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)
機械学習モデルまたはパイプラインをトレーニングした後、またはモデル カタログでニーズに合ったモデルを見つけた後は、運用環境にそれらをデプロイして、他のユーザーが "推論" に使用できるようにする必要があります。 推論とは、機械学習モデルまたはパイプラインに新しい入力データを適用して出力を生成するプロセスです。 通常、これらの出力は "予測" と呼ばれますが、推論を使うと、分類やクラスタリングなどの他の機械学習タスク用の出力を生成できます。 Azure Machine Learning では、エンドポイントを使って推論を実行します。
エンドポイントとデプロイ
エンドポイントは、モデルの要求または呼び出しに使用できる、安定した持続的な URL です。 エンドポイントに必要な入力を提供して、出力を取得します。 エンドポイントから提供されるもの:
- 安定した持続的な URL (例: endpoint-name.region.inference.ml.azure.com)
- 認証メカニズム
- 承認メカニズム。
デプロイは、実際の推論を行うモデルやコンポーネントをホストするのに必要なリソースとコンピューティングのセットです。 1 つのエンドポイントに 1 つまたは複数のデプロイを含めることができます (サーバーレス API エンドポイントを除く)。 デプロイでは、独立した資産をホストし、資産のニーズに基づいてさまざまなリソースを使用できます。 さらに、エンドポイントは、エンドポイント内の特定のデプロイに要求を転送できるルーティング メカニズムを備えています。
Azure Machine Learning の一部の種類のエンドポイントでは、デプロイで専用のリソースが使われます。 これらのエンドポイントを実行するには、サブスクリプションにコンピューティング クォータが必要です。 ただし、サーバーレス デプロイをサポートする一部のモデルは、サブスクリプションのクォータを消費せず、代わりに使用量に基づいて課金されます。
直感
与えられた写真から車の種類と色を予測するアプリケーションについての作業を行っているとします。 このアプリケーションでは、特定の資格情報を持つユーザーが URL に対して HTTP 要求を行い、要求の一部として車の画像を提供します。 そして、ユーザーは車の種類と色を文字列値として含む応答を取得します。 このシナリオでは、URL はエンドポイントとして機能します。
さらに、データ科学者の Alice がアプリケーションの実装作業を行っているとします。 Alice は TensorFlow のことをよく知っており、TensorFlow Hub から Keras シーケンシャル分類子と RestNet アーキテクチャを使ってモデルを実装することにしました。 モデルをテストした後、Alice はその結果に満足し、モデルを使って車の予測の問題を解決することにします。 モデルはサイズが大きく、実行するには 8 GB のメモリと 4 つのコアが必要です。 このシナリオでは、Alice のモデルと、モデルを実行するために必要なコードやコンピューティングなどのリソースが、エンドポイントの下のデプロイを構成します。
組織は、数か月後に、理想的な照明条件を満たしていない画像では、アプリケーションのパフォーマンスが低下することを発見するとします。 もう 1 人のデータ科学者の Bob は、その点について堅牢なモデルを構築するのに役立つデータ拡張手法について多くの知識があります。 しかし、Bob は、Torch を使ってモデルを実装し、Torch で新しいモデルをトレーニングする方を好んでいます。 Bob は、組織が古いモデルを廃止できるようになるまで、このモデルを運用環境で段階的に試そうと考えます。 また、新しいモデルは、GPU にデプロイするとパフォーマンスが向上するため、デプロイには GPU を含める必要があります。 このシナリオでは、Bob のモデルと、モデルを実行するために必要なコードやコンピューティングなどのリソースは、同じエンドポイントの下の別のデプロイを構成します。
エンドポイント: サーバーレス API、オンライン、バッチ
Azure Machine Learning では、サーバーレス API エンドポイント、オンライン エンドポイント、バッチ エンドポイントを実装できます。 サーバーレス API エンドポイントとオンライン エンドポイントは、リアルタイムの推論用に設計されています。エンドポイントを呼び出すと、エンドポイントの応答で結果が返されます。 サーバーレス API エンドポイントはサブスクリプションのクォータを消費せず、代わりに従量課金制で課金されます。
一方、バッチ エンドポイントは、実行時間の長いバッチ推論用に設計されています。 バッチ エンドポイントを呼び出すたびに、実際の作業を実行するバッチ ジョブが生成されます。
サーバーレス API、オンライン、バッチの各エンドポイントを使用すべきとき
サーバーレス API エンドポイント:
サーバーレス API エンドポイントは、リアルタイム推論に既製の大きな基本モデルを使用したり、そのようなモデルを微調整したりするために使います。 すべてのモデルをサーバーレス API エンドポイントへのデプロイに使用できるわけではありません。 次の場合は、このデプロイ モードを使うことをお勧めします。
- モデルが基本モデルであるか、その微調整バージョンをサーバーレス API デプロイに使用できます。
- クォータのないデプロイにメリットがあります。
- モデルの実行に使われる推論スタックをカスタマイズする必要がありません。
オンライン エンドポイント:
オンライン エンドポイントを使用して、同期型低遅延要求のリアルタイム推論用のモデルを運用化します。 次の場合に使用することをお勧めします。
- モデルは基本モデルであるか、その微調整バージョンですが、サーバーレス API エンドポイントでサポートされていません。
- 低遅延の要件がある。
- モデルが比較的短時間で要求に応答できる。
- モデルの入力が要求の HTTP ペイロードに適合する。
- 要求の数に関してスケールアップする必要がある。
バッチ エンドポイント:
バッチ エンドポイントを使用して、実行時間の長い非同期型推論用のモデルまたはパイプラインを運用化します。 次の場合に使用することをお勧めします。
- 実行に長い時間がかかるコストの高いモデルまたはパイプラインがある。
- 機械学習パイプラインを運用化し、コンポーネントを再利用したいと考えている。
- 複数のファイルに分散された大量のデータに対して推論を実行する必要がある。
- 低遅延を必要としない
- モデルの入力が、ストレージ アカウントまたは Azure Machine Learning データ アセットに格納される。
- 並列処理の恩恵を受けることができる
サーバーレス API、オンライン、バッチの各エンドポイントの比較
サーバーレス API、オンライン、バッチのすべてのエンドポイントは、エンドポイントのアイデアに基づいており、それらの間を簡単に移行できます。 オンラインとバッチ エンドポイントには、同じエンドポイントの複数のデプロイを管理する機能も導入されています。 次のセクションでは、各デプロイ オプションで異なる機能について説明します。
エンドポイント
次の表は、サーバーレス API、オンライン、バッチの各エンドポイントで利用できる異なる機能の概要を示したものです。
| 機能 | サーバーレス API エンドポイント | オンライン エンドポイント | バッチ エンドポイント |
|---|---|---|---|
| 安定した呼び出し URL | はい | イエス | はい |
| 複数のデプロイのサポート | いいえ | イエス | はい |
| デプロイのルーティング | なし | トラフィックの分割 | 既定値への切り替え |
| 安全なロールアウトのためのトラフィックのミラーリング | いいえ | 有効 | いいえ |
| Swagger のサポート | はい | はい | いいえ |
| 認証 | キー | キーと Microsoft Entra ID (プレビュー) | Microsoft Entra ID |
| プライベート ネットワークのサポート (レガシ) | いいえ | イエス | はい |
| マネージド ネットワーク分離 | はい | はい | はい (必要な追加構成を参照) |
| カスタマー マネージド キー | NA | はい | はい |
| コスト基準 | エンドポイント単位で分あたり 1 | なし | なし |
1 サーバーレス API エンドポイントの 1 分あたりの課金はわずかな額です。 トークンごとに課金される使用量関連の料金については、デプロイに関するセクションをご覧ください。
デプロイ
次の表は、サーバーレス API、オンライン、バッチの各エンドポイントで利用できる、デプロイ レベルのさまざまな機能の概要です。 これらの概念は、オンラインとバッチ エンドポイントの下の各デプロイと、サーバーレス API エンドポイント (デプロイの概念はエンドポイントに組み込まれています) に適用されます。
| 機能 | サーバーレス API エンドポイント | オンライン エンドポイント | バッチ エンドポイント |
|---|---|---|---|
| デプロイのタイプ | モデル | モデル | モデルとパイプライン コンポーネント |
| MLflow モデルのデプロイ | なし。カタログ内の特定のモデルのみ | はい | はい |
| カスタム モデルのデプロイ | なし。カタログ内の特定のモデルのみ | はい (スコアリング スクリプトを使用) | はい (スコアリング スクリプトを使用) |
| モデル パッケージ展開 1 | 組み込み | はい (プレビュー) | いいえ |
| 推論サーバー 2 | Azure AI Model Inference API | - Azure Machine Learning 推論サーバー - Triton - カスタム (BYOC を使用) |
バッチ推論 |
| 使用されるコンピューティング リソース | なし (サーバーレス) | インスタンスまたは詳細なリソース | クラスター インスタンス |
| コンピューティングの種類 | なし (サーバーレス) | マネージド コンピューティングと Kubernetes | マネージド コンピューティングと Kubernetes |
| 優先順位の低いコンピューティング | NA | いいえ | はい |
| コンピューティングのゼロへのスケーリング | 組み込み | いいえ | はい |
| コンピューティングの自動スケーリング3 | 組み込み | はい (リソースの負荷に基づく) | はい (ジョブ数に基づく) |
| 過剰容量の管理 | Throttling | Throttling | キューイング |
| コスト基準4 | トークン単位 | デプロイごと: 実行中のコンピューティング インスタンス | ジョブごと: ジョブで使用されるコンピューティング インスタンス (クラスターのインスタンス数の上限まで)。 |
| デプロイのローカル テスト | いいえ | 有効 | いいえ |
1 送信インターネット接続またはプライベート ネットワークなしで MLflow モデルをエンドポイントに展開するには、まず、モデルをパッケージ化する必要があります。
2 "推論サーバー" とは、要求を受け取り、それを処理して、応答を作成するサービス テクノロジのことです。 推論サーバーでは、入力の形式と予想される出力も指定されます。
3 "自動スケーリング" は、負荷に基づいて、デプロイの割り当てられたリソースを動的にスケールアップまたはスケールダウンする機能です。 オンライン デプロイとバッチ デプロイでは、自動スケーリングに使われる戦略が異なります。 オンライン デプロイではリソース使用率 (CPU、メモリ、要求など) に基づいてスケールアップおよびスケールダウンしますが、バッチ エンドポイントでは作成されたジョブの数に基づいてスケールアップまたはスケールダウンします。
4 オンライン デプロイとバッチ デプロイの両方とも、使用されたリソースに基づいて課金されます。 オンライン デプロイの場合、リソースはデプロイ時にプロビジョニングされます。 一方、バッチ デプロイの場合は、デプロイ時でなくジョブの実行時にリソースが消費されます。 そのため、デプロイ自体に関連するコストはありません。 キューに登録されたジョブでもリソースが消費されないことに注意してください。
開発者インターフェイス
エンドポイントは、組織が Azure Machine Learning で運用レベルのワークロードを運用できるように設計されています。 エンドポイントは堅牢でスケーラブルなリソースであり、MLOps ワークフローを実装するのに最適な機能を提供します。
複数の開発者ツールを使って、バッチ エンドポイントとオンライン エンドポイントを作成および管理できます。
- Azure CLI および Python SDK
- Azure Resource Manager/REST API
- Azure Machine Learning スタジオ Web ポータル
- Azure portal (IT および管理者)
- Azure CLI インターフェイスと REST および ARM インターフェイスを使用した、CI/CD MLOps パイプラインのサポート
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示