Running Ollama and LM Studio: Hardware Requirements Explained

A developer hears about Ollama, installs it in a few minutes, and pulls down a model to try running a language model locally for the first time. The smaller model runs fine. Then curiosity (or a real use case) points at a bigger, more capable model — and it either loads at a crawl, or Ollama reports it can't fit the model in memory at all. The tool didn't do anything wrong; the hardware just wasn't sized for that particular model.

Ollama and LM Studio are both front ends over the same underlying engine — llama.cpp — running quantised models in the GGUF format, so their hardware requirements are identical for a given model and quantisation level; the choice between them is about interface, not capability. What actually determines whether a model runs well is VRAM for the model size and quantisation you want, with system RAM as the fallback (slower) path when VRAM runs short, and enough storage headroom because model files are large and most people end up keeping several around. At Sephora's August 2026 prices, an RTX 5070 (12GB) at ₦1,400,000 is a comfortable entry point for 7B-class models; step up to the RTX 5070 Ti (16GB) at ₦1,700,000 if you know you want 13B-class models or larger from the start.

Sizing VRAM to the Model You Actually Want to Run

Quantisation is what makes running a large language model on consumer hardware possible at all — it compresses a model's weights from their original precision down to a smaller footprint, trading a small amount of output quality for a large reduction in memory use. Our GGUF quantisation guide covers the trade-off in depth; the short version for hardware planning is that a common 4-bit quantisation roughly needs half a gigabyte of VRAM per billion parameters, plus overhead for context length.

That 70B row is worth being straightforward about: no single Sephora catalogue GPU has enough VRAM to run a 70B model comfortably on its own, even quantised. That's a genuine multi-GPU or CPU-offload scenario, not something a bigger single card solves — if that's the model you actually need, plan around that reality rather than assuming one more VRAM tier gets you there.

Context Length Also Costs VRAM

Model size isn't the only thing eating your VRAM budget — the context window (how much conversation history or document text the model can consider at once) has a real memory cost of its own, on top of the model's base weight. A short back-and-forth chat barely touches this; feeding a model a long document to summarise, or running a coding assistant against a large file, can add a meaningful chunk of VRAM use before the model does anything with the content. This is a common surprise for people who size their GPU purely against the model-size table above and then find a long-context session runs slower or fails to load where a short one worked fine. If your actual use case leans on long context — document analysis, large codebases — size your VRAM headroom a step above what the base model size alone suggests, rather than exactly at the line.

When VRAM Runs Short: the RAM Fallback

Both Ollama and LM Studio can split a model between VRAM and system RAM when the model doesn't fully fit on the GPU — layers that don't fit stay in RAM and run on the CPU instead. It works, and it's a real way to run a model your GPU alone couldn't hold, but it comes with a genuine speed cost: CPU-side inference is meaningfully slower than GPU-side, so a partially-offloaded model runs noticeably slower than one that fits entirely in VRAM. If you're leaning on this regularly rather than occasionally, that's a sign to size up the GPU rather than the RAM. A 64GB DDR5 kit (₦1,560,006 at Sephora's catalogue pricing) gives real offload headroom for when you do need it; 128GB (₦3,120,011) is usually more than a single-model workflow needs unless you're routinely running the largest models CPU-assisted.

Storage: More Models Than You Expect

A single model file runs anywhere from around 4GB for a small quantised model up to 40GB or more for a large one at higher precision — and almost nobody who gets seriously into local models stops at just one. Comparing a general-purpose model against a coding-specialised one, or comparing quantisation levels of the same model to find the right speed/quality trade-off, means keeping several files around at once. A 1TB PCIe 4.0 NVMe drive (₦215,001) is a reasonable floor if you're keeping more than two or three models on hand; step up to 2TB PCIe 4.0 (₦409,995) if you expect to accumulate a real library over time rather than delete and re-download as you go.

Nigeria Context: Downloading Models Is the Slow Part

Model files are large, and pulling one down for the first time is a real bandwidth commitment, not a formality — a 20-40GB download over a connection that isn't consistently fast can take considerably longer than the setup itself. Plan the first pull for a time your connection can handle it, and once a model is on disk, everything after that runs entirely local — no ongoing bandwidth cost per query, which is one of the real advantages of running locally over a cloud API in the first place.

Common Setup Mistakes

The most common mistake is picking a model size based on what a benchmark leaderboard recommends rather than what your actual GPU can hold with room to spare — loading a model that just barely fits leaves no headroom for context length or for running anything else alongside it, and the result is a machine that feels sluggish even though the raw hardware is capable. Size down one step from the theoretical maximum your VRAM allows, not up to it.

The second is assuming a heavily-quantised model is a free lunch. Lower-bit quantisation (below 4-bit) saves real memory, but the quality trade-off is more noticeable than the jump from full precision to 4-bit — for coding or technical work specifically, that quality loss can matter more than the VRAM savings are worth. Test a model at the quantisation level you actually plan to use before deciding it's good enough, not at full precision in a demo.

The third is not checking whether a specific model architecture is well-supported by llama.cpp yet — new model families sometimes lag behind on optimised support, which shows up as slower-than-expected performance that has nothing to do with your hardware. If a model runs unexpectedly slowly on hardware that should handle it comfortably, that's worth checking before assuming the GPU is the problem.

Running Multiple Models at Once vs. Switching Between Them

Both Ollama and LM Studio can technically hold more than one model loaded simultaneously, but doing so splits your available VRAM between them — a machine comfortable running one 13B model can struggle running two at once, even if each individually would fit. For most people, the practical pattern is switching between models as needed rather than keeping several loaded — Ollama in particular handles this well, unloading an idle model automatically after a period of inactivity so the next one you call has full VRAM available. If your actual workflow genuinely needs two models resident at once — a small, fast model handling quick queries while a larger one handles complex ones, say — size your VRAM for the sum of both, not the larger one alone.

Related Workflows

If you're building toward something more structured than chatting with a model directly — retrieval over your own documents, for instance — our RAG and vector-database workstation guide covers the hardware profile for that specific workflow, which often runs Ollama underneath as the local inference layer. And if your interest in local models started with general computer-vision or training work rather than language models specifically, our computer-vision workstation guide covers a related but distinctly different hardware priority list.

For most people getting serious about running local models with Ollama or LM Studio, the honest starting point is the RTX 5070 — enough VRAM for genuinely useful 7B-class models today, with a clear upgrade path if your ambitions grow. Sephora Systems, a custom PC and workstation builder based in Abuja with an experience centre in Gwarimpa, can build around that exact profile — start from a local-LLM-tuned entry build in the configurator rather than guessing at a spec list yourself.