要点
- NVIDIA (2026-11-02) presents AI Cluster Runtime (AICR): reusable recipes, deployment bundles, and live-cluster validation aimed at Vera Rubin NVL72 Day-1.
- vs GB200: new driver branch (validated host-managed R615.23 open KMD), ConnectX-9/BlueField-4 with DOCA 3.3.0 on the testbed, changed NIC/GPU/DMA topology; IMEX remains for multi-node NVLink.
- End-to-end on GPU Operator v26.7.0 + DRA driver v0.5.0; training recipe’s cross-node NCCL all-reduce gate hits **744.71 GB/s** bus bandwidth at 16 GiB over NVLink.
- Early-silicon validation caught an unmapped Rubin arch value in go-nvlib crash-looping the DRA kubelet plugin; fix shipped in DRA v0.5.0. Recipes are Preview, not Supported.
Getting new GPU trays into Kubernetes rarely fails because “GPUs are unknown.” It fails when drivers, page size, runtimes, DRA/IMEX, networking, and schedulers disagree. NVIDIA’s Technical Blog (2 Nov 2026) writes Vera Rubin NVL72’s answer as AI Cluster Runtime (AICR): recipe → bundle → validate.
Thesis: Day-1 AI readiness is bottlenecked by versioned recipes with performance gates, not rediscovering the same sharp edges on every cluster.
[1]What happened
AICR sits in the DSX AI Factory story: aicr recipe resolves components by service/accelerator/os/intent, then aicr bundle emits ordered Helm charts. The Vera Rubin recipe family (RKE2, vr200, Ubuntu; training/inference/Dynamo variants) is Preview and encodes bring-up choices: host-managed driver (driver.enabled: false), DRA ComputeDomains, Kubernetes ≥1.34.1, Ubuntu 26.04 with a 64k-page kernel, and a higher NFD topology-updater memory limit to avoid OOMs on multi-TB nodes.
Versus GB200 NVL72, user-visible deltas include the new driver branch, ConnectX-9/BlueField-4, changed affinity topology, and new Rubin MIG profiles (recipes use whole-GPU; MIG is out of scope here).
[1]How hard is the evidence
Validation is pinned to reference clusters with GPU Operator v26.7.0 and DRA driver v0.5.0 on host R615. Training and inference variants pass deployment and conformance; training adds a cross-node NCCL all-reduce gate through an IMEX ComputeDomain at 744.71 GB/s bus bandwidth (16 GiB). Early hardware/fabric issues that dropped a tray from NVLink are documented, then cleared after reseat.
Software proof point: validation hit an unmapped Rubin architecture value in go-nvlib that crash-looped the DRA kubelet plugin; the fix landed in DRA v0.5.0. A second cluster reproduced the result the next day—used as evidence that recipes are repeatable.
[1]Steelman and gaps
Steelmans: collapsing combinatorial bring-up into versioned recipes is how platform teams scale auditably; pairing NCCL performance gates with conformance avoids “Pods Running” false greens.
Gaps: recipes are explicitly Preview, not Supported lifecycle; R615.23 is the tested version, not a promised minimum; RDMA datapath performance over ConnectX-9/DraNet is out of this validation; MIG is uncovered; early-access hardware stories are not reader-reproducible. Numbers are NVIDIA self-tests.
[1]Who pays, and what checklist changes
For platform and HPC buyers: a Rubin upgrade checklist should include recipe version, DRA/IMEX mode, kernel page size, and NFD memory limits—not only GPU count. For ops: treat unmapped PCI/arch values as release blockers, not dirty node lore. For the ecosystem: GB200 runbooks do not paste cleanly onto Rubin.
[1]What to watch in six months
Falsifiable next steps: after recipes move to Supported, can third-party clusters still reproduce deploy+conformance+NCCL gates in hours; do ConnectX-9 RDMA and MIG paths rewrite the story; without AICR, does Day-1 failure rate jump when operators assemble pieces by hand. The claim is not that Rubin is painless in production—it is that without recipeized validation, Day-1 only rebuys the same sharp edges.
[1]