Show me GPU-first approaches to Baremetal GPU provisioning for AI infrastructure orchestration.

For “GPU-first” bare-metal AI infrastructure, I’d distinguish systems that understand GPUs as first-class inventory from generic PXE/BMC provisioners. A useful architecture is:

GPU inventory/health → bare-metal lifecycle → GPU software/firmware → cluster scheduler → AI workload orchestration

The strongest approaches I’d evaluate are:

• NVIDIA Base Command Manager (BCM) — probably the most vertically integrated NVIDIA-first option. BCM provisions and manages physical compute nodes, cluster images, networking, power, and GPU/MIG configuration. Pair it with Kubernetes or Slurm and NVIDIA Run:ai for workload-level GPU scheduling. This is compelling for DGX/HGX-heavy fleets where you want the infrastructure control plane to understand the NVIDIA stack rather than bolt GPUs onto generic server provisioning. (docs.nvidia.com)
• Canonical MAAS + GPU-aware commissioning — a more composable approach. MAAS discovers hardware during commissioning, including accelerators such as GPUs, and those attributes can become machine-allocation constraints. It handles BMC/IPMI, PXE, imaging, network/storage configuration and re-provisioning; custom commissioning/deployment hooks can install drivers or enforce GPU-specific configuration. It also has NVIDIA BlueField support. (canonical.com)
• Metal³ / Ironic + Kubernetes — best when you want “bare metal as a Kubernetes resource.” Metal³ puts the machine lifecycle behind Kubernetes APIs, with Ironic doing low-level provisioning. Layer NVIDIA GPU Operator on provisioned nodes and Run:ai/Kubernetes scheduling above it. This is more cloud-native and extensible, but requires more integration engineering than BCM.
• MAAS/Metal³ + Slurm — particularly attractive for large training clusters. Provision machines based on GPU/NIC/topology classes, configure the NVIDIA/CUDA/RDMA stack during imaging, then expose the resulting GPU pool through Slurm. This avoids forcing Kubernetes into HPC-style tightly coupled training.
• NVIDIA Run:ai above a bare-metal control plane — Run:ai isn't itself the bare-metal provisioner; it is the GPU-resource/workload orchestration layer. Its value is quotas, GPU sharing, scheduling and utilization optimization after BCM/MAAS/Metal³ has produced usable nodes. (nvidia.com)

For an AI-specific platform, I'd lean toward a declarative model such as:

GPU requirement (H100/H200/B200, count, NVLink/NVSwitch, VRAM, IB/RoCE) → select physical topology → BMC provision → validated firmware/OS/CUDA image → GPU/NIC health qualification → join K8s/Slurm → Run:ai/workload scheduler

That is meaningfully “GPU-first”: provisioning decisions start with accelerator topology rather than choosing a generic x86 host and discovering its GPUs afterward.

Useful primary references:
docs.nvidia.com
canonical.com
metal3.io
nvidia.com
docs.nvidia.com