.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
People ask what hardware Ollama needs, and the honest answer is that Ollama itself needs almost nothing. The model decides everything. A 3B model hums along on a laptop from 2019 while a 70B model laughs at anything under 64GB of RAM, so the sizing question starts with picking the model, and only then the machine. This guide gives you the numbers to do that in the right order, using verified download sizes from the current model library (August 2026).
The 0.6GB per billion parameters rule of thumb
The community shorthand: a Q4-quantized model takes very roughly 0.6GB of RAM or VRAM per billion parameters, plus overhead for the context. Treat it as a planning estimate rather than a law. It holds because the popular library tags ship at 4-bit quantization by default, and the download sizes back it up: deepseek-r1:7b is a 4.7GB download, the 14b tag is 9.0GB and the 32b tag is 20GB. Divide any of those by the parameter count and you land near 0.6.
Three things bend the rule. A higher-precision quant (Q8 or fp16) doubles or quadruples the footprint. The context window adds a KV cache on top of the weights, and that cache grows with every token of context you configure, which the Ollama context window guide covers in detail. And the runtime itself needs working memory beyond the weights, so a 4.7GB model does not fit happily in 5GB of free RAM. Plan for the model size plus a couple of GB, minimum.
Memory needed per model size
Download sizes below are from the Ollama model library as of August 2026. The memory column assumes the default quantization and a modest context window.
| Model class | Example tags | Download size | Memory to run comfortably |
|---|---|---|---|
| 1B to 3B | llama3.2:1b, llama3.2:3b, gemma3 small tags | 1GB to 2GB | 8GB system RAM |
| 7B to 8B | mistral, llama3.1:8b, deepseek-r1:7b (4.7GB), deepseek-r1:8b (5.2GB) | 4GB to 5GB | 16GB RAM or an 8GB GPU |
| 13B to 14B | deepseek-r1:14b (9.0GB), qwen3 mid tags | 9GB to 10GB | 16GB RAM at a squeeze, 12GB to 16GB VRAM on GPU |
| 27B to 32B | gemma3:27b, qwen3:32b, deepseek-r1:32b (20GB) | 17GB to 20GB | 32GB RAM or 24GB VRAM |
| 70B | llama3.1:70b, deepseek-r1:70b (43GB) | 43GB | 64GB RAM or 48GB+ VRAM |
| gpt-oss:20b | gpt-oss:20b (14GB) | 14GB | 16GB memory systems (MXFP4 quantization) |
| gpt-oss:120b | gpt-oss:120b (65GB) | 65GB | A single 80GB GPU |
The gpt-oss rows are useful anchors because the memory claims are stated by the model's publishers rather than estimated: the 20b tag targets 16GB systems thanks to its MXFP4 quantization at 4.25 bits per parameter, and the 120b tag fits one 80GB card. Our guide to running gpt-oss goes deeper on both.
CPU-only performance: what to expect
CPU-only Ollama is more usable than its reputation suggests, within limits. A 3B model on a modern CPU feels responsive. A 7B or 8B model is fine for chat, summaries and background automation if you accept single-digit to low-teens tokens per second. At 14B the wait gets noticeable, and past 27B a CPU-only box is for patience training.
Two hardware notes matter here. Ollama expects AVX2, which every AMD and Intel CPU from the last decade has, so only genuinely old or exotic hardware is excluded. And more cores help less than people expect, because token generation is limited by memory bandwidth rather than raw compute. A CPU with fast DDR5 and eight cores beats a sixteen-core machine on slow DDR4 for this job. It's counterintuitive the first time you benchmark it, then it never surprises you again.
GPU sizing: VRAM per model tier
A GPU changes the experience from "usable" to "instant". The same 8B model that limps at 8 tokens per second on a CPU pushes several times that on even a modest card, because GPU memory bandwidth is an order of magnitude higher. The rule is blunt: the whole model plus its KV cache should fit in VRAM. When it doesn't, Ollama splits layers between GPU and CPU, and speed falls off a cliff. Run ollama ps after loading a model; if the processor column shows a CPU/GPU split, you've overshot your card.
Mapping tiers to VRAM: 8GB covers 7B to 8B models, 16GB covers 13B to 14B with context to spare, 24GB handles the 27B class and 48GB or more is 70B territory. Quantized 7B to 13B models sit nicely on a 16GB Tesla T4, which is exactly the niche a Tesla T4 GPU VPS fills. For the 27B+ tiers you want the bigger Blackwell-generation cards, which on a GPU VPS with full passthrough go up to 96GB of VRAM, enough for a 70B model with a fat context window on one card.
Storage planning for model files
Models are multi-gigabyte files and they accumulate. Anyone experimenting seriously has five or six models installed within a month, which puts 40GB to 60GB on disk without trying. My working rule is to provision at least double the space of the models you plan to keep, because pulls download layers before the old version is replaced, and trying variants (a Q8 quant here, a bigger tag there) eats the margin fast.
Disk speed matters more than people assume, for one specific moment: loading. A 20GB model streaming from NVMe reaches memory in seconds, while the same file on spinning rust or a throttled cloud volume keeps you waiting long enough to break the five-minute idle unload cycle's usefulness. Generation speed is unaffected once loaded, so this is purely about how often you tolerate cold starts.
Context window memory overhead
The spec sheets quote memory for the model weights, and then the KV cache quietly adds more. Every token of configured context needs cache space, scaled by the model's size, so raising the context from the 4096 default to 32K adds real gigabytes on the bigger models. This is the classic trap: a machine sized exactly for a 14B model runs out of memory the day someone raises num_ctx for a RAG pipeline. Budget headroom for the context you'll end up wanting, which is nearly always more than the context you start with.
Four sizing scenarios
A laptop for learning
Any 8GB machine from the last eight years or so runs llama3.2:3b or the small gemma3 tags well enough to learn the tooling, build against the API and get a feel for prompting. With 16GB you're into honest 7B to 8B territory. Don't buy hardware to learn Ollama. Use what's on your desk, and see the Ollama GitHub repo for platform-specific install notes.
A 16GB desktop as a daily driver
The sweet spot of consumer hardware. An 8B model leaves room for your browser and IDE, gpt-oss:20b fits by design and a 14B model works if you close some tabs. Add any 8GB+ GPU and the 8B class becomes fast enough that you stop thinking about speed. This is the setup I'd recommend to most developers who want a capable local model without a hardware project.
A CPU VPS for a small always-on assistant
For a Telegram bot, a docs-answering assistant or scheduled summarization jobs, a CPU-only server with 8GB to 16GB of RAM running a 3B to 8B model is a genuinely sensible deployment. Latency tolerance is the deciding factor: a bot that answers in eight seconds instead of two is fine for most automation. A KVM VPS on AMD EPYC with NVMe covers the bandwidth and load-speed side, and the Ollama VPS hosting guide walks through exposing the API safely once it's running.
A GPU server for 27B and up
Once you want 27B-class quality (and the jump in reasoning from 8B to 27B is bigger than benchmarks suggest), you need 24GB of VRAM minimum, and 70B models need 48GB or more. That's rented territory for most teams, since cards this size are expensive to buy and annoying to cool. Full GPU passthrough matters here: you want the model talking to the actual card instead of a virtualized slice of one.
Validation notes
Before committing to hardware, test your shortlisted model on anything available and measure, since ollama run --verbose prints tokens per second after each response. Watch ollama ps for the CPU/GPU split and for total memory with your real context settings, and watch free -h during generation to catch swapping, which silently destroys performance long before anything crashes. If your target model changes, resize the plan: our best Ollama models guide pairs current picks with the tier table above.
