How is pricing calculated?

Pricing is based on the hourly rate of operators in your selected region. You only pay for the time operators spend controlling your robots.

What robots are supported?

We support 9+ robot arms including SO-100, Koch, Franka FR3, Franka Panda, WidowX 250, ViperX 300, ViperX 300s, and ALOHA.

What is the latency for teleoperation?

Our platform provides ultra-low latency of 30-70ms worldwide, enabling real-time responsive robot control.

π0-FAST

Physical Intelligence, United States · January 2025

Foundation VLAOpen weights, Apache-2.0Also written pi0-FAST, pi0 FAST

Parameters: 3 B; The FAST paper describes the model as built on π0, a VLA based on PaliGemma-3B, and in the DROID training details refers to...
GPU memory: 8 GB; reported by the authors
Inference latency: 750 ms; NVIDIA 4090 GPU, per one-second action chunk.
Weights: Apache-2.0; Apache-2.0 for the openpi repository.

What it is

π0-FAST is π0's architecture with the flow matching expert replaced by autoregressive decoding over FAST action tokens, where FAST compresses an action chunk with a discrete cosine transform before byte-pair encoding it. The point of the paper is training economics: the same evaluation performance for about a fifth of the GPU hours, plus a universal FAST+ tokenizer that other autoregressive VLAs can reuse. The cost lands at inference, where decoding 30 to 60 tokens per chunk takes roughly 750 ms on a 4090 against under 100 ms for diffusion π0. That makes it a good research and pre-training vehicle and a poor choice for reactive closed-loop control. Physical Intelligence itself drew that conclusion, keeping FAST for π0.5 pre-training and reverting to a flow matching expert for deployment.

Architecture

Backbone: PaliGemma-3B, the same backbone as π0, but used autoregressively with no separate action expert
Action head: autoregressive discrete tokens produced by the FAST tokenizer (discrete cosine transform of the action chunk, quantisation, then byte-pair encoding), decoded token by token
Action chunk: 32 steps per forward pass
Parameters: The FAST paper describes the model as built on π0, a VLA based on PaliGemma-3B, and in the DROID training details refers to the 3B parameter VLAs we are using. openpi's Pi0FASTConfig (src/openpi/models/pi0_fast.py) sets paligemma_variant gemma_2b and defines no action expert, so unlike π0 there is no additional 300M expert on top.
Pretraining data: Trained on the same cross-embodied mixture as π0, described as 903M timesteps from Physical Intelligence's own datasets plus open-source data, and reported as scaling to 10k hours of robot data. The separate FAST+ universal tokenizer was fitted on approximately 1 million one-second real robot action chunks spanning single-arm, bimanual and mobile robots with joint and end-effector action spaces at various control frequencies. The released π0-FAST-DROID checkpoint was trained on 75k successful DROID episodes for three epochs (240k iterations at batch size 256), taking about 4 days on 8x H100.
Embodiments: Franka (DROID setup), UR5e, bimanual ALOHA style arms, mobile manipulators

What hardware it needs

This is the section most people came for, so it is worth being precise about which numbers are measured and which are arithmetic.

Computed from 3 B parameters. Weights only, so treat it as a floor: activations, image encoder intermediates and the CUDA context come on top, in practice 30 to 50 percent more for inference.
Precision	Weights	Note
fp32	11 GB	Training master weights, rarely used for inference
bf16 or fp16	5.6 GB	The usual way these checkpoints are served
int8	2.8 GB	Quantised, expect some loss of precision on fine motions
int4	1.4 GB	Aggressive quantisation, verify success rate before trusting it

Smallest real card that fits the bf16 weights plus a 40 percent runtime allowance: 8 GB. That is an estimate for inference, not for fine tuning. Full fine tuning also holds optimiser state and gradients, which typically costs several times the weights unless you use LoRA or a comparable adapter.

Published figures. These come from the model authors, not from this site.
Inference memory, reported	8 GB
Fine tuning memory, reported	22.5 GB
Inference latency, reported	750 ms on NVIDIA 4090 GPU, per one-second action chunk. The paper states that π0 with diffusion typically predicts one-second chunks within 100 ms on the same GPU, while π0 with FAST tokenization needs approximately 750 ms because it must run 30 to 60 autoregressive decoding steps instead of 10 diffusion steps.

openpi names the RTX 4090 for inference and LoRA. Reproducing the DROID checkpoint took 8x H100 for about 4 days.

Reported results

Grouped by what the evaluation actually asked. Values from different suites are not comparable with each other, so each one keeps its suite and split.

Simulation

No results in this category are published for this model.

Real world

Rollouts on physical hardware. The setups differ, so read these as evidence, not as a ranking.

FAST tokenizer compression analysis (FAST paper Table I) One-second action chunks across datasets with different action dimensions and control frequencies
30 tokens
action tokens emitted per one-second chunk per robot armRoughly 30 tokens per arm, so about 60 for a bimanual setup. This is a tokenizer property rather than a task score, but it is the number that determines the autoregressive decoding cost and therefore the 750 ms latency.source
π0 generalist training run (FAST paper Figure 11) Cross-embodied 903M timestep mixture, robot evaluation across the π0 task set
5 x fewer GPU hours
reduction in GPU hours needed to reach comparable evaluation performance versus diffusion π0First-party claim by the model authors. The paper states the model in the evaluations required 5x fewer GPU hours for training than the π0 model of Black et al., and that π0-FAST matches diffusion π0 performance. The underlying per-task success rates are shown only as bar charts and are not tabulated.source

Fine tuned tasks

No results in this category are published for this model.

On real hardware

The released π0-FAST-DROID policy was evaluated zero shot on table-top manipulation in environments unseen during training, at UC Berkeley, Stanford and the University of Washington, prompted purely in natural language. It uses a joint-velocity plus absolute-gripper action space, predicts 15-step chunks and executes 8 or 15 step chunks open loop. The FAST tokenizer was also validated on a high-frequency T-shirt folding dataset where naive per-dimension binning fails outright, and it lifted OpenVLA to workable performance on the same data.

Fine tuning it yourself

Fine-tune through openpi with the pi0_fast configs, using LeRobot-format data. FAST+ can be applied off the shelf to a new robot's one-second chunks, and the paper recommends quantile-normalising actions to [-1, 1] first. A dataset-specific FAST tokenizer can also be fitted in a few minutes if the universal one underperforms.

Where it helps, where it does not

Strengths

Trains roughly 5x cheaper in GPU hours than the diffusion π0 while reaching comparable evaluation performance, which matters when a full run costs thousands of GPU hours.
FAST+ is a black-box tokenizer usable on any robot's one-second action chunks without refitting, and it is released separately, so it can be dropped into other autoregressive VLAs.
π0-FAST-DROID is the released checkpoint that performs simple table-top manipulation zero shot in unseen environments from a natural-language prompt, with no calibration and no fine-tuning.
Same open Apache-2.0 openpi tooling and the same modest 8 GB inference footprint as π0.

Limits

Inference latency is the deal breaker for reactive control. Roughly 750 ms per action chunk on a 4090 versus under 100 ms for diffusion π0, because the model must autoregressively decode 30 to 60 action tokens.
The paper reports robot success rates only as bar charts, so there is no tabulated per-task number to quote or reproduce.
No results on LIBERO, SimplerEnv or any other public simulation benchmark in the paper.
Superseded inside the same repository. π0.5 keeps the FAST tokenizer for pre-training but switches back to a flow matching expert for inference precisely to avoid this latency.

Sources

Everything on this page was taken from these documents. Where they disagree with what you read here, they win.

Entry last checked 2026-08-11.

Try a policy on a real arm

A physical SO-100 is online and free to drive in the browser, and five of the models in this arena can be fine tuned on a dataset you record with your own.

Download the client Drive a real arm now