Reactor har frigivet Open Dreamer, en åben JAX/Flax-implementering af Dreamer 4s world-model-pipeline. To repos og en browserdemo er ude, og træningsopskriften er lagt frem med tal og configs. Det er en samlet pakke: arkitektur, konfigurationer og eval-strenge — ikke bare en teaser.
Nyheden er omfanget: en fuld world-model-pipeline i JAX/Flax med tokenizer, action-betinget dynamics, rollout-format og FVD-scoring. Oveni ligger en Minecraft-demo med en Game ↔ Dream-toggle. Spørgsmålet bliver, hvor langt man kan komme uden åbne checkpoints og klare benchmark-tal. Det er her, læsere skal være skarpe.
Hvad der faktisk blev udgivet
Udgivelsen består af to repos: et træningsrepo med tokenizer, dynamics, rolloutgenerering og FVD-scoring, og et separat lokalt “rollout harness”, der kan lave frames fra en MP4 plus en matchende action-fil. Derudover en browserdemo på Reactors runtime med Game ↔ Dream-knap, der skifter mellem spil og model. Ambitionen er enkel: reproducer Dreamer 4 og undgå metoder uden for papiret, så søgningen holdes smal.
Udviklingen begyndte på CoinRun, et procedurelt 2D-platformspil, der kan trænes på en enkelt GPU, og blev derefter skaleret til Minecraft/VPT-lignende gameplay-video. Først et kontrollerbart miljø. Så et større og mere rodet datasæt.
En fælles rygsøjle
Både tokenizer og dynamics bruger samme block-causal transformer. Modellen skifter mellem to lagtyper: rumlig opmærksomhed inden for en enkelt frame og kausal tidsopmærksomhed på tværs af frames. “Block-causal” betyder, at hvert tidsskridt behandles fuldt internt, og at forbindelsen mellem tidsskridt kun går bagud. Kort sagt: stabil videomodellering uden snyd med tidsretningen.
Rollouts foldes i blokke pr. tidsskridt: forrige action, state og policy. Rumlig opmærksomhed arbejder inde i blokken, kausal tidsopmærksomhed forbinder blokke. Det afgørende designvalg: world-model tokens kan ikke læse agent-token direkte. Mål og policy påvirker kun fremtiden via næste action.
Tokenizeren, ikke en VAE
Tokenizeren er en transformer-baseret Masked Autoencoder, ikke en VAE. Holdet rapporterer cirka 100× kompression uden KL- eller adversarial-loss. Det peger mod enklere træning. Men tjek den perceptuelle kvalitet selv; hurtige skift og teksturer kan give støj i latenter, især uden for spilvideoer.
MAE-tilgangen giver et latentrum, der spiller fint med mål som diffusion forcing og flow matching. Man undgår VAE’ens KL-tryk og GAN-instabilitet, men kan betale med rekonstruktionsartefakter i hjørnetilfælde. Det skal måles i egne domæner, ikke kun på Minecraft-klip.
Dynamics-modellen og træningsopskriften
Dynamics-modellen laver næste-frame-prediktion og trænes med tre greb: diffusion forcing, flow matching og shortcut-/bootstrap-samples. Den forudsiger også næste action, så policy-information bindes til konkrete handlinger i rollouts.
De offentliggjorte Minecraft-configs er konkrete: 1,6 milliarder parametre, 30 block-causal lag, d_model 1920, 30 attention heads, 3 KV-heads (grouped-query). Hvert fjerde lag er tidslag, 32 “register tokens” per tidsskridt. packing_factor=2 pakker nabolatenter fra tokenizeren i ét spatialt dynamics-token. Tidsopmærksomhed kører med et 192-step glidende vindue. Træning i 200.000 steps med Muon og en WSD-schedule, peak learning rate 3e-4, EMA 0,999. Shortcut-samples starter ved step 100.000 på 0,25 af batchen. Meget ligger tæt på Dreamer 4; valg som register tokens, packing og vindueslængde bør efterprøves i andre domæner.
Hurtige fakta
- To repos: træning (tokenizer, dynamics, rollouts, FVD) og et lokalt harness (MP4 + actions).
- Browserdemo: Minecraft-visning med Game ↔ Dream-toggle.
- Backbone: én block-causal transformer til både tokenizer og dynamics, lag der skifter mellem rum og tid.
- Tokenizer: transformer-MAE, rapporteret ~100× kompression, ingen KL/GAN.
- Dynamics: næste-frame, træning med diffusion forcing, flow matching, shortcut; forudsiger også næste action.
Hvor JAX/Flax gør forskellen i praksis
Valget af JAX/Flax handler om fart og skalerbarhed. TPU’er og XLA-kompilering gør store forsøg mere ligetil. På GPU kan man stadig vinde på sharding-mønstre og en ren funktionsstil. CI og reproducerbarhed bliver ofte mindre rodede, når dataflowet er rent og sideeffekter holdes nede.
Åbne configs hjælper også med noget lavpraktisk: budgettering. 200k steps på en 1,6B-model er ikke et weekendprojekt. Forvent uger på en klynge, afhængigt af batch, parallelisering og I/O. Det presser prioritering af data og evals frem.
Arbejdsflows der faktisk ændrer sig
Det lokale harness, der spiser MP4 + actions, er godt til fejlsøgning. Man kan validere tokenisering og forudsigelser på klip uden at køre fuld træning. Det er også en realitetstest: passer action-parsning, er latenterne stabile, hvor opstår glidning. Og det gør demoer ærlige, når man kan genspille præcis samme sekvens igen og igen.
For integrationsarbejde betyder rollout-designet, at planlægning må binde sig op på eksplicitte action-sekvenser. Agentens mål “siver” ikke ind i world-modellen via latenterne; den må vise det gennem næste action. Godt for kontrol — men kræver disciplin i pipelines.
Implementeringsbarrierer, som ikke forsvinder af open source
Compute-kravet er første mur. Selv hvis parametre kan være i hukommelsen, bider aktiver og sekvenslængder. Memory-spikes, sharding-strategier og kompromiser mellem batch, sekvens og throughput skal håndteres. Diffusion-/flow-mål kan give makrostabilitet, men er følsomme for hyperparametre og scheduler-detaljer.
Data er næste mur. Tokeniseringskvalitet driver alt nedstrøms. En rapporteret 100× kompression er stærk, men hvis domænet skifter fra spil til fx industriel video, må latenterne efterprøves på netop det domænes teksturer og bevægelser. Uden gode evals bliver det gæt.
Validering og reproducerbarhed — hvad man bør tjekke
Tjekliste: Findes der publicerede checkpoints, eller skal man træne fra bunden? Ligger FVD-scorer og scripts i repoet, og er de sammenlignet direkte med Dreamer 4-resultater? Er træningslogs, seeds og scripts på plads, så andre kan få samme kurver?
For demoen: er Game ↔ Dream et live generativt takeover per frame, eller et foroptaget spor som fallback? Hvis det ikke fremgår af repo/README, så bed forfatterne bekræfte det. Det ændrer vurderingen af modenhed.
Første skridt for teams, der vil i gang
- Klon træningsrepoet og kør et minimalt CoinRun-setup lokalt. Start med korte sekvenser og lille batch for at validere dataflowet, før der skrues op.
- Kør tokenizeren på egne klip. Mål kompression vs. kvalitet (fx LPIPS/SSIM) og kig manuelt efter artefakter i hurtige bevægelser.
- Kør FVD-scripts på samme datasplit som i repoet. Gem seeds, commit-hash og nøjagtige parametre for reproduktion.
- Test det lokale rollout-harness på en kort MP4 + actions, så action-parsing og tidsstempler bekræftes, før der bruges cluster-timer.
- Tjek licensfilen i hvert repo, før kode flyttes ind i CI/CD. Uafklaret licens koster tid senere.
Sikkerhed og styring, kort og konkret
World-models kan generalisere uventet. En planlagt sekvens kan glide, hvis modellen “tror” miljøet gør noget andet. Praktisk råd: styr adgang til stærke rollouts, log afvigelser mellem simuleret og faktisk forløb, og hold licenser, datakilder og eval-metrics i orden. Det er driftshåndværk: hvem må hvad, og hvordan fanges fejl.
Licensen er afgørende for virksomhedsbrug. Uden en klar, permissiv licens bliver adoption langsom. Er der kommercielle begrænsninger, eller er det MIT/Apache-åbent? Det bør stå tydeligt i README.
Hvad der mangler svar på
Åbne spørgsmål, der bør lukkes: findes der offentlige checkpoints, og i givet fald hvilke? Er FVD-resultater publiceret side om side med Dreamer 4s tal? Er eval-scripts komplette, inklusive reference-seeds? Hvilken licens gælder præcist for de to repos? Og for demoen: kører den live på Reactor-runtime med ægte frame-handover, eller er der fallback med foroptagede sekvenser?
For træning på CoinRun vs. Minecraft: kan en enkelt-GPU-opsætning reelt køre CoinRun-eksperimenterne som beskrevet, eller kræves der særlige data-/parse-trin, der ikke er standard? Små praktiske hager bremser teams hurtigere end store algoritmer.
Hvad det betyder i virksomhedernes hverdag
Har man TPU-klynger, er JAX/Flax en genvej til store eksperimenter uden at vride frameworket. På GPU-siden kan man læne sig op ad XLA-fusioner og velbeskrevet parallelisering. Det kan flytte en prototype til et målbart PoC på uger frem for kvartaler.
World-models rækker ud over spil: simulering af visuelle miljøer, kvalitetskontrol via syntetiske fejlscenarier og predictive maintenance ved at forudsige næste “tilstand” i video/telemetri. Men integrationen kræver disciplin: klare rollouts, robuste evals (FVD er en start, ikke slut) og styring af hvem der må generere og bruge simulerede forløb.
Før du trykker start
Planlæg compute-budget ud fra 1,6B/200k-opsætningen, og lav en forstudie med kortere sekvenser og færre heads. Test tokenizeren på eget domæne: mål kompression vs. LPIPS/SSIM og, vigtigere, downstream-fejl i dynamics. Hold øje med hukommelse — aktiver, ikke kun parametre — og vær klar til at skifte paralleliseringsstrategi undervejs.
Og dokumentér alt: seeds, git-commit, dataudsnit, parserversion. Reproducerbarhed er ikke pynt; det er garantien for, at man kan fejlfinde i morgen, når kurven knækker. Kedeligt papirarbejde, ja. Det sparer uger.
Konklusion
Open Dreamer er et klart udspil: en åben JAX/Flax-reproduktion af Dreamer 4 med arkitektur og opskrift lagt frem. Rygsøjlen hænger sammen, rollout-designet er gennemtænkt, og valget om at lade policy kun påvirke via næste action er fornuftigt. Men der er huller, der bør lukkes, før reproduktionen kan kaldes bevist: checkpoints, FVD-tal op mod originalen og en tydelig licenslinje.
Næste skridt er enkle, men tidskrævende: klon repoet, kør et lokalt rollout på CoinRun, kør FVD-scripts og benchmark mod Dreamer 4-resultaterne. Og tag en snak med forfatterne om licens, checkpoints og demodesign. Man opdager først forskellen, når man sidder med det i hænderne.
