NVIDIA DSX OS: Полный гайд по управлению GPU-кластерами Kubernetes

В мире высокопроизводительных вычислений и искусственного интеллекта одна неисправная видеокарта может стать узким горлышком для всего распределенного обучения модели. Операторы часто сталкиваются с парадоксальной ситуацией: узел проходит базовые проверки здоровья, показывает нормальную загрузку, но производительность падает. Проблема обнаруживается лишь тогда, когда работа уже запущена, что приводит к потере вычислительных ресурсов и простоев. Без непрерывной валидации первоначальная сертификация кластера быстро устаревает по мере замены узлов, обновления драйверов и расширения емкости.

Эта проблема «слепой зоны» приводит к тому, что вычислительные мощности тратятся на узлы, которые не способны выполнить задачу, а здоровые узлы простаивают из-за осторожности. Метрики утилизации могут маскировать эти потери. Более полезной метрикой является «goodput» — объем работы, успешно завершенной за единицу времени. Для поддержания готовности кластера необходима валидация на протяжении всего жизненного цикла: после изменений конфигурации, роста емкости и перед возвращением отремонтированных узлов в строй.

Платформа NVIDIA DSX AI Factory Platform объединяет технологии для проектирования, создания и эксплуатации эффективных «заводов» по производству ИИ. Ее открытый программный слой, NVIDIA DSX OS, включает инструменты для настройки, сертификации и поддержания здоровья ускоренной инфраструктуры Kubernetes. В этой статье мы подробно разберем, как использовать три ключевых компонента этой системы: AICR для конфигурации, NVCRE для сертификации и NVSentinel для эксплуатации.

01Конфигурация: Воспроизводимый базис с AICR

Первый этап работы с кластером — создание стабильной и воспроизводимой базы. NVIDIA AI Cluster Runtime (AICR) определяет программный базис кластера в файлах, контролируемых версионностью, и рендерит их в артефакты, которые применяются существующими инструментами развертывания. Декларативные шаблоны помогают обнаруживать дрейф конфигурации от ручных изменений и поддерживать согласованность конфигураций узлов после ремонтов.

AICR позволяет описать целевую среду, разрешить ее против библиотеки проверенных оверлеев и выдать рецепт (recipe). Например, для создания рецепта для сервиса с ускорителями можно использовать следующую команду:

aicr recipe --service eks --accelerator h100 --os ubuntu \
  --intent inference --platform dynamo -o recipe.yaml

Каждая запись компонента в полученном рецепте фиксирует версию и объявляет, какие зависимости должны быть здоровы перед установкой компонента. Рассмотрим фрагмент YAML-файла:

apiVersion: aicr.run/v1alpha2
componentRefs:
  - name: dynamo-platform
    chart: dynamo-platform
    namespace: dynamo-system
    source: https://helm.ngc.nvidia.com/nvidia/ai-dynamo
    type: Helm
    version: 1.4.2
    valuesFile: components/dynamo-platform/values.yaml
    dependencyRefs:
      - grove
      - cert-manager
      - kube-prometheus-stack
      - gpu-operator
      - kai-scheduler

Рецепт включает три ключевых свойства:

1. Фиксированные версии (Pinned versions): Версия зафиксирована, что помогает воспроизвести программную конфигурацию и расследовать сбои. В отличие от плавающего тега, который может указывать на другую версию программного обеспечения со временем, фиксация предотвращает непредвиденные изменения.
2. Граф зависимостей: Поле dependencyRefs объявляет, что должно быть установлено и быть здоровым первым. AICR разрешает этот граф при рендеринге пакета, поэтому порядок уже закодирован в артефактах, которые применяет ваш инструмент развертывания. Вам не нужно указывать, что cert-manager должен идти перед NVSentinel, и добавление компонента позже не требует перенумерации.
3. Утверждения о здоровье (Health assertions): Каждая запись содержит блок healthCheckAsserts, который запускается после установки и проверяет, соответствует ли компонент настроенным критериям здоровья. Kubernetes может сообщить, что под застрял в CrashLoopBackOff, как Running, поэтому проверка, основанная только на фазе пода, может пропустить сломанный компонент. Предоставленные утверждения фильтруют причину ожидания контейнера, а не только фазу пода.

Поскольку рецепт — это файл, вы можете использовать историю версий, код-ревью и обнаружение дрейфа для управления базисом. Команда aicr validate проверяет живой кластер против ограничений рецепта, а aicr diff сравнивает золотой базис с живым кластером. Флаг --fail-on-drift превращает проверку дрейфа в шлюз непрерывной интеграции (CI), а не просто отчет.

02Сертификация: Доказательство готовности к нагрузке с NVCRE

Кластер теперь построен по известному базису, но ему все еще нужна проверка рабочей нагрузки. Стандартные проверки здоровья подтверждают, что базовые службы работают. Они не подтверждают, что кластер может запустить требовательную многоузловую задачу через межсоединение без зависаний. NVIDIA Cluster Readiness Engine (NVCRE) проверяет готовность к рабочей нагрузке, запуская задачи обучения и тесты библиотеки NVIDIA Collective Communication Library (NCCL).

NVSentinel управляет запросами на валидацию, шлюзами планирования, кара

Источник: NVIDIA Developer ↗