Summary

The rtx-pro-6000 accelerator is declared in pkg/recipe/criteria.go (CriteriaAcceleratorRTXPro6000 = "rtx-pro-6000") and has five overlays today — all targeting LKE + Workstation Edition (recipes/overlays/rtx-pro-6000-lke-*.yaml and the cross-cutting rtx-pro-6000-any.yaml). There is zero EKS coverage, so aicr recipe --accelerator rtx-pro-6000 --service eks cannot resolve a usable recipe today.

Motivation / Context

AWS now exposes RTX PRO 6000 Blackwell as the g7e.48xlarge instance family — 8× NVIDIA RTX PRO 6000 Blackwell Server Edition per node (internal codename: B40). Reference NVIDIA cluster lives at dgxcloud/mk8s/manifests:clusters/av-teststudio-prod/av-teststudio-40-prod-1/cluster-spec.yaml (internal GitLab) and uses:

• AWS EKS, region us-west-2
• Node shape g7e.48xlarge
• GPU driver 580.105.08
• CDI enabled, DRA disabled, EFA enabled

Without an EKS overlay set, this hardware has no AICR recipe path. Inference workloads (the primary L40-class / RTX-Pro-class use case on hyperscalers) cannot be served by AICR for this cluster today.

Notes on SKU edition

The existing rtx-pro-6000-any.yaml comment explicitly calls out "Blackwell workstation." On g7e / EKS, the actual silicon is the Server Edition of the same product, which can differ in power envelope, NVLink topology, and cooling profile. The AICR criteria enum is a single rtx-pro-6000 value today — keep it that way for the first PR; defer splitting Workstation vs Server Edition to a separate issue unless an empirical floor difference forces it.

Suggested scope

PR 1 (minimum): RTX PRO 6000 on EKS for inference, matching the H100 inference layout:

• rtx-pro-6000-eks-inference.yaml (service-bound parent)
• rtx-pro-6000-eks-ubuntu-inference.yaml (OS-bound leaf)
• rtx-pro-6000-eks-ubuntu-inference-dynamo.yaml and/or -nim.yaml (platform-bound leaves) — match the h100-eks-ubuntu-inference-{dynamo,nim}.yaml pattern
• Deployment-phase floor Deployment.gpu-operator.version >= v25.10.0 is already inherited from rtx-pro-6000-any.yaml via wildcard match; tighten only if EKS-specific empirical data demands it
• No NCCL bandwidth threshold needed (single-node inference is the dominant use case)

PR 2+: Same patterns for GKE / AKS / OKE if and when a real reference cluster lands.

Each PR should:

• Add the overlays
• Update recipes/registry.yaml if accelerator-specific component pins are needed for EKS (driver, gpu-operator)
• Pass TestOverlayValidationPhaseFloor (deployment + conformance inherited from service-root via feat(recipe): deliver deployment-phase floor at per-accelerator wildcards #1001)
• Regenerate the BOM (make bom-docs) if any chart pin differs

Out of scope (file separately)

• RTX PRO 6000 training overlays on EKS — defer until a training use case is requested.
• Workstation vs Server Edition enum split — if SKU-specific config diverges materially, file a separate pkg/recipe/criteria.go change.
• GKE / AKS / OKE EKS-equivalent overlays — same rationale as in feat(recipes): add concrete L40 / L40S service-bound overlays #1003 sibling SKU work.

Related

• feat(recipes): add concrete L40 / L40S service-bound overlays #1003 — L40 / L40S service-bound overlays (sibling effort for the other Ada/Blackwell inference SKU class)
• Close deployment-phase validation coverage gaps for accelerator-bound GPU recipes #969 — validation phase coverage audit
• Existing pattern reference: recipes/overlays/rtx-pro-6000-lke-*.yaml (LKE + Workstation Edition), recipes/overlays/h100-eks-*inference*.yaml (EKS inference pattern)
• Reference cluster (internal): dgxcloud/mk8s/manifests:clusters/av-teststudio-prod/av-teststudio-40-prod-1/cluster-spec.yaml