Size: what a parameter count settles

The size column holds the parameter count a repository states, attached to the variant it was stated for. It is the most quoted field on these pages and the least decisive one: two releases of roughly the same size here state hardware figures that are nothing alike. As of 2026-09-12.

Inclusion rule. Families whose repository states a parameter count for a published release. A count stated for one variant is never applied to the rest of the family. Order. Alphabetical by family name.

1A count is a property of the file and not of the run

Every value here is what the vendor wrote, kept beside the release it describes. HunyuanVideo publishes over thirteen billion parameters. LTX-Video publishes a 13B model with distilled and fp8 builds around it. Mochi 1 publishes ten billion and counts a 362M video autoencoder separately. Wan's smallest published release is 5B.

None of those is a hardware requirement. What a run consumes depends on precision, output size, clip length and how much is pushed out to system memory, and a count tells you nothing about any of the four. Size and hardware are separate columns here because folding them together is the most reliable way to plan for the wrong machine.

2Two thirteens that behave nothing alike

HunyuanVideo and LTX-Video both publish around thirteen billion parameters and their hardware entries have almost nothing in common. One states sixty gigabytes of peak memory at its larger setting, measured on a single 80G card. The other states no minimum whatsoever and publishes smaller builds instead.

Put side by side they settle the question of whether the count predicts the requirement. It does not. What actually differs is the precision each release assumes, the settings its figures were measured at, and whether the vendor shipped a reduced build, and only the last of those is visible from this column at all.

3When the number needs a second number beside it

Mochi 1 states its autoencoder separately rather than rolling it into the headline, which is the honest way to publish a component that would otherwise disappear inside a rounded total. CogVideoX carries its sizes in the model names, and in that family the name decides which licence applies and which memory floor does.

So the cell is never a bare figure. It carries the variant, and where a vendor counted something on its own the register keeps it on its own. One rounded number per family would read more cleanly and would stop corresponding to anything written in the repository.

• Smallest published model
  A 5B text-to-video and image-to-video model at 720P and 24fpsTI2V-5BWan-Video, Wan2.2 repository / recorded 2026-09-12
• Published models
  A 13B model, with distilled and fp8 variants published for lower VRAM and faster inferenceseveral variantsLightricks, LTX-Video repository / recorded 2026-09-12
• Model size
  Over 13 billion parametersstated in the repositoryTencent-Hunyuan, HunyuanVideo repository / recorded 2026-09-12
• Model size
  A 10 billion parameter diffusion model, with a 362M parameter video autoencoderstated in the repositoryGenmo, Mochi repository / recorded 2026-09-12

4Sources

Values in this column are quoted from the Mochi repository, the LTX-Video repository, read 2026-09-12, and from the repositories linked on each model page. The other columns are listed on fields; what counts as a published statement is on how read. Next column: Hardware, Resolution.