feat(evidence): publish GB300 EKS training and inference evidence at v0.21.1 - #2812
Conversation
Recipe evidence checkProtected recipesRecipes with committed evidence (
How to refresh evidenceRun on a cluster matching the recipe's aicr snapshot -o snapshot.yaml
# Profiled families (AKS/GKE gpuStack): hydrate the recipe with the
# pointer's recorded 'profile:' selection first — validating the raw
# overlay resolves only the declaration default, and 'aicr validate'
# has no --profile flag. AKS additionally needs the pool projection
# (GKE uses the plain snapshot above):
# az aks nodepool list -g <rg> --cluster-name <cluster> -o json > pools.json
# aicr snapshot --aks-gpu-pools pools.json -o snapshot.yaml
# aicr recipe -s snapshot.yaml --intent <intent> [--platform <platform>] \
# --profile <name>=<value> -o recipe.yaml
# State the target leaf's intent/platform explicitly (the snapshot
# fingerprint supplies service/accelerator/OS but intent and platform
# default to 'any') and pass -r recipe.yaml below instead of the raw
# overlay.
aicr validate \
-r recipes/overlays/<slug>.yaml \
-s snapshot.yaml \
--emit-attestation ./out \
--push ghcr.io/<your-fork>/aicr-evidence
# Copy to the per-source path printed in the emit 'copyTo' hint:
# recipes/evidence/<slug>/<source>/<bundle-digest>.yamlThis gate is warning-only and never blocks merge. See ADR-007 for the trust model. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 12 included reviews per hour; 10 remain after this review. 📝 WalkthroughWalkthroughAdded schema-versioned attestation metadata for the Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Feature Merge Risk: ⚪ Minimal · up to The added evidence records conform to the repository’s validation contract, with no confirmed merge-blocking risk. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
7d08428 to
f594793
Compare
f594793 to
f509629
Compare
…v0.21.1 Signed-off-by: Yuan Chen <yuanchen97@gmail.com>
f509629 to
e07851e
Compare
Summary
Publishes signed recipe-evidence for both v1 Supported GB300 EKS coordinates, produced at the released v0.21.1 binary:
gb300-eks-ubuntu-training-kubeflowsha256:320d48c1…cc2e0gb300-eks-ubuntu-inference-dynamosha256:f8988045…2619aThe existing evidence for these coordinates records
aicrVersion: devin its signed predicate, which is what #2806 reports: the board shows evidence, but not against a shipped recipe version, so AICR's generated health table renders both rows aspending.Motivation / Context
Refs #2806
ROADMAP §2 declares both coordinates Supported with "deployment, conformance, and performance evidence published". These bundles record
aicrVersion: 0.21.1, supplying that at a released version.Type of Change
Component(s) Affected
recipes/)Implementation Notes
Run performed on EKS GB300 (
p6e-gb300r.36xlarge, 2 GPU nodes / 8 GPUs, Ubuntu 24.04, K8s v1.35.6), deployed from a clean teardown: fulltools/cleanup, GPU-node reboot (driver-managed cluster), then training bundle, then inference layered incrementally.Signed via the fork CI workflow with GitHub Actions ambient OIDC — no personal identity in the transparency log. Source slug
5bf9e82f…is already allowlisted, so noallowlist.yamlchange is needed.Testing
Both recipes validated with
aicr validate --emit-attestation, all phases green:gb300-eks-ubuntu-training-kubeflow— deployment 4/4, conformance 8/8, performance 2/2nccl-all-reduce-bw-net: 44.98 GB/s (threshold 40, floor 36)nccl-all-reduce-bw-nvls: 843.51 GB/s (threshold 700, floor 630)gb300-eks-ubuntu-inference-dynamo— deployment 4/4, conformance 11/11, performance 1/1inference-perf: 86,105.78 tok/s (constraint ≥ 60000), TTFT p99 183.51 ms (constraint ≤ 2000)aicr evidence verifyreturns exit 0 for both pointers.Risk Assessment
Low — adds two evidence pointer files, no code or recipe changes.
One thing reviewers should weigh rather than discover later:
kai-scheduler, which leaveskai-scheduler-defaultholding a stale ServiceAccount token;gang-schedulingfailed and Dynamo workers would not schedule.kubectl rollout restart deployment/kai-scheduler-defaultcleared it (401s 18→0), after which conformance passed 11/11. kai-scheduler Helm upgrade silently breaks all gang scheduling (stale ServiceAccount token) #2636 is closed but its proposedkai-scheduler-postmitigation was never implemented, so any two-intent incremental deploy still hits this.Checklist
-S) and signed off (-s)aicr evidence verifyexit 0 on both pointers