# Runway Praxis-1: GPU Requirements, Checkpoints and How to Evaluate It

The robot model is now open weight, but choosing the right checkpoint and runtime matters more than the headline benchmark.

By Paras Madan | 2026-11-12


Runway released Praxis-1 publicly on November 11, moving its robot-control model beyond the partner preview announced in September. The weights and inference and fine-tuning code are available under Apache 2.0. For a robotics team deciding whether to try it, the first questions are the robot configuration, GPU memory and evaluation setup.

## What is available now?

The [public-release announcement](https://runway.com/news/company-news/praxis-1-is-now-available) describes a model that predicts video and robot actions together, with full fine-tuning and LoRA support. That is a useful change in access: teams can inspect and adapt the system rather than depend entirely on a closed service. It is not evidence that a downloaded checkpoint will safely operate an arbitrary robot.

Choose the checkpoint before planning the integration. The DROID variant targets a single Franka-style arm with exterior and wrist cameras. The YAM variant targets a bimanual setup. The base checkpoint is the starting point for adapting to a new rig, not a ready-made controller for any arm. A camera feed and an instruction are only part of the interface; pose conventions and action interpretation have to match too.

## Which GPU should you plan for?

The [upstream repository](https://github.com/runwayml/praxis-1-oss) gives a conservative starting point: its quickstart uses Python 3.12, a CUDA 13.0 driver and one GPU with at least 80 GB of memory. The bfloat16 policy weights alone occupy about 54 GB. Treat that documented path as the baseline, rather than inferring a memory requirement from the model's active parameter count.

The repository also lists NVFP4 versions of the DROID and YAM checkpoints. These are separately fine-tuned quantized variants, not a switch that makes every GPU compatible. The current implementation explicitly rejects native NVFP4 mode on H100, while supporting particular newer NVIDIA architectures.

**Hardware support is a combination of checkpoint, precision and kernels, not just the GPU name.** A launch-page list that includes workstation cards does not mean the bfloat16 quickstart fits every workstation card. Before buying or renting hardware, match the exact runtime configuration to the documented memory and architecture requirements.

## Pick one integration path and keep it reproducible

The [LeRobot adapter documentation](https://huggingface.co/docs/lerobot/main/en/praxis) is on the main documentation branch, which requires installation from source. It provides converted DROID, YAM and base checkpoints; the base needs robot heads initialized before use. Do not assume a plain installation of an older stable LeRobot release includes the same adapter.

The adapter documents GPU-specific attention behavior. On RTX Blackwell, automatic selection uses Triton because the required FlashAttention-4 block-sparse path is unavailable. It also warns about older Transformers versions loading the text encoder incorrectly, with a compatibility fix in the policy.

The practical lesson is to keep the checkpoint revision, framework versions, attention backend and sampler configuration together in the experiment record. Mixing a tutorial's package versions with a different runtime's configuration makes a failed rollout much harder to diagnose. Start with one documented stack, then change one component at a time.

## Evaluate the robot, not the demo video

Runway's [technical report](https://runway.com/research/praxis-1-video-pretraining-to-robot-control) reports 46.2% success over 1,200 RoboLab-120 simulation episodes. Its leading position is within world action models and open-source robot foundation models, not every system on the leaderboard. The report explicitly identifies higher-scoring agents and closed models.

The same report names look-alike objects, vague instructions and long multi-step prompts as limitations. Those are useful evaluation categories. A team testing a sorting task should vary the distractors and wording, not merely replay the cleanest scene with the clearest prompt.

For an initial evaluation, begin in simulation with a small, fixed task set. Record both completion and failure behavior, then repeat with changed object positions and ambiguous targets. Before moving to hardware, validate the camera mapping, coordinate frames and stop behavior independently of model quality. These are suggested engineering checks, not results from a hands-on test here.

Praxis-1 normally produces a chunk of motion before receiving fresh observations. That makes interruption and recovery important questions for the surrounding control system. A useful trial should show what happens when execution cannot continue, not only how quickly the robot finishes when everything goes right.

Open weights remove a vendor-access barrier. They do not remove integration work or the need to establish a safe operating envelope. The valuable result of an early evaluation is a defensible account of where the model works, where it fails and what it costs to run on your actual rig.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn model releases and engineering results into clear stories developers can evaluate and use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).