Which families attach their figures to a named variant
Six of the 15 families publish several variants and attach their figures to named releases. Nine publish a single model, which removes the ambiguity rather than resolving it. As of 2026-09-12.
| Item | What is published | Detail |
|---|---|---|
| Figures named per release | Six families | A three-step memory ladder by model size; two peaks at one output size; two card counts by model; per-checkpoint output; a named 13B for a length claim |
| A single published model | Nine families | One set of weights, so every figure on the page has one owner |
| A variant with no figure of its own | Two cases | A 5B sitting between two measured variants; distilled and fp8 builds with no memory figure |
| A licence that differs by variant | One family | One release under standard terms, the other under the project's own |
Inclusion rule. One row per attribution pattern. The two cases where a published variant has no figure of its own are kept, because that is the gap a reader hits. Order. From the clearest attribution to the cases where a variant is left unmeasured.
1Naming the variant is what makes a figure falsifiable
A memory figure stated for a family that ships three sizes cannot be tested: any failure to reproduce it can be attributed to the wrong download. Attaching the release name turns the claim into something somebody can check and report on.
Six families here do that consistently. Two of them go further and publish two figures at the same output size on two model sizes, which is the only controlled comparison in the register.
2A single model is a quiet advantage
Nine families publish one set of weights, so the question cannot arise. Every figure on those pages belongs to the same object, which makes the whole entry internally consistent without any extra discipline.
It is worth noticing because narrow releases are often treated as less thorough. On this particular axis they are more reliable, not less.
3The unmeasured middle variant is the recurring gap
One family publishes three sizes and measures the smallest and the largest, leaving the middle one without a figure. Another publishes lower-memory builds and states no figure for any of them.
In both cases the interpolation a reader wants is unavailable from the vendor, and the register does not supply it. A figure derived by interpolation would be the one value on the row that nobody measured.
- HardwareFrom 4GB in FP16 for the 2B model, from 5GB in BF16 for the 5B, and from 10GB for CogVideoX1.5-5Bthe lowest figures the repository states
- HardwareAbout 14.7GB peak VRAM for a 540P video on the 1.3B model, and around 51.2GB on the 14Bthe same output size on two model sizes
- HardwareH100/H800 x 8 for the 24B model, RTX 4090 x 1 for the 4.5Bstated as a count of a named card
- Length10-second videos at 768p resolution and 24 FPS, with a 384p checkpoint that generates 5-second video at 24FPSstated per checkpoint with the frame rate
- Published modelsA 13B model, with distilled and fp8 variants published for lower VRAM and faster inferenceseveral variants
4Sources
Repository statements and hosted rates are linked from the model pages and the how read page, checked 2026-09-12. Hardware figures are set out on requirements. Nearby: Consumer cards, Stated settings, Card or repository.