Open-Sora: what the repository publishes

Open-Sora publishes an 11B model under Apache 2.0 and states peak GPU memory against the number of cards: 60.3GB at 768px on a single H100 or H800, dropping to 44.3GB across four or more. The supported resolutions are 256px and 768px. As of 2026-09-22.

Inclusion rule. The same five fields for every family here. A field the repository does not state is recorded as not stated rather than estimated from the parameter count. Order. Fixed field order, identical on every family page.

1A memory figure that changes with how many cards you own

The columns of the efficiency table are GPU counts. Sixty gigabytes at 768px on one card, forty-four across four or more, for the same output. Memory here is partly a property of the model and partly a property of the deployment, and this is one of the few entries in the register that shows both halves at once.

The consequence is that the floor is not really a floor. Somebody with two 48GB cards is in a different position from somebody with one 96GB card, even though the totals match, and no single-number requirement could have carried that distinction.

2Frames given as arithmetic instead of seconds

The repository states that candidate values for num_frames should be 4k+1 and less than 129. That is a constraint on what the code accepts rather than a claim about output, and it is written in the form the argument has to take.

Recording it as roughly five seconds would be an invention, because the repository supplies no frame rate to divide by. The register keeps the expression intact: a reader who wants seconds can choose a rate, and a reader who wants to run the command needs this form anyway.

3Two resolutions, and the memory table is built on the same two

256px and 768px, named as what the 11B model supports. The efficiency figures are measured at those same sizes, so the hardware and resolution cells describe one run here instead of two unrelated ones, which is not true of every entry in this register.

Both figures are attributed to H100 or H800 hardware. Naming the card alongside the gigabytes turns 60.3GB into something a reader with the same card can repeat, and an unattributed memory number never is.

4The same field, across every family

Inclusion rule. Families whose vendor has published weights openly. A family whose repository does not state this particular field keeps its row, marked hollow. Order. Alphabetical by family name.

Inclusion rule. Families whose vendor has published weights openly. A family whose repository does not state this particular field keeps its row, marked hollow. Order. Alphabetical by family name.

Inclusion rule. Families whose vendor has published weights openly. A family whose repository does not state this particular field keeps its row, marked hollow. Order. Alphabetical by family name.

• Licence
  Apache 2.0stated on the repositoryhpcaitech, Open-Sora repository / recorded 2026-09-22
• Model size
  Open-Sora 2.0, an 11B modelcarried in the release namehpcaitech, Open-Sora repository / recorded 2026-09-22
• Hardware
  60.3GB peak GPU memory at 768px on one GPU, and 44.3GB across four or moremeasured on H100 or H800 cardshpcaitech, Open-Sora repository / recorded 2026-09-22
• Length
  Candidate values for num_frames should be 4k+1 and less than 129expressed as the constraint the code enforceshpcaitech, Open-Sora repository / recorded 2026-09-22
• Resolution
  The 11B model supports 256px and 768px resolutionthe pair the repository nameshpcaitech, Open-Sora repository / recorded 2026-09-22

5Sources

Read from github.com/hpcaitech on 2026-09-22. Hardware figures across every family are collected on requirements; the licence column is set out on licence and what counts as a published weight is on how read. Previous family: Step-Video-T2V. Next family: Stable Video Diffusion.