The one safe derivation from a parameter count

Multiplying a parameter count by bytes per parameter gives a download size, and that is the only inference from a count this register treats as sound. Memory, speed, quality and clip length all resist the same treatment. As of 2026-09-12.

Inclusion rule. Quantities a reader might try to derive from a parameter count. A quantity that cannot be derived is listed, because the attempt is the common error. Order. The derivable target first, then the three that are not.

1Why the storage estimate holds

Weights are stored at a fixed number of bytes each, so the product of a count and a format is a real quantity. Metadata and configuration files add a little, and nothing in the calculation depends on how the model behaves.

It is worth doing before anything else, because storage is the first hard limit a local plan hits. Keeping a full model, a distilled build and a quantised build means three downloads rather than one.

2Why memory does not follow

Activation memory scales with pixels per frame and with frames held at once, and neither appears in a count. The autoencoder runs at full resolution at both ends of a generation. The framework holds buffers of its own.

This register contains a thirteen billion parameter release stating a six gigabyte floor and a two billion release requiring over thirty-two. Any arithmetic from the count would be wrong on both, in opposite directions.

3Quality is a property of training

A larger model trained on less data, for fewer steps, at a lower resolution can be worse than a smaller one. Count is a budget, not a result, and nothing about it predicts how a face holds across a clip.

That is why this register publishes no rankings. Ranking would need a benchmark, and a benchmark is a measurement this register does not make.

4Clip length is architecture, not scale

How long a model can generate depends on how it handles time: whether the whole sequence is resident, whether it is processed in sections, how context is carried across them. None of that is visible in a count.

The longest published length in this register belongs to a mid-sized release and the shortest to one of the smallest. The count orders neither.

5What to do when only a count is published

Estimate the download, then treat everything else as unknown and test one clip. A single real run at the target resolution and length answers more than any amount of arithmetic from the count.

Where a count is a bound rather than a number, even the storage estimate has an open end. That is one more reason a bound and a measurement are different kinds of value.

6Why the register keeps the two columns apart

Merging size and hardware into one column would save space and manufacture errors. The register has pairs of rows within a rounding error of each other on size and described by their own vendors as needing entirely different machines.

So the columns stay separate, and each carries what its own vendor published rather than what the other column implies.

7Where the repository figures are kept

The techniques above are general. Which vendors have published what, under which licence and on what hardware, is recorded on the model pages, each figure quoted from the repository it was read from with its date.

• The size column — what a count is quoting
• Parameter count — what it fixes
• Storage footprint — the cost nobody states

Craft notes on reading releases. No row here is attributed to a vendor, and nothing on this page is a reading of anyone's licence obligations. The sourced material is on the requirements page. Related: Clip budget, A ten-minute check.