Servicio de varios modelos a un punto de conexión de servicio 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 servir cualquiera de los siguientes tipos de modelo en un punto de conexión de servicio de modelos de IA de Mosaico. 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 la creación de puntos de conexión 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 servicio de modelos mediante la API de servicio de Databricks Mosaic AI o la interfaz de usuario de servicio de Ia de Mosaico de Databricks, también puede establecer la división inicial del tráfico para los modelos que desea servir 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 IA generativos 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"
            }
         ]
      }
   }
}

Servicio de varios modelos a un punto de conexión de rendimiento aprovisionado

En el ejemplo siguiente de la API REST se crea un único punto de conexión de rendimiento aprovisionado de Foundation Model con dos modelos y se establece la división del tráfico del punto de conexión entre esos modelos. El punto de conexión denominado multi-pt-model, hospeda la versión 2 de mistral_7b_instruct_v0_1-2 la cual obtiene el 60 % del tráfico del punto de conexión y también hospeda la versión 3 de mixtral_8x7b_instruct_v0_1-3 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":"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"
            }
         ]
      }
   }
}

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 tener modelos externos y modelos no externos en el mismo punto de conexión de servicio.

En el ejemplo siguiente se crea un punto de conexión de servicio que enruta el 50 % del tráfico proporcionado gpt-4 por OpenAI y el 50 % restante proporcionado claude-3-opus-20240229 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 Servicio de la interfaz de usuario de Databricks Mosaic AI mediante el botón Editar configuración.

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

Consulta de 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 solicitud es el mismo que consultar el punto de conexión. 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.