openpi hands-on: a 3B model on your bench

Where you are. You have fine-tuned a 450M model on your own data and learned to read a benchmark without being fooled by it. This lesson steps up a weight class, to the 3B checkpoints Physical Intelligence publishes, where the limit stops being your patience and becomes your graphics card.

A number, and the number just under it

Your card has 24 gigabytes of memory. That is the card most people doing this work actually own, and it is the number you will be doing arithmetic against for the rest of this module.

The repository you are about to clone publishes a table. The row you care about, the one for adapting a 3B model to your own robot, says: more than 22.5 gigabytes.

Do the subtraction. One and a half gigabytes. That is not a margin. That is the amount of memory a second browser tab uses.

Now read the row underneath it, the one for training the whole model rather than a small adapter on top of it: more than 70 gigabytes. There is no consumer card in that neighbourhood, and there will not be one soon.

Everything about working with frontier open models is downstream of those three numbers. Not the architecture, not the maths, not the prompt. Three numbers in a table, and which side of each one your hardware sits on.

The idea in one paragraph

openpi is Physical Intelligence’s public repository: real weights for the π₀ family, a documented way to fine-tune them, and nothing else. Using it is a plumbing exercise, and the plumbing has four decisions in it. Which checkpoint you start from, because base checkpoints and platform-specific fine-tunes are different products. Which memory regime you can afford, because inference, adapter fine-tuning and full fine-tuning sit at 8, 22.5 and 70 gigabytes and there is no negotiating. Which licence actually governs the weights, which is a different question from the licence on the code. And where the model physically runs, because a 3B model does not fit on the machine wired to your arm, so a network hop is going to end up inside your control loop whether you plan for it or not.

What is actually on the shelf

Three base checkpoints: pi0_base, pi0_fast_base and pi05_base. Then a set of fine-tuned ones whose names tell you their embodiment - two DROID variants, three ALOHA variants for towel folding, tupperware and pen uncapping, and π₀.₅ tuned for DROID and for the LIBERO simulation benchmark. They are hosted in a public bucket and cached under your home directory on first use, so the download happens once and then stops being a thing you think about.

Notice what is not in that list: an SO-101. Every fine-tuned checkpoint names a platform, and none of the platforms is the arm on your desk. Zero-shotting pi0.5-DROID at your own arm is worth doing exactly once, to watch what a confident wrong answer looks like, and then you fine-tune.

The runtime split is the other thing to check before planning a week around a checkpoint. PyTorch support arrived in September 2025 and covers π₀ and π₀.₅, validated on the LIBERO simulation benchmark. π₀-FAST is JAX only.

If your whole toolchain is PyTorch, those two lines silently remove a checkpoint and a fine-tuning mode from your options, and it is the kind of detail that costs a day when you find it at step four instead of step one.

And two models are not on the shelf at all. π*₀.₆, the version trained with reinforcement learning on the robot’s own corrected attempts, and π₀.₇, the steerable generalist from April 2026, both have papers and neither has weights. Everything either of them can do is something you read about.

The licence question you have to answer yourself

The repository carries Apache-2.0 for its code. That is a statement about the code.

Three memory regimes

Here is the table the hook was quoting, from the repository’s own documentation as of August 2026.

What a run costs

Owning the card makes the run free and slow. Renting makes it fast and cheap enough that the decision is usually not about money at all.

Those figures come from rental aggregators rather than provider pricing pages, they moved about 14% in a year, and they should be treated as plus or minus 30%. Price your own run at the provider before you quote a number to anyone.

The shape of the thing you build

A 3B model does not run on the machine wired to your arm. That single fact determines the architecture of every openpi deployment.

The model lives on a policy server, which is whatever machine has the big card. The robot host is a laptop or a small board with a USB cable running to the servos; it reads the cameras and the joint angles, sends them over, and receives back a chunk of future actions. π₀ predicts 50 of them at a time, which is what lets a model this heavy drive a control loop at all: you cross the network roughly once a second, not fifty times a second, and the host plays out the chunk it already has in between.

The consequence to internalise now: your control loop has a network in it. On a wired local network that is fine and mostly invisible. Across the public internet to a rented card it is a variable-latency link inside a real-time system, which is a bad place for one. The next lesson is entirely about that.

Check yourself

Do this

1. Plan the run before you clone anything. Save this and run it with your own numbers.

# Memory floors for a pi0.5-class checkpoint, from the openpi repository's own
# table, read 2026-08-09. Rental rates are US dollars per hour from aggregator
# listings the same month: treat them as plus or minus 30% and re-check.
MODES = [("inference", 8.0), ("LoRA fine-tune", 22.5), ("full fine-tune", 70.0)]
RATES = {"RTX 4090": 0.34, "A100 80GB": 1.30, "H100": 3.41}

def plan(vram_gb, hours):
    print(f"\na {vram_gb:g} GB card, for a {hours} h run:")
    for name, need in MODES:
        spare = vram_gb - need
        verdict = f"fits, {spare:.1f} GB spare" if spare > 0 else f"short by {-spare:.1f} GB"
        print(f"  {name:<15} needs > {need:>4} GB   {verdict}")
    for card, rate in RATES.items():
        print(f"  rent a {card:<10} ${rate:>4.2f}/h  ->  ${rate * hours:7.2f}")

plan(24, 10)     # the card you probably have
plan(80, 24)     # the card you would rent

It prints fits, 1.5 GB spare for LoRA on 24 GB and short by 46.0 GB for the full fine-tune. Swap in your actual card and your actual patience.

2. Do the reconnaissance, and date it. Open the repository and write four lines into notes/05-openpi.md, each with today’s date: the current list of base checkpoints; the licence text you actually found covering the weights, quoted, not summarised; whether your target checkpoint is supported in your framework; and the memory table as it reads today. If any of the four disagrees with this lesson, this lesson is the one that is out of date.

3. Commit to a plan in three lines. Which checkpoint you will start from and why. Which memory regime you will use, and on whose hardware. What the stop condition is - a success rate you would accept, or a number of hours after which you stop and go back to the smaller model. Writing the stop condition down before the first run is the difference between an experiment and a hobby.

What you can now do

You can plan an openpi run without guessing: name the checkpoints that exist and the two that only have papers, tell a code licence from a weights licence and know which one to read, place your own hardware against the 8, 22.5 and 70 gigabyte floors, price the rented alternative to within a factor you would defend, and draw the policy-server split that a 3B model forces on any robot small enough to sit on a desk.