MAGI-2 Preview ships 100 denoising steps, 308 GB of weights, and one optional prompt enhancer

Missing ffmpeg still writes the video, and only the checkpoints get mounted

The hardware requirement is specific: eight NVIDIA Hopper GPUs, Python 3.12, and a recent CUDA toolkit. The software requirement is the interesting one. `ffmpeg` has to be on `PATH` so the generated audio track can be muxed into the output file, and the documentation says that without it the video is still written, just silently.

That is a failure mode with no error message. A run without ffmpeg produces a file that plays as video with no sound, and nothing in the pipeline distinguishes it from a successful run.

The Docker path has a related gap. The published image is described as dependencies only, with code mounted at runtime, and the documented invocation mounts exactly one thing:

docker pull sandai/magi-2-preview:latest
docker run --gpus all -it -v /path/to/ckpt:/workspace/ckpt sandai/magi-2-preview:latest

One volume, and it is the checkpoints. The working directory in the image is `/workspace`, and no source directory appears in that command, so the launch line is missing the mount that would put your copy of the code in front of the dependency image.

Everything else the image provides is built in, including the packages that need a compiler. Building it yourself is described as necessary only to change a dependency version or to work where the registry is unreachable.

The size table adds to 308 GB while the text says 307

The weights are not in the repository. They sit on Hugging Face and the text puts the total at roughly 307 GB. The per-directory table adds up to one more than that: preview at 228 GB, text_encoder at 56 GB, refiner at 14 GB, stable-audio-open-1.0 at 5 GB, vae at 3 GB and turbo_vae at 2 GB.

A one gigabyte discrepancy in a figure this size is not worth arguing about. The distribution inside it is.

The preview transformer is 228 GB of the total, which is about three quarters of everything you download, and it is split into 56 safetensors shards with an index. The refiner is 3 shards and 14 GB, so 59 shards in all. Anyone budgeting disk or planning a partial download should start from the fact that there is no meaningful subset: skipping the refiner means losing the stage that takes the clip to 1080p, and skipping the preview means losing the stage that produces anything at all.

The download lands in `ckpt/` at the repository root, which is gitignored, and the directory names inside the model repository are the ones the configs already expect, so nothing has to be renamed afterwards. To keep the weights elsewhere, set `MAGI2_CKPT_ROOT`, which is what the configs interpolate as `${MAGI2_CKPT_ROOT}/<name>` and which defaults to `<repo>/ckpt`.

The text encoder is four times the refiner, and it is somebody else's model

Look at what sits inside the checkpoint rather than at the two transformers the model is named for. The text encoder is 56 GB and the refiner transformer is 14 GB, so the component that turns your prompt into tokens costs four times the disk of the component that cleans up the video.

That encoder is `Qwen/Qwen3.5-27B`, pulled from that project's Hugging Face repository rather than trained here. The video VAE is likewise borrowed: `vae` holds `Wan2.2_VAE.pth` from Wan-AI's TI2V-5B release at 3 GB. On the audio side, `stable-audio-open-1.0` at 5 GB is the audio VAE that decodes the generated audio latents.

The sixth directory is the odd one. `turbo_vae` is 2 GB, holds a distilled VAE decoder plus a JSON config named for a tiny shallow variant, and is the decoder used by default. So the default decode path is a distilled third-party component while the original 3 GB video VAE sits next to it unused unless you go looking.

Three of the six directories are other people's models. That is normal for a release of this kind, and it is also what makes the 307 GB figure move whenever an upstream checkpoint changes.

The distilled checkpoint is marked coming soon, so 100 plus 5 steps is the floor

Neither transformer has been step-distilled, and the documentation is direct about what that costs: the denoising step count is where most of the wall-clock time goes. It then distinguishes what exists today from what follows.

What exists is MAGI-2 Preview base, at 100 preview steps plus 5 refiner steps, with weights published. What follows is MAGI-2 Preview distilled, listed as far fewer steps with the weights column reading coming soon. No date, no branch, no tag, no partial checkpoint.

So the practical reading is that 105 sampling steps is not a configuration you can tune down. There is no documented guidance for reducing the step count on the base weights, and the one artefact that would address it is described in the future tense in a two-row table.

This matters more than usual because of what the architecture already does. The model has 114B parameters and activates 6B of them per token, so roughly one parameter in nineteen is live at any moment. A sparse model that still needs 100 denoising steps per 10 second clip is paying for its efficiency on the compute side and not on the sampling side.

Clips are fixed at 10 seconds. That is stated as the only duration the model currently supports, so there is no length parameter to trade against quality either.

requirements.txt pins 12 of 23 packages and leaves torch on a floor

The dependency file lists 23 packages. Twelve are pinned exactly and eleven carry a floor with `>=`, and the split is not along the lines you would expect.

Exactly pinned: accelerate 1.10.1, diffusers 0.38.0, ffmpeg-python 0.2.0, imageio 2.37.3, pandas 3.0.3, pydantic 2.12.2, pydantic-settings 2.14.1, rich 14.2.0, sentencepiece 0.2.1, timm 1.0.20, transformers 5.5.0 and unfoldNd 0.2.3.

Left floating: av, einops, numpy, openai, packaging, Pillow, safetensors, scipy, torch, torchvision and tqdm. The floors are torch 2.6.0, torchvision 0.21.0, numpy 1.26.0 and Pillow 10.0.0.

Leaving the CUDA stack and numpy on a lower bound is a deliberate-looking choice, since those are the ones with a hard compatibility relationship to the driver, and pinning them exactly would make the file harder to reuse across environments. It also means a fresh install resolves to whatever satisfies the floor today.

Two ffmpeg integrations sit side by side here, `ffmpeg-python` at 0.2.0 and `imageio[ffmpeg]` at 2.37.3, alongside the system-level `ffmpeg` binary the runtime needs on `PATH`. Three different ffmpeg surfaces for one muxing job.

MagiAttention and MagiCompiler are not in this file at all. They are separate repositories, and their revisions are pinned as build arguments in the Dockerfile rather than here.

Prompt enhancement is off until you edit enhancer.py, and the shipped prompts skip sample_001

The model was trained on long structured captions, so a short hand-written prompt underuses it, and the pipeline offers an optional enhancement pass before encoding. Text-to-video uses one template, image-to-video uses another, and both ask an instruction-following model for a structured JSON caption of the 10 second clip before rendering the result to readable Markdown and passing it downstream.

The switch is a source edit. The reference client talks to an OpenAI-compatible endpoint, and you set `API_KEY` inside `enhancer.py` to enable it, or subclass `LLMClient` for a different provider. Leave `API_KEY` empty and the pass is skipped, with your raw prompt used as-is.

So enabling it means editing a Python file to put a secret in it, and the alternative path means writing your own client class. There is no environment variable for the key and no command-line flag.

The assets directory ships example prompts that are already enhanced, named `sample_000.txt` and `sample_002.txt`. There is no `sample_001`. The demo run writes outputs numbered by position in the batch, as `sample_000.mp4` and upward, so the shipped examples and the output numbering share a convention with a gap in the middle that nothing in the repository explains.

The demo script itself reads `SAMPLES`, `OUTPUT_DIR`, `SEED` and `MASTER_PORT` from the environment, generates at 1080p with seed 42, and takes the batch from a JSON file in assets.

Per-commit image tags are the only reproducible handle, and latest moves under you

The published image is tagged per commit as well as by `latest`, and the guidance is to name the commit tag when reporting a result because `latest` moves. The image also records what it was built from in `/etc/magi2-build-info`, so a running container can tell you what it is.

That is a sound convention for a research release, and the Dockerfile follows the same idea internally. Flash-attention is cloned at a full commit SHA for the Hopper backend, and MagiAttention is pinned the same way, both as build arguments with the 40-character hashes written out in full. MagiCompiler is handled alongside them further down the same file.

The base image is `nvcr.io.nvidia/pytorch:25.10-py3`, and the build installs the compiler toolchain, ninja and ffmpeg through apt before installing Python packages. Two cache directories are redirected into `/tmp`: one for the Magi compiler cache and one for the MagiAttention workspace.

The licence is Apache-2.0 with a LICENSE file at the top level, and the repository has no GitHub releases, so the per-commit image tag and the checkpoint repository are the only two version handles available. The last push to the default branch is 2026-08-06.

Editorial conclusion

MAGI-2 Preview is worth reading if you are sizing an eight-GPU video inference box, because the checkpoint layout, the mount path and the per-commit image tags tell you what the job actually costs. Before you plan around it, accept that the clip length is fixed at 10 seconds, that the base checkpoints are not step-distilled so 100 preview steps plus 5 refiner steps is the floor rather than a choice, and that the prompt enhancer sends your prompt to an external endpoint the moment you put a key in enhancer.py.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. SandAI-org/MAGI-2-preview on GitHub