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

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

備考

プレビュー

Mosaic AI Model Serving は パブリック プレビュー 段階にあり、 us-east1 と us-central1でサポートされています。

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

必要条件​

大幅な変更​

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

Migrate Legacy MLflow モデルサービング提供モデルをモデルサービングへ​

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

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

  1. モデルを Unity Catalogに登録する .
  2. 機械学習ワークスペースのサイドバーにある [Serving endpoints ] に移動します。
  3. モデルを使用してサービングエンドポイントを作成する方法については、「 カスタムモデルサービングエンドポイントの作成 」で説明されているワークフローに従ってください。
  4. 新しいスコアリング形式とともに、サービングエンドポイントから提供された新しいURLを使用してモデルをクエリするようにアプリケーションを移行してください。
  5. モデルが移行されると、機械学習ワークスペースのサイドバーにある [モデル ] に移動できます。
  6. Legacy 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
          },
       ],
    }

追加のリソース​

に最終更新