Load a model in LM Studio, set the context window to 64K, and the size next to the model name reads exactly what it read at 8K. It never shows the context window RAM at all. Ours said 18.85 GB in both cases, and in the two settings in between. That number is the weights, and it is the number people budget against when they ask whether a 31B model fits on a 48 GB Mac. The context window is real memory, it is charged separately, and on this model it came to 4.4 GB.
We measured the resident set of the llama.cpp backend process itself rather than trusting the display, on a studio work/test stack: an M4 Pro with 48 GB of unified memory, running gemma-4-31B-it-QAT at Q4_0.
What does the model size in LM Studio actually include?
Only the weights. We loaded the same model four times, at 8,192, 16,384, 32,768 and 65,536 tokens of context, and the reported size was 18.85 GB every time. Load time barely moved either, 3.6 to 3.9 seconds, because the weights are the thing being read from disk and they are identical in all four cases.
The backend process tells a different story. Here is its resident set immediately after each load, with nothing else running:
| Context | Reported size | Real resident set | Over the reported figure |
|---|---|---|---|
| 8,192 | 18.85 GB | 21.97 GB | +3.12 GB |
| 16,384 | 18.85 GB | 22.59 GB | +3.74 GB |
| 32,768 | 18.85 GB | 23.84 GB | +4.99 GB |
| 65,536 | 18.85 GB | 25.24 GB | +6.39 GB |
At the smallest setting the process already holds 3.12 GB more than the label, which is the KV cache for 8K plus the compute buffers. By 64K the gap is 6.39 GB. Anyone sizing a machine on the 18.85 GB figure is out by between three and six gigabytes before they have sent a single token.
How much RAM does a 64K context window really cost?
Take the differences between adjacent rows and the cost per token falls out.
Going from 8K to 16K adds 0.62 GB across 8,192 tokens, which is 79.4 KB per token. Going from 16K to 32K adds 1.25 GB across 16,384 tokens, which is 80.0 KB per token. Two independent intervals agreeing to within one percent is a straight line, and the line says this model charges 80 KB for every token of context you give it.
The 32K to 64K interval came out lower, 44.8 KB per token, which did not fit. Rather than explain it away we pushed a 25,407-token prompt through the model at the 64K setting and measured again. The resident set went to 26.33 GB. Extending the 80 KB per token line from the 8K baseline predicts 26.34 GB. The gap closed to 10 MB.
So the low reading was not the model being clever. It was the operating system: the allocation exists but the pages are not resident until something writes to them, and at 64K there is enough untouched cache to show up as a shortfall. Once the context is genuinely used, the cost is exactly linear. Measure a big context at idle and you will flatter it.
Why is 80 KB per token so cheap for a 31B model?
Because 50 of this model’s 60 layers stop growing after the first 1,024 tokens.
Reading the GGUF metadata off the local file gives the reason without any guesswork. gemma4.attention.sliding_window is 1024, and gemma4.attention.sliding_window_pattern runs 1, 1, 1, 1, 1, 0 repeating across all 60 blocks. Five sliding-window layers, then one global layer, twenty times over. Only the 10 global layers keep a KV entry for every token in the window. The other 50 hold 1,024 tokens each and never grow again.
The global layers are also the narrow ones. gemma4.attention.head_count_kv reads 16 for the sliding-window layers and 4 for the global ones, and key_length and value_length are both 512.
That gives an arithmetic prediction: 10 global layers, 4 key-value heads, 512 dimensions, two tensors for K and V, two bytes each at 16-bit. Ten times four times 512 times two times two is 81,920 bytes, or 80 KB per token. The metadata predicts the number we measured, to the kilobyte.
This is why the context is affordable and it is a property of the architecture, not of the machine. A 31B model with global attention on all 60 layers and 16 key-value heads would charge something closer to 8 MB per token at these dimensions, and 64K of it would not fit on this Mac at any quantisation. The sliding window is doing the work, and it is the single most useful thing in the metadata when you are deciding what context to ask for. We read tensor tables for the same reason in the GGUF quant naming audit: the file knows, and the interface does not tell you.
How much context fits on a 48 GB Mac?
For this model, comfortably more than most people set. Weights and 64K of context together sit at 26.33 GB in active use, which leaves headroom on a 48 GB machine for the operating system, a browser and the rest of a working day. The model’s own metadata declares context_length at 262,144, and the linear cost says a full 256K would add about 19.9 GB to the weights, landing near 39 GB. That is inside the machine on paper and would be an uncomfortable place to live in practice.
The more useful conclusion is about method. Three numbers were available for this question and two of them were misleading. The model manager’s size is the weights and ignores context entirely. The resident set at idle understates a large context because the pages have not been touched. The one that held up was the architecture in the GGUF metadata, which predicted the cost per token before we measured it and matched the measurement once the cache was genuinely in use.
Set the context you actually need rather than the maximum the slider allows, because at 80 KB a token the difference between 8K and 64K on this model is 4.4 GB you could be spending on the prompt processing that a long context is about to cost you anyway.