Which settings are published beside a memory figure
Across the register, the output resolution is the setting most often published beside a memory figure. The numeric precision appears less often, the frame count less often again, and the batch size once. As of 2026-09-12.
| Item | What is published | Detail |
|---|---|---|
| Output resolution | Six families | 720px1280px, 768px768px, 768px, 540P, 720P and 720 x 1280 |
| Numeric precision | Four families | FP16, BF16 twice, and an fp8 build |
| Frame count | Three families | 129 frames, 204 and 136 frames, and 1800 frames |
| Offload state | One family | With cpu_offload enabled, and with the call left out |
| Batch size | One family | Batch size one, stated for three peak figures |
| Card or architecture | Eight families | A card model, a card size or a chip generation |
Inclusion rule. One row per setting that changes a memory figure. A setting stated by one family keeps its row, because rarity is the finding. Order. From the setting stated most often to the settings stated once.
1Batch size is the largest hidden variable
Weights are held once regardless of batch size and everything else scales with it, so an unstated batch makes a figure ambiguous in one direction. A figure at batch size four is a much lower per-stream cost than it looks.
One repository here states it, which means those figures are the lowest the vendor could honestly publish. Everywhere else a reader has to assume one and know they are assuming.
2Resolution is stated most often because it is easiest
A memory table naturally has rows, and the rows are usually resolutions. That is why six families name an output size beside a figure and only one names a batch size: the first falls out of the table's shape and the second has to be written deliberately.
It is also the setting readers most want, since resolution is the lever they are most likely to pull. So the column is well served by accident on its most useful axis.
3A figure with no settings cannot be adjusted
Four families publish gigabytes with no hardware named, and some of those also omit the precision. A reader wanting a different resolution or a shorter clip has no published starting point to move from.
The register keeps each figure with whatever settings were published and adds none. A configuration supplied by the register would be the part a reader relied on and the part nobody stated.
- 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
- 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
- Hardware9.3G BF16 with cpu_offload, against 27.5G if CPU offload is not enabledsingle GPU memory usage on the same run
- HardwarePeak GPU memory of 60GB at 720px1280px and 129 frames, and 45GB at 544px960pxthe vendor's own figures
- 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
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: Card or repository, More than one card, Empty cells.