Summary

Adds the four missing EKS overlays for the rtx-pro-6000 accelerator enum, mirroring the H100 EKS inference layout: a service-bound parent, an Ubuntu OS leaf, and Dynamo + NIM platform leaves.

Motivation / Context

The rtx-pro-6000 enum is declared in pkg/recipe/criteria.go but its only overlays today target LKE + Workstation Edition. AWS now exposes RTX PRO 6000 Blackwell as the g7e.48xlarge instance family (8× RTX PRO 6000 Blackwell Server Edition, internal codename B40), so aicr recipe --service eks --accelerator rtx-pro-6000 had no resolvable leaf. Reference cluster: dgxcloud/mk8s/manifests:clusters/av-teststudio-prod/av-teststudio-40-prod-1/cluster-spec.yaml (internal GitLab) — runs gpu-operator driver 580.105.08, CDI on, DRA off, EFA on.

Fixes: #1045
Related: #1003 (sibling L40/L40S effort), #969 (validation phase floor)

Type of Change

• New feature (non-breaking change that adds functionality)

Component(s) Affected

• Recipe engine / data (pkg/recipe)

(YAML data + two existing Go test tables extended to cover the new overlays. No production Go code changes.)

Implementation Notes

Layout mirrors h100-eks-ubuntu-inference{,-dynamo,-nim}.yaml:

Key decisions:

• K8s version pin: >= 1.32.4 for the base/Ubuntu leaves (matches H100 EKS), >= 1.34 for Dynamo/NIM leaves (DRA GA requirement, matches H100 EKS Dynamo/NIM).
• gpu-operator floor: >= v25.10.0 (Blackwell-era), matching the rtx-pro-6000-any.yaml wildcard. Dynamo and NIM self-declare the same value so the per-phase replace semantics keep the version pin intact.
• No nodewright-customizations: matches the existing rtx-pro-6000-lke-* pattern. The H100 EKS overlays add this for H100-specific kernel tuning; that's not the established convention for RTX Pro 6000 single-card inference.
• No NCCL bandwidth threshold: single-node inference is the dominant use case, no NVLink between cards on PCIe Blackwell Server Edition.
• Conformance check sets: plain inference leaves use the 8-check LKE set (no gang-scheduling); Dynamo/NIM use the 11-check H100 set (adds gang-scheduling, robust-controller, secure-accelerator-access).
• Performance phase: Dynamo leaf has a placeholder inference-perf block with the same loose smoke-test thresholds as the H100 Dynamo overlay, to be tightened once reference runs are published. NIM leaf omits performance to match the H100 NIM overlay (warn-only under the phase floor; not required).
• SKU edition: a single rtx-pro-6000 enum still covers both Workstation (LKE) and Server (EKS) Edition. Per feat(recipes): add concrete RTX PRO 6000 Blackwell service-bound overlays for EKS #1045, splitting them into separate enum values is deferred unless an empirical floor difference forces it.
• knownGaps deferred (not added here): pkg/recipe/validation_phase_floor_test.go marks performance as warn-only for inference-NIM in default mode (AICR_VALIDATION_FLOOR_STRICT is not set in any CI workflow today — verified via grep). The hygiene check at lines 337-352 fails the test if a knownGaps entry doesn't downgrade an actual failure, so adding an entry now for the missing NIM performance phase would be stale-flagged and break the test. This is the same trade-off the floor test itself documents (lines 64-75) for the GB200 OKE training trio. When strict mode is toggled in CI (tracked under feat(recipes): add concrete L40 / L40S service-bound overlays #1003 / Close deployment-phase validation coverage gaps for accelerator-bound GPU recipes #969 / feat(validation): add performance-phase constraints to OKE overlays once OCI testbed lands #1007), entries for the H100 NIM, the new RTX PRO 6000 NIM, and the OKE GB200 training leaves should land together in that PR — not piecemeal here.

Testing

# overlay phase-floor gate (the gate referenced by #1045 and #1003)
go test -v ./pkg/recipe/... -run TestOverlayValidationPhaseFloor

# extended invariant tests (new entries for the 4 EKS RTX PRO 6000 overlays)
go test -v ./pkg/recipe/... -run "TestNFDTopologyUpdater_OverlayCoverage|TestConformanceRecipeInvariants"

# pkg/recipe race + lint
GOFLAGS="-mod=vendor" go test -race ./pkg/recipe/...
golangci-lint run -c .golangci.yaml ./pkg/recipe/...

# full gate
make qualify

Results:

• TestOverlayValidationPhaseFloor passes for all 4 new overlays (deployment phase inherited from wildcard for plain inference; self-declared for Dynamo/NIM with both halves of the gpu-operator-version gate).
• TestNFDTopologyUpdater_OverlayCoverage extended with 4 new entries (rtx-pro-6000-eks-{inference,ubuntu-inference,ubuntu-inference-dynamo,ubuntu-inference-nim}); all assert topologyUpdater.enable=true and pass.
• TestConformanceRecipeInvariants extended with the same 4 entries; resolved component counts and conformance check coverage match the H100 EKS sibling pattern (15/15/17/16 components, 8/8/11/11 conformance checks).
• golangci-lint: 0 issues.
• make qualify: all 22 chainsaw tests pass, no vulnerabilities, license headers OK, codebase qualification completed.
• Smoke test: aicr recipe --service eks --accelerator rtx-pro-6000 --os ubuntu --intent inference --platform dynamo resolves cleanly (17 components, 8 overlays composed).

Coverage: YAML data + test additions only — per CLAUDE.md the per-package coverage gate does not apply (no new production Go code). Project-wide make test-coverage floor (70%) still passes under make qualify.

Risk Assessment

• Low — Isolated change, well-tested, easy to revert

Rollout notes: Pure addition of four new overlay files plus two test-table extensions. No existing recipe behavior changes; the new overlays only resolve when a user explicitly queries --service eks --accelerator rtx-pro-6000. Easy revert is rm of the four files plus reverting the two test edits.

Checklist

• Tests pass locally (make test with -race)
• Linter passes (make lint)
• I did not skip/disable tests to make CI green
• I added/updated tests for new functionality (TestOverlayValidationPhaseFloor auto-enumerates; TestNFDTopologyUpdater_OverlayCoverage and TestConformanceRecipeInvariants extended explicitly to cover the 4 new EKS leaves)
• I updated docs if user-facing behavior changed (no user-facing CLI/API surface changed — overlays are data, discoverable via aicr criteria list)
• Changes follow existing patterns in the codebase
• Commits are cryptographically signed (git commit -S)