Управление конечными точками обслуживания моделей
В этой статье описывается, как управлять конечными точками обслуживания модели с помощью пользовательского интерфейса обслуживания и REST API. Ознакомьтесь со статьей "Обслуживание конечных точек" в справочнике по REST API.
Чтобы создать конечные точки обслуживания моделей, используйте одно из следующих действий:
- Создайте пользовательские конечные точки обслуживания моделей.
- Создайте генерируемую модель ИИ, обслуживающие конечные точки.
Получение состояния конечной точки модели
В пользовательском интерфейсе обслуживания можно проверить состояние конечной точки из индикатора состояния конечной точки обслуживания в верхней части страницы сведений о конечной точке.
Вы можете использовать проверку состояния и сведений конечной точки программным способом с помощью REST API или пакета SDK для развертываний MLflow.
REST API
GET /api/2.0/serving-endpoints/{name}
В следующем примере показано, как получить сведения о конечной точке, которая служит первой версии ads1 модели, зарегистрированной в реестре моделей. Чтобы указать модель из каталога Unity, укажите полное имя модели, включая родительский каталог и схему, catalog.schema.example-modelнапример.
В следующем примере ответа поле "READY" означает, state.ready что конечная точка готова к получению трафика. Поле state.update_state NOT_UPDATING pending_config больше не возвращается, так как обновление успешно завершено.
{
"name": "workspace-model-endpoint",
"creator": "customer@example.com",
"creation_timestamp": 1666829055000,
"last_updated_timestamp": 1666829055000,
"state": {
"ready": "READY",
"update_state": "NOT_UPDATING"
},
"config": {
"served_entities": [
{
"name": "ads1-1",
"entity_name": "ads1",
"entity_version": "1",
"workload_size": "Small",
"scale_to_zero_enabled": false,
"state": {
"deployment": "DEPLOYMENT_READY",
"deployment_state_message": ""
},
"creator": "customer@example.com",
"creation_timestamp": 1666829055000
}
],
"traffic_config": {
"routes": [
{
"served_model_name": "ads1-1",
"traffic_percentage": 100
}
]
},
"config_version": 1
},
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"permission_level": "CAN_MANAGE"
}
Пакет SDK для развертываний MLflow
from mlflow.deployments import get_deploy_client
client = get_deploy_client("databricks")
endpoint = client.get_endpoint(endpoint="chat")
assert endpoint == {
"name": "chat",
"creator": "alice@company.com",
"creation_timestamp": 0,
"last_updated_timestamp": 0,
"state": {...},
"config": {...},
"tags": [...],
"id": "88fd3f75a0d24b0380ddc40484d7a31b",
}
Удаление конечной точки обслуживания модели
Чтобы отключить обслуживание модели, можно удалить конечную точку, в которую она была включена.
Вы можете удалить конечную точку на странице сведений конечной точки в пользовательском интерфейсе обслуживания .
- Щелкните "Служить " на боковой панели.
- Щелкните конечную точку, которую нужно удалить.
- Щелкните меню кебаб в верхней части и нажмите кнопку "Удалить".
Кроме того, можно удалить конечную точку обслуживания программным способом с помощью REST API или пакета SDK для развертываний MLflow.
REST API
DELETE /api/2.0/serving-endpoints/{name}
Пакет SDK для развертываний MLflow
from mlflow.deployments import get_deploy_client
client = get_deploy_client("databricks")
client.delete_endpoint(endpoint="chat")
Отладка конечной точки обслуживания модели
Для отладки любых проблем с конечной точкой можно получить следующее:
- Журналы сборки контейнеров сервера модели
- Журналы сервера модели
Эти журналы также доступны из пользовательского интерфейса конечных точек на вкладке "Журналы ".
Для журналов сборки для обслуживаемой модели можно использовать следующий запрос:
GET /api/2.0/serving-endpoints/{name}/served-models/{served-model-name}/build-logs
{
“config_version”: 1 // optional
}
Для журналов сервера модели для модели обслуживания можно использовать следующий запрос:
GET /api/2.0/serving-endpoints/{name}/served-models/{served-model-name}/logs
{
“config_version”: 1 // optional
}
Управление разрешениями в конечной точке обслуживания модели
Для изменения разрешений необходимо иметь по крайней мере разрешение CAN MANAGE на конечной точке обслуживания. Дополнительные сведения о уровнях разрешений см. в разделе "Обслуживание списков управления доступом конечных точек".
Получите список разрешений в конечной точке обслуживания.
databricks permissions get servingendpoints <endpoint-id>
Предоставьте пользователю jsmith@example.com разрешение CAN QUERY на конечную точку обслуживания.
databricks permissions update servingendpoints <endpoint-id> --json '{
"access_control_list": [
{
"user_name": "jsmith@example.com",
"permission_level": "CAN_QUERY"
}
]
}'
Вы также можете изменить разрешения конечной точки обслуживания с помощью API разрешений.
Получение схемы конечной точки обслуживания модели
Внимание
Поддержка схем запросов конечных точек доступна в общедоступной предварительной версии. Эта функция доступна в регионах обслуживания моделей.
Схема запроса конечной точки обслуживания — это формальное описание конечной точки обслуживания с помощью стандартной спецификации OpenAPI в формате JSON. Он содержит сведения о конечной точке, включая путь к конечной точке, сведения о запросе конечной точки, например формате текста запроса и ответа, а также типе данных для каждого поля. Эта информация может быть полезной для сценариев воспроизведения или при необходимости информации о конечной точке, но не является создателем исходной конечной точки или владельцем.
Чтобы получить схему конечной точки обслуживания модели, модель должна иметь подпись модели, зарегистрированную в журнале, и конечная точка должна находиться в READY состоянии.
В следующих примерах показано, как программно получить схему конечной точки обслуживания модели с помощью REST API. Сведения о схемах конечных точек обслуживания функций см. в разделе "Что такое Служба компонентов Databricks?".
Схема, возвращаемая API, находится в формате объекта JSON, следующего за спецификацией OpenAPI.
ACCESS_TOKEN="<endpoint-token>"
ENDPOINT_NAME="<endpoint name>"
curl "https://example.databricks.com/api/2.0/serving-endpoints/$ENDPOINT_NAME/openapi" -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json"
Сведения о ответе схемы
Ответ — это спецификация OpenAPI в формате JSON, включая такие поля, как openapi, infoservers и paths. Так как ответ схемы является объектом JSON, его можно проанализировать с помощью общих языков программирования и создать клиентский код из спецификации с помощью сторонних средств.
Вы также можете визуализировать спецификацию OpenAPI с помощью сторонних инструментов, таких как Редактор Swagger.
К основным полям ответа относятся:
- В
info.titleполе отображается имя конечной точки обслуживания. - Поле
serversвсегда содержит один объект, какurlправило, поле, которое является базовым URL-адресом конечной точки. - Объект
pathsв ответе содержит все поддерживаемые пути для конечной точки. Ключи в объекте — ЭТО URL-адрес пути. Каждыйpathможет поддерживать несколько форматов входных данных. Эти входные данные перечислены вoneOfполе.
Ниже приведен пример ответа схемы конечной точки:
{
"openapi": "3.1.0",
"info": {
"title": "example-endpoint",
"version": "2"
},
"servers": [{ "url": "https://example.databricks.com/serving-endpoints/example-endpoint"}],
"paths": {
"/served-models/vanilla_simple_model-2/invocations": {
"post": {
"requestBody": {
"content": {
"application/json": {
"schema": {
"oneOf": [
{
"type": "object",
"properties": {
"dataframe_split": {
"type": "object",
"properties": {
"columns": {
"description": "required fields: int_col",
"type": "array",
"items": {
"type": "string",
"enum": [
"int_col",
"float_col",
"string_col"
]
}
},
"data": {
"type": "array",
"items": {
"type": "array",
"prefixItems": [
{
"type": "integer",
"format": "int64"
},
{
"type": "number",
"format": "double"
},
{
"type": "string"
}
]
}
}
}
},
"params": {
"type": "object",
"properties": {
"sentiment": {
"type": "number",
"format": "double",
"default": "0.5"
}
}
}
},
"examples": [
{
"columns": [
"int_col",
"float_col",
"string_col"
],
"data": [
[
3,
10.4,
"abc"
],
[
2,
20.4,
"xyz"
]
]
}
]
},
{
"type": "object",
"properties": {
"dataframe_records": {
"type": "array",
"items": {
"required": [
"int_col",
"float_col",
"string_col"
],
"type": "object",
"properties": {
"int_col": {
"type": "integer",
"format": "int64"
},
"float_col": {
"type": "number",
"format": "double"
},
"string_col": {
"type": "string"
},
"becx_col": {
"type": "object",
"format": "unknown"
}
}
}
},
"params": {
"type": "object",
"properties": {
"sentiment": {
"type": "number",
"format": "double",
"default": "0.5"
}
}
}
}
}
]
}
}
}
},
"responses": {
"200": {
"description": "Successful operation",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"predictions": {
"type": "array",
"items": {
"type": "number",
"format": "double"
}
}
}
}
}
}
}
}
}
}
}
}
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по