vlaport

How it works

A control plane for your agents, an inference path for your robots

vlaport separates configuring endpoints from serving actions. Your AI agent uses the MCP server to set things up; your robot talks only to its endpoint.

vlaport architecture: control plane and inference pathTop lane, control plane: your AI agent calls the vlaport MCP server, which calls the vlaport API, which deploys your policy into your project in an EU GPU region. Bottom lane, inference path: your robot's openpi or LeRobot client connects to the edge gateway, which checks the JWT and forwards the request to your policy.CONTROL PLANEINFERENCE PATHYour AI agentthe one you already usevlaport MCPin developmentvlaport APIsource of truthdeploysYour project · EU GPU regionown credentialsYour policyπ0/π0.5, SmolVLA, …Your robotopenpi / LeRobot clientEdge gatewayJWT validated before the modelobservationsaction chunks
The MCP server is the control plane; the openpi/LeRobot-compatible endpoint is the inference path. Robots never talk to the MCP server, and agents never sit in the action loop.

From zero to an endpoint

  1. Step 1: Connect your agent

    Add the vlaport MCP server (in development) to the AI agent you already use. It is a thin client of the vlaport API and acts only with your credentials, inside your organisation.

  2. Step 2: Register a policy and a project

    Your agent registers your policy weights and creates a project. Each project gets its own credentials.

  3. Step 3: Deploy an endpoint

    Your agent deploys the policy to a GPU in the EU region. GPU deployments are approved and given a quota before they run.

  4. Step 4: Point your robot at it

    Your robot's openpi or LeRobot client connects to <company>-<project>-<id>.vlaport.com with an API token. Status and latency come back through the same agent.

Control plane: MCP

The vlaport API is the source of truth. The vlaport MCP server (in development) is a thin client of that API and has no direct access to the serving infrastructure. Your agent registers policies, creates projects, deploys endpoints and checks their status; operators and CI pipelines can use the same server. MCP never sits on the real-time path, so it does not change the robot client. See the MCP tools.

Inference path: openpi and LeRobot compatible

Each deployment gets its own endpoint, named <company>-<project>-<id>.vlaport.com. It speaks the openpi WebSocket protocol and the LeRobot gRPC async-inference protocol, so existing clients only change the endpoint URL and API key, not your robot code. Model versions are pinned per robot.

Python · openpi clientpython
from openpi_client import websocket_client_policy

# Before: a self-hosted openpi policy server
# policy = websocket_client_policy.WebsocketClientPolicy(host="localhost", port=8000)

# After: your vlaport endpoint (same client, same calls)
policy = websocket_client_policy.WebsocketClientPolicy(
    host="<company>-<project>-<id>.vlaport.com",
    # plus your vlaport API key: only the endpoint URL and API key change
)

action_chunk = policy.infer(observation)["actions"]

Illustrative. Final connection details are shared with early-access partners.

Async action chunking

VLA policies return a chunk of future actions rather than a single one. With async chunking the robot keeps executing the current chunk while the next one is computed and sent, so network delay overlaps with execution instead of stalling the robot.

Our research goes further: forecasting each robot's network delay and letting the server choose how much of a chunk is already committed, extending real-time chunking. That is part of our planned research.

Deadline-aware fleet scheduling

Generic GPU serving batches for throughput. Robots care about deadlines: an action that arrives late is a wasted action. vlaport's scheduler orders work by each robot's action deadline, so a fleet can share a GPU without the most urgent robot waiting behind others.

Per-robot latency telemetry

For every robot we record p50 and p99 latency, action staleness and buffer under-runs. The MCP status tool returns an endpoint's current p50 and p99 latency.

Edge–cloud split Roadmap

On the roadmap: a small edge policy next to the robot corrects cloud action chunks and asks the cloud for new ones only when it is uncertain, to ride out short network outages and reduce cloud calls.

What we plan to validate

Our planned milestone is proving π0.5/SmolVLA on a real robot arm. H1 and H2 are planned to be tested there; H3 (edge–cloud split) is planned to be tested at a later stage. These are targets, not results.

Research targets

Target, not a result

These are hypotheses we plan to test. They are goals, not measured results, and nothing on this site claims they have been achieved.

H1
Task success on a real robot served over the WAN stays close to a local-GPU baseline (target: the lower bound of the 95% Wilson interval is at least 90% of the baseline success rate).Planned to be tested on a real robot arm.
H2
The deadline-aware scheduler serves at least twice as many robots per GPU as FIFO scheduling, at no more than 0.1% deadline misses, measured within one tenant's fleet on one GPU (target).Planned to be tested on a real robot arm.
H3
Edge–cloud split serving cuts cloud calls by at least half with at most a 3-percentage-point loss in task success, and tolerates network outages of up to 300 ms with zero unsafe actions during an outage (target, roadmap).H3 is planned to be tested at a later stage.

Become an early-access design partner

vlaport is in development. We are looking for robot-learning teams who serve openpi or LeRobot policies today and want to shape a managed, EU-hosted endpoint with us. Tell us about your robots and policies.

Email contact.eu@vlaport.com

Sign-up is by email only. This site has no forms, sets no cookies and collects no personal data.