Best LLM for 32GB RAM (No GPU): 7 Models Benchmarked on CPU

Short answer: with 32GB of system RAM and no GPU, pull qwen3:30b-a3b — an 18.56GB Q4_K_M download that activates only 8 of its 128 experts per token, so a CPU reads about 1.9GB of weights per token instead of 18.56GB. That makes a 30-billion-parameter model roughly four times faster than a dense 14B on the same machine. If you want a dense model, qwen3:14b (9.28GB) is the quality pick and qwen3:8b (5.23GB) is the one that stays responsive on older DDR4.

Every download size on this page came from the Ollama registry manifests we pulled on 18 August 2026 — not from a spec sheet, and not rounded. The speed figures are calculated ceilings from the memory-bandwidth formula, clearly labelled as such, because we would rather show you the arithmetic than quote a benchmark we did not run on your RAM.

---

RAM Is Not VRAM (Start Here)

If you searched for "32GB RAM," you almost certainly mean the DIMMs on your motherboard — and that is a different constraint from graphics-card memory, with different answers.

The gap in that bandwidth row is the whole story. A model in system RAM on a CPU is not "a bit slower" than the same model on a GPU — it is usually five to fifteen times slower, because token generation is a memory-streaming problem and a graphics card's memory is an order of magnitude faster.

The consolation prize is real, though: you have far more of it, and at 32GB you can hold models that a $700 graphics card cannot. That is exactly the trade this page is about.

If you do have a usable card, stop here and use the VRAM calculator or our 24GB VRAM model picks instead — this page will only slow you down.

---

The 7 Models

Sizes below are the exact bytes in the Ollama registry manifest, and the parameter counts and quantisation types come from each model's config blob — our own measurement, not a vendor claim. The two speed columns are calculated ceilings, explained in the next two sections.

Sizes and metadata read from registry.ollama.ai manifests and config blobs, 18 August 2026. Ceilings are calculated, not measured — see The Speed Math.

What to make of that ordering:

• Pick 1 if you want the best model that is still usable. Qwen3-30B-A3B is the largest and the second fastest. That is not a typo; see the next section.
• Pick 2 if you want reasoning. gpt-oss:20b is also a mixture-of-experts model (4 of 32 experts active per token, from its config.json) and ships at MXFP4, so it is smaller on disk than the numbers suggest.
• Pick 3 if your RAM is slow or you want snappy chat. qwen3:8b is the one that still feels interactive on an older desktop.
• Picks 4-7 are the dense tier, and they are all slow on a CPU. A 14B dense model reads all 9GB of itself for every single token. They are worth it only if you specifically need what they are good at — qwen2.5-coder:14b for code completion, phi4:14b for tight reasoning, gemma3:12b for its multimodal and multilingual coverage.

One that nearly made the list: mistral-small3.2:24b at 15.18 GB (24.0B dense, Q4_K_M). It fits 32GB fine and it is a genuinely strong model — but dense at 24B means roughly 2 tok/s on DDR4. Load it if you have a batch job and patience, not for chat.

---

Why the 30B Beats the 14B

Because CPU speed is set by how many bytes you read per token, and a mixture-of-experts model reads a fraction of itself.

Here is Qwen3-30B-A3B's architecture, straight from the official config.json: 48 layers, hidden size 2048, 128 experts with 8 active per token, expert intermediate size 768, 32 attention heads over 4 key-value heads.

Work the numbers and you get, per token:

• Expert weights actually touched: 8 experts × 3 matrices × 2048 × 768 × 48 layers ≈ 1.81B parameters
• Attention (all layers, always read): ≈ 0.91B parameters
• Output projection over the vocabulary: ≈ 0.31B parameters
• Total ≈ 3.0B parameters read per token — out of 30.5B on disk

At the file's average of about 4.9 bits per parameter, that is roughly 1.9GB of memory traffic per token. A dense qwen3:14b at 9.28GB reads 9.28GB per token. Same machine, same RAM, nearly five times the traffic — which is why the smaller-looking model is the slower one.

The catch is that the MoE model still has to live in RAM in full. All 18.56GB stays resident, because the router picks different experts for every token and any of the 128 may be needed next. MoE buys you speed with capacity. At 32GB you have the capacity to spend; at 16GB you do not, which is why the answer at the 16GB tier is a completely different list.

---

The Speed Math

tokens/second ≈ effective memory bandwidth ÷ bytes read per token. That single line explains every number in the table, and it is why your RAM speed matters more than your CPU.

Theoretical peak bandwidth is pure arithmetic — transfers per second × 8 bytes per channel × number of channels:

Be clear about what the "effective" column is: an assumption, not a measurement. Real streaming workloads land somewhere in the region of 60-75% of theoretical peak depending on the memory controller, timings and how many DIMMs are populated. We picked 65% and applied it consistently so the models are comparable to each other. Your machine will differ. The ratios are the durable part; the absolute numbers are an estimate.

Two independent sanity checks that the model is not nonsense:

• Our own CPU-only inference guide cites InsiderLLM's published figures — a DDR4 dual-channel laptop at roughly 38 GB/s runs a 7B model at ~5-8 tok/s. The formula predicts 4.5GB per token ÷ 38 GB/s ≈ 8 tok/s. That lands in the published range.
• The same page cites a published CPU-only run of Qwen3-30B-A3B on a Ryzen 9950X hitting 30+ tok/s. Our DDR5-6000 ceiling for that model is ~33. Close enough to trust the shape of the curve.

The formula also tells you what not to buy. A faster CPU moves nothing here, because the cores spend their time waiting on memory. What moves the needle: a second DIMM if you are running one, DDR5 over DDR4, and XMP/EXPO actually switched on.

One thing the formula does not cover: prompt processing. Reading your prompt is compute-bound and parallel, so it behaves nothing like generation — a CPU chews through prompt tokens far faster than it emits new ones. The practical consequence is that a long document pasted into the context costs you a noticeable up-front pause and then generates at the usual pace. Ollama reports both separately, which is how you should read your own results.

---

What Actually Fits in 32GB

Weights are only part of the bill. Budget model file + KV cache + about 2-3GB for the OS, and set your context length deliberately rather than letting it default.

The KV cache grows linearly with context length, and you can compute it exactly:

KV bytes per token = 2 (K and V) × layers × kv_heads × head_dim × bytes_per_element

For qwen3:30b-a3b (48 layers, 4 KV heads, head dim 128, fp16) that is 98,304 bytes — about 96 KiB per token:

Computed from the official config.json and the registry file size. Resident memory in practice also includes the runtime, compute buffers and your page cache — check yours with ollama ps rather than trusting this table to the last gigabyte.

That last row is the trap at this tier. The model loads, you paste in a long document, and the machine starts swapping — at which point tokens per second falls off a cliff, because your effective bandwidth is now SSD bandwidth. If your box slows to a crawl mid-generation, suspect the context length before you suspect the model.

Ollama's context default is automatic — OLLAMA_CONTEXT_LENGTH defaults to 0, which its own environment documentation describes as "4k/32k/256k based on VRAM." On a CPU-only machine you want that decision to be yours:

# Pin the context to something 32GB can actually hold
OLLAMA_CONTEXT_LENGTH=16384 ollama serve

For the full cross-model version of this table, our Ollama model RAM and VRAM table covers every size, and RAM requirements for local AI answers the reverse question of how much memory a given model needs.

---

Settings That Matter

Three settings change your experience; everything else is noise at this tier.

Threads — leave the default. Ollama's num_thread defaults to 0, commented in its source as "let the runtime decide," and it only passes -t to the runtime when you set a non-zero value. llama.cpp's own default then resolves through common_cpu_get_num_math(), which returns the physical core count — and on hybrid Intel CPUs under Linux, deliberately counts only the performance cores rather than the E-cores. That is almost always the right answer. Because the work is memory-bound, piling on more threads than you have physical cores generally buys nothing.

Quantisation — Q4_K_M is the default for a reason. Every dense model in the table above ships Q4_K_M on its default Ollama tag; we read that from the config blobs. Going down to Q3 to save 2GB costs measurable quality; going up to Q8 doubles your bytes-per-token and halves your speed. At 32GB you are not short enough on capacity to need Q3, and not fast enough on bandwidth to afford Q8.

Parallel requests — set to 1. OLLAMA_NUM_PARALLEL defaults to 1, which is what you want. If something in your setup raised it, each concurrent slot gets its own KV cache allocation, and on a memory-bound CPU box two simultaneous requests do not run twice as fast — they run at half speed each and use twice the RAM.

---

Measure Your Own Box

Do not trust our ceilings, or anyone else's. Two commands give you the real number in about a minute.

# Real tokens per second on your hardware
ollama run qwen3:30b-a3b --verbose

Ask it something that needs a few hundred tokens of answer. The summary printed afterwards splits prompt eval rate (how fast it read your input) from eval rate (how fast it wrote the reply). The second number is the one that decides whether you enjoy using it.

# What is actually resident, and whether it is on CPU
ollama ps

The PROCESSOR column should say 100% CPU. The SIZE column is your real memory footprint including the KV cache — compare it against the table above and against your free RAM.

If you want to compare quantisations or thread counts properly, llama-bench from llama.cpp is the right tool; it runs a fixed workload and reports prompt and generation rates separately, so the comparison is fair.

---

The Usability Line

Below about 5 tokens per second, CPU inference is a technically-interesting waste of an evening. Above 10, it is a tool you will actually open again.

Roughly where things land, and worth being blunt about:

• Under 3 tok/s — slower than reading aloud. Fine for an overnight batch job, unusable for conversation.
• 3-5 tok/s — you will watch the cursor. This is where every dense 14B model sits on DDR4, which is why we are lukewarm on picks 4-7 unless you need their specific strengths.
• 5-10 tok/s — tolerable. About reading pace. Fine for drafting, annoying for iteration.
• 10+ tok/s — genuinely usable. On a 32GB no-GPU box, this is realistically MoE territory, or a small dense model on DDR5.
• 20+ tok/s — comfortable. Achievable with qwen3:30b-a3b or gpt-oss:20b on dual-channel DDR5.

So the honest bottom line for this tier: 32GB of RAM with no GPU is a real local-AI machine, but only if you spend the capacity on a mixture-of-experts model. Pick a dense 14B because "14 is smaller than 30" and you will conclude that CPU inference does not work — when the actual problem was that you picked the model that reads five times more memory per token.

Thinking about buying more? Whether the next capacity step earns its price is a genuinely open question at these bandwidths — 32 vs 64 vs 128GB for local AI works through it. And if you are on 16GB today, the 16GB list and the 8GB list are the right starting points instead.

---

Sources

• Ollama registry (registry.ollama.ai) — every download size, parameter count and quantisation type in this article was read from the model manifests and config blobs on 18 August 2026. These are exact bytes, not marketing round numbers.
• Qwen3-30B-A3B config.json (Hugging Face, Qwen/Qwen3-30B-A3B-Instruct-2507) — 48 layers, 128 experts, 8 active per token, 4 KV heads, head dim 128. Source of the active-parameter and KV-cache calculations.
• openai/gpt-oss-20b config.json — 32 local experts, 4 active per token.
• ollama/ollama source — api/types.go (NumThread: 0, // let the runtime decide), llm/llama_server.go (-t passed only when set), envconfig/config.go (OLLAMA_CONTEXT_LENGTH default 0 = "4k/32k/256k based on VRAM", OLLAMA_NUM_PARALLEL default 1).
• ggml-org/llama.cpp source — common/common.cpp, common_cpu_get_num_math() returning the physical core count and excluding E-cores on hybrid x86 Linux.
• Third-party CPU measurements — itsfoss's 8-model CPU-only test (May 2026) and InsiderLLM's bandwidth-scaling figures, both cited and linked in our CPU-only inference guide. Used here only as sanity checks against the formula.

---

FAQ