Gestire più modelli a un endpoint di gestione del modello

Articolo
11/02/2024

Questo articolo descrive come configurare a livello di codice un endpoint che gestisce un modello per gestire più modelli e il traffico diviso tra di essi.

La gestione di più modelli da un singolo endpoint consente di suddividere il traffico tra modelli diversi per confrontarne le prestazioni e facilitare i test A/B. È anche possibile gestire versioni diverse di un modello contemporaneamente, semplificando l'esperimento con le nuove versioni, mantenendo al tempo stesso la versione corrente nell'ambiente di produzione.

È possibile gestire uno dei tipi di modello seguenti in un endpoint Mosaic AI Model Serving. Non è possibile gestire tipi di modello diversi in un singolo endpoint. Ad esempio, non è possibile gestire un modello personalizzato e un modello esterno nello stesso endpoint.

Modelli personalizzati
Modelli di intelligenza artificiale generativi resi disponibili tramite le API del modello di base con provisioning della velocità effettiva di cui è stato effettuato il provisioning
Modelli esterni

Requisiti

Vedere Requisiti per la creazione dell'endpoint per la gestione del modello.

Per informazioni sulle opzioni di controllo di accesso per gli endpoint Model Serving e per materiale sussidiario sulle procedure consigliate, consultare ACL per endpoint di gestione.

Creare un endpoint e impostare la suddivisione iniziale del traffico

Quando si crea un modello che gestisce gli endpoint usando l'API di gestione dell'intelligenza artificiale di Databricks Mosaic o l'interfaccia utente di Databricks Mosaic per l'interfaccia utente, è anche possibile impostare la suddivisione iniziale del traffico per i modelli da gestire su tale endpoint. Le sezioni seguenti forniscono esempi di impostazione della suddivisione del traffico per più modelli personalizzati o modelli di intelligenza artificiale generativi serviti in un endpoint.

Gestire più modelli personalizzati a un endpoint

L'esempio di API REST seguente crea un singolo endpoint con due modelli personalizzati in Unity Catalog e imposta il traffico dell'endpoint diviso tra tali modelli. L'entità servita, current, ospita la versione 1 di model-A e ottiene il 90% del traffico dell'endpoint, mentre l'altra entità servita, challenger, ospita la versione 1 di model-B e ottiene il 10% del traffico dell'endpoint.

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"
            }
         ]
      }
   }
}

Gestire più modelli a un endpoint di velocità effettiva con provisioning

L'esempio di API REST seguente crea un singolo endpoint di velocità effettiva con provisioning delle API del modello di base con due modelli e imposta la suddivisione del traffico dell'endpoint tra tali modelli. L'endpoint denominato multi-pt-model, ospita la versione 2 di mistral_7b_instruct_v0_1-2 cui ottiene il 60% del traffico dell'endpoint e ospita anche la versione 3 di mixtral_8x7b_instruct_v0_1-3 cui ottiene il 40% del traffico dell'endpoint.


POST /api/2.0/serving-endpoints
{
   "name":"multi-pt-model"
   "config":
   {
      "served_entities":
      [
         {
            "name":"mistral_7b_instruct_v0_1-2",
            "entity_name":"system.ai.mistral_7b_instruct_v0_1",
            "entity_version":"2",
            "min_provisioned_throughput":0,
            "max_provisioned_throughput":1940
         },
         {
            "name":"mixtral_8x7b_instruct_v0_1-3",
            "entity_name":"system.ai.mixtral_8x7b_instruct_v0_1",
            "entity_version":"3",
            "min_provisioned_throughput":0,
            "max_provisioned_throughput":1240
         }
      ],
      "traffic_config":
      {
         "routes":
         [
            {
               "served_model_name":"mistral_7b_instruct_v0_1-2",
               "traffic_percentage":"60"
            },
            {
               "served_model_name":"mixtral_8x7b_instruct_v0_1-3",
               "traffic_percentage":"40"
            }
         ]
      }
   }
}

Gestire molteplici modelli esterni a un endpoint

È anche possibile configurare più modelli esterni in un endpoint di servizio purché abbiano tutti lo stesso tipo di attività e ogni modello abbia un univoco name. Non è possibile avere modelli esterni e modelli non esterni nello stesso endpoint di gestione.

Nell'esempio seguente viene creato un endpoint di servizio che indirizza il 50% del traffico a gpt-4 fornito da OpenAI e il 50% rimanente fornito claude-3-opus-20240229 da Anthropic.

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

Aggiornare la suddivisione del traffico tra i modelli gestiti

È anche possibile aggiornare la suddivisione del traffico tra i modelli gestiti. L'esempio di API REST seguente imposta il modello servito, current, per ottenere il 50% del traffico dell'endpoint e l'altro modello, challenger, per ottenere il 50% rimanente del traffico.

È anche possibile eseguire questo aggiornamento dalla scheda Servizio nell'interfaccia utente di Databricks Mosaic AI usando il pulsante Modifica configurazione.

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"
         }
      ]
   }
}

Eseguire query su singoli modelli dietro un endpoint

In alcuni scenari potrebbe essere necessario eseguire query su singoli modelli dietro l'endpoint.

A tale scopo, è possibile usare:

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

In questo caso viene eseguita una query sul modello gestito specifico. Il formato della richiesta equivale all'esecuzione di query sull'endpoint. Durante l'esecuzione di query sul singolo modello gestito, le impostazioni del traffico vengono ignorate.

Nel contesto dell'esempio multi-model di endpoint, se tutte le richieste vengono inviate a /serving-endpoints/multi-model/served-models/challenger/invocations, allora tutte le richieste vengono gestite dal modello gestito challenger.

Condividi tramite