The open-source release stabilizes configuration interfaces and pairs version-locked deployment recipes with signed evidence that infrastructure teams can inspect before rollout.
Listen
AI narration
12:15
0:00 / 12:15
AI SummaryGenerated from this article
NVIDIA released AICR 1.0, an open-source tool enabling GPU infrastructure teams to select version-locked Kubernetes configurations, render them for deployment tools, and validate running clusters against those recipes using signed verification evidence. The release establishes stable public interfaces for the CLI, REST API, Go SDK, and artifact schemas under a v1.x compatibility commitment, allowing teams to embed configuration management into automation without breaking on interface changes.
AICR separates workflow stages: snapshot captures cluster state, recipe describes desired components, bundle renders configuration for tools like Argo CD or Flux, and validation checks results against the recipe. NVIDIA's public dashboard publishes validation evidence for tested hardware combinations, though operators must verify that evidence matches their specific environment before treating recipes as production-ready.
With NVIDIA’s AICR 1.0, GPU-infrastructure operators can resolve a version-locked Kubernetes recipe, render it for their existing deployment tool, and validate the running cluster against that same recipe. The configuration and its supporting evidence stay tied to the deployment.
In its October 6 announcement, NVIDIA says AICR 1.0 establishes a compatibility contract across its CLI, REST API, Go SDK, generated bundle layout, and artifact schemas. Integrators can build automation around those public interfaces under the project’s v1.x compatibility policy.
NVIDIA AI Cluster Runtime is infrastructure tooling, not a new accelerator launch. It addresses a familiar operational problem: GPU drivers, kernels, container runtimes, operators, and Kubernetes releases can each be reasonable choices independently without forming a working stack together. AICR packages selected combinations as recipes, then separates deployment from verification.
The Stability Promise Covers Interfaces, Not Every GPU Stack
AICR’s 1.0 contract covers the interfaces that scripts, deployment pipelines, and management platforms consume:
The aicr CLI’s public commands, flags, exit behavior, and structured output.
The aicrd REST API and its OpenAPI contract.
The exported Go API in github.com/NVIDIA/aicr/pkg/client/v1.
Generated bundle layouts and AICR artifact schemas.
According to NVIDIA, each public interface has a committed compatibility baseline checked before changes merge. Removing or incompatibly changing a stable public interface after v1.0 requires a new major release.
For teams maintaining more than a one-off installation script, those interfaces are dependencies. Automation that parses command output, calls the API, or processes generated bundles can break when those surfaces change, even if the underlying GPU configuration remains valid.
The commitment does not freeze every component version forever or make every combination supported. Recipes pin particular configurations; the compatibility policy protects the public interfaces used to work with them. Teams still need to choose an appropriate recipe and evaluate changes to its components.
For Go integrations, the supported SDK facade avoids dependence on AICR’s internal packages. NVIDIA says the CLI and REST server use the same facade, reducing the risk of different entry points implementing different behavior.
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
A Recipe Describes the Target; GitOps Still Applies It
AICR separates its workflow into four capabilities with distinct responsibilities.
Snapshot records observed cluster state, including Kubernetes, operating system, kernel, GPU, and topology information. It describes what exists, not what the operator wants.
Recipe describes the desired, version-locked component configuration, together with applicable constraints and validation phases.
Bundle renders that recipe into artifacts for the chosen deployment tool.
Validation compares the recipe with observed cluster state and, where declared, runs deployment, conformance, and performance checks.
A recipe does not reconcile a cluster. Helm, Argo CD, Flux, or Helmfile applies or reconciles the generated configuration, after which AICR can check the result.
The AICR repository also explicitly distinguishes the project from a Kubernetes distribution, cluster provisioner, lifecycle-management system, or hosted control plane. Operators bring the cluster and deployment tooling; AICR supplies runtime configuration artifacts and validation capabilities.
An existing platform team can adopt AICR without replacing its deployment system. It fits at configuration selection and rendering, followed by checks against the deployed result.
Render One Configuration Into the Existing Deployment Workflow
The repository’s quick start illustrates the workflow with EKS, an H100 accelerator, Ubuntu, a training workload, and Kubeflow:
Those inputs identify a target environment. The recipe engine resolves them through a library of layered configurations, combining base defaults with service, accelerator, operating-system, and workload-specific settings.
The next step renders the resolved recipe for a deployment tool:
Output depends on the selected deployer. The repository describes Argo CD Application manifests, an Argo CD Helm-chart variant, Flux HelmRelease and Kustomization manifests, a Helmfile release graph, and Helm commands.
NVIDIA says the intended configuration remains the same when the operator renders a recipe for another supported deployer. Organizations using different deployment tools can therefore review a common configuration artifact, even though their generated deployment files differ.
Before handing those files to a deployment controller, operators should inspect the recipe, generated artifacts, and available verification information. AICR’s announcement makes clear that verification is an explicit operator action. Generating a bundle does not mean verification has happened.
After deployment through the existing workflow, the repository shows validation against the recipe recorded at the bundle’s root:
aicr validate --recipe ./bundles/recipe.yaml
Using that bundled recipe keeps validation tied to the configuration actually handed to the deployer. Resolving a fresh recipe later could introduce a different target into the comparison.
These are documented workflow examples, not commands tested for this article. Teams should confirm their environment’s recipe status and validation requirements before using them in production.
Audit the Signed Evidence Before Treating a Recipe as Tested
AICR distinguishes two kinds of cryptographic proof: where an artifact came from and what a validation run recorded.
The repository describes provenance as proof signed by NVIDIA CI and verifiable offline. For recipes with published evidence, validation evidence is a signer-bound, tamper-evident attestation connecting an identity to a recorded aicr validate result.
Provenance helps establish artifact origin; validation evidence records a test result associated with a signer. Neither, by itself, establishes that a different cluster will reproduce that result.
NVIDIA’s public validation dashboard lets operators inspect that distinction. They can filter recipes by service, GPU, operating system, workload intent, and optional platform, then examine recipe status and published evidence for the tested hardware configuration. Where evidence is available, NVIDIA directs users to run the dashboard’s aicr evidence verify command.
Whether the tested environment matches the intended service, accelerator, OS, and workload.
Which checks ran and passed, including whether relevant conformance or performance checks were declared.
Who signed the result and whether that identity meets the organization’s trust requirements.
Whether evidence exists for the selected recipe, rather than assuming every recipe carries a published live-cluster result.
A valid signature connects the signer to the recorded evidence without expanding the test’s scope. A signed result from one hardware configuration should not become a blanket assurance for an entire accelerator generation.
The announcement supplies no comparative benchmark results demonstrating faster training or inference. Its measurable value must be assessed through the available recipe evidence and validation on the operator’s own cluster.
AICR’s repository lists accelerator targets including A100, H100, H200, B200, GB200, GB300, L40, L40S, and RTX PRO 6000, alongside a VR200 entry marked preview. It also lists managed Kubernetes services and other environments, multiple Linux operating systems, and training and inference platforms.
These are dimensions of coverage. They do not guarantee that every possible combination is supported and validated.
When moving between NVIDIA accelerator generations, the reusable element is the workflow: select an environment, resolve its recipe, inspect evidence, render artifacts, deploy, and validate. Operators should not assume that a recipe selected for an H100 cluster applies unchanged to a GB300 deployment.
NVIDIA identifies fabric type, machine shape, and Kubernetes release as additional factors that can distinguish a working configuration from a failing one. Broad service and GPU coverage needs to be interpreted through the specific recipe and its recorded test conditions.
Successful installation is also a narrower result than operational readiness. A cluster may install its components without satisfying the recipe’s intended capabilities or declared performance thresholds. AICR’s validation stages are designed to check beyond whether deployment files were accepted.
Make the Recipe and Evidence Part of the Release Record
The strongest operational use for AICR 1.0 is treating the resolved recipe, deployment bundle, and verification results as linked release artifacts.
Keep them alongside the corresponding infrastructure change so reviewers can identify the intended configuration, inspect its evidence, and distinguish that intent from the cluster’s observed state. When upgrading, evaluate the changed recipe and revalidate the deployed result. An earlier successful run should not serve as permanent approval.
NVIDIA also describes integrations through a Pulumi Labs infrastructure-as-code provider and Mirantis’s k0rdent multi-cluster tooling. These illustrate the same configuration model being consumed through different management systems, although the announcement is not independent proof of their production behavior.
The project is Apache 2.0 licensed and accepts contributions, including new recipes and signed validation evidence from environments maintainers cannot access. This provides a route for expanding coverage, but contributed evidence still deserves scrutiny.
AICR 1.0’s stability contract makes the process more practical to embed in automation. Its value depends on keeping a pinned configuration, a verified artifact, a recorded test, and a validated running cluster distinct. Together, they give teams a more defensible basis for rollout than an installation script that happened to work once.
