feat(recipes): add GKE GB200 (A4X) recipe with NVLS NCCL validation

Add the gb200-gke-cos-{training,training-kubeflow,training-slurm,
inference,inference-dynamo} recipe leaves, covering GB200 (A4X) on
GKE with COS. New gke-gb200-rdma component wires the NCCL gIB ARM64
plugin installer needed for GPUDirect-RDMA over RoCE, plus its
health check and BOM/tuning docs. The GKE multi-networking objects
(GKENetworkParamSet/Network: gvnic-1, rdma-0..rdma-3) are provisioned
with the cluster before the node pool exists, not by this component:
AICR treats them as a prerequisite and validates all 5 objects —
including deviceMode and parametersRef linkage — via health check.

GB200 on GKE is NVLS-only: MNNVL across the A4X nodes' IMEX domain is
the fabric that actually carries all-reduce traffic, so
nccl-all-reduce-bw-nvls (not the plain check) is wired into the
training leaves' performance phase, backed by a new runtime-nvls.yaml
TrainingRuntime template with IMEX ComputeDomain wiring. GPU NIC
discovery in the NCCL validator is skipped for this accelerator/service
pair since it uses the gke-gb200-rdma Network CRs instead of the TCPXO
gpu-nic-* fabric.

GB200 already has a Kubeflow leaf overlay on EKS and OKE; adds the
same kubeflow-trainer component here so GKE isn't the only GB200
platform missing one, giving robust-controller conformance a
supported operator to validate instead of always skipping.

Also adds a gb200-gke-cos-inference-dynamo leaf (grove + dynamo-platform,
DRA-gated to Kubernetes 1.34+), mirroring the GB200 EKS/OKE Dynamo
overlays' performance-gate thresholds until a GKE-specific baseline is
published. This turns the bare gb200-gke-cos-inference overlay from a
leaf into a base shared by both the plain and Dynamo inference leaves,
the same base/platform-variant pattern already used above for
training/training-kubeflow.

And a gb200-gke-cos-training-slurm leaf (Slinky operator + a
Slinky-managed Slurm cluster), mirroring gb200-eks-ubuntu-training-slurm's
GPU GRES, task isolation, and NVLS/IMEX ComputeDomain wiring for the same
4-GPU-per-node accelerator shape. Unlike the Kubeflow Trainer/JobSet
controllers above, Slinky's controller/restapi/nodeset Deployments already
go through AICR's ordinary nodeScheduling tolerationPaths, so this leaf
needs no Trainer-style toleration workaround.

Floor calibrated on a4x-highgpu-4g (4x GB200/node): 2-node/8-GPU
all_reduce_perf measured 281.936 GB/s avg bus bandwidth. Validated on
a live A4X cluster across conformance, deployment, and NVLS
performance for the training and training-kubeflow leaves.

gb200-gke-cos-inference-dynamo is validated across all three phases on
the same cluster: deployment, conformance, and performance (103,971
tokens/sec throughput, 1388.55ms TTFT p99). gb200-gke-cos-training-slurm
is validated through deployment and conformance, including the
GB200-specific slinky-slurm-imex-channel health check; its NVLS
performance phase has not yet been run. Signed evidence bundles for
both (Sigstore/Rekor, keyless OIDC) are pushed to
ghcr.io/mikecook/aicr-evidence with pointers committed under
recipes/evidence/, and the signer is added to the community allowlist.

Signed-off-by: Mike Cook <micook@nvidia.com>

Author: mikecook

docs/README.md

@@ -46,7 +46,7 @@ For pipelines and platforms that call AICR programmatically or host
 | Add or modify recipe metadata | [Recipe Development](integrator/recipe-development.md) |
 | Verify artifacts (SLSA, SBOM, attestations) | [Supply Chain Verification](integrator/supply-chain-verification.md) |
 | Ship custom validators via `--data` | [Validator Extension](integrator/validator-extension.md) |
-| Cloud-specific GPU setup | [AKS](integrator/aks-gpu-setup.md), [GKE](integrator/gke-gpu-setup.md), [EKS networking](integrator/eks-dynamo-networking.md), [GKE networking](integrator/gke-tcpxo-networking.md), [Talos](integrator/talos-integration.md) |
+| Cloud-specific GPU setup | [AKS](integrator/aks-gpu-setup.md), [GKE](integrator/gke-gpu-setup.md), [EKS networking](integrator/eks-dynamo-networking.md), [GKE TCPXO networking](integrator/gke-tcpxo-networking.md), [GKE GB200 networking](integrator/gke-gb200-networking.md), [Talos](integrator/talos-integration.md) |
 
 ### Contributor Guide
 

docs/contributor/validator.md

@@ -804,7 +804,7 @@ default** (`Qwen/Qwen3-8B` at 256/GPU). A non-positive / non-integer
 | `AICR_INFERENCE_PERF_WORKLOAD_READY_TIMEOUT` | `10m` | Wait for the `DynamoGraphDeployment` to become ready (image pull + model load + worker health). Large models load slower — raise this **and** the catalog entry's `timeout` in tandem, or the parent deadline caps it. |
 | `AICR_INFERENCE_PERF_HEALTH_TIMEOUT` | `5m` | Wait for the endpoint to serve a real chat-completion *after* the workload reports Ready. Concurrent first-load from one RWO cache PVC can push first-serve past 5m; raise it (bounded by the catalog `timeout`). |
 | `AICR_INFERENCE_PERF_MODEL_CACHE_SIZE` | `100Gi` (on) | The PVC-backed model-weights cache is **on by default**. Set a different K8s quantity to resize, or a disable sentinel (`off`/`0`/`none`/`disabled`) to turn it off and download from HF directly. |
-| `AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS` | cluster default | StorageClass for the cache PVC. On a cluster with **no default SC and no value here**, the check **fails fast** with guidance rather than leaving the PVC `Pending` until timeout. AICR-deployed EKS gets a default `gp3` SC from `aws-ebs-csi-driver`; GKE has `standard-rwo`. |
+| `AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS` | cluster default | StorageClass for the cache PVC. On a cluster with **no default SC and no value here**, the check **fails fast** with guidance rather than leaving the PVC `Pending` until timeout. AICR-deployed EKS gets a default `gp3` SC from `aws-ebs-csi-driver`; GKE has `standard-rwo` — **except A4X/GB200 nodes**, which reject `standard-rwo`'s `pd-balanced` disks and need a Hyperdisk-backed class (see [GKE GB200 Storage Prerequisites](../integrator/gke-gb200-networking.md#storage-prerequisites)). |
 | `AICR_INFERENCE_PERF_MODEL_CACHE_POPULATE_TIMEOUT` | `13m` | Wait for the one-time model-cache populate Job (cold image pull + first-ever Hugging Face download into the PVC). Separate from — and larger than — `AICR_INFERENCE_PERF_WORKLOAD_READY_TIMEOUT` because the populate Job pays a cold pull *and* a multi-GB download; provide the optional HF-token secret to remove anonymous-download throttling. Raise it (and the catalog `timeout`) for very large models. **Migration:** the cache-populate wait no longer honors `AICR_INFERENCE_PERF_WORKLOAD_READY_TIMEOUT` (which now bounds only the DynamoGraphDeployment readiness wait) — set this knob instead to widen the populate budget. |
 
 For gated models, or to lift Hugging Face rate limits on large downloads,

docs/index.yml

@@ -75,6 +75,8 @@ navigation:
         path: integrator/eks-dynamo-networking.md
       - page: GKE TCPXO Networking
         path: integrator/gke-tcpxo-networking.md
+      - page: GKE GB200 Networking
+        path: integrator/gke-gb200-networking.md
       - page: OpenShift Deployment
         path: integrator/openshift.md
       - page: Talos Integration

docs/integrator/components/nodewright.md

@@ -86,6 +86,7 @@ The table below is generated from the recipes by `make tuning-docs` — **do not
 | eks     | rtx-pro-6000 | generic | -                  | nvidia-tuned 0.3.2      |
 | gke     | a100         | h100    | -                  | nvidia-tuning-gke 0.1.2 |
 | gke     | b200         | -       | -                  | nvidia-tuning-gke 0.1.2 |
+| gke     | gb200        | -       | -                  | nvidia-tuning-gke 0.1.2 |
 | gke     | h100         | -       | -                  | nvidia-tuning-gke 0.1.2 |
 
 {/* END AICR-TUNING */}

docs/integrator/gke-gb200-networking.md

@@ -0,0 +1,280 @@
+# GKE GB200 (A4X) Networking Prerequisites
+
+For the **GB200 GKE COS** recipes (`gb200-gke-cos-training`,
+`gb200-gke-cos-training-kubeflow`, `gb200-gke-cos-training-slurm`, and
+`gb200-gke-cos-inference-dynamo`, all on `a4x-highgpu-4g` nodes),
+GPUDirect-RDMA over RoCE enables high-speed inter-node GPU communication on
+GKE. Without it, NCCL has no fabric to use and all-reduce falls back to the
+default network path.
+
+## Infrastructure Prerequisites
+
+GKE clusters must have multi-networking configured before deploying AICR bundles:
+
+- Multi-networking enabled (1 gVNIC + 4 RDMA NICs per `a4x-highgpu-4g` node)
+- `Network` + `GKENetworkParamSet` CRs for the gVNIC and 4 RDMA NICs (cluster-specific
+  VPC/subnet values, but fixed object names — see below; not managed by AICR)
+- `nccl-rdma-installer` DaemonSet on GPU nodes (included in the AICR bundle)
+
+The last one ships in the AICR bundle. The first is **cluster provisioning** —
+AICR's `gke-gb200-rdma` health check detects it but does not create it.
+
+### Provisioning multi-networking
+
+These steps are ordered, following Google's
+[A4X custom setup guide](https://docs.cloud.google.com/ai-hypercomputer/docs/create/gke-ai-hypercompute-custom-a4x):
+
+1. **Create the VPCs and subnets** — one dedicated VPC + subnet per NIC, five in
+   total (one gVNIC, four RDMA), in the cluster's region.
+2. **Create the cluster** with multi-networking enabled (HIPPO's `GKECluster` CR
+   does this via `spec.networks.managed.gb200NetworkStrategy`).
+3. **Create the GPU node pool** on an `a4x-highgpu-4g` machine type, attaching
+   the five VPC/subnet pairs as `additionalNodeNetworkConfigs`.
+4. **Apply the `Network` and `GKENetworkParamSet` CRs** — one pair per NIC,
+   binding each additional node network into the cluster so pods can reference
+   it. Unlike TCPXO (see [GKE TCPXO Networking](gke-tcpxo-networking.md)), the
+   **object names are fixed, not cluster-specific**: `gvnic-1` for the gVNIC and
+   `rdma-0` through `rdma-3` for the RDMA NICs. Only the `vpc`/`vpcSubnet` fields
+   inside each `GKENetworkParamSet` vary per cluster (they name the VPC/subnet
+   your cluster actually has):
+
+```yaml
+apiVersion: networking.gke.io/v1
+kind: GKENetworkParamSet
+metadata:
+  name: gvnic-1
+spec:
+  vpc: "PREFIX-gvnic"
+  vpcSubnet: "PREFIX-gvnic"
+  deviceMode: NetDevice
+---
+apiVersion: networking.gke.io/v1
+kind: Network
+metadata:
+  name: gvnic-1
+spec:
+  type: "Device"
+  parametersRef:
+    group: networking.gke.io
+    kind: GKENetworkParamSet
+    name: gvnic-1
+```
+
+   Repeat for `rdma-0` through `rdma-3`, pointing `vpc`/`vpcSubnet` at
+   `PREFIX-gpu-nic-{0..3}-gb` (or whatever names your VPCs/subnets were given
+   in step 1, with `PREFIX` replaced by your own).
+
+> **The fixed naming is a requirement, not a convention.** AICR's
+> `checks/gke-gb200-rdma/health-check.yaml` asserts these five objects by exact
+> name (`gvnic-1`, `rdma-0`..`rdma-3`), including `spec.deviceMode` and
+> `spec.parametersRef` linkage. A cluster provisioned with different `Network`
+> names passes Google's own setup guide but fails this check — rename to match
+> before running `aicr validate`.
+
+AICR installs the `nccl-rdma-installer` DaemonSet and detects the CRs; it does
+not provision the networking itself. These steps are a summary of the
+prerequisite AICR depends on, not a complete provisioning runbook — follow
+Google's guide above for the full procedure, including firewall rules and
+supported GKE version floors.
+
+### Verifying
+
+```shell
+kubectl get network.networking.gke.io
+kubectl get gkenetworkparamset.networking.gke.io
+```
+
+Expect `gvnic-1` and `rdma-0` through `rdma-3` (plus the `default` network),
+each `Network` bound to its `GKENetworkParamSet` via `spec.parametersRef`.
+Fewer than five, or a `GKENetworkParamSet` with the wrong `deviceMode`, means
+the prerequisite is incomplete or misconfigured — `aicr validate` (via the
+`gke-gb200-rdma` health check) reports the shortfall by name.
+
+## Driver Installer
+
+`a4x-highgpu-4g` pools built with `--profile gpuStack=driver-installer` (see
+[GKE GPU Setup](gke-gpu-setup.md#alternative-let-gpu-operator-manage-the-device-plugin))
+need Google's standalone `nvidia-driver-installer` DaemonSet applied before
+GPU workloads can schedule. GB200's NVL72 domain needs GPU partitioning that
+Google's generic upstream COS manifest doesn't include — use a manifest with
+an added `partition-gpus` init container pinned to a
+[COS-qualified driver version](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus#cos):
+
+```yaml
+apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  name: nvidia-driver-installer
+  namespace: kube-system
+  labels:
+    k8s-app: nvidia-driver-installer
+spec:
+  selector:
+    matchLabels:
+      k8s-app: nvidia-driver-installer
+  updateStrategy:
+    type: RollingUpdate
+  template:
+    metadata:
+      labels:
+        name: nvidia-driver-installer
+        k8s-app: nvidia-driver-installer
+    spec:
+      priorityClassName: system-node-critical
+      affinity:
+        nodeAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+            nodeSelectorTerms:
+            - matchExpressions:
+              - key: cloud.google.com/gke-accelerator
+                operator: Exists
+              - key: cloud.google.com/gke-gpu-driver-version
+                operator: DoesNotExist
+              - key: gke-no-default-nvidia-gpu-device-plugin
+                operator: In
+                values: ["true"]
+              - key: cloud.google.com/gke-confidential-nodes-instance-type
+                operator: DoesNotExist
+      tolerations:
+      - operator: Exists
+      hostNetwork: true
+      hostPID: true
+      volumes:
+      - name: dev
+        hostPath:
+          path: /dev
+      - name: vulkan-icd-mount
+        hostPath:
+          path: /home/kubernetes/bin/nvidia/vulkan/icd.d
+      - name: nvidia-install-dir-host
+        hostPath:
+          path: /home/kubernetes/bin/nvidia
+      - name: root-mount
+        hostPath:
+          path: /
+      - name: cos-tools
+        hostPath:
+          path: /var/lib/cos-tools
+      - name: nvidia-config
+        hostPath:
+          path: /etc/nvidia
+      initContainers:
+      - image: "cos-nvidia-installer:fixed"
+        imagePullPolicy: Never
+        name: nvidia-driver-installer
+        resources:
+          requests:
+            cpu: 150m
+        securityContext:
+          privileged: true
+        env:
+        - name: NVIDIA_INSTALL_DIR_HOST
+          value: /home/kubernetes/bin/nvidia
+        - name: NVIDIA_INSTALL_DIR_CONTAINER
+          value: /usr/local/nvidia
+        - name: VULKAN_ICD_DIR_HOST
+          value: /home/kubernetes/bin/nvidia/vulkan/icd.d
+        - name: VULKAN_ICD_DIR_CONTAINER
+          value: /etc/vulkan/icd.d
+        - name: ROOT_MOUNT_DIR
+          value: /root
+        - name: COS_TOOLS_DIR_HOST
+          value: /var/lib/cos-tools
+        - name: COS_TOOLS_DIR_CONTAINER
+          value: /build/cos-tools
+        volumeMounts:
+        - name: nvidia-install-dir-host
+          mountPath: /usr/local/nvidia
+        - name: vulkan-icd-mount
+          mountPath: /etc/vulkan/icd.d
+        - name: dev
+          mountPath: /dev
+        - name: root-mount
+          mountPath: /root
+        - name: cos-tools
+          mountPath: /build/cos-tools
+        command:
+        - bash
+        - -c
+        - |
+          echo "Checking for existing GPU driver modules"
+          if lsmod | grep nvidia; then
+            echo "GPU driver is already installed, skipping installation"
+            exit 0
+          else
+            echo "No GPU driver module detected, installing 580.126.20"
+            /cos-gpu-installer install --version=580.126.20 || exit 1
+            chmod 755 /root/home/kubernetes/bin/nvidia
+          fi
+      - image: "gcr.io/gke-release/nvidia-partition-gpu@sha256:de12f85ebfb4fb6c1893cd30c23aab662a72fa0448f97ef74fccb82d7522ef17"
+        name: partition-gpus
+        env:
+        - name: LD_LIBRARY_PATH
+          value: /usr/local/nvidia/lib64
+        resources:
+          requests:
+            cpu: 150m
+        securityContext:
+          privileged: true
+        volumeMounts:
+        - name: nvidia-install-dir-host
+          mountPath: /usr/local/nvidia
+        - name: dev
+          mountPath: /dev
+        - name: nvidia-config
+          mountPath: /etc/nvidia
+      containers:
+      - image: "gke.gcr.io/pause:3.8@sha256:880e63f94b145e46f1b1082bb71b85e21f16b99b180b9996407d61240ceb9830"
+        name: pause
+```
+
+Re-pin the driver version (`580.126.20` above) and the `partition-gpus` image
+digest to whatever your GKE version's COS driver table and Google's release
+notes currently list — both drift over time and are not managed by AICR.
+
+## Storage Prerequisites
+
+`a4x-highgpu-4g` nodes reject the `pd-balanced` disk type that GKE's default
+StorageClass (`standard-rwo`) provisions: `pd-balanced disk type cannot be
+used by a4x-highgpu-4g machine type`. Any PVC scheduled onto a GB200 node —
+notably the `inference-perf` validator's model-weights cache
+(`AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS`, see
+[Validation](../user/validation.md)) — needs a Hyperdisk-backed StorageClass
+instead. Like the RDMA CRs above, this is a cluster prerequisite AICR does
+not provision:
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: hyperdisk-balanced
+provisioner: pd.csi.storage.gke.io
+parameters:
+  type: hyperdisk-balanced
+volumeBindingMode: WaitForFirstConsumer
+allowVolumeExpansion: true
+```
+
+Apply it once per cluster, then point the validator's model cache at it via
+an `AICR_INFERENCE_PERF_MODEL_CACHE_STORAGE_CLASS=hyperdisk-balanced` entry
+on the `inference-perf` catalog entry's `env` (or a catalog overlay in the
+`aicr validate --data <dir>` directory).
+
+## Running the NCCL Benchmark
+
+The GB200 GKE training recipe (`gb200-gke-cos-training`) selects the
+NVLS-variant performance check (`nccl-all-reduce-bw-nvls`) — MNNVL across the
+A4X nodes' IMEX domain is the fabric that carries all-reduce traffic; gIB is the
+transport driver underneath, not the NCCL algorithm itself. Run it via:
+
+```shell
+aicr validate --recipe recipes/overlays/gb200-gke-cos-training.yaml \
+  --phase performance
+```
+
+## References
+
+- [GKE A4X custom setup guide](https://docs.cloud.google.com/ai-hypercomputer/docs/create/gke-ai-hypercompute-custom-a4x)
+- [Component Catalog](../user/component-catalog.md)
+- [Validation readiness gate](../user/validation.md)
+- [GKE TCPXO Networking](gke-tcpxo-networking.md)

docs/integrator/gke-gpu-setup.md

@@ -212,7 +212,14 @@ install comes up **driverless** — never combine the label with
 must instead be created with `gpu-driver-version=disabled`, with driver
 provisioning supplied by Google's standalone
 [`nvidia-driver-installer` DaemonSet](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus#installing_drivers)
-applied to the cluster.
+applied to the cluster — **apply it before or right after pool creation**;
+until it lands, nodes come up with no `nvidia` kernel module loaded and the
+GPU Operator's toolkit/driver-validation init containers block waiting for a
+driver that never arrives. On A4X/GB200 (`a4x-highgpu-4g`) nodes, Google's
+generic upstream manifest is not sufficient — GB200's NVL72 domain needs an
+extra GPU-partitioning init container the generic manifest omits; see
+[GKE GB200 Networking › Driver Installer](gke-gb200-networking.md#driver-installer)
+for the GB200-specific manifest.
 
 Set the label when you create the GPU node pool, alongside the disabled
 managed install:
@@ -431,3 +438,4 @@ confirm exactly which advertiser owns each node.
 - [Component Catalog › GKE Device-Plugin Ownership](../user/component-catalog.md#gke-device-plugin-ownership)
 - [Validation readiness gate](../user/validation.md)
 - [GKE TCPXO Networking](gke-tcpxo-networking.md)
+- [GKE GB200 Networking](gke-gb200-networking.md)

docs/integrator/index.md

@@ -22,6 +22,7 @@ This section is for integrators who:
 | [Kubernetes Deployment](kubernetes-deployment.md) | Self-hosted API server deployment with Kubernetes manifests |
 | [EKS Dynamo Networking](eks-dynamo-networking.md) | Security group prerequisites for Dynamo overlays on EKS |
 | [GKE TCPXO Networking](gke-tcpxo-networking.md) | GPUDirect TCPXO prerequisites for GKE training overlays |
+| [GKE GB200 Networking](gke-gb200-networking.md) | GPUDirect-RDMA prerequisites for GB200 (A4X) GKE overlays |
 | [AKS GPU Setup](aks-gpu-setup.md) | AKS prerequisites: Kubernetes 1.34+ (DRA GA), GPU driver setup, DRA configuration |
 | [GKE GPU Setup](gke-gpu-setup.md) | GKE device-plugin ownership: the `gpuStack` profile, node-pool setup for both values, verification, and troubleshooting |
 | [Talos Integration](talos-integration.md) | Running AICR on Talos Linux |

docs/user/container-images.md

@@ -19,8 +19,8 @@ A machine-readable **CycloneDX 1.6 JSON** companion to this page is produced by
 <!-- BEGIN AICR-BOM -->
 ## Summary
 
-- Components: **43**
-- Unique images: **98**
+- Components: **44**
+- Unique images: **99**
 - Distinct registries: **11**
 
 Registries: `602401143452.dkr.ecr.us-west-2.amazonaws.com`, `cr.agentgateway.dev`, `docker.io`, `gcr.io`, `ghcr.io`, `gke.gcr.io`, `nvcr.io`, `public.ecr.aws`, `quay.io`, `registry.k8s.io`, `us-docker.pkg.dev`
@@ -40,6 +40,7 @@ _Rendering fidelity:_ `catalog-parity: charts are rendered with the shared recip
 | cert-manager-ocp-olm | manifest | — | — | 0 |
 | dynamo-platform | helm | dynamo-platform | 1.2.1 | 3 |
 | gatekeeper | helm | gatekeeper/gatekeeper | 3.22.2 | 3 |
+| gke-gb200-rdma | manifest | — | — | 2 |
 | gke-nccl-tcpxo | manifest | — | — | 4 |
 | gpu-operator | helm | nvidia/gpu-operator | v26.3.3 | 15 |
 | gpu-operator-ocp | manifest | — | — | 0 |
@@ -134,6 +135,11 @@ _No images extracted._
 - `openpolicyagent/gatekeeper-crds:v3.22.2`
 - `openpolicyagent/gatekeeper:v3.22.2`
 
+### gke-gb200-rdma
+
+- `gke.gcr.io/pause:3.8@sha256:880e63f94b145e46f1b1082bb71b85e21f16b99b180b9996407d61240ceb9830`
+- `us-docker.pkg.dev/gce-ai-infra/gpudirect-gib/nccl-plugin-gib-arm64:v1.1.2@sha256:6b7950cac6e6833661d4206920f5633b6e361b18bfd5315b63f9bf4a4b84a80e`
+
 ### gke-nccl-tcpxo
 
 - `gcr.io/gke-release/nri-device-injector:1.0.25-gke.6@sha256:7704e2bd74b8edbb76b6913c7904cc2362f1fa887c4d4aba7b19778ea353537c`

docs/user/recipe-health.md

@@ -40,8 +40,8 @@ The deep-link is the current Evidence rendering. It is distinct from — and coe
 {/* BEGIN AICR-HEALTH */}
 ## Summary
 
-- Recipes: **45**
-- Pass: **45** · Warn: **0** · Fail: **0** · Unknown: **0**
+- Recipes: **48**
+- Pass: **48** · Warn: **0** · Fail: **0** · Unknown: **0**
 
 ## Recipes
 
@@ -77,6 +77,9 @@ The deep-link is the current Evidence rendering. It is distinct from — and coe
 | a100-gke-cos-training-kubeflow | gke | a100 | cos | training | kubeflow | pass | R:0 D:4 P:0 C:10 | pending |
 | b200-gke-cos-inference-dynamo | gke | b200 | cos | inference | dynamo | pass | R:0 D:4 P:0 C:11 | pending |
 | b200-gke-cos-training-kubeflow | gke | b200 | cos | training | kubeflow | pass | R:0 D:4 P:0 C:10 | pending |
+| gb200-gke-cos-inference-dynamo | gke | gb200 | cos | inference | dynamo | pass | R:0 D:4 P:1 C:11 | pending |
+| gb200-gke-cos-training-kubeflow | gke | gb200 | cos | training | kubeflow | pass | R:0 D:4 P:1 C:10 | pending |
+| gb200-gke-cos-training-slurm | gke | gb200 | cos | training | slurm | pass | R:0 D:4 P:0 C:12 | pending |
 | h100-gke-cos-inference-dynamo | gke | h100 | cos | inference | dynamo | pass | R:0 D:4 P:1 C:11 | pending |
 | h100-gke-cos-training-kubeflow | gke | h100 | cos | training | kubeflow | pass | R:0 D:5 P:1 C:10 | pending |
 | h100-gke-cos-training-slurm | gke | h100 | cos | training | slurm | pass | R:0 D:5 P:0 C:11 | pending |