As of 2026-06-21T05:34:26Z UTC, the useful way to read Open-Sora Plan is not as an open-source version of a famous product demo. The better reading is narrower and more valuable: it makes the video-generation recipe auditable. Instead of asking whether a sample clip looks impressive in isolation, a builder can inspect the repo, paper, model pages, v1.5 report, data notes, accelerator path, VAE choice, frame constraints, and benchmark table before deciding what the result means.[1][2][3][4]
That matters in AI-China because video models are unusually easy to overread. A good clip can hide prompt selection, cherry-picked seeds, post-processing, private data, private evaluation, and expensive training details. Open-Sora Plan's public artifact trail does not remove those risks. It changes the diligence question. The test becomes: which parts of the recipe are visible enough to reproduce, stress, or falsify?
The project began in March 2024 as an open attempt to reproduce Sora-style text-to-video generation, initiated by the PKU-YuanGroup and TuZhan AIGC joint lab, with contributions from TuZhan, Huawei, Pengcheng Laboratory, and the open-source community.[1] By itself, that origin story would be ordinary. The more interesting signal is the release cadence. The README records a path from VideoCausalVAE in March 2024, to v1.0 in April, v1.1 in May, v1.2 in July, v1.3 in October, v1.5 in June 2025, and a 2026 Helios branch aimed at real-time long-video generation.[1]
The cadence is important because it turns the project into a stack history. Open-Sora Plan is not one checkpoint. It is a series of decisions about temporal compression, attention, data filtering, hardware, and inference shape.
The benchmark is only the last layer
The v1.5 report's headline table is easy to quote: Open-Sora Plan v1.5.0 is listed as an 8B model with an 83.02% VBench total score, compared with 83.24% for HunyuanVideo and 82.32% for Gen-3 in the same table.[2] That is a useful anchor, but it should not be treated as a product verdict. VBench is a structured benchmark, not a substitute for production video evaluation across brand safety, temporal coherence, prompt fidelity, editing control, licensing, latency, and cost.
The stronger value of the report sits upstream from the score. It states that v1.5.0 uses an 8.5B-parameter model, 1.1 billion high-quality images, 40 million high-quality videos, and Ascend 910-series accelerators through MindSpeed-MM.[2] Those are project-reported numbers, but they make the evaluation envelope legible. A reader can see which scale claim supports the benchmark, which hardware lane carried training, and which parts remain tied to NPU-specific tooling.
That hardware boundary is not a footnote. The README says v1.5.0 is fully trained and inferred on Ascend 910-series accelerators, with the GPU version still marked as coming soon; the resource notes also say current v1.5 weights are compatible with the NPU plus MindSpeed-MM framework.[1] For AI-China, that is the whole point. Open video generation is not only an algorithm race. It is a domestic accelerator and software-stack race.
Compression is the quiet control knob
Open-Sora Plan's paper describes the project as a full video-generation process with a Wavelet-Flow Variational Autoencoder, a Joint Image-Video Skiparse Denoiser, condition controllers, efficient training and inference strategies, and a multidimensional data-curation pipeline.[3] That sentence is the architecture map. The model is not evaluated only by output aesthetics; it is evaluated by whether the whole pipeline makes the high-dimensional video problem small enough to train and run.
The VAE is the cleanest example. The v1.5 report says the team moved to WFVAE with 8x8x8 downsampling, reducing latent shape and shortening attention sequence length while aiming to preserve reconstruction quality.[2] The related WF-VAE paper frames the same layer as a latent-video-diffusion problem: better video VAE design can improve compression and reconstruction before the denoising model ever acts.[5]
This is why "video generation" can be a misleading label. The hard work is not one model call. It is a chain: encode frames and motion into a latent representation, decide how much temporal detail to keep, train a DiT over a sequence that has not exploded beyond the hardware budget, and then decode motion back into video without letting compression artifacts become the final style. If the VAE is weak, the denoiser inherits damage. If the latent sequence is too large, attention cost dominates. If compression hides too much motion, benchmark scores can look cleaner than user-facing motion actually feels.
Sparse attention is the speed claim to audit
The second control knob is attention. Open-Sora Plan v1.3 introduced Skiparse Attention; v1.5 extends it into a U-shaped sparse diffusion transformer, or SUV.[1][2] The report claims that on an Ascend 910B platform at a 121x576x1024 shape, SUV runs over 35% faster than Dense DiT, with the attention operation itself gaining over 45%.[2]
Those numbers are useful because they are specific enough to test. They are also bounded. They apply to a stated platform and shape, and they come from the project report. A team should not convert them into a universal "sparse attention is faster" statement without re-running the comparison under its own resolution, frame count, batch size, compiler stack, and deployment hardware.
Still, the architectural idea is important. Video generation punishes sequence length. A model that treats every token interaction as equally expensive has to pay heavily when frames, resolution, or duration rise. SUV is a bet that sparse global interaction can keep enough temporal and spatial coherence while making high-resolution video tractable. Whether that bet holds outside the authors' benchmark envelope is exactly the right evaluation question.[2]
The release is unusually explicit about limits
The best thing about Open-Sora Plan's public materials is that they expose awkward constraints rather than only polished claims.
The Hugging Face page for v1.3.0 says the release supports complete training and inference on Huawei Ascend systems, names WFVAE, prompt refiner, data filtering, sparse attention, and bucket training, and lists a 93x480p within 24G VRAM support point.[4] It also says frames need to follow a 4n+1 pattern, such as 93, 77, 61, 45, 29, or 1, because of the stride-32 training setup.[4] The README repeats similar resource-table constraints across versions and notes that some earlier weights were not final high-quality-data fine-tuned and may produce watermarks.[1]
Those details reduce hype. They tell a builder where the edges are: frame counts, multiples of resolution, NPU framework dependence, checkpoint compatibility, and data-quality caveats. In a closed product demo, those edges usually surface only after the user hits them. In Open-Sora Plan, at least some of them are visible in advance.[1][4]
That visibility should shape adoption. A research lab can treat Open-Sora Plan as a recipe for experimenting with video architectures. A media team looking for reliable production output should treat it as a technical artifact, not a finished creative platform. A hardware team should read it as evidence that Ascend-backed training paths can carry serious video workloads, while still requiring careful validation against GPU workflows and deployment expectations.
What would make the claim stronger
Three tests matter from here.
First, reproducibility. The public code, reports, and weights are valuable, but the strongest signal would be outside groups reproducing the v1.5 benchmark profile under documented hardware and dataset assumptions. The open release makes that possible; it does not make it automatic.[1][2][3]
Second, portability. If the GPU version matures while the NPU version remains first-class, Open-Sora Plan becomes a stronger bridge between domestic accelerator strategy and global research tooling. If the v1.5 path stays tightly bound to Ascend-specific infrastructure, it remains important, but its adoption boundary is narrower.[1][2]
Third, task evaluation. VBench-style aggregate scores should be joined by practical tests: long-prompt obedience, multi-shot continuity, product-safe generation, image-to-video control, temporal editing, watermark avoidance, and cost per acceptable clip. The v1.5 report itself points toward image-to-video as a future production-relevant focus, which is the right direction because most commercial video workflows begin from assets, not free-form text alone.[2]
The bottom line: Open-Sora Plan matters because it makes AI video less magical and more inspectable. Its strongest contribution is not one generated clip. It is the documented recipe: VAE compression, sparse attention, data scale, training stages, hardware dependence, frame constraints, and benchmark boundaries in one public trail. For AI-China, that is the signal to watch. The video race is becoming a supply-chain audit.
Sources
- PKU-YuanGroup,
Open-Sora-PlanGitHub repository - project origin, release history, v1.5 Ascend training note, resource table, constraints, and public code/weights links. - PKU-YuanGroup, "Report v1.5.0" - official v1.5 technical report covering SUV, 8x8x8 WFVAE, data scale, Ascend 910-series training, VBench table, training stages, and future work.
- Bin Lin et al., "Open-Sora Plan: Open-Source Large Video Generation Model," arXiv:2412.00131 (submitted November 28, 2024).
- LanguageBind, "Open-Sora-Plan-v1.3.0" Hugging Face model page - v1.3 release notes, Ascend support, WFVAE/prompt-refiner/data-filtering details, 93x480p within 24G VRAM note, and frame-count constraints.
- Zongjian Li et al., "WF-VAE: Enhancing Video VAE by Wavelet-Driven Energy Flow for Latent Video Diffusion Model," arXiv:2411.17459.
- Wikimedia Commons, "Boya Pagoda, Peking University.jpg" - real 2011 photograph by Huangdan2060 used as the article image source.