I set up NVIDIA's ASPIRE on Anyscale and found the design I pitch for scaling sims

NVIDIA released ASPIRE v1.0 in October: it's a coding agent that writes robot control programs, with 99% success on common benchmark tasks.

I wanted to know if it was a hype project or a real research direction. After doing some research, I counted 26 projects outside NVIDIA in the same space. A frozen LLM writes robot code, runs it, fixes it and keeps what works. It's called agentic robotics, and CoRL 2026 gave it a workshop.

So I set ASPIRE up on Anyscale.

A robot arm in a LIBERO scene picks up a blue soup can and puts it in a basket

ASPIRE's example program on 1xL4, success in 27 s.

ASPIRE learns by rewriting code, not weights

Its README calls "training" skill refinement by an AI agent, instead of gradient descent.

An agent writes a program and debugs it in simulations (using practice envs, then scoring on test envs). It iteratively adds fixes and remembers them as skills for the next task.

ASPIRE's loop: an agent writes a program, the sim runs it on 15 seeds and the agent fixes it from the logs, the program is scored on 50 new seeds, and verified fixes become skills the next task starts with

ASPIRE splits the robot from its services

The program talks to two parts.

One environment interface, in Python, with LIBERO, Robosuite, BEHAVIOR-1K or two real YAM arms behind it.

Three perception and planning services, each an HTTP server with its own dependencies:

SAM3 finds objects from a text prompt. GPU.
PyRoki solves inverse kinematics. CPU.
cuRobo plans collision-free paths. GPU.

A robot program, cut down from ASPIRE's examples: localize_object calls SAM3, and move_to_pose calls PyRoki and cuRobo

Many sims share one copy of each service, "rather than one model loaded per simulator process" (their code).

I pitched the same arch for scaling sims with Ray

On 21 Oct I spoke at Encord's Long Horizon: "Why Sim Platform Shouldn't Be a Batch Job."

A common setup today, gives each scenario its own batch job and model copy. The model works 15 ms of each 1 s tick. Its GPU sits 98% idle.

A closed-loop batch job: each AWS Batch job holds a sim and its own copy of the driving model, and the model GPUs show 1.5% busy

My fix: sims in one pool, robot policies in another.

Two pools on one cluster: sims as Ray actors on RTX GPUs, the policy on Ray Serve on H100s

Same split. Arms instead of cars.

Ray Serve can run that split on fewer GPUs

ASPIRE runs its services by hand on one machine.

The same two halves on Ray: episodes as Ray tasks spread across GPU nodes, and SAM3, PyRoki and cuRobo as Serve deployments, each with its own number of copies

More out of each GPU

Batching: GPU services take one call at a time. @serve.batch runs the queue as one pass. cuRobo 0.8 plans in batches.
Fractional GPUs: SAM3 and cuRobo used 3.8 GB of my L4's 24 GB. Serve packs them beside the sims.

Two panels: batching, four sims' calls run as one GPU pass on SAM3. Fractional GPUs, one L4 split between two sims, SAM3 and cuRobo

Less to run by hand

Composition: move_to_pose calls PyRoki, then cuRobo. In one Serve app that's one call, and each step scales alone.
Compaction: copies follow the calls, to zero between runs. Anyscale's replica compaction packs the rest onto fewer nodes.
Restarts: Serve replaces a dead copy. ASPIRE's supervisor stops all three.

Three panels: composition, a sim makes one call to a planner that calls PyRoki and cuRobo inside one Serve app. Compaction, copies left on two nodes move onto one and the empty node shuts down. Restarts, a dead SAM3 copy is replaced while the others keep serving

ASPIRE's three services as Serve deployments with num_replicas set to auto, SAM3 and cuRobo on a quarter GPU and PyRoki on two CPUs, and each episode as a Ray task on a quarter GPU

I'm porting pieces of ASPIRE to Ray for my own curiosity and experiments.

Next: more experiments on less compute

ASPIRE's multi-GPU setup gives each GPU service its own card on a 4-GPU L40 machine.

My goal: more sims and service copies, on fewer GPUs.

First I'll measure how many sims one service copy can feed.

ASPIRE learns by testing code in sims. More sims per GPU means faster learning. Will share improvements in a later post.

ASPIRE is by Runyu Lu, Yubo Wu, Ethan Kou and colleagues at NVIDIA GEAR (paper).