pi 0.5 fine-tuning, measured: the hours, memory, and cost of a real 15,000-step run

An expert-only fine-tune of pi 0.5 was measured by this platform in October 2026. The run took 3.65 hours for 15,000 steps on one rented 24 GB card. It held 1.195 steps per second. It peaked at 13.75 GiB of memory. It cost 0.1497 at the run basis, 0.041 per card-hour. The official recipe is sized for an 80 GB card at batch 64. The reduced-memory variant fits the cheap card instead. It freezes the vision model and trains only the action expert. That trade costs some success rate. Nobody else publishes measured walls for this work. As of 2026-10-26 this platform offers no fine-tuning service. What follows is the measured record, the official requirements, and the dated market.

All amounts are United States dollars, written as bare numerals. The tables are static. No script is needed to check them.

Last verified: 2026-10-26

What it is

Pi 0.5 is a vision-language-action model from Physical Intelligence. The class has its own explainer. The paper went up on April 22, 2025. The weights went open in the openpi repo in September 2025. Camera images and a task sentence go in. Chunks of joint commands come out. The paper co-trains on web data, verbal instructions, and data from many robots. That co-training is why the model reaches rooms it never saw. The release is scoped. The repo carries the flow-matching action head for pi 0.5 training and inference. Other paper pieces, like subtask prediction, are not in the open code.

The model ships as a base meant for this exact work. The base checkpoint card says so plainly. Its stated use: "Base model to fine tune on your specific use case." Fine-tuning here means one loop. Record demos of your task in the LeRobot dataset format. Point a training command at them. Get back a checkpoint that drives your robot. The community does this at scale. On the Hub, the reference fine-tuned checkpoint showed 26,314 downloads on the day this page was verified, and the base showed 18,468. The Hub also carries more than a dozen community pi 0.5 tunes, with step counts in their names.

There are two official routes. Both start from the same weights.

The first is the publisher's own repo. It is JAX first. Its PyTorch path is validated on LIBERO for inference and fine-tuning. That path does not yet cover LoRA, mixed precision, or model sharding. The repo lists its own memory floors. Inference needs more than 8 GB. A LoRA fine-tune needs more than 22.5 GB. A full fine-tune needs more than 70 GB. The repo has been tested on Ubuntu 22.04 only.

The second is LeRobot, the Hugging Face robotics library. Its pi 0.5 recipe is the documented quickstart. One command installs, with the pi extras. One command trains. One command evaluates. The quickstart is sized for a single 80 GB card at batch 64 over 30,000 steps. The same docs ship the reduced-memory variant our run took. Their one-line trade: less memory, at some cost in success rate.

The posture on this platform, stated with its date. This platform does not currently offer a fine-tuning service for pi 0.5. As of 2026-10-26 there is no public listing for one. This page makes no promise that one is coming. The platform's own pi 0.5 route is a separate thing. Its page says so itself: the row exists in the platform's model data with its rate set, and it is not on the public list. Nothing answers under pi05 today. The models index is the live catalog. The VLA page holds the family.

Use cases

The reader who typed the query has a robot or a benchmark, plus a pile of demos. The real question is not whether the model can be tuned. It is what tuning costs in card, hours, data, and mistakes. Four decisions carry most of the money.

First decision: the data. A robotics integrator's February 2026 write-up quotes the publisher at 1 to 20 hours of demos for a task adaptation. The LeRobot team answered this directly in August 2026. About 50 episodes is a reasonable start for one simple task. Use 100 to 200 when objects and positions vary. The strongest dated quality findings come from a robotics company that published its test results in September 2026. One high-quality hour added to a 21-hour set lifted success from 76 to 90 percent. A 1.7-hour set built with human corrections beat the 21-hour model by 12 points. Five scenes instead of one, at the same collection time, added 30 points. Quality and diversity beat volume. Nobody's first instinct is to collect less data. The evidence says collect better data.

Second decision: the mode. It sets the card bill. The full recipe wants an 80 GB card. The expert-only variant fits 24 GB. In our run it gave up nothing the benchmark could see. The fine-tune it produced scored 96.4 percent on LIBERO. LoRA is the third option. The September 2026 study measured it 23 points below a full fine-tune, even at rank 256. Smaller policies below this class train on far cheaper cards. Above it, the 5B class refused our 24 GB card outright, in both training modes, at batch 1. Memory is the pricing boundary, not speed.

Third decision: where the hours come from. That is a table of today's public counters, read on the verification date, in the benchmarks section. The short version: the same measured wall costs 0.33 at the community tier and 9.13 on a premium managed card. That is a spread of about 28 times for identical work.

Fourth decision: who does the work. You can run the open recipe yourself, on your own card or a rented one. You can apply to the first-party Pi API beta, announced October 13, 2026. You upload data. They fine-tune on compute they manage. The result serves through their gateway. That door is a waitlist with no published price. You can go to a platform. One ships the full training pipeline but sells model training only in private deployments, by contact. Another lets you fine-tune several base models and compare them, behind a registration door with no pricing page. A third lists pi 0.5 serving by the hour and arranges fine-tune compute by call. One training platform does publish per-run prices: about 4 to 12 per run for this class on 80 GB cards, about 1 to 3 for smaller policies on 24 GB cards, dated on their own page. Every door was checked on October 26, 2026. Only one prints a number.

What none of the doors tell you: the run itself is the cheap part. The expensive parts are the ones the recipe never mentions. Checkpoints overflow the free storage tier mid-run. Pushing them somewhere safe doubles the wall. Both laws sit in the benchmarks section, with their numbers.

API usage

No fine-tune endpoint exists on this platform today. The open routes are command lines, not APIs. Three things in this section are real and usable now. One is the live-catalog check every posture sentence here rests on. One is the publisher's own serving client for a fine-tuned checkpoint. One is the official training command in the mode our run took. The platform's action route is the serving contract a fine-tuned policy would ride. It is written up in the action route guide.

curl

The catalog check is one request. Listing state is verified this way, not guessed, on this platform or any other.

curl -sS "https://api.ironstratum.com/v1/models" \
  -H "Authorization: Bearer $KEY"

The answer is the live list of model ids this platform lists. As of 2026-10-26, no fine-tuning service id is in it. No pi 0.5 id is in it either. Repeat the request later to learn whether that changed. You do not need to trust any page's date.

The action call, for any id that ever appears in that list, is a multipart POST. Its shape is fixed today:

curl -X POST "https://api.ironstratum.com/v1/action" \
  -H "Authorization: Bearer $KEY" \
  -F "model=<id exactly as the models index lists it>" \
  -F "instruction=put the red cube in the bowl" \
  -F 'state=[0.12, -0.80, 1.25, 0.40, -0.20, 0.90, 0.50]' \
  -F "image=@cam0.jpg" \
  -F "image=@cam1.jpg"

Sent today with an unlisted id, it answers 404 with the code model_not_found. That is the honest answer. The platform's own docs promise exactly that for ids that are not on the public list.

python

The serving path for a fine-tuned checkpoint is the publisher's own client, from the repo's remote inference guide. On the GPU machine, start the policy server with the repo's serve_policy script and your checkpoint directory. It listens on port 8000. On the robot machine, install the openpi-client package and speak to it:

from openpi_client import image_tools
from openpi_client import websocket_client_policy

# The server was started from the openpi repository with your
# fine-tuned checkpoint directory and listens on the GPU machine.
client = websocket_client_policy.WebsocketClientPolicy(
    host="gpu-box.local", port=8000
)

observation = {
    "observation/image": image_tools.convert_to_uint8(
        image_tools.resize_with_pad(img, 224, 224)
    ),
    "observation/wrist_image": image_tools.convert_to_uint8(
        image_tools.resize_with_pad(wrist_img, 224, 224)
    ),
    "observation/state": joint_positions,  # unnormalized; the
    # server applies the checkpoint's normalization statistics
    "prompt": "pick up the green cube",
}
action_chunk = client.infer(observation)["actions"]

This is the publisher's documented pattern. The observation keys, the 224-pixel resize, and the raw state all come from the official example. Your driver plays the returned chunk of actions at its control rate. Where the policy should live once it works, on the robot's own computer or against a rented card, is its own comparison. The quiet variable is the match between your arm's stats and the checkpoint's. The embodiment statistics guide covers it.

lerobot

This is the command our measured run took. It is the official recipe in the reduced-memory mode, on a 24 GB card. It is the LeRobot route that names this page's query.

lerobot-train \
    --dataset.repo_id=lerobot/libero \
    --policy.type=pi05 \
    --policy.pretrained_path=lerobot/pi05_libero_base \
    --policy.normalization_mapping='{"ACTION": "MEAN_STD", "STATE": "MEAN_STD", "VISUAL": "IDENTITY"}' \
    --policy.n_action_steps=10 \
    --policy.empty_cameras=1 \
    --policy.freeze_vision_encoder=true \
    --policy.train_expert_only=true \
    --policy.gradient_checkpointing=true \
    --policy.dtype=bfloat16 \
    --policy.device=cuda \
    --policy.push_to_hub=false \
    --batch_size=2 \
    --num_workers=8 \
    --steps=15000 \
    --save_freq=1000 \
    --seed=1000

Three laws from the official docs and the run record. Read them before the first attempt. First, the quantile law. Pi 0.5 normalizes state and action with quantiles by default. Your dataset's stats must carry q01 and q99, or the first batch throws the ValueError that names them. Older datasets need a stats recompute. Switching the mapping to mean and standard deviation is the other escape. Second, the checkpoint-loading law. pretrained_path loads weights only. n_action_steps falls back to 50 unless you set it. A rename map must never ride alongside pretrained_path. Third, the tokenizer gate. Accept the PaliGemma license on the Hub and log in before training, or the run dies at setup. Then evaluate the result with the library's eval command. Read the benchmark section before trusting a single score.

Benchmarks

This section is the spine. Every wall, rate, and verdict below comes from this platform's dated run record, October 2026. The rig: rented RTX 3090-class cards with 24 GB of memory, 10 vCPUs, 32 GB of RAM, LeRobot pinned at 0.6.1. Every wall is a recorded job, not an estimate.

The run climbed a three-step ladder of robot policies. The verdict rule comes first. A fine-tune clears only when its measured cost sits at or below one fifth of its charge band's midpoint.

Three properties of the middle row, the one this page exists for. Its basis is a below-list batch rate, 0.041 per card-hour at a community cloud. That is a named program at a named cloud, not a checkout price. Its verdict margin is wide: 1.8 percent of its line. Its mode is the budget decision. The same model at its official batch and full recipe rents the 80 GB tier. A published per-run price of 4 to 12 sits there today.

The same measured wall, bought at every public counter read on the verification date:

Rates: the community cloud's own pricing page, the RunPod pricing page, and the Hugging Face card table. Each was read on 2026-10-26. Read the vCPU column before the price column on the managed rows. The Hugging Face A10G small card ships with 4 vCPUs and 15 GB of RAM. A fine-tune that stalls on data loading behind a thin CPU slice pays the same rate for a longer wall.

Then the two laws the recipe never mentions. Both were measured on the middle rung. The storage law: a 15,000-step run that saves every 1,000 steps makes 15 checkpoints. Each is about 11.55 GB. Together, about 173 GB. The free private tier on the Hub holds 100 GB, per their storage limits document. One such run overflows it by itself. The measured record hit that wall five times at the same checkpoint boundary. The final model push, about 3.4 GB, hit the same quota four times after training was done, at about 117 minutes of re-run each time. Deleted files free quota only after about a day and a half. Every fix costs something. Keep checkpoints on the machine and push only the final model. Push to public storage where policy allows. Or buy the paid tier: its 1 TB holds about 86 checkpoint sets of this size. Choose before the run, not during it.

The push law: sending each checkpoint to the Hub as insurance took 12 to 17 minutes per interval. Training an interval took about 12 minutes. Saved-everywhere roughly doubles the wall of this rung. Space the saves out and a crash costs more work. Push everything and the wall doubles. No setting removes the choice. Interruptions were measured too. Work lost is at most one save interval. A machine restart costs about 80 minutes cold, or 16.3 minutes warm. A cold re-run without the chunked design costs about half again as much wall.

The proof that the cheap mode still tunes well is the report the fine-tune earned. The same checkpoint was evaluated on LIBERO, 500 episodes across four suites:

That evaluation has its own full page, the 1.93 per 500-episode report. The product-level math of train plus report, 2.08 at this basis against a written charge band, is its own guide. The numbers there agree with this page exactly. A 40-episode quick check ran first, at 3.863 hours and 0.1584. That order is the low-cost mistake-catcher in the whole loop.

Third-party anchors, each with its owner and date. The LeRobot implementation of pi 0.5 scores 97.5 percent average on LIBERO. The reference implementation scores 96.85. Both numbers are in the official docs. The library route gives up nothing at the benchmark level. The September 2026 study named above is the success-rate companion to this cost record. Its findings on data quality, LoRA's gap, and serving settings all move success rates. None of them carries a price tag anywhere but here. A February 2026 builder write-up adapted the base model to a custom task and embodiment. It used about 400 episodes, or 10 hours of data, on standard cloud training rentals.

One honesty note to close the section. No LIBERO score predicts your robot. The benchmark's own docs warn that scores move a few points across evaluation seeds. The LIBERO page covers the suites and the studies that stress them. The 96.4 says the mode works at the benchmark level. Before a purchase decision, spend a slice of the same budget on a small, counted evaluation. It should look like your tables, your cameras, and your parts.

Getting started

1. Read the primary sources. The openpi repo, the LeRobot pi05 recipe, the base checkpoint card, and the Pi API beta post are all public. Every identity fact on this page traces to one of them.
2. Collect less data than you planned, better than you planned. Fifty episodes to start, quality over volume, variety over repetition, corrections when you can get them.
3. Pick the mode before the card. Expert-only on 24 GB is the measured cheap path. The full recipe rents the 80 GB tier. LoRA buys memory with success points.
4. Budget the hidden lines. Storage before the first checkpoint. Save frequency before the first push. A quick check before the long evaluation.
5. On this platform, watch the live list. Create an account on the signup page and make an API key. Then check the models index with the one-line call from the curl tab, on any date, without trusting this page's date. The action route is written up in the action route guide; what listed lanes cost sits on the pricing page. The model family lives on the VLA page. If a fine-tuning or serving id for this class ever appears in that list, the question on this page stops being what the work takes and becomes what a call costs, and the answer will be a published rate, not a blog post.