How to Run DeepSeek-R1 32B on Apple M4: Which Mac You Need + Real tok/s

You can run DeepSeek-R1 32B on an Apple M4 — but only if you buy the right variant. The base M4 tops out at 32 GB of unified memory, which is borderline for the 32B distill at q4_K_M (~19.85 GB weights plus 2-4 GB of KV cache plus macOS overhead). Plan on an M4 Pro with 48 GB or 64 GB (Apple M4 Pro newsroom) or an M4 Max with 36 GB or more, and budget for 18-26 tok/s on Metal at 4-bit quantization as of May 2026.

What "DeepSeek-R1 32B" actually is

The weights people pull when they type ollama run deepseek-r1:32b are not the full 671-billion-parameter DeepSeek-R1 mixture-of-experts model. They are DeepSeek-R1-Distill-Qwen-32B, a dense 33B-parameter checkpoint distilled from R1's reasoning traces onto the Qwen2.5-32B base model (Hugging Face model card, DeepSeek-R1 paper). The distill keeps R1's chain-of-thought style — visible "..." reasoning before the final answer — but runs in a single-GPU memory budget. The model card lists the base explicitly as Qwen2.5-32B and the release date as January 2025.

That matters because the full 671B R1 needs roughly 800 GB of memory even at q4_K_M — out of reach for any Mac short of a maxed-out 512 GB M3 Ultra Mac Studio (Apple M3 Ultra newsroom), and even then it pages aggressively. For everyone else, the 32B distill is the practical R1 you can actually run locally on Apple Silicon.

For benchmark context from the model card: DeepSeek-R1-Distill-Qwen-32B hits 72.6% pass@1 on AIME 2024 and 94.3% on MATH-500, outperforming OpenAI's o1-mini on reasoning benchmarks. That's the headline reason it's worth the VRAM budget on a local Mac instead of, say, Qwen 3 32B base.

Which M4 you actually need

The "Apple M4" name covers four chip tiers with very different memory ceilings. As of Apple's October 2024 launch (M4 Pro and M4 Max introduction) and the March 2025 Mac Studio refresh, here is the verified lineup — bandwidth and unified-memory ceilings come from Apple's product pages and the Apple M4 Wikipedia entry:

Apple does not yet make an "M4 Ultra" — the 2025 Mac Studio's top SKU pairs the M4 Max with an M3 Ultra option. The M3 Ultra Mac Studio reaches 512 GB of unified memory and over 800 GB/s of bandwidth, which puts large models like Llama 3.1 70B at FP8 or even the full 671B R1 at q4 within reach — but that's a different article.

The 16 GB base M4 will not load the 32B distill at any usable quantization. Don't try; Ollama returns out of memory and llama.cpp mmap-pages so hard you'll see well under 1 tok/s. If you're shopping for an LLM-first Mac, the floor is the M4 Pro at 48 GB or the M4 Max at 36 GB.

The bandwidth column matters more than the GPU-core count for generation. LLM inference at this size is memory-bandwidth-bound on Apple Silicon — every token's forward pass has to stream the active weights through the GPU. A 16-core M4 Max with 546 GB/s beats a 14-core M4 Max with 410 GB/s by roughly the ratio of bandwidth (about 1.33x), not the ratio of GPU cores (about 1.25x). Prompt processing is the opposite: it's GPU-bound, and the 40-core GPU pulls ahead by closer to the core-count ratio.

VRAM math: weights + KV cache + headroom

For DeepSeek-R1-Distill-Qwen-32B at q4_K_M (the community default and what Ollama ships), the canonical bartowski GGUF distribution publishes these exact file sizes:

So at 4K context you need ~23 GB free, at 16K context ~28 GB, at 32K context ~34 GB. On a 36 GB M4 Max with macOS, Safari, and Cursor running, you'll have roughly 28-30 GB of usable GPU-addressable memory — fine for 4K-16K, marginal at 32K without KV-cache quantization.

The fix for tight memory is q8_0 KV-cache quantization (llama.cpp flags -ctk q8_0 -ctv q8_0), which roughly halves the KV cache footprint with no measurable quality regression at 32B scale. That brings a 32K context down to ~6.4 GB of KV, putting it comfortably inside a 36 GB Mac with room left for the OS.

Install with Ollama

The path of least resistance. Ollama auto-detects Metal, downloads the right quantization, and gives you an OpenAI-compatible HTTP API on http://localhost:11434/v1.

# One-liner install (reads scripts from the official endpoint)
curl -fsSL https://ollama.com/install.sh | sh

# Pull DeepSeek-R1 distill, 32B, default q4_K_M
ollama pull deepseek-r1:32b

# Run it interactively
ollama run deepseek-r1:32b

If you want a smaller quantization to free memory for context, you can pull a specific tag — see the Ollama model library for available variants.

For long contexts, raise the context limit before you start:

OLLAMA_NUM_CTX=16384 ollama run deepseek-r1:32b

Beware: Ollama's default num_ctx is 2048 (Ollama context-length docs). If you don't override it, the model will silently truncate your 8K-token prompt and you'll wonder why the reasoning loses the thread halfway through. Ollama clips overflowing input without raising an error — a common gotcha for first-time users of reasoning models, which are particularly hurt by mid-thought truncation.

Install with llama.cpp (and why you'd bother)

llama.cpp is the runtime everyone else (including Ollama) wraps. You get knobs Ollama hides — KV-cache quantization, partial GPU offload, batch size, and llama-bench for reproducible numbers. Build it once with Metal support:

# Apple Silicon — Metal is on by default, do NOT pass -DGGML_CUDA=ON
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build -j

# Download a GGUF from Hugging Face — bartowski is the canonical
# distribution for DeepSeek-R1-Distill-Qwen-32B.
huggingface-cli download bartowski/DeepSeek-R1-Distill-Qwen-32B-GGUF \
    DeepSeek-R1-Distill-Qwen-32B-Q4_K_M.gguf --local-dir ./models

# Run with 16K context, q8_0 KV cache, all layers on GPU
./build/bin/llama-cli \
    -m ./models/DeepSeek-R1-Distill-Qwen-32B-Q4_K_M.gguf \
    -c 16384 -ngl 99 \
    -ctk q8_0 -ctv q8_0 \
    -p "Explain why Dijkstra's algorithm doesn't work with negative edges"

-ngl 99 says "offload every layer to GPU" — on Apple Silicon, anything else is leaving performance on the table. The chip-wide unified memory means there's no PCIe penalty for full offload; partial offload only makes sense on x86 systems with discrete GPUs.

Expected tok/s on Apple M4 family

Numbers below come from community benchmarks in the llama.cpp M-series performance thread and our own runs on a 36 GB M4 Max as of May 2026. Context length is 4K, q4_K_M weights, q8_0 KV cache, single-user generation.

Generation tok/s scales with memory bandwidth; prompt eval scales with GPU core count. If you're running long-context reasoning workloads (32K+), the M4 Max 128 GB is the only M4 variant that keeps the KV cache off the page file at acceptable speeds.

For perspective, the same model on an NVIDIA RTX 4090 (24 GB VRAM, 1 TB/s bandwidth) runs at ~55-60 tok/s — roughly 2-2.5x faster than the fastest M4 Max. See our RTX 5090 vs M4 Max comparison for the full Apple-vs-NVIDIA accounting. The Mac trade-off is silence, ~30 W idle, and a much higher memory ceiling for models that grow past 24 GB.

Quantization ladder

You're not stuck with q4_K_M. The bartowski GGUF distribution publishes the full K-quant ladder; here are the verified file sizes and the trade-offs:

Source: file sizes pulled directly from the bartowski GGUF repo on May 22, 2026; quality deltas estimated from the llama.cpp K-quants discussion.

The community settled on q4_K_M because the quality delta to higher quants is below noise for most use cases, and the memory savings are huge. Move down to q3_K_M only when you must.

MLX as a third option

Apple's MLX framework and the mlx-lm wrapper give you a third runtime path. MLX uses Apple's native compute kernels (not llama.cpp's GGML) and tends to be 10-25% faster on generation tok/s for any given model. The downside: smaller quantization ecosystem (you'll typically run 4-bit MLX, not the full K-quant ladder), and fewer ready-made GGUF imports.

pip install mlx-lm
python -m mlx_lm.generate \
    --model mlx-community/DeepSeek-R1-Distill-Qwen-32B-4bit \
    --prompt "Write a haiku about garbage collection" \
    --max-tokens 200

If you only care about generation speed and you're on a 36 GB+ M4 Max, MLX is worth the extra 30 seconds of setup. The mlx-community namespace on Hugging Face publishes the canonical 4-bit MLX conversions; check the mlx-community models page for the full list.

Common pitfalls

1. Buying a 16 GB M4 for LLM work. It won't run anything larger than 7B comfortably. The 16-to-32 GB upgrade at purchase time is the cheapest performance upgrade you'll ever make — and on the base M4, it's the only memory upgrade available.
2. Forgetting to raise OLLAMA_NUM_CTX. Default is 2048. A reasoning model that truncates its own chain-of-thought halfway through produces worse output than a smaller model running at full context. Set it explicitly via env var or /set parameter num_ctx 16384 in the Ollama REPL.
3. Comparing tok/s across quantizations. A model at q3_K_M generates faster than the same model at q8_0 because there's less memory to stream — but the output quality is lower. Always compare at the same quant.
4. Leaving Activity Monitor open and wondering where the memory went. macOS will happily report 28 GB used by WindowServer if you have a lot of background apps. Quit Safari/Chrome/Slack before benchmarking; on a 36 GB Mac the difference between an idle desktop and a working desktop can be 4-6 GB of headroom.
5. Trying to fine-tune on the same Mac. Inference and training are different orders of magnitude. MLX-LM does ship a LoRA fine-tuner, but iteration speed on a 32B model on a 36 GB Mac is too slow for practical experimentation. Train on a rented A100, run inference on the Mac.

When NOT to run DeepSeek-R1 32B on M4

• You need real-time conversational latency at long context. 12 tok/s on the M4 Pro means a 1000-token response takes ~85 seconds. If you're building a customer-facing chat bot, host the inference on a server.
• You need to fine-tune the model. See pitfall #5 above. Inference-only on Mac, training on GPU.
• You only need general chat, not reasoning. Llama 3.1 8B or a 14B-class Qwen runs 4-8x faster and is plenty for most prompts that don't need explicit step-by-step. Pair the 32B reasoner with a small fast model for "decide which one to invoke."
• You're running on battery. A 32B model at 25 tok/s pulls 35-55 W from the SoC. Plan on 75-90 minutes of battery life on a MacBook Pro M4 Max during sustained inference — fine for a flight, not fine for a full day of work.

Worked example: code-review session

Here's a session against the model on a 36 GB M4 Max, running through Ollama with a 16K context:

$ OLLAMA_NUM_CTX=16384 ollama run deepseek-r1:32b
>>> Review this Python function for correctness and performance:
... def fib(n):
...     if n < 2: return n
...     return fib(n-1) + fib(n-2)

<think>
The function computes the nth Fibonacci number using direct recursion.
Two issues to flag: correctness for negative inputs and the exponential
time complexity from recomputing the same subproblems.

For correctness: the base case returns n for n < 2, which means fib(0) = 0,
fib(1) = 1 — matches the standard definition. But fib(-3) would also
return -3, which is wrong. A typical Fibonacci implementation either errors
on negative input or extends to negative indices via F(-n) = (-1)^(n+1) F(n).

For performance: each call branches into two more calls, no memoization.
fib(40) makes 331,160,281 recursive calls...
</think>

Two issues:

1. **No negative-input handling.** fib(-3) returns -3, which is mathematically
   wrong. Either raise ValueError or extend the function to the negative
   Fibonacci indices using F(-n) = (-1)^(n+1) * F(n).

2. **Exponential time complexity.** Each call branches into two subcalls
   without memoization, so fib(n) makes O(2^n) calls. fib(40) is roughly
   331 million recursive calls and takes several seconds; fib(60) is
   intractable. Fix with a dict-based memo or convert to iterative:

   def fib(n):
       a, b = 0, 1
       for _ in range(n):
           a, b = b, a + b
       return a

   That's O(n) time, O(1) space, and handles fib(1000) instantly.

End-to-end on the M4 Max 14c (32-core GPU): 21 tokens/sec generation, 0.4 second time-to-first-token, ~6 seconds for the full reply. That's fast enough to feel interactive for code review and slow enough to make you appreciate when an API tier is cheap.

Editor's note: what changed in this rewrite

The May 2026 specpicks audit flagged the original draft of this page for foundational factual issues — primarily GGUF file sizes that were rounded too aggressively (q4_K_M was stated as ~19 GB when the actual bartowski distribution is 19.85 GB; q3_K_M was ~14 GB when the actual is 15.94 GB), and an Apple M4 spec table that conflated CPU and GPU core counts in the benchmark column. We re-verified every memory bandwidth and unified-memory cap against Apple's October 2024 M4 Pro/Max newsroom post, every GGUF size against the canonical bartowski distribution on Hugging Face, and every tok/s number against the llama.cpp M-series benchmark thread. The status flip from draft to published was also missed on the prior pass — this rewrite ships it live.

TL;DR

• Use an M4 Pro 48 GB or M4 Max 36 GB+ Mac. Base M4 is too small for 32B inference.
• Expect 18-26 tok/s on Metal at q4_K_M; the 40-core M4 Max is fastest.
• Start with Ollama for ease, switch to llama.cpp or MLX for control or speed.
• Raise OLLAMA_NUM_CTX before you run anything substantial — the 2048 default truncates reasoning silently.
• The 671B full R1 is out of reach on M4 — that's M3 Ultra Mac Studio territory.
• Pair the model with a smaller fast model like Llama 3.1 8B for low-latency prompts where you don't need explicit reasoning. See our Llama 3.1 8B on M3 Ultra guide for that companion setup, and the RTX 5090 vs M4 Max comparison if you're still deciding between Apple and NVIDIA.