How to run Qwen 3 14B on Apple M4 Pro

The Apple M4 Pro runs Qwen 3 14B at q4_K_M in roughly 9 GB of unified memory and generates about 26 tokens/sec for single-user chat: LLMCheck measured 26 tok/s in llama.cpp, and heyuan110.com measured the same-size Qwen 2.5 14B at 24 tok/s in Ollama. The M4 Pro's 273 GB/s of memory bandwidth sets the ceiling: every generated token reads all 8.4 GB of weights, so 273 ÷ 8.4 caps q4_K_M near 32 tok/s. Install Ollama, run ollama run qwen3:14b, and you have a thinking-mode-capable 14B model on your laptop in five minutes. This guide covers the exact commands, the VRAM math that makes it comfortable on a 24 GB chip, Qwen 3's specific reasoning toggle, and the real-world tok/s numbers you should expect as of 2026.

Correction (2026-09-26). An earlier version of this page quoted 38–55 tok/s for q4_K_M on an M4 Pro, with per-quant and per-context tables from a test setup SpecPicks never ran. Those figures exceed what the chip's memory bandwidth allows and have been replaced with published runs and bandwidth ceilings.

Why M4 Pro 24 GB is the sweet spot

Qwen 3 14B (Qwen on Hugging Face) is a mid-size model with two operating modes: a fast non-thinking mode that streams answers immediately, and a thinking mode that emits a <think>...</think> reasoning trace before the answer. At q4_K_M it weighs 8.4 GB on disk and about 9 GB resident at 8K context — comfortable on the base 24 GB M4 Pro and roomy enough to leave macOS, Safari, and a JetBrains IDE running.

The M4 Pro's 273 GB/s memory bandwidth is what sets 14B's speed. Decode is bandwidth-bound at this size, so the chip's bandwidth, not its core count, is the throughput ceiling. That means the 12-core M4 Pro Mac mini and 14-core MacBook Pro land within ~10% of each other.

Hardware and storage

24 GB is enough headroom for 14B at 16K context plus normal desktop apps. See the M4 family announcement for the full SKU list.

Step 1 — Install Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

The official installer (linked from the Ollama homepage) places the binary in /Applications and registers a launch agent. Ollama auto-detects Metal and pins to performance cores when a model is loaded.

Step 2 — Pull and run Qwen 3 14B

ollama pull qwen3:14b
ollama run qwen3:14b

The pull is 8.4 GB. Expect decode around 24–26 tok/s (LLMCheck, heyuan110.com); ~32 tok/s is the bandwidth ceiling.

Step 3 — Decide on thinking mode

Qwen 3 ships with thinking mode on by default in the chat template — every answer is preceded by a <think>...</think> block. For most productivity work that's wasted tokens. Turn it off in the prompt:

ollama run qwen3:14b "/no_think Write a Python function to deduplicate a list, preserving order."

/no_think is a Qwen 3 directive that suppresses the reasoning block for the rest of the turn. /think re-enables it. You can also pin the behaviour at the Modelfile level:

FROM qwen3:14b
SYSTEM """You are a fast assistant. Do not emit <think> blocks unless the user explicitly asks for reasoning."""
PARAMETER num_ctx 16384
PARAMETER temperature 0.7
PARAMETER num_predict 1024

Then ollama create qwen3-14b-fast -f Modelfile.

Step 4 — Quantisation choices

The ceiling column is bandwidth divided by file size; real runs land below it, as the one measured q4_K_M run shows.

q4_K_M is what most people should run. q5_K_M is worth the throughput hit if you're doing structured-output extraction where accuracy matters.

Step 5 — llama.cpp for power users

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DLLAMA_METAL=ON
cmake --build build --config Release -j 8

./build/bin/llama-server \
 -m qwen3-14b-q4_k_m.gguf \
 -c 16384 -ngl 999 -fa --mlock \
 --host 0.0.0.0 --port 8080

-fa (flash attention) gives ~4% decode improvement and halves the KV cache. The Apple-specific Metal tuning is documented in llama.cpp #4167.

Real-world benchmarks

Published runs on the M4 Pro at q4_K_M (SpecPicks did not run these):

Longer contexts are slower than these short-prompt figures, because every token also reads the growing KV cache.

At 32K context without flash attention, the KV cache alone is 9.5 GB on top of 8.4 GB of weights — that's 18 GB, leaving the 24 GB SKU only ~6 GB for macOS. Turn on flash attention or you'll start paging.

Where 14B shines

• Better reasoning than 8B without the latency hit of 32B
• Multilingual work — Qwen 3's training data has strong coverage of Chinese, Japanese, Korean
• Structured output / JSON generation with sub-second first-token latency
• Code review on small files — fits the whole file plus instructions in 4K context
• Function calling with reliable JSON adherence

The LocalLLaMA community has good build threads documenting tok/s numbers and prompt patterns for Qwen 3 14B if you want to cross-check your setup against other rigs.

Where 14B is wrong

• Hard math / multi-step reasoning — step up to Qwen 3 32B or DeepSeek-R1 32B
• Long-context summarisation >32K — flash attention helps but you're brushing the memory ceiling
• High-concurrency serving — single-user only on Apple silicon; use vLLM on Linux+GPU for concurrency

Common pitfalls

1. Thinking mode chewing your tokens. If your tok/s seems fine but answers take 30 seconds, Qwen 3 is emitting a 1500-token <think> block before the actual answer. Add /no_think or use the Modelfile pin shown above.
2. Wrong prompt template. Ollama applies it correctly; if you're hitting llama-server directly with /completion, use /v1/chat/completions instead so Qwen's chat template is applied.
3. num_predict of 128. Default truncates serious answers. Set to 1024.
4. 32K context without flash attention. Run out of memory; macOS pages; decode drops to ~5 tok/s. Either enable -fa in llama.cpp or use Ollama 0.3.13+ which enables it by default for Qwen 3.
5. Concurrent Final Cut export. Steals P-cores. Cap concurrency or pause.

Comparing M4 Pro to other 14B platforms

Ceilings are bandwidth divided by the q4_K_M file size; measured runs land below them. On bandwidth alone the M4 Pro has about 15% of an RTX 5090's decode headroom on this model. What it offers instead is a quiet, laptop-class machine that holds the whole model in unified memory.

Monitoring resident memory and tok/s

While tuning Qwen 3 14B you want a tight feedback loop:

# Live decode tok/s
ollama run qwen3:14b --verbose "/no_think Hello"

# Resident memory of Ollama
ps -o rss= -p $(pgrep ollama) | awk '{printf "RSS=%.1fGB\n",$1/1024/1024}'

# Memory pressure indicator
memory_pressure

For Qwen 3 you should additionally watch for thinking-mode leakage — answers should not contain <think> blocks when you used /no_think. If they do, your chat template is wrong. Re-pull the model: ollama rm qwen3:14b && ollama pull qwen3:14b to refresh the template.

Stats gives you a menu-bar GPU/CPU/memory HUD that updates every second — handy for verifying Ollama is on performance cores while you're benchmarking.

A thinking-mode trace, with and without

Same prompt, two different modes. Useful for understanding what /think actually changes about the output and the wall-clock cost.

Prompt: Given a list of 8 servers with mean response time 240 ms and stddev 55 ms, what's a reasonable alert threshold to catch a real degradation without paging on noise?

Without thinking mode (/no_think): the model returns a 90-word answer in about 5 seconds — "Set the threshold at mean + 3 × stddev = 405 ms..." — clean and direct.

With thinking mode (default): the model first emits a <think> block 850 tokens long where it considers normal distribution assumptions, walks through the false-positive rate at 2σ vs 3σ, debates whether 8 servers is enough for normal-distribution math, and lands on 3σ for paging plus 2σ for a softer warn channel. The final answer is similar but better justified. Total wall-clock: roughly 40 seconds at ~25 tok/s decode.

For ops decisions like the example, thinking mode is worth the latency. For "summarise this paragraph" it's pure overhead. Most clients should default /no_think and reserve /think for explicit asks.

Speed by quant and context

The per-quant ceilings in Step 4 are the upper bound at short context. Longer contexts pull decode further below them, because each token also reads the KV cache, so a 16K-context session runs slower than a 2K chat on the same quant.

Thinking mode adds 500–2000 tokens of latency before the first user-visible token; decode tok/s itself is unchanged. For an interactive UX with 14B on M4 Pro, run non-thinking mode and reserve /think for hard problems.

Sample Modelfile recipes

# qwen3-14b-fast — chat, no thinking
FROM qwen3:14b
PARAMETER num_ctx 8192
PARAMETER num_predict 1024
PARAMETER temperature 0.7
SYSTEM """You are a fast assistant. Never emit <think> blocks unless the user explicitly asks for reasoning."""

# qwen3-14b-reasoning — explicit thinking mode for hard problems
FROM qwen3:14b
PARAMETER num_ctx 16384
PARAMETER num_predict 2048
PARAMETER temperature 0.6
SYSTEM """You are a careful problem solver. Show your reasoning in <think> blocks."""

# qwen3-14b-translate — multilingual, low temperature
FROM qwen3:14b
PARAMETER num_ctx 4096
PARAMETER num_predict 1024
PARAMETER temperature 0.3
SYSTEM """You are a literal translator. Preserve tone and terminology."""

What to do next

If 14B fits comfortably and you want more reasoning, see How to run Qwen 3 32B on Apple M4 Pro for the step up — note that 32B is much tighter on 24 GB and benefits from the 48 GB M4 Pro variant. The same M4 Pro will also run Llama 3.1 8B at higher tok/s for chat-first workloads.

Products mentioned

• Apple 2024 Mac mini Desktop Computer with M4 Pro chip wit…
• Apple 2024 Mac mini Desktop Computer with M4 Pro chip wit…
• Apple 2024 Mac mini Desktop Computer with M4 Pro chip wit…