NVIDIA Run:ai: платформа оркестрации GPU стала открытой

ИИ 11 мин чтения 56 просмотров

NVIDIA выложила полную платформу Run:ai в открытый доступ. Это расширяет платформу NVIDIA DSX AI Factory и даёт заказчикам, разработчикам и партнёрам экосистемы доступ к production-инструментам оркестрации AI-нагрузок и GPU. Исходный код опубликован в организации NVIDIA DSX AI Factory на GitHub, а готовый стек доступен на NGC как Community Product с Helm-чартом для установки.

Run:ai несколько лет помогал организациям запускать AI-нагрузки на Kubernetes в масштабе: динамически распределять ресурсы GPU и управлять рабочими нагрузками на всём жизненном цикле — от обработки данных и обучения до инференса. Открытие кода позволяет любому партнёру экосистемы DSX и AI-облаку повышать пропускную способность нагрузок, улучшать утилизацию GPU и эффективнее эксплуатировать общую AI-инфраструктуру. NVIDIA последовательно открывает свои инфраструктурные проекты: так же появился, например, маршрутизатор локального ИИ-инференса NVIDIA PAIR.

Четыре компонента, которые можно ставить по отдельности

Релиз включает полную платформу и четыре модульных компонента, которые можно внедрять независимо: KAI Scheduler, GPU Fractioning Operator, KAI Resource Management и Workload Map. Вместе с остальным кодом платформы они образуют интегрированный Run:ai. Команды могут взять платформу целиком, строить на ней свои продукты или подключать отдельные компоненты под свои задачи.

KAI Scheduler: планировщик для GPU-нагрузок

KAI Scheduler — это Kubernetes-планировщик, на котором работает Run:ai. NVIDIA открыла его под лицензией Apache 2.0 и передала в CNCF как Sandbox-проект. Все доработки планировщика идут через одно сообщество-репозиторий, так что улучшения попадают в общий код.

Планировщик рассчитан на GPU-нагрузки в масштабе и умеет:

  • gang scheduling с предварительным моделированием в памяти — многоподовые задачи размещаются по принципу «всё или ничего» и не вытесняются без нужды;
  • fair-share (включая time-based) и распределение квот, чтобы доли ресурсов между командами оставались сбалансированными;
  • топологическую осведомлённость и bin-packing на уровне решения о размещении;
  • разделение GPU, когда несколько нагрузок делят одну или несколько карт (MIG, MPS, разделение по времени, HaMi, дробление MPS в CUDA 13.4);
  • поддержку Dynamic Resource Allocation (DRA).

KAI Scheduler разворачивается в существующем кластере рядом с текущим стеком ПО и не требует всей платформы Run:ai. Вопросы задают в канале #kai-scheduler в CNCF Slack, код — в репозитории kai-scheduler/KAI-Scheduler.

GPU Fractioning Operator: доли GPU на Kubernetes

Платформа Run:ai давно поддерживает дробное выделение GPU: несколько нагрузок делят одну карту с жёсткой изоляцией памяти. Доли запрашиваются по требованию и настраиваются на лету, без предварительной подготовки узла администратором. Это одна из самых востребованных возможностей у ML-команд, которые запускают нагрузки, не требующие всей памяти GPU, — интерактивные ноутбуки и инференс небольших моделей. Раньше это была проприетарная реализация.

GPU Fractioning Operator переносит CUDA-нативное дробление GPU в Kubernetes, а проприетарную реализацию вывели из эксплуатации в пользу нативной возможности CUDA 13.4. Драйвер CUDA жёстко ограничивает память GPU для каждой нагрузки, и каждая видит только свою долю. Оператор даёт кластеру способ это потреблять: он включает CUDA-доли GPU и экспортирует метрики по каждой доле в разрезе пода. Это слой интеграции с Kubernetes, позволяющий нагрузкам использовать нативное дробление CUDA; он не привязан к конкретному планировщику.

Оператор подходит для нагрузок, которые могут делить неиспользуемую ёмкость GPU: ноутбуков, сессий разработки и небольших моделей. Он интегрируется с KAI Scheduler, превращая доступную ёмкость GPU в реальное решение о размещении, но остаётся совместим и с другими планировщиками. Начать можно с документации GPU Fractioning Operator.

KAI Resource Management: кто что получает

Планировщик решает, куда положить работу, а KAI Resource Management — кому что достаётся:

  • Проекты и подразделения — организационная структура, привязывающая ресурсы к командам и инициативам, которые их потребляют.
  • Управление ресурсами с иерархией — возможность выделять, гарантировать и делить ёмкость GPU по этой структуре с семантикой fair-share и квот.
  • Пулы узлов — группировка и таргетинг разнородного железа, чтобы нагрузки попадали на нужные ресурсы.

Вместе это позволяет платформенным командам выйти за рамки сырого планирования Kubernetes и управлять GPU так, как реально работают организации: по командам, подразделениям, инициативам и гарантиям ресурсов. Например, платформенная команда может гарантировать 50% кластера исследователям и при этом не дать ни одной команде монополизировать остаток. Если квоты сейчас ведутся в таблице, а неймспейсы на каждую команду поддерживаются вручную, этот слой заменяет такую практику. Он сочетается с KAI Scheduler в кластерах.

Workload Map: единый контракт на типы нагрузок

Workload Map — это контракт, который Run:ai использует для поддержки любого типа нагрузок. KAI Scheduler применяет его для планирования и gang-семантики, остальная платформа — для обнаружения нагрузок, мониторинга и управления жизненным циклом.

В Kubernetes AI-нагрузка почти никогда не бывает голым Deployment или Job. Это PyTorchJob, RayCluster, JobSet, KServe InferenceService, развёртывание графа Dynamo или собственный custom resource компании. У каждого типа своя внутренняя структура, компоненты с разными ролями (driver и workers, head и workers, prefill и decode), своя семантика масштабирования и gang, свой способ отчитываться о статусе.

Workload Map даёт единый способ трактовать такие нагрузки как first-class объекты на всём жизненном цикле: описывать поды, компоненты и роли; отправлять и конфигурировать; планировать с учётом gang и топологии; единообразно наблюдать статус и здоровье; применять политики при admission или в рантайме.

Этот слой лежит между примитивами Kubernetes и планировщиками, дашбордами, SRE- и troubleshooting-инструментами, средствами учёта затрат, бэкапа и ML-платформами. Вместо того чтобы каждому инструменту строить частную частичную интеграцию под каждый CRD, Workload Map описывает тип нагрузки один раз — и любой инструмент может планировать, наблюдать, действовать и управлять им единообразно, ничего не хардкодя. Он поставляется как Go-библиотека, работающая офлайн на неструктурированных объектах, так что подключить её можно, ничего не добавляя в кластер. Специально узкий: Workload Map описывает структуру нагрузки и не планирует, не ставит в очередь, не масштабирует и не распространяет между кластерами.

Model Streamer и Grove: ускорение загрузки и оркестрация инференса

Два связанных проекта решают смежные задачи и подключаются независимо.

Model Streamer снижает задержку холодного старта. Запуск инференса на Kubernetes может занимать несколько минут, в течение которых GPU выделены, но простаивают на одном шаге — загрузке весов модели из хранилища в память GPU. Model Streamer читает веса параллельно и стримит их напрямую в память GPU, сокращая время загрузки больших моделей. Он уже встроен в vLLM и SGLang, где включается флагом --load-format runai_streamer, а также в ModelExpress. Поддержаны локальные файловые системы, S3-совместимые хранилища и сетевые файловые шары.

Крупные облака документируют Model Streamer в своих руководствах: в AWS он входит в vLLM Deep Learning Container и рекомендован как быстрый путь в официальной документации EKS для инференса, в Google Cloud есть нативная поддержка Cloud Storage, в Microsoft Azure — интеграция с Azure Blob Storage. Опубликованные бенчмарки на восьми виртуальных машинах с NVIDIA H100 показывают загрузку в 3–6 раз быстрее стандартного загрузчика и стабильные 80 Гбит/с против примерно 40 Гбит/с у стандартного пути. Партнёры по хранению данных тоже измерили результат: WEKA — 3,5 секунды, примерно на 40% быстрее загрузки с локального NVMe; VAST Data — 1,7 секунды, улучшение на 60%; DDN — 65,5 ГБ модели Qwen3-32B на 8 GPU менее чем за четыре секунды, что экономит до 10% суточного времени работы GPU по сравнению с локальным хранилищем.

Grove даёт один API для любой архитектуры инференса. Новые паттерны нагрузок — агентные конвейеры, разделённый инференс, обучение mixture-of-experts — состоят из нескольких связанных компонентов, которые должны масштабироваться вместе. Grove предоставляет Kubernetes API для оркестрации таких нагрузок: от одного пода до развёртываний на десятки тысяч GPU. Он даёт топологически осведомлённый автомасштабинг и иерархический gang scheduling, позволяя компонентам вроде prefill и decode стартовать как единое целое по принципу «всё или ничего». На NVIDIA GB200 NVL72 он автоматически управляет ресурсами ComputeDomain, включая многоузловую производительность NVLink одной аннотацией вместо рукописного YAML. Grove — модульная часть NVIDIA Dynamo, которую можно использовать отдельно; недавно добавилась поддержка llm-d и Volcano как backend-планировщика, поддержка Kueue в работе. Для команд, которым нужен не оркестратор, а рантайм для агентных запусков, есть отдельные решения вроде Shepherd — Python-рантайма для форка и отката агентных запусков.

Как внедрять и что с лицензиями

Полный исходный код Run:ai лежит в репозитории NVIDIA Run:ai в организации NVIDIA DSX AI Factory на GitHub. Команды могут изучать код, контрибьютить, строить на платформе или брать модульные компоненты по отдельности. Полная открытая платформа доступна и на NVIDIA NGC как Community Product с Helm-чартом для установки интегрированного стека.

Исходный код регулируется применимыми открытыми лицензиями. Загрузка Community Product из NGC требует принятия лицензионного соглашения NVIDIA Software License Agreement и Product-Specific Terms for NVIDIA AI Products. Платная подписка Run:ai и право на поддержку NVIDIA для Community Product не требуются, но корпоративная поддержка NVIDIA в него не входит.

Для развёртываний NVIDIA Enterprise AI Factory платформа по-прежнему доступна через коммерческие предложения с поддержкой NVIDIA, включая отдельный продукт, NVIDIA Mission Control и NVIDIA AI Enterprise, а также отдельные облачные маркетплейсы. Доступность, лицензирование и условия поддержки зависят от предложения.

Партнёры экосистемы DSX

Восемь партнёров экосистемы NVIDIA DSX интегрируют открытую платформу в свои продукты:

  • Crusoe — интеграция с Crusoe Managed Kubernetes: оркестрация GPU-нагрузок плюс управляемый Kubernetes и GPU-инфраструктура.
  • Mirantis — расширяет k0rdent AI платформой Run:ai, получая стек AI-фабрики «от металла до модели» с жизненным циклом под управлением и автоматическим провижинингом инфраструктуры.
  • Nebius — предлагает Run:ai как развёртывание приложения в один клик в Nebius AI Cloud на Nebius Managed Service for Kubernetes.
  • OpenNebula Systems — интегрирует Run:ai с OpenNebula AI Cloud Platform через OneKS для открытых и суверенных AI-облаков.
  • Rafay — расширяет интеграцию до полностью управляемого сервиса: автоматизирует весь стек от GPU-инфраструктуры и кластеров до control plane и тенантов Run:ai, чтобы провайдеры и предприятия предлагали его через свои каталоги самообслуживания.
  • Saturn Cloud — интеграция для запуска white-label сервисов AI-инференса через платформу Token Factory, включая выделенный и мультитенантный model serving, поминутный учёт токенов и автоматический биллинг.
  • Spectro Cloud — интеграция в PaletteAI: развёртывание через PaletteAI Studio и управление той же автоматизацией жизненного цикла, что и для остальной AI-инфраструктуры.
  • vCluster — предоставляет Run:ai через предварительно проверенные шаблоны развёртывания: полное окружение на каждого тенанта, что усиливает границы тенантов, пока Run:ai продолжает планировать в рамках одного пула GPU.

Частые вопросы

Что именно NVIDIA открыла?

Полную платформу Run:ai для оркестрации AI-нагрузок и GPU, включая четыре модульных компонента: KAI Scheduler, GPU Fractioning Operator, KAI Resource Management и Workload Map. Код — в организации NVIDIA DSX AI Factory на GitHub, стек — на NGC.

Нужна ли платная подписка, чтобы попробовать?

Нет. Для Community Product из NGC платная подписка Run:ai и право на поддержку NVIDIA не требуются, но и корпоративная поддержка в него не входит. Нужно принять лицензионное соглашение NVIDIA и Product-Specific Terms.

Как поставить платформу целиком?

На NGC доступен Community Product с Helm-чартом для установки интегрированного стека. Отдельные компоненты можно внедрять независимо, если полная платформа не нужна.

KAI Scheduler можно поставить в существующий кластер?

Да, он разворачивается рядом с текущим стеком ПО и не требует всей платформы Run:ai. Это Kubernetes-планировщик под лицензией Apache 2.0, переданный в CNCF как Sandbox-проект.

Что случилось с проприетарным дроблением GPU?

Проприетарную реализацию вывели из эксплуатации в пользу нативной возможности CUDA 13.4. GPU Fractioning Operator — слой интеграции с Kubernetes, который позволяет нагрузкам использовать CUDA-нативное дробление и даёт метрики по долям в разрезе пода.

Обязателен ли KAI Scheduler для GPU Fractioning Operator?

Нет. Оператор с ним интегрируется, превращая доступную ёмкость GPU в решение о размещении, но остаётся совместим и с другими планировщиками.

Что даёт Model Streamer на практике?

Сокращает холодный старт инференса, стримя веса модели напрямую в память GPU. В бенчмарках на восьми H100 — загрузка в 3–6 раз быстрее и стабильные 80 Гбит/с против примерно 40 Гбит/с у стандартного загрузчика.

Workload Map планирует нагрузки?

Нет, он сознательно узкий: описывает структуру нагрузки, компоненты и роли, но не планирует, не ставит в очередь, не масштабирует и не распространяет между кластерами. Поставляется как Go-библиотека, работает офлайн и не требует ничего добавлять в кластер.

Для каких нагрузок подходит Grove?

Для графовых нагрузок с разными ролями и связанным масштабированием — агентных конвейеров, разделённого инференса, обучения mixture-of-experts. На GB200 NVL72 он автоматически управляет ComputeDomain, включая многоузловую производительность NVLink одной аннотацией.

Останется ли Run:ai доступен с поддержкой NVIDIA?

Да, для развёртываний NVIDIA Enterprise AI Factory платформа доступна через коммерческие предложения с поддержкой: отдельным продуктом, через NVIDIA Mission Control и NVIDIA AI Enterprise, а также в отдельных облачных маркетплейсах. Условия зависят от предложения.

Источник: developer.nvidia.com