The Pulse
AWS Publishes Production Blueprints for NVIDIA Cosmos 3
AWS has published reference architectures for running NVIDIA Cosmos 3 across data curation, fine-tuning, cloud inference and edge deployment. The plans combine Amazon S3, SageMaker HyperPod, EKS, JumpStart and IoT Greengrass, with different
AI.info Team · Written with AI ·
“Cosmos 3 delivers all three capabilities through one model and one inference call.”
Abhishek Srivastav, Ali Shahrokni and Brett Hamilton, AWS Physical AI Blog
A four-stage path from sensor data to robot
AWS published production reference architectures for NVIDIA Cosmos 3 on September 28, laying out how teams can take physical-world data from storage through model adaptation and deployment. The proposed pipeline uses Amazon S3 for incoming video, LiDAR and camera feeds; AWS Batch to run Cosmos Curator for filtering and quality scoring; and Amazon EKS with Milvus and Cosmos-embed NIM to search for relevant clips.
For model adaptation, AWS points to SageMaker HyperPod, where teams can fine-tune Cosmos 3 for their environments and robot tasks. The post describes adapting action outputs to a robot’s joint configuration, gripper and end-effector paths, then using the model’s forward-dynamics capability for closed-loop checks before physical deployment.
The architecture extends to devices as well as cloud services. AWS says the 4-billion-parameter Cosmos 3 Edge variant can run on NVIDIA Jetson hardware through AWS IoT Greengrass, with over-the-air model updates and sensor data sent back to S3 for later training. The design connects those steps into a loop rather than treating inference as the end of the pipeline.
One model family, three sizes
Cosmos 3 brings scene reasoning, world generation and action prediction into one model architecture. The earlier Cosmos setup used separate Predict, Transfer and Reason models, each with its own inference call and serving infrastructure, according to AWS. Cosmos 3’s Mixture-of-Transformers design instead pairs a reasoning tower with a generator that produces video and action outputs conditioned on that reasoning.
AWS lists three variants: Super at 64 billion parameters for higher-fidelity simulation and offline generation; Nano at 16 billion for production inference; and Edge at 4 billion for on-device use and low-latency control loops. The post presents those as different operating choices, not interchangeable checkpoints: the larger versions target cloud-scale workloads, while Edge is aimed at robots with local inference requirements.
The architecture’s promise is to keep spatial and task information from being lost as a system passes between separate models. In AWS’s description, one forward pass can produce reasoning, video, audio and action trajectories, including joint angles, gripper commands and six-degree-of-freedom paths.
EKS control or managed SageMaker endpoints
AWS sets out two cloud-serving routes. Teams that need control over Kubernetes scheduling, batching and routing can deploy GPU-backed Cosmos NIM microservices on EKS; the example uses Karpenter to provision GPU nodes and CloudWatch and Prometheus metrics to track utilization, queue depth and latency.
SageMaker JumpStart is the managed alternative. AWS says all three Cosmos 3 variants were available in JumpStart as of August 2026, with real-time endpoints for interactive requests and asynchronous endpoints for longer world-generation jobs. Checkpoints produced through HyperPod can also be registered in SageMaker Model Registry and served through the managed endpoint path.
The distinction is operational: EKS offers more control over the serving stack, while JumpStart reduces the infrastructure teams must operate. Neither route removes the need to select GPU capacity suited to the particular model and workload.
GPU guidance comes with a benchmarking caveat
AWS recommends g7e.2xlarge or p5.4xlarge instances for single-GPU Nano inference, associating them with an RTX PRO 6000 96 GB or an H100 80 GB. Its guidance for Nano throughput or post-training points to p5.48xlarge instances with eight H100 GPUs; multi-node post-training guidance names p5en.48xlarge with eight H200 GPUs and EFAv3.
For Super inference, AWS lists p5e.48xlarge or p5.48xlarge and advises using the runtime’s recommended parallelism layout rather than assuming a simple eight-way tensor-parallel setup. The post also says full Nano and Super checkpoints have been tested in BF16, while supported Cosmos 3 Generator NIM profiles offer separate FP8 options.
AWS gives sizing recommendations, not a comparative performance or price study. Its own guidance calls for validating sharding and replication against the chosen runtime, and benchmarking configurations before making performance claims. That leaves teams with concrete starting points for deployment—but still requires workload-specific testing to determine what a production system will cost and deliver.