NodeValid

Published video-model weights, licences and hardware notes

Autoencoder, and why it is counted apart

A video autoencoder compresses frames into a compact representation and reconstructs them afterwards. It is trained separately from the denoising model, which is why some releases publish its parameter count on its own. As of 2026-09-22.

Where the autoencoder sits in a runFrames are compressed, the generation happens in the compact space, and the result is reconstructed, so the autoencoder is loaded at both ends of a run.EncodeFrames compressed intoa compactrepresentationa small tensorGenerateThe large model worksin that compact spacea generatedtensorDecodeThe representationexpanded back intoframesSmall in parameters, present at both endsTwo releases here publish this component's count separately from the main model.
Fig. 1 Two passes through a small component, around one pass through a large one.
Why a separate count for this component is worth having. Recorded 2026-09-22.
ReasonWhat it enables
It is trained separatelyA reader can tell the two models apart
It can be replacedSwapping decoders becomes a visible option
It is smallA total would hide it entirely
It runs twiceIts cost is not proportional to its size

Inclusion rule. Reasons a release might publish this component on its own. A reason that applies to every release is listed, because the practice is not universal. Order. From the reason about training to the reason about run time.

1A total would hide the decomposition

One release in this register publishes a ten billion parameter diffusion model and a 362M autoencoder. A combined figure would be arithmetically true and would tell a reader less.

Another publishes 175M for the autoencoder and 2.8B for the transformer, with labels that name the architecture. The labels carry information the numbers do not.

2Being small does not make it cheap

The component runs at both ends of a generation and works on full-resolution frames, so its memory cost is not proportional to its parameter share. A four per cent share of the weights is not a four per cent share of the run.

That is one more reason the size column does not predict the hardware column, and one more reason this register keeps them apart.

3Where this component is visible in the register

Two families publish this component's count separately from the main model, one as a 362M figure beside a ten billion parameter model and one as a 175M figure beside a 2.8B transformer.

In both cases the memory figure on the same page is far larger than either count would suggest, which is the clearest evidence in the register that the size column does not predict the hardware column.

A reading note, not an entry: no vendor value appears on this page. Where the register records this term for a particular release, it is on the size column and on that family's own page. Nearby terms: Diffusion transformer, Peak memory.