One family, one column, one page

Each page here takes a single family and a single column of the register and says what the vendor published in it, what the vendor attached to it, and which questions it still leaves open. The value and the qualifying columns are read straight off the entry. As of 2026-09-22.

Fifteen families and five columns make seventy-five possible pages, and rather fewer worth writing. A cell earns a page when the vendor put something specific in it: a figure with the setting it was measured at, two numbers for one run, a count broken into components, a licence name nobody else uses. It also earns one when the cell is empty and the emptiness is strange for that column.

A cell does not earn a page when the value is a name and a shrug. Eight releases here carry Apache 2.0 or MIT with nothing beside it beyond the sentence that says so, and eight pages reading the same short string would be eight pages of padding. Those cells still appear in full on the family entry and in the column summary.

1How many pages each column earned

Inclusion rule. One row per column of the register. A column with no deep pages would keep its row and say so, because an empty column is a finding about the vendors rather than about the register. Order. Alphabetical by column name.

2The licence column

• HunyuanVideo licence — The weights carry tencent-hunyuan-community rather than a standard permissive name, which means the terms have to be read rather than recognised.
• CogVideoX split licence — The 2B model is Apache 2.0 and the 5B carries a separate project licence, so in this family the terms are a property of the model rather than the family.
• SVD commercial pointer — The card is tagged stable-video-diffusion-community and sends commercial use to a separate licence page, so the tag starts the question, not the answer.
• Borrowed licence name — The tag is stabilityai-ai-community, a licence named after a company that did not publish these weights, which is a pattern worth a row of its own.
• skywork-license — The tag is skywork-license, a document written by the same company that published the weights, so the name at least identifies who to read and who to ask.
• Commercial use answered — The NVIDIA Open Model License is vendor-written, and the card states in plain words that the models are commercially usable, which is rare in this column.
• Wan, licensed and unlicensed — Two Wan releases are Apache 2.0, and the version sold by the second has no published weights, so no licence attaches to what people actually buy.

3The size column

• Pyramid Flow, no count — Every other family in the register states a size.
• A hedged parameter count — The repository gives the size as over 13 billion parameters, a hedged figure that will not sit beside the exact counts published elsewhere here.
• Size in the model name — The parameter count is carried by the model names, 2B and 5B, and in this family the size also decides which licence and which memory figure apply.
• Counted in two parts — Ten billion parameters for the diffusion model and 362M for the video autoencoder, published as two figures because they are two components of one release.
• VAE and DiT apart — The card gives 175M for the VAE and 2.8B for the DiT rather than one total, which names the architecture at the same time as the size.
• Thirty billion — The largest single count in the register, published in the repository introduction, and matched by memory figures in the high seventies of gigabytes.
• Size in the release name — The parameter count travels in the release name rather than in a table, which ties every hardware and resolution figure on the page to that one model.
• 2B with no floor — The card shows 2B params and gives a timing on an A100 rather than a memory figure, so the smallest count here comes with the least hardware guidance.
• 13B against 6GB — The count is published as the size the memory floor belongs to, which makes this the row where the two columns diverge furthest in the register.
• Three sizes, one table — Three variants in one family, with memory stated for the smallest and the largest at the same output size, which isolates what the count changes.
• Two sizes, two machines — Each published size carries its own hardware statement, one naming eight data-centre cards and the other a single consumer GPU, inside one repository.
• Counted to the unit — An exact count rather than a rounded one, on a card that also gives memory to two decimal places and names the GPU architectures it supports.
• The 5B that runs at home — The smallest published Wan release is a 5B text-to-video and image-to-video model at 720P and 24fps, and it carries the consumer hardware note.
• One size, several builds — One parameter count with distilled and fp8 variants published beside it, which is a hardware statement made by release engineering instead of by a figure.

4The hardware column

• Allegro memory pair — One run, two memory figures.
• 60GB and 45GB — Two peak memory figures at two pixel sizes, both measured on a single 80G card, which makes the pair a scaling statement rather than a minimum.
• From four gigabytes — The lowest published memory figure in the register, stated in FP16 for the 2B model, with 5GB and 10GB figures for the larger releases in the same family.
• Sixty gigabytes and an H100 — A figure and a recommendation together: roughly 60GB of VRAM on one card, with at least one H100 recommended, for a release that outputs 480p.
• Never below 72GB — Three peak figures at three configurations, from 78.55 GB down to 72.48 GB, all at batch size one, which makes the floor of the published range high.
• One card or four — The repository states what sharding buys in its own measurements, on H100 or H800 cards, for the same 11B weights at the same 768px output.
• A stopwatch, not a floor — The card states about 180s on an A100 80GB card and no memory minimum, so the hardware column here answers a question nobody asked first.
• Six gigabytes, named cards — The lowest floor in the register is published with the output it buys and with the card generations it was tested on, which is what makes it checkable.
• Offloading, no numbers — The card talks about offloading and never states a memory figure, which leaves the technique named and its effect unmeasured.
• 14.7GB or 51.2GB — Two peak figures for the same output size on two model sizes, which isolates what the parameter count costs when nothing else changes.
• Eight H100s or one 4090 — Hardware is stated as a count of a named card for each published size, with a separate 12GB floor for a distilled fp8 build of the smaller model.
• 32.54 GB, three architectures — A memory figure to two decimal places with Ampere, Hopper and Blackwell named as supported, for a 2B model that outputs five seconds at 720P.
• No card, no figure — A 13.6B release that publishes its parameter count and its output size and says nothing at all about the machine it runs on.
• A 4090 and 80GB — Two hardware answers in the same repository, one naming a consumer card with a timing and the other a minimum of 80GB for different commands.
• No minimum stated — No memory figure appears in this repository.

5The resolution column

• Pixels as a setting — The pixel dimensions on this release appear only as configurations of the memory table, so the resolution column records no output size for it.
• Two sizes, two releases — Two output sizes across two releases in one family, each attached to the model that produces it, which is what makes the pair readable.
• 480p, for now — The output size is stated as 480p and described as the current capability, which is a hedge about time rather than about the architecture.
• 720 x 1280, in full — The card gives the output size, the frame count, the seconds and the frame rate together, which is the most complete output row in the register.
• Sizes from the table — 768px768px and 544px992px appear as the configurations of the memory table, so the output sizes are documented as measurement settings.
• 256px and 768px — A pair of supported sizes rather than a single output, stated for the 11B model, with a memory figure published for the larger one only.
• 576x1024 from training — The card describes the model as trained to generate 25 frames at 576x1024 given a context frame of the same size, which ties the output to the input.
• No frame size given — The repository publishes a clip length, a frame rate and a memory floor, and never says how large each of those 1800 frames is.
• One size per checkpoint — Two checkpoints with one resolution each, and the clip length each one runs for, on a card that publishes neither a parameter count nor a memory figure.
• 540P and 720P in pixels — The repository writes out 544 x 960 for 540P and 720 x 1280 for 720P, which removes the ambiguity a marketing tier name usually carries.
• A default set for speed — The 4.5B default is 720x720, described as chosen to accelerate inference, with arbitrary resolutions said to be supported.
• 720P at 16FPS — The card publishes the output size, the frame rate and the clip length in one sentence, next to an exact memory figure for the same run.
• Length instead of size — This repository publishes a sixty second ceiling and never states an output size, which is the opposite of the usual gap in this column.

6The length column

• 129 frames as a setting — The frame count on this release appears as part of a memory measurement, not as a ceiling, and no frame rate is published anywhere beside it.
• 161 frames in seconds — The repository states up to 161 frames on its newer release and calls the result five or ten seconds, which leaves the frame rate implied.
• No length recorded — The repository states a resolution, a parameter breakdown and a memory figure, and never says how long a clip the release produces.
• Frames, seconds, rate — All three length values published together, so the output duration needs no conversion and no assumption about playback rate.
• 204 frames, no rate — The ceiling is published in frames with no frame rate anywhere in the repository, so the clip length in seconds is not something this release states.
• Length as a code rule — The constraint is published as candidate values of 4k+1 under 129 frames, which is what the code enforces rather than a clip length.
• Four seconds, admitted — The card gives 25 frames and describes the output as rather short, at four seconds or less, written as a limitation rather than as a specification.
• A minute, at a price — The one minute figure is published as what 6GB of memory buys, which gives it a price no other length value in the register carries.
• Ten seconds, or five — Two checkpoints with a clip length each, both at 24 FPS, which is a complete length statement on a card that publishes no memory figure.
• A frames-to-seconds table — The repository publishes a table converting frame counts into durations, from 257 frames for ten seconds up to 1457 for sixty.
• No ceiling on frames — Frames are an argument with no stated maximum, so the length column records an absence on a release that documents its hardware carefully.
• Five seconds, stated — The clip length is published in the same sentence as the frame rate and the output size, which makes it the cleanest length value in the register.
• Minutes, with no number — The length claim is qualitative: output is described as minutes-long with no frame count, no seconds and no rate attached to it.
• Up to sixty seconds — The longest published figure in the register, stated on the 13B model in the vendor's own release notes, with no frame rate and no frame size beside it.

Where two families land in genuinely opposite places on one of these columns, the pair gets a page of its own under contrasts rather than a mention on both entries.

Also in the register: Models, Hosted, Contrasts, Fields, Questions, Terms, Learn, Data. What a release has to publish is set out on the reading page.