Yes, you can run a local LLM on 8GB RAM, including 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:3bandmistral:7bdid trigger new swapouts in this run, andmistral:7b's context-init call took 21 seconds versus 1-4 seconds for the smaller models. qwen2.5:7bstill could not be tested in this run; treat anything abovemistral: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.
| Hardware label | What the 8GB must cover | What this test proves |
|---|---|---|
| 8GB unified memory | macOS, the model, KV cache, and other applications | Measured on the M1 MacBook Air below |
| 8GB system RAM without a discrete GPU | The operating system and CPU inference workload | Not measured here; speed depends on the CPU and runtime |
| 8GB dedicated VRAM | GPU-resident weights and KV cache | Not the same as this Apple Silicon test |
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 on 8GB 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.
| Model | Params | Quantization | Resident memory after load | Tokens/sec |
|---|---|---|---|---|
| llama3.2:1b | 1.2B | Q8_0 | 1,415 MB | 77.02 |
| qwen2.5:1.5b | 1.5B | Q4_K_M | 1,080 MB | 59.94 |
| llama3.2:3b | 3.2B | Q4_K_M | 2,333 MB | 48.55 |
| phi3:mini | 3.8B | Q4_0 | 3,624 MB | 31.13 |
| mistral:7b | 7.2B | Q4_K_M | 4,460 MB | 9.64 |
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).
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 a MacBook Air M1 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 model for an M1 Mac?
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 LLM models be run on M1 chip Macs?
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.
Can I run LLMs on 8GB of VRAM?
Apple Silicon does not have separate VRAM; the 8GB is unified memory shared by CPU and GPU (Source: Apple Support). On a discrete-GPU PC with 8GB of VRAM specifically, the same 1B-4B parameter class in Q4-Q8 quantization is the realistic comfortable range, with 7B-class models possible but tight, echoing what this test measured on unified memory.
How much VRAM is needed to run a local LLM?
It depends on parameter count and quantization: roughly params times bytes-per-parameter for the weights, plus a smaller amount for the active context. In this test, models from 1.2B to 7.2B parameters used between 1,080 MB and 4,460 MB of resident memory; the 7.2B model additionally pushed the system into measurable new swap activity where the smaller ones mostly did not.
Is the MacBook Air M1 outdated for running local LLMs?
No, but it has a real ceiling. This test found every model up to 7.2B parameters loads and answers correctly on a stock 8GB M1 Air, with the three smallest staying swap-free and fast. A 7B model works but visibly strains the machine. For models in the 1B-4B range it remains genuinely usable in 2026.
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/




