How to read a repository memory table
A memory table gives one figure per configuration. Reading it well means locating the row closest to the work actually planned, checking which settings are held constant across rows, and noticing which variables the table never moves. As of 2026-09-12.
| Column | What it fixes |
|---|---|
| Resolution | The pixels per frame the figure was measured at |
| Frame count | How many frames were held at once |
| Memory | The measurement, peak or floor depending on the wording |
| Precision | The bytes per parameter assumed, when it appears at all |
Inclusion rule. Columns that appear in memory tables across published video releases. A column that is frequently absent is listed, because its absence changes how the table reads. Order. In the order the columns usually appear, left to right.
1Find the row before reading the number
The headline figure in a table is usually the largest configuration, because that is the impressive one. The row that matters is the one closest to the resolution and clip length actually planned, and it is often two rows down.
If no row matches, the useful question is which direction the gap runs. A planned configuration smaller than every published row is a reasonable bet; one larger than all of them is not.
2Check what is held constant across rows
A table that changes the resolution between rows and keeps everything else fixed supports interpolation. One that changes the resolution and the model size at the same time describes two runs and no gradient.
The second kind is common and looks like the first. Reading a ratio out of it produces a number that cannot be checked against anything.
3Notice the variables the table never moves
Batch size, numeric precision and offload state are the three that usually sit outside a table entirely. Each of them can change a figure by a large factor, and a table that names none of them is describing one point in a four-dimensional space.
A table that does state one of them is worth more than a table with more rows. Stating batch size in particular removes the largest hidden multiplier.
4A peak and a floor are read in opposite directions
A peak transfers upward: a card larger than the one measured will also finish. A floor transfers downward badly and upward trivially. Neither converts into the other, and the wording in the table is the only clue which one is on offer.
Where a repository writes requires or minimum or from, it is offering a floor. Where it writes peak or used or consumed, it is offering a measurement of one run.
5Throughput rows are a different table
Some tables mix durations in with memory figures. A duration is a capacity number for a class of card and it ages differently: inference code gets faster while weights stay the same size.
Treat them as two tables that happen to share a page. Planning feasibility from the memory rows and capacity from the timing rows keeps both honest.
6When a memory table is the whole hardware statement
Several releases publish nothing about hardware except a memory table, which means the card, the formats and the driver stack are unstated. The figures then describe a workload rather than a machine.
Those figures are still worth having for comparing workloads. They cannot answer whether a particular card qualifies, and no amount of careful reading will make them.
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.
- Requirements — every hardware figure as published
- Peak memory — why it is not a minimum
- Stated settings — which dials get named
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: Count to download, Clip budget.