Коммерческий релиз Evolution Stack.ML: как собрать гибридный ML‑завод с on‑premise данными и GPU в облаке

Во многих компаниях своя инфраструктура, строгая безопасность и несколько команд, которые конкурируют за один GPU‑парк. Эксперименты запускают, но до стабильных ML‑сервисов в продакшене доходит немногое. Мы решили эти проблемы MLOps-платформой Evolution Stack.ML для обучения и тюнинга ИИ-моделей и разработки ИИ-приложений, которая на днях вышла в коммерческую эксплуатацию.

Теперь крупный бизнес может работать с ИИ в своем контуре и масштабироваться в облако. Ниже — подробнее о платформе и о том, как собрать на нашей платформе гибридный ML‑завод, в котором данные остаются в контуре, а тяжелое обучение и пики нагрузки переезжают в публичное облако.

Из каких проблем выросла Evolution Stack.ML

На входе у нас были типичные запросы клиентов:

• «У нас уже есть GPU, но их утилизация низкая, а инвестиций много».

• «Данные по требованиям ИБ остаются только в контуре, но нам нужны мощные ресурсы и эксперименты».

• «Несколько команд одновременно борются за один парк серверов».

• «Мы бы хотели один понятный путь от кода до продакшена, а не отдельный проект под каждую новую модель».

В среднем, по внутренним замерам, до запуска платформы утилизация корпоративных GPU‑кластеров держалась на уровне порядка 30–35%. Evolution Stack.ML вместе с сервисом Evolution Distributed Train помогает поднять утилизацию до 80–90% и за счет этого окупить вложения в серверную инфраструктуру за несколько месяцев, а не лет.

Какой контур мы считаем правильным

Вместо отдельных сервисов и скриптов мы пошли от идеи ML‑завода: один конвейер, который ведет данные и модели от первых экспериментов до продакшена и может при этом жить и в локальном, и в облачном кластере.

Наша платформа собирает вокруг себя четыре очевидных, но обычно разорванных части: подачу данных, среду разработки, запуск задач и управляемый слой GPU‑ресурсов.

Над базовой инфраструктурой заказчика (CPU- и GPU-серверы, NVMe, NFS и S3-хранилища) развернут Evolution Stack.ML с Kubernetes и сервисами уровня OSS/BSS: IAM, биллинг, логирование, мониторинг и уведомления. Поверх них живут ML‑сервисы — Data Transfer, Jobs, Jupyter Notebooks, Experiments, Model Monitoring, Deploys и Allocations, которые работают как единый слой для всех команд.

В чем преимущества такого подхода ⬇️

1️⃣ Единый конвейер вместо пула точечных сервисов.

Пайплайн выглядит так: ресурсный слой → Data Transfer → Jupyter → Deploys/Jobs. 

• Data Transfer отвечает за перенос данных из источников в хранилище, работает через transfer‑воркеры и коннекторы к S3, NFS, PostgreSQL, Oracle и другим системам. Поддерживается ручная и автоматическая миграция данных с учетом прав доступа и аудита.

• Jupyter‑серверы поднимаются как сервисы в командных пространствах. Это Jupyter Notebook / JupyterLab с готовыми Docker и Singularity образами, доступом по SSH из IDE и поддержкой экспериментов через MLflow, TensorBoard и WandB.

• Задачи обучения запускаются на 1…N GPU с использованием Horovod и PyTorch DDP: под капотом декларативные job‑описания, которые можно гонять и on-premise, и в облаке.

• Ресурсный слой построен вокруг аллокаций: для команд выделяются отдельные GPU/CPU‑пулы, которые изолируются на уровне Kubernetes, а очереди, приоритеты, спотовые задачи и auto‑shutdown простаивающих подов обеспечивает пропатченный Volcano.

Выход одного этапа является входом для следующего, а не отдельным проектом по интеграции.

2️⃣ Один пользовательский сценарий для on‑premise и облака.

On‑premise и облачная версия Evolution Stack.ML используют одну кодовую базу и одинаковые API, Python SDK и CLI. По сути, гибридный сценарий — это не два разных продукта, а два кластера за одним и тем же контроллером: переносить нагрузку между ними можно конфигурацией (сменой эндпоинтов и ключей доступа), а не переписыванием пайплайнов.

# локальный кластерml-cli job submit --endpoint https://ml.onprem.company ...# тот же пайплайн в облакеml-cli job submit --endpoint https://ml.cloud.ru ...Декларация job остается прежней, меняется только целевой контур и учетные данные.

3️⃣ Управляемая утилизация GPU.

Внутри платформы есть:

• Очереди и приоритеты. Они помогают нескольким подразделениям делить один GPU‑парк без ручных договоренностей: задачи высокой важности не ждут в общей очереди, а эксперименты с низким приоритетом уходят на споты.

• Аллокации и командные пространства. Дают прозрачные квоты и бюджеты, так что администратор ресурсов управляет пулом под конкретную команду или продукт.

• Встроенные механизмы восстановления (self-healing). Автоматически обнаруживают сбои оборудования, перезапускают задачи и заменяют GPU-ноды, обеспечивают стабильное выполнение распределенных задач обучения даже на больших кластерах. 

• Автоотключение по отсутствию нагрузки и спотовый режим. Снижают стоимость эксплуатации: GPU не крутятся пустыми, а пиковые эксперименты выносятся в облако только на время реальной работы.

В результате можно повысить загрузку существующей инфраструктуры и уменьшить потребность в расширении, а также повлиять на TCO и окупаемость.

Evolution Stack.ML теперь доступен в коммерческой эксплуатации: его можно развернуть в своем контуре как основу гибридного ML‑завода и подключить к публичному облаку Cloud.ru, не меняя стек и пользовательские сценарии.

А если хочется посмотреть на архитектуру поближе и рассмотреть живые примеры настройки рабочих пространств, очередей и распределенного обучения на GPU, зовем смотреть запись вебинара «Свой ML‑завод: что дает собственная ML‑платформа и как ее запустить».