A model's weights take parameters times bytes per weight. At 16-bit a weight is 2 bytes, at 8-bit 1 byte, at 4-bit half a byte.
- So a 7 billion parameter model's weights are 14 GB at 16-bit, 7 GB at 8-bit, 3.5 GB at 4-bit. Quantisation, storing weights at fewer bits, is what moves a model from not fitting to fitting.
- That is the floor. Real 4-bit files are somewhat larger because they store scales, and a running model needs more memory for its context and working buffers.
- The local AI readiness check sets the weights of each size against the graphics memory the browser let it allocate and verify. It does not predict tokens per second, and nor does this guide.
The short answer
Your laptop can run a model whose weights, plus room for its context, fit in memory its graphics chip can use. Work out the weights with the formula below, find out how much memory you have, and leave headroom. Whether it runs fast enough is a separate question that depends on the runtime and the model, and no figure here answers it.
We have no recorded runs of this test in our validation notes yet, so this guide quotes no measured results. Every line and constant below is the one the test's code applies.
The formula
Weights in bytes = parameters x bytes per weight. Bytes per weight: 2 at 16-bit, 1 at 8-bit, 0.5 at 4-bit. The check draws the table for 1, 3, 7, 8, 13, 14, 32 and 70 billion parameters, the sizes models are commonly published at, without naming any model.
Worked through for 7 billion: 7 billion x 2 bytes is 14 GB; x 1 byte is 7 GB; x 0.5 bytes is 3.5 GB. For 70 billion at 4-bit, 35 GB.
These are decimal gigabytes. Memory tools often print GiB, which are about 7% larger, so a figure in GiB holds a little more than the same number in GB.
What quantisation changes, and what it does not
Quantisation stores each weight in fewer bits. Halving the bits halves the weights' memory and the data read for every generated token. It can cost some quality, by how much depends on the model and the method, which is a question for the model's own documentation, not for a memory check.
It does not shrink the context. The memory a runtime keeps for the conversation so far grows with its length, on top of the weights, and the check does not add it.
What the browser check measures
It reads whether the browser offers WebGPU, whether the adapter is a fallback on the processor, and whether it offers shader-f16. Then it runs the VRAM test's allocation and reports the largest size whose weights fit at each precision. At the default 2 GiB cap, the largest size in the table whose 4-bit weights fit is 3 billion; at the 8 GiB cap, if the browser allows it all, 14 billion. Raise the cap to see how far your browser goes.
It also shows memory bandwidth, because generation speed depends on it, without turning it into tokens per second. A native runtime usually reaches more of the hardware than a browser one, so a size that fits here will generally fit there too.
Terms used here
Questions
- Does system RAM count?
- On an integrated chip or Apple silicon the graphics memory is system RAM, so yes, up to what the system lets the chip use. On a discrete card, runtimes can split a model between the card and RAM, which fits more and runs slower.
- Why not estimate tokens per second from the bandwidth?
- Because the runtime, the model's design, the context length and the browser all change it, and none of them can be known from this page. A number would be a guess.