Summary

The current NVIDIA DRA driver (nvidia-dra-driver-gpu) does not enable
full-GPU allocation via DRA by default — it ships ComputeDomain (IMEX) only.
Whole GPUs continue to be allocated through the device plugin
(nvidia.com/gpu). AICR's recipes, workloads, examples, docs, and the DRA
conformance test currently assume full-GPU DRA (a gpu.nvidia.com device class

• ResourceClaims), which does not exist on such clusters. AICR should align
  with the driver's default: allocate GPUs via the device plugin, and reserve DRA
  for ComputeDomain.

Evidence

On a managed GB300 EKS cluster running nvidia-dra-driver-gpu (v25.12.0):

• DeviceClasses present: compute-domain-daemon.nvidia.com,
  compute-domain-default-channel.nvidia.com — no gpu.nvidia.com.
• ResourceSlice driver: compute-domain.nvidia.com — no GPU resource slices.
• The driver pods are healthy; GPU allocation simply isn't enabled.
• GPUs are advertised + scheduled via the device plugin (nvidia.com/gpu).

Consequences observed:

• secure-accelerator-access conformance check fails — its DRA test pod is
  Unschedulable: device class gpu.nvidia.com does not exist.
• The inference-perf workload's worker (DRA ResourceClaimTemplate against
  gpu.nvidia.com) is unschedulable; switching the request to
  nvidia.com/gpu (on extraPodSpec.mainContainer.resources.limits) lets it
  schedule and run.

Important: keep ComputeDomain DRA

This is only about full-GPU allocation. ComputeDomain (IMEX) for GB200/GB300
MNNVL NVLink fabric is a legitimate, required DRA use and must stay — the
compute-domain.* device classes and claims remain. The change is: GPUs via
device plugin; DRA used for ComputeDomain (and AWS networking), not for whole-GPU
allocation.

Proposed work

1. Disable / do not enable full-GPU DRA. In AICR's nvidia-dra-driver-gpu
   component values, ensure full-GPU allocation (the gpu.nvidia.com device
   class) is not enabled — match the upstream default. Keep ComputeDomain
   enabled.

2. Convert GPU ResourceClaim usage to nvidia.com/gpu everywhere AICR
   requests whole GPUs via DRA:

   • Workloads: inference Dynamo deployment
     (validators/performance/testdata/inference/dynamo-deployment.yaml,
     resource-claim-template.yaml) and the wiring in
     inference_perf_constraint.go (ResourceClaimTemplate apply +
     extraPodSpec.resourceClaims injection + gpuDRADriverName).
   • NCCL perf templates: the NVLS variants
     (testdata/gb200/{eks,oke}/runtime-nvls.yaml) that request
     gpu.nvidia.com.
   • Examples & overlays: any recipe overlay / example manifest requesting
     GPUs via ResourceClaim / gpu.nvidia.com.
   • Docs: anywhere DRA-based GPU allocation is documented as the AICR
     pattern.

3. Rework the DRA conformance test to use different examples/checks.
   secure-accelerator-access (and dra-support) currently require the
   gpu.nvidia.com DRA pattern (assert resourceClaims, reject
   nvidia.com/gpu). Update them to:

   • validate device-plugin GPU access + isolation for whole-GPU workloads, and/or
   • exercise ComputeDomain DRA (the DRA capability that is enabled),
     rather than asserting full-GPU DRA.

Open questions

• CNCF AI conformance: does the conformance suite require accelerator via
  DRA specifically? If so, reconcile (ComputeDomain DRA may satisfy the DRA
  requirement; otherwise flag the gap).
• Should full-GPU DRA be supported conditionally (enabled where the cluster
  exposes gpu.nvidia.com) rather than dropped entirely, to stay
  forward-compatible as the driver default may change?

Related: deployment/conformance validators surface the same divergence; EFA
device-plugin-vs-DRA migration question (separate issue).