--- title: "Run Multiple Ollama Models on Mac: See What Fits in Memory" description: "Ollama won't tell you if two models fit in memory at once. ToolPiper shows per-model usage, GPU allocation, and warns before you exceed capacity." date: 2026-04-10 updated: 2026-04-14 author: "Ben Racicot" tags: ["Ollama", "Chat", "Text Generation", "Privacy", "macOS", "Apple Silicon"] type: "article" canonical: "https://modelpiper.com/blog/ollama-multi-model-mac/" --- # Run Multiple Ollama Models on Mac: See What Fits in Memory > Ollama won't tell you if two models fit in memory at once. ToolPiper shows per-model usage, GPU allocation, and warns before you exceed capacity. ## TL;DR Ollama doesn't tell you whether two models fit in memory at the same time. It'll try to load both, swap to disk, and grind to a halt. ToolPiper shows real-time per-model memory usage, GPU/CPU allocation, and warns before you exceed capacity on your specific hardware. **Not sure what fits on your Mac?** Use the [model fit calculator](/fit) to check which models your specific hardware can run — with estimated speeds and recommended quantizations. You loaded a 14B model. Now you want to load an 8B alongside it for a different task. Ollama doesn't tell you whether your Mac can handle both. It reads system RAM once at startup, makes a rough estimate, and proceeds. If it's wrong, macOS starts swapping to disk. Token generation drops from 40 tokens per second to two. Your fans spin up. Every app on the Mac slows down. The problem isn't that you can't run multiple models. Apple Silicon's unified memory architecture is actually well-suited for it - the GPU and CPU share the same pool, so there's no VRAM limit to hit. The problem is visibility. Nothing in Ollama tells you how much memory each model is using, how much is left, or when you're about to cross the line. ## How much memory do Ollama models actually use? Model memory isn't just the file size on disk. A GGUF model file is compressed with quantization. In memory, the model expands, and the inference engine allocates additional buffers for context, KV cache, and computation. Rough guidelines for common models at Q4 quantization on Apple Silicon: **Small models (1-4B):** 1.5-2.5GB in memory. Qwen 3.5 0.8B sits at about 1.5GB. Llama 3.2 3B uses about 2GB. Phi-4-mini at 3.8B takes around 2.5GB. These are cheap to keep loaded - on an M2 MacBook Air, a 3B model generates 50-80 tokens per second. **Medium models (7-9B):** 5-7GB in memory. Llama 3.1 8B at Q4 uses about 5GB. Qwen 3.5 9B sits around 7GB. This is where 8GB Macs hit their ceiling - one medium model plus macOS overhead fills available memory. Expect 20-35 tok/s on M1/M2 base chips, 30-50 tok/s on M3/M4 Pro. **Large models (12-14B):** 9-11GB in memory. Phi-4 at 14B uses about 9GB at Q4. With inference overhead, count on 10-11GB total. On a 16GB Mac, one 14B model leaves room for macOS and not much else. On 32GB, you have headroom and the model runs at 25-40 tok/s on Pro-class chips. **XL models (24B+):** 15-42GB+ in memory. Mistral Small 3.2 (24B) at Q4 uses about 15GB. Gemma 4 31B needs roughly 20GB. Llama 3.3 70B at Q4 uses about 42GB. These need 32GB or 64GB Macs. Mixture-of-experts models change the math here - Qwen 3 30B-A3B, Gemma 4 26B, and Llama 4 Scout (109B total, 17B active) load all parameters into memory but only activate a fraction per token. Qwen 3 30B-A3B and Gemma 4 26B use 15-18GB at Q4 and activate 3-4B per token — you get 30B-class quality at speeds closer to a small model: 50-85 tok/s on M4 Max. Llama 4 Scout is the largest practical MoE for local use: ~58GB at Q4 (needs 64GB+ Mac), but it only activates 17B parameters per token, so inference speed stays competitive despite the massive parameter count. The catch with all MoE models is they still occupy the full memory footprint. These numbers are approximate. Actual usage depends on quantization level, context length, and how the inference engine manages memory. Which is exactly why you need measurement, not estimation. ## Why doesn't Ollama show you per-model memory usage? Ollama checks available system RAM once at startup and uses that number to decide whether a model fits. It doesn't re-check as conditions change. If you loaded a browser with 40 tabs after Ollama started, Ollama doesn't know the available memory shrank. If another model was already loaded by a different process, Ollama doesn't see it. There's no `ollama stats` or `ollama memory` command. The `ollama ps` command shows which models are loaded but not how much memory each one consumes. Open WebUI inherits the same blind spot - it can't report what Ollama doesn't measure. Activity Monitor shows total process memory, but it reports the Ollama server process as one blob. If you have three models loaded, you see one combined number with no breakdown. You can't tell which model to unload to free the most space. ## How does ToolPiper track per-model memory? **ToolPiper measures actual per-model memory usage through `proc_pid_rusage`**, the macOS kernel API that reports resident memory per process. Because ToolPiper manages each model as a separate llama.cpp server process, it can attribute memory to individual models precisely. The resource monitor shows: **Per-model resident memory.** Not the file size, not an estimate - the actual bytes the model occupies in RAM right now. You can see that Llama 3.2 3B is using 2.1GB while Parakeet v3 is using 480MB. **GPU vs CPU allocation.** On Apple Silicon, Metal GPU acceleration handles most of the inference work, but some layers may fall back to CPU if GPU memory pressure is high. ToolPiper shows the split via IOKit GPU utilization metrics, so you know whether your model is running at full GPU speed or partially on CPU. **System RAM pressure.** macOS kernel APIs report memory pressure at three levels: normal, warn, and critical. ToolPiper surfaces this as a simple indicator. When pressure reaches "warn," loading another model will likely cause swapping. You see this before the slowdown starts, not after. **Pre-load estimation.** Before you load a model, ToolPiper shows its estimated memory requirement alongside your current available memory. If a model won't fit without causing pressure, you see a warning before loading - not after macOS has already started paging to disk. ## What model combinations actually fit on common Macs? All models at Q4 quantization. Speed ranges below are from Apple Silicon community benchmarks - your results depend on chip generation, memory bandwidth, and what else is running. **8GB Mac (M1/M2 MacBook Air):** One model is the practical limit. Llama 3.2 3B (2GB) or Phi-4-mini (2.5GB) runs comfortably with headroom for macOS. An 8B model (5GB) fits alone but leaves razor-thin margins - macOS needs roughly 3-4GB for itself, and your browser isn't free either. Expect 50-80 tok/s on 3B models, 20-35 tok/s on an 8B. Two models simultaneously isn't realistic on 8GB. **16GB Mac:** Room for one large model or two-three small ones. Llama 3.1 8B + Parakeet STT + PocketTTS (total ~6GB) runs a full voice chat pipeline comfortably. Phi-4 14B alone leaves adequate headroom. Two 8B models simultaneously pushes to the edge. **32GB Mac:** The sweet spot for multi-model workflows. Phi-4 14B + an 8B coding model + STT + TTS (total ~16GB) runs with plenty of room. Gemma 4 31B fits alone with headroom for utility models. Ollama 0.19 added an MLX backend that auto-activates on 32GB+ Macs, roughly doubling decode speed compared to the Metal backend. This is where local AI stops feeling constrained. **64GB+ Mac:** Run almost any combination. Llama 3.3 70B (42GB at Q4) and Llama 4 Scout (58GB at Q4, MoE with only 17B active per token) become practical. Multiple large models simultaneously. On M4 Max with MLX, expect 50-80 tok/s on 14B models, 8-15 tok/s on 70B dense, and 20-35 tok/s on Scout (benefits from MoE's lower active compute). Memory stops being the bottleneck - inference speed and context length become the limiting factors instead. ## Practical multi-model scenarios ### Coding model + chat model A common setup: keep a coding-optimized model loaded for programming tasks and a general chat model for everything else. On 16GB, pair Phi-4-mini (2.5GB, strong at code and reasoning) with Llama 3.1 8B (5GB) - about 7.5GB total, comfortable with macOS overhead. On 32GB, scale up to Devstral Small 2 (24B, ~15GB) alongside Qwen 3.5 9B (~7GB) - about 22GB total. MoE coding models are another option: Qwen 3 30B-A3B loads ~18GB but only activates 3B parameters per token, hitting 50-85 tok/s on M4 Max. ToolPiper lets you switch between models from the same interface without waiting for a swap. ### Voice chat pipeline STT (Parakeet v3, ~500MB) + chat LLM (Llama 3.2 3B at ~2GB or Llama 3.1 8B at ~5GB) + TTS (PocketTTS at ~300MB). Total: 3-6GB depending on chat model size. With the 3B model, 8GB Macs can manage if you keep other apps minimal. An 8B voice setup at 6GB needs 16GB to be comfortable - on 8GB, macOS overhead plus three models exceeds capacity. All three stay loaded for the duration of the voice session, so there's no model-swap latency between turns. See [voice chat with Ollama](/blog/ollama-voice-chat-mac) for the full walkthrough. ### RAG + chat Embedding model (Apple NL Embedding uses zero additional memory since it's built into macOS, or a dedicated model at ~500MB) + chat LLM (Qwen 3.5 9B at ~7GB). Total: 7-7.5GB. Comfortable on 16GB. The embedding model stays loaded for indexing and query embedding while the chat model handles generation. ## When quantization is the answer If your target model combination doesn't fit, the first lever to pull is quantization level. The same model at Q8 (8-bit) uses roughly double the memory of Q4 (4-bit). Going from Q8 to Q4 on an 8B model saves about 4GB with a modest quality reduction that's barely noticeable for most tasks. For multi-model setups, use Q4 for the smaller utility models (coding assistant, summarizer) and reserve Q5 or Q6 for your primary chat model where quality matters most. ToolPiper's model browser shows the memory impact of each quantization option before you download. ## Stretch context length with KV cache quantization Model weight quantization (Q4, Q8) controls how much memory the model itself uses. But there's a second memory hog that grows with every token you generate: the KV cache. The key-value cache stores attention state for every token in your context window. At default 4K context, it's small. At 16K or 32K context, it can rival the model itself in memory usage. At 128K, it dominates. Ollama now supports **KV cache quantization**, which compresses this cache from FP16 down to smaller representations. It's not on by default — you enable it with an environment variable: `OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve` The available options: **q8\_0** — 8-bit KV cache. Uses roughly half the cache memory of the default FP16. Negligible quality loss. This is the safe default if you want longer contexts. **q4\_0** — 4-bit KV cache. Uses roughly one quarter the cache memory. Small-medium quality trade-off, but dramatically extends what fits in memory. **tq3 / tq4** — TurboQuant (coming soon to llama.cpp). Based on Google's PolarQuant paper, these apply a randomized Hadamard rotation to key vectors before quantizing. Better quality preservation than raw q3/q4 at similar compression ratios. Not yet in mainline Ollama. The practical impact: a 7B model at 32K context with FP16 KV cache might use 6-7GB total. With `q4_0` KV cache, the same model at the same context length drops to roughly 5GB — enough headroom to load a second small model alongside it. This matters most for multi-model setups where you're already near your memory ceiling. Quantizing model weights gets you in the door; quantizing the KV cache lets you extend context without getting pushed back out. **Note:** ToolPiper ships with q8\_0 KV cache quantization enabled by default on all models — no configuration needed. Ollama requires you to opt in via an environment variable. For a deeper dive into how KV cache quantization works, when each option makes sense, and benchmarks on Apple Silicon, see [Ollama KV Cache Quantization: Fit Longer Contexts in Less Memory](/blog/ollama-kv-cache-quantization). ## What are the limitations of running multiple models locally? **Unified memory is shared.** The GPU, CPU, and system all draw from the same memory pool on Apple Silicon. When you load models, you're reducing the memory available to macOS, your browser, and every other app. The model combinations above assume a clean system with minimal other load. Twenty browser tabs and Slack running alongside changes the math. **Context length multiplies memory.** The numbers above assume default context lengths (2048-4096 tokens). Increasing context to 8192 or 16384 tokens increases KV cache memory proportionally. An 8B model at 16K context uses noticeably more RAM than the same model at 4K. If you're running multiple models with extended context, account for the additional memory — or use [KV cache quantization](/blog/ollama-kv-cache-quantization) to compress it. **Model loading takes time.** Swapping models in and out isn't instant. Loading an 8B model from disk to memory takes 3-5 seconds on fast NVMe storage. If you frequently switch between more models than fit in memory simultaneously, you'll feel the swap cost. The solution is to keep your most-used models loaded and unload the rest. **Ollama's model management is opaque.** Ollama has its own model loading/unloading behavior that isn't fully controllable. It may keep models loaded after your last request, or unload them based on its own memory heuristics. When using Ollama alongside ToolPiper, the memory reported by ToolPiper's resource monitor covers ToolPiper's models accurately, but Ollama-managed models show as a single process in the system view. Download ToolPiper at [modelpiper.com](https://modelpiper.com) and check the resource monitor before loading your next model. If you use Ollama, connect it as a provider and manage your model loading through ModelPiper's interface. _This is part of a series on [Ollama frontends for Mac](/blog/best-ollama-frontend-mac). See also: [How AI Model Memory Works on Mac](/blog/ai-model-memory-mac) for the fundamentals of model memory on Apple Silicon._ ## FAQ ### Does Ollama automatically unload models to free memory? Ollama has basic model lifecycle management, but it's not fully transparent. It may keep models loaded after your last request and unload them after an idle timeout. You can force an unload with the API, but there's no built-in UI for managing what's loaded. ToolPiper gives you explicit control: load and unload models individually with real-time memory feedback. ### Can I run Ollama and ToolPiper models at the same time? Yes. They're separate processes drawing from the same unified memory pool. An 8B model in Ollama and a 3B model in ToolPiper use about 7GB combined. The constraint is total available RAM, not any interaction between the two tools. ToolPiper's resource monitor shows system-wide memory pressure, so you'll see the impact of both. ### What happens when I exceed available memory? macOS starts paging to the SSD swap file. Token generation speed drops dramatically - from 40+ tokens/second to single digits. The entire system feels sluggish: app switching lags, browser tabs reload, and fan noise increases. The fix is unloading a model. ToolPiper warns you before this happens. Ollama does not. ### Should I use Q4 or Q8 quantization for multi-model setups? Q4 for most models in a multi-model setup. The quality difference between Q4 and Q8 is modest for conversational tasks. Q4 cuts memory usage roughly in half, which is the difference between fitting two models and fitting one. Reserve Q5 or Q6 for your primary chat model if quality matters more than memory for that specific use case.