A fleet of autonomous industrial robots does not simply generate log files. It produces continuous multimodal reality streams: camera feeds, LiDAR point clouds, depth data, audio, inertial measurements, and high-frequency joint telemetry. At fleet scale, even compressed sensor streams can accumulate into terabytes or petabytes of data over relatively short periods.

World Models turn this data from passive telemetry into an active training pipeline. The challenge is not merely storing reality, but selecting, organizing, replaying, simulating, and feeding the right physical experiences to accelerators fast enough to learn.

Part 2 established that continuously ingesting every raw sensor stream is itself a wall. Part 5 introduces the next question: even after filtering that stream, how do we decide what physical experience is valuable enough to retain for future learning?

The Data Selection Problem

You absolutely do not want to store everything.

Millions of normal, uneventful frames may provide less incremental learning value than rare or novel events, although they remain important for maintaining coverage of the normal operating distribution. However, a rare event—an unexpected obstacle, a near-collision, actuator saturation, a novel surface, or human intervention—can be extremely valuable.

The objective is not simply to collect unusual events, but to maintain a balanced dataset covering both normal operation and rare behaviors. Therefore, the pipeline must prioritize informative experience, not merely volume. The value of a training sample is not proportional to its size. World Model training becomes a data-selection problem before it becomes a storage problem.

flowchart TD
    Physical["PHYSICAL WORLD"] --> Edge["Edge Data Collection"]
    Edge --> Selection["Selection & Curation (Filter for Events, Novelty, Failures & Coverage)"]
    Selection --> DL["Data Lake"]
    DL --> Sim["Simulation"]
    DL --> Train["Training"]
    Sim --> Train
    Train --> Eval["Evaluation & Safety Validation"]
    Eval --> Deploy["Edge Deployment"]
    Deploy --> Physical

The Storage Hierarchy

Storing reality streams requires a hybrid approach. We need the massive scale of archival storage, combined with the extreme throughput of local NVMe arrays for active training jobs.

Storage Tier Typical Technology Primary Function Cost/Performance Profile
Hot Tier (Training) Local/distributed NVMe, parallel storage Feeding active GPU training clusters with high-throughput, low-latency data access. Extreme cost / Max throughput
Warm Tier (Simulation) Parallel filesystem, high-throughput object Storing recent telemetry & curated datasets for simulation. High cost / High throughput
Cold Tier (Archive) Object storage, archival tiers Archiving long-term historical data. Low cost / High latency

Dataset Provenance and Versioning

At fleet scale, a dataset is more than a collection of sensor files. Each sample needs context: when and where it was captured, which sensors produced it, the robot and software version, the model version running at the time, and what event caused it to be retained.

This provenance becomes essential when a model behaves differently after retraining. Engineers need to trace the behavior back through the dataset, simulation configuration, training run, and deployed model.

World Model infrastructure therefore needs dataset versioning and lineage just as software systems need source control and build provenance. Dataset versioning turns a collection of files into a reproducible training asset.

Feeding the Accelerators

In a traditional data architecture, when a GPU requests a batch of video data for training, the data flows from the storage array to the host CPU, into system RAM, and finally across the PCIe bus into the GPU’s memory.

When dealing with thousands of concurrent video streams, poor data pipelines can leave expensive GPUs underutilized while they wait for data.

To solve this, the industry utilizes technologies like GPU-Direct Storage (GDS).

GDS does not mean the CPU is eliminated entirely; the CPU still handles control, orchestration, and filesystem logic. The goal is to minimize unnecessary CPU-mediated memory copies by enabling data to move efficiently from the storage NIC into GPU memory.

flowchart TD
    subgraph Control["Control Plane"]
        C["Host CPU"]
    end
    
    subgraph DataPath["Storage / Data Path"]
        direction LR
        S["NVMe / Parallel FS"] -->|High-speed I/O path| G["GPU Memory"]
    end
    
    C -.->|"I/O Orchestration"| S

Technologies such as GPUDirect Storage can reduce unnecessary data copies through host memory; RDMA/RoCE may be part of the underlying high-performance data path depending on the storage architecture. By reducing CPU bottlenecks, this architecture maximizes the utilization of the training cluster, ensuring that training workloads can ingest large datasets without leaving expensive accelerators unnecessarily idle.

Re-Simulating Reality

Once the storage bottlenecks are resolved, the true value of the World Model architecture is unlocked: The Simulation Engine.

When an edge robot encounters a physical failure (e.g., slipping on an unknown surface), that exact curated telemetry is flagged and routed to the Warm Tier. The cloud simulator then reconstructs a digital twin of that moment.

Instead of just retraining on the single failure, the simulator can generate large numbers of controlled variations of the scenario:

  • What if the robot was moving 10% faster?
  • What if the surface was slightly less reflective?
  • What if the payload was heavier?

This synthetic data is then routed via high-speed storage into the training cluster, which periodically retrains and evaluates updated model versions. Finally, after rigorous safety validation, the newly learned physics rules are deployed back down to the edge (as discussed in Part 3).

Conclusion

Over this five-part series, we have traced the evolution of AI infrastructure from the edge to the cloud.

The data center is becoming an active part of the Physical AI learning and simulation loop. High-throughput storage, accelerator-aware data movement, simulation infrastructure, and intelligent data curation must operate as one cohesive system.

The storage problem for World Models is not simply about storing more data. It is about turning continuous physical experience into a searchable, curated, simulation-ready training dataset, and moving the right data to accelerators at the right time.

We are no longer just processing data; we are computing reality.