Multi-Model Endpoints

Multi-Model Endpoints — это программно-аппаратный интерфейс (API-эндпоинт), предназначенный для одновременного или последовательного обращения к нескольким различным моделям машинного обучения (ML) в рамках одного запроса или одного развёрнутого сервиса. В отличие от классического Single-Model Endpoint, который обслуживает только одну конкретную модель, Multi-Model Endpoint позволяет маршрутизировать запросы к разным моделям, агрегировать их ответы или выполнять композицию моделей без необходимости развёртывания отдельного эндпоинта для каждой из них. Такие системы активно используются в платформах MLOps, облачных сервисах (например, Amazon SageMaker, Google Vertex AI, Azure ML) и в архитектурах микросервисов для обеспечения гибкости, масштабируемости и снижения операционных затрат.

История и развитие

Концепция Multi-Model Endpoints возникла как ответ на рост числа моделей машинного обучения в промышленной эксплуатации. В начале 2010-х годов, когда ML-модели только начинали внедряться в бизнес-процессы, каждая модель обычно развёртывалась на отдельном сервере или виртуальной машине. Это приводило к неэффективному использованию ресурсов: для редких моделей оборудование простаивало, а для популярных — требовалось масштабирование.

С развитием контейнеризации (Docker, Kubernetes) и облачных платформ (AWS, Google Cloud, Microsoft Azure) в середине 2010-х годов появилась возможность запускать несколько моделей в одном контейнере или кластере. В 2017 году Amazon Web Services (AWS) анонсировала поддержку Multi-Model Endpoints в сервисе Amazon SageMaker, что стало одним из первых коммерческих решений такого рода. Позднее аналогичные функции появились в Google Vertex AI (под названием «Multi-Model Serving») и Azure Machine Learning.

Основным драйвером развития стали задачи, где требуется быстрое переключение между моделями (например, A/B-тестирование, канареечные развёртывания, обслуживание разных версий одной модели для разных клиентов) или когда модели имеют разную частоту запросов, и их объединение позволяет экономить вычислительные ресурсы.

Архитектура и принцип работы

Основные компоненты

Multi-Model Endpoint состоит из следующих ключевых элементов:

Роутер запросов (request router) — компонент, который на основе данных из запроса (например, заголовка X-Model-Name, параметра URL или содержимого тела запроса) определяет, к какой конкретной модели следует направить запрос. Роутер может быть реализован как часть API-шлюза или как отдельный микросервис.
Менеджер моделей (model manager) — отвечает за загрузку, выгрузку и кэширование моделей в оперативной памяти. Он управляет жизненным циклом каждой модели: загружает модель при первом запросе, выгружает при неактивности, обновляет версии.
Исполнительный движок (inference engine) — среда выполнения, в которой непосредственно происходит инференс (вывод) модели. Это может быть библиотека (например, TensorFlow Serving, TorchServe, ONNX Runtime) или собственный код.
Хранилище моделей (model repository) — место хранения файлов моделей (обычно в облачном объектном хранилище, например, Amazon S3, Google Cloud Storage, Azure Blob Storage). Модели могут быть упакованы в контейнеры или представлены в виде сериализованных файлов (например, .pt, .h5, .onnx).

Процесс обработки запроса

Клиент отправляет HTTP-запрос на эндпоинт, указывая идентификатор модели (например, в заголовке X-Amzn-SageMaker-Custom-Attributes или в пути URL).
Роутер запросов извлекает идентификатор модели и проверяет, загружена ли она в память.
Если модель не загружена, менеджер моделей загружает её из хранилища в оперативную память (или на диск, если модель очень большая). Этот процесс может занимать от нескольких секунд до минут.
Исполнительный движок выполняет инференс, передавая входные данные модели.
Ответ возвращается клиенту. После завершения обработки менеджер моделей может выгрузить модель, если она долго не использовалась, чтобы освободить память для других моделей.

Типы маршрутизации

Явная маршрутизация — клиент сам указывает, какую модель вызвать. Наиболее распространённый и простой вариант.
Неявная маршрутизация — система сама выбирает модель на основе правил (например, по региону клиента, по типу данных, по версии модели). Используется в A/B-тестировании и канареечных развёртываниях.
Агрегация — запрос отправляется сразу нескольким моделям, а ответы объединяются (например, усреднение предсказаний ансамбля моделей). Требует синхронизации и обработки таймаутов.

Классификация и виды

По способу развёртывания

Встроенные (on-premise) — Multi-Model Endpoint развёртывается на собственных серверах организации. Требует управления инфраструктурой, но даёт полный контроль над данными.
Облачные (cloud-based) — предоставляются как управляемый сервис облачными провайдерами. Примеры: Amazon SageMaker Multi-Model Endpoints, Google Vertex AI Prediction, Azure ML Managed Endpoints.
Гибридные — часть моделей работает в облаке, часть — на локальных серверах, с единым API-шлюзом.

По типу поддерживаемых моделей

Однородные — все модели имеют одинаковый формат и фреймворк (например, все модели на PyTorch). Упрощает управление, но ограничивает гибкость.
Гетерогенные — поддерживаются модели разных фреймворков (TensorFlow, PyTorch, Scikit-learn, XGBoost) и даже разных форматов (ONNX, PMML). Требует более сложного исполнительного движка.

По масштабу

Малые (до 10 моделей) — часто используются для A/B-тестирования или канареечных развёртываний.
Средние (10–100 моделей) — типичны для крупных организаций, где каждая бизнес-единица использует свою модель.
Крупные (более 100 моделей) — характерны для платформ, предоставляющих ML-модели как услугу (MLaaS), или для систем с большим количеством персонализированных моделей (например, для каждого клиента своя модель).

Применение

A/B-тестирование и канареечные развёртывания

Multi-Model Endpoints позволяют одновременно выставить несколько версий модели (например, старую и новую) и направлять на них часть трафика, сравнивая метрики качества. Это ускоряет итерации и снижает риски при внедрении новых моделей.

Персонализация

В рекомендательных системах и рекламных платформах для каждого пользователя или сегмента может использоваться своя модель. Multi-Model Endpoint позволяет обслуживать тысячи таких моделей, не развёртывая их по отдельности.

Экономия ресурсов

Если модели имеют разную частоту запросов (например, одна модель вызывается 1000 раз в секунду, а другая — 1 раз в час), их объединение на одном эндпоинте позволяет эффективно использовать вычислительные мощности. Модели с низкой частотой загружаются по требованию и выгружаются после использования.

Ансамбли и композиции

Multi-Model Endpoint может использоваться для построения ансамблей моделей (например, голосование нескольких классификаторов) или для последовательной обработки (например, сначала модель детекции объектов, затем модель классификации). В этом случае эндпоинт выступает как оркестратор.

Мультитенантность

В SaaS-платформах, где каждый клиент (тенант) использует свою модель, Multi-Model Endpoint позволяет обслуживать всех клиентов через один API, изолируя модели друг от друга на уровне памяти и конфигурации.

Преимущества и недостатки

Преимущества

Снижение затрат — уменьшение количества развёрнутых экземпляров и, как следствие, экономия на вычислительных ресурсах (виртуальных машинах, GPU).
Упрощение управления — единый API для всех моделей, единая точка мониторинга и логирования.
Гибкость — быстрое добавление, удаление и обновление моделей без перезапуска всего сервиса.
Масштабируемость — возможность автоматического масштабирования эндпоинта в зависимости от общей нагрузки, а не от нагрузки на каждую модель отдельно.

Недостатки

Сложность реализации — требуется разработка роутера, менеджера моделей, механизмов кэширования и выгрузки.
Риск «шумного соседа» — одна модель может потреблять много памяти или процессорного времени, замедляя работу других моделей на том же эндпоинте.
Задержки при холодном старте — если модель долго не использовалась и была выгружена, первый запрос к ней будет обрабатываться дольше из-за загрузки.
Ограничения по памяти — все модели на одном эндпоинте делят оперативную память, поэтому количество одновременно загруженных моделей ограничено.

Интересные факты

В Amazon SageMaker Multi-Model Endpoints по умолчанию поддерживают до 1000 моделей на один эндпоинт, но при необходимости это число может быть увеличено.
В Google Vertex AI для много-модельного обслуживания используется технология «Model Garden», которая позволяет также комбинировать модели разных типов (например, текстовые и графические).
В России аналогичные решения разрабатываются в рамках платформ MLOps, таких как «ML Space» (от «Сбера») и «DataSphere» (от «Яндекса»), однако они не являются публично доступными сервисами в том же объёме, что и западные аналоги.
При использовании Multi-Model Endpoints в облачных сервисах важно учитывать требования законодательства РФ о персональных данных (ФЗ-152), так как модели могут обрабатывать данные пользователей, и передача их за рубеж может быть ограничена.

Критика

Основная критика Multi-Model Endpoints связана с проблемой «шумного соседа»: если одна модель потребляет непропорционально много ресурсов, это может ухудшить качество обслуживания других моделей. Для решения этой проблемы используются механизмы квотирования (resource quotas) и изоляции на уровне контейнеров (например, cgroups в Linux). Также отмечается, что для очень больших моделей (например, больших языковых моделей с миллиардами параметров) Multi-Model Endpoints неэффективны, так как каждая такая модель требует выделенного GPU или TPU, и их объединение не даёт выигрыша.

Источники

Amazon Web Services. «Multi-Model Endpoints in Amazon SageMaker» — документация AWS.
Google Cloud. «Vertex AI Prediction: Multi-Model Serving» — документация Google Cloud.
Microsoft Azure. «Azure Machine Learning Managed Endpoints» — документация Azure.
«MLOps: Model Management and Deployment» — статья в журнале «Journal of Machine Learning Research» (2022).
«Serving Machine Learning Models: A Survey» — обзор в журнале «ACM Computing Surveys» (2023).

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →