Physical AI infrastructure

Orchestrating Physical AI Inference

RLMesh puts a network boundary between models and environments, so each side keeps its own language and dependencies. Managed runs optimize inference across rollouts, so the GPU stays saturated.

Built for evaluation, and for any model ↔ environment inference workload, including data collection across simulators and the real world.

Self-healing fleet
RLMesh repairing
env step model inference pod failure

Fully managed, end to end. RLMesh handles scheduling, scaling, and recovery, so your evaluations just run.

Open-source framework

Any language on either side of the wire

A model and an environment don't have to share a language, or a dependency stack, to run together. RLMesh keeps each in its own process, talking over one wire, so neither is locked to the other's interpreter or versions. Python and Rust work today; C and C++ are planned on the same wire.

env processowns the simulator

1from rlmesh import
2import gymnasium as gym
3
4env = gym.make("CartPole-v1")
5(env, "127.0.0.1:5555").()
~
~
~
~
valuesbackend-agnostic; clients choose how to decode

client processowns the model

1from rlmesh.numpy import
2
3env = ("127.0.0.1:5555")
4, info = env.()
5
6 = env..sample()
7, reward, terminated, truncated, info = env.()
~
~
values

Serve from Python and connect from Rust, or reverse it. RLMesh keeps endpoints, spaces, and values on one wire contract.

Adding a model is one spec, not N adapters

Every environment reports observations in its own shape, and a generalist policy can't reshape its inputs for each one. The old way, you hand-write an adapter to reconcile every model with every environment: 4 envs means 4 adapters, 10 means 10. RLMesh makes the environment declare its observation and action spaces once, so any model connects through that contract and runs against all of them.

+1 model +N adapters vs +1 spec

Old way

+1 model = +N adapters

RLMesh

+1 model = +1 spec

Managed platform

Keep GPUs busy through the eval loop

GPU infrastructure today is built for workloads that stay fed: LLM serving runs off a constant queue of requests, and training holds its whole batch on the device. Robotics policy inference is fundamentally different. The model and the environment take turns, so every action waits on the next observation and the GPU sits idle between steps. That gap is what RLMesh closes: managed runs batch inference across concurrent rollouts, so the GPU stays busy on one batch while other environments step.

GPU timeline · who stays busy
illustrative
Physical AI Inference idle between steps
env
model
Physical AI Inference on RLMesh batched across rollouts
env
model

Same suite, same silicon, fewer idle gaps.

Open Source

The framework

Use RLMesh when simulator and model stacks need separate processes. Gymnasium-style environments get a network boundary, and value decoding stays explicit.

  • EnvServer and RemoteEnv across process boundaries
  • Sandboxed environments, each with its own dependency stack
  • Gymnasium-style environment contracts and space conversion
  • Native, NumPy, Torch, and JAX value backends

Managed Platform

Managed evaluation fleets

Run models × tasks on a connected Kubernetes cluster. RLMesh batches inference across rollouts, streams status through the control plane, and reconciles final results from artifacts.

  • Models × tasks expanded into workloads
  • Live episode results and logs through the control plane
  • Final results reconciled from object-storage artifacts
  • Connected-cluster packaging in progress

Start with the two-process quickstart

Serve CartPole in one process, connect from another, then swap in your own environment.