Dedicated Container Inference

Your checkpoint. Our plumbing.

Every policy that touches a real arm has been fine-tuned on somebody's own demonstrations — a generalist that needs no adaptation does not exist yet. So the interesting checkpoint is usually yours. Bring it, and it answers on the same endpoint, with the same request body, as everything in the catalogue.

What changes, and what does not

Your client code

unchanged

Only the model string moves, from accounts/sequences/… to accounts/<you>/…. Same body, same response, same metering.

Isolation

1 tenant

A container per deployment, on hardware nobody else is scheduled onto. The serverless pool multiplexes; this does not.

Billing unit

GPU-hour

Tokens are a proxy for GPU time on shared capacity. When the capacity is yours, the proxy is dropped and you pay for the hour.

Declaring an embodiment

A policy is not just weights. It is weights plus a contract: how many cameras, which views, how wide the state vector, how many steps come back and how fast they are meant to run. Get one of those wrong and the arm moves the wrong joint — so the contract is declared, not inferred.

deployment.tomldeclared, not guessed

# The checkpoint
weights      = "s3://your-bucket/pi05-kitchen-v4"
base         = "pi05"          # which adapter speaks its protocol

# The embodiment contract — every field is load-bearing
[embodiment]
robot           = "franka_fr3"
camera_views    = ["exterior_1", "wrist_left"]
state_dim       = 8
action_dim      = 32
action_horizon  = 15            # steps returned per call
control_hz      = 15.0          # → chunk covers 1.00 s
action_space    = "joint_absolute"
context_frames  = 1             # 17 or 33 for a world model

[hardware]
accelerator  = "H100_80GB"
min_replicas = 0               # scale to zero between shifts
max_replicas = 4

Dimensions are checked, not trusted. A chunk whose width disagrees with the declared action_dim is rejected before it reaches your controller. We have already been bitten by two configuration names differing by one field — pi05_droid returns 15 steps and pi05_full_droid_finetune returns 16 — and nothing about that mistake announces itself at runtime.

API or dedicated

	Inference API	Dedicated container
Models	The ten in the catalogue	Yours, plus any of the ten
Billing	Per token, per architecture tier	Per GPU-hour
Cold start	None — pool is warm	Scale-to-zero costs a load
Neighbours	Shared pool	None
Best when	You are still choosing a policy	You have your own demonstrations
Breaks even	Under steady load, roughly a third of a GPU	Above it

The honest version: start on the API while the question is which policy, move to dedicated once the question is how well does mine do. Nothing in your code changes at the boundary, which is the point of keeping one request shape.