Run a Local LLM on 8GB RAM: What an M1 MacBook Air Can Do

Yes. Running a local LLM in 8GB of RAM is practical on a stock Apple M1 MacBook Air with no swap tuning and no GPU. We installed Ollama on an unmodified 8GB M1 Air and tested five models between 1.2B and 7.2B parameters: all five loaded and all five answered a fixed test prompt correctly. Four ran without any new swap activity. The fifth, a 7B model, worked but visibly strained the machine: real swapping, a large drop in speed, and a much slower context load. That is the actual boundary this test found, not a hard wall but a steep cost.

Key takeaways

• Every model we tested, from 1.2B to 7.2B parameters, loaded and correctly answered a fixed arithmetic prompt on this 8GB machine.
• Tokens per second fell from 77.02 (smallest model) to 9.64 (mistral:7b) as parameter count grew, a roughly 8x drop end to end.
• Three of five models triggered zero new swap activity; llama3.2:3b and mistral:7b did trigger new swapouts in this run, and mistral:7b's context-init call took 21 seconds versus 1-4 seconds for the smaller models.
• qwen2.5:7b still could not be tested in this run; treat anything above mistral:7b's 7.2B as an open question, not a "yes" or "no" answer.

8GB RAM vs 8GB VRAM: do not mix these answers

The phrase “8GB local LLM” hides two different hardware questions. This article tests an M1 MacBook Air with 8GB of unified memory, where macOS, the model, the KV cache, and other applications share one pool. A desktop with 8GB of dedicated VRAM has a separate GPU ceiling and a different failure mode.

Apple describes memory pressure using free memory, swap rate, wired memory, and cached memory, so a near-zero “free” number alone does not prove that an application is failing (Source: Apple Support). For this reason, the useful signals below are swap activity, response speed, and context initialization, not the free-memory counter by itself.

How to run a local LLM in 8GB of RAM

The machine is a MacBook Air with an Apple M1 chip and 8GB of unified memory, meaning the CPU and GPU share the same RAM pool rather than using separate video memory (Source: Apple Support). The runtime is Ollama, an open-source local-inference server built on llama.cpp that handles model loading, quantization, and the HTTP API a client talks to (Source: Ollama). We installed the standalone Ollama binary (no Homebrew, no admin permissions needed) and pulled five models directly from the Ollama library: llama3.2:1b, qwen2.5:1.5b, llama3.2:3b, phi3:mini, and mistral:7b.

Every model was tested the same way: unload any previously loaded model, record memory, send one generation request with a fixed prompt, record memory again, then send a second request asking for an eight-thousand-token context window. We recorded each measurement using the same procedure so the results can be compared rather than treated as anecdotal.

Vinh Luong, Head of Open Source at Aitomatic, called Llama 3.2's lightweight models "a strong differentiating factor" for the open-source model ecosystem (Source: Meta AI). That is a useful reason to test small models directly, but it is not evidence that every small model behaves the same on this Mac.

Measured in our test: all five pulls and test runs happened on the same machine in one session: Apple M1, 8GB unified memory. ollama pull mistral:7b and its siblings ran with no GPU offload flags and no manual memory limits set.

How to run a comparable 8GB RAM test

The shortest useful reproduction is to run the same model at a fixed context, unload it, and inspect the processor split. Ollama documents ollama ps as the way to check whether a model is on the GPU, CPU, or split across both, and documents num_ctx as the context-length setting (Source: Ollama).

ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b
ollama ps
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:1.5b",
  "prompt": "Answer with only the number: what is 17 times 24?",
  "stream": false,
  "options": {"num_ctx": 4096}
}'
ollama stop qwen2.5:1.5b

Record the model tag, quantization, context length, tokens per second, and swap activity before comparing it with this report. A different background workload can move the swap boundary, so a single “it fits” result is not a portable performance guarantee.

Which models actually load on 8GB

Loading was never an outright failure in this test, even at 7B. It got slower and heavier, not impossible.

Quantization is the process of storing model weights at lower numeric precision (fewer bits per parameter) to shrink both file size and runtime memory (Source: Ollama). qwen2.5:1.5b uses more resident memory than the larger llama3.2:1b file would suggest relative to its size because its default quant (Q4_K_M) is denser than llama3.2:1b's Q8_0 (Source: Qwen).

Ollama and qwen2.5:1.5b on 8GB RAM

Measured in our test: qwen2.5:1.5b loaded on the 8GB M1 MacBook Air, used 1,080 MB of resident memory, ran at 59.94 tokens/sec, and showed zero new swapout pages for the first generation. That makes it the safest default from this five-model run, not a universal best model for every task. The exact tag and quantization are part of the result. (Source: Ollama, Qwen)

Memory pressure and swap: where it breaks

Measured in our test: resident memory for the model process alone ranged from 1,415 MB (llama3.2:1b) to 4,460 MB (mistral:7b), measured via ps on the llama-server subprocess Ollama spawns per loaded model, not the lightweight ollama CLI front-end. Free system pages dropped to a 60-138 MB floor after every load, which is normal macOS behavior (the OS keeps "free" pages near zero and leans on reclaimable cache) rather than a distress signal by itself. (Source: Apple Support)

Swap is the real distress signal, and this run caught it. Measured in our test: we diffed vm_stat's cumulative swapout counter immediately before and after each model's first generation call. Three of five models, llama3.2:1b, qwen2.5:1.5b, and phi3:mini, showed a delta of 0 pages. Two did not: llama3.2:3b triggered 30,168 new swapout pages and mistral:7b triggered 50,468. This was not a strict function of model size alone; it reflects whatever else was resident on the machine at that moment, which is why the same 3B model can swap in one run and not another. The honest reading is that this machine has a soft ceiling somewhere in the 2-4GB resident range, not a hard cutoff.

Tokens per second: measured speed

Speed is where the boundary shows up most clearly. llama3.2:1b produced 77.02 tokens/sec; qwen2.5:1.5b 59.94; llama3.2:3b 48.55; phi3:mini 31.13; and mistral:7b just 9.64, all through Apple's Metal GPU acceleration path that Ollama uses automatically on Apple Silicon (Source: Ollama). The drop from phi3:mini to mistral:7b alone is roughly 3.2x, steeper than any earlier step in the lineup, and it lines up with the swap activity measured in the same run.

For a chat-style workload, anything above roughly 15-20 tokens/sec reads as comfortably responsive. The four smaller models cleared that bar; mistral:7b did not.

Context window ceiling on 8GB

We tested every model with an eight-thousand-token context window request, well inside each model's much larger trained context window (Source: Meta AI; Source: Microsoft). Measured in our test: the four smaller models answered that request in 1 to 4 seconds. mistral:7b took 21 seconds for the identical request, the clearest single number in this test showing where the machine starts to strain.

Context length matters because Ollama's default KV cache (the running memory of the conversation so far) grows with both the model's layer count and the context size (Source: Ollama). At 7B parameters, that extra KV cache on top of an already large resident footprint is almost certainly what pushed mistral:7b into swap and slowed its context-init call so much.

The fixed task: same prompt, every model

Every model was asked the identical question: "what is 17 times 24?" with instructions to answer with only the number. The correct answer is 408. Measured in our test: all five models, llama3.2:1b through mistral:7b, answered correctly on the first try with no retries or prompt engineering. This is a deliberately trivial task; it exists to confirm each model is actually reasoning over the prompt, not just staying resident in memory and returning garbage. The task ran through Ollama's local generation path, which is the runtime boundary this report measures (Source: Ollama).

Best local LLM for an M1 Mac with 8GB RAM

Given this test's results, qwen2.5:1.5b is the best default for a MacBook Air M1 with 8GB: it used less resident memory than llama3.2:1b in this run (1,080 MB versus 1,415 MB) while still running at a usable 59.94 tokens/sec, and it never triggered new swap activity. If raw quality matters more than headroom, phi3:mini is the largest model that stayed swap-free and responsive in this test, at 31.13 tokens/sec. mistral:7b runs, and it answers correctly, but 9.64 tokens/sec and a 21-second context load are real costs, not a rounding error; treat it as usable in a pinch, not a comfortable daily driver on this exact machine.

qwen2.5:7b still could not be downloaded during this run due to a slow, unstable connection, not a model-loading error, so the honest ceiling of confirmed data in this article stops at mistral:7b. The model identifiers and quantization labels above are the Ollama model records used for this run (Source: Ollama).

Does this apply to any low-end PC?

Only partially. The unified-memory architecture that lets an M1 Air share 8GB between CPU and GPU without a separate VRAM pool is specific to Apple Silicon (Source: Apple Support). A Windows or Linux laptop with 8GB of RAM and no discrete GPU will run a similarly quantized small model through Ollama's CPU path, but tokens-per-second and memory headroom will differ with the CPU's architecture and memory bandwidth. Anyone hunting for the best small LLM for a low-end PC should treat the model shortlist above (1.2B-3.8B for comfortable use, 7B as a strained but workable ceiling) as the right size class to try, not this article's exact speed numbers, which are M1-specific.

FAQ

What is the best local LLM for 8GB RAM?

In this 8GB test, qwen2.5:1.5b gave the best balance of memory headroom (1,080 MB resident, zero new swap activity) and speed (59.94 tokens/sec). phi3:mini is a stronger option at 3,624 MB and 31.13 tokens/sec if you can spare the memory and still want to stay swap-free.

Can I run a local LLM with 8GB RAM?

Yes. Every model tested here, from llama3.2:1b up to mistral:7b, loaded and ran successfully on an 8GB M1 MacBook Air through Ollama, though the 7B model showed real memory pressure: new swap activity and a sharp drop to 9.64 tokens/sec.

Which Ollama models run on an 8GB M1 Mac?

All five tested tags loaded: llama3.2:1b, qwen2.5:1.5b, llama3.2:3b, phi3:mini, and mistral:7b. The three smallest offered the most headroom. mistral:7b answered correctly but caused new swap activity and ran at 9.64 tokens per second on the tested machine.

What quantization should I use on an 8GB Mac?

Start with a 4-bit quantized model when memory is the binding constraint. Quantization reduces weight memory, but model size and context still matter. Check the exact Ollama model metadata and monitor memory pressure during a representative prompt instead of assuming every model with the same parameter count fits identically.

How much context can an 8GB Mac handle?

Context consumes additional memory through the KV cache, so the ceiling changes with model architecture, context length, and concurrency. Start at a modest context, monitor memory pressure and swap, then increase it with the actual workload. The measured results here should not be treated as a universal context limit.

Does an M1 MacBook Air have enough memory for Ollama?

Yes for small quantized models. This test ran models from 1.2B through 7.2B parameters on an 8GB M1 MacBook Air, but the 7B model created meaningful memory pressure. Models in the 1B to 4B range offered the better balance of speed and headroom on this machine (Source: Apple Support).

Limitations

This test covers one machine, one runtime, and five models between 1.2B and 7.2B parameters. qwen2.5:7b could not be tested; its download failed during this run from network instability, not a model-loading problem, so the article cannot say whether an 8-9B model behaves like mistral:7b or worse. Swap behavior was not a clean function of model size: llama3.2:3b triggered new swapouts in this run but not in an earlier same-day run at the same settings, which means background system load at the moment of testing matters as much as the model itself. Results are specific to Apple's unified-memory architecture and to Ollama's default settings; a different runtime, a different quantization scheme, or a discrete-GPU PC will not behave identically. Treat this as a bounded field report for this exact setup, not a universal claim about every 8GB computer. (Source: Apple Support)

The model tags tested here are a reproducible snapshot, not a permanent “best local LLM” ranking. Ollama's library changes, and newer models may fit or perform differently. Use the measured table for the M1/8GB decision, then check the companion hardware calculator with the exact model metadata before downloading a newer model.

Related coverage

• LLM VRAM Calculator: RAM, Quantization, and Model Fit
• Ollama vs llama.cpp: Speed, Overhead, Which Local LLM Runner

References

• Apple Support - https://support.apple.com/en-ie/guide/activity-monitor/actmntr1004/mac
• Meta AI - https://ai.meta.com/blog/llama-3-2-connect-2024-vision-edge-mobile-devices/
• Microsoft - https://azure.microsoft.com/en-us/products/phi
• Ollama - https://docs.ollama.com/faq
• Qwen - https://qwenlm.github.io/blog/qwen2.5/