Servir varios modelos en un endpoint de implementación de modelos

En este artículo se describe cómo configurar mediante programación un punto de conexión de servicio de modelo para atender varios modelos y la división del tráfico entre ellos.

Servir varios modelos desde un único punto de conexión permite dividir el tráfico entre diferentes modelos para comparar su rendimiento y facilitar las pruebas A/B. También puede servir diferentes versiones de un modelo al mismo tiempo, lo que facilita la experimentación con nuevas versiones, a la vez que mantiene la versión actual en producción.

Puede implementar cualquiera de estos tipos de modelos en un endpoint de Model Serving. No se pueden proporcionar tipos de modelo diferentes en un único punto de conexión. Por ejemplo, no puede servir un modelo personalizado y un modelo externo en el mismo punto de conexión.

Requisitos

Consulte los requisitos para crear el endpoint de servicio del modelo.

Para comprender las opciones de control de acceso para los puntos de conexión de servicio de modelos y la guía de procedimientos recomendados para la administración de puntos de conexión, consulte Servicio de ACL de punto de conexión.

Creación de un punto de conexión y establecimiento de la división de tráfico inicial

Al crear puntos de conexión de Model Serving mediante la API de Model Serving o la interfaz de usuario de Model Serving, también puede establecer la distribución inicial del tráfico para los modelos que desea implementar en ese punto de conexión. En las secciones siguientes se proporcionan ejemplos de cómo establecer la división de tráfico para varios modelos personalizados o modelos de base servidos en un punto de conexión.

Servicio de varios modelos personalizados a un punto de conexión

En el ejemplo siguiente de la API REST se crea un único punto de conexión con dos modelos personalizados en el catálogo de Unity y se establece la división del tráfico del punto de conexión entre esos modelos. La entidad atendida, current, hospeda la versión 1 de model-A y obtiene el 90 % del tráfico del punto de conexión, mientras que la otra entidad atendida, challenger, hospeda la versión 1 de model-B y obtiene el 10 % del tráfico del punto de conexión.

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 varios modelos en un endpoint de rendimiento aprovisionado

En el siguiente ejemplo de la API REST se crea un único endpoint con rendimiento aprovisionado de la API de modelos fundacionales con dos modelos y se configura la distribución del tráfico del endpoint entre esos dos modelos. El punto de conexión denominado multi-pt-model, hospeda la versión 2 de meta_llama_v3_1_70b_instruct la cual obtiene el 60 % del tráfico del punto de conexión y también hospeda la versión 3 de meta_llama_v3_1_8b_instruct la cual obtiene el 40 % del tráfico del punto de conexión.


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

Servir varios modelos externos a un punto de conexión

También puede configurar varios modelos externos en un punto de conexión de servicio siempre que todos tengan el mismo tipo de tarea y cada modelo tenga un único name. No puede haber tanto modelos externos como internos en el mismo endpoint de servicio.

En el ejemplo siguiente se crea un endpoint de servicio que dirige el 50 % del tráfico a gpt-4, proporcionado por OpenAI, y el 50 % restante a claude-3-opus-20240229, proporcionado por 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}
            ]
        },
    }
)

Actualización de la división del tráfico entre los modelos servidos

También puede actualizar la división del tráfico entre los modelos servidos. En el siguiente ejemplo de la API REST se establece el modelo servido, current, para obtener el 50 % del tráfico del punto de conexión y el otro modelo, challenger, para obtener el 50 % restante del tráfico.

También puede realizar esta actualización desde la pestaña Serving de la interfaz de usuario de Azure Databricks mediante el botón Edit configuration.

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

Consultar modelos individuales detrás de un punto de conexión

En algunos escenarios, es posible que desee consultar modelos individuales detrás del punto de conexión.

Puede hacerlo mediante:

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

Aquí se consulta el modelo de servicio específico. El formato de la solicitud es el mismo que el de consultar el endpoint. Al consultar el modelo individual servido, se omite la configuración del tráfico.

En el contexto del ejemplo multi-model del punto de conexión, si todas las solicitudes se envían a /serving-endpoints/multi-model/served-models/challenger/invocations, el modelo de solicitud challenger atiende todas las solicitudes.

  • Last updated on