Ollama 'Model Requires More System Memory'? Fix the RAM Check That Blocks Your Model (2026)

By RunAIHome Team · 13 min read
ollamatroubleshootingsystem-ramlocal-llmlinux

TL;DR: This error is Ollama’s pre-flight check, not your OS running out of memory. Ollama estimates what the model needs (weights + KV cache) and compares it against free RAM — plus free swap on Linux. When the estimate loses, nothing loads. The fix is one of three moves: free/raise the available side (close apps, fix container limits, add swap), shrink the required side (smaller quant, lower context), or fix the GPU detection that silently dumped the whole model onto system RAM.

What you’ll be able to do after this guide:

  • Decode the two numbers in the error and know which side of the comparison — required or available — is actually lying.
  • Spot the three environments that fake a low “available” number: Linux page cache/ZFS ARC, WSL2’s default 50% cap, and Docker/Kubernetes memory limits.
  • Unblock a load with a swapfile in two commands, and know when that’s a fine loader cushion versus a thrashing trap.

Honest take: nine times out of ten this error is telling you the truth — the model genuinely doesn’t fit, and the right response is a smaller quant, not a bigger swapfile. But the tenth case (containers, cached memory, undetected GPUs) wastes hours because the “available” number is wrong, and that’s the case worth learning to spot in 30 seconds.

You ask Ollama to run a model and get this instead of a prompt:

$ ollama run deepseek-r1:14b
Error: model requires more system memory (10.2 GiB) than is available (2.9 GiB)

Both numbers come from Ollama, not from your OS. The left number is Ollama’s estimate of what the model needs to run on CPU (or the CPU-resident share of a partial GPU offload): weights plus KV cache for the configured context. The right number is what Ollama thinks it can get — and on Linux that figure is free RAM plus free swap, which is why the server log for a failed load prints a line like system memory total=39.2 GiB free=37.3 GiB free_swap=0 B. The check runs before anything is loaded, and setting "use_mmap": true does not bypass it — a machine with 13.6 GiB free was still refused a 17.7 GiB model with mmap explicitly enabled (ollama issue #7942).

Everything below is tested logic against Ollama v0.32.0 (July 13, 2026); the check has behaved this way since at least the 0.5.x releases, and the GitHub reports span 0.4 through 0.9+.

30-second diagnosis

Read the error’s two numbers, then find your row:

What you seeLikely causeFix
”Available” is far below what free -h shows in its available columnLinux cache accounting (page cache, ZFS ARC)Fix 2
Running in Docker, WSL2, or Kubernetes and “available” is suspiciously round (8 GiB, 4 GiB)Container/VM memory limit, not host RAMFix 3
You have a GPU and this model used to load fineGPU not detected → silent CPU fallbackFix 4
”Required” looks absurdly large for the modelThe estimate is honest — quant + full-context KV cache + parallel slots add upFix 5
Both numbers are honest and required > your RAMThe model doesn’t fitFix 5, swap (Fix 6), or different hardware

Fix 1: confirm what’s actually free

On Linux, trust the available column, not free:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        8.2Gi       4.9Gi       0.5Gi        18Gi        22Gi
Swap:          8.0Gi          0B        8.0Gi

free (4.9Gi here) is memory nothing has touched; available (22Gi) adds the page cache the kernel would happily evict for you. A model needing 10 GiB fits comfortably on this machine — but if Ollama’s check keys off the low figure, you get refused anyway (that’s Fix 2).

On Windows, open Task Manager → Performance → Memory and check “Available”. On macOS, Activity Monitor’s Memory tab. Close the obvious offenders first — browsers with 40 tabs, Electron apps, another inference server holding a model resident. If a previously-working setup degrades over days, restart the Ollama service before debugging anything else: users have reported the available number sinking across long uptimes until a restart clears it (issue #10256).

Also check whether Ollama itself is the tenant: ollama ps lists loaded models. A previous model kept alive by OLLAMA_KEEP_ALIVE may be squatting on the RAM your new model needs — ollama stop <model> evicts it immediately.

Fix 2: the Linux cache traps

Two related accounting problems produce a fake-low “available” number on Linux:

Page cache counted as used. A Docker-on-Linux user with 32 GB of RAM was refused a deepseek-r1:14b load — “requires 10.2 GiB, available 2.9 GiB” — while roughly 20 GiB sat in reclaimable cache; Ollama’s log reported free=5.0 GiB on a box that was mostly cache (issue #11497, v0.9.6). The kernel would evict that cache the moment a real allocation asked, but a conservative pre-check doesn’t know that. Quick test:

$ sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
$ ollama run deepseek-r1:14b

If the load succeeds after dropping caches, you’ve confirmed the accounting problem. Don’t script drop_caches as a permanent fix (it throws away useful cache, including your model files’ warm pages — cold loads get slower); treat it as a diagnostic, and add swap headroom (Fix 6) as the durable workaround.

ZFS ARC. On TrueNAS, Proxmox-with-ZFS, and any ZFS root, the ARC deliberately grows to consume most idle RAM and doesn’t report as ordinary reclaimable cache — which leads Ollama to refuse models that would run fine (issue #5700). Cap the ARC so the accounting matches reality, e.g. limit it to 8 GB:

# echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

(Persist via /etc/modprobe.d/zfs.conf with options zfs zfs_arc_max=8589934592.) If you’re running models off a NAS box anyway, we’ve laid out why that’s usually the wrong home for an inference server in When NOT to Use a NAS for Local LLMs.

Fix 3: container and VM walls

Inside Docker, WSL2, or Kubernetes, Ollama sees the sandbox’s memory, not your machine’s.

WSL2 is the sneakiest because the default is generous-sounding and silently small: builds since 20175 cap the VM at 50% of host RAM or 8 GB, whichever is less (Microsoft Learn). A 64 GB Windows tower running Ollama inside WSL2 with no config file is an 8 GB Linux machine as far as Ollama is concerned. Fix it in %UserProfile%\.wslconfig:

[wsl2]
memory=48GB
swap=16GB

then wsl --shutdown from PowerShell and relaunch.

Docker Desktop (macOS/Windows) applies its own VM limit under Settings → Resources → Memory — raise it there, not in the container. On Linux, check whether the container was started with --memory/-m. A reproducible report of this class: Ollama in Docker refusing loads triggered from the Continue IDE plugin, where the container ceiling — not the host — was the binding constraint (issue #7423). If you’re wiring Ollama into a coding assistant, our sister site’s setup guides at aicoderscope.com assume a correctly-sized container for exactly this reason.

Kubernetes pods hit the same wall via resources.limits.memory — the 42.8-vs-12.9 GiB report above came from a pod on a 68 GiB node (issue #10256). Raise the pod limit; the node’s total is irrelevant.

Fix 4: you have a GPU — why is Ollama talking about system memory?

Because it’s not using the GPU, or not using enough of it. Two versions:

Total fallback. If the NVIDIA/AMD runtime isn’t visible (driver mismatch, missing container toolkit, unsupported ROCm card), Ollama schedules the whole model on CPU and the system-memory check inherits the full weight of the model. The error you’re staring at is a symptom; the disease is in the server log (no compatible GPUs were discovered). Work through Ollama Not Using GPU? Fix CPU-Only Inference first — once the GPU is back, the system-RAM requirement collapses to a fraction of the model.

Partial offload. A 70B Q4_K_M is ~43 GB of weights; a 24 GB card holds roughly half, and the other half must live in system RAM — so a 32 GB machine can fail the check even with a healthy RTX 3090 installed. That’s not a bug, it’s the offload math, and we’ve walked the layer-by-layer version of it in How to Run a 70B Model on a Single 24GB GPU. If the GPU-side of memory is what’s overflowing instead, that’s a different error with its own fix list: CUDA Out of Memory on Local AI.

Fix 5: shrink the required side

When the estimate is honest, reduce it. Three levers, in order of impact:

Smaller quant / smaller model. Rough CPU-side footprints at Q4_K_M (weights alone — add 1–3 GB for KV cache and overhead at default context): 8B ~5 GB, 14B ~9 GB, Gemma 4 26B-A4B ~16 GB, 32B ~20 GB, 70B ~43 GB. Dropping from Q8_0 to Q4_K_M roughly halves the weight footprint for the same parameter count. On a 16 GB machine, a 14B Q4 with headroom beats a 32B that can’t load.

Context length. The KV cache is allocated for the full configured context up front, not grown as the conversation fills. Ollama’s default is 4,096 tokens (OLLAMA_CONTEXT_LENGTH), but many UIs and Modelfiles push num_ctx to 32K or 128K, and long contexts can add gigabytes to the requirement before the first token. If you cranked context for one task, that’s likely your regression.

Parallel slots. Required memory scales with OLLAMA_NUM_PARALLEL × context length — each parallel slot gets its own KV allocation (Ollama FAQ). The default is 1 in current builds, but if you set 4 for a multi-user box, your KV budget quadrupled. Same logic applies to OLLAMA_MAX_LOADED_MODELS — two resident models means two full footprints (see Ollama Keeps Reloading the Model? for the keep-alive interactions).

One expectation to kill explicitly: MoE models don’t need less RAM. A user with 40 GB of RAM tried deepseek-r1:671b expecting the Mixture-of-Experts architecture to only need the ~37B active parameters resident, and got refused at “requires 446.3 GiB, available 37.3 GiB” (issue #8667). Sparse activation saves bandwidth per token — every expert’s weights must still be somewhere the runtime can reach. All 446 GiB of them.

Fix 6: add swap (yes, it actually changes the number)

On Linux, Ollama’s “available” figure is free RAM plus free swap — the failed-load log prints free_swap right next to free. That makes a swapfile a legitimate unblocking move, not a superstition:

$ sudo fallocate -l 16G /swapfile
$ sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile
$ free -h | grep Swap
Swap:           16Gi          0B        16Gi

(Add /swapfile none swap sw 0 0 to /etc/fstab to persist.) Now the same model that was refused loads, because “available” grew by 16 GiB.

Know what you’re buying. If the model mostly fits in RAM and swap only absorbs the load-time spike and rarely-touched pages, this works fine — mmap’d weights on a fast NVMe drive read back quickly. If inference actively pages weights in and out every token, you’ll get single-digit-percent of normal speed and an SSD doing constant reads. Swap is a loader cushion and an accounting fix, not extra RAM. Put the swapfile on your fastest drive — a Samsung 990 Pro 2TB at ~7,400 MB/s sequential makes the difference between a sluggish first load and a coffee break.

macOS and Windows manage swap automatically (Windows’ version of this failure is the pagefile commit limit — same accounting idea, different OS; the ComfyUI flavor is covered in our os error 1455 guide).

When the answer is actually “buy RAM” (or rent it)

If you keep bumping into the check with models you genuinely want to run, the durable fixes are hardware:

  • More system RAM — the 2026 memory price surge makes this a worse deal than it was a year ago, but it’s still the cheapest capacity: 64 GB DDR5 kits (2×32GB) ran $688–$770 in Newegg’s July 2026 sale, against list prices as high as $1,229 for RGB 6400 kits at Best Buy. A Corsair Vengeance 64GB DDR5 kit turns a 70B partial-offload from impossible to routine. Sizing guidance lives in How Much System RAM Do You Need for Local LLMs?, and the price context in DDR5 and SSD Prices Doubled in 2026.
  • Rent for the one-offs. If the model that triggers this error is a 200GB+ monster you’d run twice a month, don’t build for it — a high-RAM/multi-GPU pod on RunPod by the hour beats owning 512 GB of DDR5 that idles.
  • CPU-only isn’t hopeless. If you’re deliberately RAM-rich and GPU-poor, MoE models make CPU inference genuinely usable — we measured Gemma 4 26B at 5 tok/s on a 13-year-old Xeon with 128 GB of DDR3.

FAQ

Is this the same as “signal: killed” / the OOM killer? No — it’s the opposite failure. This error is the pre-flight check refusing to start a load. llama runner process has terminated: signal: killed is what you get when the check passed but the kernel ran out of memory mid-flight and shot the runner. That one has its own decode table in our runner-terminated guide.

Why does Ollama let me download a 400GB model it will refuse to run? ollama pull doesn’t run the memory check; only loading does. Check the footprint math before a multi-hour download — required RAM ≈ quantized weight size + KV cache for your context.

Can I just disable the check? There’s no supported override. The check exists because mmap-ing a too-big model “succeeds” and then delivers seconds-per-token inference or an OOM kill. Raising available memory (swap, container limits) is the sanctioned escape hatch.

Does use_mmap reduce the requirement? No — the check runs before load regardless of mmap settings (issue #7942). Mmap changes how weights are read, not how much memory Ollama demands up front.

Products linked in this guide:

Sources

Last updated July 22, 2026. Prices and Ollama behavior change; verify current rates and release notes before purchasing or upgrading.

Was this article helpful?