Try AICR

Choose the question first

Path A: compare existing GPU nodes

Use AICR's read-only path when the question is whether two nodes or two points in time differ. It records kernel command-line settings, modules, system services, GPU hardware, and other measured state as YAML.

aicr snapshot --output baseline.yaml
# select the other node or repeat after the change
aicr snapshot --output current.yaml
aicr diff --baseline baseline.yaml --target current.yaml --fail-on-drift

A difference is not automatically a fault. Missing iommu=pt or nvidia_peermem is an observation first. A node without Mellanox networking may correctly omit both settings; a variant intended for RDMA may require them.

Choose the provider-curated source variant meant for that node's service, accelerator, operating system, workload intent, platform, and relevant hardware before deciding what should change. NVIDIA curates the built-in AICR variants. Other catalog providers can publish and review additional variants.

The complete snapshot walkthrough includes a working local review command, a machine-readable result with both snapshot and profile hashes, optional local OCI output, and the commands that retain the review as non-deployable ConfigHub Units.

expected-resources answers a later question. It needs the selected variant and its declared components deployed. If those components are absent, record that check as blocked or not run; do not call it failed GPU conformance.

Read the maintained result · Open the complete review YAML · Open the AICR v0.20.0 release · See the tested assessment boundaries

Path B: inspect a retained configuration

This path reads a reviewed AICR-generated package. It does not inspect a live GPU node or prove that the selected platform runs.

Where the selected configuration came from

The provider chooses the source variant. ConfigHub Workshop records that choice before it keeps the generated objects as a base. Later ConfigHub variants are changes to that retained base; they do not rewrite the provider's catalog record.

Open the complete source-catalog record · Open the retained BaseVariantRecord. Provider evidence applies to the selected source variant. ConfigHub evidence starts with the exact retained objects and records later changes, promotion, release, and delivery separately.

1. Install ORAS

ORAS reads and writes OCI packages without running a container.

oras version

If that command fails, use the ORAS installation instructions.

2. Pull and check the configuration

Run one script. It uses an empty credential store for the public pull, checks the source digest, selects the seven reviewed files, and compares the local OCI with those files.

bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/aicr-cpu-starter/try.sh)

Source: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/aicr-eks-h100-training-kubeflow-argocd-config:0.14.0

Recorded source digest: sha256:dcf7feeeeaece04cb5d55cbc1106862172b3ae77718154252b39db1ad8957010

3. Read what you received

The result contains seven Argo CD Application files, the source-and-intent record that explains the selection, and a local OCI containing the same seven files.

find ./aicr-cpu-starter/config/templates -maxdepth 1 -type f -print
cat ./aicr-cpu-starter/source-and-intent.yaml
oras manifest fetch --oci-layout ./aicr-cpu-starter/aicr-cpu-starter.oci:0.14.0

Expected local OCI digest: sha256:62eaf39703ca0e5e968fcd4a667cbccbb5b3ff16403471c4b3441b3681b2b225.

What the retained-configuration example proves

The public AICR configuration can be pulled without signing in. The seven selected Applications match their reviewed hashes, and the local OCI returns the same files.

The CPU starter is a ConfigHub Workshop selection from an AICR-generated platform. It is not an upstream NVIDIA AICR recipe. It keeps the source files unchanged, including a gp3 storage-class setting that must be changed before use on a cluster without that class.

An AI can propose that change, but a checker decides whether to accept it. The recorded example keeps all seven Application identities, changes only kube-prometheus-stack, and changes only its StorageClass field. A second request also moves a namespace, so the checker refuses it and writes no candidate.

Compare the accepted and refused requests.

Read the recorded anonymous run · Read how the selection was made · See the separate live CPU inference result

Open the AICR v0.20.0 starting configuration to inspect the newest retained source variant, 17 exact Applications, all 16 nested source renders, and the separate Argo CD and Flux lifecycle plans. The records bind 409 local objects to exact chart, values, and output digests without claiming that a GPU target ran. Read the nested and destination result. The v0.19.0 entry continues further into ConfigHub variants and release OCI.

Choose what to do next

Keep the files and OCI locally, or upload it into ConfigHub when your team needs shared changes, environment variants, approvals, and promotion from development to production. That account step is the same for every configuration.

To gate and move a change to this AI-platform configuration through environments, compare the exact object sets and promote the one that passed.

For deployment, choose the controller or direct path that will consume the reviewed objects. Do not apply this platform configuration until you have reviewed its component requirements and changed the recorded storage-class residue.

Compare this with a native platform built from tested parts. Build a Kubara platform composes similar components without Argo CD Applications from AICR. Apps on a platform defines how a workload lands on either kind.

Compare the other inference examples · Try the shorter Redis example