Sampling Control
Alpamayo1.5 NIM exposes request parameters for controlling VLM rollout, trajectory sampling, and optional navigation text.
Trajectory Inputs
Trajectory requests require compressed camera images and ego-motion history. The default layout is 16 images: four timesteps for each of four cameras. When camera_order is omitted, the NIM assumes this default camera-major order:
t0 is the oldest frame, approximately t-0.3s. t3 is the current frame.
Reduced image layouts are supported. For any trajectory request that does not use the default 16-image layout, include both camera_order and num_frames_per_camera. Images must still be ordered camera-major: all timesteps for the first camera, then all timesteps for the next camera. For example:
This layout expects front_wide_t0 through front_wide_t3. A layout such as camera_order=["cross_left", "front_wide", "cross_right", "front_tele"] and num_frames_per_camera=1 expects one current-frame image for each camera. If a trajectory request sends fewer or more than 16 images without camera_order, request-model validation returns HTTP 422 because the NIM cannot infer the image grouping.
Camera names can be full Alpamayo camera names, such as camera_front_wide_120fov, or OSS short names, such as front_wide.
The ego-motion history length is independent of the image layout. Every trajectory request, including reduced and single-image requests, requires all 16 history entries. Do not shorten the history to match the number of images.
Use JPEG input images when possible. JPEG payloads are smaller than PNG and use the fastest image decode path in the NIM.
VQA Inputs
Visual question answering accepts one or more compressed images and preserves the image order sent by the client. VQA requests do not require ego-motion. Use JPEG images when possible. Common benchmark-style layouts such as one image, three images, five frames, and six camera views are accepted.
Sampling Parameters
Reproducibility
HTTP and gRPC requests can include seed to initialize sampling state. When seed is omitted, the container-level NIM_ALPAMAYO_SEED value is used. For repeatable K=1 trajectory inference in the same deployment, use the same input with num_traj_samples=1, a fixed seed, top_k=1, and top_p=1:
The seed controls diffusion sampling. top_k=1 requests top-1 VLM decoding, and top_p=1 leaves nucleus sampling unrestricted so it does not filter the top-1 token.
K Values
The active K values are controlled by NIM_ALPAMAYO_TRAJ_SAMPLES. Configure only the K values your deployment needs. Use an explicit comma-separated list such as 1,2,3 or 1,10. Each configured value is warmed during startup and retained for CUDA graph performance, so broad K lists can increase startup time and GPU memory usage. Requests outside the configured list return a client error. For example, num_traj_samples=2 when NIM_ALPAMAYO_TRAJ_SAMPLES=1,10 returns an error that the profile supports only those values.
For the full profile matrix, refer to Support Matrix.
Trajectory Metrics
Trajectory responses include a metrics object with trajectory-only kinematic metrics. The primary comfort metrics are scalar pass rates in [0, 1] across the generated trajectory samples:
comfort_lat_accelcomfort_lon_accelcomfort_lon_jerkcomfort_yaw_accelcomfort_yaw_rate
These metrics are computed from the generated trajectory and predicted ego rotations. Evaluation-only metrics that require ground truth or map geometry are not part of the normal inference response.
The object also reports its schema version, time_step_s, comfort thresholds, aggregate min/mean/max kinematic summaries, and a per_sample breakdown. Refer to API Reference for the full field list and units.
The response includes pred_rotations as rotation matrices with shape [K, num_points, 3, 3]. This matches the OSS pred_rot output after squeezing the batch and trajectory-set dimensions.