Checking a weights release in ten minutes
Most of what a decision needs from a weights release can be established in ten minutes: which version the files are, what the licence field says, what the hardware statement actually claims, and which of the five columns the repository leaves empty. As of 2026-09-12.
| Question | Where to look |
|---|---|
| Which versions have weights | The files or the organisation listing |
| What the licence says | The licence field, then the file list |
| What hardware is claimed | The readme, or a memory table |
| What comes out | A model info table, or the release notes |
Inclusion rule. Questions answerable from a repository in a short session. A question needing a test run is excluded, because it cannot be answered by reading. Order. In the order the checks should be done.
1Start with which version has files
A family name covers everything a vendor has published, and a hosted service may sell a version that was never released. Establishing which numbered releases actually have downloadable weights takes a minute and it anchors everything else.
Every other value belongs to one of those releases. A licence, a memory figure or a resolution recorded against a family rather than a version is a value that cannot be checked later.
2Read the licence field, then the file list
The field gives a name. The file list says whether an acceptable-use policy or a supplementary notice sits beside it, and those add restrictions the name does not carry. A repository with both looks identical to one with neither at a glance.
Where the name is a standard one, the reading stops. Where it is a company's, the document has to be opened, and the plan decides how carefully.
3Work out which kind of hardware figure is on offer
The wording settles it: requires, minimum and from mean a floor, while peak, used and consumed mean a measurement of one run. A floor can be matched against a card; a peak can only be matched against a similar machine.
Then find the setting. A figure with no resolution, no frame count and no precision describes one point in a space with four dimensions, and it cannot be adjusted towards the work planned.
4Collect the output values as a set
A frame size, a frame rate and a clip length together describe what comes out. Any two of them leave a question, and the missing one is usually the rate, which is the cheapest of the three to publish.
Write down all three where they exist and mark the gaps. A specification with a gap is still usable; a specification whose gap has been filled by assumption is not.
5Note the date, not just the values
Model cards and readmes are edited without announcements. A value read today is a fact about today, and a note that says the licence is permissive will not survive a question six months later.
Recording the page and the date turns a claim that would have to be researched again into one that can be rechecked in a minute. That is the whole discipline behind this register.
6Stop before the parts that need a run
Quality, consistency across a long clip, how a face holds through a cut and how often a generation has to be repeated are all outside a repository. Ten minutes of reading cannot reach them and no amount of careful reading will.
The honest end of the check is a list of what the release states, a list of what it leaves open, and one test clip at the target configuration.
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.
- How read — what counts as a published statement
- The five columns — what each one holds
- Card or repository — where the licence value sits
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: Two figures, Limits of a register.