Валидация GPU-платформ с помощью Runtime AI Inventory в NVIDIA DSX

В эпоху, когда искусственный интеллект перестал быть экспериментальной технологией и стал основой бизнес-процессов, управление инфраструктурой для обучения и инференса моделей требует беспрецедентной точности. Команды, развертывающие AI-нагрузки с использованием NVIDIA Dynamo, Kubeflow или Slurm, сталкиваются с фундаментальной проблемой: отслеживание того, что именно работает в кластере, выходит за рамки простой конфигурации платформы. Приложение определяется и обновляется командами разработки независимо от базовой инфраструктуры, что делает невозможным гарантию того, что воспроизводимый пакет развертывания соответствует реальному состоянию узлов. Особенно сложной становится ситуация с изменяемыми тегами образов, такими как :latest, которые могут привести к тому, что два узла будут выполнять разный код под одинаковыми именами, а обновление образа на следующей неделе может загрузить версию, не прошедшую предварительный аудит безопасности.

Для решения этой проблемы NVIDIA представила компонент AI Bill of Materials (AIBOM) в составе NVIDIA AI Cluster Runtime (AICR), который является открытым модульным компонентом платформы NVIDIA DSX AI Factory. Эта интеграция, построенная на базе открытого проекта Google k8s-aibom, закрывает критический пробел в видимости AI-нагрузок, работающих в Kubernetes. AICR генерирует версии, заблокированные по зависимостям, и воспроизводимые пакеты развертывания для GPU-ускоренных кластеров Kubernetes, в то время как k8s-aibom наблюдает за поддерживаемыми AI-нагрузками и формирует записи AIBOM формата CycloneDX 1.6 с указанием уровней достоверности и локаторов доказательств.

01Два конца одной проблемы: AICR и k8s-aibom

Чтобы понять ценность этой интеграции, необходимо рассмотреть два разных подхода к управлению жизненным циклом AI-инфраструктуры. AICR и k8s-aibom смотрят на разные части этого процесса, но дополняют друг друга, создавая полную картину.

AICR помогает командам платформы генерировать и проверять конфигурации, которые считаются «известно правильными» (known-good). Он работает на уровне среды выполнения развертывания: драйверы, операторы, ядра, компоненты Kubernetes, конфигурации развертывания. AICR превращает известные конфигурации GPU-платформ в версии, заблокированные по зависимостям, и воспроизводимые пакеты развертывания. Каждый рецепт фиксирует желаемую конфигурацию для одной комбинации оборудования, облака, операционной системы и задачи: его компоненты, привязки версий, значения, ограничения, порядок развертывания и ожидания валидации. AICR генерирует воспроизводимые артефакты развертывания из фиксированных рецептов, каталогов и пакетов. Пакеты включают контрольные суммы; подпись является опциональной через команду aicr bundle --attest.

k8s-aibom, с другой стороны, работает на более высоком уровне стека и на более поздних этапах жизненного цикла кластера. Он наблюдает за API рабочих нагрузок и подов Kubernetes и формирует CycloneDX 1.6 AIBOM для каждого распознанного AI-задания. Покрытие ограничено: инвентаризируются только поддерживаемые виды рабочих нагрузок, несущих распознанный AI-сигнал. В покрытие входят нативные графы Dynamo, ресурсы NIMService, LeaderWorkerSet, DisaggregatedSet и CronJob. Отслеживаемые дочерние рабочие нагрузки объединяются в AIBOM их владельца.

Один подход обеспечивает контроль и воспроизводимость конфигурации GPU-ускоренного Kubernetes, а другой добавляет обнаружение рабочих нагрузок и отслеживаемость в этом кластере. Конкретно, AIBOM помогает вам:

• Находить незарегистрированные или «теневые» AI-нагрузки в пространствах имен, выбранных для отчетности.
• Идентифицировать модели, среды выполнения инференса, агентов и компоненты RAG (Retrieval-Augmented Generation).
• Отслеживать внешние AI-API и векторные базы данных.
• Обнаруживать изменения или дрейф в AI-зависимостях.
• Поддерживать аудиты безопасности, реагирование на инциденты и соответствие нормативным требованиям.

Оба проекта пришли к этому решению с противоположных сторон одной и той же проблемы. AICR фиксирует квалифицированное намерение развертывания и оценивает его против кластера в определенный момент времени. k8s-aibom наблюдает за поддерживаемыми AI-нагрузками и записывает то, что он нашел, включая то, насколько уверенно были определены каждый атрибут. Ни один из этих взглядов не достаточен для управления AI-государственностью в одиночку, и граница между ними — это именно то место, где сегодня отсутствует подотчетность.

02Настройка и генерация рецепта

Давайте рассмотрим практический пример использования AICR в связке с k8s-aibom. Эти примеры отражают AICR v1.2.0 и его каталог, который фиксирует версию k8s-aibom 1.6.2. Для воспроизведения примеров используйте сборку CLI, соответствующую этому каталогу.

Начните с кластера Google Kubernetes Engine (GKE), работающего на Kubernetes 1.32 или более поздней версии, с узлами GPU NVIDIA H100, использующими Container-Optimized OS (COS) и драйверами и плагинами устройств, управляемыми GKE. Следующий рабочий процесс генерирует рецепт, рендерит его в пакет, развертывает его и проверяет результат. Ничего не собирается вручную, и ничего не настраивается вручную.

С той же версией AICR, каталогом и входными данными генерации разрешение рецепта производит ту же конфигурацию. Последний шаг проверяет кластер против него. Это та половина, которую AICR привносит в эту пару: проверенная GPU-платформа быстро и повторяемо. Затем k8s-aibom продолжает инвентаризацию поддерживаемых AI-нагрузок.

Для генерации рецепта используйте следующую команду:

aicr recipe \
  --service gke \
  --accelerator h100 \
  --os cos \
  --intent inference \
  --output recipe.yaml

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

aicr query \
  --service gke --accelerator h100 --os cos --intent inference \
  --selector components.k8s-aibom.version
# 1.6.2

Это гарантирует, что вы работаете с проверенной версией компонента инвентаризации, что критически важно для воспроизводимости и безопасности.

03Создание пакета и развертывание

После генерации рецепта следующим шагом является создание пакета развертывания. Используйте развертыватель Helm по умолчанию. Замените примерные селекторы узлов метками, присутствующими в вашей системе и пулах GPU-узлов:

aicr bundle \
  --recipe recipe.yaml \
  --system-node-selector nodeGroup=system-pool \
  --accelerated-node-selector nodeGroup=gpu-worker \
  --output ./bundles

Пакет представляет собой одну директорию для каждого компонента, упорядоченную по графу зависимостей, каждая из которых содержит свои значения, контрольные суммы и скрипт установки. AICR поддерживает множество развертывателей через флаг --deployer, включая helmfile, flux и argocd.

Проверьте сгенерированный пакет, а затем установите его:

(cd ./bundles && aicr verify . && chmod +x deploy.sh && ./deploy.sh)

После развертывания контроллер k8s-aibom запускается в пространстве имен k8s-aibom-system. AICR использует CRDs основного чарта, а не сопутствующий чарт k8s-aibom-crds. Helm-пакеты включают шаг применения CRD; Flux и Argo CD обрабатывают обновления через свои контроллеры. Helmfile, Terraform и Fleet требуют документированного ручного обновления CRD, когда переход требует этого. Проверьте установленную версию хранилища:

kubectl get crd aiboms.aibom.k8saibom.dev \
  -o jsonpath='{.spec.versions[?(@.storage==true)].name}'
# v1beta1

04Валидация и проверка состояния

После развертывания необходимо убедиться, что кластер соответствует заявленной конфигурации. AICR предоставляет инструменты для создания снимков состояния кластера и их сравнения с исходным рецептом.

aicr snapshot --output snapshot.yaml
aicr validate --recipe recipe.yaml --snapshot snapshot.yaml \
  --phase deployment --phase conformance

Проверка здоровья k8s-aibom запускается как часть фазы развертывания. Она требует, чтобы развертывание контроллера было доступно, кластер-scoped AIBOMControllerConfig сообщал о текущем состоянии Ready=True, и оба CRD сообщали о версии хранилища, которую ожидает зафиксированный чарт.

Это обеспечивает фундаментальную гарантию того, что инфраструктура GPU построена из известной и проверенной конфигурации. Только после этого можно переходить к инвентаризации рабочих нагрузок.

05Выбор пространства имен для инвентаризации

Инвентаризация является опциональной для каждого пространства имен. Метка управляет тем, какие пространства имен генерируют записи AIBOM; она не сужает то, что читает контроллер. Informers все еще кэшируют спецификации рабочих нагрузок и подов во всем кластере, включая аргументы контейнеров и встроенные значения переменных окружения. Слив и доступ к секретам по умолчанию не настроены, поэтому ничего не покидает кластер без явного решения.

Чтобы включить инвентаризацию для конкретного пространства имен, выполните следующие команды:

kubectl create namespace prod-jobs
kubectl label namespace prod-jobs aibom.k8saibom.dev/enabled=true

Это позволяет гибко управлять тем, какие части вашей инфраструктуры подлежат аудиту и отслеживанию, не перегружая систему ненужными данными из системных пространств имен.

06Запуск рабочей нагрузки инференса

Поддерживаемые рабочие нагрузки, несущие распознанный AI-сигнал, инвентаризируются автоматически, когда их пространство имен включено. Для простой демонстрации рассмотрим развертывание vLLM, обслуживающее модель Qwen. Обратите внимание, что оно извлекает vllm/vllm-openai:latest, а не дайджест, что является распространенным шаблоном в некоторых средах.

Селектор nvidia-h100-mega-80gb и терпимость должны соответствовать меткам и ограничениям пула GPU вашей системы:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen
  namespace: prod-jobs
spec:
  replicas: 1
  selector:
    matchLabels: {app: vllm-qwen}
  template:
    metadata:
      labels: {app: vllm-qwen}
    spec:
      # Adjust to match your GPU node pool's taints and labels.
      tolerations:
        - key: dedicated
          operator: Equal
          value: gpu-workload
          effect: NoSchedule
      nodeSelector:
        cloud.google.com/gke-accelerator: nvidia-h100-mega-80gb
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "Qwen/Qwen2.5-0.5B-Instruct",
                 "--max-model-len", "4096",
                 "--gpu-memory-utilization", "0.30"]
          ports:
            - containerPort: 8000
          resources:
            limits:
              nvidia.com/gpu: "1"
          volumeMounts:
            - {name: shm, mountPath: /dev/shm}
      volumes:
        - name: shm
          emptyDir: {medium: Memory, sizeLimit: 2Gi}

Сохраните этот манифест как vllm-qwen.yaml, а затем создайте рабочую нагрузку:

kubectl apply -f vllm-qwen.yaml

07Просмотр инвентаря

После применения рабочей нагрузки вы можете отслеживать инвентарь:

kubectl -n prod-jobs get aiboms.aibom.k8saibom.dev

Пример вывода:

NAME                        WORKLOAD     NAME        CATEGORY    RUNTIME   READY   AGE
apps-deployment-vllm-qwen   Deployment   vllm-qwen   inference   vllm      True    28m

Контроллер автоматически классифицировал категорию рабочей нагрузки и среду выполнения. Одна граница, о которой стоит знать: запись строится на основе спецификации рабочей нагрузки, поэтому AIBOM может существовать до того, как какой-либо под будет запущен. AIBOM может появиться и сообщить Ready=True, пока под все еще извлекает свой образ. AIBOM говорит вам, что было объявлено, и, как только существует Pod, к чему он разрешился. Он не доказывает успешное планирование или выполнение.

Проверьте условия статуса:

kubectl -n prod-jobs get aibom apps-deployment-vllm-qwen \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status} {end}'
# Ready=True Synced=True SinkFailed=False Stale=False

08Проверка документа AIBOM

Документ хранится внутри ресурса, когда он достаточно мал, с опубликованным SHA-256 для канонических байтов:

kubectl -n prod-jobs get aibom apps-deployment-vllm-qwen -o json > aibom.json
jq -r '.status.bomDocument.inline.data' aibom.json | base64 -d > bom.json
jq -r '.status.bomDocument.sha256' aibom.json
shasum -a 256 bom.json | awk '{print $1}'

Здесь все сходится вместе:

jq -r '.components[] | "\(.type)\t\(.name)"' bom.json

Ответ должен выглядеть примерно так:

application              vllm
container                vllm/vllm-openai
machine-learning-model   Qwen/Qwen2.5-0.5B-Instruct

Обычный SBOM (Software Bill of Materials) говорит вам, какой образ запущен. AIBOM говорит вам, какая модель обслуживается и какая среда выполнения ее обслуживает. Атрибуты несут один из четырех уровней достоверности — declared (заявлено), inferred (выведено), unresolved (не разрешено) или verified (проверено) — вместе с локатором доказательств, так что рецензенты могут видеть, как было достигнуто каждое утверждение.

09Влияние на ресурсы

Одной из ключевых проблем внедрения любых мониторинговых инструментов является их влияние на производительность. Исходный проект k8s-aibom измерил v1.6.1 на GKE с NVIDIA Dynamo и конфигурацией AICR. Тест использовал узлы только с CPU, а рабочие нагрузки оставались в состоянии ожидания, поэтому эти цифры описывают накладные расходы контроллера инвентаризации:

• Примерно четыре запроса к API-серверу в минуту в течение 15-минутного окна наблюдения в стабильном состоянии.
• Среднее использование CPU контроллера составляет 2.2 миллиядра (millicores).
• Рабочий набор памяти контроллера составляет от 28 до 34 MiB.
• Одна регенерация AIBOM при изменении тега образа тестируемой рабочей нагрузки.

Эти показатели демонстрируют, что интеграция k8s-aibom является крайне легкой и не оказывает значительного влияния на производительность GPU-кластера, что делает ее пригодной для использования в производственных средах с высокими нагрузками.

10Что это значит на практике

Интеграция AICR и k8s-aibom представляет собой значительный шаг вперед в управлении AI-инфраструктурой. Она позволяет командам не только развертывать GPU-ускоренные кластеры с гарантией их конфигурации, но и постоянно отслеживать, какие именно AI-модели и среды выполнения работают в этих кластерах.

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

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

Для команд, работающих с GPU-нагрузками в Kubernetes, эта интеграция добавляет инвентарь распознанных AI-нагрузок и доказательства, показывающие, как был определен каждый атрибут. Это не просто инструмент мониторинга, а комплексное решение для обеспечения целостности, безопасности и эффективности AI-инфраструктуры.

Оба проекта, AICR и k8s-aibom, являются открытыми. AICR доступен по адресу NVIDIA/aicr, а k8s-aibom — по адресу GoogleCloudPlatform/k8s-aibom. Если вы запускаете GPU-нагрузки в Kubernetes, эта интеграция добавляет инвентарь распознанных AI-нагрузок и доказательства, показывающие, как был определен каждый атрибут.

11Заключение

Внедрение NVIDIA AI Cluster Runtime (AICR) с компонентом AI Bill of Materials (AIBOM) через проект k8s-aibom знаменует собой новый этап в управлении AI-инфраструктурой. Эта интеграция обеспечивает не только воспроизводимость и валидацию конфигураций GPU-кластеров, но и глубокую видимость работающих AI-нагрузок, что критически важно для безопасности, соответствия нормативным требованиям и эффективного управления жизненным циклом приложений.

Для российских компаний и разработчиков, работающих с AI-решениями, понимание и внедрение подобных инструментов становится все более актуальным. Несмотря на возможные ограничения доступа к некоторым облачным сервисам, принципы управления инфраструктурой, описанные в этой статье, применимы к любым Kubernetes-кластерам, развернутым как в облаке, так и локально. Открытость проектов AICR и k8s-aibom позволяет адаптировать их под различные среды, включая локальные дата-центры, что делает их ценным инструментом для построения надежной и безопасной AI-инфраструктуры.

Рекомендуется начать с изучения репозиториев AICR и k8s-aibom, чтобы понять возможности этих инструментов и оценить их применимость к вашим конкретным задачам. По мере роста сложности ваших AI-нагрузок, внедрение систем инвентаризации и валидации, подобных NVIDIA DSX AI Factory, станет не просто опцией, а необходимостью для обеспечения стабильности и безопасности ваших операций.

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