Modal for robotics: running pi-family models on a serverless GPU platform

Yes, you can run pi-family robot policies on Modal. Physical Intelligence, the lab behind pi 0 and pi 0.5, ran real-time remote inference for robot control on Modal itself, and its published setup added only 10 to 15 milliseconds of network overhead. But know what you are walking into. Modal is a generic serverless GPU platform. It bills by the second, you bring the container, and its own documentation carries no robotics example at all. The recipe is real and this page assembles it, with every rate and limit dated October 27 2026.

Last verified: 2026-10-27. All amounts on this page are US dollar amounts. Every rate carries its source and its read date, because serverless GPU pricing moves.

What Modal is, and what the name collides with

Modal, at modal.com, runs your Python code in containers on cloud GPUs. You decorate a function with gpu="H100", Modal builds the container, starts it when called, and stops it when idle. You do not manage a machine, a cluster, or a docker daemon. The meter is per second of compute time, and a container that scales to zero costs nothing while it is down. That is the whole platform pitch, and for burst work it works.

The name collides badly in search results. Modal fabric is a textile, and textile pages own big chunks of these queries. Bootstrap has a modal dialog component, which owns more. ModalAI makes drone companion computers, which is a third company with the word in its name. Robotics papers say multimodal and match too. So the results for modal robotics gpu look strange, and a searcher with a robot arm gets fabric care guides. This page is about modal.com only.

The proof: Physical Intelligence ran its robot loop on Modal

The anchor evidence is a customer story Modal published on April 8 2026, read in full on October 27 2026. It is the strongest proof this lane has, because it is the model's own maker.

The facts, as the post states them. Pi trains its models in the cloud, then usually downloads them to run on GPUs on board each robot. For robots without an on-board GPU, Pi runs the policy remotely instead. Every arm movement flows through a closed loop of continuous inference, and Pi validates every model revision on real robots, around the clock.

The transport is the interesting part. Modal's standard low-latency path is a tunnel, a live TCP port exposed from a running container. Pi skipped it for the control loop. TCP can stall a request stream, and even small jitter degrades robot behavior. So Pi worked with Modal on a different transport: a QUIC channel over UDP, with NAT traversal through STUN and UDP hole punching, and the rendezvous handled by Modal's own dict store. The robot connects once, then streams observations in and receives actions back on the same channel.

The measured result, in the post's own words, is that the cloud only added roughly 10 to 15 milliseconds of network overhead. That number is why this lane is real. A policy that tolerates a network hop can live off the robot.

Three more facts from the same post. Pi runs larger data-center GPUs on Modal than fit on the robot. Checkpoints sit in Modal Volumes and load in under 30 seconds. And the deployments are pinned to regions close to the robots, so a new site means a new container near it, with the same checkpoints, and no hardware shipped.

Modal's own docs carry no robotics recipe, verified

Here is the honest other half. Modal's documentation index, the page at modal.com/llms.txt that lists every docs page, was read in full on October 27 2026. It carries no robotics example, no VLA example, and no pi model guide. The closest entries are a WebRTC camera demo with a YOLO detector and a webcam quickstart. Its product pages describe inference work for text, image, video, and audio. The customer story above is a blog post, not documentation.

One recent launch comes close to the loop problem. On June 25 2026 Modal shipped a new "Servers" primitive for ultra-low-latency HTTP, WebSocket, and gRPC traffic. The launch post reports cutting median proxy latency from 39 milliseconds to 6 milliseconds versus the older web function path. The same post even names driving a robot over UDP hole punching as a thing you can do. So the platform keeps building toward this shape. What it does not ship is the robot part. You bring the container, the weights, and the server. Nobody at Modal hands you a policy endpoint.

The recipe: openpi on Modal in five moves

The model side is already built for you. The openpi repository from Physical Intelligence ships a remote inference design, in its own docs, read October 27 2026. One command starts a policy server that listens on a websocket at port 8000. A small client package connects from the robot, sends images and joint state, and receives an action chunk back. The images get resized to 224 by 224 on the robot side to keep the channel light. You call the policy every few steps and run the chunk open loop between calls. The full model record for pi 0.5, with benchmarks and checkpoints, is on its model page.

Here is the whole lane in five moves.

One, pick the GPU. The openpi memory table sets the floors. Inference needs more than 8 GB, a LoRA tune more than 22.5 GB, and a full tune more than 70 GB. On Modal that maps cleanly. The A10 tier gives 24 GB, enough for serving. Modal's own GPU guide suggests the L40S at 48 GB as the starting card for running models, which covers serving plus a LoRA tune. The full tune wants the 80 GB class, an A100-80GB, an H100, or an H200 with 141 GB, and you can request up to eight of those in one container.

Two, put the weights in a Volume. Modal's model weights guide recommends a Volume, a shared disk your containers mount. Download the checkpoint from Hugging Face once, into the Volume, and load it in the container's enter hook so it runs once per container. This is the same pattern Pi used to get checkpoint loads under 30 seconds.

Three, wrap the policy server. Your container image needs the openpi dependencies. One decorator on the server class sets the GPU. The openpi server itself does not change.

Four, expose it. Two roads. A tunnel, with modal.forward(8000), gives you a public TCP address with TLS and no extra charge, which Modal's docs call its fastest direct connection. Or the newer Servers class with a warm floor of containers. A community project packages both roads. The openpi-flash repository, last updated July 29 2026, is a real-time serving engine for openpi that deploys to Modal with one command. Its tunnel mode runs openpi's native websocket server over a direct TCP tunnel. Its QUIC portal mode mirrors the Pi transport, over UDP with hole punching, and the repo itself labels that mode experimental. For one user, the project reports cutting a round trip from about 4,000 milliseconds to about 200 milliseconds against the stock server. Treat that as their claim, not a promise.

Five, fine-tune in bursts. The modal_training recipe in the awesome-lerobot collection, dated July 2025, exists because a local 24 GB card hits out-of-memory errors on pi0 even at a batch size of one. Its fix is one command that runs LeRobot training on Modal with an H100 or an A100. The guide's own estimates put a short test run under 1 and a 100,000-step pi0 tune around 50 on an H100. Its best advice is to debug locally first, because a serverless container gives you no SSH to poke at. Some Hugging Face checkpoints you find in these searches, like the ones named modal_pi0_test, are outputs of this exact recipe. That is why model cards surface where guides should be.

What a loop costs at per-second rates

The rates below are Modal's own, read from the pricing page on October 27 2026. The per-hour column is the per-second rate times 3,600. Modal prints the same figure itself for the H100 class in its own comparison example, so the derivation checks out.

Around the table: storage in a Volume runs 0.09 per GiB per month with the first TiB free each month. Network egress runs 0.04 per GiB. The entry plan costs nothing per month and includes 30 per month in free compute credits, with ten GPUs allowed at once.

Now the loop shape. A control loop needs the container warm for the whole session, so the honest unit is the warm hour, not the call:

warm session cost  =  R x T / 3600
cold boot waste    =  L x R / 3600, paid at every start from zero

R: hourly rate for your GPU, from the table above
T: seconds your robot session runs, warm the whole way
L: seconds of model load at each cold boot

Four rules from Modal's own billing and cold start docs shape that math. A container stays alive 60 seconds after its last input by default, and that idle time is billed. You can set the idle window from 2 seconds to 20 minutes. A floor of warm containers removes cold boots entirely, but then the GPU bills around the clock, even at 3 a.m. with the robot parked. And pinning your container to a region near the robot, which is the whole point of the lane, multiplies the base price by 1.15 for a broad region or 1.75 for a narrow one.

One sensitivity line, so the shape is concrete. At the L40S rate, a warm four-hour lab session costs about 7.8 before any region multiplier, plus about 0.011 for each 20-second model load. Per-second billing is a burst tool. A robot that runs all day is not a burst.

The limits that bite a control loop

Preemption, first. Modal's preemption guide says all functions there can be interrupted, and the flag that opts out of preemption is not offered for GPU functions at all. So a cloud policy loop can always drop. Your client needs reconnect logic, and the openpi-flash project's own label on its QUIC mode, experimental, is the honest read of maturity here.

Warm-up, second. The container itself boots in about one second. The model load is the slow part. Weights in the tens of gigabytes can take minutes to load at a cold boot unless they sit in a Volume or the image, per the cold start guide. Pi's team got this under 30 seconds. Plan for the first call after a cold spell to be slow.

Rejections at zero, third. The Servers primitive rejects requests with a 503 when no container is up, by design, and pushes retry duty onto your client. A robot loop that hits a scale-to-zero gap gets errors, not queueing.

Timeouts, fourth. A function run gets 300 seconds by default, and you can raise that to 24 hours. Long sessions are fine. A permanent resident process is not the shape of the thing.

No SSH, fifth. Debugging happens through logs and repeat runs. Debug the training script locally on a small model, then send the big run up. That is the community recipe's advice and it is correct.

Which lane for which job

The hosted row deserves its own words. This platform keeps a written record for the pi 0.5 family on its action route, one row each for pi05, pi05-droid, and pi05-libero, the base and the two public checkpoint tunes. The record's facts as of October 27 2026: the rows sit in the platform's model data, metering is per call, and the models are not on the public list. The models index is the live catalog, and reading it beats trusting any page's date, including this one. Open-weights economics for that family, and the waitlist for the maker's own API, each have their own guides, linked below.

Budgeting a per-call lane is one multiplication, and the unit conversion lives in its own guide: calls per robot hour follow from your chunk length and loop rate. The pricing units guide works both directions. For the measured cost side, what an hour of robot work costs on real cards, read the cost per robot hour report. Every path for pi 0.5 specifically is in the pi 0.5 pricing guide, and the maker's own beta is covered in the waitlist walkthrough. On the wider question of which big hosts serve robot models at all, the big hosts guide is the census, and the Replicate robotics page is the neighboring intercept. If the loop should live next to the robot, the Jetson versus cloud guide and the VLA break-even guide carry that trade.

Compare every option on the pricing page, and sign up to budget metered calls with a prepaid balance as the hard stop.

Check it yourself in two minutes

Every claim here decays. Re-date the three big ones yourself. Open the pricing page and read the GPU table, then check whether the rates on this page still match. Then open the docs index and search it for robot, to see whether a robotics example has appeared. Open the Pi customer story and see if the transport story changed. Three pages, two minutes, and this page is either current or visibly stale.

Frequently asked questions

Can you run pi 0 or pi 0.5 on Modal?

Yes. The openpi repository ships the serving side, a websocket policy server on port 8000 with a small robot-side client, and Modal runs it in a GPU container with the weights in a Volume. Physical Intelligence itself ran real-time remote robot control on Modal, with 10 to 15 milliseconds of added network overhead, per Modal's own April 2026 customer story. What Modal does not provide is a hosted pi endpoint. You build and run the container.

Does Modal host robot models the way it hosts LLM examples?

No. Its docs index, read October 27 2026, carries no robotics or VLA example. The examples that exist are text, image, audio, and protein work. The robotics lane on Modal is bring-your-own-container by nature, which is the opposite of a model zoo. For the zoo question on other platforms, the big hosts guide has the census.

What does it cost to run a VLA on Modal?

The meter is per second, and a loop needs a warm container, so think in warm hours. At the rates read October 27 2026, the L40S that Modal recommends for serving runs 1.95 per warm hour, and the 80 GB class runs 2.50 to 3.95, before the 1.15 to 1.75 region multiplier. A floor of warm containers bills around the clock. Storage is the small line item by comparison: 0.09 per GiB per month with the first TiB free. The community fine-tuning guide estimates under 1 for a short test run and around 50 for a 100,000-step pi0 tune on an H100.

Is Modal good for robotics?

For two job shapes, yes: fine-tuning bursts and batch evaluation, where per-second billing and scale-to-zero fit the work. For a production control loop, three facts cut against it. GPU functions there can always be preempted, with no opt-out for GPUs. Cold boots pay the model-load seconds again. And the region pinning that keeps latency low multiplies the price. A tolerant lab loop works, and has worked for the model's own maker. A floor of robots that must never drop wants the GPU on board or a hosted action API.

What GPU should I pick for pi 0.5 on Modal?

Follow the memory floors from the openpi repo. Serving needs more than 8 GB, so the 24 GB A10 tier is the smallest tier that serves. The L40S at 48 GB is Modal's own suggestion for running models and gives headroom for a LoRA tune, which needs more than 22.5 GB. A full tune needs more than 70 GB, so take the A100-80GB, H100, or H200 class, and you can attach up to eight of them to one container for the big runs.

Last verified: 2026-10-27