Gemma 4 31B's Context VRAM is insane. Seems like an unusable model to me.

#2
by watchingyousleep - opened

I did the numbers crunching with Claude and here's how much VRAM you'd need to run this model at full context.
Model used: UD-Q4_K_XL (18.8 GB)
Model Size in VRAM without Cache: 21.07 GB
β€” No KV Quantization (0.85 MB/token) β€”
8K: ~7 GB
32K: ~27 GB (48GB of VRAM required)
64K: ~54 GB
128K: ~109 GB
256K: ~218 GB

β€” Q8_0 (0.25 MB/token) β€”
8K: ~2 GB (Might fit in 24GB of VRAM)
32K: ~8 GB
64K: ~16 GB (37GB of VRAM required)
128K: ~32 GB
256K: ~64 GB

β€” Q4_0 (0.038 MB/token) β€”
8K: ~0.3 GB
32K: ~1.2 GB
64K: ~2.4 GB (Might fit in 24GB of VRAM)
128K: ~4.9 GB
256K: ~9.7 GB

These numbers are rough and were gained using a setting of 100, 2048, and 8192 empty context with the KV Cache settings. Tests were done on LM Studio on Windows 11. They aren't perfect but plenty to get the point across. Q4_0 is the only one that looks remotely usable if you ask me. For reference Qwen3.5 27B is somewhere around 0.003MB per token at Q8_0.

watchingyousleep changed discussion title from Should I just ignore this model if I don't have at least 64GB of VRAM? Context RAM usage is absurd to Gemma 4 31B's Context VRAM is insane. Seems like an unusable model to me.

The model has a fixed 3.6GB SWA KV cache that you need to account for.

With --fit and 32GB of VRAM the UD-Q4_K_XL model with f16/f16 (no KV quantization) leaves me with over 100,000 context.

The model has a fixed 3.6GB SWA KV cache that you need to account for.

With --fit and 32GB of VRAM the UD-Q4_K_XL model with f16/f16 (no KV quantization) leaves me with over 100,000 context.

I switched to llama.cpp to test it further when I had more time on my hands and it appears that my above post was just an LM Studio bug. In llama.cpp I'm seeing 22.3GB of VRAM usage at 16384 context at FP16.

watchingyousleep changed discussion status to closed

If you are the only user add the
-np 1
option to your llama.cpp config. I will reserve space for a single SWA KV instead of the default 4.

Ollama Gemma 4 26B A4B KV-Cache Measurement

i did some investigating about your convo and hope this helps.

This note summarizes a local measurement of Ollama memory allocation for gemma4:26b while varying num_ctx from 8k to 256k tokens.

Gemma 4 Ollama memory chart

System

  • Machine: MacBook Pro Mac16,7
  • Chip: Apple M4 Pro, 14-core CPU (10 performance, 4 efficiency)
  • Memory: 48 GB unified memory
  • Architecture: arm64
  • OS: macOS 15.6 (build 24G84)
  • Measurement time: 05/02/2026, 21:04:11 CDT; raw report timestamp 2026-05-03T02:04:11.646Z

Model

  • Ollama model: gemma4:26b
  • Family: gemma4
  • Parameter size reported by Ollama: 25.8B
  • Quantization reported by Ollama: Q4_K_M
  • Installed model file size reported by Ollama: 17,987,581,215 bytes (~16.75 GiB)

Script And Method

Script path in the Gary repo:

scripts/diagnostics/measure-ollama-kv-cache.mjs

Command run:

npm run diagnose:ollama-kv -- --max-tokens 262144 --step-tokens 8192 --no-manage-ollama --output output/ollama-kv-measurement-256k.json

The script ran in context mode, which is designed for runtimes that preallocate KV cache from num_ctx rather than growing only with actual prompt tokens. For each 8k-token step it:

  1. unloaded the currently loaded Ollama model;
  2. waited briefly;
  3. started a tiny one-token prompt with options.num_ctx set to the target context size;
  4. sampled Ollama process RSS and Ollama /api/ps reported size;
  5. wrote partial JSON after every probe;
  6. fit memory as fixed model allocation + per-token allocation.

Gary-managed services were stopped before the run. The command used --no-manage-ollama because an existing Ollama server was already reachable on 127.0.0.1:11434; attempting to start a new sandbox-managed Ollama process could not bind that local port from this shell.

Results

The run completed 32 samples from 8,192 tokens through 262,144 tokens.

The script's RSS-based fit reported:

  • Fixed/model memory: 18.487 GiB
  • KV/cache slope: 0.02267 MiB/token
  • KV/cache slope: 0.18132 GiB per 8,192 tokens

Ollama's own API-reported model size produced a slightly cleaner fit:

  • Fixed/model memory: 18.270 GiB
  • KV/cache slope: 0.02232 MiB/token
  • KV/cache slope: 0.17855 GiB per 8,192 tokens

Selected API-reported allocation points:

Context Ollama API size Peak RSS delta
8,192 18.51 GiB 18.64 GiB
65,536 19.68 GiB 19.95 GiB
131,072 21.12 GiB 21.45 GiB
196,608 22.56 GiB 22.81 GiB
262,144 23.99 GiB 24.42 GiB

Interpretation

For this hardware, model, Ollama build, and quantization, the measured context allocation was roughly 0.18 GiB per 8k tokens, or ~0.022 MiB/token. That is below a rough 0.25 GiB per 8k tokens planning estimate but close enough that 0.20-0.22 GiB per 8k tokens looks like a practical target if some overhead is desired.

At 256k context, Ollama reported about 23.99 GiB resident for the model plus context allocation. This was feasible on a 48 GB unified-memory M4 Pro when Gary was stopped, though macOS whole-system free memory dropped very low during the largest probe. Ollama API-reported size was smoother than process RSS, so I would treat the API-size fit as the cleaner estimate and RSS as a sanity check.

Raw data:

Screenshot 2026-05-02 at 9.09.36β€―PM

Sign up or log in to comment