Release Notes

Release 2.0.0

This is the first release of the Alpamayo 2 Super NIM: container tag and GET /v1/version release 1.0.0. It is documented by documentation version 2.0.0, the version shown in this site’s version selector, which also retains the Alpamayo 1.5 pages. For prerelease containers, also record the image tag or digest because release candidates can report the same NIM version.

Capabilities

• Driving-scene inference: trajectory generation, visual question answering, meta-action prediction, auto-labeling, and visual grounding through POST /v1/infer. See Inference Tasks.
• Client APIs: HTTP for all five tasks, OpenAI-compatible trajectory and VQA routes, and gRPC Predict for trajectory generation. See API Reference.
• Deployment profiles: BF16 and ModelOpt FP8, with optional DFlash2 speculative decoding, on supported H100 and H200 GPUs. See Support Matrix.
• Trajectory control: multiple trajectory samples, explicit sampling seeds, and optional navigation guidance. See Sampling Control and Navigation-conditioned trajectory.
• Deployment tools: bundled scenes, payload builder, HTTP and gRPC clients, agent skills, custom checkpoint loading, and offline deployment instructions. Start with Quickstart Guide.
• Operations: health checks, active configuration discovery through GET /v1/models, and Prometheus metrics for requests, queues, and speculative decoding. See Observability.

Compatibility and limitations

All inference responses are returned in full; streaming is not supported. Each container uses one GPU and processes requests one at a time; startup rejects more than one visible GPU. BYOC accepts unquantized BF16 and ModelOpt FP8 checkpoints and rejects other checkpoint quantizations at startup. Grounding responses carry bbox_space (grid_0_1000), and GET /v1/models reports action_expert_max_batch_size. The served model ID is nvidia/alpamayo-2-super; requests that name the earlier ID nvidia/Alpamayo2-Super are still accepted. GET /v1/models also reports root, the directory of the selected profile’s checksums.blake3 model-file manifest. For current limitations and operational guidance, see Known Issues and Limitations.

Migrating from Alpamayo 1.5

Update the model ID to nvidia/alpamayo-2-super and use the Alpamayo 2 Super examples. Images, camera layouts, and precision profiles differ from 1.5.

Alpamayo 2 Super uses vLLM-Omni as its serving backend. Read the active backend from GET /v1/models and use the Super-specific configuration and warmup guidance. Compatible HTTP envelopes do not imply identical runtime behavior.

• Send task with trajectory, vqa, meta_action, auto_labeling, or grounding, and use task="vqa" for questions. The legacy mode field remains accepted: trajectory selects trajectory generation, answer selects VQA, and both returns combined output. The API reference maps every task to its mode value.
• The default driving layout has six cameras with four frames each (24 images), plus 16 ego-history poses. Trajectory accepts an explicitly declared subset of those cameras, including the four-camera layout; meta-action and auto-labeling retain the complete profile. See Camera order and sample files.
• Multi-image VQA without camera_order reads 24 images in the same six-camera driving order as trajectory and the bundled samples. Declare camera_order for other layouts, including rear_tele.
• POST /v1/infer also accepts the OpenAI-style model (served ID or empty) and stream (false) fields, and responses add finish_reason, time_step and warnings. See API Reference.
• Select bf16 or fp8, or an opt-in DFlash2 variant. There is no w4a16 profile. See Support Matrix for GPU requirements.
• Omit max_tokens from trajectory-producing requests; including it returns HTTP 422. The NIM manages the trajectory generation budget.
• Use the HTTP status code and status field for readiness checks. The readiness object string is now Alpamayo model readiness check.

For the previous generation’s capabilities and deployment instructions, see Alpamayo 1.5 Documentation.