この記事では、ワークスペースで Model Serving を有効にし、モデルをサーバーレス コンピューティング上に構築された Mosaic AI Model Serving エクスペリエンスに切り替える方法について説明します。
Von Bedeutung
2025 年 8 月 22 日から、お客様は従来の MLflow モデル サービス エクスペリエンスを使用して新しいサービス エンドポイントを作成できなくなります。 2025 年 9 月 15 日に、レガシ エクスペリエンスは終了し、このサービスを使用するすべての既存のエンドポイントは使用できなくなります。
要件
- MLflow モデル レジストリに登録されたモデル。
- アクセス制御ガイドに説明されている登録済みモデルに対するアクセス許可。
- ワークスペースでのサーバーレス コンピューティングの有効化。
重要な変更
- Model Serving では、エンドポイントに対する要求の形式とエンドポイントからの応答が、レガシ MLflow Model Serving と若干異なります。 新しいフォーマット プロトコルの詳細については、モデル エンドポイントのスコアリングに関する記事を参照してください。
- Model Serving では、エンドポイント URL には
serving-endpointsではなくmodelが含まれます。 - Model Serving には、API ワークフローを使用したリソースの管理に対する詳細サポートが含まれています。
- Model Serving は運用環境に対応していて、Azure Databricks SLA によってサポートされています。
従来の MLflow モデル サービスを使用するサービス エンドポイントを識別する
レガシ MLflow モデル サービスを使用するモデル サービス エンドポイントを識別するには:
- ワークスペースの [モデル ] UI に移動します。
- ワークスペース モデル レジストリ フィルターを選択します。
- [ レガシ サービスの有効化のみ ] フィルターを選択します。
レガシ MLflow Model Serving が提供したモデルを Model Serving に移行する
Model Serving エンドポイントを作成し、レガシ MLflow Model Serving を無効にすることなく、ワークフローを提供するモデルを柔軟に切り替えることができます。
次のステップでは、UI でこれを実現する方法を示します。 レガシ MLflow Model Serving が有効になっているモデルごとに、次の手順を実行します。
- モデルを Unity カタログに登録します。
- 機械学習ワークスペースのサイドバーから [Serving endpoints] (提供エンドポイント) に移動します。
- モデルを使用して提供エンドポイントを作成する方法については、「カスタム モデル サービング エンドポイントを作成する」に記載されているワークフローに従います。
- 提供エンドポイントによって提供される新しい URL を使用してモデルのクエリを実行するように、新しいスコアリング形式とともにアプリケーションを移行します。
- モデルが切り替わると、機械学習ワークスペースのサイドバーにある [モデル] に移動できます。
- レガシ MLflow Model Serving を無効にするモデルを選択します。
- [提供] タブで、[停止] を選択します。
- 確認メッセージが表示されます。 [提供の停止] を選択します。
デプロイされたモデル バージョンを Model Serving に移行する
前のバージョンの Model Serving 機能では、登録済みのモデル バージョンのステージ (Staging または Production) に基づいてサービス エンドポイントが作成されていました。 そのエクスペリエンスから提供されたモデルを移行するには、新しい Model Serving エクスペリエンスでその動作をレプリケートできます。
このセクションでは、Staging モデル バージョンと Production モデル バージョンに別個のモデル サービング エンドポイントを作成する方法について説明します。 次の手順では、サービス対象モデルごとに Serving Endpoints API を使用してこれを実現する方法を示します。
この例では、登録されたモデル名 modelA にモデル ステージ Production のバージョン 1 とモデル ステージ Staging のバージョン 2 があります。
登録済みモデルに対して、
Stagingモデル バージョン用の1 つと、Productionモデル バージョン用のもう 1 つの 2 つのエンドポイントを作成します。Stagingモデル バージョン用:POST /api/2.0/serving-endpoints { "name":"modelA-Staging" "config": { "served_entities": [ { "entity_name":"model-A", "entity_version":"2", // Staging Model Version "workload_size":"Small", "scale_to_zero_enabled":true }, ], }, }Productionモデル バージョン用:POST /api/2.0/serving-endpoints { "name":"modelA-Production" "config": { "served_entities": [ { "entity_name":"model-A", "entity_version":"1", // Production Model Version "workload_size":"Small", "scale_to_zero_enabled":true }, ], }, }エンドポイントの状態を確認します。
Staging エンドポイント用:
GET /api/2.0/serving-endpoints/modelA-StagingProduction エンドポイント用:
GET /api/2.0/serving-endpoints/modelA-Productionエンドポイントの準備ができたら、次を使用してエンドポイントに対してクエリを実行します。
Staging エンドポイント用:
POST /serving-endpoints/modelA-Staging/invocationsProduction エンドポイント用:
POST /serving-endpoints/modelA-Production/invocationsモデル バージョンの切り替えに基づいてエンドポイントを更新します。
新しいモデル バージョン 3 が作成されるシナリオでは、モデル バージョン 2 を
Productionに移行できます。同時に、モデル バージョン 3 はStagingに移行でき、モデル バージョン 1 はArchivedになります。 これらの変更は、次のように別個のモデル サービング エンドポイントに反映できます。Stagingエンドポイントについては、Stagingで新しいモデル バージョンを使用するようにエンドポイントを更新します。PUT /api/2.0/serving-endpoints/modelA-Staging/config { "served_entities": [ { "entity_name":"model-A", "entity_version":"3", // New Staging model version "workload_size":"Small", "scale_to_zero_enabled":true }, ], }Productionエンドポイントについては、Productionで新しいモデル バージョンを使用するようにエンドポイントを更新します。PUT /api/2.0/serving-endpoints/modelA-Production/config { "served_entities": [ { "entity_name":"model-A", "entity_version":"2", // New Production model version "workload_size":"Small", "scale_to_zero_enabled":true }, ], }