Put the parameter count on the model card

One number that every sizing starts from

The parameter count belongs on the model card as a plain number because every estimate of the hardware a model needs begins with it. Weights take roughly the parameter count times the bytes per parameter: 2 bytes in 16-bit, 1 in 8-bit, half a byte in 4-bit. A buyer who cannot find the count cannot do that sum, cannot pick a GPU, and cannot price the job. Write the count, the precision the weights ship in, and the file size of the download.

This is the single fact that turns a model page into a cost estimate. Without it, a buyer guesses from the name, and model names are not a reliable unit.

Why the name is not enough

Plenty of model names carry a size, something like 8B or 70B, and plenty of buyers read it as the count. The name is rounded, sometimes generously, and sometimes it describes a family rather than the checkpoint in front of them. A model with 7.6 billion parameters and one with 8.4 billion could both be called 8B, and that difference is more than a gigabyte of weights in 16-bit.

Other names carry no size at all. A buyer meeting one of those has nothing to start from except the size of the files, which they only learn after a download that may run to tens of gigabytes.

The count should also match the checkpoint. A family page that gives one size for several checkpoints, or a figure from an early technical report that a later release changed, leaves the buyer with a number that is close and wrong, which is harder to catch than a missing one.

Total and active parameters are different facts

Some models send each token through only part of their weights. For those, two numbers matter and they answer different questions. The total count decides how much memory the weights occupy, because all of them have to be loaded. The count used per token bears on how much arithmetic each token costs.

Publishing only the smaller number makes a model look cheaper to host than it is. Publishing only the larger one hides the reason it may be quick. Print both, labelled, and say which is which in words rather than with an abbreviation a buyer has to look up.

If the share of weights used per token depends on a setting, say which setting and give the figure at the default. A best case quoted as the only number is the one buyers will copy into their sizing sheets.

Quantised files need their own line

When a maker publishes several builds, or hosts publish quantised builds of its weights, the parameter count stays the same and the size changes. A 4-bit build of an 8 billion parameter model holds the same parameters as the 16-bit original in about a quarter of the space. Buyers sometimes read a smaller file as a smaller model, and expect it to behave like one.

List each published build with its precision and its file size, and say plainly that they share a parameter count. If you have measured how answers differ between builds, say what you measured. If you have not, say that you did not evaluate the quantised builds, so a buyer knows the check is theirs to run.

What the count lets a buyer work out

With a count in hand, the first question is which card can hold the weights at all. A model of 34 billion parameters in 16-bit needs about 68 GB for weights alone, which rules out a 48 GB card and leaves an 80 GB H100 with some room. The same model in 4-bit is about 17 GB, which changes the shortlist entirely.

The second question is what that card costs. The GPU rate table lists 51 cards with an on-demand price, and the lowest listed rate for an H100 SXM 80GB is $1.68 an hour. A buyer can only connect your model to a line in that table once they know its size.

The arithmetic gives the floor, not the answer. The key-value cache and activations need memory on top, they grow with context length and the number of requests served together, and no single figure covers them. Say so beside the count, so the buyer does not take the weights figure as the whole bill.

Buyers also use the count to set self-hosting beside a hosted alternative. If a model needs a pair of large cards around the clock, the monthly rental can be compared with a token price for the same volume, and the count is what makes that comparison possible at all.

Where to put it, and in what form

On the model card, near the top, as a number with its unit: parameters, total and per token if they differ. Then the precision of the published weights, and the size of each published file or quantised variant. A small table works, as long as it is text and not an image.

Keep the same order on every model you publish. Buyers comparing your small and large checkpoints read down a column, and a count that sits in a different paragraph on each page gets missed. The same rule applies to the license, covered in stating your license in plain words.

Hosts can copy this table. A host listing your model on its own page has your card as the obvious source for the count, and if the card does not state it, the host writes whatever it inferred. A number on your page is the one that spreads, and a missing one leaves room for several.