複数のモデルを Model Serving エンドポイント に提供する

この記事では、Databricks Model Servingを利用するサービス エンドポイントに複数のモデルを提供する方法について説明します。

要件

「 Model Serving エンドポイント作成 の要件 」を参照してください。

モデルサービング エンドポイントのアクセス制御オプションとエンドポイント管理のベスト プラクティス ガイダンスを理解するには、 「エンドポイント ACL の提供」を参照してください。

エンドポイントを作成し、初期トラフィック分割 を設定する

モデルサービング エンドポイントは、Databricks Machine Learning API を使用して作成できます。 エンドポイントは、 Model Registryに登録されている登録済みの Python MLflow モデルを提供できます。

次の API 例では、2 つのモデルを持つ 1 つのエンドポイントを作成し、それらのモデル間でエンドポイント トラフィックを分割するように設定します。 サーブド モデル currentはバージョン 1 of model-A をホストし、エンドポイント トラフィックの 90% を取得し、もう 1 つのサービス モデル challengerはバージョン 1 of model-B をホストし、エンドポイント トラフィックの 10% を取得します。

POST /api/2.0/serving-endpoints

{
   "name":"multi-model"
   "config":{
      "served_entities":[
         {
            "name":"current",
            "entity_name":"model-A",
            "entity_version":"1",
            "workload_size":"Small",
            "scale_to_zero_enabled":true
         },
         {
            "name":"challenger",
            "entity_name":"model-B",
            "entity_version":"1",
            "workload_size":"Small",
            "scale_to_zero_enabled":true
         }
      ],
      "traffic_config":{
         "routes":[
            {
               "served_model_name":"current",
               "traffic_percentage":"90"
            },
            {
               "served_model_name":"challenger",
               "traffic_percentage":"10"
            }
         ]
      }
   }
}

配信モデル 間のトラフィック分割の更新

また、配信モデル間のトラフィック分割を更新することもできます。 次の API の例では、エンドポイント トラフィックの 50% を取得するようにサービス モデル currentを設定し、残りのトラフィックの残りの 50% を取得するように他のモデル challengerを設定します。

この更新は、 Databricks Machine Learning UI の [配信 ] タブから [ 構成の編集 ] ボタンを使用して行うこともできます。

PUT /api/2.0/serving-endpoints/{name}/config

{
   "served_entities":[
      {
         "name":"current",
         "entity_name":"model-A",
         "entity_version":"1",
         "workload_size":"Small",
         "scale_to_zero_enabled":true
      },
      {
         "name":"challenger",
         "entity_name":"model-B",
         "entity_version":"1",
         "workload_size":"Small",
         "scale_to_zero_enabled":true
      }
   ],
   "traffic_config":{
      "routes":[
         {
            "served_model_name":"current",
            "traffic_percentage":"50"
         },
         {
            "served_model_name":"challenger",
            "traffic_percentage":"50"
         }
      ]
   }
}

クエリー エンドポイント の背後にある個々のモデル

シナリオによっては、エンドポイントの背後にある個々のモデルをクエリーしたい場合があります。

これを行うには、以下を使用します。

POST /serving-endpoints/{endpoint-name}/served-models/{served-model-name}/invocations

ここで提供される特定のモデルはクエリーです。 要求の形式は、エンドポイントのクエリと同じです。 個々のサービス モデルを照会している間、トラフィック設定は無視されます。

multi-model エンドポイントの例のコンテキストでは、すべての要求が /serving-endpoints/multi-model/served-models/challenger/invocationsに送信された場合、すべての要求は challenger サービスモデルによって処理されます。

ノートブック: 複数のモデルを 1 つのモデル にパッケージ化する

コンピュートのコストを節約するために、複数のモデルを1つのモデルにパッケージ化することもできます。

複数の MLflow モデルを 1 つの MLflow モデル ノートブック にパッケージ化する

ノートブックを新しいタブで開く