VLA Training Cost: What a Fine-Tuning Run Really Costs

The bill has four lines, and the GPU is the smallest one

When people ask what it costs to fine-tune a vision-language-action model for an SO-100, they almost always mean the GPU rental. That is the number that shows up as a charge on a card, so it is the one that feels real. It is also, by a wide margin, the smallest of the four numbers that decide what a working policy actually costs you.

Training times below come from the five models' own papers and repositories, hardware cost from the published bill of materials, platform numbers from the AY-Robots policy catalog and pricing page. Where the platform does not help, this article says so.

What a GPU hour actually costs on the spot market

There is no single price for an A100 hour. On a marketplace like vast.ai every host sets its own rate, and the training run you launch lands on whichever machine is cheap and free at that second. The honest answer is a distribution. Here it is, measured 23 August 2026 at 13:44 UTC: single full cards, on demand, filtered by real VRAM.

# Live, full-card, single-GPU, on-demand offers from the vast.ai public bundle API.
# No account and no API key needed. gpu_ram is in MB, so an 80 GB card is >= 80000.
python3 - <<'PY'
import json, statistics, urllib.parse, urllib.request

def offers(name, min_ram):
    q = {"rentable": {"eq": True}, "num_gpus": {"eq": 1}, "gpu_name": {"eq": name},
         "order": [["dph_total", "asc"]], "limit": 500, "type": "on-demand"}
    url = "https://console.vast.ai/api/v0/bundles/?q=" + urllib.parse.quote(json.dumps(q))
    with urllib.request.urlopen(url, timeout=60) as r:
        return [o for o in json.load(r)["offers"]
                if o["gpu_frac"] == 1.0 and o["gpu_ram"] >= min_ram]

groups = {
    "RTX 4090 24 GB": (["RTX 4090"], 24000),
    "RTX 5090 32 GB": (["RTX 5090"], 30000),
    "A100 80 GB":     (["A100 PCIE", "A100 SXM4"], 80000),
    "H100 80 GB":     (["H100 SXM", "H100 PCIE"], 80000),
    "H100 NVL 94 GB": (["H100 NVL"], 90000),
}
for label, (names, min_ram) in groups.items():
    o = [x for n in names for x in offers(n, min_ram)]
    if not o:
        print(label, "no offers"); continue
    p = sorted(x["dph_total"] for x in o)
    b = sorted(x["min_bid"] for x in o if x.get("min_bid"))
    bid = f"{b[0]:.2f}" if b else "n/a"
    print(f'{label}: n={len(p)} | {p[0]:.2f} / {statistics.median(p):.2f} / {p[-1]:.2f}'
          f' USD/h | bid floor {bid}')
PY

Why the 3B models cannot use the cheap card

A 4090 hour and an H100 80 GB hour differ by roughly six times at the medians above. What forces you onto the expensive card is not speed, it is memory. openpi puts the floor for a full Pi0.5 fine-tune at 70 GB, and NVIDIA recommends 40 GB or more for GR00T. Note what the GR00T number is not. Its fine-tune config freezes the language model and the visual encoder by default (tune_llm and tune_visual are False, the projector and the diffusion head True), which is why the catalog lists roughly 40 M trained parameters out of 3 B. The 40 GB is not optimizer state for 3 B weights, it is the frozen backbone plus activations. Reduced-scope variants drop lower: openpi's LoRA path wants 22.5 GB and names the 4090, and NVIDIA's Isaac Lab Arena workflow lists a 24 GB single-GPU option for GR00T post-training. The platform tiers on the floor each vendor publishes for the configuration it actually runs. The pi0 flow-matching write-up explains where that flow-matching footprint comes from.

That table is why the platform splits the five models into two tiers. GR00T N1.7, GR00T N1.5 and Pi0.5 go on A100 80 GB or H100 because that is what the vendors ask for. SmolVLA and ACT go on an RTX 4090 or any 24 GB card because that is genuinely enough.

How long each of the five models actually runs

Run time is the other half of the cost: 2.00 USD per hour is irrelevant if the job is 40 minutes and ruinous if it is 40 hours. These are the defaults AY-Robots really sends to the trainer, with the run window and cost for each tier.

Where those run windows come from upstream

• SmolVLA: the lerobot documentation states that 20,000 steps takes roughly 4 hours on a single A100. The platform runs the same 20,000 steps on the cheaper 24 GB tier, hence a window rather than a flat 4 hours.
• ACT: the original ALOHA paper reports around 5 hours on a single 11 GB RTX 2080 Ti for an 80M-parameter model. A 4090 is several generations newer but the platform budgets 100,000 steps, so the window lands in the same place.
• GR00T: NVIDIA's reference workflow for the N1.6 generation quotes roughly 4 to 8 hours for 20,000 steps at batch 24 on eight L40S cards, and 2 to 3 hours for 30,000 steps at batch 16 on a single Ada 6000. Single-card fine-tuning of a 3B VLA in a few hours is normal, not optimistic.
• Pi0.5: openpi publishes no wall-clock figure, but it does publish the 70 GB floor for a full fine-tune, which pins the card and therefore the rate.

Worth pausing on the number you are not paying. The GR00T N1 paper reports roughly 50,000 H100 GPU hours to pretrain the 2.2B model, on a cluster of up to 1024 GPUs, at a pretraining batch size of 16,384 for 200,000 gradient steps. At the 1.34 to 2.34 USD per hour measured above that is on the order of 67,000 to 117,000 USD of rented compute. The SmolVLA paper puts its project at approximately 30,000 GPU hours over 481 community datasets, 22.9K episodes and 10.6M frames. You inherit all of it for the price of a download; your 8 USD buys the last 20,000 steps. Why VLAs are built this way covers that split.

The arm: a one-time cost that dwarfs the GPU bill

A training run costs less than lunch. The robot does not. That is why the SO-100 matters: it is the cheapest arm the whole imitation learning toolchain actually supports.

The upstream bill of materials in the SO-ARM100 repository is more granular and worth checking against your region: its Parts For Two Arms list totals 229.88 USD or 226.30 EUR for a leader plus follower setup, and its Parts for One Follower Arm list totals 121.94 USD or 124.30 EUR. Six STS3215 servos at 13.89 USD each are 83.34 of that 121.94, so the servos are the arm. At 1 to 3 USD per SmolVLA or ACT run, one pair of arms is worth between 77 and 230 training runs. If you are still choosing, SO-100 against SO-101 is the comparison that matters, because the two are close enough that the decision is about availability rather than capability.

Human hours: the line nobody puts in the spreadsheet

This is the number that turns the cost discussion upside down. Recording demonstrations is a person moving a robot arm, one episode at a time, in real time. There is no batching it and no renting it by the second. The LeRobot dataset recorder ships with defaults that make the arithmetic easy, all three confirmed in DatasetRecordConfig: 60 seconds per episode, 60 seconds to reset the scene, 50 episodes. The money column below assumes 15 USD for an hour of someone's time, which is an assumption rather than a platform number. Substitute your own rate; the ratio is the point.

1. 1
   Record the dataset with the defaults you will actually be billed for

   This is lerobot 0.6.1, the version on PyPI as of 3 August 2026. Note the CLI shape: recording runs through the lerobot-record console entry point (lerobot.scripts.lerobot_record), not the old python -m lerobot.scripts.record module path. AY-Robots targets 0.5.1, and the 0.5.1 wheel declares the same lerobot-record and lerobot-train entry points, so the shape below is stable across both. The three timing flags are the upstream defaults, so this is also the command the arithmetic in the next table assumes.

   bash

   lerobot-record \
       --robot.type=so100_follower \
       --robot.port=/dev/ttyACM0 \
       --robot.id=my_follower_arm \
       --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
       --teleop.type=so100_leader \
       --teleop.port=/dev/ttyACM1 \
       --teleop.id=my_leader_arm \
       --dataset.repo_id=${HF_USER}/pick-place-cube \
       --dataset.num_episodes=50 \
       --dataset.episode_time_s=60 \
       --dataset.reset_time_s=60 \
       --dataset.single_task="Grab the black cube and put it in the bin"

2. 2
   Look at what you recorded before you rent a single GPU minute

   Inspecting a dataset costs zero USD per hour. Discovering the same problem from a loss curve costs 2.00 USD per hour on the H100 tier and tells you four hours late. Push the dataset and scrub it in the LeRobot viewer, or browse the AY-Robots dataset directory.

   bash

   # the recorder pushes to the Hub by default; disable with --dataset.push_to_hub=False
   echo https://huggingface.co/datasets/${HF_USER}/pick-place-cube
   
   # then open https://huggingface.co/spaces/lerobot/visualize_dataset
   # and scrub through episodes: are both camera streams alive on every episode?
   # is the gripper actually closing? does the arm sit at a joint limit?

3. 3
   Train, and make sure the checkpoint outlives the pod

   A rented machine is temporary by definition, so write checkpoints somewhere durable during the run. Two flags decide whether you keep what you paid for. --save_freq defaults to 20,000 steps, so a default 20,000-step SmolVLA run writes its first checkpoint when the run is already over; lower it before you rent anything interruptible. --save_checkpoint_to_hub requires --policy.repo_id and does not exist in lerobot 0.5.1, so on that version you copy the output directory off the machine yourself. The batch size below is the upstream doc's example; the AY-Robots form sends 2 for SmolVLA and writes to object storage as checkpoints appear.

   bash

   lerobot-train \
       --policy.path=lerobot/smolvla_base \
       --dataset.repo_id=${HF_USER}/pick-place-cube \
       --batch_size=64 \
       --steps=20000 \
       --save_freq=2000 \
       --output_dir=outputs/train/my_smolvla \
       --job_name=my_smolvla_training \
       --policy.device=cuda \
       --policy.repo_id=${HF_USER}/my_smolvla \
       --save_checkpoint_to_hub=true

Compare the right-hand column with the 1 to 12 USD the run costs. At that assumed rate, a 50-episode dataset costs two to seven times as much to record as it costs to train on, before calibration, camera setup and the episodes you throw away. That is why getting the data right the first time has a direct dollar value. The lerobot guide suggests at least 50 episodes with 10 per object location; the SmolVLA docs report that a 25-episode version of the same task was not enough.

Where the money actually goes missing

1. Runs on data that was never going to work

A 20,000-step GR00T run on a dataset with two swapped camera streams costs the same as one on a clean dataset, takes the same time, and produces a loss curve that looks fine. The failure shows up on the arm, hours later. Training steps are billed by the hour and diagnosis is billed in days. Two symptoms worth memorising: the loss falls but the policy does nothing usually means the observations do not carry what the task needs, and the policy only works in one setup means the dataset had less variation than you thought.

2. Paying foundation-model prices for a fixed-camera task

ACT is roughly 80M parameters and was designed to train from scratch on 50 demonstrations of one task. GR00T N1.7 is roughly 3B with a pretrained backbone. For a bolted-down camera, a fixed table and one object, the 80M model frequently gets there, runs at about 20 ms per action step instead of 152 ms, and costs 1 to 3 USD per run instead of 4 to 12. Spend 3 USD finding out whether the cheap model works before spending 12 USD on the expensive one. ACT against SmolVLA and GR00T N1.7 against Pi0.5 show where each stops being the right answer; the model arena has 85 models and 332 benchmark results.

3. The GPU you forgot about

The cheapest mistake to prevent and the most common one to make. An instance started on a Friday to debug something bills through the weekend at the same rate as a real run.

On AY-Robots this failure is designed out for inference: pods provisioned by the inference API carry an idle watchdog and destroy themselves after an idle period. If you rent the card yourself, that watchdog is your calendar reminder.

4. Paying twice for the same answer

GR00T's fine-tuning entry point is a tyro CLI that exposes no seed. That is not a platform limitation, it is the upstream tool: there is no seed field in gr00t/configs/finetune_config.py, and the repository's own training tips warn that runs vary by 5 to 6 percent because the image augmentations are non-deterministic. lerobot defaults to seed 1000 in both 0.5.1 and 0.6.1, so ACT, SmolVLA and Pi0.5 runs can at least be rerun from the same initialization and data order. That is not a promise of bit-identical weights on a GPU, but it is the difference between a rerun and a new experiment. If a GR00T run produces a policy that works and you did not keep the checkpoint, you pay full price for a result that may differ by more than the difference you were chasing. There is a second way to lose a checkpoint you paid for: the CLI defaults to --save-total-limit 5, documented as the maximum number of checkpoints kept before older ones are deleted. Storage is cents; a rerun is 4 to 12 USD and six hours.

Doing it yourself versus letting the platform rent the card

# GR00T N1.7, single GPU, Isaac-GR00T as of August 2026.
# Note the entry point: gr00t/experiment/launch_finetune.py, a tyro CLI.
# scripts/gr00t_finetune.py does not exist in this repository; tutorials that
# still reference it are stale. The per-embodiment walkthrough is
# getting_started/finetune_new_embodiment.md.
CUDA_VISIBLE_DEVICES=0 uv run python gr00t/experiment/launch_finetune.py \
    --base-model-path nvidia/GR00T-N1.7-3B \
    --dataset-path demo_data/cube_to_bowl_5 \
    --embodiment-tag NEW_EMBODIMENT \
    --modality-config-path examples/SO100/so100_config.py \
    --num-gpus 1 \
    --output-dir ./so100-checkpoints \
    --max-steps 20000 \
    --global-batch-size 32 \
    --dataloader-num-workers 4

# v3.0 dataset? Convert it down first or the loader will crash. The helper
# has its own pyproject and must be installed in its own environment:
cd scripts/lerobot_conversion
uv venv && source .venv/bin/activate
uv pip install -e .
python convert_v3_to_v2.py --repo-id <DATASET_REPO_ID>

What the platform charges and how it picks the card

The logic is deliberately boring. Every model in the catalog declares a GPU tier; the backend takes the required VRAM and rents a matching card on the same spot market measured above. That is why the quoted cost is a range, not a price. GR00T and Pi0.5 are cloud-only here because of the 40 GB and 70 GB floors. SmolVLA and ACT also run locally on your own 24 GB card, where the cloud cost is zero and the electricity is your problem.

One knob deserves a warning. Gradient accumulation genuinely applies for both GR00T variants, so raising it buys a larger effective batch on the same card. For Pi0.5 and SmolVLA it does not apply at all: lerobot 0.5.1 has no gradient-accumulation option in its training config, so setting the field to 16 costs nothing and buys nothing. If a queued job never starts, the stuck-in-queue page covers what to check; if the dataset is rejected before the run begins, it is almost always the v3.0 format problem.

A worked budget for a first working policy

All four lines together, starting from nothing. The GPU total assumes 3 to 5 runs: the first proves the pipeline works, the second exposes a data problem, the third or fourth is the one you keep.

The pattern holds at this size of robot: compute is a rounding error, hardware is a real one-time cost, human hours are the recurring expense. To test the training half before buying anything, the no-hardware entry points let you compare models and rent a GPU without an arm, and the live arm is a physical SO-100 you can drive in the browser with no signup. For the whole pipeline end to end, the complete SO-100 guide covers setup, teleoperation and training, and train your first policy is the short version.