Open-Sora: a fully open video generation stack you train and run yourself

What Open-Sora actually is, and who it is built for

Open-Sora is an open-source video generation project from HPC-AI Tech. The README describes it as an initiative to produce high-quality video efficiently and to make "the model, tools and all details accessible to all". The repository backs that claim with more than weights: it ships configs/, opensora/, scripts/, a gradio/ app, docs/ and a setup.py that installs the package as opensora version 2.0.0 under the Apache Software License 2.0.

The intended user is not someone who wants to type a prompt into a website. It is an engineer or researcher who wants the training loop, the data preprocessing pipeline and the checkpoints in one place. The README's news entries track that audience: Open-Sora 1.0 shipped a full pipeline of data preprocessing, training with ColossalAI acceleration and inference; 1.1 added text-to-image, text-to-video, image-to-video and video-to-video; 1.2 introduced a 3D-VAE, rectified flow and score condition; 1.3 upgraded the VAE and Transformer; 2.0 is an 11B model. Each release is paired with a technical report in docs/ or on arXiv.

One framing detail matters for anyone evaluating it. The README places a promotional block for Video Ocean and hpc-ai.com model APIs near the top, and the project is maintained by the same organisation that sells those services. That is a normal open-core arrangement, but it tells you where the polished product experience lives and where the research code lives.

The mechanism: data pipeline in, trained model out

Open-Sora is structured as a pipeline rather than a single model file. The top-level layout separates concerns cleanly: configs/ holds model and training configuration, opensora/ holds the Python package, scripts/ holds entry points such as scripts/train.py (linked directly from the README's December 2024 news item), and gradio/ holds the demo app. A separate docs/ tree carries the per-version technical reports.

On the model side, the architecture changed across versions, and the README is explicit about it. Open-Sora 1.2 added a 3D-VAE, rectified flow and score condition. Open-Sora 1.3 rebuilt the VAE and Transformer. Open-Sora 2.0 scales to 11B parameters, and the README claims on-par performance with 11B HunyuanVideo and 30B Step-Video on VBench and human preference, with training cost stated as $200K. Those are the project's own published claims, sourced to arXiv paper 2503.09642v1, not independent measurements.

Training acceleration comes from ColossalAI, which is a hard dependency in requirements.txt (colossalai>=0.4.4). That dependency explains the project's HPC framing and why the training path assumes multi-GPU infrastructure rather than a laptop. The config-driven design means you change resolution, sequence length and model size by editing config files rather than code.

Installing Open-Sora and generating a first video

The repository does not include an install section in the README excerpt, so the authoritative source for dependencies is requirements.txt at the repository root. It pins the framework tightly: torch==2.4.0 and torchvision==0.19.0, alongside colossalai>=0.4.4, mmengine>=0.10.3, av==13.1.0 for video loading, and liger-kernel==0.5.2. Because torch is pinned to an exact version, match your CUDA build to that wheel before installing anything else.

A conventional setup from the repository root looks like this:

pip install -r requirements.txt
pip install -e .

The second command uses setup.py, which installs the opensora package version 2.0.0 and reads the same requirements file for its install_requires. The setup excludes assets, configs, docs, gradio, scripts and other non-package directories, so those stay in the working tree where the scripts expect them.

For a first run, the repository provides a Gradio app under gradio/ and a Hugging Face Space at hpcai-tech/open-sora. The Space is the fastest way to see output without provisioning a GPU, since it runs on Hugging Face infrastructure. For local generation, the entry points live under scripts/ and are driven by configs; the README does not document a single canonical inference command in the excerpt provided, so read the config you intend to use before running anything. Expect the first run to spend most of its time downloading checkpoints.

Where Open-Sora breaks down or is the wrong tool

The most concrete limitation is hardware. ColossalAI is a required dependency, torch is pinned, and the headline model is 11B parameters. Nothing in the README excerpt states a minimum GPU or VRAM requirement, which is itself a problem: you cannot size a machine from the documentation alone, and the answer differs sharply between running the 1B Open-Sora 1.3 checkpoints and the 11B Open-Sora 2.0 checkpoints. Treat hardware planning as an experiment you run, not a number you look up.

Version drift is the second failure mode. The README states that Open-Sora keeps separate branches for different versions, with v1.0, v1.1, v1.2 and v1.3 living outside main. A config, checkpoint or script from one branch will not necessarily work on another. If you follow a tutorial written for 1.2 while sitting on main, expect mismatched config keys. Pin your checkout to a branch or tag before you start, not after something fails.

The third issue is that the project is not a product. There is no documented rollback path, no compatibility matrix, and no stated support window. The README does not document an upgrade procedure between major versions. If your requirement is a stable API that returns a video for a prompt, the vendor's own hosted services are what the README points to, and that is a fair signal about where the maintenance burden is expected to fall.

Open-Sora against Wan and other open video models

The obvious comparison, and one people search for directly, is against Wan and Wan 2.2. Both are open video generation models, but they differ in what they hand you. Open-Sora's distinguishing feature is that the repository ships the full training path: data preprocessing, ColossalAI-accelerated training via scripts/train.py, configs, and the technical reports describing each architectural change. The README's cost claims ($200K for the 11B training run, a stated 46% training cost reduction for the earlier release) only make sense in that frame, because they describe the cost of reproducing the model, not the cost of calling it.

If you only want to generate video, that training machinery is dead weight: an extra set of pinned dependencies, a ColossalAI requirement, and config files you must read before you can run anything. A model distributed primarily as weights with a simple inference path will get you to a first clip with less setup. Open-Sora's value appears when you want to modify the architecture, retrain on your own data, or audit how the model was built. Choose based on which of those two jobs you actually have.

Maintenance, upgrades and the Apache-2.0 licence

The last push to the main branch was on 2026-04-09, roughly five months before the time of writing. The repository is not archived. The latest tagged release is v1.3 from 2025-02-21, while the README's news section announces Open-Sora 2.0 under the 2025.03.12 entry and setup.py declares version 2.0.0. So the version number in the package metadata runs ahead of the most recent GitHub release tag. If you automate dependency resolution against release tags, you will get 1.3 artifacts, not 2.0. Verify which channel you are pulling from before you build.

Upgrade cost is real and undocumented. Because the project keeps a separate branch per version and the architecture changed materially between 1.2, 1.3 and 2.0, moving from one to the next is closer to a migration than a version bump. Budget for re-reading configs and re-downloading checkpoints. There is no migration guide in the repository.

The licence is Apache-2.0, declared both in the LICENSE file and in setup.py as "Apache Software License 2.0". That is a permissive licence with an explicit patent grant and no copyleft obligation on your own code. It does not, by itself, settle the status of the model weights or of any third-party data used in training; the repository does not document those terms, so check the checkpoint distribution pages before commercial use. This is a description of what the repository states, not legal advice.

How to decide in an afternoon

Start with the hosted Gradio Space at hpcai-tech/open-sora to see whether the output quality is acceptable for your use case at all. That costs you nothing and rules the project in or out before you touch a GPU.

If the output is good enough, clone the repository and pin to a specific branch, because main and the v1.x branches diverge. Read the config you intend to use under configs/ before installing, since the pinned torch==2.4.0 and torchvision==0.19.0 in requirements.txt will constrain your environment more than anything else in the stack. Then run the install and confirm that opensora imports.

Only after that should you decide between inference and training. The two paths have very different costs, and the README's efficiency claims are about the training path. If you never intend to train, weigh whether the ColossalAI dependency and the config-driven entry points are worth it compared to a weights-only distribution.

Editorial conclusion

Adopt Open-Sora if you have GPU capacity and want to inspect or retrain a video generation stack rather than call an API: the 11B Open-Sora 2.0 checkpoints and training code are published, and the repo ships configs, scripts and a Gradio app. Do not adopt it if you need a maintained product with support guarantees, because the last push to main was on 2026-04-09 and the README points commercial users to the vendor's hosted services instead. Before you commit, verify three things against the repository: that your CUDA and PyTorch combination matches the pinned torch==2.4.0 and torchvision==0.19.0 in requirements.txt, that the checkpoint you want is actually published for the version you plan to run, and that the config in configs/ for your target resolution fits in your GPU memory, since the README documents no minimum hardware figure.

Frequently asked questions

Official sources

1. hpcaitech/Open-Sora on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases