Best Ollama Models for 4GB VRAM: 8 That Really Fit (4GB VRAM)
GTX 1650, GTX 1050 Ti, RTX 3050 4GB laptop, MX550 — the pulls that stay on-GPU, and the ones that only look small
The best Ollama model for 4GB VRAM in 2026 is qwen3.5:2b — 2.7GB in the Ollama library, with tool calling, thinking and image input, which still leaves roughly a gigabyte of a 4GB card for context and the desktop. Below it phi4-mini (2.5GB), qwen3:4b (2.5GB), granite4.1:3b (2.1GB), llama3.2:3b (2.0GB) and qwen2.5-coder:3b (1.9GB) all fit, and gemma3:1b (815MB) is the floor when the same card is also driving your monitors. Everything from the 4B-vision class up — qwen3.5:4b is 3.4GB, gemma3:4b is 3.3GB — technically loads on a 4GB card and then pushes layers onto your CPU, which is where the speed goes.
Models that fit in 4GB VRAM
Tested reference: GTX 1650 / GTX 1050 Ti / RTX 3050 4GB laptop / MX550. Figures are for Q4_K_M with a modest context window.
| Model | Size | Build | VRAM used | Speed |
|---|---|---|---|---|
| WINNERqwen3.5:2b The most capable pull that still leaves a 4GB card usable: tools, thinking, image input and a 256K native context. Worth knowing before you type it — Ollama publishes two builds under this name, the default qwen3.5:2b at 2.7GB and an explicit qwen3.5:2b-q4_K_M at 1.9GB. That 0.8GB gap is a fifth of the whole card, decided by whether you typed the suffix. ollama pull qwen3.5:2b | 2B (vision) | Ollama default tag | 2.7GB | mid · ~2.7GB/token |
| phi4-mini The strongest text-only model per gigabyte at this tier, with function calling. Its size hides the catch: 32 layers × 2 × 8 KV heads × 128 head_dim × 2 bytes = 128 KiB per token, so Ollama’s default 4K window already costs 512MB of KV cache on top of the weights — an eighth of a 4GB card before you have said anything. ollama pull phi4-mini | 3.8B | Q4_K_M | 2.5GB | mid · ~2.5GB/token |
| qwen3:4b The largest parameter count on this list, and the cleanest illustration of the Q4_K_M rule of thumb: 2.5GB ÷ 4B ≈ 0.63GB per billion parameters. Ollama lists it at 256K context, far more than a 4GB card can ever hold — treat that number as the model’s ceiling, not yours. ollama pull qwen3:4b | 4B | Q4_K_M | 2.5GB | mid · ~2.5GB/token |
| granite4.1:3b IBM’s Apache-2.0 small model with tool calling and a 128K listed context. The permissive licence is the reason to pick it over the Llama and Qwen rows if this is going anywhere near work; at 2.1GB it also leaves the most room of the 3B class for an actual context window. ollama pull granite4.1:3b | 3B | Q4_K_M | 2.1GB | fast · ~2.1GB/token |
| llama3.2:3b The safe default when a tool, script or tutorial assumes a Llama. Its config is public, so the context maths is checkable: 28 layers × 2 × 8 KV heads × 128 head_dim × 2 bytes = 112 KiB per token. A 4K window is ~448MB; a 32K window would be ~3.5GB, which is more than the entire card. ollama pull llama3.2:3b | 3B | Q4_K_M | 2.0GB | fast · ~2.0GB/token |
| qwen2.5-coder:3b The coding pull for 4GB, and the one row here where a long context is genuinely affordable. 36 layers × 2 × 2 KV heads × 128 head_dim × 2 bytes = 36 KiB per token, so a 16K code window is only ~576MB — a third of what phi4-mini charges for the same span. Pair with qwen2.5-coder:1.5b (986MB) for inline autocomplete. ollama pull qwen2.5-coder:3b | 3B | Q4_K_M | 1.9GB | fast · ~1.9GB/token |
| llama3.2:1b The size to drop to when a 3B keeps spilling. 16 layers × 2 × 8 KV heads × 64 head_dim × 2 bytes = 32 KiB per token makes it the cheapest context on the page — though even here the advertised 128K window works out to exactly 4 GiB of KV cache, the size of the whole card, so the ceiling is still your GPU rather than the model. ollama pull llama3.2:1b | 1B | Q4_K_M | 1.3GB | faster · ~1.3GB/token |
| gemma3:1b The floor, and the one that still works when the same 4GB card is driving two monitors and a browser. Sub-gigabyte weights mean summarising, classifying, routing and rewriting; it is not a model you reason with. gemma3:270m (292MB) exists below it if you are building something embedded. ollama pull gemma3:1b | 1B | Q4_K_M | 815MB | fastest · ~0.8GB/token |
What won't fit in 4GB
- ✗qwen3.5:4b (needs 3.4GB) — The 6GB tier’s winner, and the single most likely mis-pull here — it is under 4GB on paper, which is exactly the trap. 3.4GB of weights on a 4GB card leaves ~0.6GB before Windows takes its share, so the KV cache has nowhere to live and Ollama starts offloading on the first long prompt.
- ✗gemma3:4b (needs 3.3GB) — Same shape, same outcome. Note the tag inversion too: gemma3:4b-it-qat is 4.0GB, so on Gemma 3 the quantisation-aware build is the bigger one and neither fits comfortably. gemma3:1b is the Gemma that belongs on a 4GB card.
- ✗gemma4:e2b-it-qat (needs 4.3GB) — The smallest variant Ollama publishes for Gemma 4 at all, and it is larger than the entire card. There is no 4GB entry point to this generation of Gemma — stay on gemma3:1b.
- ✗granite4.1:8b-q2_K (needs 3.4GB) — The "just quantise it harder" answer, and a real published tag. It loads, leaves roughly 0.4GB for KV cache plus desktop, and has given up more quality than any other build IBM ships. granite4.1:3b at Q4 is the better machine on the same card.
- ✗qwen2.5-coder:7b (needs 4.7GB) — The coder most people actually want. It is larger than the whole card, so every prompt runs partly on your CPU. qwen2.5-coder:3b (1.9GB) is the 4GB coding model.
- ✗llama3.1:8b (needs 4.9GB) — The classic 8B ask and the standard disappointment at this tier. It is 0.9GB bigger than the card before any context, so Ollama splits it — and a split model runs at the speed of the slow half. The 8B class is an 8GB-card class.
- ✗deepseek-r1:8b (needs 5.2GB) — Reasoning models emit long thinking traces, so they need the most context headroom, which is exactly what 4GB has least of. deepseek-r1:1.5b (1.1GB) is the way to get a visible chain-of-thought on this card.
How to fit more in 4GB
- →The "speed" column is each model’s published size standing in for bytes read per generated token, not a benchmark. Decode is memory-bandwidth bound, so tok/s ≈ your card’s bandwidth ÷ that figure — accurate for a dense model, generous for a mixture-of-experts. A GTX 1050 Ti and an RTX 3050 4GB laptop run this identical list at very different rates, which is why no absolute tok/s is quoted here.
- →Budget from ~3GB usable, not 4GB. Windows plus a hardware-accelerated browser can hold 0.5–1GB of VRAM before Ollama loads anything; on a 6GB card that is 8–17% of the budget, on a 4GB card it is 12–25%. That difference is the whole reason a 3.3GB model fits at the 6GB tier and does not fit here.
- →Context is the entire game at 4GB. Ollama defaults anything under 24 GiB of VRAM to a 4K window, and on llama3.2:3b that costs 112 KiB per token × 4096 = ~448MB. Raise it to 32K and the KV cache alone is ~3.5GB, larger than the whole card. At this tier the default is not a limitation, it is the budget.
- →Read the tag, not just the model name. Ollama publishes qwen3.5:2b at 2.7GB and qwen3.5:2b-q4_K_M at 1.9GB — 0.8GB, a fifth of a 4GB card, decided by a suffix. It runs the other way on Gemma 3, where gemma3:4b is 3.3GB but gemma3:4b-it-qat is 4.0GB. Check the size on the tags page before you pull.
- →Buy context back with KV quantisation rather than with a smaller model. Ollama supports OLLAMA_KV_CACHE_TYPE=q8_0 with flash attention enabled, which its docs describe as roughly half the memory of f16 with very little quality loss — on llama3.2:3b that turns a 448MB 4K cache into about 224MB.
- →Run exactly one model at a time. Ollama keeps recently used models resident and will happily load a second alongside the first; on 4GB that is an instant spill. Set OLLAMA_KEEP_ALIVE=0 if you switch models often, or unload explicitly with a keep_alive of 0.
- →Old 4GB cards are supported, but check your driver version. Ollama requires CUDA compute capability 5.0 or higher, and its GPU docs add that cards in the 5.0–6.2 range — which covers every 4GB Maxwell and Pascal card, GTX 750 Ti through GTX 1050 Ti — need driver 570 or newer. A GTX 1650 is compute 7.5 and only needs 550+.
- →Load a model, then run `ollama ps` in a second terminal. The PROCESSOR column must read 100% GPU; any CPU share means the model spilled past your 4GB. Ollama’s own docs use exactly this check, and at this tier you should run it every time you change a model or a context setting.
- →Know what a spill actually costs before you accept one. The offloaded layers read from system RAM: dual-channel DDR4-3200 is 2 × 3200 MT/s × 8 bytes = 51.2 GB/s, and a single-channel laptop is half that. Since decode is bandwidth-bound, the CPU share sets the pace for the whole generation — which is why a fully-resident 3B beats a partly-offloaded 8B on this card.
Quick start
curl -fsSL https://ollama.com/install.sh | shollama run qwen3.5:2bollama ps # PROCESSOR must read 100% GPUOLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serveGo from "it runs" to actually building
All 561 chapters — running local models, RAG, agents, fine-tuning — plus the Python Lab and every course added later.
Frequently asked questions
What are the best Ollama models for 4GB VRAM?
qwen3.5:2b (2.7GB) as the most capable all-rounder, phi4-mini (2.5GB) and qwen3:4b (2.5GB) as the strong text-only defaults, granite4.1:3b (2.1GB) when the licence matters, llama3.2:3b (2.0GB) when something expects a Llama, qwen2.5-coder:3b (1.9GB) for code, and llama3.2:1b (1.3GB) or gemma3:1b (815MB) when the same card is also driving your monitors. Every size quoted is the one Ollama publishes in its own library.
What is the best LLM for 4GB VRAM, not just in Ollama?
The same list, because the constraint is the card rather than the runner. Ollama, LM Studio and llama.cpp all load the same GGUF weights, so a 2.5GB file is 2.5GB of VRAM whichever one opens it. On 4GB you are choosing inside the 1B–4B class at Q4, and qwen3.5:2b is the most capable option that still leaves headroom for a context window. The only thing that changes between runners is the default context length — Ollama picks 4K below 24 GiB of VRAM, and other tools may default higher and OOM you.
Can Ollama run a 7B or 8B model on 4GB VRAM?
Not on the GPU. llama3.1:8b is 4.9GB and qwen2.5-coder:7b is 4.7GB, both larger than the entire card, so Ollama splits the model and runs the remainder on your CPU. That share reads from system RAM — dual-channel DDR4-3200 is 2 × 3200 MT/s × 8 bytes = 51.2 GB/s, single-channel half that — and because decode is memory-bandwidth bound, the slow half sets the pace for everything. Run `ollama ps`: if PROCESSOR is not 100% GPU, that is what happened.
What is the best Ollama model for coding on 4GB VRAM?
qwen2.5-coder:3b at 1.9GB. It is the smallest model on this page actually trained for code, and its attention layout makes context unusually cheap: 36 layers × 2 × 2 KV heads × 128 head_dim × 2 bytes = 36 KiB per token, so a 16K window costs only about 576MB — affordable on 4GB in a way it is not on phi4-mini. For inline autocomplete drop to qwen2.5-coder:1.5b (986MB) and leave the 3B for chat. The 7B coder is 4.7GB and does not fit.
Is a 4GB GPU worth using for Ollama, or should I just run on the CPU?
Worth using, provided you stay at 3B and under. A model held entirely in VRAM reads at GDDR bandwidth instead of DDR bandwidth, and that gap is the difference between a usable assistant and a slideshow — so a fully-resident 2B beats a partly-offloaded 8B every time. What a 4GB card cannot do is run the 7B–14B models most "best Ollama models" lists assume, and no quantisation trick changes that: granite4.1:8b-q2_K is a real 3.4GB tag and it still leaves nothing for the KV cache. If the models on this page are too small for the job, the honest options are a 6GB or 8GB card, or CPU-only inference with a lot of system RAM.
Related guides
Ready to Go Beyond Tutorials?
20 structured courses with hands-on chapters - build RAG chatbots, AI agents, and ML pipelines on your own hardware.
Was this helpful?