AlayaLab/Evoke: a three-step, CFG-free interactive world model

What EVOKE solves that windowed video models do not

Most autoregressive video models carry the past in the denoiser's context window. The longer the session, the more frames sit in that window, and memory grows with it. EVOKE moves scene geometry out of the context and into an external, camera-indexed world state bank. Only what the current view needs is retrieved. The README states that context therefore stays bounded however long the session runs, which is the project's central claim.

The second problem is interactivity. Diffusion samplers usually need many steps plus classifier-free guidance, which means two forward passes per step. EVOKE is described as a three-step, CFG-free model: one forward per step, not two. The README quotes 1.5 s of 384x640 video every 2.11 s on a single H200.

The intended user is a researcher or an engineer building interactive world models, camera-controllable video generation, or long-horizon supervision pipelines. This is not a tool for someone who wants to type a prompt into a hosted API.

The chunk layout and the three memory tiers

The student model is autoregressive over latent chunks, with `latent_window_size = 9`. Each chunk is laid out along the RoPE frame index in a fixed order: `prefix | long(16) | mid(2) | warp(W) | prev_short(1) | noise(W)`.

The `prefix` tier is the frame-0 global anchor. In i2v mode that is the input image; in v2v mode it is the first latent of the reference video. The `long` and `mid` tiers are a multi-term parametric memory, configured as `history_sizes = [16, 2, 1]`, and they use coarser patch kernels: long at `(4,8,8)`, mid at `(2,4,4)`, and everything else at `(1,2,2)`. The coarse kernels are what keep the memory cheap to attend over.

The `warp` tier is the world state bank rendered into the current view. Because it is camera-indexed and retrieved per view rather than accumulated, the bank does not have to be re-encoded into the context on every chunk. The `prev_short` tier holds one latent from the immediately preceding chunk, which is what stops visible seams between chunks.

One constraint worth noting: the README says the engine forbids combining warp with t2v. Text-only conditioning has no camera track, so there is nothing to render the bank into.

Installing EVOKE and running a first inference

The repository ships a `requirements.txt` pinned to the environment the weights were trained and evaluated in: CUDA 12.4 on H200. The file is explicit that torch and deepspeed are load-bearing, not aspirational. Torch 2.4 is required because the attention path assumes 2.4 SDPA semantics, and deepspeed 0.14.5 is required because `train_evoke.py` interleaves manual gradient reduction against that version's ZeRO-2 internals.

Torch and torchvision carry a `+cu124` local version, so the file instructs you to install them from the CUDA 12.4 index first:

pip install torch==2.4.0 torchvision==0.19.0 --index-url https://download.pytorch.org/whl/cu124
pip install -r requirements.txt

Weights come from Hugging Face, at `AlayaLab/Evoke` for the base model and `AlayaLab/Evoke-Turbo` for the distilled one. The README does not spell out a download command, so check the model cards before assuming a layout.

Once weights are in place, the bundled examples under `examples/` are enough to run inference without an external dataset. A four-chunk v2v rollout is one command:

MODE=v2v NUM_CHUNKS=4 bash scripts/inference/infer_post_distill.sh

The `MODE` variable also accepts `i2v` and `t2v`. The README notes that t2v produces 140 frames for four chunks while the other modes produce 141, because t2v has no camera conditioning and therefore no warp chunk. If you want to see mid-rollout re-prompting, the segment schedule switches the prompt at chunk 3 of 6:

MODE=segment NUM_CHUNKS=6 MAX_CASES=0 bash scripts/inference/infer_post_distill.sh

The two non-distilled models have their own launchers, `scripts/inference/infer_stage1.sh` and `scripts/inference/infer_evoke_teacher.sh`. Both are sampled at 50 steps with CFG 5.0, so expect them to be far slower than the distilled path.

Where EVOKE is the wrong tool

The hardware floor is the first real limitation. The README's headline throughput figure is measured on a single H200, and the newer interactive UI figure is measured on five H200 GPUs. Nothing in the repository suggests a smaller-GPU path, and the pinned CUDA 12.4 environment rules out older driver stacks.

The dependency pins are aggressive in a way that will bite in shared environments. `diffusers==0.39.0.dev0` and `safetensors==0.8.0rc0` are pre-release versions, and `transformers==5.3.0` is far ahead of what most other projects in the same virtualenv will expect. If you need EVOKE to coexist with a stable diffusion pipeline or an existing training stack, plan on a separate environment. The requirements file itself explains why the pins are tight: a resolver was previously free to drop or float packages like `pyyaml`, `scipy`, `pandas`, `torchdata` and `triton` that first-party code imports directly.

There is also a configuration gap. The README documents conditioning modes and the chunk layout, but it does not document rollback, checkpoint resumption, or how to recover a partially written session. If your use case depends on resuming an interrupted long rollout, verify that behaviour in the code before designing around it. And if you want a hosted text-to-video service, this is the wrong layer entirely: it is a research implementation with launcher scripts.

How EVOKE differs from a standard diffusion video pipeline

A conventional approach in this space is a multi-step diffusion model with classifier-free guidance, sampled frame by frame or chunk by chunk with the history kept in the attention context. EVOKE's own `stage1_camera_control` model is exactly that: the README describes it as the multi-step model that precedes distillation, sampled at 50 steps with CFG 5.0 like an ordinary diffusion model.

The difference is threefold. First, step count: three steps versus fifty. Second, guidance: EVOKE is CFG-free, so each step is one forward pass rather than two, which roughly halves per-step cost before the step-count reduction is even counted. Third, and most structurally, memory: a context-window model pays for session length in attention cost, while EVOKE pays a fixed retrieval cost against the state bank.

The teacher model is the other comparison point. `evoke_teacher` is a dual-expert DMD teacher sampled directly at 50 steps with CFG 5.0, and it takes no camera conditioning. The README says the teacher was rebuilt for the long horizon using chunk-wise grouping, distant-frame retrieval, and a linear-attention global state, so its memory and compute grow linearly. That linear growth is what the README credits for making 30 s self-forced supervision affordable during training. The student inherits the long-horizon behaviour but not the linear cost.

Maintenance, licensing, and what a fork costs you

The repository is not archived, and the last push was on 2026-09-12, five days before this writing. The news section shows a steady cadence through August and September 2026: Day 0 on 2026-08-14, the Director Web UI on 2026-08-30, Evoke-Turbo on 2026-09-11, and the interactive UI plus inference optimizations on 2026-09-12. There are no tagged releases retrieved, so upgrades happen by pulling `main`.

That has a practical consequence. Without versioned releases, the only upgrade signal is the commit history and the requirements file. If a pin changes, you find out by diffing. Budget for reading `requirements.txt` on every pull rather than assuming a stable interface.

The licence is Apache-2.0, which permits commercial use and modification with the usual attribution and notice requirements, and it includes a patent grant. That is a permissive licence, but it governs the code in this repository, not the model weights hosted on Hugging Face. Check the model cards for the weights' own terms before shipping anything. Nothing here is legal advice.

The upgrade cost is dominated by the environment, not the code. Torch 2.4.0 with a `+cu124` local version, flash-attn 2.8.3, and deepspeed 0.14.5 all have to move together if you want to move any of them, because `train_evoke.py` is written against deepspeed 0.14.5's stage_1_and_2 internals.

Editorial conclusion

Adopt EVOKE if you are working on interactive world models, long-horizon video rollouts, or few-step distillation research, and you have H200-class hardware plus the patience for a pinned CUDA 12.4 environment. Do not adopt it if you need a productized text-to-video service or you cannot install torch 2.4.0 with the +cu124 local version. Before committing, verify three things: that the Hugging Face weights at AlayaLab/Evoke and AlayaLab/Evoke-Turbo download, that flash-attn 2.8.3 builds against your CUDA toolkit, and that the InteractiveUI path actually reaches the documented 1.34 seconds per chunk on your GPUs rather than the single-H200 2.11 seconds the README quotes for the base model.

Frequently asked questions

Official sources

1. AlayaLab/Evoke on GitHub
2. Issues
3. License: Apache-2.0
4. README