LeRobot 0.7 Remote Inference: Migrate From async_inference Without Guessing

LeRobot 0.7.0 removes lerobot.async_inference and the async installation extra. To migrate, install the remote extra, run your checkpoint through lerobot-policy-server, and connect with lerobot-rollout using the remote backend. An old import failing after the upgrade can therefore be an expected breaking change rather than a broken environment.

The November 5 release moves model computation onto a GPU server while cameras, motor control, teleoperation and recording stay on the robot computer. That makes a lighter local machine possible, but introduces a network and timing problem that a successful model download cannot resolve.

I would treat this as a deployment migration, with a known working task as the reference. Changing the policy, camera setup and inference architecture together makes it unnecessarily difficult to explain a regression.

Check the checkpoint before rewriting the command

The implementation's support table separates software compatibility from real checkpoint execution and hardware evidence. ACT, SmolVLA, XVLA, LaWAM and EVO1 have documented remote hardware examples. ACT requires temporal ensembling to be disabled. Several other families have only partial evidence or need additional integration.

The current runner expects a checkpoint that can predict an action chunk from the current observation. A model relying on observation history or private per-step queues cannot necessarily satisfy that contract. A working synchronous rollout does not establish remote compatibility.

For your migration record, identify the exact checkpoint revision, saved processors, camera views and robot configuration. Then record which support evidence applies to that combination. A family name is too broad to be a useful acceptance criterion, especially when different checkpoints have different memory or action conventions.

Do not remove configuration fields just to make admission pass. If the remote path cannot represent what the trained policy needs, keep the working deployment while investigating the missing integration.

Move the model configuration to the server

Start from the maintained server YAML example. It is explicitly a generic schema, not a validated robot-and-checkpoint recipe. Replace its checkpoint path, pin a Hub revision, choose the model device and match the declared robot type, action frequency, component order and units to your setup.

The example describes six state and action components, a front RGB image and a particular SO-101 action convention. Copying those declarations onto another robot would describe the wrong system, even if the vector lengths happened to match. Camera names also carry meaning: relabeling a side camera as a front camera does not give the policy the view it learned from.

Follow the versioned remote-inference guide for installation on both machines. Keep hardware dependencies on the client and policy dependencies on the server. Start the configured server with lerobot-policy-server --config_path=server.yaml, then adapt your existing rollout to --inference.type=remote and the matching endpoint and deployment. Model loading belongs on the server, so remove client-side policy-path and model-device arguments.

Before operating hardware, validate the setup in simulation where supported, preserve the manufacturer's safety procedures and have an independent emergency-stop procedure. A remote connection is not a safety certification.

Remote inference and RTC are different choices

Real-Time Chunking, or RTC, conditions a new prediction on the trajectory already underway. Remote inference determines where computation runs. You can serve ordinary action chunks remotely, and compatible checkpoints can also use RTC through that remote path.

Local --inference.type=rtc runs inference in a background thread without transport. Two separate processes on the same computer still use the remote backend. This distinction matters when diagnosing a problem: local RTC does not exercise your network, while a same-host server can help isolate transport setup from cross-machine latency.

RTC also has checkpoint-specific requirements. Its trained mode currently requires a compatible Pi05 checkpoint trained for action-prefix conditioning. Selecting a mode does not add that capability to an arbitrary policy. Start with the mechanism your checkpoint supports before exploring additional smoothing.

Diagnose action exhaustion with a time budget

Consider an illustrative deployment returning 60 actions at 30 actions per second. That prediction spans two seconds. If obtaining it takes 1.2 seconds and alignment removes the steps already passed, only about 0.8 seconds remain. Another 1.2-second request cannot fit into that remaining playback. These are example numbers, not benchmark results.

This is why I would inspect end-to-end turnaround and usable playback together before tuning. Faster model execution is only useful if the complete cycle delivers actions in time. Measure representative camera traffic and slow requests, rather than reporting the best GPU timing in isolation.

The remote guide documents bounded waiting and terminal faults. Holding the last target does not guarantee immobility or turn torque off, and a lost server connection does not automatically resume its old session. Plain TCP does not authenticate peers; outside a trusted lab network, use the documented authenticated-router configuration. The guide says operation through a router or hosted GPU still lacks hardware validation.

A sensible acceptance test therefore includes interruptions and shutdown behavior, not just successful motion. The useful result is a deployment whose timing and failure behavior you understand well enough to operate, rather than a remote demo that happened to finish once.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn complex AI systems and developer workflows into clear technical writing that people can actually use.

Book a 30-minute call.