🤖 AI

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

Este artigo argumenta que a falha dos atuais modelos de mundo generativos em suportar tarefas de simulação com estado não decorre de limitações arquitetônicas, mas de designs de tempo de execução centrados em requisições que descartam o estado computacional persistente, propondo, em vez disso, um tempo de execução centrado em sessões que possibilite o checkpoint e a restauração quase instantâneos de estado não recomputável para facilitar rollouts de modelos de mundo byte-idênticos e eficientes.

Autores originais: Zhen Lin

Publicado 2026-07-27

📖 8 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Zhen Lin

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está construindo um videogame onde o mundo não apenas segue um roteiro; ele realmente vive. Em um jogo desse tipo, se você se afasta de uma fogueira, o fogo continua queimando. Se você deixa uma bola rolando colina abaixo, ela continua rolando. Este é o sonho dos "modelos de mundo generativos": sistemas de IA que podem simular uma realidade consistente e viva, não apenas gerar imagens bonitas. Mas aqui está o detalhe: para manter este mundo vivo, o computador precisa se lembrar exatamente do que aconteceu, até o menor detalhe, mesmo quando o jogador desvia o olhar e depois olha de volta.

Por muito tempo, os cientistas pensaram que esses modelos de IA estavam falhando porque eram "esquecidos" ou "ruins em lembrar". Eles assumiam que o cérebro da IA simplesmente não era grande o suficiente para conter toda a história. Mas este artigo faz uma pergunta diferente: e se a IA não for o problema? E se o problema for o sistema de computador executando o jogo, que fica jogando fora as notas da IA toda vez que o jogador faz uma pausa? Os autores descobriram que a "memória" que a IA precisa para manter o mundo consistente não é um superpoder mágico; são apenas alguns pedaços específicos de dados que o sistema de computador estava deletando acidentalmente.

O Grande Mistério do "Você Esqueceu?"

No mundo da geração de vídeo por IA, existe um erro frustrante. Você diz à IA para mostrar um gato pulando em uma cama, depois pede para mostrar o gato se afastando. Então, você pede para mostrar o gato pulando de volta na cama. Em um mundo perfeito, o gato deveria pousar exatamente no mesmo lugar, com o mesmo pelo bagunçado da mesma forma. Mas em 2026, quando pesquisadores testaram isso com 14 modelos diferentes (usando um teste chamado MBench) e 23 modelos diferentes (usando WRBench), eles encontraram o mesmo resultado triste: o gato não voltou direito. O mundo havia "derivado". A cama parecia diferente, a posição do gato estava errada e a física parecia quebrada.

Os especialistas olharam para esses mundos quebrados e disseram: "Os modelos de IA são muito fracos. Eles precisam de novos treinamentos, cérebros maiores e módulos de memória especiais para aprender a lembrar." Eles pensavam que o problema estava dentro do céreção do modelo.

Mas os autores deste artigo, liderados por Zhen Lin, decidiram agir como detetives. Eles suspeitavam que o culpado não era o cérebro da IA, mas o sistema de computador que a executa — o "runtime".

O Experimento do Detetive: O Teste de "Viagem no Tempo"

Para provar sua teoria, os pesquisadores montaram um experimento inteligente. Eles pegaram um modelo de IA funcional e deixaram que ele gerasse uma cena. Então, logo antes da cena ficar complicada, eles tiraram um "instantâneo" (snapshot) de duas coisas muito específicas que o computador estava segurando:

A última imagem que a IA viu (armazenada como uma lista simples de números).
O estado do Gerador de Números Aleatórios (RNG). Pense nisso como o lançamento de dados interno da IA. Toda vez que a IA toma uma decisão ou cria um novo detalhe, ela lança um dado digital. Se você não salvar o número exato em que o dado caiu, o próximo lançamento será diferente, e o mundo mudará.

Após tirar esse instantâneo, os pesquisadores forçaram a IA a fazer uma "jornada". Eles a fizeram gerar uma sequência longa e selvagem de eventos — o suficiente para bagunçar completamente qualquer memória "implícita" que a IA pudesse estar tentando manter em sua cabeça. Então, eles pararam a jornada, jogaram fora tudo o que o computador estava segurando e restauraram o instantâneo.

O resultado foi chocante. Quando a IA continuou a partir do instantâneo, o vídeo que ela gerou foi byte a byte idêntico a um vídeo onde a IA nunca havia saído. Foi perfeito. O gato pousou exatamente no mesmo lugar. Os pixels eram idênticos.

Isso provou que a IA podia lembrar de tudo perfeitamente. O problema não era que a IA era esquecida; era que o sistema de computador executando a IA tinha jogado fora as notas (o instantâneo) antes que a IA pudesse usá-las.

A Confusão entre "Requisição" vs. "Sessão"

Por que o computador jogou as notas fora? Acontece que o computador estava seguindo regras projetadas para chatbots (como aqueles com os quais você conversa para fazer o dever de casa). Chatbots funcionam em "requisições". Você faz uma pergunta, o computador responde e, então, ele limpa sua mesa para estar pronto para a próxima pessoa. Isso funciona muito bem para chatbots porque, se eles esquecerem o contexto, o computador pode simplesmente reler suas palavras anteriores para entender.

Mas os modelos de mundo são diferentes. Eles funcionam em "sessões". Uma sessão é uma história contínua. Se você pausa uma história e volta mais tarde, você não quer que o computador releia o livro; você quer que ele retome exatamente de onde parou.

Os autores chamam a peça de dado que falta de Estado Computacional Persistente (PCS). Este é o pequeno e essencial conjunto de coisas que devem ser salvas para manter o mundo consistente.

Para um modelo simples, o PCS é apenas a última imagem e o lançamento de dados (cerca de 1,38 MB).
Para um modelo mais complexo com um "banco de memória", é esse banco mais o lançamento de dados (cerca de 185 KB).
Para um modelo que usa uma "janela" de dados passados, é essa janela mais o lançamento de dados (cerca de 1,67 GB).

O artigo mostra que você não precisa salvar tudo (o que seria enorme e lento). Você só precisa salvar o PCS. E o melhor? Salvar e restaurar esses dados leva apenas 0,012 milissegundos. Isso é cinco ordens de magnitude mais rápido do que o tempo necessário para gerar um único passo do vídeo (1,85 segundos). É praticamente de graça.

A Reviravolta da "Relevância" vs. "Recência"

O artigo também descobriu algo surpreendente sobre como gerenciar essa memória quando o computador fica cheio. Em chatbots, os computadores geralmente usam uma regra de "Recência": eles jogam fora as mensagens mais antigas para abrir espaço para novas. Mas para modelos de mundo, isso é um desastre.

Imagine que você está assistindo a um filme e o computador decide jogar fora a cena de 10 minutos atrás porque ela é "antiga", mantendo apenas a cena de 1 minuto atrás. Se o filme exigir que você se lembre do que aconteceu há 10 minutos para entender o final, o filme quebra.

Os autores testaram diferentes maneiras de gerenciar a memória. Eles descobriram que, para modelos de mundo, você precisa de uma regra de Relevância. Você deve manter as partes da memória que são importantes para o retorno (o momento em que a câmera volta), mesmo que sejam antigas.

Quando o computador foi forçado a ser muito econômico com a memória (apenas 2 MB disponíveis), a regra de "Recência" salvou apenas 6 de 16 mundos.
A regra de "Relevância" salvou todos os 16 mundos.

Isso é uma mudança enorme. Significa que, para manter um mundo vivo, você tem que parar de pensar como um chatbot e começar a pensar como um contador de histórias que sabe quais pontos da trama são mais importantes.

A Grande Conclusão

O artigo conclui que o "esquecimento" dos modelos de mundo de IA não é um erro no cérebro da IA. É um erro na organização do sistema de computador. A IA estava pronta para lembrar; o sistema apenas continuava jogando as notas no lixo.

Ao mudar o sistema para salvar o "Estado Computacional Persistente" (o instantâneo e o lançamento de dados) e ao usar uma maneira mais inteligente de decidir o que manter quando a memória está apertada, os pesquisadores mostraram que:

O mundo pode ser restaurado perfeitamente. A IA pode retornar a um estado exatamente como era antes, mesmo após uma longa jornada.
Não custa quase nada. Salvar este estado leva microssegundos.
Você pode rodar muito mais sessões. Como o computador não precisa manter toda a memória pesada na placa de vídeo super rápida, ele pode armazenar as "notas" no disco rígido comum. Isso significa que uma única placa de vídeo poderia lidar com cerca de 2.300 vezes mais sessões ativas do que antes.

Os autores não apenas encontraram uma maneira de consertar a memória; eles descobriram que o "conserto" era, na verdade, uma mudança simples em como gerenciamos o tempo e o espaço do computador. O mundo não estava perdido; estava apenas esperando para ser retomado.

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

1. Declaração do Problema

Em meados de 2026, benchmarks de larga escala (MBench e WRBench) estabeleceram que modelos de mundo de vídeo generativos falham em manter a consistência através de "excursões de viewpoint" (ex: uma câmera se afastando e retornando a uma cena). Quando um modelo é solicitado a retomar uma trajetória após uma pausa ou um desvio, a cena retornada frequentemente não corresponde à configuração anterior, e objetos que saíram de vista não retornam de forma consistente.

O diagnóstico predominante no campo atribui essa falha ao próprio modelo, sugerindo que as arquiteturas atuais carecem da necessária "memória do que" para registrar mudanças ocultas ou que os objetivos de treinamento falham em supervisionar a persistência de pontos finais. Consequentemente, os remédios propostos envolvem mudanças arquiteturais caras, novos módulos de memória e retreinamento em larga escala.

O Contra-Diagnóstico do Artigo:
Este artigo argumenta que, para uma classe significativa de modelos, o diagnóstico é incompleto e frequentemente errado. A falha não é uma falta de capacidade dentro do modelo, mas sim uma falha de runtime: a camada de serviço descarta o estado não-recomputável necessário para continuar o mundo. O serving generativo moderno é "centrado no request", recuperando o estado em limites de requisição com base na suposição (herdada do serving de LLMs) de que todo estado útil é recomputável. Essa suposição é falsa para modelos de mundo porque o estado deles carrega um kernel não-recomputável (ex: o fluxo do Gerador de Números Aleatórios ou ativações de memória recorrente) que não pode ser reconstruído rodando novamente os inputs. Quando esse estado é descartado, o mundo é perdido, não porque o modelo não consiga gerá-lo, mas porque o runtime jogou fora a semente (seed).

2. Metodologia e Abstração Central

O Experimento de Restauração

Os autores conduzem um experimento construtivo para refutar a hipótese de "déficit do modelo". Eles pegam um modelo de mundo, geram um rollout e capturam snapshots de objetos de runtime específicos (observação, estado do RNG ou bancos de memória). Em seguida, conduzem o modelo através de uma excursão genuína (destruindo a continuidade implícita), restauram o snapshot e continuam.

Resultado: A continuação é byte-idêntica a uma trajetória que nunca saiu (similaridade DINOv2 1.0, erro de pixel 0.0).
Ablação: Remover o RNG do snapshot degrada o resultado, provando que o snapshot é "load-bearing" (essencial para a carga) e não é ignorado.
Conclusão: A capacidade existia; o runtime descartou o estado necessário.

Estado Computacional Persistente (PCS)

O artigo define o Estado Computacional Persistente (PCS) como o conjunto mínimo de estado não-recomputável que deve sobreviver entre requisições para garantir a continuação semântica.

Definição Formal: $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 ϵ}$
- Onde $S$ é um subconjunto do estado completo de runtime $H$ , $D$ é uma métrica de distância semântica e $\epsilon$ é uma tolerância (0 para exatidão de bits).
Propriedades:
1. Minimalidade: Nenhum subconjunto próprio é suficiente; cada elemento é essencial.
2. Recuperabilidade: O complemento $H \setminus PCS$ é derivável (recomputável) e não precisa ser armazenado.
3. Dependência do Modelo: A composição do PCS varia conforme a arquitetura (ex: observação plana + RNG para modelos Markovianos vs. bancos de memória crescentes para modelos não-Markovianos).

O Contrato de PCS

O artigo especifica um contrato para um runtime centrado em sessão:

API: checkpoint(s), restore(c), fork(c), delete(c).
Invariantes:
- Round-trip: A restauração produz um estado semanticamente equivalente ao original.
- Durabilidade: Checkpoints sobrevivem à morte do processo e a fronteiras entre processos.
- Independência de Fork: Continuações filhas são semanticamente independentes das mães.
- Completude do Snapshot: O checkpoint captura exatamente o PCS e nada que seja derivável.

Descoberta por Medição (Fingerprinting)

Em vez de projetar listas de estado manualmente, o artigo propõe um Procedimento de Fingerprinting agnóstico ao modelo:

Teste de Necessidade: Ablar sistematicamente buffers de runtime. Se a remoção de um buffer degradar a métrica de consistência de retorno além da tolerância, ele é "necessário".
Teste de Suficiência: Restaurar apenas o conjunto necessário. Se a métrica estiver dentro da tolerância, este conjunto é o PCS.
Fallback de Redundância: Lidar com buffers correlacionados via seleção gulosa.
Este procedimento descobre automaticamente composições de PCS estruturalmente diferentes (planas, crescentes ou de janela) para diferentes classes de modelos sem suposições arquiteturais.

Runtime Centrado em Sessão

Os autores constroem um runtime onde a unidade de serving é uma sessão, não um request.

Arquitetura: A GPU mantém uma sessão ativa; todos os outros estados de PCS residem no host (memória CPU).
Política de Evicção: Ao contrário dos LLMs que evictam por recência (LRU), os modelos de mundo exigem evicção baseada em relevância. Frames relevantes para o "retorno" (a âncora) devem ser mantidos, enquanto frames recentes da excursão podem ser descartados.
Validação: Um Teste de Conformidade de Consistência de Retorno é utilizado. Diferente da exatidão de bits (que pode passar com o estado errado), este teste verifica se o mundo restaurado é semanticamente consistente com a âncora, rejeitando mundos "plausíveis, mas desviados".

3. Resultados Principais

Configuração Experimental

Avaliado em três classes distintas de modelos usando uma única GPU A800:

Cosmos3-Nano: Markoviano, condicionado por ação com difusão.
WorldMem: Não-Markoviano com um banco de memória explícito.
Matrix-Game 2.0: Causal-difusão autorregressiva com contexto KV endereçável.

Performance e Escalonamento

Restauração Byte-Exata: Todos os três modelos alcançaram continuações bit-idênticas (ou latentes-exatas para Matrix-Game) após restauração entre processos, confirmando a "Hipótese de Descarte de Runtime".
Custo: Operações de checkpoint/restore levam ~0.012 ms, o que é cinco ordens de magnitude mais rápido que um passo de geração (1.85 s). O gerenciamento de estado consome ~0.00035% do tempo de execução (wall time).
Escalonamento de Sessão:
- Memória do Dispositivo: Permanece constante (~4.7 GB) independentemente do número de sessões, pois apenas uma sessão está residente.
- Memória do Host: Escala linearmente com as sessões.
- Capacidade: Um runtime centrado em sessão pode suportar ~2.300× mais sessões residentes do que um runtime centrado em request (que deve manter o working set de cada sessão no dispositivo).
Eficiência de Evicção: Sob pressão de memória, a evicção baseada em relevância (mantendo frames âncora) supera significativamente a evicção baseada em recência (LRU). Em orçamentos apertados, a retenção baseada em relevância preservou 16/16 mundos, enquanto o LRU preservou apenas 6/16.
Cargas de Trabalho de Planner: Em um cenário de planejador Monte-Carlo Tree Search (MCTS), a evicção baseada em recência causou o colapso da árvore de busca (orfandade de forks), enquanto a evicção baseada em relevância permitiu que a busca fosse concluída com zero retornos perdidos.

O Que Não Funcionou

Evicção Preditiva: Foi descoberto que encolher sessões precocemente (antes dos binds de memória) é monotonicamente pior do que a evicção reativa, pois empurra as sessões para seu piso de retenção prematuramente, levando a mais descartes posteriormente.
Admissão Preditiva: Recusar sessões baseando-se na demanda projetada foi prejudicial, pois rejeitou mundos que completariam com sucesso sob a baseline reativa.

4. Significância e Alegações

O artigo afirma que a "perda do mundo" em modelos generativos é frequentemente um gap de serving, não um gap do modelo.

Mudança de Paradigma: Argumenta pela mudança da unidade de serving de "request" para "sessão" e pela introdução do Estado Computacional Persistente (PCS) como um primitivo.
Mensurabilidade: Demonstra que o estado mínimo necessário para a persistência pode ser descoberto por medição em vez de assumido ou projetado manualmente.
Corretude vs. Eficiência: Destaca que as suposições padrão de serving de LLM (recomputabilidade) são incorretas para modelos de mundo. Um runtime que depende de cache de recomputação para modelos de mundo retorna um mundo "plausível", mas errado, enquanto um runtime centrado em sessão com PCS retorna o mundo exato.
Modéstia: Os autores declaram explicitamente que não reivindicam universalidade para todas as arquiteturas (ex: modelos de estado latente recorrente não foram testados) e que o resultado de "exatidão" é específico para modelos onde a observação ou o banco de memória captura totalmente o estado visível. Eles também esclarecem que sua contribuição é a abstração e a camada de serving, não a arquitetura do modelo em si.

A conclusão central é que manter o mundo é um primitivo de serving que custa microssegundos, e a falha em fazê-lo é resultado do descarte de estado não-recomputável, não de uma falta de capacidade do modelo.