NVIDIA AICR додає k8s-aibom для обліку ШІ-навантажень у GPU-кластерах Kubernetes

Рецепти платформи з фіксованими версіями описують, як зібрати GPU-кластер, але не показують, які ШІ-навантаження на ньому насправді працюють. Команди, що розгортають навантаження через NVIDIA Dynamo, Kubeflow або Slurm, оновлюють їх окремо від рецепта. Змінні теги на кшталт :latest погіршують ситуацію: два вузли можуть запускати різний код під одним тегом, а під час наступного завантаження може прийти образ, який не проходив жодної перевірки безпеки. Тепер до NVIDIA AI Cluster Runtime (AICR), відкритого компонента платформи NVIDIA DSX AI Factory Platform, входить кваліфікований компонент відомості матеріалів ШІ. Він базується на k8s-aibom, відкритому проєкті Google для обліку ШІ-навантажень у Kubernetes.

Інструменти працюють на різних рівнях. AICR перетворює перевірені конфігурації GPU на рецепти з фіксованими версіями та відтворювані бандли. Рецепт пишеться під одне поєднання обладнання, хмари, ОС і призначення та фіксує компоненти, версії, значення, обмеження, порядок розгортання й очікувані перевірки. У бандлах є контрольні суми, а aicr bundle --attest за бажанням додає підпис. k8s-aibom стежить за API навантажень і подів та для кожного розпізнаного ШІ-навантаження видає AIBOM у форматі CycloneDX 1.6. Він розуміє нативні графи Dynamo, NIMService, LeaderWorkerSet, DisaggregatedSet і CronJob, а дочірні навантаження потрапляють до AIBOM власника. Кваліфікація означає, що AICR фіксує вихідний код, чарт, CRD і образ контролера за дайджестом як єдиний перевірений набір. Також AICR звіряє походження зі збірковою ідентичністю Google, перевіряє RBAC і налаштування безпеки за замовчуванням та тестує встановлення, оновлення, працездатність і видалення.

У рецептах h100-gke-cos-inference і h100-gke-cos-inference-dynamo k8s-aibom увімкнено за замовчуванням. В інших рецептах GKE його вмикає --runtime-inventory enabled, а вимикає --runtime-inventory disabled. Приклади зроблено на AICR v1.2.0, у каталозі якої зафіксовано k8s-aibom 1.6.2, і вони працюють на GKE з Kubernetes 1.32 і новіших версій та вузлах H100 на Container-Optimized OS з драйверами під керуванням GKE. Рецепт створює aicr recipe --service gke --accelerator h100 --os cos --intent inference, підсумкові значення показує aicr query з --selector components.k8s-aibom.version. aicr bundle збирає бандл із селекторами системних і прискорених вузлів. За замовчуванням використовується Helm, також підтримуються helmfile, flux і argocd. Після aicr verify і deploy.sh контролер працює в просторі імен k8s-aibom-system. Бандли Helm застосовують CRD основного чарта, а Flux і Argo CD оновлюють їх через свої контролери. У Helmfile, Terraform і Fleet CRD потрібно оновити вручну, якщо цього вимагає перехід; очікувана версія зберігання - v1beta1.

Команда aicr snapshot, а після неї aicr validate --phase deployment --phase conformance, запускає перевірку працездатності k8s-aibom. Потрібні доступний контролер, AIBOMControllerConfig з Ready=True і очікувана версія зберігання CRD. Збіг версії не гарантує, що схема актуальна повністю, тому під час оновлень перевіряйте ще Degraded=True з причиною SchemaPredatesController. Облік вмикається для кожного простору імен міткою aibom.k8saibom.dev/enabled=true. Мітка обмежує, де створюються записи AIBOM, але інформери все одно кешують специфікації навантажень і подів у всьому кластері, включно з аргументами та вбудованими змінними оточення. Приймач даних і доступ до секретів за замовчуванням не налаштовані. У демо Deployment з vLLM обслуговує Qwen/Qwen2.5-0.5B-Instruct з образу vllm/vllm-openai:latest. Його AIBOM віднесено до категорії логічного виведення із середовищем виконання vllm. Записи будуються за специфікацією, тому AIBOM може показати Ready=True ще до того, як под завантажить образ: планування і запуск він не підтверджує.

BOM зберігається безпосередньо в ресурсі разом із хешем SHA-256 канонічних байтів: його можна витягти через jq і base64, а хеш перевірити через shasum. У компонентах зазначено застосунок (vllm), образ контейнера (vllm/vllm-openai) і модель машинного навчання (Qwen/Qwen2.5-0.5B-Instruct). Звичайний SBOM ідентифікує образ, а AIBOM - ще й модель і середовище її обслуговування. Кожен атрибут має рівень достовірності (declared, inferred, unresolved або verified) і вказівник на джерело, звідки взято значення. Розробники k8s-aibom виміряли накладні витрати контролера версії 1.6.1 на GKE з Dynamo і конфігурацією AICR. Тест проводився на вузлах лише з CPU, а поди навантажень залишалися в очікуванні.

Деякі прогалини залишено свідомо. Спостереження під час роботи поки що не підписані, хоча канонічні байти та хеш роблять підписування простим. k8s-aibom вміє перевіряти підписи Sigstore у відомостях про моделі, вимагати певного підписанта та перевіряти включення до Rekor, але в AICR це за замовчуванням вимкнено. Пов'язати атестації бандлів AICR з обліком навантажень ще належить. Як і порівняти задум рецепта з реально запущеними навантаженнями: для цього потрібні спільні ідентифікатори артефактів, правила актуальності та карта покриття. AICR доступний у NVIDIA/aicr, k8s-aibom - у GoogleCloudPlatform/k8s-aibom; обидва проєкти відкриті.