Aller au contenu principal
Dernière mise à jour le

Servez plusieurs modèles à un Endpoint de service de modèles

Cet article décrit comment configurer par programme un endpoint de mise en service de modèle pour servir plusieurs modèles et la répartition du trafic entre eux.

Le déploiement de plusieurs modèles à partir d'un seul Endpoint vous permet de répartir le trafic entre différents modèles afin de comparer leurs performances et de faciliter les tests A/B. Vous pouvez également déployer différentes versions d'un modèle simultanément, ce qui facilite l'expérimentation de nouvelles versions tout en maintenant la version actuelle en production.

Vous pouvez déployer n'importe lequel des types de modèles suivants sur un Endpoint de Model Serving. Vous ne pouvez pas déployer différents types de modèles sur un seul endpoint. Par exemple, vous ne pouvez pas déployer un modèle personnalisé et un modèle externe dans le même Endpoint.

Exigences​

Consultez les Conditions requises pour la création d'Endpoint de déploiement de modèles.

Pour comprendre les options de contrôle d'accès pour les endpoints de service de modèle et obtenir des conseils sur les meilleures pratiques pour la gestion des endpoints, consultez ACL d'endpoint de service.

Créez un Endpoint et définissez la répartition initiale du trafic​

Lorsque vous créez des endpoints de Model Serving à l’aide de l’API Model Serving ou de l’ interface utilisateur Model Serving, vous pouvez également définir la répartition initiale du trafic pour les modèles que vous souhaitez servir sur cet endpoint. Les sections suivantes fournissent des exemples de configuration de la répartition du trafic pour plusieurs modèles personnalisés ou modèles de fondation servis sur un Endpoint.

Déployez plusieurs modèles personnalisés sur un Endpoint​

L'exemple d'API REST suivant crée un seul Endpoint avec deux modèles personnalisés dans Unity Catalog et définit la répartition du trafic de l'Endpoint entre ces modèles. L'entité servie, current, héberge la version 1 de model-A et reçoit 90 % du trafic de l'endpoint, tandis que l'autre entité servie, challenger, héberge la version 1 de model-B et reçoit 10 % du trafic de l'endpoint.

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

Servir plusieurs modèles à un endpoint de throughput provisionné​

L'exemple d'API REST suivant crée un seul Endpoint de throughput provisionné pour les APIs de modèles de fondation avec deux modèles et définit la répartition du trafic de l'Endpoint entre ces modèles. Le Endpoint nommé multi-pt-model, héberge la version 2 de meta_llama_v3_1_70b_instruct qui reçoit 60 % du trafic du Endpoint, et héberge également la version 3 de meta_llama_v3_1_8b_instruct qui reçoit 40 % du trafic du Endpoint.

Bash

POST /api/2.0/serving-endpoints
{
   "name":"multi-pt-model"
   "config":
   {
      "served_entities":
      [
         {
            "name":"meta_llama_v3_1_70b_instruct",
            "entity_name":"system.ai.meta_llama_v3_1_70b_instruct",
            "entity_version":"4",
            "min_provisioned_throughput":0,
            "max_provisioned_throughput":2400
         },
         {
            "name":"meta_llama_v3_1_8b_instruct",
            "entity_name":"system.ai.meta_llama_v3_1_8b_instruct",
            "entity_version":"4",
            "min_provisioned_throughput":0,
            "max_provisioned_throughput":1240
         }
      ],
      "traffic_config":
      {
         "routes":
         [
            {
               "served_model_name":"meta_llama_v3_1_8b_instruct",
               "traffic_percentage":"60"
            },
            {
               "served_model_name":"meta_llama_v3_1_70b_instruct",
               "traffic_percentage":"40"
            }
         ]
      }
   }
}

Déployer plusieurs modèles externes vers un endpoint​

Vous pouvez également configurer plusieurs modèles externes dans un endpoint de service tant qu'ils ont tous le même type de tâche et que chaque modèle possède un name unique. Vous ne pouvez pas avoir à la fois des modèles externes et des modèles non externes dans le même endpoint de service.

L'exemple suivant crée un endpoint de service qui achemine 50 % du trafic vers gpt-4 fourni par OpenAI et les 50 % restants vers claude-3-opus-20240229 fourni par Anthropic.

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

Mettre à jour la répartition du trafic entre les modèles servis​

Vous pouvez également mettre à jour la répartition du trafic entre les modèles servis. L'exemple d'API REST suivant définit le modèle servi, current, pour recevoir 50 % du trafic de l'endpoint et l'autre modèle, challenger, pour recevoir les 50 % de trafic restants.

Vous pouvez également effectuer cette mise à jour depuis la tab Serving de l'interface utilisateur de Databricks en utilisant le bouton Modifier la configuration .

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

Interroger des modèles individuels derrière un Endpoint​

Dans certains scénarios, vous pourriez vouloir interroger des modèles individuels derrière l'Endpoint.

Vous pouvez le faire en utilisant :

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

Ici, le modèle servi spécifique est interrogé. Le format de la requête est le même que l'interrogation de l'Endpoint. Lors de l'interrogation du modèle servi individuel, les paramètres de trafic sont ignorés.

Dans le contexte de l'exemple d'endpoint multi-model, si toutes les requêtes sont envoyées à /serving-endpoints/multi-model/served-models/challenger/invocations, alors toutes les requêtes sont traitées par le modèle servi challenger.

Sur cette page