What GPU do you need to run Open-Sora 2.0?

More than most people expect. On the project's own numbers, generating at 256 by 256 takes about 52.5GB of VRAM on a single GPU, and 768 by 768 takes about 60.3GB on a single GPU. That is H100 or H800 class hardware, not a consumer card. Multi-GPU splits the load, dropping 768px to roughly 44.3GB per card across four or more GPUs, and there is an --offload True flag that trades speed for memory. If you have a 24GB consumer GPU, Open-Sora 2.0 is not the right project for you.

Is Open-Sora the same as OpenAI's Sora?

No, and the name similarity causes constant confusion. Open-Sora is an independent open-source project from hpcaitech, released under Apache-2.0, whose weights you download and run yourself. OpenAI's Sora is a closed commercial product you access through a subscription. They share an ambition and nothing else: different teams, different licenses, different hardware requirements.

How do you install Open-Sora 2.0?

Create a Python 3.10 conda environment, clone the repository, install it in place, then add the two extras that are easy to miss: 'pip install xformers==0.0.27.post2 --index-url https://download.pytorch.org/whl/cu121' and 'pip install flash-attn --no-build-isolation'. It expects PyTorch 2.4.0 or newer against CUDA 12.1. Weights come separately through the Hugging Face CLI into a local ckpts directory.

What video formats and lengths can Open-Sora 2.0 produce?

It generates 4 to 128 frames, in aspect ratios including 16:9, 9:16, 1:1, and 2.39:1, so vertical short-form output is supported natively. It runs text-to-video, image-to-video, and a text-to-image-to-video path, and exposes a motion score between 1 and 7 that defaults to 4.

How to Use Open-Sora 2.0: The Real Setup Guide, Including the VRAM Number

Open-Sora is one of the most starred open-source video projects on GitHub, sitting around 29.4k stars with an Apache-2.0 license and an 11B parameter model in its 2.0 release. It is a genuine piece of open research infrastructure, and it is also the single most misunderstood project in generative video, for one boring reason: it shares a name with a commercial product from a different company.

This guide covers the real thing. What it is, the exact commands, and the hardware number that decides whether the rest of this page is useful to you.

First, the name

Open-Sora is not OpenAI's Sora. It comes from hpcaitech, it is Apache-2.0 licensed, and you run it on your own hardware with weights you download yourself. OpenAI's Sora is a closed commercial service. They are unrelated projects that happen to have converged on similar names, and almost every search result for one is polluted by the other.

If you arrived here wanting the subscription product, this is the wrong page and you will save yourself an afternoon by knowing that now.

The hardware requirement, up front

Most setup guides bury this in a table near the bottom. It belongs at the top, because it decides everything else. On the project's own published figures:

256×256: about 52.5GB VRAM on one GPU, about 44.3GB per card with two or more.
768×768: about 60.3GB on one GPU, about 48.3GB across two, about 44.3GB across four or more.

Those numbers are measured on H100 and H800 class hardware. This is not a project you run on a 12GB or 24GB consumer card, and no amount of configuration changes that by an order of magnitude. There is an --offload True flag that trades speed for memory and helps at the margins, and multi-GPU meaningfully reduces per-card load, but the floor stays high.

If you do not have access to that hardware, skip to the last two sections rather than spending an evening finding this out through out-of-memory errors.

Installing it

Assuming you do have the hardware, the install is well-specified. It expects Python 3.10, PyTorch 2.4.0 or newer, and CUDA 12.1.

conda create -n opensora python=3.10
conda activate opensora
git clone https://github.com/hpcaitech/Open-Sora
cd Open-Sora
pip install -v .
pip install xformers==0.0.27.post2 --index-url https://download.pytorch.org/whl/cu121
pip install flash-attn --no-build-isolation

Two of those lines are the ones people skip and then debug for an hour. The pinned xformers build has to come from the CUDA 12.1 PyTorch index, not from PyPI, and flash-attn needs --no-build-isolation or the build will fail in a way that does not obviously point at the cause.

Getting the weights

Weights are a separate download and do not come with the repository:

pip install "huggingface_hub[cli]"
huggingface-cli download hpcai-tech/Open-Sora-v2 --local-dir ./ckpts

ModelScope works as an alternative source if Hugging Face is slow or blocked where you are. Plan for a substantial download and check your disk before starting.

Running inference

Generation runs through torchrun against a config file, not through a UI. The text-to-image-to-video path at 256px on a single GPU:

torchrun --nproc_per_node 1 --standalone scripts/diffusion/inference.py \
  configs/diffusion/inference/t2i2v_256px.py --save-dir samples --prompt "raining, sea"

And the 768px path across eight GPUs:

torchrun --nproc_per_node 8 --standalone scripts/diffusion/inference.py \
  configs/diffusion/inference/t2i2v_768px.py --save-dir samples --prompt "raining, sea"

The pattern is stable: --nproc_per_node matches your GPU count, the config file selects resolution and pipeline, and --prompt carries your text. Output lands in --save-dir.

Useful knobs once it runs: it produces 4 to 128 frames, supports 16:9, 9:16, 1:1, and 2.39:1 aspect ratios, and exposes a motion score from 1 to 7 that defaults to 4. The 9:16 support matters if short-form vertical video is your actual goal.

Using it with Claude Code, Cursor, or Codex

A coding agent earns its keep on this project specifically, because most of the difficulty is environment rather than creative:

Getting the CUDA, PyTorch, xformers, and flash-attn versions mutually consistent, which is the classic four-way version conflict, and reading the real error rather than guessing.
Writing a sweep script that runs one prompt across several motion scores and aspect ratios so you learn the model's behaviour in one batch instead of forty manual runs.
Wrapping torchrun calls so failed runs get logged with their config, which matters when a job dies 40 minutes in.
Watching VRAM and adjusting --nproc_per_node and --offload automatically instead of by trial and error.

Open the repository in your agent, tell it your GPU situation honestly, and let it own the environment loop.

If you are renting the GPU instead of owning it

Most people who run this project do not own an H100. Renting is the normal path, and there are four things worth deciding before you start the meter rather than after.

Disk before compute. The weights are a large download and the instance needs room for them plus your outputs. An instance that runs out of disk halfway through huggingface-cli download has cost you the download time twice.

Persist the checkpoint directory. If your provider wipes local storage between sessions, re-downloading weights every time will quietly become the largest line on your bill. Attach a volume, point --local-dir at it, and check that it survives a restart before you rely on it.

Watch the interruption policy. Cheap capacity is usually preemptible. A 40-minute generation on an instance that can be reclaimed at any moment is a bad trade unless you are logging runs and can resume them.

Match the CUDA version to the image. The install pins xformers against CUDA 12.1. Pick a base image that already matches, rather than fighting the driver on a rented box where you may not have full control.

Check the current hourly rate yourself at the time you rent, because that market moves quickly enough that any number written here would be wrong by the time you read it.

The failures you should expect

None of these are mysterious once you know the shape of them.

Version conflicts between PyTorch, CUDA, xformers, and flash-attn. This is the most common way the install dies. The pins exist for a reason, and installing xformers from the default index instead of the CUDA 12.1 PyTorch index is the single most frequent cause.

flash-attn failing to build. It needs --no-build-isolation. Without it, the build cannot see the installed torch and fails in a way that does not name the real cause.

Out of memory partway into generation. Compare your actual card against the figures above before assuming a configuration problem. Try --offload True, drop to 256px, or add GPUs. If you are far below the floor, no flag will close the gap.

Realistic expectations

Open-Sora is research infrastructure that happens to be usable, not a product. That framing sets expectations correctly: the model is capable, the interface is a command line, and iteration speed is bounded by generation time on very expensive hardware.

It is an excellent choice if you are studying video diffusion, need to fine-tune on your own data, or have institutional GPUs sitting idle. It is a poor choice if what you actually want is a finished short-form video this afternoon.

A short, honest note

If you have the hardware and the curiosity, this project deserves the stars it has. Go run it.

If you got here because you want vertical short-form video that performs, the hardware requirement is telling you something useful: model access is not your bottleneck. Structure is. Riffkit starts from a video that already won, models the emotion formula underneath it, and rebuilds that formula as your own video with your product and your character. Same formula, new story, no H100 involved.

For the closest open-source neighbours that do run on normal hardware, see our guides to OpenMontage and Open Generative AI. If you are specifically looking for what to use instead of Open-Sora, we sorted that by hardware budget in Open-Sora alternatives.

Get the Riffkit skill

If you already work in Claude Code or Cursor, the Riffkit skill takes one source link and a sentence of direction and returns a finished video plus caption, without leaving the terminal and without a GPU.