# NVIDIA AICR 1.2 Adds an Operator Preview and Separate GPU Runtime Bundles

The new AI Cluster Runtime release makes GPU infrastructure changes easier to separate and review, while keeping important features in preview.

By Paras Madan | 2026-11-03

NVIDIA released AI Cluster Runtime 1.2.0 on November 2 with an opt-in Kubernetes operator preview, separate core and operations bundles, and new GPU deployment recipes. For platform teams running AI workloads, the change is about controlling how the supporting infrastructure gets deployed and updated.

## What NVIDIA AI Cluster Runtime does

[AICR](https://github.com/NVIDIA/aicr) packages combinations of drivers, operators, kernels and configuration into version-locked recipes. Teams bring their existing Kubernetes cluster and deployment tools, then generate configuration artifacts and validate the resulting environment.

That makes it useful for a familiar problem: a GPU job can fail because several individually reasonable component versions do not work together. A reproducible recipe gives the team a specific configuration to inspect rather than a collection of loosely related installation instructions.

AICR is Apache-2.0 software. It does not supply a hosted cluster or replace the cloud provider. Its generated artifacts can fit existing deployment workflows such as Helm, Argo CD or Flux.

## AICR 1.2 operator preview

The [1.2.0 release notes](https://github.com/NVIDIA/aicr/releases/tag/v1.2.0) introduce an opt-in operator that runs a pinned AICR image inside the cluster. It validates bundle recipes, fingerprints inventory specifications and requires approval before bundle rollout.

The distinction between preparing a change and applying it is useful. A generated bundle can be technically valid while still being the wrong change for a production cluster at that moment. Approval gives the operator a point where an infrastructure owner can review the proposed action.

The [operator implementation proposal](https://github.com/NVIDIA/aicr/pull/3475) describes a lifecycle covering assessment, planning, approval, rollout and validation. It includes a Kubernetes API, controller, Helm chart and kubectl plugin. This puts ongoing operations closer to the cluster instead of leaving every stage in a separate manual runbook.

**The operator is a preview.** The 1.2.0 operator defaults to AICR 1.1.2 because that is the release with which it was tested. Installing the latest operator therefore does not mean its default runtime is also the latest CLI release.

## Why separate core and operations bundles?

AICR 1.2 classifies components into core and operations layers. Core covers what a basic GPU pod needs, including fabric and installation prerequisites. Operations covers the remaining components, including workload platforms. The new bundle split option renders these separately.

This creates a useful ownership boundary. The team responsible for the GPU runtime can review its changes independently from a team updating the surrounding workload platform. Separating the artifacts does not remove dependencies, but it can make the scope of a proposed deployment easier to understand.

For example, a training-platform change should not become an excuse to update the entire GPU stack without review. A smaller deployment boundary gives teams a clearer basis for deciding what must be tested together.

## New recipes and remaining limits

New recipes cover CoreWeave training previews and NVKE GB200. NKTP telemetry integration also begins, although stock recipes will switch to it in a later release.

Separately, NVIDIA's [November 2 Vera Rubin walkthrough](https://developer.nvidia.com/blog/making-kubernetes-ai-ready-for-nvidia-vera-rubin-on-day-one/) describes preview recipes validated on early hardware. That walkthrough uses AICR 1.0.0, so its results should not be presented as a new 1.2 benchmark or general production qualification.

The broader lesson is practical: a recipe, a successful validation and production support answer different questions. Infrastructure teams need to know which one they have before treating a working example as an upgrade plan.

AICR 1.2 makes those plans more manageable by separating components and introducing an explicit review point. The useful test is whether that reduces the amount of unrelated infrastructure a team must touch each time it changes an AI workload.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help teams explain complex AI infrastructure through clear technical writing and launch stories that developers can understand and use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).