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; оба проекта открытые.