Платформа управления вычислениями Run.ai предлагает новые подходы к виртуализации и эффективному распределению ресурсов GPU в кластерах Kubernetes. В рамках спецвыпуска Solutions Guide на подкасте The TWIML AI Podcast основатель проекта Сэм Чаррингтон и ведущий инженер по решениям Run.ai Гай Султан подробно разобрали, как специализированный планировщик помогает дата-сайентистам избегать простоев дорогостоящего оборудования. В центре внимания — технологии динамического квотирования, запуск интерактивных сессий на долях графических процессоров и интеграция с популярными MLOps-инструментами.
🛠️ Проблема стандартного планировщика Kubernetes в задачах AI 0:00
Современная индустрия искусственного интеллекта практически полностью перешла на контейнеризацию. Как отмечает Гай Султан, Kubernetes де-факто стал новым стандартом для оркестрации контейнеров в AI-экосистеме. Однако базовый планировщик (scheduler), поставляемый с Kubernetes по умолчанию, создавался для традиционных веб-приложений и микросервисов. Он абсолютно не приспособлен для специфики глубокого обучения и задач AI, поскольку не обладает механизмами гибкого управления графическими процессорами.
Главный недостаток стандартного подхода заключается в статическом выделении ресурсов. Обычно администраторы закрепляют за каждым дата-сайентистом фиксированное количество GPU (например, один процессор на человека). В этой конфигурации исследователь запускает свои интерактивные сессии для отладки кода или полноценные задачи на обучение моделей.
Однако реальная потребность исследователей в вычислительных мощностях постоянно колеблется. В один день команде может потребоваться массивный пул GPU для обучения тяжелой модели на огромном датасете, а в другие дни процессоры будут простаивать. Подобное статическое квотирование приводит к катастрофически низкой утилизации дорогостоящего оборудования.
📊 Динамическое квотирование и гарантированные лимиты 4:24
Для решения проблемы неэффективного использования оборудования компания Run.ai разработала собственный кастомный планировщик для Kubernetes. В этой системе все запускаемые вычислительные задачи привязываются к конкретным проектам, которые могут представлять собой как отдельных исследователей, так и целые рабочие группы.
Вместо жестких статических ограничений Run.ai вводит концепцию так называемых гарантированных квот (guaranteed quota). Механизм их работы строится на следующих принципах:
- Обеспечение базовых прав: если для «Команды А» установлена гарантированная квота в 2 GPU, система обязуется мгновенно предоставить эти ресурсы по первому запросу.
- Автоматический выход за пределы лимита (Over-quota): если в текущий момент в кластере есть свободные графические процессоры (например, «Команда Б» не использует свою долю), планировщик автоматически позволяет «Команде А» выйти за рамки квоты.
- Использование всей мощности кластера: в периоды отсутствия конкуренции одна команда может легитимно задействовать абсолютно все свободные GPU в кластере для проведения дополнительных экспериментов.
Такой подход позволяет радикально повысить общую продуктивность инженеров и максимизировать утилизацию аппаратного обеспечения. При этом, по словам Гая Султана, хорошей практикой администрирования остается конфигурация, при которой сумма всех гарантированных квот не превышает совокупный объем GPU в физическом кластере. Это позволяет железно выполнять обязательства перед всеми проектными группами.
⚖️ Алгоритм справедливого распределения и вытеснение задач 10:19
Динамическое превышение лимитов неизбежно порождает вопрос: что происходит, когда кластер загружен на 100%, и одной из команд внезапно требуются её гарантированные графические процессоры? Для разрешения таких конфликтов Run.ai имплементировала проприетарный алгоритм справедливого распределения (fairness algorithm), работающий поверх базового планировщика.
Когда возникает дефицит ресурсов, система выполняет автоматическое вытеснение (preemption):
- Планировщик находит задачи той команды, которая в данный момент сильнее всего превысила свою законную квоту.
- Одна из избыточных задач этой команды автоматически приостанавливается и отправляется обратно в очередь (pending queue).
- Освободившийся GPU мгновенно передается той группе, которая запросила свои гарантированные ресурсы.
Гай Султан особо подчеркнул, что вытесняемая задача не уничтожается бесследно. Система бережно ставит её на паузу, фиксирует время ожидания в очереди и автоматически сохраняет последнее состояние вычислений (checkpoint). Как только в кластере снова появится свободное место, планировщик возобновит выполнение этой задачи с той же самой точки. Весь процесс происходит полностью автоматически и не требует ручного вмешательства администраторов.
Ведущий Сэм Чаррингтон точно охарактеризовал эту схему, отметив, что Run.ai фактически реализовала аналог спотовых инстансов (spot instances) облачных провайдеров, но на базе собственного локального оборудования организации. Гость подтвердил эту аналогию, добавив, что это лучший способ заставить работать оборудование, которое иначе бы просто простаивало.
🧩 Виртуализация GPU и работа с дробными ресурсами 17:46
В реальной практике задачи дата-сайентистов делятся на два принципиально разных типа: тяжелое обучение моделей (training) и интерактивные сессии разработки (interactive sessions), такие как написание и отладка кода. Если для обучения требуются целые графические процессоры или даже их связки, то для интерактивной отладки зачастую нужна лишь небольшая часть вычислительной мощности.
Инженеру бывает необходимо запустить короткий цикл вычислений в Jupyter Notebook, чтобы просто проверить корректность работы алгоритма. Выделять под это целый дорогой GPU — непозволительная роскошь. К сожалению, ни стандартный Kubernetes, ни базовые драйверы видеокарт не умеют делить один физический GPU между изолированными контейнерами на дробные части.
Компания Run.ai решила эту проблему с помощью собственной технологии глубокой виртуализации GPU. Разработанное решение позволяет запрашивать и выделять фиксированные доли физического процессора:
- Половину GPU (0.5);
- Треть GPU (0.33);
- Ровно 20% от совокупной мощности.
Данная виртуализация работает абсолютно на любых архитектурах графических плат NVIDIA, будь то относительно старые Tesla, популярные V100 или доступные T4. В рамках демонстрации Гай Султан запустил три независимые интерактивные сессии Jupyter Notebook, назначив каждой ровно по 1/3 от одного физического GPU Tesla T4. Попадая внутрь терминала такой сессии и запуская стандартную утилиту nvidia-smi, пользователь видит изолированный сегмент — ровно треть от общего объема видеопамяти графического адаптера.
При этом виртуализация полностью прозрачна: дата-сайентистам не нужно переписывать свой код, вносить изменения в Docker-образы или менять конфигурационные файлы. Все работает «из коробки». В результате на кластере из четырех физических GPU клиенты Run.ai могут одновременно запускать по 20 или даже 40 интерактивных рабочих сред для инженеров, полностью ликвидировав очереди на этапе разработки.
🔄 Технология Swap: борьба с «нулевой» утилизацией 23:33
Разделение задач на тренировочные и интерактивные диктует разные правила управления их жизненным циклом. Обучение моделей — это длительный, автономный процесс, который может идти часами или днями, поэтому такие задачи можно безболезненно вытеснять в очередь. Но с интерактивными сессиями разработчиков так поступать нельзя: если посреди написания кода сессия инженера внезапно прервется и «умрет» из-за вытеснения, это приведет к отвратительному пользовательскому опыту. Поэтому интерактивный софт работает строго в рамках гарантированных квот и не подвергается принудительной остановке.
Тем не менее интерактивные среды таят в себе скрытую угрозу для эффективности кластера. Даже если за Jupyter Notebook закреплена всего треть графического процессора, реальная утилизация этого чипа большую часть времени равна 0%. Инженер не считает код непрерывно: он подолгу изучает строки, анализирует логи, уходит на обед или переключается на другие задачи, пока выделенная видеопамять удерживается контейнером впустую.
Для борьбы с этим явлением Run.ai анонсировала скорый выход новой технологии под названием Swap (на момент записи видео до релиза оставалось несколько недель). Суть технологии заключается в динамическом «закулисном» перераспределении памяти:
- Мониторинг активности: система фиксирует, что интерактивная сессия удерживает дробный GPU, но реальная нагрузка на чип отсутствует.
- Временный перехват: если в очереди стоит готовая к запуску задача обучения, планировщик временно забирает неиспользуемый GPU у спящего Jupyter Notebook и отдает его на обучение.
- Мгновенный возврат контекста: как только исследователь возвращается к работе и нажимает кнопку выполнения кода в своем блокноте, система Swap мгновенно и незаметно возвращает графический процессор интерактивной сессии.
По заверениям Гая Султана, обратное переключение происходит с минимальной, практически незаметной просадкой производительности. Инженер даже не поймет, что его GPU секунду назад выполнял чужие вычисления, а общая эффективность утилизации железа в компании приблизится к максимуму.
🗺️ Гетерогенные кластеры, шаблоны и управление CPU/RAM 13:33
На практике крупные компании редко имеют однородный парк оборудования. Чаще всего они обладают гетерогенными кластерами, сочетающими разные поколения ускорителей: например, сверхмощные NVIDIA A100 соседствуют с более старыми V100 и энергоэффективными T4.
Интерфейс администратора Run.ai позволяет гибко сопоставлять типы вычислительных нагрузок с конкретными архитектурами чипов на уровне настроек проектов. Администратор может жестко прописать правила: ресурсоемкие задачи обучения (train jobs) всегда направляются на производительные ускорители уровня V100 или A100. В то же время легковесные интерактивные сессии автоматически маршрутизируются на карты T4.
Для управления конфигурациями в платформе предусмотрено два типа шаблонов:
- Пользовательские шаблоны (User Templates): исследователи могут самостоятельно сохранять часто используемые параметры конфигурации, чтобы разворачивать новые контейнеры в пару кликов.
- Административные шаблоны (Admin Templates): позволяют ограничить хаотичный ввод параметров. Вместо ручного заполнения текстовых полей node affinity (привязки к узлам), базирующейся на стандартных метках Kubernetes, ученый получает строгий выпадающий список доступных типов нод, одобренных системными администраторами.
Несмотря на то, что фокус платформы смещен в сторону GPU, Run.ai полноценно управляет и стандартными компонентами вычислений — CPU и оперативной памятью (RAM). В расширенном меню распределения ресурсов пользователь может запустить задачу с нулевым использованием GPU, но при этом запросить, к примеру, ровно 8 ядер CPU и жестко лимитировать объем доступной оперативной памяти. Все эти метрики транслируются на встроенную панель аналитики, позволяя отслеживать динамику потребления CPU и RAM за любые исторические периоды.
🔄 Интеграция с экосистемой MLOps и конвейерами Kubeflow 28:12
Создатели Run.ai четко позиционируют свой продукт на рынке: платформа располагается на нижних уровнях инфраструктурного стека, максимально близко к аппаратному ускорению и физическим GPU. Компания не стремится заменить устоявшиеся и удобные для дата-сайентистов инструменты разработки. Напротив, ключевая стратегия заключается в бесшовной интеграции с популярными экосистемами оркестрации, такими как Kubeflow, Airflow, MLflow и JupyterHub.
В качестве примера глубокой интеграции Гай Султан привел open-source платформу Kubeflow, которая стремительно набирает популярность благодаря развитому механизму построения автоматических конвейеров (pipelines). Типичный конвейер Kubeflow состоит из последовательных шагов:
- Сбор и предобработка сырых данных;
- Непосредственное обучение модели;
- Верификация и тестирование полученных результатов;
- Деплой (развертывание) готовой модели в промышленную эксплуатацию (production).
Поскольку Kubeflow разворачивается поверх Kubernetes, инженерам Run.ai удалось полностью подменить стандартный планировщик под капотом этой системы. В такой конфигурации дата-сайентист продолжает использовать привычный интерфейс Kubeflow для описания шагов пайплайна и не заходит в консоль Run.ai.
Однако в момент выполнения каждого шага вычисления контролируются умным планировщиком Run.ai. Задачи из пайплайна Kubeflow автоматически начинают подчиняться правилам установленных приоритетов, получают возможность динамически выходить за рамки квот, вытеснять чужие фоновые процессы или работать на изолированных дробных долях физических графических плат. Вся активность при этом прозрачно отображается на едином графическом дашборде администратора Run.ai.
