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

複数のモデルをモデルサービングエンドポイントに提供する

備考

プレビュー

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

この記事では、複数のモデルとそれらの間でトラフィックを分割するようにモデルサービングエンドポイントをプログラムで設定する方法について説明します。

1 つのエンドポイントから複数のモデルを提供することで、トラフィックを異なるモデル間で分割してパフォーマンスを比較し、A/B テストを容易にすることができます。 また、モデルの異なるバージョンを同時に提供することもできるため、現在のバージョンを本番運用に保持しながら、新しいバージョンでのエクスペリメントが容易になります。

次のモデルタイプのいずれかを Mosaic AI Model Serving エンドポイントで提供できます。 1 つのエンドポイントで異なるモデルタイプを提供することはできません。 たとえば、カスタムモデルと外部モデルを同じエンドポイントで提供することはできません。

必要条件​

モデルサービングエンドポイント作成の要件 を参照してください。

モデルサービング エンドポイントのアクセスコントロールオプションとエンドポイント管理のベストプラクティスガイダンスについては、 サービングエンドポイント ACLを参照してください。

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

Databricks Mosaic AI サービング API または Databricks Mosaic AI サービング UI を使用してモデルサービングエンドポイントを作成する場合、そのエンドポイントでサブリングするモデルの初期トラフィック分割を設定することもできます。 次のセクションでは、エンドポイントで提供される複数のカスタムモデルまたは基盤モデルのトラフィック分割を設定する例を示します。

エンドポイントに複数のカスタムモデルを提供する​

次の REST API の例では、Unity Catalog に 2 つのカスタム モデルを持つ 1 つのエンドポイントを作成し、それらのモデル間でエンドポイント トラフィックの分割を設定します。 配信されるエンティティ currentは、 model-A のバージョン 1 をホストし、エンドポイント トラフィックの 90% を取得します。一方、他の配信エンティティである challengerは、 model-B のバージョン 1 をホストし、エンドポイント トラフィックの 10% を取得します。

Bash
POST /api/2.0/serving-endpoints

{
   "name":"multi-model"
   "config":
   {
      "served_entities":
      [
         {
            "name":"current",
            "entity_name":"catalog.schema.model-A",
            "entity_version":"1",
            "workload_size":"Small",
            "scale_to_zero_enabled":true
         },
         {
            "name":"challenger",
            "entity_name":"catalog.schema.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"
            }
         ]
      }
   }
}

エンドポイントで複数の外部モデルをサービングする​

また、すべての外部モデルが同じタスクタイプを持ち、各モデルに固有のnameがある限り、サービングエンドポイントで複数の外部モデルを設定することもできます。外部モデルと非外部モデルの両方を同じサービスエンドポイントに含めることはできません。

次の例では、トラフィックの 50% を OpenAI が提供する gpt-4 にルーティングし、残りの 50% を Anthropic が提供する claude-3-opus-20240229 にルーティングするサービングエンドポイントを作成します。

Python
import mlflow.deployments

client = mlflow.deployments.get_deploy_client("databricks")

client.create_endpoint(
    name="mix-chat-endpoint",
    config={
        "served_entities": [
            {
                "name": "served_model_name_1",
                "external_model": {
                    "name": "gpt-4",
                    "provider": "openai",
                    "task": "llm/v1/chat",
                    "openai_config": {
                        "openai_api_key": "{{secrets/my_openai_secret_scope/openai_api_key}}"
                    }
                }
            },
            {
                "name": "served_model_name_2",
                "external_model": {
                    "name": "claude-3-opus-20240229",
                    "provider": "anthropic",
                    "task": "llm/v1/chat",
                    "anthropic_config": {
                        "anthropic_api_key": "{{secrets/my_anthropic_secret_scope/anthropic_api_key}}"
                    }
                }
            }
        ],
        "traffic_config": {
            "routes": [
                {"served_model_name": "served_model_name_1", "traffic_percentage": 50},
                {"served_model_name": "served_model_name_2", "traffic_percentage": 50}
            ]
        },
    }
)

配信されるモデル間で分割されたトラフィックを更新する​

また、提供されるモデル間のトラフィック分割を更新することもできます。 次の REST API の例では、提供されるモデル currentがエンドポイント トラフィックの 50% を取得するように設定され、他のモデル challengerがトラフィックの残りの 50% を取得するように設定されています。

この更新は、Databricks Mosaic AI UI の サービス タブから 構成の編集 ボタンを使用して行うこともできます。

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

{
   "served_entities":
   [
      {
         "name":"current",
         "entity_name":"catalog.schema.model-A",
         "entity_version":"1",
         "workload_size":"Small",
         "scale_to_zero_enabled":true
      },
      {
         "name":"challenger",
         "entity_name":"catalog.schema.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"
         }
      ]
   }
}

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

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

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

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

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

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

に最終更新