Udostępnij za pośrednictwem

Obsługa wielu modeli w punkcie końcowym obsługującym model

  • Artykuł

W tym artykule opisano sposób programowego konfigurowania punktu końcowego obsługującego model w celu obsługi wielu modeli i podziału ruchu między nimi.

Obsługa wielu modeli z jednego punktu końcowego umożliwia podzielenie ruchu między różnymi modelami w celu porównania ich wydajności i ułatwienia testowania A/B. Można również obsługiwać różne wersje modelu w tym samym czasie, co ułatwia eksperymentowanie z nowymi wersjami przy jednoczesnym zachowaniu bieżącej wersji w środowisku produkcyjnym.

W punkcie końcowym obsługi modelu mozaiki AI można obsłużyć dowolny z następujących typów modeli. Nie można obsługiwać różnych typów modeli w jednym punkcie końcowym. Na przykład nie można obsłużyć modelu niestandardowego i modelu zewnętrznego w tym samym punkcie końcowym.

Wymagania

Zobacz Wymagania dotyczące tworzenia punktu końcowego obsługującego model.

Aby poznać opcje kontroli dostępu dla punktów końcowych obsługujących model i wskazówki dotyczące najlepszych rozwiązań dotyczących zarządzania punktami końcowymi, zobacz Obsługa list ACL punktów końcowych.

Tworzenie punktu końcowego i set początkowego podziału ruchu

Podczas tworzenia modeli obsługujących punkty końcowe przy użyciu interfejsu API usługi Databricks Mosaic AI lub interfejsu API mozaiki usługi Databricks obsługującego interfejsu użytkownikamożna również set początkowego podziału ruchu dla modeli, które mają być używane w tym punkcie końcowym. W poniższych sekcjach przedstawiono przykłady ustawiania podziału ruchu dla wielu modeli niestandardowych lub modeli podstawowych obsługiwanych w punkcie końcowym.

Obsługa wielu modeli niestandardowych w punkcie końcowym

Poniższy przykład interfejsu API REST tworzy pojedynczy punkt końcowy z dwoma modelami niestandardowymi w środowisku Unity Catalog i ustawia podział ruchu punktu końcowego między tymi modelami. Obsługiwana jednostka, current, hostuje wersję 1 i model-A pobiera 90% ruchu punktu końcowego, podczas gdy druga obsługiwana jednostka , challengerhostuje wersję 1 i model-B pobiera 10% ruchu punktu końcowego.

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

Udostępnianie wielu modeli punktowi końcowemu aprowizowanej przepływności

Poniższy przykład interfejsu API REST tworzy pojedynczy punkt końcowy aprowizowanej przepływności interfejsów API modelu foundation z dwoma modelami i ustawia ruch punktu końcowego między tymi modelami. Punkt końcowy o nazwie multi-pt-model, hostuje wersję 2 mistral_7b_instruct_v0_1-2 , z której otrzymuje 60% ruchu punktu końcowego, a także hostuje wersję 3 mixtral_8x7b_instruct_v0_1-3 , z której otrzymuje 40% ruchu punktu końcowego.


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

Udostępnianie wielu modeli zewnętrznych do punktu końcowego

Można również skonfigurować wiele modeli zewnętrznych w punkcie końcowym obsługującym, o ile wszystkie mają ten sam typ zadania, a każdy model ma unikatowy nametyp . Nie można mieć zarówno modeli zewnętrznych, jak i modeli innych niż zewnętrzne w tym samym punkcie końcowym obsługującym.

Poniższy przykład tworzy punkt końcowy obsługujący, który kieruje 50% ruchu do gpt-4 udostępnionego przez usługę OpenAI, a pozostałe 50% do claude-3-opus-20240229 udostępnionego przez antropię.

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

Update podział ruchu między obsługiwanymi modelami

Można również update podział ruchu między obsługiwanymi modelami. Poniższy przykład interfejsu API REST ustawia obsługiwany model, current, na get 50% ruchu punktu końcowego, a drugi model, challenger, na get pozostałe 50% ruchu.

Możesz również ustawić tę update na karcie Serwowanie w interfejsie użytkownika Databricks Mosaic AI za pomocą przycisku Edytuj konfigurację.

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

Wykonywanie zapytań dotyczących poszczególnych modeli za punktem końcowym

W niektórych scenariuszach możesz chcieć wykonywać zapytania dotyczące poszczególnych modeli za punktem końcowym.

Możesz to zrobić przy użyciu:

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

W tym miejscu zostanie zapytany określony obsługiwany model. Format żądania jest taki sam jak wykonywanie zapytań względem punktu końcowego. Podczas wykonywania zapytań względem pojedynczego obsługiwanego modelu ustawienia ruchu są ignorowane.

W kontekście przykładu punktu końcowego multi-model , jeśli wszystkie żądania są wysyłane do /serving-endpoints/multi-model/served-models/challenger/invocationsusługi , wszystkie żądania są obsługiwane przez challenger model obsługiwany.