Open-Sora-Plan: what the PKU-YuanGroup video model repo actually ships

What Open-Sora-Plan is trying to reproduce, and for whom

The README opens with a plain statement of intent: the project exists to build a simple and scalable repository that reproduces Sora, which the authors pointedly call "ClosedAI". It is run out of the PKU-Tuzhan AIGC joint lab, with contributions listed from Tuzhan, Huawei, Pengcheng Laboratory and the wider open source community. The audience is therefore not a product team looking for a video API. It is researchers and algorithm engineers who want the training recipe, the VAE, the data pipeline and the model code in one place, and who are willing to read reports rather than documentation.

The version history makes the research posture obvious. v1.0.0 arrived in April 2024, v1.1.0 in May, v1.2.0 in July with a 3D full attention architecture replacing 2+1D and training on 4s 720p, v1.3.0 in October 2024 with WFVAE, a prompt refiner, sparse attention and a bucket training strategy, and v1.5.0 in June 2025. Each release is accompanied by a report under docs/. That cadence is a research cadence, not a maintenance cadence.

The v1.5 branch runs on Ascend, not on your 4090

This is the single fact that decides whether the repository is useful to you. The README states that the current V1.5 version is fully trained and inferred on Huawei Ascend 910-series accelerators, and the Chinese line above it says the same thing more bluntly. The release note for v1.5.0 repeats it and points readers at the mindspeed_mmdit branch for the new code and docs/Report-v1.5.0.md for the report. It then adds that the GPU version is coming soon.

The v1.5.0 announcement claims performance comparable to HunyuanVideo using an 8B-scale model and 40 million video samples, with a higher-compression WFVAE and an improved sparse DiT architecture the authors call SUV. Those are the authors' claims in their own release note; nothing in the repository metadata lets you check them independently. What matters for adoption is the hardware boundary: if you do not have Ascend 910-series hardware, v1.5.0 is something you read, not something you run.

The main branch also carries a March 2026 news entry for Helios, a separate project at PKU-YuanGroup/Helios that the README describes as reaching 19.5 FPS on a single H100 without conventional long-video anti-drifting or standard video acceleration techniques. Helios is a different repository. Do not read the H100 number as a statement about Open-Sora-Plan itself.

Package layout, pinned dependencies and the version mismatch

The repository root holds .github/, docs/, examples/, opensora/, scripts/, pyproject.toml and LICENSE. The Python package is named opensora, and pyproject.toml declares version 1.3.0 even though the newest release on the repository is v1.5.0. That gap is worth knowing before you file a bug: installing from the main branch gives you a package that reports 1.3.0.

Dependencies are pinned hard, which is good for reproducibility and bad for coexistence. The list includes torch==2.1.0, torchvision==0.16.0, xformers==0.0.22.post7, diffusers==0.30.2, transformers==4.44.2, accelerate==0.34.0, deepspeed==0.12.6, gradio==4.0.0, numpy==1.24.4 and av==11.0.0, plus decord, pytorchvideo, moviepy, wandb and tensorboard. requires-python is >=3.8. Expect to build a dedicated environment; dropping this into an existing project that already pins torch will fight you.

The build backend is setuptools with setuptools>=61.0, and both tool.setuptools.packages.find and tool.wheel exclude assets*, docker*, docs and scripts*, so the docs and scripts you may want are not part of the wheel. There is also a mypy configuration with warn_return_any and warn_unused_configs, and a dev extra pinning mypy==1.8.0. Type checking is configured, not enforced by what is visible here.

Installing opensora and running a first VAE reconstruction

The repository does not present a step-by-step install guide in the README. What it does give you is pyproject.toml and an examples/ directory containing rec_image.py, rec_video.py, cond_prompt.txt, cond_pix_path.txt and sora.txt. The reconstruction scripts are the most concrete entry point visible in the layout, because they exercise the VAE without requiring you to train anything.

pyproject.toml is a standard PEP 621 project table, so the package installs with pip from a checkout of the repository. The pinned dependencies listed in that file are what pip will resolve.

[project]
name = "opensora"
version = "1.3.0"
description = "Reproduce OpenAI's Sora."
readme = "README.md"
requires-python = ">=3.8"

The project also declares an optional extra for development tooling, which the same file lists as a single pinned dependency.

[project.optional-dependencies]
dev = ["mypy==1.8.0"]

The examples directory holds the runnable entry points. rec_video.py and rec_image.py are the VAE reconstruction scripts, and cond_pix_path.txt and cond_prompt.txt are the example input files that ship alongside them, with sora.txt holding a sample prompt. The README does not document the command-line arguments of these scripts, so read the files in examples/ before running them.

What you should expect from a reconstruction run is a reconstructed video or image written out by the script. The README does not document the output path, the supported input formats beyond what cond_pix_path.txt contains, or the expected runtime, so treat the first run as an experiment rather than a verified workflow.

Where Open-Sora-Plan stops being the right tool

The clearest limitation is the one the release note admits: v1.5.0 is Ascend-only, and the GPU version is described as coming soon. A promise of a future port is not a port. Anyone whose cluster is NVIDIA-based and who needs the v1.5 architecture today has no path inside this repository, and should be reading docs/Report-v1.5.0.md for the method rather than waiting on a branch.

The second limitation is documentation depth at the level an operator needs. The README is a news feed with badges. It does not document rollback, it does not document an upgrade path between v1.3.x and v1.5.0, and it does not document the command-line arguments of the example scripts. The reports under docs/ are research write-ups. If your team needs a supported interface, this is the wrong repository, and no amount of reading will change that.

The third is the licensing ambiguity. The README badge links to LICENSE and reads Apache, while the project metadata you are given lists MIT. Those are different licences with different patent and notice provisions. Resolve that against the actual LICENSE file before you build anything on top of it.

Finally, note the maintenance signal rather than the marketing. The last push to the repository was on 2026-03-08, which is more than six months before today. The repository is not archived, but a six-month gap on a project whose README describes itself as iterating quickly is a fact worth weighing, and the March 2026 entry is about Helios, a sibling project, not about Open-Sora-Plan.

Open-Sora-Plan against the wider open video model field

The obvious comparison is with HunyuanVideo, and the project invites it: the v1.5.0 note measures itself against HunyuanVideo as the open-source reference point. The difference in approach is architectural and infrastructural at once. Open-Sora-Plan pairs a higher-compression WFVAE with a sparse DiT design it calls SUV, and it has committed its current generation to Ascend hardware. HunyuanVideo is the baseline the authors benchmark against, not a project this repository wraps or forks.

A second comparison sits inside the same lab. Helios, announced in the March 2026 news entry, targets minute-scale video at 19.5 FPS on a single H100 and explicitly avoids conventional long-video anti-drifting strategies and standard video acceleration techniques. That is a different bet on the same problem: Helios is a separate repository with its own technical report, and if your interest is long-horizon generation on NVIDIA hardware, it is the more relevant place to look than the v1.5 branch here.

A third axis is version choice within Open-Sora-Plan itself. v1.3.0 shipped WFVAE, a prompt refiner, a data filtering strategy, sparse attention and bucket training, and the release note states support for 93x480p within 24G VRAM. If your constraint is a single 24GB GPU, the v1.3.0 line is the one whose published constraint matches your hardware. v1.5.0 is not a drop-in upgrade from it.

Maintenance, upgrade cost and what the licence means in practice

Upgrading between lines here is not a version bump. v1.3.0 and v1.5.0 differ in VAE, in attention architecture and in target hardware, and the v1.5 code lives on the mindspeed_mmdit branch rather than main. The pyproject.toml on main still declares version 1.3.0. Any upgrade plan has to start by deciding which branch you are on, because the package metadata will not tell you.

The dependency pins make upgrades expensive in the ordinary sense too. torch==2.1.0 and xformers==0.0.22.post7 are old relative to current PyTorch releases, so moving the project forward means either accepting the pins or doing the port yourself. There is no changelog beyond the news list, and no documented migration path.

On licensing: the README badge points at LICENSE and labels the project Apache, while the project metadata you are given says MIT. Both are permissive, but they are not identical, and the difference matters if you plan to redistribute a derivative or rely on a patent grant. Read the LICENSE file in the repository and, if the answer affects a commercial deployment, get your own legal review. Nothing here is legal advice.

On maintenance: the last push was on 2026-03-08. The repository is not archived. The most recent release is v1.5.0 from 2025-06-05, and the most recent news item concerns Helios rather than this repository.

Editorial conclusion

Adopt Open-Sora-Plan if you want to read or extend a Sora reproduction and can work inside its pinned Python stack, and go in expecting the v1.5 weights to be an Ascend 910-series story rather than a CUDA one. Do not adopt it if you need a supported product with an SLA, a stable API, or a GPU release that the repository currently promises but has not published. Before you commit, read docs/Report-v1.5.0.md against the mindspeed_mmdit branch, confirm which of v1.3.0 or v1.5.0 matches your hardware, and check the LICENSE file: the README badge reads Apache while the project metadata you are given says MIT.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PKU-YuanGroup/Open-Sora-Plan on GitHub
4. README
5. Releases