WorldPager keeps long world-model sessions within memory limits
WorldPager: Zero-Stall Tiered Memory for Long-Horizon World Models on a Single Consumer GPU · arXiv:2610.35529
In plain words
Interactive world models keep information from earlier video so a place can look familiar when the camera returns. That memory can fill a computer's host memory, even when the drive could move it fast enough between chunks.
WorldPager is software that stores this memory across GPU memory, host memory and an SSD, and stages it before it is needed. In one 3,000-chunk MG2 session, it generated 37.5 minutes of video without growing beyond its 32 GiB host-memory budget. This was one setup, and it ran slower than real-time playback.
The research
An interactive world model needs to retain earlier chunks so places can look consistent when revisited. Yet on a single consumer machine, that growing memory can fill host memory, while the model's own positional limit can stop generation even if memory remains available. Can a system keep such a session going within those limits?
WorldPager spreads retrieved world-model memory across GPU, host memory and NVMe, staging it ahead of use to extend sessions on one machine.
How can an interactive world model keep generating when its memory fills host RAM and its position table also imposes a limit? On the tested machine, MG2's host memory held 45 seconds of bf16 memory or 2.8 minutes in int4, and its original position table stopped generation at about 4.3 minutes.
WorldPager stages retrieved memory from NVMe while the preceding chunk is generated. When all retrieved blocks were forced to come from NVMe, its median wait stayed at zero down to 0.25 GB/s on one MG2 trajectory, while on-demand loading stalled at every tested bandwidth.
With the full system enabled, one session generated 37.5 minutes of video within the 32 GiB host-memory budget.
The 37.5-minute result comes from one session on one RTX 4090 with a 32 GiB host-memory budget and one NVMe drive. Generation ran below the 16-frames-per-second playback rate, and that session did not revisit memory already written to NVMe; separate tests measured those reads. Int4 storage also lowered image-quality scores on long-gap revisits.
What the evidence shows
- Two limits stop sessions
Interactive world models can retrieve information from earlier video chunks to make revisited places look consistent. On the tested machine, Matrix-Game 2.0 (MG2) ran into two different limits: host memory held 45 seconds of bf16 retrieval memory or 2.8 minutes in int4, while its original position table stopped generation after about 4.3 minutes regardless of memory capacity. The question is how to keep a session going within those constraints.
- A runtime manages memory
WorldPager is a memory runtime for interactive world models. It manages where retrieved keys and values from earlier chunks live, placing them in GPU memory, host dynamic random-access memory (DRAM), or an NVMe drive.
The model's retrieval rule still chooses which past chunks to use; WorldPager handles where those chunks are stored and when they move. It also handles positions at inference time to extend generation beyond MG2's original positional horizon.
- Transfers fit the compute window
The design depends on whether moving memory would delay chunk generation. An MG2 chunk took about 1.2 seconds to compute, and a test with real computation found no measured stall when double-buffered transfers moved payloads up to 1.46 GB.
This supports the researchers' diagnosis that the tested workload runs short of total memory capacity before transfer bandwidth becomes its limiting factor.
- Prefetching has a boundary
To test whether staging retrieved memory ahead of use helps, the researchers forced all retrieved blocks to come from NVMe and compared WorldPager with on-demand swap-in, which copies blocks when the next chunk starts. On the a_yaw trajectory, WorldPager's median wait stayed at zero down to 0.25 GB/s of read bandwidth, while on-demand swap-in stalled at every tested bandwidth.
Below the transition, prefetching could stall and its worst waits could exceed the comparison on b1_ws.
- A long run with trade-offs
With the full system enabled, one MG2 session generated 37.5 minutes of video while host memory stayed within its 32 GiB budget. The result shows continuous generation in the tested setup, not real-time playback or a read test of previously spilled chunks.
Separate comparisons found that int4 storage retained consistency on tested long-gap revisits but had lower image-quality scores; a second model supplied system measurements only.
Deep
- Original paper authors
- Bingnan Liu, Ruini Xue
- Submitted to arXiv
- License
- arXiv non-exclusive