メインコンテンツまでスキップ

モデルサービングへの移行

この記事では、ワークスペースでモデルサービングを有効にし、モデルをサーバレス コンピュート Mosaic AI Model Serving エクスペリエンスに切り替えます。

必要条件​

大幅な変更​

  • モデルサービングでは、エンドポイントへのリクエストとエンドポイントからのレスポンスの形式が、レガシー MLflow モデルサービングとは少し異なります。 新しい形式プロトコルの詳細については、 モデルエンドポイントのスコアリング を参照してください。
  • モデルサービングでは、エンドポイント URL には modelではなく serving-endpoints が含まれます。
  • モデルサービングには、APIワークフローを使用したリソースの管理が完全にサポートされています。
  • モデルサービングは本番運用に対応しており、 Databricks SLAによって支えられています。

レガシーMLflow モデルサービング提供モデルをモデルサービングへ移行​

モデルサービングエンドポイントを作成し、 レガシーMLflow モデルサービングを無効にせずにモデルサービング ワークフローを柔軟に移行できます。

次の手順は、UI を使用してこれを実現する方法を示しています。 レガシーモデルサービングが有効になっている各MLflowモデルで以下を実施します:

  1. モデルを Unity Catalogに登録する .
  2. 機械学習ワークスペースのサイドバーにある サービングエンドポイント に移動します。
  3. モデルを使用してサービングエンドポイントを作成する方法については、「 カスタムモデルサービングエンドポイントの作成 」で説明されているワークフローに従ってください。
  4. 新しいスコアリング形式とともに、サービングエンドポイントから提供された新しいURLを使用してモデルをクエリするようにアプリケーションを移行してください。
  5. モデルが移行されると、機械学習ワークスペースのサイドバーにある モデル に移動できます。
  6. レガシー MLflow モデルサービングを無効にするモデルを選択します。
  7. サービング タブで、 停止 を選択します。
  8. 確認のメッセージが表示されます。 サービングの停止 を選択します。

デプロイされたモデルバージョンをモデルサービングに移行する​

以前のバージョンのモデルサービング機能では、サービングエンドポイントは、登録済みのモデルバージョン( Staging または Production)のステージに基づいて作成されていました。 そのエクスペリエンスから提供されたモデルを移行するには、新しいモデルサービング エクスペリエンスでその動作をレプリケートできます。

このセクションでは、 Staging モデルバージョンと Production モデルバージョンで別々のモデルサービングエンドポイントを作成する方法について説明します。 次の手順は、各サービングモデルのサービングエンドポイント API を使用してこれを実現する方法を示しています。

この例では、登録されたモデル名 modelA は、モデル ステージ Production にバージョン 1 があり、モデル ステージ Stagingにバージョン 2 があります。

  1. 登録済みモデルに対して 2 つのエンドポイント (1 つは Staging モデル バージョン用、もう 1 つは Production モデル バージョン用) を作成します。

    Staging モデルバージョンの場合：

    Bash
    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 モデルバージョンの場合：

    Bash
    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
               },
            ],
         },
      }

  2. エンドポイントのステータスを確認します。

    ステージング エンドポイントの場合: GET /api/2.0/serving-endpoints/modelA-Staging

    本番運用エンドポイントの場合: GET /api/2.0/serving-endpoints/modelA-Production

  3. エンドポイントの準備ができたら、次を使用してエンドポイントをクエリします。

    ステージング エンドポイントの場合: POST /serving-endpoints/modelA-Staging/invocations

    本番運用エンドポイントの場合: POST /serving-endpoints/modelA-Production/invocations

  4. モデル バージョンの遷移に基づいてエンドポイントを更新します。

    新しいモデル バージョン 3 を作成するシナリオでは、モデル バージョン 2 を Productionに移行し、モデル バージョン 3 を Staging に移行してモデル バージョン 1 を Archivedにすることができます。 これらの変更は、次のように個別のモデルサービングエンドポイントに反映できます。

    Staging エンドポイントについては、Stagingの新しいモデル バージョンを使用するようにエンドポイントを更新します。

    Bash
    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の新しいモデルバージョンを使用するようにエンドポイントを更新します。

    Bash
    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
          },
       ],
    }

追加のリソース​

に最終更新