Как масштабно обслуживать модели ИИ в мультитенантной среде?

Question

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

Этот кластер обслуживает нескольких клиентов . У каждого покупателя в S3 своя модель ИИ. Каждый файл модели AI в размере S3 имеет размер ~ 50 МБ.

Проблема:

Допустим, этот кластер состоит из 10 серверов и обслуживает 20 клиентов. Соответственно, в S3 есть 20 моделей AI.

В наивном решении каждый сервер в кластере может в конечном итоге загрузить все 20 моделей из S3 в память сервера. 20 (серверов в кластере) * 50 МБ (размер модели в S3) = 1 ГБ. Загрузка модели и загрузка ее в память занимает много времени, а объем памяти ограничен объемом памяти сервера. И, конечно же, с масштабом эти проблемы усугубляются.

Итак, какие у меня варианты? Я знаю, что есть готовые продукты для управления жизненным циклом модели, такие как MlFlow, KubeFlow, ... Есть ли в этих продуктах решение проблемы, которую я поднял?

Может быть, использовать Redis в качестве кеша слой?

Может быть, использовать Redis в качестве слоя кеша в сочетании с MlFlow и KubeFlow?

Любое другое решение?

Ограничение: Я не могу имеет липкий сеанс между серверами в этом кластере, поэтому я не могу гарантировать, что все запросы одного и того же клиента попадут на один и тот же сервер.

Answer 1

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

Чтобы решить эту проблему, вы должны запрашивать, зависящие от клиента, к указанному c экземпляру сервера.

В этом случае вам может помочь шаблон «Штампы развертывания». См. https://docs.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp для получения дополнительной информации.

В качестве входной двери (см. Шаблон) NGINX или Spring Cloud Gateway могут быть хорошим решением. Просто посмотрите на заголовок запроса (заголовок авторизации), чтобы получить клиента / пользователя и определить соответствующий экземпляр сервера.

Answer 2

Насколько я понимаю вашу проблему, я бы использовал отдельные обслуживающие серверы для каждой модели. В результате у вас будет 20 серверов обслуживания моделей, которые загружают только 50 МБ данных модели, и сервер будет обслуживать одну модель. Вам также понадобится 1 сервер, на котором хранятся метаданные модели, и он отвечает за отправку входящего запроса на соответствующий сервер обслуживания модели. Эти метаданные будут содержать информацию «клиент против конечной точки обслуживающего сервера модели».

По сути, Kubeflow предлагает вышеуказанное решение в виде пакета, и оно хорошо масштабируется, поскольку использует Kubernetes для оркестровки. Например, когда-нибудь, если вы захотите добавить нового клиента, вы сможете запустить конвейер Kubeflow, который обучит вашу модель, сохранит ее в S3, развернет отдельный сервер модели в кластере Kubeflow и обновит метаданные. Kubeflow предлагает как автоматизацию с использованием конвейерного подхода, так и масштабируемость с помощью Kubernetes.

Минусы Kubeflow на данный момент, на мой взгляд, в том, что сообщество невелико, а продукт улучшается.

Раньше я не использовал MlFlow, поэтому не могу рассказать об этом подробнее.