PhyseaWiki How AI actually works physea.ai →

Model-size calculator

How big a model can my computer run?

Enter how much memory you have and pick a precision level. The calculator estimates the largest model you can run and shows which common sizes (7B, 32B, 70B, and up) fit, using the rule that memory needed is roughly parameters times bytes-per-weight plus overhead.

Last updated 2026-07-25 · Physea Labs

The single number that decides what you can run locally is memory: your GPU’s VRAM, or, on a Mac, the unified memory shared between CPU and GPU. A model has to fit in memory to run well. If it does not fit, it either refuses to load or slows to a crawl.

Enter your memory below and pick a quantization level to see what fits.

You can run models up to about

Rule of thumb: memory needed ≈ parameters × bytes-per-weight, plus about 20% for the runtime and a modest context window. Longer context windows and bigger batches need more on top. Mixture-of-Experts models (e.g. a 235B-A22B) still need memory for all their weights, not just the active ones.

Run the arithmetic once and the result stops being a black box. At the default 24GB and 4-bit, the calculator uses about 0.55 bytes per weight plus 20% overhead, which works out to roughly 0.66GB for every billion parameters. 24 divided by 0.66 lands at about 36 billion, past the 32B tier and short of 70B, which is exactly what the sizes list below the headline number shows. Double the memory to 48GB and the ceiling roughly doubles too. Nothing about the arithmetic favors any particular memory size; it is a straight line, not a curve.

A few things worth knowing as you read the result. Quantization (covered in its own topic) is what makes large models practical at home: 4-bit weights are about a quarter the size of full precision for a small quality cost. The calculator’s own bytes-per-weight figures are not the naive one-eighth of 32-bit that a quick mental calculation would suggest; 4-bit is set at 0.55 GB per billion, not 0.5, because real 4-bit formats spend a little extra on a per-block scale factor stored alongside each group of weights, which the quantization topic covers in the exact block sizes real formats use. Context is the asterisk: a long context window needs extra memory on top of the weights, so leave headroom if you plan to feed in long documents. And for a Mixture-of-Experts model, the size shown is the total weight count it must hold, not the smaller number it uses per token.

One simplification worth naming rather than hiding: the calculator’s 20% overhead figure is fixed, but the real number is not. It has to cover the runtime’s own memory plus a short context window; feed the model a long document and the true overhead grows well past 20%, because the KV cache that holds a conversation’s running state is separate from the weights and grows with how much text is in play, not with parameter count. The hardware and VRAM page has a worked number: about 4.5GB just for a 32,000-token context on an 8B model, on top of the weights.

Your memory GB entered above ÷ bytes/weight set by quant level ÷ 1.2 runtime + context overhead Max parameters the number shown
Behind the number: the calculator runs this division once per quantization level, for every size on the list.

Nothing here is hidden or proprietary — it is the same rule of thumb from the 4-bit rule page, just run in reverse: instead of parameters times bytes-per-weight equals memory, it is memory divided by bytes-per-weight equals parameters.