🤖 AI

Persistent Computational State: A Session-Centric Runtime for Generative World Models

This paper argues that the failure of current generative world models to support stateful simulation tasks stems not from architectural limitations but from request-centric runtime designs that discard persistent computational state, proposing instead a session-centric runtime that enables near-instantaneous checkpointing and restoration of non-recomputable state to facilitate efficient, byte-identical world model rollouts.

Original authors: Zhen Lin

Published 2026-07-27

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Zhen Lin

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a video game where the world doesn't just play out a script; it actually lives. In this kind of game, if you walk away from a campfire, the fire keeps burning. If you leave a ball rolling down a hill, it keeps rolling. This is the dream of "generative world models": AI systems that can simulate a consistent, living reality, not just generate pretty pictures. But here's the catch: to keep this world alive, the computer needs to remember exactly what happened, down to the tiniest detail, even when the player looks away and then looks back.

For a long time, scientists thought these AI models were failing because they were "forgetful" or "bad at remembering." They assumed the AI's brain just wasn't big enough to hold the whole story. But this paper asks a different question: What if the AI isn't the problem? What if the problem is the computer system running the game, which keeps throwing away the AI's notes every time the player takes a break? The authors discovered that the "memory" the AI needs to keep the world consistent isn't a magical super-power; it's just a few specific pieces of data that the computer system was accidentally deleting.

The Great "Did You Forget?" Mystery

In the world of AI video generation, there's a frustrating glitch. You tell the AI to show a cat jumping on a bed, then you ask it to show the cat walking away. Then, you ask it to show the cat jumping back on the bed. In a perfect world, the cat should land in the exact same spot, with the same fur ruffled in the same way. But in 2026, when researchers tested this with 14 different models (using a test called MBench) and 23 different models (using WRBench), they found the same sad result: the cat didn't come back right. The world had "drifted." The bed looked different, the cat's position was wrong, and the physics felt broken.

The experts looked at these broken worlds and said, "The AI models are too weak. They need new training, bigger brains, and special memory modules to learn how to remember." They thought the problem was inside the model's brain.

But the authors of this paper, led by Zhen Lin, decided to play detective. They suspected the culprit wasn't the AI's brain, but the computer system running it—the "runtime."

The Detective's Experiment: The "Time-Travel" Test

To prove their theory, the researchers set up a clever experiment. They took a working AI model and let it generate a scene. Then, right before the scene got complicated, they took a "snapshot" of two very specific things the computer was holding:

The last picture the AI saw (stored as a simple list of numbers).
The "Random Number Generator" (RNG) state. Think of this as the AI's internal dice roll. Every time the AI makes a decision or creates a new detail, it rolls a digital die. If you don't save the exact number the die landed on, the next roll will be different, and the world will change.

After taking this snapshot, the researchers forced the AI to go on a "journey." They made it generate a long, wild sequence of events—enough to completely scramble any "implicit" memory the AI might have been trying to hold in its head. Then, they stopped the journey, threw away everything the computer had been holding, and restored the snapshot.

The result was shocking. When the AI continued from the snapshot, the video it generated was byte-for-byte identical to a video where the AI had never left. It was perfect. The cat landed in the exact same spot. The pixels were identical.

This proved that the AI could remember everything perfectly. The problem wasn't that the AI was forgetful; it was that the computer system running the AI had thrown away the notes (the snapshot) before the AI could use them.

The "Request" vs. "Session" Mix-Up

Why did the computer throw the notes away? It turns out, the computer was following rules designed for chatbots (like the ones you talk to for homework). Chatbots work in "requests." You ask a question, the computer answers, and then it clears its desk to be ready for the next person. This works great for chatbots because if you forget the context, the computer can just re-read your previous words to figure it out.

But world models are different. They work in "sessions." A session is a continuous story. If you pause a story and come back later, you don't want the computer to re-read the book; you want it to pick up exactly where it left off.

The authors call the missing piece of data Persistent Computational State (PCS). This is the tiny, essential list of things that must be saved to keep the world consistent.

For a simple model, PCS is just the last picture and the dice roll (about 1.38 MB).
For a more complex model with a "memory bank," it's that bank plus the dice roll (about 185 KB).
For a model that uses a "window" of past data, it's that window plus the dice roll (about 1.67 GB).

The paper shows that you don't need to save everything (which would be huge and slow). You just need to save the PCS. And the best part? Saving and restoring this data takes only 0.012 milliseconds. That is five orders of magnitude faster than the time it takes to generate a single step of the video (1.85 seconds). It's basically free.

The "Relevance" vs. "Recency" Twist

The paper also found something surprising about how to manage this memory when the computer gets full. In chatbots, computers usually use a "Recency" rule: they throw away the oldest messages to make room for new ones. But for world models, this is a disaster.

Imagine you are watching a movie, and the computer decides to throw away the scene from 10 minutes ago because it's "old," keeping only the scene from 1 minute ago. If the movie requires you to remember what happened 10 minutes ago to understand the ending, the movie breaks.

The authors tested different ways to manage memory. They found that for world models, you need a Relevance rule. You should keep the parts of the memory that are important for the return (the moment the camera comes back), even if they are old.

When the computer was forced to be very stingy with memory (only 2 MB available), the "Recency" rule saved only 6 out of 16 worlds.
The "Relevance" rule saved all 16 worlds.

This is a huge shift. It means that to keep a world alive, you have to stop thinking like a chatbot and start thinking like a storyteller who knows which plot points matter most.

The Big Takeaway

The paper concludes that the "forgetfulness" of AI world models isn't a bug in the AI's brain. It's a bug in the computer system's housekeeping. The AI was ready to remember; the system just kept tossing the notes in the trash.

By changing the system to save the "Persistent Computational State" (the snapshot and the dice roll) and by using a smarter way to decide what to keep when memory is tight, the researchers showed that:

The world can be restored perfectly. The AI can return to a state exactly as it was before, even after a long journey.
It costs almost nothing. Saving this state takes microseconds.
You can run way more sessions. Because the computer doesn't have to keep the whole heavy memory on the super-fast graphics card, it can store the "notes" on the regular hard drive. This means a single graphics card could handle about 2,300 times more active sessions than before.

The authors didn't just find a way to fix the memory; they found that the "fix" was actually a simple change in how we manage the computer's time and space. The world wasn't lost; it was just waiting to be picked up.

Technical Summary: Persistent Computational State for Generative World Models

1. Problem Statement

By mid-2026, large-scale benchmarks (MBench and WRBench) have established that generative video world models fail to maintain consistency across "viewpoint excursions" (e.g., a camera moving away and returning to a scene). When a model is asked to resume a trajectory after a pause or a fork, the returned scene often fails to match the prior configuration, and objects that left the view do not return consistently.

The prevailing diagnosis in the field attributes this failure to the model itself, suggesting that current architectures lack the necessary "what-memory" to record hidden changes or that training objectives fail to supervise endpoint persistence. Consequently, proposed remedies involve expensive architectural changes, new memory modules, and large-scale retraining.

The Paper's Counter-Diagnosis:
This paper argues that for a significant class of models, the diagnosis is incomplete and often wrong. The failure is not a lack of capability within the model, but a runtime failure: the serving layer discards the non-recomputable state required to continue the world. Modern generative serving is "request-centric," reclaiming state at request boundaries based on the assumption (inherited from LLM serving) that all useful state is recomputable. This assumption is false for world models because their state carries a non-recomputable kernel (e.g., the Random Number Generator stream or recurrent memory activations) that cannot be reconstructed by re-running inputs. When this state is discarded, the world is lost, not because the model cannot generate it, but because the runtime threw away the seed.

2. Methodology and Core Abstraction

The Restore Experiment

The authors conduct a constructive experiment to disprove the "model deficit" hypothesis. They take a world model, generate a rollout, and snapshot specific runtime objects (observation, RNG state, or memory banks). They then drive the model through a genuine excursion (destroying implicit continuity), restore the snapshot, and continue.

Result: The continuation is byte-identical to a trajectory that never left (DINOv2 similarity 1.0, pixel error 0.0).
Ablation: Removing the RNG from the snapshot degrades the result, proving the snapshot is "load-bearing" and not ignored.
Conclusion: The capability existed; the runtime discarded the necessary state.

Persistent Computational State (PCS)

The paper defines Persistent Computational State (PCS) as the minimal set of non-recomputable state that must survive across requests to guarantee semantic continuation.

Formal Definition: $PCS(M) = \arg \min_S \{ |S| : D(restore(S), oracle) \le \epsilon \}$ $P C S (M) = ar g min_{S} {∣ S ∣ : D (r es t or e (S), or a c l e) \leq ϵ}$
- Where $S$ is a subset of the full runtime state $H$ , $D$ is a semantic distance metric, and $\epsilon$ is a tolerance (0 for bit-exactness).
Properties:
1. Minimality: No proper subset suffices; every element is load-bearing.
2. Recoverability: The complement $H \setminus PCS$ is derivable (recomputable) and need not be stored.
3. Model-Dependence: The composition of PCS varies by architecture (e.g., flat observation + RNG for Markovian models vs. growing memory banks for non-Markovian models).

The PCS Contract

The paper specifies a contract for a session-centric runtime:

API: checkpoint(s), restore(c), fork(c), delete(c).
Invariants:
- Round-trip: Restore yields a state semantically equivalent to the original.
- Durability: Checkpoints survive process death and cross-process boundaries.
- Fork Independence: Child continuations are semantically independent of parents.
- Snapshot Completeness: The checkpoint captures exactly PCS and nothing derivable.

Discovery by Measurement (Fingerprinting)

Rather than hand-engineering state lists, the paper proposes a model-agnostic Fingerprinting Procedure:

Necessity Test: Systematically ablate runtime buffers. If removing a buffer degrades the return-consistency metric beyond tolerance, it is "necessary."
Sufficiency Test: Restore only the necessary set. If the metric is within tolerance, this set is the PCS.
Redundancy Fallback: Handle correlated buffers via greedy selection.
This procedure automatically discovers structurally different PCS compositions (flat, growing, or windowed) for different model classes without architectural assumptions.

Session-Centric Runtime

The authors build a runtime where the unit of serving is a session, not a request.

Architecture: The GPU holds one active session; all other sessions' PCS resides on the host (CPU memory).
Eviction Policy: Unlike LLMs which evict by recency (LRU), world models require relevance-keyed eviction. Frames relevant to the "return" (the anchor) must be kept, while recent frames from the excursion can be dropped.
Validation: A Return-Consistency Conformance Test is used. Unlike bit-exactness (which can pass on the wrong state), this test verifies that the restored world is semantically consistent with the anchor, rejecting "plausible but drifted" worlds.

3. Key Results

Experimental Setup

Evaluated on three distinct model classes using a single A800 GPU:

Cosmos3-Nano: Markovian, action-conditioned diffusion.
WorldMem: Non-Markovian with an explicit memory bank.
Matrix-Game 2.0: Autoregressive causal-diffusion with addressable KV context.

Performance and Scaling

Byte-Exact Restoration: All three models achieved bit-identical continuations (or latent-exact for Matrix-Game) after cross-process restore, confirming the "Runtime-Discard Hypothesis."
Cost: Checkpoint/restore operations take ~0.012 ms, which is five orders of magnitude faster than a generation step (1.85 s). State management consumes ~0.00035% of wall time.
Session Scaling:
- Device Memory: Remains constant (~4.7 GB) regardless of session count because only one session is resident.
- Host Memory: Scales linearly with sessions.
- Capacity: A session-centric runtime can support ~2,300× more resident sessions than a request-centric runtime (which must keep every session's working set on the device).
Eviction Efficiency: Under memory pressure, relevance-keyed eviction (keeping anchor frames) significantly outperforms recency-based (LRU) eviction. At tight budgets, relevance-based retention preserved 16/16 worlds, while LRU preserved only 6/16.
Planner Workloads: In a Monte-Carlo Tree Search (MCTS) planner scenario, recency-based eviction caused the search tree to collapse (orphaning forks), while relevance-based eviction allowed the search to complete with zero lost returns.

What Did Not Work

Predictive Eviction: Shrinking sessions early (before memory binds) was found to be monotonically worse than reactive eviction, as it pushes sessions to their retention floor prematurely, leading to more drops later.
Predictive Admission: Refusing sessions based on projected demand was harmful, as it rejected worlds that would have completed successfully under the reactive baseline.

4. Significance and Claims

The paper claims that the "loss of the world" in generative models is often a serving gap, not a model gap.

Paradigm Shift: It argues for moving the unit of serving from "request" to "session" and introducing Persistent Computational State (PCS) as a primitive.
Measurability: It demonstrates that the minimal state required for persistence can be discovered by measurement rather than assumed or hand-engineered.
Correctness vs. Efficiency: It highlights that standard LLM serving assumptions (recomputability) are incorrect for world models. A runtime that relies on recompute-caching for world models returns a "plausible" but wrong world, whereas a session-centric runtime with PCS returns the exact world.
Modesty: The authors explicitly state they do not claim universality for all architectures (e.g., recurrent latent-state models were not tested) and that the "exactness" result is specific to models where the observation or memory bank fully captures the visible state. They also clarify that their contribution is the abstraction and serving layer, not the model architecture itself.

The core conclusion is that keeping the world is a serving primitive costing microseconds, and the failure to do so is a result of discarding non-recomputable state, not a lack of model capacity.