The Pulse
NVIDIA adds AI workload inventory to GPU platform runtime
NVIDIA AI Cluster Runtime now includes an inventory component for supported Kubernetes AI workloads. The component is selected by default in two Google Kubernetes Engine recipes, but its records do not prove a workload has executed.
NVIDIA AI Cluster Runtime now includes a component that inventories supported AI workloads on Kubernetes alongside the configurations used to deploy GPU platforms. The company said in a November 11 technical post that the integration uses k8s-aibom, an open-source project created by Google.
The component is selected by default in two Google Kubernetes Engine recipes for inference. Other GKE recipes can opt in using the runtime-inventory flag, while recipes that select the component by default can opt out.
From recipes to inventory
AI Cluster Runtime, or AICR, is an open-source component of the NVIDIA DSX AI Factory Platform. It generates version-locked recipes and deployment bundles for GPU-accelerated Kubernetes, recording components, version pins, constraints, deployment order and validation expectations for a particular configuration.
The inventory component examines a different layer: Kubernetes workloads and pods. It produces an AI bill of materials, or AIBOM, for each recognized workload, using the CycloneDX 1.6 format. Tracked child workloads are combined into their owner's record.
Coverage is limited to supported workload types carrying a recognized AI signal. These include native Dynamo graphs, NIMService, LeaderWorkerSet, DisaggregatedSet and CronJob resources.
The default recipes are named h100-gke-cos-inference and h100-gke-cos-inference-dynamo. The examples in the post use AICR v1.2.0 with a catalog that pins k8s-aibom 1.6.2. NVIDIA says its qualification process binds the upstream source, chart, custom resource definitions and controller image as a tested set and checks provenance, security defaults and deployment operations.
What the records show
Inventory reporting is enabled separately for each namespace. That setting controls where AIBOM records are emitted, but it does not restrict what the controller reads: workload and pod specifications are cached across the cluster, including container arguments and inline environment values.
No external sink or secret access is configured by default. The post's example uses a vLLM deployment serving a Qwen model; the controller classifies the workload as inference and identifies its serving runtime.
An inventory record is built from the workload specification and can appear before a pod is running. A record marked ready therefore does not establish that the workload was successfully scheduled or executed. Once a pod exists, the record can also include what its declared artifacts resolved to.
Attributes carry confidence tiers of declared, inferred, unresolved or verified, along with evidence locators. A document small enough to fit is stored inline on its Kubernetes resource, with a published SHA-256 hash of its canonical bytes.
Test results and remaining work
The upstream project measured k8s-aibom version 1.6.1 on GKE using NVIDIA Dynamo and AICR's configuration, the company said. The test used CPU-only nodes with workload pods remaining pending, so its figures describe controller inventory overhead rather than running GPU workloads.
During a 15-minute steady-state observation window, the test recorded approximately four API-server requests per minute, average controller CPU use of 2.2 millicores and a memory working set of 28 to 34 MiB. It also recorded one AIBOM regeneration when the tested workload's image tag changed.
Runtime observations are currently unsigned. Although k8s-aibom can verify signatures on model claims against operator-configured trust roots, AICR leaves that verification disabled by default. Connecting platform provenance to runtime inventory and comparing recipe intent with observed workload specifications remain future integration work.