.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
I keep a shortlist of models I'd redeploy tomorrow if a server died, and it's much shorter than the Ollama library would suggest. Hundreds of models are one ollama pull away and most of them aren't worth your disk space. These are the ones I'd pull today, grouped by task, with the hardware each one honestly needs.
One note on freshness before the picks. The library moves fast and any "best models" list ages in months. The criteria age much slower: match the model to the task, match the quantized size to your memory and prefer the newest generation at a size you can run well. When a pick here gets replaced, apply the same logic to its successor.
Best Ollama model for general chat
Pick: llama3.1:8b. A boring choice and still the right one. It follows instructions predictably, handles tool calling, and nearly every framework, template and tutorial on the internet was tested against it first. On a machine with 8GB of VRAM or 16GB of RAM it runs without drama.
ollama run llama3.1:8bRunner-up: gemma4:12b. Google's current generation gives you noticeably sharper answers than the Llama 3 era plus a 256K context window, and the 12b tag is a 7.6GB download that fits a 12GB card. If your hardware can hold it, I'd argue it beats the pick on pure output quality. It loses on compatibility, since some older tooling still assumes Llama-style behavior. Details and tags are on the gemma4 library page.
Best Ollama model for coding
Pick: qwen3-coder:30b. This is the one I'd defend in an argument. It's a mixture-of-experts model with 3.3B active parameters, so it generates fast for its size, and the 256K context window means you can feed it whole modules instead of snippets. The download is 19GB, which puts it in 24GB VRAM territory for GPU inference, though the low active parameter count makes it more tolerable on CPU than a dense 30B would be.
ollama run qwen3-coder:30bRunner-up for 16GB machines: qwen2.5-coder:14b. A 9.0GB download, dense, 32K context, and it punches well above its size on code generation and repair. If 14b feels sluggish on your box, qwen2.5-coder:7b keeps most of the quality at half the footprint. I'd take either of these over a general chat model for anything code-shaped; the specialization is real.
Best Ollama model for reasoning
Pick: deepseek-r1:8b. The default tag of the R1 family, a 5.2GB download that thinks before it answers. For math, multi-step planning and gnarly debugging sessions the visible reasoning genuinely improves results. The catch is token overhead: a thinking model burns two to five times the tokens of a direct answer, so responses are slower and longer. Reserve it for problems where a wrong first answer costs you more than the extra wait, and use a normal chat model for summaries and quick questions. I've covered sizes, the API and the thinking output in a full guide to running DeepSeek-R1 with Ollama.
ollama run deepseek-r1:8bRunner-up: gpt-oss:20b. OpenAI's open-weight model with a party trick the R1 distills lack: adjustable reasoning effort (low, medium, high), so one model covers both quick answers and hard problems. MXFP4 quantization squeezes it onto 16GB machines despite the 20B parameter count. My notes on running gpt-oss with Ollama cover the effort levels and the 120b variant.
Best small Ollama models for CPU-only servers
No GPU changes the math completely. You want the fewest parameters that still do the job, because CPU token generation speed scales roughly with model size.
Pick: llama3.2:3b. Fast enough on a modern 4 vCPU server to feel interactive, and capable enough for summarization, classification, extraction and light chat. This is what I'd run behind an internal tool.
ollama run llama3.2:3bRunner-up: qwen3:4b. A 2.5GB download with a 256K listed context and optional thinking mode, which is a strange amount of capability for something this small. The full size range from 0.6b up sits on the qwen3 library page. For truly tiny footprints, gemma3:1b is an 815MB download and gemma3:270m goes down to 292MB, useful for embedded-style jobs where latency beats brilliance.
Best Ollama vision models
Pick: gemma4:12b. Image understanding is built in rather than bolted on, and the same tag doubles as your chat model, which keeps your VRAM budget honest. The e2b and e4b edge tags add audio input if you need it. Runner-up: qwen2.5vl, which has a strong reputation for document and screenshot parsing specifically. The old llava tags still work but the newer generations read charts and dense text far better, so I'd skip llava for new setups. On limited hardware, gemma3:4b is the smallest vision model I'd trust, at a 3.3GB download.
Best Ollama embedding models for RAG
Embeddings are the quiet half of every RAG setup and the good news is they're cheap. Pick: nomic-embed-text. It's small, fast, handles long passages and has been the community default long enough that every vector database tutorial assumes it.
ollama pull nomic-embed-textRunner-up: mxbai-embed-large, when retrieval quality matters more than speed. Newer options like embeddinggemma and qwen3-embedding (strong for multilingual corpora) are worth testing if you're starting fresh. Embedding models run happily on CPU, so don't spend GPU memory on them.
Ollama models by VRAM: 8GB, 16GB and 24GB picks
The rule of thumb I use: a Q4 model needs roughly 0.6GB of memory per billion parameters, plus overhead for context. The full arithmetic lives in our guide to Ollama hardware requirements, but here's the short version.
8GB VRAM: 7B and 8B models at Q4. llama3.1:8b, qwen2.5-coder:7b, deepseek-r1:7b. Leave room for context; a fully loaded 8B with a long context will spill into RAM and slow down.
16GB VRAM: the sweet spot for price versus capability. Everything above runs with headroom, 12B to 14B models fit comfortably and gpt-oss:20b fits thanks to MXFP4. A 16GB card like the Tesla T4 handles the 7B to 13B class at genuinely interactive speeds.
24GB VRAM: the 27B to 32B class opens up, and it's a real quality jump. qwen3-coder:30b, gemma4:31b, deepseek-r1:32b. This is where I'd point anyone doing serious daily work with local models; a GPU VPS gets you there without buying a card, with passthrough options from the T4 up to 96GB Blackwell territory for the truly large tags.
CPU-only: 3B to 8B dense models, or a MoE like qwen3:30b, which streams tokens surprisingly well because only 3.3B parameters activate per token. Expect reading-speed output at best and budget RAM at the same 0.6GB per billion rule.
Models I'd skip
A 70B model squeezed onto a 24GB card at Q2 is the classic mistake. Aggressive quantization below Q4 degrades quality enough that a clean 27B to 32B model beats it while running twice as fast, so run the biggest model that fits well instead of the biggest model that fits at all. I'd also skip llama2-era models entirely (the newer small models embarrass them), any 400B-class or 671B tag outside server-class hardware, and vision models on CPU-only boxes, where image processing takes long enough to feel broken.
Validating models on your own hardware
Benchmarks are a starting point and your prompts are the finish line. Pull two candidates, run your five most common real tasks through both and check ollama ps while they run: if the output shows part of the model sitting in system RAM instead of GPU memory, size down. Remember that every model here defaults to a 4096-token context regardless of what the library page lists, which quietly truncates long documents; raising it is a one-variable fix covered in our Ollama context window guide. If you'd rather skip setup and go straight to comparing models in a browser, the Ollama VPS template deploys Ollama with Open WebUI in one click, and swapping between candidates becomes a dropdown instead of a terminal session.
