alpamayo2-super

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Alpamayo 2 Super

Run NVIDIA's real VLM plus 2.3B diffusion expert. Never replace inference with
an import, fabricated trajectory, or manifest-only smoke.

## Legal gates

Keep the boundaries separate:

- Source: `NVlabs/alpamayo2@beb2977d9a7e9d66837d4a3ad5144ff59de37519`,
  Apache-2.0, baked with its license and the marked dataset-revision patch.
- Model: `nvidia/Alpamayo2-Super@00554695e729a6ff0b6281fd2c81b18d06e33dbe`,
  OpenMDW-1.1. Acceptance is by exercising granted rights. Fetch at runtime.
- Dataset: `nvidia/PhysicalAI-Autonomous-Vehicles@b719eea7f0a63619ef51ec7f54178af0937ef050`,
  gated by NVIDIA's AV Dataset License. It is non-transferable; accept it
  interactively on Hugging Face and fetch it only into the operator cache.
- Outputs: OpenMDW-1.1 imposes no output restriction, but Alpamayo is not an
  automotive-grade driving stack. Preserve model-card safety provenance.

Before provisioning, run:

```bash
npa workbench health preflight
npa workbench health access --capability alpamayo2-super
```

A missing dataset entitlement is terminal. Open the exact URL printed by the
access command; Hugging Face acceptance cannot be automated by NPA.

## Build and scan

Build only from the checked-in Dockerfile. Never pass `HF_TOKEN` as a build arg
or populate `/workspace/.cache/huggingface` during a build.

```bash
bash npa/docker/workbench/alpamayo2-super/build.sh
npa/.venv/bin/python npa/scripts/scan_image_alpamayo2_payload.py \
  <exact-local-image>
```

Require a complete clean scan over every layer for checkpoints, PhysicalAI-AV
payload, caches, and credentials. Inspect SBOM/provenance separately; the byte
scanner is not a license review.

## Run the workflow

Use B200 first. The workload is headless and does not need RT cores; its measured
H100 peak is 72,115 MiB, so one B200 has ample memory. Validate RTX PRO 6000
separately because B200 `sm_100` does not prove RTX `sm_120`.

```bash
npa workbench workflow validate-spec \
  workflows/testing/alpamayo2-super-inference.yaml
npa workbench workflow submit \
  workflows/testing/alpamayo2-super-inference.yaml \
  --infra <configured-infra-target> --var bucket=<operator-bucket> \
  --secret-env HF_TOKEN --secret-env AWS_ACCESS_KEY_ID \
  --secret-env AWS_SECRET_ACCESS_KEY
```

The run must publish non-empty `trajectory.json`, `trajectory.png`, and
`result.json`. Verify exact model/dataset revisions, the runtime image digest,
`weights_baked=false`, `dataset_baked=false`, and the node-local ephemeral cache
tier. Treat success without all three artifacts as failure.

## Diagnose

For HTTP serving, configure `NPA_ALPAMAYO2_SUPER_TOKEN` as a deployment secret
and `NPA_ALPAMAYO2_SUPER_OUTPUT_ROOT` as an operator-owned local `0700`
directory or authorized S3 prefix. All operational routes require bearer
authentication; keep transport private or terminate HTTPS. HTTP clients can
select samples and inference controls, but cannot change the pinned model,
dataset revision, or startup snapshot of `NPA_ALPAMAYO2_SUPER_MANIFEST`.
Their `output_path` is a result label, and the server creates a fresh prefix
under its configured root. Trusted CLI/SDK customization remains available.
Keep the container-native health check on
`npa.workbench.alpamayo2_super.healthcheck`; it reads the admission credential
from the runtime environment and authenticates `/health` without putting the
credential in process arguments or output.

- 401/403 before GPU allocation: accept the dataset agreement with the same HF
  account or replace the rejected token; do not add an NPA bypass boolean.
- CUDA OOM: confirm one trajectory sample, ten diffusion steps, and no competing
  process; do not silently reduce cameras or frames.
- `no kernel image`: inspect Torch arch flags and flash-attn build targets.
  B200 requires `sm_100`; RTX PRO 6000 requires `sm_120`.
- Missing camera projection: retain fail-closed `--require-camera-projection`.
- Pending job: inspect scheduling and image-pull evidence. Change GPU products
  only for scheduler/capacity evidence and record a separate architecture result.

Cancel the exact run before teardown. Never delete shared operator resources
merely because a validation job finished.

## Accepted release baseline

`0.1.0-cu128-r3` is the accepted runtime-fetch baseline. Its OCI index digest is
`sha256:17a3966a6e743cf34ecaeb2ef684272646c815d07a8a4668ccebf17de6aa0e07`.
It was built from source commit `5b693476c113c833e9d9d4f8c7aa492492a27505`,
which includes the `HTTPConnection` loopback healthcheck fix. Later acceptance
metadata commits are not the image source. On 2026-09-16 the exact digest
completed the real upstream workflow on B200 (`sm_100`) and, independently,
RTX PRO 6000 (`sm_120`). The 25-layer payload scan and complete
vulnerability/secret/license scan were clean. Both runs
produced all three required artifacts, projected shape `[1, 1, 1, 64, 3]`, and
runtime-only model/data provenance. B200 measured ADE 1.503835 and FDE 4.357265;
RTX measured ADE 1.501321 and FDE 4.351557. Neither r3 run recorded a trustworthy
peak allocation, so retain NVIDIA's 72,115 MiB H100 measurement as the
conservative documented reference rather than inventing a B200 or RTX number.

For RTX qualification, preserve the committed B200 default and override the
submitted accelerator with `NPA_WORKFLOW_GPU_ACCELERATOR=RTXPRO6000:1`. Require
the same three artifacts and provenance checks; do not infer RTX support from a
B200 result.

## Verify changes

For Ray scenario/seed/diffusion experiments, use
`workflows/testing/alpamayo2-ray-sweep.yaml` and
`workflows/testing/alpamayo2-ray-hardcases.yaml`, derived from the inference

From nebius/nebius-physical-ai, Apache-2.0.

More from nebius/nebius-physical-ai