Ollama RAM & VRAM Requirements: Can Your Computer Run Local AI?

Short answer: Ollama does not have one universal “minimum RAM” number. A model may fit in memory and still feel unusable once you increase the context window, send parallel requests, or leave part of the model on the CPU. The useful question is therefore two questions: can this model load on my machine? and can it run at a speed and responsiveness I can accept?

This guide explains how to answer both without treating a model’s download size as a hardware guarantee. It covers system RAM, dedicated VRAM and unified memory, quantization, context and KV cache, concurrency, disk space, CPU offload, and the cost of running local AI. The Ollama and model-library facts below were checked on September 10, 2026; hardware results still depend on the exact model tag, backend, drivers, operating system, and workload.

“It loads” is not the same as “it feels good”

There are at least four checkpoints:

1. Download: the model package fits on the disk.
2. Allocation: Ollama can reserve enough memory for weights and runtime buffers.
3. Placement: the model is placed on the GPU, CPU, or a split between them.
4. Experience: prompt processing, time to first token, generation, heat, battery use, and multitasking are acceptable for your use case.

Only the first two can be answered from a model page and a rough memory inventory. The last two need a real run on your own computer. This is why a “7B model needs exactly X GB” chart is usually more confident than the evidence allows.

RAM, dedicated VRAM, and unified memory

System RAM

System RAM is used by the operating system, applications, Ollama’s server, and any model layers running on the CPU. If a model is fully CPU-resident, system RAM is the main working memory. It is also the fallback pool for a split CPU/GPU placement, so “I have enough VRAM” does not mean the rest of the computer is irrelevant.

Leave headroom for the OS, browser, documents, embeddings, and the application calling Ollama. A machine that can allocate a model only after closing everything else may be technically compatible but practically inconvenient.

Dedicated GPU VRAM

A discrete GPU has its own memory pool. GPU inference generally wants the model’s active weights and runtime allocations to fit in that pool. Ollama’s own documentation notes that increasing the context length increases memory requirements, and recommends checking placement with ollama ps rather than assuming from the model’s parameter count alone.

VRAM is not just “the model file in a different location.” The working set can include weights, the KV cache, compute-graph/workspace allocations, and other backend overhead. The exact split changes with model architecture, quantization, context length, and parallel requests.

Unified memory

On a unified-memory design, the CPU and GPU share the same physical memory pool. Apple describes this directly in its Metal documentation: a unified GPU shares its memory with the CPU, while a discrete GPU uses a separate GPU memory pool. That can make a large memory number look more flexible than dedicated VRAM, but the pool is still shared with the operating system and applications. It is not “free VRAM.”

For planning, treat unified memory as a shared budget. A 24 GB machine does not necessarily have 24 GB available for an Ollama model, and a large model can pressure the OS even when a graphics panel reports that the GPU can address the memory.

Quantization changes the weight footprint, not the whole bill

Quantization stores model weights with fewer bits or a lower-precision format. In practice, a quantized tag can be far smaller than a full-precision tag and may make local inference possible on a smaller machine. It can also trade some quality, compatibility, or accuracy for that smaller footprint; the trade-off is model- and task-dependent.

Do not turn “4-bit” into a guaranteed VRAM number. The runtime still needs non-weight memory, and the same quantized weights can have different overhead across architectures and backends. Context and parallel requests can add substantial allocations after the model has loaded.

The official Ollama library is useful for seeing the difference between tags. For example, its current Gemma 3 listing shows gemma3:4b at 3.3 GB, gemma3:12b at 8.1 GB, and gemma3:27b at 17 GB, each with a 128K context window. Those are listed package sizes, not promises that a machine with exactly that much memory will run the model. The Llama 3.1 tag list similarly shows multiple 8B variants from 3.2 GB for q2_K to 16 GB for fp16.

Use a tag’s size to plan disk space and a first experiment. Use Ollama’s runtime status and your own workload to decide whether the experiment is useful.

Context length and the KV cache are the common surprise

Context length is the number of tokens the model can access in memory for a request. Ollama’s official context-length guide explicitly says that a larger context requires more memory. The same guide currently documents default context lengths based on available VRAM: below 24 GiB, 4K; 24–48 GiB, 32K; and 48 GiB or more, 256K. These defaults are not a universal recommendation for every model or workload.

The practical implication is simple: a model that loads at a small context may fail, spill to the CPU, or become uncomfortable when you ask it to process long documents, search results, coding context, or agent traces. The KV cache holds attention state for the active context; as the context grows, that state grows too. It is runtime memory, not part of the download size shown in the library.

Ollama documents the OLLAMA_CONTEXT_LENGTH setting for changing the server context:

OLLAMA_CONTEXT_LENGTH=64000 \
ollama serve

Set context for the task you actually need. Do not raise it because a model page advertises a large maximum. A short chat, a coding session, and a long agent workflow have very different memory profiles.

Concurrency multiplies the pressure

A single interactive chat is not the same workload as a local API serving several clients. Ollama’s FAQ explains that concurrent processing depends on available system memory or VRAM. It also notes that parallel requests increase the effective context allocation: for example, a 2K context with four parallel requests behaves like an 8K context for memory planning.

The relevant server controls include:

• OLLAMA_NUM_PARALLEL limits parallel requests per model; required memory scales with parallelism and context.
• OLLAMA_MAX_LOADED_MODELS limits how many models may remain loaded at once when memory allows it.
• OLLAMA_MAX_QUEUE controls how many requests can wait before Ollama reports that the server is overloaded.

For a personal workstation, start with one model and one interactive request. For a home server or small team, budget for the peak number of simultaneous contexts, not the average number of users. Otherwise a setup that looks fine in a single-user demo can queue, unload models, or run out of memory under real use.

CPU offload: a compatibility path, not a speed promise

If the model cannot fit entirely in VRAM, Ollama may place some layers in system memory and some on the GPU. The official FAQ shows the PROCESSOR column as the way to see this: 100% GPU, 100% CPU, or a split such as 48%/52% CPU/GPU.

ollama ps

Partial offload can be a reasonable way to make a larger model load. It also means that CPU memory bandwidth, GPU/CPU transfer, thermals, and the prompt’s context all matter. Ollama’s context guide recommends avoiding CPU offload for best performance, but that is a performance guideline—not a claim that CPU offload never works. Check the actual split and treat the resulting latency as hardware-specific.

If Ollama unexpectedly falls back to CPU, check the official troubleshooting guidance for drivers and GPU discovery before buying more memory. A driver or container configuration problem can look like a hardware limit.

Disk space is a separate constraint

Model files are large, and keeping several variants multiplies storage use. The library’s listed size is a useful download-footprint reference, but it does not include every temporary file, cache, or the free space needed for updates. Leave room for:

• the model tag or tags you actually keep;
• temporary downloads and replacement versions during updates;
• Ollama’s application/runtime files;
• logs, embeddings, vector stores, and the front end that calls Ollama.

Prefer one well-chosen model over collecting every quantization. A smaller model that stays loaded and responds predictably can be more useful than a larger model that repeatedly unloads or exhausts the machine.

A cautious hardware triage checklist

The following is a workflow, not a compatibility guarantee:

1. Record the real budget: total and currently free system RAM, dedicated VRAM or unified memory, free disk space, operating system, and GPU driver/backend.
2. Pick one official tag: start with a small or mid-size quantized tag whose listed package size fits comfortably on disk. Do not compare only the parameter count.
3. Start with a modest context: use the model’s normal chat workload first. Increase context only when a real task needs it.
4. Load one model: do not test with several large models left resident or with artificial parallel traffic.
5. Inspect placement: run ollama ps and record the processor split and context shown by Ollama.
6. Test your task: use the prompt length, output length, files, tools, and concurrency you care about. Measure your own waiting time and system pressure.
7. Change one variable: if it is slow or unstable, reduce context/parallelism, try another quantization, or choose a smaller model before changing several settings at once.

“Can my computer run a 7B model?” is therefore incomplete. A better question is: “Can my computer run this exact tag, at this context and concurrency, with enough memory headroom that the resulting latency is acceptable for my task?”

Local AI versus API or subscription cost

Local inference replaces some provider charges with a different cost stack: hardware, electricity, cooling, storage, upgrades, setup time, monitoring, and troubleshooting. It can be attractive when the workload is frequent, privacy-sensitive, or predictable, but the fixed cost is paid before the first useful token.

An API usually charges for usage under the provider’s current model and billing rules. Google’s official Gemini pricing page, for example, separates free, paid, batch, priority, caching, and tool charges; Anthropic describes prepaid API usage credits and auto-reload in its billing help. These details change, so use the provider’s current pricing pages rather than copying an old price table into a hardware guide. For a workload-specific estimate, compare those variable costs with the local hardware and maintenance costs using our AI API Cost Calculator and AI Subscription vs API analysis.

Do not treat local AI as automatically cheaper. If you use a GPU only occasionally, API usage may be less expensive than buying or renting hardware. If you need frequent private inference and already own suitable hardware, the calculation can reverse. The break-even point depends on tokens, model quality, latency, uptime, and your value for hands-on maintenance.

What to choose first

For a broader look at local interfaces, agents, and workflow tools, browse our Self-Hosted AI Tools directory, then compare the application layer in Open WebUI vs LibreChat vs LobeHub and Dify vs n8n vs Langflow. Those tools do not remove the underlying model-memory constraints; they make them easier—or sometimes more concurrent—to use.

FAQ

Can an 8 GB computer run a 7B model?

It may be possible with a small quantized tag, a modest context, and little else competing for memory, but the parameter count alone cannot guarantee it. “Loads” and “is comfortable for your task” are separate outcomes. Check the actual package tag, available memory, and ollama ps placement.

How much VRAM do I need?

There is no honest universal number. The model tag, quantization, context, parallel requests, runtime buffers, and other loaded models all change the requirement. Use official model metadata for the starting footprint, then validate the exact workload.

Does quantization solve the memory problem?

It reduces the weight footprint for a particular tag, but it does not remove context/KV-cache memory, compute work, system overhead, or the quality trade-off. It is one lever, not a complete sizing formula.

Is unified memory the same as dedicated VRAM?

No. Unified memory is shared by the CPU and GPU; dedicated VRAM is a separate GPU pool. Unified memory can be flexible, but the operating system and other applications use the same physical pool, so the advertised capacity is not all available to Ollama.

Where can I see whether Ollama is using my GPU?

Run ollama ps while the model is loaded and read the PROCESSOR column. It tells you whether the model is on the GPU, CPU, or split. It does not replace a task-specific latency test.

Sources and method

This guide uses the official Ollama context-length documentation, the Ollama FAQ, and Ollama’s Gemma 3 model library and Llama 3.1 tag metadata. The unified-memory explanation follows Apple’s Metal unified-memory documentation. Cost notes point to Google’s Gemini API pricing and Anthropic’s API credit billing guidance. No Ollama benchmark was run for this article, so it does not present any speed, temperature, or exact memory result as a site test.