Replicate What Varies: Resource Sharing for Domain-Randomized Embodied Simulation

Replicate What Varies: Resource Sharing for Domain-Randomized Embodied Simulation Zixu Hao1 Weijun Wang1 Xiangyu Li1 Liang Mi1,2 Hao Wu2 Yunxin Liu1 Ting Cao1

arXiv:2610.33582v1 [cs.DC] 24 Oct 2026

1 Institute for AI Industry Research (AIR), Tsinghua University 2 Nanjing University

Abstract

supply failure traces for diagnosis, followed by further trials to validate proposed improvements [2]. Physical trials require robot hardware, operating time, and supervision; simulated environments can be reset and run in parallel at scale with much lower costs. Recent agentic real-to-sim-to-real systems reconstruct interactive simulation environments from realworld observations and transfer simulation-acquired skills or policies back to physical robots, making simulation a more practical environment for learning from experience [1, 13, 25]. We see simulation as a sandbox for embodied agents, with the potential to become part of their post-training infrastructure. The scale at which these sandboxes can run affects how much experience an agent can collect within a fixed time and hardware budget. Useful experience also requires variation in the conditions an agent encounters. Domain randomization varies properties such as lighting, textures, and object poses to expose policies to different conditions and support transfer to the real world [30]. For example, repeated attempts at a pickand-place task may use different object positions and table textures while retaining the same robot and room geometry. Collecting this experience at scale requires many such environments to run concurrently. Their combined CPU and GPU memory footprint limits how many environments fit on a machine, making efficient deployment of diverse simulation sandboxes a practical concern. Part of this memory footprint comes from duplicating resources that remain unchanged across diverse environments. High-throughput simulators are optimized for running many homogeneous environments together. 1 When environments differ, constructing separate models or scenes can copy common resources along with the properties that vary. ManiSkill’s GPU path shares a PhysX system and simulation buffers while constructing heterogeneous sub-scenes independently [28].

Simulation provides a low-cost sandbox where embodied agents can attempt tasks, observe outcomes, and learn from experience. Running many diverse simulation environments concurrently can consume substantial CPU and GPU memory because independently constructed scenes duplicate resources that remain unchanged across instances. We present Patchwork, a resource-sharing system for domain-randomized simulation, built around the representation E = T + ∆: a shared template contains common resources, and a patch records the mutations needed to construct a target environment. Patchwork separates randomization sampling from replay and selects reusable templates together with patches that preserve each target environment’s intended configuration. Its layered runtime shares compiled model structure and immutable assets while keeping mutable parameters and simulation state private to each instance. We implement Patchwork on robosuite and MuJoCo and evaluate it on LIBERO-plus and RoboCasa365 workloads. At 32 replicas, shared-template execution reduces CPU RSS by 88–92% relative to process-perenvironment execution. Controlled experiments show how sharing shifts memory growth toward template diversity and unique asset content rather than instance count, within the supported sharing boundaries.

1

Introduction

Language models are expanding how robots can interpret instructions and carry out tasks in the physical world. Recent work uses language models to generate and refine robotcontrol programs [16, 19], control robots directly through action interfaces [7, 8, 38], and coordinate vision-languageaction (VLA) policies within agent harnesses [2, 39]. These systems open a path for embodied agents to improve through experience, making access to environments for repeated interaction an important part of their development. Simulation offers a low-cost sandbox for embodied agents to interact with their surroundings and learn from this interaction. In Zetta, for example, repeated simulation rollouts

1 Recent Isaac Lab versions support heterogeneous cloning by routing asset variants to selected environments. However, sharing remains bounded by USD prim/instance and backend-native physics boundaries; mutations that cross these boundaries may require uninstancing and prevent effective sharing.

1

ization choices. Simulation frameworks often sample these choices during construction or reset. Reusing a template can bypass some of these steps or repeat others, producing a different environment if the choices remain implicit. The system must record the choices and replay their effects so that applying a patch reproduces the target instance. We present Patchwork, a simulation system that supports resource sharing for heterogeneous domain-randomized workloads. It describes environment differences through a declarative mutation interface and uses a layered runtime to construct target instances from shared templates and patches. To handle different resource granularities, Patchwork maps each supported mutation to the sharing boundary of the resource it affects. The runtime shares compiled structure through templates, keeps mutable model parameters and runtime state private to each instance, and deduplicates immutable assets by content. To preserve isolation during instance construction, Patchwork keeps templates read-only and directs supported patch mutations to instance-owned resources. During template selection and planning, it compares structural and asset profiles to identify compatible templates and derive patches within the supported mutation vocabulary. To preserve randomization choices across template reuse, Patchwork separates sampling from application and records the sampled choices as declarative mutations. Instance construction replays these mutations without resampling their values. This makes the choices explicit and replayable, allowing template reuse to reproduce the intended target instance. Our evaluation shows that, for compatible task variants, common model and asset resources need not be replicated per instance: model storage is shared within template groups, and texture storage is reused across groups. We summarize our contributions as follows: • We introduce a template-and-patch representation for domain-randomized simulation environments, with explicit, replayable mutations describing the differences between a shared template and each target instance. • We design and implement Patchwork on the robosuite/MuJoCo stack. Its layered runtime shares compiled model structure and immutable assets while isolating per-instance model parameters and simulation state. • We evaluate Patchwork on robosuite-based LIBERO-plus and RoboCasa365. With 32 RoboCasa365 environments, it reduces CPU RSS and GPU memory by 92% and 93%, respectively, compared with process-per-environment execution.

Figure 1: Resource sharing across diverse simulation environments. Many CPU-based MuJoCo stacks maintain a full model per worker, as in the subprocess environments used by RLinf for RoboCasa and LIBERO [26, 37]. When independent models are materialized, model and asset resources grow with the number of environments, limiting how many simulation sandboxes can run concurrently on a machine. Many domain-randomized environments differ in only a small portion of their description. A scene may retain the same robot, room geometry, and most assets while changing a light parameter, an object pose, or a texture reference. These limited differences leave substantial common content that could be shared across environments. Figure 1 illustrates this sharing opportunity. We represent this structure explicitly as E = T + ∆. A simulation environment E consists of a shared template T containing its invariant content and a patch ∆ recording the mutations that produce one instance. This representation allows environments to share unchanged resources while keeping the parts that vary private to each instance. Turning this representation into efficient resource sharing raises three challenges. First, simulator resources have no uniform structure or sharing granularity. Compiled model structure, model parameters, runtime state, and rendering assets have different storage layouts, lifetimes, and ownership rules. A model parameter may vary at the level of an individual field, while an immutable texture can be shared as a complete asset. The system must map the mutations in a patch to sharing boundaries appropriate for each resource type. Second, constructing an environment from a template and patch must preserve isolation and simulation semantics. Each mutation in the patch must be applied to resources owned by the target instance, leaving the shared template and other instances unaffected. The resulting environment must behave as if it had been constructed independently with the same specification. Third, template reuse must preserve the intended random-

2 2.1

Background Simulation Software Stack

Embodied simulation stacks combine task definitions, an environment framework, and physics and rendering backends. 2

XML scene description

Table 1: Representative embodied simulation software stacks. Sim. Env.

Framework

LIBERO [18] RoboCasa [22]

robosuite [41] MuJoCo [31] / OpenGL

ManiSkill [6, 28]

SAPIEN [34]

Isaac Lab [20] Isaac Sim [5] BEHAVIOR-1K [14] OmniGibson

Physics / Rendering

compile

mjModel compiled scene

PhysX [23] / Vulkan mjData1 runtime state

PhysX / RTX

mjData2 runtime state

mjData3 runtime state

Figure 2: MuJoCo separates the compiled model (mjModel) from per-instance runtime state (mjData).

LIBERO-plus

Table 1 lists representative stacks. LIBERO and RoboCasa use robosuite with MuJoCo.

2.2

base BDDL

add #21

table #25

variant A

variant B

variant C

RoboCasa365

MuJoCo provides physics simulation and rendering interfaces. robosuite adds environment construction and controllers for multiple robot embodiments. It also provides interfaces for advancing simulations and obtaining observations and rewards. LIBERO defines manipulation tasks on this stack, and LIBERO-plus [4] extends them with generated task variants. RoboCasa constructs household scenes and tasks procedurally; RoboCasa365 provides a benchmark of 365 everyday tasks.2

MuJoCo Models and Simulation State

Figure 3: Domain randomization examples from LIBEROplus and RoboCasa365.

MuJoCo separates a compiled scene description from the state of a simulation instance. It compiles an XML scene description into an mjModel, which contains the scene’s bodies, geometries, joints, actuators, assets, and simulation parameters. An mjData object stores the evolving state of one instance, including positions, velocities, contacts, sensor readings, and solver state.

2.3

Domain Randomization Interfaces

Applications express randomization choices through different interfaces: task-description files, environment construction options, or direct model edits. These interfaces also differ in when the choices take effect. LIBERO describes tasks in BDDL, a declarative taskdescription format. LIBERO-plus generates variants of these descriptions offline, for example by adding objects or changing table appearances, and stores each variant as a separate BDDL file. These choices enter the environment before the scene is compiled. RoboCasa makes choices during environment construction, selecting layouts, styles, and objects and sampling their placements. The texture variants in Figure 3 use different texture sets within the same layout and style. robosuite also exposes modders that edit fields of an existing model. They provide interfaces for changing lighting, cameras, materials and textures, and dynamics parameters such

During physics simulation (mj_step), MuJoCo treats mjModel as read-only and updates the instance’s mjData. An unchanged model can therefore be shared by multiple instances, each advancing independently with its own mjData object (Figure 2). The compiled model uses a structure-of-arrays representation with fixed-size storage allocated during compilation. Structural changes, such as adding bodies or geometries, change the array layout and require recompilation. Some parameter values, such as lighting, can instead be edited in an existing model without changing its layout. If concurrent instances require different values for these parameters, they cannot use the same model unchanged: writing a shared model field affects every instance using it. Running these variants with separate models also duplicates the unchanged parts of those models.

2 RoboCasa (v0.2) and RoboCasa365 (v1.0 onward) are releases of the same project. We distinguish them because their task sets and asset libraries differ substantially.

3

as friction, mass, and damping. These edits change model data directly rather than rebuilding the scene from its task description.

3

instance has its own mjData, whose main buffer occupies less than 1% of the model and asset footprint, reaching at most 0.77 MiB for the measured LIBERO tasks and 2.07 MiB for RoboCasa365. Sharing must preserve reusable model and asset data while keeping environment-specific parameters and runtime state isolated.

Characterizing Domain-Randomized Workloads

In this section, we characterize the domain-randomized workloads and derive the requirements they place on the system design.

3.3 Coupling Randomization with Construction Undermines Sharing and Replayability

3.1

The interfaces described in Section 2 apply variation during environment construction or through edits to an existing model. Construction typically produces a complete model for each variant, duplicating unchanged resources alongside the differences. Editing model fields avoids rebuilding the model, but those writes affect every instance that shares it. Supporting variation efficiently therefore requires identifying which resources must be constructed or privately owned for each change. RoboCasa illustrates the cost of applying these decisions at the environment level. Its default hard-reset path reconstructs the scene and reinitializes the simulator even when changes are confined to model parameters or simulation state. Reusing an existing model avoids this work but can skip randomization choices embedded in construction. In our RoboCasa365 integration, we found that the reconstruction path mixed restored episode metadata with freshly sampled task-specific choices. Such partial replay can silently produce an environment that no longer matches the recorded episode, undermining comparisons intended to use the same environment. Sharing therefore requires both selective materialization and faithful replay of the choices that define each target environment.

Variation Is Sparse and Structured

LIBERO-plus provides an enumerable set of task variants. Across 16,170 task records, we identify 5,855 distinct compiled models (Figure 4a). We group records by scene and construction metadata, then verify within-group model equivalence by compiling every member and comparing its model profile. For example, 4,000 language variants map to 21 models, all of which also occur in other families. Changing the instruction does not require a different model. Variation is also concentrated in explicit targets. Across the 16,000 non-base variants, 75% change just one semantic target in the task description: lighting, language, or background texture (Figure 4b). Object-placement perturbations (level) and distractor additions (add) affect a broader set of targets, but no variant changes more than 17. The same qualitative pattern appears in other interfaces. robosuite modders organize changes into lighting, camera, texture, and dynamics fields, while RoboCasa exposes choices for layouts, styles, objects, and placements. These interfaces generate diverse environments through explicit, structured choices.

3.2 Memory Footprints Are Layered and Skewed

3.4

Memory costs are unevenly distributed across an environment’s resources. A compiled model contains large assets such as textures and meshes alongside smaller structural arrays and simulation parameters. Environments can differ in a few parameters while retaining the same large assets. Copying the whole model to isolate those parameters also duplicates the unchanged assets. The bottom panel of Figure 4 decomposes this logical footprint for three LIBERO tasks and three RoboCasa tasks. Texture pixels alone account for 20–69% of the LIBERO models. For CloseDrawer, textures account for 81% of the footprint in RoboCasa v0.2 and 70% in RoboCasa365. The corresponding model and asset footprints are 874 MiB and 539 MiB. Smaller components still need isolation when their values differ across environments. Parameters such as light, camera, body, and site fields reside in the compiled model, so writing them in a shared model affects every instance using it. Each

Workload Properties and Requirements

The workloads examined here exhibit sparse, structured variation across resource layers with different memory costs and sharing opportunities. These observations motivate representing each environment as a reusable template and an explicit patch, E = T + ∆. Supporting this decomposition imposes four requirements. Explicit variation. The representation must identify the targets and values of each change across application interfaces. Resource-specific sharing. Materialization must reuse unchanged resources at the granularity supported by their storage and access patterns. Isolation and semantic equivalence. Constructing one instance must leave shared resources and other instances unchanged, and produce the same model and behavior as independent construction of the target environment. Faithful replay. Reconstruction must preserve sampled choices without introducing additional randomization. 4

(a) Records and compiled models language 21

1,141 799

0

1000

1,600

2000

count

189 119

0

owl NE8 tove k_bstove SCEa pots _the_s c _ a l N _b n HE ok _on _up o KITCboth m turn pick

3000

1000

median min max

0

4000

BVH

effective total (MiB)

effective total (MiB)

248

9 (3 11)

records distinct models

mesh

100

9.5 (3 17)

2,400

LIBERO (base BDDL, single seed) 200

1 1 1

4,000 4,000 4,000

1,950 1,935

light table add level base 32170

(b) Changes relative to the base task

0

5

10

15

20

25

semantic targets changed per variant

other mjModel (est.)

texture

RoboCasa (median of 3 seeds; min--max marked) 965

901

874

750

500

539

500

507

250 0

v0.2

v1(365)

CloseDrawer

v0.2

v1(365)

CheesyBread

v0.2

v1(365)

FillKettle

Figure 4: Top: compiled models (a) and per-variant changes (b) in LIBERO-plus. Bottom: model and asset memory in LIBERO and RoboCasa. RoboCasa memory bars show medians of three seeds with min–max markers.

4

5

Design Overview

5.1

Mutation Representation and Materialization Contract Mutation Specifications

We represent one environment change as an immutable MutationSpec. Each specification names a logical target, an operation, and a value:

Figure 5 shows the execution pipeline of Patchwork. Given environment specifications and randomization choices, Patchwork constructs a common mutation representation (§5). A serving policy selects reusable templates and represents each target environment as a patch over one template (§7). The resulting template–patch pairs are materialized through layered sharing mechanisms, which share compiled structure and immutable assets while isolating per-environment parameters and runtime state (§6).

target = MutationTarget("object", ("moka_pot_1", "pose")) spec = MutationSpec(target, "set", pose)

The target is a stable namespace and path, such as object/moka_pot_1/pose or scene/light/0/diffuse. It does not expose an engine-specific storage location. The generic representation admits set, add, and remove. The backend-specific vocabulary restricts these operations to targets that the resolver can materialize. For the current MuJoCo backend, compile-free serving primarily uses isolated set operations. The specification records what changes, but does not state whether the change requires a new compiled template, instance-owned model storage, or per-environment state. Benchmark and framework frontends generate this common representation for storage, template planning, and instance construction. Canonical serialization preserves each specification’s target, operation, and value across these modules. Mutation specifications thus serve as an intermediate

We first describe the mutation representation and the underlying sharing mechanisms, then explain how template serving connects the two. Section 5 makes variation explicit and replayable, exposing the differences that determine sharing opportunities. Section 6 realizes these opportunities through resource-specific mechanisms that preserve instance isolation and simulation semantics. Section 7 bridges the representation and these mechanisms by discovering reusable templates and deriving the patches that construct each target environment from them. 5

Template serving / planning §7 Frontend adapter

Environment specs

+ random choices

Mutation representations

Candidate templates

Match and select

+ profiles

Layered resource sharing §6

E1

E2

Model view E1 E2 E3

fork

Shared template

Shared asset pool

E3

+

Δ

Template–patch assignments

§5

Environment instances

Templates

Parameters

State

Materialize

Figure 5: Overview of Patchwork. The pipeline transforms environment specifications into mutation representations, serves them with shared templates and patches, and materializes them through layered resource-sharing mechanisms.

Ordered MutationSpecs Environment specification + local RNG

Table 2: Logical mutation targets and their materialization destinations.

target

scene/light/0/diffuse

Sampler

op / value

set [0.8,0.6,0.4] save

Storage same sequence

load

Resolver resolve + apply no sampling

Instance A

Target

Example

Structure Model field Runtime state Metadata

object addition model arrays light diffuse DR buffer object pose mjData task language Python env

Owner template instance instance instance

private DR buffer [0.8,0.6,0.4]

5.3

Template and Patch Semantics

Once a template is fixed, the mutations that distinguish a target environment from that template form its patch. We represent the result for environment Ei as a template identifier and an ordered patch:

Figure 6: Sampling produces an explicit mutation sequence that can be saved and replayed without further randomness. representation (IR) behind the existing application APIs.

5.2

Destination

Ei = Tg(i) + ∆i ,

Sampling and Replay

where g(i) selects the template and ∆i is a sequence of MutationSpec objects. The sequence can be persisted with encode_patch as a versioned record containing the template key and its mutations. The patch is valid only when every mutation has a defined interpretation relative to the selected template. Section 7 describes how the system makes that selection. The central contract is that materializing ∆i over Tg(i) produces the same model and execution behavior as constructing Ei independently. Section 6 describes how the runtime preserves this contract while sharing structure and assets.

Sampling produces mutation data, while application consumes that data. The sampler receives a local random-number generator and returns an ordered sequence of specifications: class LightSampler: def sample(self, rng): value = tuple(rng.uniform(0.0, 1.0, 3)) target = MutationTarget("scene", ("light", "0", " diffuse")) return (MutationSpec(target, "set", value),)

The sampler may use the generator for collision checks or retries, but those choices remain inside sample. Applying a sampled sequence uses a resolver that maps each logical target to a backend-specific writer:

5.4

Logical Targets and Resource Mapping

Mutation targets identify logical environment fields, while the resolver maps them to the resource and execution stage that owns the corresponding write. In the current backend, changes to structure or asset membership require building a new template, which remains readonly once shared. Model-field changes write to instanceowned DR buffers. Poses and other dynamic values are applied to the instance’s mjData, and task metadata is handled by its Python environment.

mutations = sampler.sample(np.random.default_rng(seed)) apply_mutations(env, mutations, resolver=resolver)

apply_mutations consumes no random numbers and preserves the order of the sequence. The same sequence can therefore be stored, applied to another compatible environment, or encoded as part of a patch and replayed later. The recorded sequence can be attached to a selected template and applied during materialization without resampling. 6

6.2

This mapping is deliberately outside MutationSpec. The same logical target can therefore be interpreted by a backendspecific resolver without changing the serialized representation, while the resolver can reject an operation that its target does not support. The interface records the mutation and its order. Template selection and the execution path determine where that mutation is materialized.

6

Some mutations change model values after compilation, such as light, camera, body, and site parameters. These fields cannot be written into the shared model body because a write for one environment would change every environment using that template. For these fields, each fork has a small private DR buffer, and the relevant model pointers resolve to that buffer after the fork. The engine can then use its normal field accesses while the mutation resolver writes only to the fork-local copy. Each fork receives a deep copy of the DR buffer, giving it independent storage for mutable model parameters. The buffer is small compared with the shared model and asset data, making a deep copy cheaper and easier to reason about than a general copy-on-write scheme. The DR boundary depends on both storage cost and update propagation. Small parameter arrays are inexpensive to copy, but their updates must also preserve the engine’s derived state. The backend admits a field only when its writes and any required derived updates stay within instance-owned storage. Fields whose updates would affect shared storage are excluded from the DR vocabulary and require a different template or materialization path. The backend explicitly defines this propagation contract for each supported field. Page-level copy-on-write can isolate modified bytes, but does not trigger the application-specific updates needed to keep related fields and derived state consistent.

Layered Model Resource Sharing

Section 5 defines a patch as an ordered sequence of logical writes over a selected template. This section describes how Patchwork materializes those writes without copying every resource for every environment. The runtime uses separate mechanisms for compiled model structure, mutable model parameters, and immutable assets. The mechanisms share a common rule: the template remains read-only, and every write is directed to the owner of the target environment.

6.1

Parameter Layer: Fork-Local DR Buffers

Structure Layer: Model Forking

MuJoCo allows instances to share an unchanged mjModel while maintaining separate mjData objects. Instances that require different model-field values need separate writable storage. Patchwork adds a model-level fork operation that creates an environment-specific model view while referencecounting the large read-only body of the compiled model. The fork owns its writable model metadata and its mjData. Unchanged compiled structure remains shared with the template. The fork operation must reproduce the complete simulation environment, not only the MuJoCo model. Robosuite also holds Python-side construction state, including choices that determine the generated MJCF and the initial simulation state. The template provides a baseline for homogeneous copies: a compiled model, a deterministic initial state, and metadata needed to replay construction decisions. The capture path disables reset-time sampling but retains the structural choices that determine the compiled model. A fork rebuilds private Python objects from the captured construction metadata and creates a shallow model copy with its own mjData. The captured state provides a common baseline for instance-specific model and state changes, allowing compatible variants to reuse the compiled model while preserving their intended differences. Process-level copy-on-write shares memory at page granularity, without distinguishing model structure, mutable parameters, and renderer resources. It does not specify how Python environments and graphics contexts should be reconstructed for each instance. The model-level operation instead makes the shared body and the per-environment owners explicit. The implementation details of its reference counting and backend integration appear in Section 8.

6.3 Asset Layer: Content-Addressed Deduplication Meshes and textures are immutable after loading and can be shared across models even when their surrounding environments differ. Patchwork assigns each asset a content identity and keeps shared references in a process-wide CPU pool. Copying a model increments references to existing asset data instead of copying its bytes. The renderer applies the same idea to GPU texture objects across the workers’ shared GL context group, using content together with texture metadata as the identity. The CPU and GPU pools are separate because they own different resource types, but both implement the same rule: equal immutable content has one physical copy and each model or context holds an explicit reference to it.

7

Template Selection and Serving

Section 5 defines a served environment as a template and an ordered patch, and Section 6 describes how the pair is materialized. This section describes the policy layer that connects the two: given a set of environment specifications, it decides which templates to make available and which patch serves each specification. The policy may resolve one specification against templates already in a cache, or plan a complete batch 7

Read-only compiled bodies Template X

Template Y

textures {τ, σ}

textures {τ, ρ}

ref.

Instance A mjModel view A patch A

asset references

light *

Private DR buffer

ref.

Instance B mjModel view B patch B

light *

Private DR buffer

CPU texture pool ref.

Instance C

σ

ρ

pixels

pixels

mjModel view C patch C

light *

GPU registry • one GL share group

Private DR buffer

τ

σ

ρ

texture

texture

texture

Context A

Context B

Context C

refs {τ, σ}

refs {τ, σ}

refs {τ, ρ}

[0.8, 0.6, 0.4]

[0.2, 0.4, 0.9]

[0.5, 0.5, 0.5]

Private runtime mjData + Python state

Private runtime mjData + Python state

Private runtime mjData + Python state

resource / pointer reference

τ pixels

supported patch write

content correspondence (distinct allocations)

Figure 7: Compiled structure is shared within template groups, while immutable textures are deduplicated across groups, separately on CPU and GPU. before any new template is built. In either case, its output assigns every environment to one template and one patch.

Batch planning is optional. The default profile-based policy composes incremental selection with grouping and one anchor per remaining group. A workload-specific policy can replace that strategy while preserving the same assignment and build-plan interface. The current LIBERO-plus offline index is a static instance of this batch path: it names representative sources and their patches before runtime construction, while unresolved requests can still fall back to the incremental cache.

7.1 Incremental Selection and Batch Planning Patchwork exposes two planning interfaces with the same output contract. Both use profiles summarizing model structure, parameter values, and immutable asset identities to check compatibility and derive patches. The frontend supplies these profiles without exposing its construction path to the selection policy. Incremental selection handles an arriving specification using the templates already registered in a cache. It obtains the specification’s profile, asks a selection policy for a compatible source, and returns a TemplateAssignment containing the source id and the derived patch. On a miss, the cache registers the specification as a new source rather than forcing it into an incompatible template. This path is the generic fallback because it does not require the workload to be known in advance. Batch planning receives the whole collection of specifications and returns a BatchTemplatePlan:

7.2

The Operational Serving Preorder

Let V be the backend’s compile-free materialization vocabulary, rather than all operations expressible by the generic mutation representation. We say that B serves A when a valid ordered patch from V materializes A from B: A ⪯V B

⇐⇒

∃∆ ∈ V ∗ : apply(B, ∆) ≡ A.

The equivalence here is the materialization contract of Section 5, including the environment state and behavior. The patch must preserve the write-isolation requirements of Section 6. The direction is from the target A to the template B that can serve it. An empty patch gives A ⪯V A. If valid patches can be composed without recompilation, concatenating patches from C to B and from B to A gives A ⪯V C. Under this closure condition, ⪯V is a preorder. Its mutual-serving kernel, A ∼V B iff A ⪯V B and B ⪯V A, is an equivalence relation. A one-way serving relation can cover several targets with one template, whereas the kernel partitions environments into classes whose members can serve one another. The preorder defines a larger search space for batch planning. The current policy uses its mutual-serving kernel under the restricted MuJoCo vocabulary: it partitions profiles into

plan = cache.plan( members, profile_of=profile_of, vocabulary=vocabulary, policy=policy)

The plan contains one build record for each template that must be materialized and one assignment for each workload member. The policy chooses how to group profiles, which member anchors each group, and which patch derives every other member from that anchor. The cache applies the plan only after planning completes, so template construction can be performed once per selected source and in parallel when the caller provides a parallel materialization path. 8

Req.

Requests

Mask → fingerprints

immutable config + light.diffuse

V = {light.diffuse}

Config

Classes → templates

Member assignments patch sets light.diffuse

Mask writable field

Diffuse

light.diffuse → *

A

X

[0.8,0.6,0.4]

B

X

[0.2,0.4,0.9]

keep config + assets

C

X

[0.5,0.5,0.5]

Kx = h(X, {τ})

class {A, B, C} rep. A → Tx

B: Tx + [0.2,0.4,0.9]

D

Y

[0.8,0.6,0.4]

Ky = h(Y, {τ})

class {D} rep. D → Ty

D: Ty + ∅

A: Tx + ∅

All requests use asset set {τ}.

C: Tx + [0.5,0.5,0.5]

X ≠ Y gives two templates; identical asset content τ can still be shared across them.

Figure 8: Template serving groups profiles by their unchanged structure and asset identities, selecting one representative per class and deriving member patches. equivalence classes and selects one representative for each class. A more general policy could select templates whose serving regions cover the whole workload. For example, if the mutation vocabulary can select asset bindings, a policy could construct a union template for several classes and serve each member with a class-specific patch. This policy would require executable support for the additional mutations and is outside the current implementation. To explore such union templates, a policy can use a structural–asset cover test as a preliminary filter before deriving executable patches. The test checks for compatible non-asset topology, sufficient reachable asset counts, and an asset set covering the target’s requirements. Passing this test identifies a candidate whose resources could cover the target, subject to backend support for selecting asset bindings and applying the required writes.

7.3

dent of input order, while the representative can be chosen by a policy such as minimum total patch writes. The resulting assignments are recorded explicitly so that template construction and environment creation consume the same plan.

7.4 Offline Index Construction and Validation When a workload or a useful subset of it can be enumerated in advance, the batch interface can build an offline index of template assignments. The index records each covered specification’s selected template and patch. It can be reused across runs through the same assignment interface as the incremental cache. Planning groups specifications using their profiles and selects the templates to construct. Requests outside the indexed subset use incremental selection, so the index can be partial or omitted entirely. The indexed path is summarized below.

Equivalence-Based Serving

for member in workload: profiles[member] = profile_of(member)

The current implementation instantiates batch planning with the mutual-serving kernel of the operational preorder. Two profiles belong to the same class when they have identical immutable asset identities and agree outside the structure fields covered by the mutation vocabulary. The class fingerprint excludes patchable fields from the structural comparison and includes the sorted asset identities. Within each class, the policy selects one representative and derives the field-level patches for the other members:

groups = group_by_key(profiles, vocabulary) plan = select_representatives(groups, policy) for source in plan.templates: template = materialize(source.representative) check_profile(template, profiles[source.representative ]) for member in source.members: patch = derive_patch( profiles[source.representative], profiles[ member], vocabulary) check_profile_patch(template, patch, profiles[ member]) index[member] = (source.id, patch)

vocabulary = (PatchField(1, ("scene", "light"), "diffuse") ,) patch = derive_patch(template_profile, member_profile, vocabulary)

The first check ensures that the profile used for planning describes the model that is actually materialized. The second checks that the template and patch reproduce the member’s

This policy turns planning into deterministic grouping followed by representative selection. The grouping is indepen9

9.1

profile within the supported mutation vocabulary. The full materialization contract also requires agreement in derived state and execution behavior with an independently constructed target environment. Section 9 reports the coverage and results of profile and execution-level validation.

8

Workloads. We use three workload families on the robosuite/MuJoCo stack: the base robosuite benchmark suite, LIBERO-plus, which provides an enumerable corpus of task variants, and RoboCasa365, which supplies asset-rich household scenes. Unless stated otherwise, the workloads are robosuite’s PickPlaceMilk, the libero_10 living-room basket task of LIBERO-plus, and RoboCasa365’s CloseDrawer.

Implementation

We implement Patchwork on the MuJoCo/robosuite stack with approximately 18K LoC.

8.1

Software. Patchwork is implemented on forked robosuite 1.5.2 and MuJoCo 3.8.1 code bases, with the LIBERO-plus (v0.1.0) and RoboCasa365 (v1.0.1) benchmark packages on top.

MuJoCo Engine Extensions

We add a shallow-copy fork primitive and use reference counting to manage the shareable body of an mjModel. Each model can own a private DR buffer, which is deep-copied when the model is copied. Enabling a DR group redirects the corresponding model pointers into this buffer, allowing existing engine field accesses to use instance-owned storage. We extend the engine’s macro-based field declarations to define DR groups and derive buffer sizing, field copying and pointer redirection. Fields admitted to these groups must satisfy the propagation contract described in Section 6. The current asset-pooling implementation deduplicates textures on both CPU and GPU. The CPU texture pool uses content hashes and reference counting to manage shared pixel data. A mjModel no longer exposes tex_data as one contiguous pixel array, and texture-size statistics report logical bytes referenced by the model. A renderer-side registry shares GPU texture objects across GL contexts using content and texture metadata as the key.

8.2

Testbed. Experiments run on a server with two Intel Xeon Silver 4314 CPUs (32 physical cores total) and NVIDIA A40 GPUs with 48 GB of memory each. Each GPU benchmark run uses one selected A40 for EGL offscreen rendering. Metrics. We report throughput in environment steps per second, CPU RSS, and process-attributed GPU memory. CPU RSS sums the resident set sizes of the benchmark process and its descendants. GPU memory is attributed to those processes on the selected device. Scaling experiments average memory samples taken during steady-state execution after warmup. Scaling results report medians over three seeds, with throughput measured after warmup.

9.2 Resource Use and Throughput under Replica Scaling We first measure stepping with camera and object observations disabled in env.step, while keeping offscreen rendering initialized and available on demand. This configuration excludes Python-side camera and object observation processing, whose GIL contention limits threaded scaling. We then enable camera observations to measure their additional cost.

Threaded robosuite Runtime

We run environments as threads within one process so they can access shared model and asset pools. The Python controller path in robosuite limits concurrent execution through the GIL. We move the physics and controller computations on the simulation hot path into C++, releasing the GIL during their execution. Correctness checks compare control outputs and simulation states against the Python path from matching initial states and actions. Environments are assigned to fixed worker threads, each owning a GL context. The contexts of all workers belong to one EGL share group, enabling texture sharing in GPU memory.

9

Evaluation Setup

Replica scaling. For each workload, we compare processper-environment execution, threaded execution with independent models, and threaded execution with shared templates as the replica count increases. Each comparison uses the same task and observation configuration. GPU texture sharing is enabled in all three configurations. Figure 9 shows substantial memory savings with throughput close to process-perenvironment execution. At N=32, shared-template threads reduce summed CPU RSS by 88% on LIBERO-plus and 92% on RoboCasa365 relative to separate processes. On RoboCasa365, summed RSS falls from 123.8 to 10.5 GiB, compared with 27.6 GiB for independent threads. GPU memory falls from 44.0 to 3.2 GiB, compared with 5.9 GiB for independent threads. Throughput is 1,632 versus 1,550 steps/s on

Evaluation

We evaluate how sharing affects resource use and throughput, how resource use changes with workload diversity, and how effectively templates serve related environments. We check semantic equivalence alongside the serving results. 10

process summed RSS (GiB)

robosuite

summed RSS (GiB)

128 64 32 16 8 4 2 1

1

2

summed RSS (GiB)

LIBERO-plus

8

thread, fork

GPU DRAM (GiB)

32.00 16.00 8.00 4.00 2.00 1.00 0.50 0.25

1000 500 1

2

4

8

16 32

32.00 16.00 8.00 4.00 2.00 1.00 0.50 0.25

RoboCasa365

2

4

8

1

2

4

8

16 32

1

2

4

8

16 32

1000 500 1

2

4

8

16 32

32.00 16.00 8.00 4.00 2.00 1.00 0.50 0.25 1 2 4 8 16 32 number of environments (N)

0

1500

16 32

128 64 32 16 8 4 2 1

throughput (env-steps/s) 1500

16 32

128 64 32 16 8 4 2 1

1

summed RSS (GiB)

4

thread, independent

0

400 200

1 2 4 8 16 32 number of environments (N) Bars: median of 3 seeds; whiskers: min-max.

0

1 2 4 8 16 32 number of environments (N)

Figure 9: Resource use and throughput across replica counts. Bars show medians over three seeds with min–max markers. LIBERO-plus and 475 versus 533 steps/s on RoboCasa365 for shared-template threads and separate processes, respectively.

use 3.9 versus 7.1 GiB of GPU memory and 10.7 versus 27.7 GiB of summed RSS for independent threads. Camera observations reduce shared-template throughput from 475 to 241 steps/s, which remains 21% above independent threads. The camera observation path still processes images in Python and is subject to GIL contention as concurrency grows. We expect moving this Python observation path into native code to alleviate the throughput scaling bottleneck.

Table 3: Effect of enabling camera observations on RoboCasa365. Values are medians over three seeds. Steps/s Config N indep. indep. indep. shared shared shared

1 8 32 1 8 32

GPU (GiB)

RSS (GiB) off

off

on

off

45.5 226.3 348.9 46.6 420.4 474.6

39.6 162.3 199.4 41.5 267.8 240.6

0.65 1.83 5.89 0.56 1.16 3.22

on

on

0.68 2.70 2.72 2.15 10.66 10.82 7.14 27.61 27.67 0.58 2.59 2.58 1.32 5.11 5.44 3.85 10.50 10.71

9.3

Memory under Workload Diversity

We separate the memory effects of template diversity and unique asset content. Here N is the number of environment instances and K is the number of serving classes, each materialized with one template. These construction experiments do not initialize a renderer.

Camera observations. We enable one 224×224 RGB camera in each environment’s step observations (Table 3). The memory advantage persists: at N=32, shared-template threads

Controlled variation. We hold N fixed and increase K in LIBERO-plus (Figure 10a). Each class serves at least one 11

N = 32 N = 64 no-sharing sanity

1

2

4

8 16 32 64

Serving classes (K)

7 6 5 4 3

(b) Axis-isolated light texture region

1

2

object language

4

8

Summed RSS (GiB)

(a) Serving-class response

Summed RSS (GiB)

Summed RSS (GiB)

12 10 8 6 4

16 32

Serving classes (K), N = 32

(c) Within-class

3.3

K=1 K=2

3.2 3.1 3.0 2.9

1

2

4

8

16 32

Distinct variants per class (M)

Figure 10: LIBERO-plus memory use as template diversity (a, b) and distinct variants per class (c) increase. Crosses mark independent-model baselines. instance, so K ≤ N. At N=32, summed RSS grows from 2.98 to 7.14 GiB as K increases from 1 to 32. When K=N, no two instances reuse a template, and RSS approaches the independent-model baseline. The same trend holds at N=64 and when varying each mutation axis separately (Figure 10b). Light and language sweeps stop at K=16 because the index contains only 21 eligible classes for those axes. At fixed N=32 and K, we increase the number M of distinct task variants per class, repeating sampled variants to fill the 32 instances (Figure 10c). The constraint KM ≤ 32 limits the K=2 sweep to M=16. RSS varies by at most 55 MiB as the number of distinct variants per class increases from 1 to 32, showing little additional memory cost for task variation served by the same templates.

Table 4: Static accounting of the LIBERO-plus offline index. Index quantity Variant records Distinct models Selected templates Additional models served Patch writes per additional model

9.4

Value 16,170 5,855 3,042 (−48.0%) 2,813 (6 zero-write) median 6, max 22

Template Serving and Correctness

Offline index. The 16,170 LIBERO-plus records describe 5,855 distinct models. Template selection reduces the number of templates needed to serve these models to 3,042, a 48% reduction (Table 4). The remaining 2,813 models are served by applying patches to the selected templates. These patches contain a median of six field writes and a maximum of 22, with six requiring no writes.

Controlled texture response. To isolate asset-content costs, we generate RoboCasa365 workloads with noise images of controlled resolutions in the four generative texture slots. The requested files determine the total unique compiled texture bytes. With one template, RSS grows approximately linearly with this quantity over a 0.75 GiB range, with slope 0.96 and R2 =0.966 (Figure 11a). To test reuse across templates, we compare K templates referencing one common texture set with K templates referencing disjoint sets (Figure 11b). At K=8, the disjoint case uses 1.35 GiB more RSS, consistent with the cost of seven additional 0.19 GiB texture sets. Texture differences still require separate templates under the current vocabulary, while the content pool reuses textures shared across those templates.

Selection policy. We compare the offline index and incremental selection on identical uniformly sampled request sets, with three trials at each size (Figure 12). We measure reuse as 1 − T /R, where T is the number of selected templates and R is the number of requests. Constructing one model per request gives zero reuse. Both paths select the same number of templates in every trial, with median reuse rising from 6% at 16 requests to 50% at 256 requests. The offline index preserves this reuse while reducing online assignment cost from 0.79–0.88 s to 0.51–0.53 ms per request by eliminating runtime profile construction and patch derivation. Incremental selection itself takes only 0.04–0.45 ms once profiles are available, with profile construction accounting for nearly all of its online cost. Loading the index takes 0.14 s once per run. These timings exclude template materialization, which is still required on first use.

Native-style workloads. We also use RoboCasa365’s native texture choices, varying palette overlap across three levels at K=8 and N=32 while holding the task, layout, and replay metadata fixed. Template serving reduces summed RSS by 31–33%, from 8.41–8.65 GiB with independent models to 5.60–5.94 GiB. These workloads combine texture overlap with differences in compiled asset composition. 12

RSS vs K = 1 (GiB)

RSS (GiB), K = 1

0.75

(a) Asset response

slope 0.96, R 2=0.966

0.50 0.25 0.00 0.0

0.2

0.4

0.6

(b) Content-addressed pool 3

Common texture set Disjoint texture sets

2 1 2

Unique compiled texture bytes (GiB)

4

8

Templates (K), 40962 textures, N = 32

Figure 11: RoboCasa365 memory response to unique texture bytes (a) and texture sharing across templates (b), with N=32.

template reuse rate

60% 40%

offline index incremental cache compile all (0%)

1.24

RoboCasa365

1.79

1.91

0

0%

process baseline first template capture

16

64

requests per draw

256

1.24

1.56

20%

2

4.55 GiB

1.99

4

summed RSS (GiB)

5.51 GiB

6

remaining 7 captures fork-private state (32 envs)

Figure 13: RSS growth during template and instance construction, with K=8 and N=32.

Figure 12: Template reuse under uniform LIBERO-plus request sampling. Bars show medians of three trials, with individual trials marked by dots.

In the construction microbenchmark, capturing a template from an existing environment takes about 1 ms, compared with 0.3–0.8 s to construct and reset the source environment. Creating an instance from the template takes about 0.1 s. Template capture adds little overhead to source construction, and subsequent instances avoid rebuilding the shared model.

Semantic checks. Model-level acceptance tests compare served profiles with independently compiled target models. Seeded rollout checks cover four tasks over 30 steps, comparing each member of a shared group with a separately run instance using the same template, patch, seed, and actions. Simulator states and images from both cameras match bitwise, and success flags agree. Rebuilt groups and indexed versus incremental selection also produce identical trajectory hashes.

9.5

LIBERO-plus

Sharing-layer ablation. Figure 14 independently enables model sharing and GPU texture sharing across replica counts. At N=32, model sharing alone lowers summed RSS from 74.0 to 31.4 GiB by reusing the captured model and its hostside content. GPU texture sharing alone lowers GPU memory from 44.1 to 5.9 GiB by reusing textures across rendering contexts. Enabling both lowers summed RSS to 10.5 GiB and GPU memory to 3.2 GiB, reductions of 7.0× and 13.7× from the configuration with both disabled. The combined savings show that sharing at both layers is needed to reduce CPU and GPU memory together. Throughput also improves with either layer enabled, reaching 629.6 steps/s with both enabled compared with 273.6 steps/s with both disabled.

Component Costs and Ablation

Construction costs. We sample RSS after each template capture and each batch of instances to measure memory growth during construction (Figure 13). At K=8 and N=32, constructing the first template adds 1.24 GiB for LIBEROplus and 1.79 GiB for RoboCasa365, including initial asset loading and initialization. The remaining seven templates together add 1.91 and 1.56 GiB, respectively. Constructing the 32 instances adds another 1.24 and 1.99 GiB, averaging about 40 and 64 MiB per instance. This per-instance cost includes private environment objects and simulation state. 13

fork

GPU texture sharing on

40 30 20 10 0

(b) Summed CPU RSS

summed RSS (GiB)

GPU DRAM (GiB)

(a) GPU memory

1

2

4

8

16

GPU texture sharing off

32

number of environments (N)

60 40 20 0

1

2

4

8

16

32

number of environments (N)

throughput (env-steps/s)

independent

(c) Throughput 600 400 200 1

2

4

8

16

32

number of environments (N)

Figure 14: Model and GPU texture sharing ablation on RoboCasa365, showing medians of three seeds.

10

Discussion

variation. MuJoCo Warp supports both shared and per-world model fields; its per-world mesh workflow uses a base model containing all candidate meshes and the maximum required geometry slots, with per-world fields selecting meshes and disabling unused slots [21]. Isaac Lab combines USD instancing with backend-native physics replication, mapping asset prototypes to selected environments so that compatible heterogeneous variants can retain physics replication [10]. Some forms of variation require changing the sharing arrangement: its visual texture randomization implementation disables physics replication and removes instancing from affected visual prims before editing their materials [11].

Independent Agent Interactions and Batched Simulation. Simulation sandbox workloads can differ from lockstep reinforcement-learning rollouts. An agent may need to keep interacting with one environment while other agents are waiting for model inference, diagnosis, or recovery decisions. GPU vectorized simulators are highly effective when environments advance in synchronized batches, but irregular arrivals can leave a runtime choosing between waiting to form a batch and executing smaller batches. We focus on CPU-based simulation sandboxes, where environments can progress independently while still sharing resources within a process. This execution flexibility motivates our target workload; quantifying the trade-off against GPU batching under asynchronous agent requests remains future work.

Resource Sharing in Sandboxes and Serverless Systems. Memory sharing has long supported dense deployment of isolated instances. Page deduplication and shared filebacked mappings reduce repeated memory across virtual machines and sandboxes, as in VMware ESX, Linux KSM, and DeepSeek’s DSec [9, 29, 32]. Serverless systems reuse initialized state through zygote processes, checkpoint restoration, and local or remote fork, reducing startup costs and repeated initialization across instances [3, 24, 33]. Faasm combines WebAssembly-based isolation with shared memory regions between co-located functions [27]. These mechanisms provide reuse at page, process, or sandbox boundaries. Patchwork instead derives sharing boundaries from simulation resources and supported mutations, allowing common assets to be reused across different model templates while applying parameter changes to private storage.

Sharing Boundaries and Generality. The sharing opportunities a runtime can realize depend on its resource representation and supported mutations. A field’s size and the updates it induces in derived state help determine whether it can vary privately while the rest of a model remains shared. Our current backend restricts these mutations to keep their effects and isolation requirements explicit. Equivalence-based serving then provides a concrete policy within the broader serving preorder. A richer backend could support asset rebinding and union templates that serve targets from several current equivalence classes, at the cost of additional storage, isolation, and validation requirements. The template–patch interface allows these policies to evolve alongside the sharing mechanisms, while retaining the requirement that each served instance reproduce its target environment.

11

Structure-Aware Resource Sharing. Application structure can expose reuse opportunities and guide the mechanisms that realize them. Tetris identifies identical model tensors across serverless functions and maps them into shared read-only memory [15]. PagedAttention manages KV cache in shareable blocks [12], while SGLang discovers common prefixes through a radix tree and schedules requests to reuse cached

Related Work

Sharing in Heterogeneous Simulation. GPU simulators combine resource sharing with several forms of environment 14

state [40]. Parrot exposes application dataflow through Semantic Variables, enabling the serving system to identify related requests and coordinate their execution [17]. Sharing also affects memory traffic: FlashInfer’s cascade attention separates shared-prefix and private-suffix attention so that multiple queries can reuse prefix KV data within a kernel [35, 36]. Across these systems, workload representations, reuse discovery, and execution mechanisms work together to exploit common structure. Patchwork follows this approach for simulation: explicit mutations and resource profiles expose reuse, serving policies select templates, and the runtime materializes the assignments through model and asset sharing.

12

Zhaoye Fei, Jinlan Fu, Jingjing Gong, and Xipeng Qiu. LIBERO-Plus: In-depth robustness analysis of vision-language-action models. arXiv preprint arXiv:2510.13626, 2025. [5] Sicong Gao, Maurice Pagnucco, Tomasz Bednarz, and Yang Song. Nvidia isaac sim: Enabling scalable, gpuaccelerated simulation for robotics. arXiv preprint arXiv:2606.03551, 2026. [6] Jiayuan Gu, Fanbo Xiang, Xuanlin Li, Zhan Ling, Xiqiang Liu, Tongzhou Mu, Yihe Tang, Stone Tao, Xinyue Wei, Yunchao Yao, et al. ManiSkill2: A unified benchmark for generalizable manipulation skills. In International Conference on Learning Representations (ICLR), 2023.

Conclusion

Patchwork represents domain-randomized environments as shared templates and explicit patches, allowing simulation sandboxes to reuse common resources across task variants. Its mutation interface, layered sharing runtime, and templateserving policies connect environment differences to the physical resources that must be private or can remain shared. Our robosuite/MuJoCo prototype reduces memory use in replicascaling and controlled heterogeneous workloads, with savings determined by template reuse and asset overlap. These results support template-based resource sharing as a way to deploy diverse simulation environments within a fixed memory budget.

[7] Meng-Hao Guo, Zhe-Han Mo, Jia-Jun Wang, Yi Zhang, Kejin Wang, Yi-Xuan Deng, Jia-Peng Zhang, Yongming Rao, and Shi-Min Hu. Transferring the intelligence of VLMs to robotic control. arXiv preprint arXiv:2609.22966, 2026. [8] Sida He, Lingxi Xie, Yunning Cao, Pengfei Chen, Kaiwen Duan, Jiannan Ge, Xinyue Huo, Jiacheng Shao, and Qi Tian. Robot manipulation with GPT-6-Astra: Body knowledge, experience reuse, emergent skills, and Sim2Real transfer. arXiv preprint arXiv:2609.31770, 2026.

References

[9] Jialiang Huang, Hongxuan Tang, Jingchang Chen, et al. DeepSeek Elastic Compute (DSec): A sandbox infrastructure for effective agentic training at scale. arXiv preprint arXiv:2609.22978, 2026.

[1] Kaiyuan Chen, Shuangyu Xie, Uksang Yoo, Xinyue Zhu, Cael Magner, Alvin Zhu, Daehwa Kim, Eric Heiden, Erwin Coumans, Miles Macklin, Spencer Huang, and Ken Goldberg. RoboSimStudio: An interactive toolkit for human and agent rapid Real2Sim of robot manipulation tasks. arXiv preprint arXiv:2610.18835, 2026.

[10] Isaac Lab Developers. Isaac Lab: Multiasset spawning and clone planning. https: //github.com/isaac-sim/IsaacLab/blob/ a8b4da3c29ae528b39d4b3c9444d782ce58d886d/ docs/source/how-to/multi_asset_spawning. rst. Source revision inspected October 18, 2026.

[2] Xin Ding, Liang Mi, Mingzhe Huang, Zixuan Wang, Chao Zhang, Zixu Hao, Fu Chen, Xiangyu Li, Yikai Zheng, Yaoyu Guo, Weijun Wang, Kun Li, Hao Wu, Yunxin Liu, and Ting Cao. Zetta ζ: An efficient closedloop embodied harness for self-evolving physical intelligence. arXiv preprint arXiv:2608.16590, 2026.

[11] Isaac Lab Developers. Isaac Lab: Visual material randomization implementation. https://github.com/isaac-sim/IsaacLab/blob/ a8b4da3c29ae528b39d4b3c9444d782ce58d886d/ source/isaaclab/isaaclab/envs/mdp/events. py. Source revision inspected October 18, 2026.

[3] Dong Du, Tianyi Yu, Yubin Xia, Binyu Zang, Guanglu Yan, Chenggang Qin, Qixuan Wu, and Haibo Chen. Catalyzer: Sub-millisecond startup for serverless computing with initialization-less booting. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, pages 467–481, 2020.

[12] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with PagedAttention. In Proceedings of the 29th Symposium on Operating Systems Principles, pages 611–626, 2023.

[4] Senyu Fei, Siyin Wang, Junhao Shi, Zihao Dai, Jikun Cai, Pengfang Qian, Li Ji, Xinzhe He, Shiduo Zhang, 15

[13] Bowei Li, Yuner Zhang, and Changliu Liu. ARSTAG: An agentic Real2Sim2Real system for task-specific robot data generation. arXiv preprint arXiv:2609.24563, 2026.

[22] Soroush Nasiriany, Abhiram Maddukuri, Lance Zhang, Adeet Parikh, Aaron Lo, Abhishek Joshi, Ajay Mandlekar, and Yuke Zhu. RoboCasa: Large-scale simulation of everyday tasks for generalist robots. In Robotics: Science and Systems (RSS), 2024.

[14] Chengshu Li, Ruohan Zhang, Josiah Wong, Cem Gokmen, Sanjana Srivastava, Roberto Martín-Martín, Chen Wang, Gabrael Levine, Michael Lingelbach, Jiankai Sun, et al. BEHAVIOR-1K: A benchmark for embodied AI with 1,000 everyday activities and realistic simulation. In Proceedings of The 6th Conference on Robot Learning (CoRL), volume 205 of Proceedings of Machine Learning Research, pages 80–93. PMLR, 2023.

[23] NVIDIA. NVIDIA PhysX SDK. https://developer. nvidia.com/physx-sdk, 2024. [24] Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Harter, Andrea C. Arpaci-Dusseau, and Remzi Arpaci-Dusseau. SOCK: Rapid task provisioning with Serverless-Optimized containers. In 2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 57–70. USENIX Association, 2018.

[15] Jie Li, Laiping Zhao, Yanan Yang, Kunlin Zhan, and Keqiu Li. Tetris: Memory-efficient serverless inference through tensor sharing. In 2022 USENIX Annual Technical Conference (USENIX ATC 22), pages 475–488. USENIX Association, 2022.

[25] Kerui Ren, Yingxiang Xu, Kaiwen Song, Linning Xu, Bo Dai, Mulin Yu, and Tao Lu. Real2Gym: Building gyms from videos, bringing skills to robots. arXiv preprint arXiv:2609.37089, 2026.

[16] Jacky Liang, Wenlong Huang, Fei Xia, Peng Xu, Karol Hausman, Brian Ichter, Pete Florence, and Andy Zeng. Code as Policies: Language model programs for embodied control. arXiv preprint arXiv:2209.07753, 2023.

[26] RLinf Authors. RLinf: Reinforcement learning infrastructure for embodied agents. GitHub, 2025. [27] Simon Shillaker and Peter Pietzuch. Faasm: Lightweight isolation for efficient stateful serverless computing. In 2020 USENIX Annual Technical Conference (USENIX ATC 20), pages 419–433. USENIX Association, 2020.

[17] Chaofan Lin, Zhenhua Han, Chengruidong Zhang, Yuqing Yang, Fan Yang, Chen Chen, and Lili Qiu. Parrot: Efficient serving of LLM-based applications with semantic variable. In 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24), pages 929–945. USENIX Association, 2024.

[28] Stone Tao, Fanbo Xiang, Arth Shukla, Yuzhe Qin, Xander Hinrichsen, Xiaodi Yuan, Chen Bao, Xinsong Lin, Yulin Liu, Tse kai Chan, Yuan Gao, Xuanlin Li, Tongzhou Mu, Nan Xiao, Arnav Gurha, Viswesh Nagaswamy Rajesh, Yong Woo Choi, Yen-Ru Chen, Zhiao Huang, Roberto Calandra, Rui Chen, Shan Luo, and Hao Su. Maniskill3: Gpu parallelized robotics simulation and rendering for generalizable embodied ai. Robotics: Science and Systems, 2025.

[18] Bo Liu, Yifeng Zhu, Chongkai Gao, Yihao Feng, Qiang Liu, Yuke Zhu, and Peter Stone. LIBERO: Benchmarking knowledge transfer for lifelong robot learning. In Advances in Neural Information Processing Systems (NeurIPS), volume 36, pages 44776–44791, 2023.

[29] The Linux Kernel Documentation. Kernel Samepage Merging. Linux kernel documentation. Accessed October 21, 2026.

[19] Runyu Lu, Yubo Wu, Ethan Kou, Letian Fu, Wenli Xiao, Ajay Mandlekar, Yinzhen Xu, Guanya Shi, Ken Goldberg, Ang Chen, Mosharaf Chowdhury, Yuke Zhu, Linxi "Jim" Fan, and Guanzhi Wang. ASPIRE: Agentic /skills discovery for robotics. arXiv preprint arXiv:2607.00272, 2026.

[30] Josh Tobin, Rachel Fong, Alex Ray, Jonas Schneider, Wojciech Zaremba, and Pieter Abbeel. Domain randomization for transferring deep neural networks from simulation to the real world. arXiv preprint arXiv:1703.06907, 2017.

[20] Mayank Mittal, Calvin Yu, Qinxi Yu, Jingzhou Liu, Nikita Rudin, David Hoeller, Jia Lin Yuan, Ritvik Singh, Yunrong Guo, Hammad Mazhar, Ajay Mandlekar, Buck Babich, Gavriel State, Marco Hutter, and Animesh Garg. Orbit: A unified simulation framework for interactive robot learning environments. IEEE Robotics and Automation Letters, 8(6):3740–3747, 2023.

[31] Emanuel Todorov, Tom Erez, and Yuval Tassa. MuJoCo: A physics engine for model-based control. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 5026–5033, 2012. [32] Carl A. Waldspurger. Memory resource management in VMware ESX server. In USENIX Symposium on Operating System Design and Implementation (OSDI), pages 181–194, 2002.

[21] MuJoCo Developers. MuJoCo Warp documentation. https://mujoco.readthedocs.io/en/stable/ mjwarp/index.html. Accessed October 17, 2026. 16

[40] Lianmin Zheng, Liangsheng Yin, Zhiqiang Xie, Chuyue Sun, Jeff Huang, Cody Hao Yu, Shiyi Cao, Christos Kozyrakis, Ion Stoica, Joseph E. Gonzalez, Clark Barrett, and Ying Sheng. SGLang: Efficient execution of structured language model programs. arXiv preprint arXiv:2312.07104, 2023.

https://www.usenix.org/legacy/event/osdi02/ tech/waldspurger/waldspurger.pdf. [33] Xingda Wei, Fangming Lu, Tianxia Wang, Jinyu Gu, Yuhan Yang, Rong Chen, and Haibo Chen. No provisioned concurrency: Fast RDMA-codesigned remote fork for serverless computing. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23), pages 497–517. USENIX Association, 2023.

[41] Yuke Zhu, Josiah Wong, Ajay Mandlekar, Roberto Martín-Martín, Abhishek Joshi, Kevin Lin, Abhiram Maddukuri, Soroush Nasiriany, and Yifeng Zhu. robosuite: A modular simulation framework and benchmark for robot learning. arXiv preprint arXiv:2009.12293, 2020.

[34] Fanbo Xiang, Yuzhe Qin, Kaichun Mo, Yikuan Xia, Hao Zhu, Fangchen Liu, Minghua Liu, Hanxiao Jiang, Yifu Yuan, He Wang, Li Yi, Angel X. Chang, Leonidas J. Guibas, and Hao Su. SAPIEN: A simulated partbased interactive environment. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pages 11097–11107, 2020. [35] Zihao Ye, Lequn Chen, Ruihang Lai, Wuwei Lin, Yineng Zhang, Stephanie Wang, Tianqi Chen, Baris Kasikci, Vinod Grover, Arvind Krishnamurthy, and Luis Ceze. FlashInfer: Efficient and customizable attention engine for LLM inference serving. arXiv preprint arXiv:2501.01005, 2025. [36] Zihao Ye, Ruihang Lai, Bo-Ru Lu, Chien-Yu Lin, Size Zheng, Lequn Chen, Tianqi Chen, and Luis Ceze. Cascade inference: Memory bandwidth efficient shared prefix batch decoding. FlashInfer technical blog, 2024. [37] Chao Yu, Yuanqing Wang, Zhen Guo, Hao Lin, Si Xu, Hongzhi Zang, Quanlu Zhang, Yongji Wu, Chunyang Zhu, Junhao Hu, Zixiao Huang, Mingjie Wei, Yuqing Xie, Ke Yang, Bo Dai, Zhexuan Xu, Jiakun Du, Xiangyuan Wang, Xu Fu, Letong Shi, Zhihao Liu, Kang Chen, Weilin Liu, Gang Liu, Boxun Li, Jianlei Yang, Zhi Yang, Guohao Dai, and Yu Wang. RLinf: Flexible and efficient large-scale reinforcement learning via macroto-micro flow transformation. In 20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 26), pages 829–846. USENIX Association, 2026. [38] Wenbo Zhang, Kaixuan Wang, Yutao Ouyang, Xiaoyu Huang, Liyang Li, Kailun Su, Weiyang Jin, Wenhao Chai, Haotian Liang, Zhiyang Dou, Yue Chen, and Tianxing Chen. An unexpected robot policy: Early evaluations of GPT-6 Astra on RoboDojo and beyond. arXiv preprint arXiv:2609.24170, 2026. [39] Yixian Zhang, Huanming Zhang, Feng Gao, Xiao Li, Zhihao Liu, Yi Nie, Chunyang Zhu, Jiaxing Qiu, Yuchen Yan, Jiyuan Liu, Wenhao Tang, Jiaji Rao, Zhengru Fang, Changxu Wei, Yu Wang, Wenbo Ding, and Chao Yu. Harness VLA: Steering frozen VLAs into reliable manipulation primitives via memory-guided agents. arXiv preprint arXiv:2607.08448, 2026. 17

Related documents

• Replicate What Varies: Resource Sharing for Domain-Randomized Embodied Simulation#1456405
• LogicEnvGen: Task-Logic Driven Generation of Diverse Simulated Environments for Embodied AI#1117305
• From Failures to Learnable Worlds: Policy-Conditioned Environment Generation for Navigation Agents#1345243
• RoboPhys-3D: A Comprehensive Embodied World Model Evaluation via 3D Reconstruction#792966
• RoboPhys-3D: A Comprehensive Embodied World Model Evaluation via 3D Reconstruction#788962