NVIDIA Developer рассказывает, что платформа NVIDIA DSX AI Factory объединяет технологии, которые помогают экосистеме проектировать, строить и эксплуатировать более эффективные ИИ-фабрики. В её состав входят программные компоненты с открытым исходным кодом и модульной архитектурой, рассчитанные на многопользовательские среды и масштабирование. Эксплуатация ИИ-фабрики требует общего понимания распределённых нагрузок: их компонентов, шаблонов подов, количества реплик и статуса. В Kubernetes каждый фреймворк описывает эту информацию по-своему. Ресурсы JobSet, LeaderWorkerSet и другие пользовательские ресурсы часто требуют отдельных адаптеров, прежде чем инструмент сможет их интерпретировать и управлять ими. Для решения этой задачи NVIDIA предлагает Workload Map, общее описание структуры рабочих нагрузок Kubernetes, которое пользователи могут повторно применять для разных фреймворков. В составе платформы DSX AI Factory Workload Map позволяет интегрированным планировщикам, контроллерам и платформам понимать поддерживаемые типы нагрузок без поддержки отдельного кода разбора для каждого фреймворка. В материале показано, как описать распределённую нагрузку JobSet один раз, а затем использовать это описание для инспекции, группового планирования и наблюдения на уровне платформы. Почему каждому типу нагрузки нужен собственный адаптер. В Kubernetes реальная рабочая нагрузка редко представлена одним подом. Распределённое обучение или многоузловой сервер инференса выглядит как небольшое дерево ресурсов: группы подов, у каждой из которых есть роль, количество реплик, шаблон пода и статус, зависящий от типа нагрузки. Команды, которые создают планировщики, контроллеры, панели мониторинга или инструменты учёта затрат и должны работать с такими нагрузками, сталкиваются с этим сразу. Команда NVIDIA Run:ai столкнулась с той же задачей при создании своей платформы. Для каждого нового определения пользовательского ресурса (CRD) разработчики в коде отвечают на одни и те же вопросы: какова структура типа нагрузки, как интерпретировать статус ресурса как фазу, как изменить спецификацию пода, не нарушив работу нагрузки. Ответы пишутся один раз для каждого типа нагрузки и оформляются в виде адаптера под конкретный CRD. Каждый новый фреймворк, который приносит клиент, требует ещё одного адаптера. Поэтому разработка адаптера становится пунктом дорожной карты для каждого фреймворка, а не разовыми затратами, и поддержка нового типа нагрузки часто ждёт очередного релиза. Манифест показывает распределённое задание обучения в том виде, в котором его отправляет пользователь: ресурс JobSet с ведущим заданием (leader Job) и двумя рабочими заданиями (worker Jobs), в каждом поде которых запрашивается по четыре GPU. Манифест описывает одного лидера, двух воркеров и суммарный запрос в 12 GPU. Чтобы интерпретировать эту структуру, нужен код, который понимает JobSet, поскольку kubectl выводит ресурсы по отдельности: сам JobSet, три задания и их поды отображаются как отдельные записи. Владельческие ссылки связывают задания с JobSet, но платформе всё равно нужно описание, чтобы понимать роли и суммировать запросы ресурсов. В NVIDIA Run:ai без такого описания три задания отображаются как три отдельные нагрузки, каждая с четырьмя GPU. Без общего описания пользователям приходится самостоятельно восстанавливать нагрузку и подсчитывать её запросы GPU. Workload Map, ранее называвшийся Karta (вид ресурса CRD по-прежнему Karta), поставляется как CRD для Kubernetes и библиотека на Go, которая интерпретирует определения нагрузок. Каждое определение указывает, где найти шаблоны подов, количество реплик и поля статуса для своего типа нагрузки. Workload Map предоставляет планировщикам и платформенным потребителям общее структурное представление. KAI Scheduler использует эти определения для интерпретации группировки подов и инструкций группового планирования, а NVIDIA Run:ai применяет их для управления нагрузками и наблюдения за ними. Каждый потребитель опирается на одно и то же описание, что снижает необходимость в отдельных парсерах для каждого фреймворка. Библиотека на Go преобразует живой объект в единое структурное представление. Имея определение нагрузки, потребитель может извлекать шаблоны подов, количество реплик, статус и метаданные; обновлять спецификации подов, метки и аннотации у всех экземпляров; понимать иерархию нагрузки, например реплицированные задания JobSet и их поды. Workload Map включает каталог готовых, протестированных определений для JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet и NVIDIA Dynamo. Дополнительные типы нагрузок можно добавить, написав YAML-определение, которое описывает их структуру и статус. Ключевая идея в том, что знания о нагрузке выносятся из скомпилированных адаптеров в данные, которые разработчики могут писать, проверять и применять к кластеру как любой другой манифест. Определение для JobSet задаёт корневой компонент: вид самой нагрузки и способ чтения её статуса. JobSet не сообщает обычного условия «Running», поэтому определение вычисляет его выражением jq по полю replicatedJobsStatus: хотя бы одно задание готово и активно, ни одно не завершилось с ошибкой. Нативные условия Completed и Failed сопоставляются с общими категориями статуса, которыми пользуется потребитель. Так же описываются и другие типы: у RayJob или LeaderWorkerSet статусы устроены совсем иначе, но переводятся в те же категории. Дочерний компонент описывает структуру внутри нагрузки. Роли JobSet перечислены в списке replicatedJobs, и каждая запись этого списка является экземпляром. Путь podTemplateSpecPath указывает на шаблон пода каждого задания. Количество подов для реплицированного задания равно количеству реплик, умноженному на parallelism, поэтому в примере параллелизм задан явно. Имя каждого экземпляра берётся из поля name, благодаря чему leader и worker отображаются как отдельные роли, а не как три безымянных задания. Декларативные определения приводят ресурсы JobSet и LeaderWorkerSet, которые имеют разные схемы, к общему представлению дерева нагрузки. Одно описание поддерживает три сценария: инспекцию нагрузок, их совместное планирование и управление ими как единым целым. Инспекцию выполняет CLI Workload Map. Он загружает описание JobSet, находит живой объект и его поды и выводит дерево нагрузки, используя kubeconfig для доступа к кластеру. Для инспекции не нужно устанавливать Workload Map в сам кластер. Команды установки через Homebrew на macOS или Linux (tap dsx-ai-factory/kli, затем пакет kli) и проверка версии через kli --version подтверждают, что исполняемый файл доступен в PATH. При запущенном демонстрационном JobSet в текущем контексте Kubernetes команда kli describe jobset/demo -n выводит лидера и воркеров, суммарный запрос в 12 GPU и фазу Running. Раннюю версию этого вывода в CLI Karta можно было получить командой karta workload tree. Для инструментов, которые планируют нагрузки, определение может содержать необязательные инструкции группового планирования: группу podGroup с именем job и подгруппы, привязанные к компоненту replicatedjob. Определение задаёт группировку, а KAI Scheduler обеспечивает групповой допуск и принимает решения о размещении. KAI Scheduler использует Workload Map как запасной вариант в своём pod grouper для типов нагрузок, у которых нет нативного плагина. Подходящее определение даёт структуру и группировку без нового плагина под конкретный фреймворк, но нативные плагины сохраняют приоритет. В NVIDIA Run:ai один вызов API регистрирует тип нагрузки с помощью определения из того же каталога, без дополнительного кода. Затем платформа управляет JobSet как единой нагрузкой: отображает 12 GPU и структуру с ведущим заданием и заданиями воркеров. CLI, KAI Scheduler и NVIDIA Run:ai используют одно и то же определение для разных целей: инспекции, планирования и наблюдения на уровне платформы. Для других поддерживаемых типов нагрузок соответствующее определение из каталога описывает их структуру через тот же интерфейс. NVIDIA Workload Map распространяется по лицензии Apache 2.0 и уже используется в продуктивной среде NVIDIA Run:ai. Декларативные определения поддерживают наблюдение за нагрузками, интерпретацию статуса, отправку и изменение нагрузок для поддерживаемых типов в Kubernetes. Применение распространилось и на планирование в нескольких кластерах: Nova от Elotl использует Workload Map, чтобы понять структуру нагрузки и требования к ресурсам при выборе кластера для распределённых нагрузок. Благодаря готовым определениям Nova не нужно поддерживать собственную логику разбора для каждого фреймворка, и это показывает, как одна и та же модель описания нагрузок подходит разным потребителям в планировании и управлении. NVIDIA Workload Map — компонент с открытым исходным кодом, доступный в GitHub-организации NVIDIA DSX AI Factory. Если вы запускаете ИИ-нагрузки в Kubernetes и вам нужен единый способ интерпретировать их структуру для разных фреймворков, Workload Map помогает закрыть этот разрыв. Начните с каталога нагрузок, чтобы найти определение для используемого фреймворка, или адаптируйте существующее под собственный тип нагрузки. Присоединиться к обсуждению можно в рабочем пространстве NVIDIA DSX AI Factory в Slack по приглашению по ссылке. Мы с нетерпением ждём, что вы создадите. Материал подготовлен нейросетью на основе оригинальной публикации. ИИ может ошибаться в деталях (цифры, имена, даты, цитаты) — для важной информации сверяйтесь с первоисточником.