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 ustawianie początkowego podziału ruchu

Podczas tworzenia modeli obsługujących punkty końcowe przy użyciu interfejsu API obsługującego sztuczną inteligencję usługi Databricks lub interfejsu użytkownika usługi Databricks Mosaic AI można również ustawić początkowy podział 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 generowania modeli sztucznej inteligencji 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 katalogu aparatu Unity 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}
            ]
        },
    }
)

Aktualizowanie podziału ruchu między obsługiwanymi modelami

Można również zaktualizować podział ruchu między obsługiwanymi modelami. Poniższy przykład interfejsu API REST ustawia obsługiwany model , currentw celu uzyskania 50% ruchu punktu końcowego i innego modelu, challengerw celu uzyskania pozostałego 50% ruchu.

Tę aktualizację można również wprowadzić na karcie Obsługa w interfejsie użytkownika interfejsu użytkownika mozaiki usługi Databricks 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.