Which repositories state a minimum rather than a peak
Four of the 15 families publish a stated minimum. Two more publish a requirement figure, four publish a peak measurement, one publishes the memory a run used, one publishes only a timing, and three publish nothing. As of 2026-09-12.
| Item | What is published | Detail |
|---|---|---|
| A stated minimum | Four families | From 4GB in FP16; 6GB for 1800 frames; at least 12GB on an fp8 build; at least 80GB |
| A requirement figure | Two families | 32.54 GB of VRAM; approximately 60GB on one GPU |
| A peak measurement | Four families | 78.55 GB, 60.3GB, 60GB and around 51.2GB, each at a stated configuration |
| Memory a run used | One family | 9.3G with offload and 27.5G without, on the same run |
| A timing and no memory | One family | About 180s on an A100 80GB card |
| Nothing stated | Three families | No figure, and in two cases no card either |
Inclusion rule. One row per kind of memory statement. A kind used by a single family keeps its row, because the shape of the statement is the finding rather than the count. Order. From the statement most useful to a reader with one card to the least.
1Publishing a minimum is the harder choice
A peak falls out of instrumentation: run a script, report the maximum allocated. Establishing the smallest card that completes a job means acquiring or borrowing hardware the vendor may not have, and then standing behind the result.
That is why peaks outnumber minimums here, and why a minimum is usually conservative. A vendor that publishes one has accepted that anybody with that card will test it.
2The two kinds do not convert into each other
A run that peaked at 60GB on an 80GB card may still need a different offload strategy to fit on anything smaller, and a 6GB minimum says nothing about how much headroom a large card would have. Reading one as the other is the commonest error in this column.
The register keeps the vendor's own word in the value. Where a repository says peak, the cell says peak, and where it says minimum or requires, the cell says that instead.
3The three silent releases are not all silent in the same way
One discusses offloading without ever giving a figure, which at least tells a reader that memory was a consideration. One names no card and no number at all. One publishes smaller builds instead of a figure, which is an answer in a form this column cannot hold.
All three are recorded as absences. A number from a forum thread would be the only value on those rows that nobody published, and it would be the one readers quoted.
- HardwareTo generate a 1-minute video at 30fps, 1800 frames, using the 13B model, the minimal required GPU memory is 6GBa floor stated together with the output it buys
- 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
- HardwareFor 4.5B models, any machine with at least 24GB of GPU memory is sufficient, and a distilled fp8 configuration works on GPUs with at least 12GBa floor for the model and a lower one for a build
- Hardware78.55 GB peak GPU memory at 768px768px204f, 77.64 GB at 544px992px204f and 72.48 GB at 544px992px136fstated per configuration at batch size one
- HardwareSVD-XT takes about 180s on an A100 80GB carda timing on a named card with no memory floor stated
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: Figures, no card, Frames, no rate, Exact or rounded.