Known Issues and Limitations

This page lists current operational limitations for Alpamayo1.5 NIM.

Startup and First-Request Latency

Initial startup downloads or loads model artifacts, initializes TensorRT-LLM, and runs warmup for every configured K value. It can take several minutes. Wait for GET /v1/health/ready to return HTTP 200 before sending inference. A first request can still be slower than steady state; run one untimed request before benchmarking.

Configured K Values Consume Startup Resources

Each value in NIM_ALPAMAYO_TRAJ_SAMPLES is warmed and retains shape-specific CUDA state. Configure only the trajectory counts your deployment serves. Broad K lists can increase startup time and GPU memory use. Refer to Support Matrix for validated limits.

CUDA JPEG Decoding Can Fall Back

JPEG input normally uses the accelerated decoder. If it fails for a valid payload, the request is retried with the regular decoder. Repeated failures can disable the CUDA JPEG path for the lifetime of that container, affecting preprocessing performance rather than response semantics. Recovery and diagnostic guidance are in Observability.

One GPU per Container

Alpamayo1.5 NIM uses one visible GPU per container. Run separate container instances and use an external load balancer when scaling across GPUs.

Reporting an Issue

When requesting support, include the output of GET /v1/version, the selectedModelProfileId from GET /v1/metadata, GPU and driver information from nvidia-smi, the relevant HTTP or gRPC status and error message, and container logs around the failure. Do not include API keys or model request content that your organization treats as sensitive.