運用環境での推論のためのエンドポイント
適用対象:
Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)
機械学習モデルまたはパイプラインをトレーニングした後は、運用環境にそれらをデプロイして、他のユーザーが "推論" に使用できるようにする必要があります。 推論とは、機械学習モデルまたはパイプラインに新しい入力データを適用して出力を生成するプロセスです。 通常、これらの出力は "予測" と呼ばれますが、推論を使うと、分類やクラスタリングなどの他の機械学習タスク用の出力を生成できます。 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 のモデルと、モデルを実行するために必要なコードやコンピューティングなどのリソースは、同じエンドポイントの下の別のデプロイを構成します。
エンドポイントとデプロイ
エンドポイントは、モデルの要求または呼び出しに使用できる、安定した持続的な URL です。 エンドポイントに必要な入力を提供して、出力を取得します。 エンドポイントから提供されるもの:
- 安定した持続的な URL (例: endpoint-name.region.inference.ml.azure.com)
- 認証メカニズム
- 承認メカニズム。
デプロイは、実際の推論を行うモデルやコンポーネントをホストするのに必要なリソースとコンピューティングのセットです。 1 つのエンドポイントに複数のデプロイを含めることができます。 これらのデプロイは、独立した資産をホストし、資産のニーズに基づいてさまざまなリソースを使用できます。 エンドポイントには、エンドポイント内の特定のデプロイに要求を転送できるルーティング メカニズムがあります。
適切に機能するには、各エンドポイントに少なくとも 1 つのデプロイが必要です。 エンドポイントとデプロイは、Azure portal に表示される、独立した Azure Resource Manager リソースです。
オンライン エンドポイントとバッチ エンドポイント
Azure Machine Learning では、オンライン エンドポイントとバッチ エンドポイントを実装できます。 オンライン エンドポイントは、リアルタイムの推論用に設計されています。エンドポイントを呼び出すと、エンドポイントの応答で結果が返されます。 一方、バッチ エンドポイントは、実行時間の長いバッチ推論用に設計されています。 バッチ エンドポイントを呼び出すたびに、実際の作業を実行するバッチ ジョブが生成されます。
ユース ケースにオンライン エンドポイントを使用すべきときとバッチ エンドポイントを使用すべきとき
オンライン エンドポイントを使用して、同期型低遅延要求のリアルタイム推論用のモデルを運用化します。 次の場合に使用することをお勧めします。
- 低遅延の要件がある。
- モデルが比較的短時間で要求に応答できる。
- モデルの入力が要求の HTTP ペイロードに適合する。
- 要求の数に関してスケールアップする必要がある。
バッチ エンドポイントを使用して、実行時間の長い非同期型推論用のモデルまたはパイプラインを運用化します。 次の場合に使用することをお勧めします。
- 実行に長い時間がかかるコストの高いモデルまたはパイプラインがある。
- 機械学習パイプラインを運用化し、コンポーネントを再利用したいと考えている。
- 複数のファイルに分散された大量のデータに対して推論を実行する必要がある。
- 低遅延を必要としない
- モデルの入力が、ストレージ アカウントまたは Azure Machine Learning データ アセットに格納される。
- 並列処理の恩恵を受けることができる
オンライン エンドポイントとバッチ エンドポイントの比較
オンライン エンドポイントとバッチ エンドポイントはどちらも、エンドポイントとデプロイの概念に基づいており、一方から他方に簡単に移行することができます。 ただし、一方から他方に移動する場合は、いくつかの考慮すべき重要な違いがあります。 これらの違いの一部は、作業の性質によるものです。
エンドポイント
次の表は、オンライン エンドポイントとバッチ エンドポイントで異なる機能の概要を示したものです。
| 機能 | オンライン エンドポイント | バッチ エンドポイント |
|---|---|---|
| 安定した呼び出し URL | はい | はい |
| 複数のデプロイのサポート | はい | はい |
| デプロイのルーティング | トラフィックの分割 | 既定値への切り替え |
| 安全なロールアウトのためのトラフィックのミラーリング | はい | いいえ |
| Swagger のサポート | はい | いいえ |
| 認証 | キーとトークン | Microsoft Entra ID |
| プライベート ネットワークのサポート | はい | はい |
| マネージド ネットワーク分離 | はい | はい (必要な追加構成を参照) |
| カスタマー マネージド キー | はい | はい |
| コスト基準 | なし | なし |
デプロイメント
次の表は、オンライン エンドポイントとバッチ エンドポイントのデプロイ レベルで異なる機能の概要です。 これらの概念は、エンドポイントの下のデプロイごとに適用されます。
| 機能 | オンライン エンドポイント | バッチ エンドポイント |
|---|---|---|
| デプロイのタイプ | モデル | モデルとパイプライン コンポーネント |
| MLflow モデルのデプロイ | はい | はい |
| カスタム モデルのデプロイ | はい (スコアリング スクリプトを使用) | はい (スコアリング スクリプトを使用) |
| モデル パッケージ展開 1 | はい (プレビュー) | いいえ |
| 推論サーバー 2 | - Azure Machine Learning 推論サーバー - Triton - カスタム (BYOC を使用) |
バッチ推論 |
| 使用されるコンピューティング リソース | インスタンスまたは詳細なリソース | クラスター インスタンス |
| コンピューティングの種類 | マネージド コンピューティングと Kubernetes | マネージド コンピューティングと Kubernetes |
| 優先順位の低いコンピューティング | いいえ | はい |
| コンピューティングのゼロへのスケーリング | いいえ | はい |
| コンピューティングの自動スケーリング3 | はい (リソースの負荷に基づく) | はい (ジョブ数に基づく) |
| 過剰容量の管理 | 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 パイプラインのサポート