NVIDIA Run:ai — оркестрация GPU
Введение: Что такое NVIDIA Run:ai
NVIDIA Run:ai представляет собой корпоративный уровень оркестрации GPU-ресурсов поверх Kubernetes, созданный для превращения разрозненных серверов с ускорителями в единый пул вычислительных мощностей. Платформа снимает аппаратные ограничения планировщика контейнеров, динамически нарезая видеокарты под задачи инференса, интерактивной разработки и распределенного обучения.
Проблема утилизации GPU в Kubernetes
Классический планировщик Kubernetes изначально проектировался под процессоры и оперативную память, поэтому со стандартным плагином устройства он воспринимает видеокарту как неделимую единицу. Если дата-сайентист запускает Jupyter Notebook с легкой моделью, резервирующей 4 ГБ видеопамяти, кластер блокирует весь графический процессор целиком. В результате ускорители уровня H100 или A100 на 80 ГБ часто почти пустые: ноутбук запросил 4 ГБ, а планировщик отдал всю карту.
Попытки решить эту проблему штатными средствами несут технические компромиссы. Технология аппаратного разделения NVIDIA MIG требует перезапуска конфигураций и жестко делит ресурсы на фиксированные профили, а time-slicing на уровне драйвера не защищает процессы от ошибок нехватки памяти (OOM) соседних задач. Run:ai устраняет этот разрыв с помощью специализированного планировщика и программного перехвата обращений к API видеокарт.
Сравнение методов оркестрации GPU
| Метод оркестрации | Гранулярность памяти | Динамическое выделение | Защита от OOM | Поддержка очередей и квот |
|---|---|---|---|---|
| Стандартный Kubernetes | Только целая карта | Нет | Базовая | Отсутствует из коробки |
| Аппаратный NVIDIA MIG | Фиксированные профили | Требует реконфигурации | Полная изоляция | Зависит от внешнего софта |
| NVIDIA Run:ai | Произвольные доли в МБ | Полная динамика на лету | Программный контроль | Встроенный многоуровневый планировщик |
Архитектура и ключевые механизмы
Система состоит из двух логических уровней: централизованной панели управления и агентов, развертываемых внутри каждого вычислительного кластера. Центральный Control Plane управляет пользователями, правами доступа, политиками очередей и финансовым биллингом, не имея прямого доступа к закрытым данным или весам моделей. Вычислительный контур монтируется непосредственно поверх рабочего дистрибутива Kubernetes через Helm-чарты или операторы.
KAI Scheduler работает как специализированный Kubernetes-планировщик для AI- и ML-нагрузок и может функционировать в одном кластере рядом с другими. Он поддерживает очереди, gang scheduling, приоритеты и topology-aware размещение задач с учетом заданной топологии узлов, включая NVLink-домены и сетевую инфраструктуру кластера.
Механизм дробления ресурсов позволяет запрашивать конкретный объем памяти, например 12 ГБ из доступных 80 ГБ, запуская сразу несколько контейнеров на одном физическом кристалле.
Двухуровневые квоты разделяют гарантированные вычислительные ресурсы и негарантированный овербукинг, позволяя низкоприоритетным задачам занимать простаивающее железо.
Приоритетное вытеснение позволяет освобождать ресурсы, занятые менее приоритетными интерактивными или batch-задачами, если они требуются более важной нагрузке. Для обучающих задач Run может предоставить время на корректное завершение работы, однако сохранение и последующее восстановление контрольной точки должно поддерживаться самим приложением или ML-фреймворком.
Пример распределения ресурсов
Рассмотрим типовой сценарий в кластере на базе четырех восьмичиповых серверов NVIDIA HGX. Днем исследовательская группа инженеров тестирует прототипы и выполняет квантование моделей в интерактивном режиме через веб-интерфейс. Им не требуются полноразмерные чипы, поэтому планировщик выделяет каждому разработчику по 0.25 от физического ускорителя.
Ночью интерактивные задачи уступают ресурсы фоновому обучению большой языковой модели. Планировщик вытесняет низкоприоритетные поды, собирает свободные GPU в полные узлы и выделяет все тридцать два ускорителя одному распределённому заданию на базе PyTorch Elastic или Ray. Если инфраструктура кластера поддерживает GPUDirect RDMA, обучение использует его для быстрого обмена данными между узлами. Если ранним утром бизнес-сервис инференса фиксирует резкий наплыв пользовательских запросов, Run:ai автоматически отбирает несколько видеокарт у ночного обучения и разворачивает дополнительные реплики Triton Inference Server.
От стартапа до поглощения
Стартап Run был основан в 2018 году в Израиле Омри Геллером, Роненом Даром и профессором Меиром Федером. Инженеры сделали ставку на то, что ускоренные вычисления повторят эволюцию классических x86-процессоров тридцатилетней давности, когда переход к виртуализации серверов кардинально изменил экономику дата-центров. За время независимого развития стартап привлек более $118 млн инвестиций от венчурных фондов, собрав клиентскую базу из десятков крупных технологических компаний.
В апреле 2024 года NVIDIA заключила соглашение о приобретении израильского разработчика. Финансовые условия официально не раскрывались, однако, по данным Reuters, стоимость сделки оценивалась примерно в $700 млн. Сделка привлекла повышенное внимание европейских антимонопольных регуляторов, заподозривших производителя чипов в попытке ограничить конкуренцию на смежных программных рынках. Однако в декабре 2024 года Европейская комиссия выдала безусловное одобрение на слияние, после чего поглощение было юридически закрыто.
Заключение: Место платформы в AI-инфраструктуре
Интеграция Run:ai в экосистему NVIDIA AI Enterprise отражает фундаментальную смену бизнес-модели чипмейкера: переход от продажи кремния к лицензированию комплексного стека фабрики искусственного интеллекта. Если классические суперкомпьютерные задачи исторически управлялись шедулером Slurm, то современный генеративный AI строится преимущественно на облачно-нативных веб-сервисах. Приобретя Run:ai, вендор закрыл этот разрыв на уровне оркестрации.
Платформа стала одним из официально поддерживаемых инструментов оркестрации для инфраструктуры NVIDIA, включая DGX SuperPOD и DGX Cloud. При этом в DGX SuperPOD могут использоваться разные системы управления нагрузками, включая Run и Slurm, в зависимости от архитектуры конкретного кластера. Для конечных заказчиков внедрение подобного оркестратора снижает капитальные расходы на покупку новых дорогостоящих карт, а для производителя фиксирует клиентов внутри проприетарной программной среды, где оптимизация CUDA неразрывно связана с логикой распределения контейнеров. Open-source инициативы вокруг ядра KAI Scheduler параллельно помогают компании задавать технические стандарты планирования во всем сообществе открытого кода.
