Развертывайте пользовательские LLM с помощью сервиса Custom Model Serving

Important

Эта функция доступна в бета-версии. Администраторы рабочей области могут управлять доступом к этой функции на странице "Предварительные версии ". См. статью "Управление предварительными версиями Azure Databricks".

На этой странице показано, как развернуть пользовательские большие языковые модели (LLM) в службе моделей с помощью подсистемы vLLM . Используйте этот рабочий процесс для обслуживания точно настроенных моделей, вариантов PEFT, многомодальных моделей и других базовых моделей, которые недоступны в API-интерфейсах модели Foundation (FMAPI). Начальная записная книжка в конце этой страницы содержит весь выполняемый код для следующих действий.

Когда следует использовать настраиваемую службу LLM

Azure Databricks рекомендует использовать пользовательскую службу LLM при наличии одного из следующих вариантов использования:

  • Полностью настроенные модели с пользовательскими весами, которые вы обучали на Azure Databricks.
  • Модели от Hugging Face, недоступные в FMAPI.
  • Пользовательские рецепты PEFT, не поддерживаемые FMAPI.
  • Специализированные модели за пределами каталога FMAPI, такие как MedGemma.
  • Многомодальные модели (язык визуального распознавания), такие как Qwen/Qwen2.5-VL-3B-Instruct.
  • Внедрение моделей, которые недоступны в FMAPI, например nomic-ai/nomic-embed-text-v2-moe.
  • Любая модель, которая соответствует 1xH100 (80 ГБ памяти GPU).

Requirements

Шаг 1. Настройка среды

Создайте блокнот для бессерверных GPU-вычислений с графическим процессором A10. Установите vLLM и его зависимости. Начальная записная книжка закрепляет проверенную версию vLLM.

Можно также указать зависимости через бессерверную среду вместо использования %pip install.

Important

Установите рабочий каталог на локальный жесткий диск (например, с помощью tempfile.mkdtemp()). Файловая /Workspace система не поддерживает большие файлы, такие как вес модели.

Шаг 2. Скачивание модели

Скачайте веса модели из Hugging Face с помощью snapshot_download. Стартовый блокнот использует Qwen/Qwen3-4B в качестве примера, но вы можете заменить её на любую модель, которая укладывается в объём памяти выбранного графического процессора, в том числе одну из следующих:

  • Мультимодальные модели, такие как Qwen/Qwen2.5-VL-3B-Instruct, для сценариев, объединяющих зрение и язык.
  • Более крупные модели, которые соответствуют 1xH100, например openai/gpt-oss-120b.

Выберите GPU в зависимости от потребностей вашей модели в памяти и производительности.

графический процессор (GPU) Память GPU workload_type
T4 16 ГБ GPU_SMALL
A100 80 ГБ GPU_LARGE

Шаг 3. Тестирование модели локально с помощью vLLM

Перед развертыванием протестируйте модель непосредственно в бессерверной записной книжке GPU, запустив локальный сервер vLLM. Локальное тестирование позволяет проверять модель, экспериментировать с параметрами vLLM и устранять неполадки перед созданием конечной точки обслуживания.

Основные сведения:

  • Бессерверные вычисления GPU позволяют выполнять локальное тестирование только через порты 3000–3999. Выберите порт из этого диапазона; стартовый ноутбук использует 3080.
  • Сервер vLLM предоставляет API, совместимый с OpenAI, по адресу /invocations.
  • Вы можете протестировать как обычные, так и потоковые запросы.
  • Настройте такие параметры, как --dtype, --max-model-lenи --gpu-memory-utilization для модели.
  • Добавьте --enforce-eager для более быстрого запуска, ценой некоторого снижения производительности инференса.
  • Для более крупных моделей используйте бессерверный вариант GPU H100 для локального тестирования.

Если вы удовлетворены конфигурацией, остановите локальный сервер перед продолжением.

Шаг 4. Регистрация модели с помощью пользовательской точки входа

Этот шаг подключает локальную настройку к службе модели и имеет следующие требования к конфигурации:

  • Должны task быть "llm/v1/chat" (модели чата, включая многомодальные) или "llm/v1/embeddings" (внедренные модели). См. раздел "Поддерживаемые задачи".
  • Точка входа должна быть открыта на порту 8080 — порту, который ожидает Model Serving.
  • Команда точки входа должна совпадать с той, которую вы тестировали на шаге 3, но с портом 8080 вместо вашего локального порта.
  • Точка входа запускается из папки артефактов модели MLflow, поэтому пути модели относятся к этой папке.

Для модели чата:

metadata = {
    "task": "llm/v1/chat",
    "entrypoint": (
        "python -u -m vllm.entrypoints.openai.api_server "
        "--model qwen3 --served-model-name qwen "
        "--host 0.0.0.0 --port 8080 "
        "--dtype float16 --max-model-len 16384 "
        "--gpu-memory-utilization 0.85"
    ),
}

Для модели внедрения установите task"llm/v1/embeddings" и запустите сервер в режиме внедрения. В версии vLLM, используемой здесь, то есть --runner pooling (старые версии vLLM используют --task embed):

metadata = {
    "task": "llm/v1/embeddings",
    "entrypoint": (
        "python -u -m vllm.entrypoints.openai.api_server "
        "--model nomic-embed --served-model-name nomic-embed "
        "--runner pooling "
        "--host 0.0.0.0 --port 8080 "
        "--gpu-memory-utilization 0.85"
    ),
}

Поддерживаемые задачи

task Тип модели Область запросов
llm/v1/chat Модели чата, включая многомодальные (язык визуального распознавания) chat.completions
llm/v1/embeddings Внедрение моделей embeddings

Указанный task должен соответствовать тому, что фактически предоставляет ваша точка входа: точка входа должна предоставлять OpenAI-совместимый API для этой задачи на порте 8080. В приведенных выше примерах используется vLLM, но любой сервер, соответствующий этому контракту, работает. Другие типы задач, например llm/v1/completions, не поддерживаются.

Шаг 5. Регистрация модели в каталоге Unity

Зарегистрируйте модель в каталоге Unity с помощью mlflow.register_model. Обслуживание пользовательских LLM основано на express deployments, поэтому при регистрации используется параметр env_pack="databricks_model_serving", и требуются mlflow>=3.12 и databricks-sdk>=0.102.0.

Например, добавьте в записную книжку следующую команду:


model_version = mlflow.register_model(model_info.model_uri, UC_MODEL_NAME, env_pack="databricks_model_serving")

Шаг 6. Создание конечной точки обслуживания

Создайте конечную точку в пользовательском интерфейсе или программно с помощью Azure Databricks SDK. Ключевыми решениями являются тип вычислений, размер рабочей нагрузки и поведение масштабирования до нуля.

Выберите workload_type в зависимости от вашей модели и облака:

workload_type графический процессор (GPU) Примечания.
GPU_SMALL 1x T4 (16 ГБ) Наименьший вариант.
GPU_LARGE 1x A100 (80 ГБ) Рекомендуется для больших рабочих нагрузок LLM.

workload_size (Small, Medium или Large) определяет количество выделенных реплик для этой конечной точки. Используйте Small для разработки и нагрузок с низкой интенсивностью трафика.

В следующем примере показана типичная конфигурация:

ServedEntityInput(
    entity_name="main.<catalog>.<model_name>",
    entity_version="<version>",
    workload_type=ServingModelWorkloadType.GPU_MEDIUM,
    workload_size="Small",
    scale_to_zero_enabled=True,
)

Масштабирование до нуля и планирование мощностей

В бета-версии обслуживание пользовательской LLM-модели выделяет фиксированное количество реплик для вашей конечной точки. Автоматическое масштабирование для числа реплик больше нуля пока не поддерживается, поэтому необходимо задать размер workload_type и workload_size с учетом пикового трафика. Конечная точка ставит запросы в очередь, если их количество превышает емкость подготовленных реплик.

Установите значение scale_to_zero_enabled=True, чтобы конечный узел масштабировался до нуля реплик в отсутствие нагрузки. Холодные запуски являются медленными— загрузка весов модели и запуск vLLM обычно занимает от одного до нескольких минут.

Для рабочих нагрузок, чувствительных к задержке, или критически важных для производственной среды задайте scale_to_zero_enabled=False и подберите размер workload_size с учетом пикового трафика заранее.

Предупреждение

Вертикальное масштабирование не гарантируется. Всякий раз, когда Azure Databricks необходимо получить новый GPU для конечной точки — при создании, workload_size увеличении или при пробуждении конечной точки от нуля— запрос может перестать отвечать, если поставщик облачных служб не имеет емкости GPU в вашем регионе. Это относится ко всем типам GPU. Databricks смягчает эту проблему с помощью прогретых пулов и предварительного резервирования, которые поддерживают доступность и готовность ресурсов GPU.

Шаг 7. Запрос конечной точки

После того как конечная точка будет готова, она автоматически появится на игровой площадке ИИ на странице конечной точки. Вы также можете запросить его программным способом с помощью пакета SDK Databricks, пакета SDK OpenAI или curl.

Модели чата (llm/v1/chat):

Databricks SDK

w.serving_endpoints.query(
    name="<endpoint-name>",
    messages=[ChatMessage(role=ChatMessageRole.USER, content="Hello")],
)

OpenAI SDK

client = OpenAI(
    api_key=DATABRICKS_TOKEN,
    base_url=f"{DATABRICKS_HOST}/serving-endpoints",
)
client.chat.completions.create(
    model="<endpoint-name>",
    messages=[{"role": "user", "content": "Hello"}],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Hello"}]}' \
  https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations

Внедрение моделей (llm/v1/embeddings):

OpenAI SDK

client = OpenAI(
    api_key=DATABRICKS_TOKEN,
    base_url=f"{DATABRICKS_HOST}/serving-endpoints",
)
client.embeddings.create(
    model="<endpoint-name>",
    input=["The quick brown fox jumps over the lazy dog."],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"input":["The quick brown fox jumps over the lazy dog."]}' \
  https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations

Некоторые модели внедрения ожидают префикс конкретной задачи для каждого входного ввода (например, nomic-embed-text-v2-moe использует search_query: и search_document:). Проверьте карточку вашей модели, чтобы узнать требования к входным данным.

Отслеживайте свое конечное устройство

Пользовательское обслуживание LLM использует ту же инфраструктуру наблюдаемости, что и стандартные конечные точки обслуживания пользовательских моделей, но с несколькими дополнительными возможностями, специфичными для vLLM, описанными в следующих разделах.

Динамические журналы

На вкладке Журналы страницы конечной точки в интерфейсе Serving в режиме реального времени отображаются stdout и stderr из вашего процесса vLLM. Вы также можете открыть эти выходные данные через API журналов.

Сохраненные журналы и метрики

Если телеметрия включена, журналы и метрики сохраняются в Delta-таблицах Unity Catalog для долгосрочного хранения, выполнения SQL-запросов и соблюдения нормативных требований. Полные инструкции по настройке, требования и схемы таблиц см. в разделе Сохранение пользовательских данных обслуживания моделей в Unity Catalog.

Конкретно для обслуживания настраиваемых LLM:

  • Журналы: stdout и stderr из процесса vLLM записываются автоматически. Код ведения журнала на стороне приложения не требуется.
  • Метрики: Azure Databricks автоматически считывает метрики с Prometheus-эндпоинта сервера vLLM /metrics и сохраняет их вместе с журналами. По умолчанию вы получаете задержку для каждого запроса, пропускную способность, количество токенов, глубину очереди и использование кэша KV.

Запросы к данным телеметрии

Во время бета-версии не существует пользовательского интерфейса для визуализации журналов или метрик. Запрос сохраненных данных непосредственно в каталоге Unity с помощью SQL или записной книжки. См. схемы метрик и журналов, описанные в разделе Сохранение пользовательских данных обслуживания моделей в Unity Catalog.

В следующей записной книжке показано, как проанализировать и визуализировать сохраненные метрики vLLM:

Настраиваемая записная книжка для обслуживания метрик LLM

Получите ноутбук

Пример записной книжки

Разработайте и протестируйте модель в бессерверном GPU-блокноте, а затем зарегистрируйте и разверните ту же конфигурацию как конечную точку обслуживания. Ниже приведён блокнот, содержащий полный выполняемый процесс из данного руководства.

Пользовательская записная книжка для обслуживания LLM

Получите ноутбук

Ограничения

Следующие ограничения применяются во время бета-версии.

  • Автоматическое масштабирование между репликами не выполняется. Поддерживается масштабирование до нуля.
  • Поддерживаются только задачи чата (llm/v1/chatвключая мультимодальные) и задачи внедрения (llm/v1/embeddings). См. раздел "Поддерживаемые задачи".
  • Нет оптимизации маршрута.
  • Нет пользовательского интерфейса для визуализации журналов или метрик. Запрашивайте телеметрию непосредственно в Unity Catalog.

Обратитесь в свою команду по работе с учетной записью Azure Databricks, если у вас есть вопросы или отзывы.

Во время регистрации истекает время ожидания загрузки артефакта

Когда вы регистрируете модель с помощью env_pack, Azure Databricks загружает упакованные веса модели и среду как артефакты (model_version.tar и model_environment.tar). При databricks-sdk использовании более ранних 0.102.0версий отправка больших артефактов LLM может завершиться через пять минут и завершить регистрацию ошибкой, как показано ниже:

MlflowException: The following failures occurred while uploading one or more artifacts to
/Models/<catalog>/<schema>/<model>/<version>: {
  '.../model_environment.tar': "TimeoutError('Timed out after 0:05:00')",
  '.../model_version.tar': "TimeoutError('Timed out after 0:05:00')"
}

Чтобы устранить эту проблему, выполните обновление databricks-sdk>=0.102.0 и повторно зарегистрируйте модель:

%pip install databricks-sdk>=0.102.0
  • Last updated on