GPU platform validation gains a runtime inventory: AICR now ships k8s-aibom by default, showing what actually runs on each node
Synopsis
NVIDIA's open-source AICR now includes Google's k8s-aibom as a qualified component in its recipes, so a GPU-accelerated Kubernetes platform can deploy a known-good configuration while recording which AI workloads actually run in the cluster. Previously a recipe fixed only the platform configuration, and workloads updated independently by application teams, plus mutable tags like :latest, could leave two nodes running different code under the same tag. Two GKE recipes select the component by default, and others can opt in at generation time.
Interpretation
A GPU platform's deployment recipe can now carry a runtime AI inventory alongside the infrastructure, answering which AI assets actually run in the cluster rather than only whether the infrastructure matches a validated configuration. Previously the recipe recorded platform configuration while application teams defined and updated workloads independently, so a reproducible deployment bundle alone could not establish which workload artifacts were running on each node. Two stock recipes, h100-gke-cos-inference and h100-gke-cos-inference-dynamo, select k8s-aibom by default; other GKE recipes can opt in during generation with --runtime-inventory enabled, and recipes that select it can opt out with --runtime-inventory disabled.
The inventory component watches supported workloads inside the cluster and emits a CycloneDX 1.6 AIBOM for each recognized AI workload. k8s-aibom sits higher up the stack and later in the cluster lifecycle than AICR: AICR works at the runtime deployment layer of drivers, operators, kernels and Kubernetes components, while k8s-aibom watches workload and pod APIs. Coverage includes native Dynamo graphs, NIMService, LeaderWorkerSet, DisaggregatedSet and CronJob resources, with tracked child workloads combined into their owner's AIBOM; in the example a vLLM deployment is automatically classified as category inference with runtime vllm, and the inventory lists the vllm application, the vllm/vllm-openai container and the Qwen/Qwen2.5-0.5B-Instruct model.
AICR's qualification of k8s-aibom is a specific set of checks rather than a rubber stamp. Qualification binds the exact upstream source, chart, CRDs and digest-pinned controller image as one tested set. The checks verify provenance against Google's expected build identity, review rendered RBAC and security defaults, and exercise installation, upgrade, health and uninstall on the deployment paths it tested.
Perspective
The demonstrated workflow targets readers running Kubernetes 1.32 or later on GKE with H100 GPU nodes using Container-Optimized OS and GKE-managed drivers and device plugins, and the examples correspond to AICR v1.2.0 and its catalog pinning k8s-aibom 1.6.2. Inventory is opt-in per namespace, and only supported workload kinds carrying a recognized AI signal are recorded.
The runtime AIBOM is written as a Kubernetes resource, but the observation itself is unsigned; signing would make captured observations tamper-evident, not prove every workload declaration true or establish successful execution. AICR leaves Sigstore signature verification disabled by default, and connecting platform provenance to runtime AI inventory remains future integration work, as does correlating recipe intent with observed workloads. The record is built from the workload spec, so an AIBOM can appear and report Ready=True while the pod is still pulling its image.