Local LLMUpdates
Search

Guides · published

How to troubleshoot local LLM memory pressure on Mac

Check Activity Monitor, record swap, and retry a GGUF with a small explicit context and one llama.cpp slot. A diagnostic checklist with measured command evidence and clear test limits.

Published October 4, 2026 · Local LLM Updates Editorial

If a local model fails to load or your Mac becomes sluggish during a chat, check memory pressure before changing system settings. A successful model load is only a startup check: it does not establish that the model leaves enough headroom for your usual apps and longer conversations.

This checklist uses Apple’s memory diagnostics and a pinned llama.cpp configuration. We checked the read-only Terminal commands on one 24 GB M5 Mac on October 3, on macOS 27.0.1. The startup example reuses our September 5 smoke test, which ran on macOS 26.6.2; we did not rerun inference after that OS change, and we did not measure a memory improvement for this article.

1. Look at the whole Mac before blaming the model

Open Activity Monitor → Memory. Record the Memory Pressure graph, Swap Used, and which apps are using memory before starting your local model. Apple describes green as efficient RAM use, yellow as a possible future need for more RAM, and red as a need for more RAM.

Apple’s definition of memory pressure includes swap rate, wired memory, cached files and free memory. A single free-RAM number or Swap Used total does not identify which process caused pressure. Record a baseline, then watch how the graph and counters change during your own workload.

Save your work before quitting apps you recognize and do not need for the test. Keep the model, prompt and other settings the same when checking whether that changes the behavior.

2. Record a small diagnostic snapshot

These commands only read system information:

sw_vers
sysctl hw.memsize
sysctl vm.swapusage
vm_stat
memory_pressure -Q
llama-server --version

The October 3 evidence records successful execution on macOS 27.0.1 with 25,769,803,776 bytes of physical memory and llama.cpp build 10470, commit 34af94cd9. The full record also checks the chip identifier and server help.

memory_pressure -Q printed a system-wide free-memory percentage. That output is not the Activity Monitor pressure graph and is not a calculation of how much memory your LLM can use. Our snapshot had substantial existing swap and uncontrolled background work. It diagnoses no particular model and proves no comfortable memory budget.

Record the same counters after your test. Treat changes as observations; one run does not isolate a cause. If the server exits, keep its error message as well: a missing file or unsupported model is a different problem from a memory-allocation failure.

3. Make the server configuration explicit

Check llama-server --help on your installed version. In the pinned server documentation, --ctx-size sets prompt context size, --parallel sets server slots, and --cache-ram sets the maximum cache size in MiB; zero disables that cache. It does not promise to eliminate every other allocation made by the runtime.

For a first small text-only check, this is the configuration family we used previously:

llama-server \
  --model '/absolute/path/to/your-model.gguf' \
  --alias mac-guide-test \
  --host 127.0.0.1 \
  --port 18765 \
  --ctx-size 2048 \
  --parallel 1 \
  --cache-ram 0 \
  --reasoning off

Replace the placeholder with your real file path. Keep the bind address at 127.0.0.1 for this local check. If the port is occupied, choose another unused port; leave unfamiliar processes alone. Stop your own foreground server with Ctrl+C when finished.

If your installed help does not list an option used here, stop and check the documentation for your build before running the example. Do not install or upgrade a runtime just for this check.

The September 5 evidence records the browser and API checks. It obtained two short replies with the pinned third-party Huihui-Qwen3.8-27B-abliterated-UD-Q2_K_XL.gguf, using context 2048, one slot and cache-ram zero. That run was on macOS 26.6.2, with uncontrolled background load, another local server still listening, and substantial swap already in use. It was not repeated on macOS 27.0.1. This is neither an optimal configuration nor a promise that your file will fit, and it does not show the result of changing one option. See the related startup guide for a walkthrough.

The October 3 work checked read-only diagnostics and five help options: --ctx-size, --parallel, --cache-ram, --host and --port. The startup command, including --alias and --reasoning off, comes from the September 5 record and pinned documentation; it was not rerun.

4. Change one thing and keep a record

In the checked build, --cache-ram defaults to 8192 MiB, --ctx-size defaults to 0 (loaded from the model), and --parallel defaults to -1 (auto). Omitting these flags does not mean a small context, one slot or no cache. Check your build’s help for its defaults.

If your current configuration requests a large context, try a smaller explicit context that still covers your short test prompt and expected reply. If you need only one conversation, try one server slot. Try --cache-ram 0 to disable that cache for a diagnostic run. These are settings to investigate, not measured speed or memory improvements from our October 3 check.

Record the runtime version, model filename and checksum, context, slot count, cache limit, prompt, response length, pressure graph and swap observations. Change one setting at a time. If the Mac still shows sustained pressure, consider a smaller compatible model and test it again on your actual task; a smaller download does not establish equivalent answer quality.

Observation Next check
The model never loads Read the server error and verify the file path and runtime compatibility.
Pressure is already high before startup Establish a quieter baseline after saving work and quitting unneeded apps.
Pressure rises during a chat Record when it changes and retry one context, slot or cache setting at a time.
A short reply works but a long task struggles Repeat with the real prompt and output length; keep the successful smoke test separate.

Do not turn a diagnostic into an unmeasured system-tuning experiment. The core diagnostic steps require no swap disabling, privileged memory-limit edits, new model download or runtime upgrade. The optional smaller-model test is separate and may involve a download.

For a recorded model-selection example, see the 24 GB Mac selection guide. To measure speed after you have a stable configuration, use the llama-bench guide and preserve its run conditions.