Resumen Técnico: Estado Computacional Persistente para Modelos de Mundo Generativos

1. Declaración del Problema

Para mediados de 2026, los benchmarks a gran escala (MBench y WRBench) han establecido que los modelos de mundo de video generativos fallan al mantener la consistencia a través de "excursiones de punto de vista" (por ejemplo, una cámara que se aleja de una escena y luego regresa a ella). Cuando se le pide a un modelo que reanude una trayectoria tras una pausa o una bifurcación, la escena devuelta suele no coincidir con la configuración previa, y los objetos que salieron de la vista no regresan de manera consistente.

El diagnóstico predominante en el campo atribuye este fallo al modelo mismo, sugiriendo que las arquitecturas actuales carecen de la necesaria "memoria de qué" para registrar cambios ocultos o que los objetivos de entrenamiento no supervisan la persistencia de los puntos finales. En consecuencia, los remedios propuestos implican cambios arquitectónicos costosos, nuevos módulos de memoria y un reentrenamiento a gran escala.

El Contra-Diagnóstico del Artículo:
Este artículo argumenta que, para una clase significativa de modelos, el diagnóstico es incompleto y a menudo erróneo. El fallo no es una falta de capacidad dentro del modelo, sino un fallo de tiempo de ejecución (runtime failure): la capa de servicio descarta el estado no recomputable necesario para continuar el mundo. El servicio moderno de modelos generativos es "centrado en la solicitud" (request-centric), reclamando el estado en los límites de cada solicitud basándose en la suposición (heredada del servicio de LLMs) de que todo estado útil es recomputable. Esta suposición es falsa para los modelos de mundo porque su estado conlleva un núcleo no recomputable (por ejemplo, el flujo del Generador de Números Pseudoaleatorios o las activaciones de la memoria recurrente) que no puede reconstruirse ejecutando nuevamente los inputs. Cuando este estado se descarta, el mundo se pierde, no porque el modelo no pueda generarlo, sino porque el runtime tiró la semilla.

2. Metodología y Abstracción Central

El Experimento de Restauración

Los autores llevan a cabo un experimento constructivo para refutar la hipótesis del "déficit del modelo". Toman un modelo de mundo, generan un despliegue (rollout), y capturan una instantánea (snapshot) de objetos específicos del tiempo de ejecución (observación, estado del RNG o bancos de memoria). Luego, conducen al modelo a través de una excursión genuina (destruyendo la continuidad implícita), restauran la instantánea y continúan.

• Resultado: La continuación es idéntica en bytes a una trayectoria que nunca se había ido (similitud DINOv2 1.0, error de píxel 0.0).
• Ablación: Eliminar el RNG de la instantánea degrada el resultado, demostrando que la instantánea es "de carga" (load-bearing) y no es ignorada.
• Conclusión: La capacidad existía; el runtime descartó el estado necesario.

Estado Computacional Persistente (PCS)

El artículo define el Estado Computacional Persistente (PCS) como el conjunto mínimo de estado no recomputable que debe sobrevivir a través de las solicitudes para garantizar la continuación semántica.

• Definición Formal: $PCS(M) = \arg \min_S \{ |S| : D(restore(S), oracle) \le \epsilon \}$
  • Donde $S$ es un subconjunto del estado completo de ejecución $H$, $D$ es una métrica de distancia semántica, y $\epsilon$ es una tolerancia (0 para exactitud de bits).
• Propiedades:
  1. Minimalidad: Ningún subconjunto propio es suficiente; cada elemento es de carga.
  2. Recuperabilidad: El complemento $H \setminus PCS$ es derivable (recomputable) y no necesita ser almacenado.
  3. Dependencia del Modelo: La composición del PCS varía según la arquitectura (por ejemplo, observación plana + RNG para modelos Markovianos frente a bancos de memoria crecientes para modelos no Markovianos).

El Contrato PCS

El artículo especifica un contrato para un runtime centrado en sesiones:

• API: checkpoint(s), restore(c), fork(c), delete(c).
• Invariantes:
  • Ida y vuelta (Round-trip): La restauración produce un estado semánticamente equivalente al original.
  • Durabilidad: Los checkpoints sobreviven a la muerte del proceso y a los límites entre procesos.
  • Independencia de Bifurcación (Fork Independence): Las continuaciones hijas son semánticamente independientes de las matrices.
  • Completitud de la Instantánea: El checkpoint captura exactamente el PCS y nada que sea derivable.

Descubrimiento por Medición (Fingerprinting)

En lugar de diseñar manualmente listas de estados, el artículo propone un Procedimiento de Fingerprinting agnóstico al modelo:

1. Prueba de Necesidad: Ablar sistemáticamente los buffers de ejecución. Si eliminar un buffer degrada la métrica de consistencia de retorno más allá de la tolerancia, este es "necesario".
2. Prueba de Suficiencia: Restaurar solo el conjunto necesario. Si la métrica está dentro de la tolerancia, este conjunto es el PCS.
3. Fallback de Redundancia: Manejar buffers correlacionados mediante selección codiciosa (greedy selection).
   Este procedimiento descubre automáticamente composiciones de PCS estructuralmente diferentes (planas, crecientes o de ventana) para distintas clases de modelos sin suposiciones arquitectónicas.

Runtime Centrado en Sesiones

Los autores construyen un runtime donde la unidad de servicio es una sesión, no una solicitud.

• Arquitectura: La GPU mantiene una sesión activa; el PCS de todas las demás sesiones reside en el host (memoria CPU).
• Política de Evicción: A diferencia de los LLMs que evictan por recencia (LRU), los modelos de mundo requieren una evicción basada en la relevancia. Los frames relevantes para el "regreso" (el ancla) deben mantenerse, mientras que los frames recientes de la excursión pueden descartarse.
• Validación: Se utiliza una Prueba de Conformidad de Consistencia de Retorno. A diferencia de la exactitud de bits (que puede pasar con el estado incorrecto), esta prueba verifica que el mundo restaurado es semánticamente consistente con el ancla, rechazando mundos "plausibles pero desviados".

3. Resultados Clave

Configuración Experimental

Evaluado en tres clases distintas de modelos utilizando una única GPU A800:

1. Cosmos3-Nano: Markoviano, con difusión condicionada por acción.
2. WorldMem: No Markoviano con un banco de memoria explícito.
3. Matrix-Game 2.0: Difusión causal autorregresiva con contexto KV direccionable.

Rendimiento y Escalamiento

• Restauración Idéntica en Bytes: Los tres modelos lograron continuaciones idénticas en bytes (o latentes exactas para Matrix-Game) tras una restauración entre procesos, confirmando la "Hipótesis de Descarte del Runtime".
• Costo: Las operaciones de checkpoint/restore toman ~0.012 ms, lo cual es cinco órdenes de magnitud más rápido que un paso de generación (1.85 s). La gestión del estado consume ~0.0003s% del tiempo de ejecución (wall time).
• Escalamiento de Sesiones:
  • Memoria de Dispositivo: Permanece constante (~4.7 GB) independientemente del número de sesiones, porque solo una sesión reside en ella.
  • Memoria de Host: Escala linealmente con las sesiones.
  • Capacidad: Un runtime centrado en sesiones puede soportar ~2,300 veces más sesiones residentes que un runtime centrado en solicitudes (que debe mantener el working set de cada sesión en el dispositivo).
• Eficiencia de Evicción: Bajo presión de memoria, la evicción basada en la relevancia (mantener los frames ancla) supera significativamente a la evicción basada en la recencia (LRU). En presupuestos ajustados, la retención basada en la relevancia preservó 16/16 mundos, mientras que LRU preservó solo 6/16.
• Cargas de Trabajo de Planificadores: En un escenario de planificador de búsqueda en árbol de Monte Carlo (MCTS), la evicción basada en la recencia causó el colapso del árbol de búsqueda (orfandad de bifurcaciones), mientras que la evicción basada en la relevancia permitió completar la búsqueda con cero pérdidas en el regreso.

Lo que No Funcionó

• Evicción Predictiva: Se encontró que reducir las sesiones prematuramente (antes de que los vínculos de memoria se establezcan) fue monótonamente peor que la evicción reactiva, ya que empuja las sesiones a su piso de retención prematuramente, provocando más caídas más adelante.
• Admisión Predictiva: Rechazar sesiones basadas en la demanda proyectada fue perjudicial, ya que rechazaba mundos que habrían completado con éxito bajo la línea base reactiva.

4. Significado y Reivindicaciones

El artículo afirma que la "pérdida del mundo" en modelos generativos es a menudo un vacío de servicio, no un vacío del modelo.

• Cambio de Paradigma: Argumenta que se debe pasar de la unidad de servicio de "solicitud" a "sesión" e introducir el Estado Computacional Persistente (PCS) como un primitivo.
• Medibilidad: Demuestra que el estado mínimo requerido para la persistencia puede ser descubierto mediante la medición en lugar de ser asumido o diseñado a mano.
• Corrección vs. Eficiencia: Destaca que las suposiciones estándar de servicio de LLM (recomputabilidad) son incorrectas para los modelos de mundo. Un runtime que depende del caché de recomputación para los modelos de mundo devuelve un mundo "plausible" pero erróneo, mientras que un runtime centrado en sesiones con PCS devuelve el mundo exacto.
• Modestia: Los autores declaran explícitamente que no pretenden la universalidad para todas las arquitecturas (por ejemplo, no se probaron modelos de estado latente recurrente) y que el resultado de "exactitud" es específico para modelos donde la observación o el banco de memoria captura totalmente el estado visible. También aclaran que su contribución es la abstracción y la capa de servicio, no la arquitectura del modelo en sí.

La conclusión central es que mantener el mundo es un primitivo de servicio que cuesta microsegundos, y el fallo al hacerlo es el resultado de descartar el estado no recomputable, no una falta de capacidad del modelo.