Overview
Ollama out of memory on a Mac almost always means the model weights plus the KV cache for your context need more unified memory than the machine can give the runner, so the first fix is to compute the total and pick a smaller model, a smaller context or a smaller quantization. The error Error: llama runner process has terminated: signal: killed is a related symptom: in ollama/ollama issue 8571, a commenter with a Collaborator badge suggested the runner was killed externally, possibly by an OS policy. This page gives the memory check from methodology, what the two main GitHub threads say, and the settings Ollama documents. Speed is not covered; it is unknown here, and you can measure it with measure-tokens-per-second-mac.
What does “signal: killed” mean in Ollama on a Mac?
It means the Ollama runner process was ended from outside, and in thread 8571 the working explanation was memory pressure on macOS. The reporter ran DeepSeek R1 671B on a MacBook Pro M3 Pro with 64 GB and on a Mac Studio M1 Ultra with 128 GB, both on Ollama 0.5.7, and got Error: llama runner process has terminated: signal: killed.
What the thread’s commenter rick-github (shown with a “Collaborator” badge; the page does not show organization membership) said, as summarized from the thread:
- On Jan 25, 2025, to add a lot of swap, that the model needed about 322 GiB of system RAM and 63 GiB of GPU memory, and that the runner was likely killed externally (possibly by an OS policy), with a pointer to the Console logs.
- On Jan 29, that macOS skips the memory check because Darwin has fully dynamic swap, with
num_gpu: 0anduse_mmap: trueas a workaround.
The issue was closed as completed on Mar 31, 2025 via PR #9433. What that PR changed is unknown here; the thread text read on 2026-10-13 does not say.
Why does Ollama run out of memory on my Mac?
The total need is weights plus KV cache plus overhead, and any one of them can push you over. This site uses the formulas on methodology:
weights_GB = params × bits / 8 / 1e9
total_GB = weights_GB + kv_GB + overhead_GB, with the overhead a labelled 2 GB assumption.
Two worked examples from model cards:
| Model | Card parameters | Bits (assumed) | Weights | Fits in 64 GB? | Fits in 128 GB? |
|---|---|---|---|---|---|
| DeepSeek-R1 | 671B total (37B activated) | 4.0 | 335.5 GB | No | No |
| Gemma 3 27B it | 27B | 4.0 | 13.5 GB | Weights yes, KV unknown | Weights yes, KV unknown |
Arithmetic: 671e9 × 4 / 8 / 1e9 = 335.5 GB, and 27e9 × 4 / 8 / 1e9 = 13.5 GB. The 4.0 is a round number, not a measured GGUF bits-per-weight. The DeepSeek-R1 weights alone are above 128 GB, which matches the 8571 reports on 64 GB and 128 GB Macs. For Gemma 3 27B the KV cache needs the layer and head counts from config.json, which sits behind a gate on that card, so the KV term and the total are unknown here. For ungated cards, how-much-ram-for-local-llm works the KV formula through.
The macOS reserve (how much unified memory the GPU may use) is unknown on this site; see mac-gpu-memory-limit. Treat a total close to your installed memory as unconfirmed.
Why did memory use jump when I updated Ollama?
An estimation change can make memory use or offload decisions shift between versions. In issue 9791 (titled “Out of memory errors when running gemma3”, later retitled by a maintainer to say gemma3’s memory estimation led to too many layers offloaded or crashes), a user with 64 GB of RAM on Ollama 0.6.1 reported gemma3:27b memory rising from about 15.5 GB to 49.8 GB. That is a user report in a thread, not a measurement by this site.
Comments in that thread:
- rick-github (Mar 23, 2025): smaller context-buffer changes made the estimate harder to get right, and the team was aware and expected estimation changes in upcoming releases.
- rick-github (Mar 26): PR #9987 cut the estimate for gemma3:12b with a 16K cache from about 17 GB to 12 GB in 0.6.3-rc0.
- jessegross (shown as “Contributor”; Mar 26): the old engine preallocates the worst-case compute graph while the new one does not, so nvidia-smi underreports total memory until the worst case has been exercised.
The issue was closed on Apr 8, 2025, with a remaining system-memory leak directed to issue 10040. The thread’s original reporter used an RTX 3060 12 GB; the 64 GB report is the only one here that mentions a high-RAM machine, and whether it was a Mac is not stated in the text read.
How do I check what Ollama actually loaded?
Run ollama ps. The Ollama FAQ says it shows the models loaded into memory, that 100% GPU means the model loaded entirely into the GPU, 100% CPU means entirely in system memory, and a split such as 48%/52% CPU/GPU means it is spread across both. For logs, the troubleshooting page gives cat ~/.ollama/logs/server.log on Mac, and the macOS page lists app.log and server.log in ~/.ollama/logs.
What can I change to stop the error?
Reduce one term of the formula, using only settings Ollama’s docs name:
- Pick a smaller model or lower-bit quantization, which reduces
weights_GB. - Lower the context. The FAQ says the default context window is 4096 tokens, overridable with
OLLAMA_CONTEXT_LENGTHor/set parameter num_ctx; the context-length page lists 4k, 32k and 256k defaults by VRAM tier and the Modelfile reference says “(Default: 2048)”, so checkollama psfor the live value. In thread 9791 the original reporter said 4k context worked where 8k crashed. See long-context-on-mac. - Check parallelism. The FAQ says required RAM scales by
OLLAMA_NUM_PARALLEL(default 1). - Unload other models. The FAQ says models stay in memory 5 minutes by default;
ollama stop <model>unloads one, andOLLAMA_MAX_LOADED_MODELScaps how many load at once. - Quantize the KV cache. The FAQ lists
OLLAMA_KV_CACHE_TYPE(defaultf16), which applies only with Flash Attention enabled. How much memory it saves on your Mac is unknown here. - In thread 8571, a commenter suggested
num_gpu: 0withuse_mmap: true, and one user said it loaded a smaller Unsloth quantization. These are thread reports; the FAQ page does not document them.
The macOS page also notes models can be tens to hundreds of GB on disk, and lists macOS Sonoma (v14) or newer and Apple M series as requirements. Setup is on ollama-on-mac; a model that loads but is slow is local-llm-slow-on-mac.
Questions
Why is Ollama out of memory on my Mac?
The model weights, KV cache and overhead together exceed what the runner can get from unified memory. Compute weights_GB = params × bits / 8 / 1e9, add the KV cache and a 2 GB overhead assumption, and compare with your installed memory, remembering that the macOS reserve is unknown.
What does Ollama “signal: killed” mean?
The runner process was ended from outside. In issue 8571, a commenter with a Collaborator badge suggested the runner was killed externally, possibly by an OS policy, and pointed to the Console logs.
Why does Ollama crash on my Mac?
The documented cause in the threads is memory: oversize models in issue 8571 and over-large memory estimates in issue 9791. Check ollama ps and ~/.ollama/logs/server.log to see what loaded and what the runner reported.
Can a 128 GB Mac run DeepSeek R1 671B in Ollama?
Not at 4.0 bits: 671e9 × 4 / 8 / 1e9 = 335.5 GB of weights, above 128 GB. Thread 8571 reports the same error on a 128 GB Mac Studio M1 Ultra; one user there reported a smaller Unsloth quantization (about 150 GB) failing in Ollama but working in llama.cpp. See giant-moe-on-mac.
Does adding swap fix it?
Unknown. A commenter in thread 8571 advised adding a lot of swap, and another argued swap-based inference would be unusably slow. No tested fix by swap is documented there.
Does lowering context length help?
It lowers the KV cache term, which grows linearly with context (how-much-ram-for-local-llm). Ollama’s FAQ gives a default of 4096 tokens (other Ollama docs pages disagree, see long-context-on-mac); how much memory you save on a given model depends on its layers and KV heads.
How much faster is it after the fix?
Unknown; this site publishes no speed numbers. See measure-tokens-per-second-mac.
Sources read on 2026-10-13
- ollama/ollama issue 8571: error string, hardware, Ollama 0.5.7, collaborator comments, workarounds, closure via PR #9433.
- ollama/ollama issue 9791: 64 GB user report, estimation comments, PR #9987, closure Apr 8, 2025.
- Ollama macOS docs: requirements, log files, disk size note.
- Ollama FAQ:
ollama ps, keep-alive, parallelism, context default, KV cache type. - Ollama troubleshooting: Mac log command.
- DeepSeek-R1 model card: 671B total, 37B activated.
- Gemma 3 27B it card: 27B params; gated, no layer data taken.
- methodology: weight and total formulas, 2 GB overhead assumption.